> I feel like Docker and other containerization tools are becoming even less relevant given that systemd can twiddle the same isolation bits so there's no real difference in terms of security that using a container tool grants.
I see it as _exactly_ the opposite. Podman gives me more or less the same security controls as systemd and the package/delivery problem is solved.
Call me when `systemctl pull ...` fetches the binary and everything else needed to run it _and_ puts the .service file in the right spot.
nixos kind of does that except better. Usually just set services.foo.enabled to true along with any other config you want. It's also super easy to wrap services in a container if you want, and doing so is kept conceptually separate from dependency management. If you want to make your own systemd service, then referencing a package in `ExecStart` or whatever will make it automatically get pulled in as a dependency.
Solved dependency management would involve reproducing your artifacts in the future - isolation is a completely orthogonal thing and container tech just sidesteps this issue.
I can already hear the systemd-haters complaining about The One True Unix Way™ is to have tools that only do one thing even if that leaves holes in their functionality.
Isn't this literally what podman-systemd does? You don't exactly run a command to pull a container, but just like systemd you place a config file in the right directory, tell podman-systemd to reconfigure itself, and run the service the standard systemd way.
1) the usual `curl` or `wget` to fetch the binary and the lib(s) and all the work of validating and putting them in place and the like and _then_ you can use a systemd/.service file to set up controls for the bin
2) podman pull and then either ask podman to make a .service file for you or write your own
because only one of the two approaches has solved the package/distribution issue, containers are _not_ "less relevant given that systemd can twiddle the same isolation bits"
What "validating" does docker/podman pull do that is in excess of a curl of a file?
One of the advantages of a real package manager is that it checks signatures on the content that is downloaded. The supply chain on a linux distro's package repos is much harder to break into than typosquatting into a docker registry somewhere.
> What "validating" does docker/podman pull do that is in excess of a curl of a file?
Every single thing has a sha hash so verifying that I actually downloaded what I meant to download is easy. This gets tedious if I have to `curl https://github.com/someUser/someProject/release/latest.tar.g...` and also get the `tar.gz.sha256` file (if they even publish one ...).
Curl supports resuming a partial file (assuming the sending server also does) but it can't "know" ahead of time that the first 1/3 of the file I am downloading has already been fetched because it's also used by $someOtherArtifact.
> One of the advantages of a real package manager is that it checks signatures on the content that is downloaded.
So does docker/podman.
> The supply chain on a linux distro's package repos is much harder to break into than typosquatting into a docker registry somewhere.
Perhaps. For every "secure" package repo, I'll show you a much more up-to-date package in AUR/Nix.
IMO, docker layering over the OS's built-in package management and update lifecycle in an incompatible ways is far worse than systemd replacing the init system and other service management functionality.
Back in the old days (late 90's, early 2k's) as a sysadmin I'd often write scripts to chroot or in other ways isolate services rather than run them as root, so extending the init system to handle those features feels like it's a logical extension, not a incompatible replacement.
systemd-sysupdate already exists. systemd won't run the software repository of course, but with systemd-sysupdate together with some overlay mounts you can get Steam Deck-like ease of use system updates.
For software management in R/W environments, there's the podman + systemd combo that'll let you run containers like normal systemd services.
I see it as _exactly_ the opposite. Podman gives me more or less the same security controls as systemd and the package/delivery problem is solved.
Call me when `systemctl pull ...` fetches the binary and everything else needed to run it _and_ puts the .service file in the right spot.