"People are very open-minded about new things - as long as they're exactly like the old ones." - Charles Kettering

Drones can be hacked. Their signals jammed or spoofed. Their satellites destroyed. Their home bases attacked or infiltrated. They work very well against low tech enemies like Iraq and Afghanistan. Against the Russians or Chinese it would be a different matter, especially when the chips in a drone originate in China. War is an ever-changing game where every move has a countermove. The nice thing about human pilots is that they understand their orders and the underlying reasons for those orders. They can change their minds quickly and use situational information that drones would lack.

I'm not sure that g-force matters all that much in an era of smarter, faster missiles. When was the last real movie-style dogfight?

On the other hand, there is no question that drones are useful and will continue to improve at a rapid pace. Eventually they will replace most of our planes. With longer flight times we might be able to replace half of our aircraft carriers with land-based drones, but the inevitable cost overruns won't magically disappear.

Date-driven development is almost always a disaster. The only way it works is to completely finish a reduced feature version of the application, add and test one feature at a time to it, and ship what you have when the date is hit.

He is probably confusing lines of code with value.

I couldn't agree more about Apple abandoning perfectly fine, expensive hardware. My 8-core, 3GHz MacPro2,1 can still run circles around most of Apple's current lineup and yet it won't run Mountain Lion. I specifically waited for "64-bit" hardware so it would last longer. If new MacPros weren't so damn expensive or offered something more than compatibility in return it wouldn't be quite as annoying.

Google and Apple should respond with "We will if you will."

SPDY solves *a* problem, but not *the* problem. The root of the problem today is that loading a simple web page requires 20 or more separate connections: images, ad networks, tracking systems, social network links, 3rd party comment systems, javascript libraries, css, etc. Somehow all of that content needs to be coalesced into fewer connections.

Programmer productivity will suffer.

In general that is how it works, but Bloomberg is more of a nanny billionaire.

As an old guy, I am not looking forward to a future with servers named after Harry Potter characters. If Trek was good enough for us, it's good enough for our kids!

Now all we need is polarized contact lenses so you don't look silly.

If you had to destroy hard drives regularly, the Pure Leverage hard drive crusher looks like a nice way to do it:

http://www.youtube.com/watch?v=vY3ZssxkcsQ

But it's a bit expensive for only 10 drives -- $325.

Yes, I've cursed them for more than 25 years because trying to fit desktop application storage into relational models nearly always creates more work than necessary.

Except that the column types are fixed. What happens if keys point to different types of data (images, text, movies, urls, other tables)? Do you create one column for every type of data that may be used into the future? One table per data type? Do you misuse blob columns? One of the nice things about sqlite is that it doesn't force developers into such a restricted world view.

Just because you can haul anything in a semi truck doesn't mean that a semi truck is the optimal vehicle for hauling everything. Sometimes it's better to use 5 minivans. Do you seriously think that Google Maps are implemented in BigTable because the folks at Google were too stupid to use a relational database?

The OOP to Relational mismatch is described at: http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch

Relational databases work well for certain types of data but to assume that tables of rows and columns work for every need is silly.

Relational databases are inherently hard to scale because they mix data together that doesn't necessarily need to be together. If there's no reason why Bob and Alice's records should be in the same table or on the same machine then they shouldn't be. You can avoid all contention by distributing each individual's records on unique or underutilized machines.

Relational databases do not work well for storing hierarchical data like a file system or an object-oriented data store. They do not work well for large blobs like movie files or for unstructured documents like medical records. Because of their rigid structure, they do not version well because copying records to older versions of the schema loses data - if the column doesn't exist there's no place to put the data (imagine if application versions 1 and 2 have to read and write to the same database).

Relational databases have their place and I completely agree that transactions are vital to data integrity, but the fixed column data model is way too limited to store all of the kinds of data used in the real world.

"The bitterness of poor quality is remembered long after the sweetness of meeting a deadline is forgotten." -Charles Kettering