I have heard “pronies” said, although with a joking tone to it. non-bino will not happen as we already have enby unfortunately.

The video uses quadlets, which afaik, is just using systemd units to run containers via podman. Therefore, you can just run

podman stop jellyfin (podman ps to get the actual name of the jellyfin container)

podman rm jellyfin

podman pull docker.io/jellyfin/jellyfin:latest

systemctl restart jellyfin.container (or whatever you called your unit when you set it up)

Quick google says you can setup auto updates if you want: https://major.io/p/podman-quadlet-automatic-updates/

Caveat: I am a docker compose user, I may have missed something due to lack of familiarity with quadlets/podman

That 87€ would likely be the standard price without any additional coverage though.

Still does seem a bit pricey if its just one shot but also seems like a number OOOP just made up on a guesstimate.

GitHub lets you use them as an oauth provider. Issue solved.

Instance fragmentation is annoying in the sense while you can unify log in with oauth you can’t share settings between instances of the same software. Would be cool if oauth could have a generic user_data field to store json of settings maybe…

err . i don't really. well I do a bit. the obvious one is config-as-documentation: docker compose mainly. I'm in the middle from migrating from storing them in portainer's internal store to using git (and dockhand), which should improve their role as documentation with the addition of vcs.

in addition I have a handful of markdown notes in my obsidian vault to track a few things. there's some general terminal stuff command references, which aren't strictly for the server. i have a list off all my hard drives, including their SN,PN,Partition UUID and label (this is their partition/volume label as well an actual physical label on them. It makes moving between operations on my host machine, omv VM and physical drive easy. its a maddening combination of using three or more command ouputs to map a drive between whatever info is available in proxmox, a vm or physically otherwise!

If that is indeed true it would only mean that the docker container is vulnerable to a supply chain attack. You are not any more vulnerable to a vulnerability in the codebase.

If you’re using the ghcr image, to post malicious code there, the attack would have already had to compromise their github infra … which would likely result in the attacker being able to push malicious code to git or publish malicious releases. Their linux distro packages are self published via a ppa/install script, which I would assume just pull from their github releases, so a bad github release would immediately be pulled as an update by users just as fast as a container.