You can't make everything you need out of holes. Your tunnels will need doors, partitions, tables, etc., etc. No IKEA on Mars and the shipping charges are horrendous. There are lots of things besides main structural walls to be made.

Thanks for all your calculations, but you entirely neglect auditory acoustic response issues, or the fact this energy is coming exclusively in rapid rise impulses.

There is more direct information in this readily available. We read here that the
"Concorde's sonic boom noise level was 105 PLdB. The PLdB that researchers believe will be acceptable for unrestricted supersonic flight over land is 75, but NASA wants to eventually beat that and reach 70 PLdB."
The measure PLdB is "perceived level of decibels" which takes into the account that impulsive, rapid rise sounds appear louder to humans. A 105 dB sound is a very loud sound to anybody. There would be hundreds, perhaps even thousands, of supersonic flights coast-to-coast a day if this became commercial. If you were under a common flight corridor, you might hear one of these every few minutes all day long.

The NASA article discusses though the fact that aircraft design can lessen sonic booms, and that is real key to making this a viable transcontinental technology.

But where we really need supersonic flight is on trans-Pacific flights! Where are the hypersonic trans-Pacific airliner projects these days?

Amen to this! I like everything - if it is good. I enjoy discovering new styles, genres, bands. I have been around awhile, but I was one of Pentatonix's first fans for example. Went to one of their concerts a few months back - Cello/beatboxing was showcased and it was cool! Check out Mattisyahu: his Hassidic/Reggae/Rap fusion is brilliant. Here's a tip - listen to an unfamiliar style/genre more than once. I listen to music from all over the world. It takes time to appreciate the nuances that each style/genre brings. (Bluegrass is one of America's greatest contributions to music.)

I am a big proponent of agile methods (see the agile thread today), but here I disagree. A UI is part of the system architecture, and architecture fundamentals do need to be defined early in development (but then refined and evolved as development proceeds). Agile is definitely not "making stuff up as you go along".

Or: because anything that enables vote-count corruption favors Republicans.

There is no evidence of significant voter fraud anywhere, that's why voter ID proponents never cite any real cases. The only problems with corruption of the voting system occurs when the votes are counted, or measures to deny people the ability to vote.

Just makin' stuff up, I see.

And the fact that these voted ID laws never include proactive provisions to get IDs into the hands of all voters for free reveals their true intent quite clearly. Heck, Ohio is trying to enact a poll tax (banned explicitly by the Constitution, 24th Amendment) by requiring a voter ID card that you must pay for.

I actually agree with this. The documentation does need to evolve with the implementation, and if you don't, it is as you say. But having a clear concept about how it is to be used, and working out a coherent description of using it is a very strong design tool to make a usable, understandable system.

Inapplicable (or should be). There is no "standard" here. It is a collection of related, mutually supporting practices and tools. People who try to make it into "name brand" all-or-nothing methodologies can create that impression though.

Iterative, incremental development - the core of agile - has been around at least since Barry Boehm described the "spiral model" of development in 1986, and has been successfully used for nigh upon 30 years since under various monickers (and I'll bet there were practitioners before Boehm's paper).

"Agile" has matured and developed a lot of inter-related supporting practices and tools that have made it increasingly powerful and easy to implement. Continuous integration, test-driven development, use of "stories" as a tool for requirements definition, you cannot tell me these techniques and tools are not successful.

I have personally seen the development practices of a company dramatically transformed for the better by having an agile trainer brought in and training the entire staff, including managers, and instituting formal agile practices. It is great when a junior developer can tell the VP of marketing to take a hike because his request has not been submitted through the grooming and priority assignment process.

This one experience gives me complete confidence that people mocking agile simply do not know what they are talking about.

One problem agile does have is with zealots who don't understand that this is, and has to be, a collection of related practices that must be tailored to the needs of the environment, not a one-size-fits-all, all-or-nothing thing. Another problem is thinking that "form" is what is important, not "what is happening".

For example: holding stand-ups is not agile. It is a common, useful tool to use in an agile environment. If your team is coordinating with informal sessions as needed, Skype, chat tools, and an updated Wiki in real time, and the managers are keeping in the loop using these tools, then maybe a stand-up is a waste of time for you. I think most teams benefit, but design and planning is not part of a stand-up, other meetings are needed for these.

There can be long-term planning that does not follow the agile model, and can be described as water-fall, and this has its place too. But I think the only really successful development practices are variants of an "agile" type process.

And not because it has to be that way. The software is just poorly designed.

In an ideal world, user documentation would be written before the software so that an understandable, consistent, UI would exist. This sometimes happens, but even then, the implementation may not match the documentation (yes, I have seen this more than once).

Design principles like: simple things (and common tasks, even if not exactly simple) should be simple to do; the same technique should work in all contexts; etc. are often ignored in OS projects.

I have come to despair in trying to find a nice open source (Linux) object-drawing program that is intuitive (and thus easy to learn), has consistent behavior, and allows the quick creation of clean basic diagrams, and maybe has an additional level of finer controls for more precise work. The original Macintosh had this back in the 1980s with MacDraw, and the even more awesome MacDraw II. Complete novices could take the program and discover how to make good looking "boxologies" in minutes just by playing with the tools. Maybe such programs are still available on the Mac platform (I haven't had one in years), but no OS object drawing or 2D CAD program on Linux seems able to grasp what one of the first such pieces of software on the market was able to accomplish.

(Another really annoying thing to find in user documentation is self-praise about the product and accompanying documentation: making promises about how great the product is, and how wonderful the documentation you are looking at is, that are rarely kept.)

Videos have their place, I grant. Especially when it comes to manipulating some object (could be a graphical object on a screen), where a verbal description just cannot compete.

But I hate "video documentation" with an undying passion. They have an extremely so rate of information transfer, typically very low information density (see how little text is in a 5 minute video script), cannot be scanned at all, require you to have an audible audio hook-up, cannot be copied for notes,... I'm just getting started here, but you get the picture. I can literally take in information 10 times faster in printed form, and locate relevant content even faster than that.

If video documentation is available as optional back-up, great! But if that is the only documentation, I will not use whatever-the-heck-it-is, I'll find something else.

That's a good call. With Cloudera and HortonWorks both adding new components to the Hadoop stack it has exploded in the number of components in the last a year or two, and that can be a bad thing. The complexity of the whole ecosystem is getting horrendous, with a typical configuration file doubling from 250 or so to 500 configuration items, which are almost all undocumented (unless you read the code - which scarcely qualifies as "documented") in the last year. For a practical deployment you are pretty much forced to use a commercial stack to get something up and running in a manageable fashion. And then there is the fact that the HDFS foundation is showing its age.

Spark on Mesos is looking mighty awesome.

MapReduce is still viable for stable production jobs, but not in a dynamic requirements environment.

Although HiveQL is alive and kicking, the complete replacement of Hive Server with Hive Server 2, while possibly an improvement in usability overall (I am not convinced), it trashes your skill investment in the (now) obsolete Hive stack component. Maybe I am just grousing, but I start having reservations about technology planning in the data center when a key stack component changes so much it a relatively short period of time

Brookings analyses have increasingly been up for sale. Not surprisingly it is taking up this pro-Microsoft, pro-Gates agenda after the Bill's foundation became their biggest contributor.