Start at != fully loaded.
run a business without paying the traditional costs in the field and socialize your costs. in this case he wants every internet customer to pay for his bandwidth whether they use netflix or not.
ISPs chose their flat-rate business model; Netflix didn't force it on them. If that business model no longer works, ISPs should switch to a different one.
Nah, Netflix used to use other CDNs. But then they got big enough that it was cheaper to build their own.
That's orthogonal to the issue that (in most people's opinion) no CDN should have to pay broadband ISPs.
I agree with the first part of your comment, and came here to say almost the same thing. The law of unintended consequences strikes again.
The second part makes you seem like a moron. Seriously, losing access to your e-toy for a minute or two is worth killing over? Get a grip.
There are two different ways to do network display: the RDP way and the right way. With RDP you're sending the entire "screen" over the network, so all the windows have to be composited first. Thus RDP requires a fully featured compositor like Weston on the remote end.
The right way is to send each window over the network, which should require a lightweight compression proxy. No one appears to be working on this.
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...