The TPM releases the key to the OS at boot time. Without that, there would be no way for the OS to load (assuming the root FS is encrypted).

The key is bound to PCRs in the TPM, which control under what conditions the key can be released. For example, it can be tied to secure boot, bios settings, etc.

Aside from the group suggestions, you could also use ACLs. https://wiki.archlinux.org/title/Access_Control_Lists

Arch Wiki for more general info. Official docs/man pages of whatever thing you are working with for details.

With rootless containers, even root in the container is basically useless anyway because it truly runs as a fake ID on the host.

I’ve seen this repeated a lot, but I’m not really convinced running as root inside containers is a good/safe thing to do. User namespaces can provide some protection for the host, but that does nothing for the rest of the files inside the guest. For example, consider a server software with an arbitrary file write vulnerability. If the process is running as a low privilege user, exploiting the vulnerability might not really get you anywhere. If it’s running as root, it’s basically a free pass to root privilege and arbitrary code execution within the container.

H264 does work fine in the paid version. The lack of AAC support is sometimes an issue though. For footage in AAC+H264, I usually just run it through ffmpeg to transcode the audio to PCM and keep the video as-is.

I think they already have. I held off on Wayland on my main machine for a long time due to Nvidia issues. For example, I was getting rendering issues where some windows/popups would be totally invisible until I moused over them. Those issues are now gone, and I’ve been running Wayland for the last few months with no problems at all.

The system will be secure for personal use as before.

I wouldn’t be so sure of that. CPU side channels allow data to be leaked across security contexts. For example, from a user process to sandboxed JavaScript in a browser, from kernel space to user space, or from one containerized process to another. This is a problem even on a single user system without any VMs.

Some Chromebooks are pretty hackable. I’ve got an older one that I reflashed with tianocore UEFI firmware. It makes for a pretty decent cheap and lightweight low power laptop. You can run basically any standard ARM Linux distro on it.

You could maybe do some tricks with one of the variations of locate - such as mlocate or locate. There are options for the updatedb to index specific paths and store in the specified database. If you store a separate db per drive, a bit of scripting to loop through all DBs would let you search them all.

What are you comparing it to? I’m pretty sure vnstat is using the raw.interface counters. This would include all protocol overhead. I would expect it to be higher than, for example, an application level counter.

Things like taking screenshots and setting wallpaper actually do have a standard API. That stuff is just part of xdg desktop portals and not the core Wayland protocols. If, for example, a screenshot app uses the org.freedesktop.portal.Screenshot API then it should work with any compositor (as long as the compositor follows the API standards).

If you are familiar with the concepts and are looking more for the specific details, you can probably go a long way with official docs (iptables, nftables, kernel), the arch wiki, man pages, and some hands-on.

I agree those CVE responses are not great. Those are from quite a few years ago though. Has their handling of CVEs improved since?

Boot times are not that big of a deal to me either, but some people seem to care about it a lot.

I’ve never personally had any problems with binary logs. You could always forward to a different logging daemon if that’s a concern.

I don’t see any fundamental reason why systemd would be insecure. If anything, I would expect it to be less prone to security bugs than the conglomerations of shell scripts that used to be used for init systems.

The bloated argument seems to mostly come from people who don’t understand systemd init is a separate thing from all the other systemd components. You can use just the init part and not the rest if you want. Also, systemd performs way better than the old init systems anyway. I suspect many of the those complaining online didn’t really have first hand experience with the old init systems.

If a different init suits your needs better, then sure go with it. But for the vast majority of typical desktop/server stuff, systemd is probably the best option. That’s why most distributions use it.

On the flip side, if 3D graphics performance is not a priority then Intel graphics is incredibly well supported and is probably the most consistently reliable and bug-free graphics option.

Yes, I agree - using a VPN that supports IPv6 is preferred. If they don’t want to/can’t change providers, then disabling IPv6 is the best way to prevent IPv6 leaks without negatively affecting network performance.

In this case, disabling IPv6 is actually the right move. If the VPN provider doesn’t support IPv6, then there’s no way to allow to allow IPv6 Internet traffic without causing a leak/VPN bypass. If you block IPv6 via firewall or routing it to a dead-end, it will add delays as things try IPv6, timeout, and fall back to IPv4. If you just remove the IPv6 address from the Internet interface, you have to also make sure it doesn’t get re-added by SLAAC/DHCPv6 or other interface changes (switching wifi networks, etc). As dumb as it seems, disabling IPv6 or switching to a provider that supports it are probably the best options.

In addition to the other things mentioned, check the health of your drive. This could be a symptom of corruption.

1Gb EFI, rest of the disk LUKS with a single BTRFS inside. Use BTRFS subvols to divide things up. Swap as a swap file on BTRFS (be sure to set it as no_cow).

What setting are you trying to change? Some stuff can be done via CLI tools.