You can complain that you don't liken systemd's design or that it does too much (very overplayed complaint, but ok).
But that's an orthogonal point to the initial complaint you've made that it's somehow bad that this requires systemd to run.
That complain is moot, since you'd be running systemd anyway, with or without those containers. And it's double moot, because you can run > 1 containers (with podman) without root too.
(It's also wrong that systemd was added container compose capabilities - podman is what translates things to systemd "speak")
It's not at all orthogonal. Making the "default" way to run > 1 containers together require the init process is fucking stupid.
Similar to how requiring ROOT to run containers was a stupid design decision made by docker.
This decision to make quadlets the "default podman orchestrator" and to double down on it relegates podman from being "a better docker" to just "docker just with different design mistakes".
>That complain is moot, since you'd be running systemd anyway
false. systemd is not the only pid 1 in existence (much as it likes to pretend it is). when you run a container inside a container there also isn't a systemd.
>And it's double moot, because you can run > 1 containers (with podman) without root too.
except there is NO good orchestration system for doing that. podman compose is a steaming pile of shit. quadlets requires systemd which requires root. docker compose requires a root service. you can run podman compose inside a container but not quadlets.
might as well just use docker at this rate.
>That complain is moot
Your comment comprehensively missed my point 3 times. It's triple moot. It would have been better left unmade.
I'd stop complaining about quadlets being a hunk of crap if podman compose were decently maintained.
and that particular init process did way more than any init process ever should even before somebody had the bright idea to add "docker compose substitite" to its ever growing list of responsibilities.
you could put a word processor and games in their too if you really wanted. is that a good idea? ill leave that for the reader's judgment.
From the podman docs:
> Podman supports building and starting containers (and creating volumes) via systemd by using a systemd generator.
Putting aside all the other issues one may have with systemd, this feels like a decent feature for a service manager to have (custom generation of service specifications).
> bright idea to add “Docker compose substitute”
Why is this so revolutionary? Docker-compose is just a service manager for containers. Systemd is a service manager. Systemd allowing podman to give it “container” features seems pretty reasonable.
systemd itself isn’t acting as a docker-compose substitute. Podman simply translates unit files containing docker-esque configuration (image name, volumes, etc.) into plain systemd unit files that contain (among other things) an ExecStart line that starts the container with the proper arguments.
It was a shitty decision that renders it just "a less popular docker" and not "a better docker".
Podman has a better architecture than Docker in that it can easily run on a non-privileged user.
Quadlet (aka podman-systemd.unit) is a podman-systemd integration which can make it easy to launch and orchestrate podman containers via systemd. You can get all if the systemd dependency handling, require other units to run after a container finishes, and all sorts of other useful things. Systemd "user" units (systemctl --user) also works here with the containers running as a non-privileged user in a non-root systemd context.
Just to be clear, Quadlet is just an integration and you can still run podman without it. You can still run podman on non-systemd systems as well.
Just to be clear we're talking about QUADLETS, red hat's recommended way to orchestrate containers.
>Just to be clear, Quadlet is just an integration and you can still run podman without it.
Just to be clear, nobody was unclear about that.
It is, just to be clear, red hat's recommended way to orchestrate podman containers despite having this nasty dependency analogous to the one docker has on a root service.
Hope that helps.
Oh, you were quite unclear. Also wrong in saying you need systemd with podman to orchestrate multiple containers without root.
>It is, just to be clear, red hat's recommended way to orchestrate podman containers despite having this nasty dependency analogous to the one docker has on a root service.
It's not "red hat's recommended way to orchestrate podman containers" in general. It's "red hat's recommended way to orchestrate containers on top of systemd", that its whole point.
Nothing nasty about it either, you'd already be running systemd on your redhat system (and many non red-hat ones).
I explicitly said thay it wasnt needed and that there werent other ways just that it was the recommended way.
>It's not "red hat's recommended way to orchestrate podman containers
It is.
systemd runs on a linux host, the rootless container runs on a linux host, controlled by `systemctl --user ...`.
systemd itself requires root.