Quadlets might make me finally stop using docker-compose

In my limited experience, when Podman seems more complicated than Docker, it’s because the Docker daemon runs as root and can by default do stuff Podman can’t without explicitly giving it permission to do so.

Can't argue with that. There's some truth to this.

99% of the stuff self-hosters run on regular rootful Docker can run with no issues using rootless Podman.

If this figure was even close to being remotely true, everyone would have moved to rootless containers by now.

Rootless Docker is an option, but my understanding is most people don’t bother with it. Whereas with Podman it’s the default.

These two share the same set of problems. People don't want to downgrade from a "working" docker to a rootless "safer" docker that comes with more usability headaches.

Docker is good, Podman is good. It’s like comparing distros, different tools for roughly the same job.

Not really. The two are really different underneath but on surface they may look like they are overlapping solutions to the untrained eye.

Pods are a really powerful feature though.

Last time I was giving podman a try, I didn't find anything really special about pods. Maybe it just didn't click for me or I was not the intended audience.

Podman might have a "more secure" design but you can run the docker daemon as rootless. Podman itself is not immune to vulnerabilities and will not solve all your security problems.

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 don't really understand what you're suggesting. Having a seperate compose file for your database would "work", but you'd lack any of the dependency handling.

It’s just morally rough that they basically said they don’t get anything of benefit from contributing to open source despite really owing their start to it

Have you seen how they have behaved recentl?

There is some surprising behavior with some of the features of yaml, mostly arising from the fact that it looks nice to read. Here's a list of things that you can avoid to avoid a lot of the pitfalls: https://hitchdev.com/strictyaml/why/ . I haven't actually used strictyaml, but the arguments it presents are pretty solid and some are things I've run into in real environments

JSON was never meant for configuration.

YAML has a ton of footguns.

YAML is way too bloated of a standard and has a ton of inconsistencies between implementations, despite the widespread reputation of simplicity. It is easy to read as long as you limit yourself to a fraction of its capabilities and err on the side of caution when it comes to escaping characters (especially when number literals are involved, or booleans for that matter). As far as alternatives go, I prefer TOML for simple key=value configs, but it has its own issued and is nowhere near as featureful, for better or worse.

If you're just reading configs then yeah, it's superior. If you're maintaining big complex configurations, possibly for multiple machines, you need something to reduce boilerplate. Jsonnet, nickel or nix are excellent here. So the best way is to use one of those, generate yaml, and deploy. Saves you a lot of headaches but it's one more moving thing in your pipeline which can break.

...except I can run Docker anywhere. It's not tied to systemd. These quadlets seem like a very systemd-specific thing. Which is great if you're building everything around systemd but it's a niche.