Systemd is just the default on Debian, and is trivial to replace by whatever you like. I do agree that Debian would be a better distribution if systemd weren't the default, but nevertheless, all you need to do is apt-get install sysvinit-core.

That's probably just because you didn't boot in UEFI mode.

While that may be true, most systems don't use SELinux, and for fairly good reason if you ask me. I've tried a couple of permutations on the idea, and having several parallel security systems has never really come out as a good thing in the end. Especially one as complex as SELinux.

To be fair, reading TFA it doesn't seem to be a general EFI bug at all, but merely a bug with some implementations of it. TFA mentions "some MSI notebooks", but isn't more specific than that. So yes, this seems like a particular hardware bug, rather than a bug with either UEFI, the Linux kernel, systemd, or any other software bug in general.

I don't want to be that guy, but this is why you
1. Don't type fast when your command starts with rm -rf;
2. Never rm -rf by absolute path at all;
3. Never start typing rm -rf at all, but type the rest of the command first and then edit in the rm; and
4. Don't use root shells, but sudo, and edit in the sudo last on potentially destructive commands.

There may be good reason to break one or more of these rules at one time, but never all four.

Not that UEFI isn't catastrophically broken, but reading TFA, in this case the real problem seems to be the way it is implemented on some motherboards (TFA mentions "some MSI notebooks" without specifying further). Even if EFI vars are broken, that really shouldn't brick your motherboard unless the motherboard itself is buggy. Makes me wonder if the owners have tried resetting their NVRAM, or if that too is perhaps impossible on these motherboards.

While not running systemd is always a good idea, it wouldn't change anything with regards to this, as the EFI variables are in /sys/firmware/efi/vars regardless of what init system you use.

so for now there is no good solution to avoid potentially bricking your system

Have you tried not running rm -rf /?

Do note how you can also read it as libReSSL, though.

Yes, of course liquid cooling not magically going to make the heat disappear or otherwise violate the laws of thermodynamics. But it can transfer it to a place where you can have larger metal fins and/or better fans.

Sure, admittedly so, of course. The point, though, is clearly to be able to use a larger or otherwise better air cooler in the end, which I can certainly see being the point in this case, seeing is how the PCI specification gives too little room for a proper cooler on the card itself, especially if it's going to fit in only two slots.

The point with liquid cooling isn't to replace the metal in contact with the chip, you know. It's to replace the air that is normally cooling the metal.

Right.

It's mostly a matter of incompetence in the implementation, indeed. The Java vulnerabilities I have followed have always included calling some obscure part of the Java class library which is implemented using native code (mostly for optimization reasons) that happened to be buggy in some way.

It should be said in this case, however, that the new Java 7 dynamic language support infrastructure, which is one of the things Oracle added since they took Java over. Many of the things Oracle has done to Java lately (and especially as additions in Java 7) have struck me as poorly designed features that just allowed Oracle to check of some feature-lists to make Java appear as "feature-complete" as dotnet.

You don't normally use LVM for RAID1 (you can, but it kind of sucks and is a bit immature). Normally, you'd use mdraid for that, and then construct a LVM PV from the resulting mdraid device(s).

Neither ext3, LVM nor mdraid checks for silent corruption, however. That's strictly a feature of filesystems like ZFS or btrfs that explicitly checksum all data.