Come on, jerks, the efficient solution has been known since 1980.

But when you say "goes 10x further per [unit fuel]" you're talking about it the other way! I.e. this one gets 110 km/L, 10 times more km per liter than your car that gets around 11 km/L.

If instead you're comparing 9 L/100km to 0.9 L/100km, that's not talking about how much distance you get per liter, but about how many liters you use per distance, i.e. the rate of fuel consumption. Of course, they're equivalent ratios; it's just a reciprocal.

There's a category of neighborhood electric vehicles that are basically glorified golf carts. They can go about 30 mph, in some states can legally go on roads up to posted speed limits of 45 mph, and don't weigh much.

Which of the two widely used metric standards do you want? ;-)

If you're from one of the countries that uses the km/L measure (Netherlands, Denmark, Japan, Korea, etc.), then this Volkswagen prototype gets about 110 km/L.

If you're from one of the countries that uses the L/100km measure (Germany, Italy, Australia, etc.), then this prototype uses about 0.90 L/100km.

Perhaps they aren't wrecking the world's economy, but the Chinese Environmental Ministry is doing its best to damage the worldwide environment. Most noticeably in their region, where smog blankets Chinese cities and sometimes other countries' cities, too.

If your local DMV has an online appointment system, it's way better than it used to be with the old show-up-and-wait system. Was in and out within 15 minutes last time.

Nothing is stopping you from choosing to pay for your own healthcare in cash, out of pocket, ye olde free-market way.

Welcome to Enterprise IT.

Digging around, they do also seem to be working on a transport-level protocol with some of the main features of SPDY (fast multiplexed encrypted streams), called QUIC: http://en.wikipedia.org/wiki/QUIC

That feels like a better solution than shoving it into HTTP. But I guess if they want quick adoption, it's a lot easier to upgrade the application layer than the transport layer. Especially if you're Google and control both ends of the application (several widely used servers and a widely used browser), but not the networking equipment in between. So I can see why, pragmatically, they would be pushing HTTP/2.0.

It reads almost like they reimplemented all of TCP inside of HTTP, complete with stream set-up and teardown, queuing, congestion control, etc. Why not just use... TCP to manage multiple streams?

Not particularly bloated or slow to parse, especially on modern hardware. HTTP/2.0, which is basically a minorly tweaked version of Google SPDY, doesn't even claim speedups more than about 10%.

This map doesn't have any force of law, though, unlike the sex offender registry. You are not required to register yourself on the map each time you move, for example.

I agree structurelessness is problematic, but there are structures that work which are less hierarchical than traditional boss-and-subordinates tree-styled management structures. A common feature of Scandinavian workplaces, for example, is a set of committees with precisely specified areas of competence. It is relatively non-hierarchical but very structured and transparent: rather than informal cliques taking on different roles, formal committees with procedures take them on. Overall it works pretty well.

Yelling numbers in a public square is not exactly forging an ID.

The article notes that they have 4 million users just in Japan, oddly enough. That's about 3% of Japan's population.