I used to run a TFTP server on my router that held the decryption keys. As soon as a machine got far enough in the boot sequence to get network access, it would pull the decryption keys from the router. That way a thief would have to steal the router along with the computer, and have the router running when booting up the computer. It works wirelessly, too!

To the best of my knowledge, this “drives from the same batch fail at around the same time” folk wisdom has never been demonstrated in statistical studies. But, I mean, mixing drive models is certainly not going to do any harm.

The scary thing? Define “new”. This judgment is from a lawsuit in 2014. So any car made in at least the last 9 years is doing this. Maybe newer cars are doing even worse things.

It’s a bit more complicated than that. System load is a count of how many processes are in an R state (either "R"unning or "R"eady). If a process does disk I/O or accesses the network, that is not counted towards load, because as soon as it makes a system call, it’s now in an S (or D) state instead of an R state.

But disk I/O does affect it, which makes it a bit tricky. You mentioned swapping. Swapping’s partner in crime, memory-mapped files, also contribute. In both of those cases, a process tries to access memory (without making a system call) that the kernel needs to do work to resolve, so the process stays in an R state.

I can’t think of a common situation where network activity could contribute to load, though. If your swap device is mounted over NFS maybe?

Anyway, generally load is measuring CPU usage, but if you have high disk usage elsewhere (which is not counted directly) and are under high memory pressure, that can contribute to load. If you’re seeing a high load with low CPU utilization, that’s almost always due to high memory pressure, which can cause both swapping and filesystem cache drops.

What kind of rube works in the same country they live in? I met a lot of WFH workers when I visited Thailand, and not a single one of them was working for a company in Thailand.

BitWarden+PiHole+NextCloud+Wireguard combined will add to like maybe 100MB of RAM or so.

Where it gets tricky, especially with something like NextCloud, is the performance you see from NextCloud will depend tremendously on what kind of hard drives you have and how much of it can be cached by the OS. If you have 4GB of RAM, then like 3.5GB-ish of that can be used as cache for NextCloud (and whatever else you have that uses considerable storage). If you have tiny NextCloud storage (like 3.5GB or less), then your OS can keep the entire storage in cache, and you’ll see lightning-fast performance. If you have larger storage (and are actually accessing a lot of different files), then NextCloud will actually have to touch disk, and if you’re using a mechanical (spinning rust) hard drive, you will definitely see the 1-second lag here and there for when that happens.

And then if you have something like Immich on top of that…

And then if you have transmission on top of that…

Anything that is using considerable filesystem space will be fighting over your OS’s filesystem cache. So it’s impossible to say how much RAM would be enough. 512MB could be more than enough. 1TB could be not enough. It depends on how you’re using it and how tolerant you are of cache misses.

Mostly you won’t have to think about CPU. Most things (like NextCloud) would be using like <0.1% CPU. But there are some exceptions.

Notably, Wireguard (or anything that requires encryption, like an HTTPS server) will have CPU usage that depends on your throughput. Wireguard, in particular, has historically been a heavy CPU user once you get up to like 1Gbit/s. I don’t have any recent benchmarks, but if you’re expecting to use Wireguard beyond 1Gbit/s, you may need to look at your CPU.