About five years ago, I was involved in the installation of a thousand-node cluster in Boulder. We knew *before we went in* that we needed to change our EDAC (memory error correction) code to account for the higher rate of bit-flips due to the altitude. Some of the people we were working with had been there when those same problems nearly caused a months-long delay in a larger installation at NCAR nearby. We ended up running into a more subtle problem involving lower air density, heat and voltage, but *this* problem was incredibly old news even then.

What is concerning are the twice refuted efforts for RDRAND to bypass the Linux kernel pool mixing entirely, and the design decisions which intentionally make RDRAND an inscrutable black box and trivial for a VMM to intercept and modify. These are not accidents.

While there is no harm in using RDRAND to complement entropy on a system, by no measure should it be used as the sole source of entropy in a system.

Immediately you say? Android users might disagree.

QUIC has congestion control. (I suppose your brain would explode if you saw uTP, which runs over UDP yet is even less aggressive than TCP.)

I think Google intends to put it in the kernel once they have finished actually designing and standardizing it. Since it would take 10-15 years to get QUIC into the Windows kernel, they're putting it in Chrome as a stopgap.

QUIC uses an equivalent of SYN cookies to prevent some kinds of DoS. It also uses packet reception proofs to prevent some ACK spoofing attacks that TCP is vulnerable to. Overall it looks even better than TCP.

As for encryption, Google gives two reasons. They intend to run HTTP over QUIC and Google services are encrypted by default; it's more efficient for QUIC itself to implement encryption than to layer HTTP over TLS over QUIC. The other reason is that middleboxes do so much packet mangling that encryption is the only way to avoid/detect it.

He's including free speech in civil rights. He supports free speech for everyone except fanboys and trolls.

You mean a workstation uses "not consumer" RAM? Tell me more...

The rover loses 30% of its value as soon as you drive it off the lot. And if NASA tries to trade it in I bet a lot of "damage" will be discovered to drive down the price.

I used to have an N900 running Maemo with "true multitasking". A poorly-written app in the background (like Firefox with the "full Web experience" of Flash) would run down the battery in two hours. But at least I could use top to find the problem and kill -9 it.

Now I use Android where apps are specifically written to be aware of my battery.

That was kinda my point; people with a 15 GB cap will not sign up for Netflix at all. They won't sign up for Netflix, blow their cap, and pay $100/month in overages. So Netflix does not cause ISPs to earn more money.

A lot of BitTorrent traffic shifted to cyberlockers like MegaUpload a few years ago; I don't know if it has come back since then.

But since most ISPs are either unlimited or have such punitive overage charges that customers will never pay them, greater demand for bandwidth generally does not translate into more revenue for ISPs. Even the lowest tier 5 Mbps plan is sufficient to watch Netflix.

If by similar you mean 1/18th the performance.