If you make something with Podman yourself it is actually less work most of the time (the OP tutorial is incredibly convoluted for no reason).
Doubt.
OP’s guide is simply describing how podman is designed to work. With systemd unit files for managing services.
But sure, if someone else did all the work for you and you just need to download the docker-compose file and run it, that is of course less work for you. But that is just a result of Docker’s relative popularity compared to Podman.
Why re-invent the wheel?
I think he’s referring to the fact that it’s mixed in with a bunch of CoreOS setup stuff. I also thought the same of this tutorial. I use podman myself but I have no interest in CoreOS. It was a bit difficult trying to extract just the podman related stuff out of that tutorial.
Doubt.
Cool attitude. In my experience, most docker/docker-compose setups will work transparently with podman/podman-compose. If you want to tighten security, lock down ressource access, run rootless (daemon and inside the container), integrate with SELinux, then you might need to put in extra-work, just like you would if you used docker.
Why re-invent the wheel?
They aren’t. Podman is mostly just a docker-compatible CLI wrapper around an existing OCI runtime (runc by default). It also lets you manage pods and export k8s yaml, which is arguably the more important industry standard at this point. Podman was also completely usable in rootless mode way before Docker support for that was on the table, which was the main reason I switched years ago. Podman development effort also yielded buildah, which is a godsend if you want to build container images in a containerized environment, without granting docker socket access (which is a security nightmare) or using some docker in docker scenario (which is just a nightmare in general).
Cool attitude. In my experience, most docker/docker-compose setups will work transparently with podman/podman-compose. If you want to tighten security, lock down ressource access, run rootless (daemon and inside the container), integrate with SELinux, then you might need to put in extra-work, just like you would if you used docker.
The whole point of docker/compose is you don’t have to do all those things to get started.
Why re-invent the wheel? They aren’t.
This whole conversation is about re-inventing the wheel called docker-compose with quadlet. Or whatever podman will come up with next as a “drop-in” replacement.
Quadlets were never meant as a drop-in replacement. The docker-compose tool works just fine on top of podman though. I personally use it to setup Jellyfin and Nextcloud.
Yes, but only 10% or so of the article is about what you actually need to know to use Quadlet and the rest is some convoluted mess that I don’t know why the author bothered with sharing that.
Major typically writes these as much for his own notes / thoughts as anything. Having some insight into how he got where he is in the process can help some others learn. I’ve learned tons from the guy.
I’ve known him over 15 years, and he always has written posts for himself first. This isn’t a bad way, just maybe not the simplest for experienced folks. Laying out your own thoughts along the path can help later when you wonder why you did X instead of Y.
