If you aren't backing up your data to removable storage, then it is not valuable to you.

The best choice is almost certainly to aim for the Pacific and evacuate all the coastal areas. The devastation from a mega-tsunami is far preferable (and more temporary) than the long-term climate disruption of a land collision. The amount of dust ejected into the air could easily trigger a "nuclear winter" kind of disaster.

Southwest has their quirks (poor boarding procedures for people with kids, some people really don't like open seating, etc), but they continue to allow each passenger two checked bags for free. They also don't charge explicit fees for ticket changes, though you have to pay the difference in seat prices if they have gone up. So far, they seem to be doing OK, so at least one airline hasn't had to go super-crazy with the unbundling to stay profitable. (Instead they just made their frequent flier awards much harder to use than 5 years ago.)

I think the only "extra charge" option is their Early Bird checkin, which basically gets you on the plane first for $10.

Super-Kamiokande would light up like Christmas from a supernova only 600 light years from Earth. (Hopefully they still have a trigger configured to save such data, despite being used now as a target for the T2K experiment.) Super-K is 10x larger than Kamiokande-II and Kamiokande-II was able to detect 11 events from a supernova that was 250x further away than Betelgeuse. Granted, not all supernova have the same intensity, but still, I think we'd have a pretty good view from here.

Guess? You didn't say anything about the design of Google's Storage API. (Which is fine by me, since the basic premise of this thread is stupid. The storage API is designed to match the S3 API, and isn't targeting end-users in the first place.)

I assume they used the word "bucket," because that's what Amazon calls the same abstraction in S3. And that's really the target audience for this storage system: developers who are currently using Amazon S3 or are familiar with it. The idiot complaining about this API is angry that he went to a hardware store and didn't find the pipes already in the shape of his sprinkler system, possibly because he doesn't know what a hardware store is.

I tend to think of your taxonomy in terms of design outcomes:

4. Sufficiently engineered
3. Over-engineered
2. Under-engineered
1. Doesn't work or works on accident.

That is to say, average developers tend to nail the common case, but lack the experience or knowledge to spot the corner cases. Your "above average" developer wants to demonstrate his knowledge by optimizing for as many corner cases as possible at the expense of simplicity in the common case. The well-above average developer can balance the common and the exceptional.

Both over and under-engineered solutions are "bad," but the under-engineered solution usually has the advantage of less code to delete when you have to redesign everything. :)

To be perfectly honest, I would be skeptical of any sociological conclusions drawn by primetime TV news programs, which are famous for peddling sensationalist moral panics about "the kids these days." They tend to be heavy on anecdotal evidence and cherry-picked expert testimony.

For one year during the middle of my CS degree, the department tried to enforce a rule that said that no student was allowed to view code in electronic or print form written by another student. We (and possibly some of the instructors) pushed back on this rule until it was repealed with good reason. While certainly it made certain kinds of leeching unambiguously disallowed, it also eliminated cooperative debugging, which we found incredibly helpful. I learned more about practical coding, and working with other programmers debugging other people's code than I ever did debugging my own code (or even writing it in the first place).

Yeah, most of the cheating I heard about in my CS program 10 years ago was not from people who were necessarily lazy or "party-people" or whatever the usual stereotype is. Most of the temptation to cheat was for people who were completely in over their head with the entire subject and felt backed into a corner. They were wedged between a lack of preparation and social pressure to succeed. ("I did OK in math class, and I like using my computer, so why can't I do this?") The first time many of them had ever thought critically about the structure and function of a computer was day one of CS 101 (consider trying to do college algebra if you had never seen mathematical operators before) and they just got more behind as time went on. This was not helped by the cattle herd design of public university classes.

The ethically smart ones got extra tutoring from classmates and teaching assistants, or worst case, switched degrees when they realized they were hopelessly behind. The not so smart ones abused the help of their friendly/naive classmates or found some other way to BS through the material. Most of the time, this didn't work out even on semester timescales, but I do remember one group project where a guy couldn't write a single line of code unprompted, yet somehow had landed a job at IBM to start at the end of the semester.

I don't have any sympathy for people who cheat in classes, but I agree that characterizing the problem as simple laziness or the "moral bankruptcy of the kids these days" teaches you nothing about how to address the problem. Sadly, the solution probably involves things that are socially or economically infeasible: Smaller intro classes, actual focus on pedagogy and not teaching fads in intro classes, de-emphasis of 4-year degrees as a prerequisite for white-collar employment, more investment and advertisement in focused two-year programs for technical fields, etc.

Now if every possible subset of developers has to meet, then you have a problem.... :)