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.

In addition to what others have said, make sure the vents are not full of dust or obstructed.

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.

They aren’t accommodating the gambling industry. It’s a bug fix for a media player issue. The text in the changelog comes from the bug report title. The bug isn’t specific to that site, and neither is the fix.

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.

Syncthing is another good cloud-free option.

After creating it with mkpart, are you formatting it with mkfs.btrfs? You need to both steps (create partition and format it). Also, try running partprobe or rebooting after making changes so that the kernel re-detects it.

There is a filesystem type field in the partition table. Formatting the partition won’t change it. Delete the partition and recreate it with the correct filesystem type. In parted you can do that with “mkpartfs”.

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.