The idea is to use TPM to store the keys - if you boot into a modified OS, TPM won't give you the same key so automatic unlock will fail. And protection against somebody just booting the original system and copying data off it is provided by the system login screen.
Voilà, automatic drive decryption with fingerprint unlock to log into the OS. That's what Windows does anyway.
Or is there any functional difference between the two methods?
Can't test right now, but I have a strong suspicion you will have trouble getting IP broadcast to work. Normally broadcast address is calculated by setting all bits after the network prefix to 1, but your computer believes to be in a /32 "network". It won't broadcast over routes that are not part of its network.
And even if you calculate the broadcast address successfully (maybe the software you use has /24 hardcoded for whatever reason), no computer configured with a /32 address will receive it - 192.168.0.255 is not within the 192.168.0.1/32 network, so it will probably get forwarded according to your routes if you have forwarding enabled (except it shouldn't in this case with one network interface, because you never send packets back the way they came from)
Well, Nvidia doesn't support OpenCL 2, so if you want your software to support the most commonly used cards, you're going to be limited to OpenCL 1.2, which is pretty crap compared to the shiny CUDA. There's also a lot of great tooling made or heavily sponsored by Nvidia that's only available for CUDA.
And yes, Nvidia now supports OpenCL 3, but that's pretty much just OpenCL 1.2 with all OpenCL 2 features marked as optional (and Nvidia doesn't support them, obviously).
Letting you disable or limit internet access to apps would go pretty strongly against Google's interests - how would they get their ad money if half the users were running most apps offline?
Some vendors provide a way to do this (Xiaomi has an internet access toggle per app, or at least it did in the KitKat era), but it's never making its way into stock Android until Google integrates AdMob into the system.
Those distros "force" you to reboot when you want to update (as opposed to allowing you to do the update on the running system). Think Windows 7 and earlier, that kind of forced reboots, back when people were fine with the way Windows did updates.
You still need some privileged process to exploit. Glibc code doesn't get any higher privileges than the rest of the process. From kernel's point of view, it's just a part of the program like any other code.
So if triggering the bug in your own process was enough for privilege escalation, it would also be a critical security vulnerability in the kernel - it can't allow you to execute a magic sequence of instructions in your process and become a root, that completely destroys any semblance of process / user isolation.
Cool, so it's like two years ago
Oh...
Oh no
It is, and it's the reason Pixel 6 and 7 series had so many issues with poor battery life and weak modem. Although it appears that the third generation Tensor CPUs in Pixel 8 have major improvements on both of these pain points.
Still, that probably brings Pixel 8 only to the cheap-ish midrange standard when it comes to cell signal, as the Pixel 7 phones were atrocious and 6s were apparently even worse.
~~I think the idea at the time was that if /usr is unavailable, you won't be doing much with the system anyway (other than fixing the configuration).~~
Nevermind, apparently the original meaning had nothing to do with a network (TIL for me), so our discussion is kinda moot. See section 0.24 in this 2.9BSD (1983) installation guide
Locally written commands that aren't distributed are kept in /usr/src/local and their binaries are kept in /usr/local. This allows /usr/bin, /usr/ucb, and /bin to correspond to the distribution tape (and to the manuals that people can buy). People wishing to use /usr/local commands are made aware that they aren't in the base manual.
No comment on sensibility, but technically both are equally difficult - mount the parent filesystem, then mount the child filesystem into an empty directory in the parent. Doesn't matter which one is where, it's all abstracted away at this level anyway.
I do not get paid every time it runs for the rest of my life, so why should you?
Sorry if I misunderstood you, but this feels rather easy to answer: because you are being paid to write the code. Spotify doesn't pay anyone to write music (well maybe they technically do for some ads or something, but it's definitely not how they acquire more music to add to the library), they just pay for streaming rights on music that was somehow already independently produced. And tiny unknown musicians have no leverage to negotiate better terms than what Spotify offers.
If you boot the computer into the currently installed OS, you will be presented with a login screen and will have to enter the correct password to log in (kernel parameters are part of the checksums, so booting into single-user mode won't help you, that counts as a modified OS). If you boot a different OS, you won't get the key off the TPM.