Most Internet communications are carried in packets with unique source address and unique destination address. Conceptually, it doesn't matter whether those packets are encoded with Point-to-Point Protocol on a serial cable, or whether they go through a bunch of routers first. A more pedantic term is unicast. So, the actual counterexample would be multicast, and despite best efforts, there's very little of that on the Internet.

The real exception to point-to-point communications is WAN acceleration, but I'm guessing that its effects are minor across the Internet.

Recompiling Linux and packages. That has worked out so well for ARM servers, so far.

I think that's a terrible idea. I don't think the 20-bit real mode, etc., are actually used except for the BIOS, which is in the process of being replaced by UEFI, and I'm not sure all of those instructions actually still work.

But the big thing about Intel is the idea that you can just take whatever x86 software and run it. Maybe recompile if you have something that can take advantage of the SIMD instructions, but it doesn't need to be recompiled to run great. The commentaries I've been reading say that the x86 instruction decoder is basically free, anyway, so it's a competitive advantage without significant penalty.

Yes, Slashdot is rather sad these days.

But the NSA isn't just about withholding classified information. The NSA is about weakening encryption standards. Vint Cerf said he would have used encryption if he had the opportunity to do it over again. The Internet community had such an opportunity, IPv6 with IPsec, and the NSA bungled it up.

IPsec doesn't involve the routers, because that would kill performance. IPsec is designed to handle different algorithms, so you don't need to support the same broken algorithms indefinitely. But the IPsec spec is a horrible design that in practice has made it very little used outside of very professional environments with very full-time engineers to keep it running.

I don't think there is any instance where cryptography would not be useful, as long as privacy is an option. Most Internet communications are point-to-point, so caching should not be done in between. From an opsec point of view, it's less risky to use encryption for confidential information if you also use encryption for everything else, too.

Even for publicly cached data, you could use cryptography for authenticity instead of confidentiality. For example, DNSSEC is about proving the authenticity of DNS information, so your name resolver doesn't get fooled by DNS hijacking. Authenticity turns out to be useful even for completely mundane stuff.

As always, it's a matter of tradeoffs.

I run a small lab of computers, and I decided to try upgrading them to 128GB SSDs. The fast computers with Windows 8 became even faster. The slow computers with Windows Vista did not improve dramatically.

Especially the small desktop with the 1.6GHz Core Duo. A lot of time is spent on hard disk access, but get slow enough and a huge amount of time is actually waiting on the CPU. Chrome opens pretty quickly, but Firefox still takes several times as long to launch. LibreOffice still takes a long time to install or open, though appreciably less time than on HDD.

It all depends on the use. No storage upgrade is going to make your Internet connection faster, or allow your computer to play 1080p video if it doesn't have the GPU decoder or CPU power for it. If you upgrade to an SSD, you'll see some improvement, but you'll get the most benefit if your other hardware is still adequate and you're mostly waiting on the HDD. To determine whether that's so, you really should be doing measurements.

ORLY

I think that is a grave mistake on Microsoft's part. It makes people think that they can still run Windows XP securely, just intercepting viruses that match the signatures, instead of patching the underlying vulnerabilities.

I also think continuing to let OEMs install Windows XP until Windows 7 was also a grave mistake. In the short term, it slowed people from fleeing to Linux, especially for the early-model netbooks. In the long term, it has delayed the end of Windows XP by years, making it more painful when people do finally upgrade.

As the evil Soviet Union rises again, they're back to their old form, rejecting stylish devices from the USA and adopting clunky copycat devices.

So you create a working configuration, and you script it.

This is not your neighborhood club's web site. This is Google. I'm sure they have the resources at hand to do configuration management on their DNS servers. So, once it's set up, you just need to renew the registrar's DS records appropriately. You need to communicate with your registrar regularly, anyway, to keep your zone from expiring. Unless you want your cloud to fall down like a Microsoft cloud.

Greater complexity is usually greater risk, but we already know that not having DNSSEC is risky. DNSSEC was invented to eliminate certain types of risks.

I didn't study technology because I wanted to be satisfied with the status quo. Right now, you cannot eat your cake and still have it, but what if you could?

I upgraded my phone because I wanted greater functionality. (Actually, I upgraded because I wanted the very cheap monthly plans on Republic Wireless.) I now have to plug my phone in every night instead of two to three times a week. The Moto X already has compromised specs to get very good battery life, and I only ran out of battery once after doing a 2-hour Google Hangout with video. I would not mind staying with this amount of power, but increasing battery life even more.

Yes, I tried it.

Actually, I tried it in extreme form. I no longer install the Flash player plugin. I'm fed up with the updater.

And what I found was that most YouTube videos don't work in HTML5. So I use Firefox for my main browsing and Google Chrome for interacting with Google web sites.

If Google ends up with a distorted view of browser use statistics, that's their fault.

What are you talking about? DNS does that, anyway.

DNSSEC records are distributed and expire just like any other record. Make a mistake deploying DNSSEC, then just fix it, and eventually the bad records will expire and the new ones will take over. The major issue I see is that the TLD registrar needs to hold DS records for your key, so now your registrar needs to do NS, DS, and glue records.

Worst case scenario, you lose the secure entry point keys. So, you use some out-of-band management interface to change the DS records in the TLD. That's slightly worse than without DNSSEC, because you could mess up your zone all you want without involving the TLD administrator. But the bad DS records expire, the new ones take over, you're back in business.

For a company the size of Google, they'll probably want the SEP keys to be held in a HSM. Maybe they'll put all their private keys in a bunch of HSMs. You can have more than 1 DS record, so they can distribute their HSMs as widely as they want. There's no good reason why Google can't do DNSSEC.