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
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.
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).
Running it in a dedicated VM is usually the more expensive option, particularly with something simple like DNS.
What setting are you trying to change? Some stuff can be done via CLI tools.
Immutable/offline backups. If you backup to local physical media (HDD/tape), physically disconnect/eject it and store it somewhere safe. If you back up to cloud storage (S3, etc), many of them have immutability options. If configured properly nobody (not even you) can delete or modify the backups (within the specified time period).