You make a good case for increasing upload bandwidth, but other than WAN recovery (a full restore of a 1TB disk will take 18 days), none of those requires better than a 6.5Mbit symmetric connection.

X is optimized for programs that use a small number of colors to draw an effectively vector-based user interface on a raster display. It is very, very good at that, and provides a powerful range of tools for the job.

Most programs use color-rich bitmap-based user interfaces. Doing this with core X functionality is painfully slow and difficult (think tens of seconds to draw a 800x600 JPEG), so everyone uses protocol extensions for this. Wayland is designed around bitmap-based drawing at the core.

But can't we cheer a little that some bad guys went down?

How much collateral damage was there?

When Freedom Hosting was busted, they took down a bunch of child-porn sites and de-anonymized some of the users. But in the process, they also took down TorMail, a legal anonymous email provider, and de-anonymized some of its users.

Sure, punishing guilty people is fine, but not if you punish innocent people in the process.

The problem is size. Pumped-storage hydropower can store about 2.5 watt-hours of electricity per metric ton of water per meter of drop. An average two-story house could store maybe 10 KWH if the entire attic and basement were devoted to water storage, and the building would need to be reinforced to handle the 400 metric tons of water involved.

Pumped storage really only makes sense on a large scale, when you've got a couple of valleys you can dam, and a fair-sized height difference between them.

Are you suggesting they can't detect when someone is preventing a door from closing completely by any means other than a person looking?

An obstruction interlock can certainly detect an arm or a leg, but if you set it sensitive enough to detect loose fabric (say, a scarf or a hanging sleeve), it'll be sensitive enough that thermal expansion will cause false positives and negatives.

I've seen one analysis that estimates that if all medical causes of death were eliminated, we would enjoy an average lifespan of about 650 before some accident would kill us.

The interesting thing with this is not the average, but the change in the distribution. Currently, the population curve has a sharp drop-off around the age of 70; with the elimination of medical causes of death, the curve will assume the shape of a decaying exponential, making that 650-year life expectancy more akin to a "half life".

If such a change happened today, of the 6 billion or so individuals currently alive, at least one of them could be expected to reach an age of over 20,000 years.

Why not try to get rid of the causes instead of finding out what other sort of drugs and chemicals we can add to reverse it?

We could try it, but I don't think you'd be very happy.

The #1 cause of cancer is old age. People are dying of cancer in droves because they aren't dying of tuberculosis, or pneumonia, or cholera, or epidemic smallpox, or infected cuts, or any of the other causes of death we've eliminated in the past century.

DNA copying isn't perfect. It takes, on average, 70 years for enough mutations to build up to bypass the body's anti-cancer defenses and become cancerous. Life expectancy at adulthood has gone up from 60 years to 75 years in the past century or so, and the resulting explosion in cancer cases is quite predictable.

There is a very small proportion of ideas for which crowdfunding is a good thing. These are ideas that are really great but have not been able to attract funding because investors (mistakenly) didn't see their potential.

There's a second group where crowdfunding also works well: ideas that are too small for traditional funding to get involved in. If you're seeking $50 million to develop an A-list video game, you'll have no problem attracting attention. On the other hand, if you're seeking $1000 to get a musician to produce a soundtrack for your Flash game, they'll laugh at you.

Can you think of any feature that actually requires the volume manager to be stirred together with the filesystem?

Smart array (re)builds. In the typical layered approach, the redundancy layer doesn't know what parts of the filesystem are in use, so it spends a great deal of time synchronizing empty space.

It's fast, reliable, caches intelligently, adaptable to a large variety of mirror/striping/RAID configurations, snapshots with incredible efficiency, and simply works as advertised.

Can I:

1) Add a disk to a RAID array (or whatever ZFS calls it) and reshape the array to take advantage of the space?

2) Run with less than 1 GB of RAM per TB of disk space?

3) Pull a disk that's suffered a transient failure, check it, plug it back in, and have the array write only the portions of the disk that changed, rather than doing a full rebuild?

The last time I looked at using ZFS for my storage server, #1 and #2 were deal-breakers. #3 was added when I expanded the server with a bunch of Seagate hard drives -- md's write-intent bitmaps reduced typical rebuild times from around a week to less than half an hour.

Ever seen a dam break? Look up the number of casualties due to dam breaks in the last 50 years vs the number of casualties due to nuclear meltdowns in the last 50 years. Then divide by watts.

Make sure you're counting the right dams, though. A large number of dam failures have been flood-control or irrigation dams rather than hydroelectric dams. For example, of the ten deadliest dam failures since 1964, all ten involved flood-control, irrigation, or tailings impoundment dams.

The problem isn't the lack of strong typing in JavaScript. The problem is the combination of dynamic typing and operator re-use.

In Perl, I can tell you at compile time what "5 + $val + 5" will return: a number 10 greater than the numeric value of $val (and there are clear rules for converting strings to numbers). In JavaScript, I can't tell if "5 + val + 5" will be a string value or a numeric value, except by carefully tracking the possible data flows for "val" and seeing if it comes from a string source or a numeric source (or worse, both string and numeric sources).

Are you sure the car won't spot the dog, mistake it for a child (remember, the quality of information from the front camera is reduced), and perform an emergency turn to the left? Are you sure the presence of the car won't mask the presence of the dog, or vice-versa?

It's easy to say "when in doubt, maintain heading and come to a halt". It's much harder to define "doubt" in a way that's useful to a computer.

The problem with simulator testing is that you can't test scenarios that you didn't think of. This is particularly important to find problems arising from multiple simultaneous situations. For example, you might test the scenarios "front camera obscured by rain", "car ahead of you performs emergency stop", and "dog runs into street", but that doesn't necessarily tell you how the car will respond to a combination of the three.

Real life is far more creative than any scenario designer.