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!

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.

Yes, with some big "if"s. NextCloud can work very well for a large organization if that large organization has a “real” IT department. I use “real” to describe how IT departments used to work 20+ years ago, where someone from IT was expected to be on call 24/7, they built and configured their own software, did daily checks and maintenance, etc. Those sorts of IT departments are rare these days. But if they have the right personnel, it can definitely be done. NextCloud can be set up with hot failovers and fancy stuff like that if you know what you’re doing.

This seems to be the answer

That’s less fun. I believe you’ve either got to put everything on one SLAAC network (no static IPs), or you’ve got to use DHCPv6 (with a smaller network size) instead of SLAAC.

(Whoops, accidentally hit “Delete” instead of “Edit” and Lemmy doesn’t ask for confirmation!! Boo!! I’ll try to retype my comment as best I can remember)

I’ll buck the trend here and say “Yes, for a home LAN, it’s absolutely worth it. In fact for a home LAN it is more important than in a data centre. It is absolutely the bees’ knees for home and is worth doing.”

All of that depends on how your ISP does things. When I did it, I got a /56, which is sensible and I think fairly common. If your ISP gives you anything smaller than a /64, (a) your ISP is run by doofuses, but (b) it’s going to be a pain and might not be worth it. (I now live in literally one of the worst countries in the world for IPv6 adoption, so I can’t do it any more)

The big benefit to it is that you can have your servers (if you want them to be) publicly reachable with one unique address, the way the Internet was originally designed to work. This means you can use exactly the same address to reach them outside the network as you would inside the network. Just make one AAAA for them and you can get to it from anywhere in the world (except my country).

When I did it, I actually just set up 2 /64s, so a /63 would have been sufficient (but a /56 is nice). Maybe you can think of more creative ways of setting up your networks. Network configuration is a lot of fun (I think).

I had 1 /64 for statically-assigned publicly-reachable servers. Then I had a separate /64 for SLAAC (dynamic) end-user devices, which were not publicly reachable (firewalled to act essentially like a NAT). (Sidenote: if you do go to IPv6 for your home network, look into RFC7217 for privacy reasons. I think it’s probably turned on by default for Windows, Android, iOS, etc., these days, but it’s worth double-checking)

I’ll buck the trend and say “yes, for a home LAN, it is the bees’ knees”. I don’t do it now because my country (and hence my ISP) does not do IPv6, but for most places it’s worth doing.

It depends on how your ISP does it. When I did it before, my ISP gave me a /56, which is pretty sensible and I think fairly common. If you get smaller than a /64, (a) your ISP is run by doofuses, but (b) it’s going to be a pain and maybe not worth it.

A /56 was much bigger than I needed. I actually only used 2 /64s, so a /63 would have been fine, but network configuration is fun (I think), so maybe you can get creative and think about different ways of allocating your network.

I had 1 /64 for statically-assigned, publicly reachable servers. And then I had a separate /64 for SLAAC (dynamic) allocated personal devices (laptops, phones, etc.) which were not publicly-reachable (firewalled essentially to act like a NAT). (Sidenote, if you are going to use IPv6, I recommend turning on RFC7217 on your devices for privacy reasons. I think these days it’s probably turned on by default for Windows, Android, iOS, etc., but it’s worth double-checking)

The big benefit to using IPv6 is that all of your home machines can be (if you want them to be) reachable inside your network or outside your network using exactly the same IP address, which means you can just give them a fixed AAAA and access them from anywhere in the world you like. If you’re into that sort of thing, of course. It’s a lot of fun.