It depends in the situation where it is used. If your data almost but not quite fits on your available media at 15%, and you're not pressed for time, you might still go for 15%. And if you only have 15 seconds to compress it, strictly no more, you might settle for significantly less compression than would be possible in 20 seconds.

Microsoft's chess strategy seems to be to sacrifice all its pawns and its Queen, laying waste to its Bishops Knights and Rooks and trying to win the game with just its King left. Good luck with that one.

And if the CA was not in the loop, the CIA could create such a certificate themselves, and it would be just as valid as the certificate created by the real owner to the outside observer. So how is adding the CA increasing the vulnerability again?

Please expand. Are you saying that the CA signed certificate can contain two public keys, and that browsers will encrypt the session key such that either key's corresponding private key can be used to decrypt it?

The CA doesn't get key data.

The only requirement in fact is that you be willing to work in an "apprenticeship" (code word for jobs paying significantly less than market rate salaries).

There is some sort of regulation though. Flying Singapore to LA earlier this year, WiFi was available from the gate at Singapore until the seatbelt sign came on approaching Narita, then from when the seatbelt sign went off after leaving Narita until we started to approach the coast of Alaska, and while flying over Canada. Basically the only places it was not available was takeoff and landing in Japan, and flying over US airspace.

Alaska gets 8+ earthquakes fairly frequently. The luck is more that noone lives up there than the earthquake frequency (though a 9+ would no doubt cause some major damage down the coast)

As far as I know, the hardware is no different than a standard platter drive

You don't know very far then, do you? But yes, a secure rewrite of the full device should wipe the flash to the point where some serious lab equipment is needed to recover anything from the device.

I can understand the benefit of higher resolution capture capability to microscopic applications, but displays? Do you look at your display through a microscope?

An SNR of 124dB is 89.1 times as good as approximately 105dB. When your speakers are around 80-90 dB and CD quality input around 100dB (less for most heavily compressed input and MP3s), that 105dB SNR for your internal audio is already the least important component in the chain for sound quality. I suspect though that that is for digital output. The analogue stages in onboard audio do leave a lot to be desired.

When was the last time the average person created something original?

People create random original things all the time. It's the hardware fluke bar they'd have trouble passing.

The vendor supplied tools may be Windows only, but chances are there is a gcc backend available for the target architecture these days. I wouldn't like to be using an ARM board for my cross compiling though, getting QEMU set up for any compilation steps that need to run on the target architecture is enough of a nightmare on Intel, let alone other architectures that noone has used that way before.

One decade maybe. But the primary development environment for kernel and driver work today still looks very different than in 1980.

I said vim, not vi. I'm well aware that vi goes back further, but nobody in their right mind would consider using the original vi as their primary development tool these days. And Emacs goes back to 1985, not 1972. Sure, it can trace its roots back to ed, from 1972, but it is even less like ed than vim is like vi.