If you want a "this cannot happen" with core dump in C, just use abort(). Unless its behaviour is specifically overriden, it's specified to exit the program as unsuccessful termination by the C standards (e.g. 7.22.4.1p2 of C11), and to core dump by POSIX (about as portable as you can get where core dumps are concerned; in straight C, they might not necessarily exist). It also has the benefit of being pretty short, and not undefined behaviour at all.

Of course, that doesn't work in the kernel, but then neither would the other methods you suggested.

You can do that in Windows 8 too, right-click the very bottom-left corner of the screen. (The main problem with that is that it's basically impossible to discover until someone tells you about it.)

It's worse than that. In general, there's nothing stopping anyone sending an email from any address they like; the From: address is simply written onto the email by the sender, much the same way as there's nothing preventing someone sending physical mail writing any return address they like on the envelope. Of course, this makes it kind-of easy to spam, so various methods have sprung up over the years for people to validate the From: address on an email, but there's no universal method that will work for every email you might ever receive.

In general, you should never trust the From: address on an email for any purpose whatsoever other than determining who the sender wants you to think they are.

It's best known for working in some old, buggy FORTRAN situations. Nowadays, it's legal INTERCAL too, albeit mostly to be perverse (and in some compilers, you may have to alias the constant to a variable to be able to assign to it without the compiler complaining).

In gcc, you can do -Werror=parentheses if you want to make this an error rather than a warning.

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