I like this trick, and am glad that you're publicising it. It was a pretty clever addition to many compilers; the compilers that don't understand it won't reject the code, the compilers that do will know it's intentional. And maintenance programmers reading the code will know it's intentional, too.

You have to do this no matter what privilege escalation method you use, because a rogue administrator might have left a random setuid binary around somewhere. Or has put a logic bomb in the script. Or something like that. Having only one door to guard is no use when the inside of the building carries a bunch of materials for building extra doors.

In the UK, it's impossible for the upper house to block a bill for more than two sessions; for bills purely about funding/taxation, it's one month. This seems to be a better solution to the solution used by the US, but I prefer Australia's solution even more.

Not every site does. For instance, I vaguely remembered that Microsoft EULAs have jurisdiction based on the country where you live, with the "you consent to jurisdiction in Washington" bit only applying to Americans. I checked the Terms of Service for Bing, and I was right. (For instance, for Europeans, it uses Luxembourg law for breaches of the ToS specifically, and the local jurisdiction for other claims.) Microsoft seems to have local companies set up for the purpose of sorting out contracts with people in countries other than the US. Many other sites don't seem to consider jurisdictional issues in their TOS at all. I suspect that that might lead to complications if they ever have to sue someone, but it's nicer for their users. Incidentally, local jurisdiction clauses in a ToS are actually one reason that causes me to avoid agreeing to them, unless they're set up in such a way that they only apply if I invoke them, they can't be invoked against me. (I end up avoiding a large number of major websites because of this.)

Alt-e opens a menu whose name starts with E. AltGr-e is (on Windows, at least) a standard way to type é. So you can't really conflate the two.

I use Caps Lock as my compose key, and fix two problems at once (not having a compose key, and hitting Caps Lock by mistake; hitting Compose by mistake is pretty minor, really).

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.)