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.

While ZDI reported the vulnerability to the Exim team in June 2022 and resent info on the flaw at the vendor’s request in May 2023, the developers failed to provide an update on their patch progress.

Yikes. Sitting on a critical RCE in internet exposed server software for a year. That’s a great way to destroy trust in a project.

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.

Syncthing is another good cloud-free option.

But then building it still requires whatever scripting tool you use. Including the bash-ified version would not for practice, as it wouldn’t be very human readable and would have to be kept in sync with the source script. It’s much cleaner and simpler to just require python for your build environment.

I don’t see why bash would be used at all here. If you want something that doesn’t need another interpreter, then just compile a binary.

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.