Right Alt is pretty useful if you aren't American; it tends to be used to type a bunch of accented or non-ASCII characters in Europe, for instance (notably, the euro currency symbol, which is standardised as right alt+4 on all the major OSes at this point).

More to the point, it's trivial to break a chroot on Linux if you have root access; it's not designed to be secure against someone with root permissions. (You create a second chroot inside the original chroot, and move your shell inside it but keep the working directory between the two chroots. Then you can just do cd .. until you reach the original root, and chroot again to reset the root to its original value.) I think this is intentional; there are plenty of other ways to break a chroot as root, but they tend to be more destructive, so having an easy way out is nice. (This is also the reason that chroots can only be created as root; otherwise, they'd be no security even against unprivileged users.)

If you did that, the backdoor would disappear over the course of time whenever someone released a production compiler that was compiled with a debugging-symbol version of the same compiler. (This is a lot more likely than it seems; the people who actually develop compilers, and thus compile them, are likely to have debugging symbols on for their compilers as a matter of course, because they frequently make changes that break them.)

/dev/random blocks if it feels that there wasn't enough entropy gathered from the environment to produce a truly random number. /dev/urandom will never block; rather, if there isn't enough entropy gathered from the environment, it will give you a cryptographically secure pseudorandom number instead. So the difference basically depends on what level of true randomness you need; in general, /dev/urandom is just fine for all applications except cryptography, and if you're doing cryptography, you shouldn't be using either directly but rather relying on a crypto library anyway (and the library probably uses /dev/random, possibly among other things).

The AC used to be correct, but gcc have been trying to clean up more recently. (Most likely, at least partly because competition from clang meant that trying to lock out third-party closed-source plugins wasn't a particularly useful thing to do anyway.)

I remember to set a quick LC_ALL=C when I'm doing anything that might have to parse the output of a shell command (typically just on that command, rather than exported). Including the space you need to separate it from the command, it's what, nine characters? (And as a bonus, it forces things like the decimal point convention to known values too.)

(By the way, "C" is a better setting than any specific language, including English; its entire purpose is to be as portable as possible across computers. I've actually also come across programs that give more 'friendly' output on, say, "en_US.UTF-8" than they do on "C"; it's the difference between knowing that your output will be read by a human, or by a computer.)

I think Duckduckgo is actually using Yandex behind the scenes now, rather than Bing (sometimes they give an attribution to that effect). Possibly even both.

INTERCAL uses the same character for opening and closing parenthesis (' or ", the programmer can choose, and occasionally has to mix them to resolve ambiguity). This is not particularly easy to read, although it is normally unambiguous; look at my signature for an example.

Most likely, both. (It would even likely cause an increase in BSD use, although BSD would still have insignificant market share even then.)

The private key is normally protected by a password, without which it won't/can't work. The password doesn't need to be sent anywhere in order to work correctly.

SSH keys are actually one of the easiest ways to get two-factor authentication ("something you have" = the encrypted private key, "something you know" = the password to decrypt it.

A bunch of Pokémon fansites were hacked recently (here's one reasonably detailed report from one of the sites). Although as far as I know no plaintext passwords were stored on any of the servers, there were a bunch of password hash databases taken; and because Pokémon is a Nintendo property, Nintendo's website would be an obvious place to try any username/password pairs that were weak enough to be reversed from the databases (and some plaintext passwords would be available as a result of compromised login forms).

Many of the hacked sites (that I know about, at least) were reasonably small, with user counts measured in thousands; as such, 24 thousand total seems to be a reasonable estimate for the number of accounts that might have been affected.

Well, I can't drive, so there'd be a passenger in the car who could make the call. (As such, I'm very used to car-sharing, because I don't know of any other sort of driving; if I'm in a car, there's always a passenger able to make the call.)

I'm thinking of situations like "needing to pick someone up in an emergency (with limited time) and trying to contact them to verify where they are". If you pull over in order to make the call, then you're going to have to break the speed limit in order to get there on time, which is dangerous in a different way. If a passenger's making the call, there's no danger involved, and so things are safer all around.

The problem with trying to do that via technical means is that I've seen several situations where a passenger needs to use a cellphone while a car is driving. It can't be very technically easy to distinguish between a driver using a phone, and a passenger using a phone.

It's basically done per household, and indirectly for all the people in the household in some special cases (e.g. portable TVs used inside cars).