I can’t tell whether you’re kidding or not.
In Germany you absolutely get subpoenaed for the slightest copyright infringement. There a law firm called “Waldorf Frommer” that does all the dirty work for the so called rights holders.

Is this relevant when using built-in zstd compression on ZFS?

I think you need to look out for “OVMF”.

Alpine Linux is an independent, non-commercial, general purpose Linux distribution designed for power users who appreciate security, simplicity and resource efficiency.

https://www.alpinelinux.org/about/

It’s also around for 20 years already, so long before Docker was a thing. But setting it up as a desktop OS would be a bit of work, I agree.

I assume Alpine Linux is very limited in terms of power usage, at least out of the box.

I’m currently in the process to switching over to it.

Could be just streaming, but who knows.

dd-mm-yyyy is not an insane format, thank you.

KDE Connect and SyncThing

Turn your laptop around and look for a sticker with a model number. Go to your vendor’s support website, search for the model number and check their BIOS/UEFI downloads. Usually it’s a file you put on a USB stick, then you boot into BIOS/UEFI (press F12 or DEL ob boot, check manual if in doubt), select BIOS/UEFI update and select the file on the USB stick.

It’s the same for desktop components. There are very few vendors/models that get BIOS/UEFI updates via Windows Update (or fwupd under Linux).

(Edit: Fixed image)

Honestly, don’t use hobby distros unless it’s just for testing purposes. They will fail you in the end, always.
That being said, if you want to check out another hobby distro, PikaOS is pretty fucking cool: https://wiki.pika-os.com/

https://docs.docker.com/engine/containers/run/#runtime-privilege-and-linux-capabilities

The --privileged flag gives all capabilities to the container. When the operator executes docker run --privileged, Docker enables access to all devices on the host, and reconfigures AppArmor or SELinux to allow the container nearly all the same access to the host as processes running outside containers on the host.

A manual --device /dev/dri should not be necessary. I’ll make sure to test it nevertheless.

I don’t think you responded to the comment you actually wanted to, but:

--privileged implies access to all host devices, so any --device directive should be redundant.
Regarding the user permissions, the current user in the container is root which should theoretically have all access it needs, but it’s a good suggestion and I’m going to take a look at it.

I trust Valve not to exfiltrate my Steam credentials or account details (credit card number, home address). I wouldn’t trust a third party with that.

This suggests passing through dbus to the container. I will take a look at that.

A strictly confined Snap by the original software authors? For sure. The available Snap on Snapcraft.io is by Canonical though, but that’d be fine as well, if I can not get my own solution to work. I’m just a bit puzzled that apparmor on Debian apparently simply doesn’t allow for strictly confined Snaps.

https://docs.docker.com/engine/containers/run/#runtime-privilege-and-linux-capabilities

The --privileged flag gives all capabilities to the container. When the operator executes docker run --privileged, Docker enables access to all devices on the host, and reconfigures AppArmor or SELinux to allow the container nearly all the same access to the host as processes running outside containers on the host.

A manual --device /dev/dri should not be necessary. I’ll make sure to test it nevertheless.

If true that’s somewhat disturbing, but I still care about verified publishers nonetheless…

Thanks for the input, but I will probably never not want to use Steam and I’ve accepted non-free firmware blobs a long time ago. All I want is to use a simple sandbox like I use for many other applications (mostly as Docker containers).