I ditched Docker for Podman

The "podman generate systemd" command from the article is deprecated. The alternative are Podman Quadlets, which are similar to (docker-)compose.yaml, but defined in systemd unit files.

Which actually makes a lot of sense, to hand over the orchestration / composing to systemd, since it’s not client <> server API calls (like with docker) anymore but actual userland processes.

With almost no documentation, mind

I find the man page fairly comprehensive: https://docs.podman.io/en/latest/markdown/podman-systemd.uni...

It totally does! On the con side, I find systemd unit files a lot less ergonomic to work with than compose files that can easily be git-tracked and colocated.

What makes a systemd service less ergonomic? I guess it needs a deployment step to place it into the right places where systemd looks for them, but is there anything else?

Yep. It works even better on a declarative distro like NixOS because you can define and extend your systemd services (including containers) from a single config.

Taking this further (self-plug), you can automatically map your Compose config into a NixOS config that runs your Compose project on systemd!

https://github.com/aksiksi/compose2nix

Is linking to a 404 page meant to highlight the lack of docs, or is there some mistake?

Apparently the documentation was just updated. The new location is https://docs.podman.io/en/latest/markdown/podman-quadlet.7.h...

I do believe you about the "updated" part, and that's a constant hazard with linking to "latest" or "main" of anything. But I don't know why you'd then change the actual file in the URL, since the original comment was citing "podman-systemd.unit.5.html" <https://docs.podman.io/en/v5.6.1/markdown/podman-systemd.uni...> and you've chosen to cite quadlet.7

You can also look the documentation up locally: `man quadlet`

Not OP but "podman-systemd.unit.5" used to be the primary Quadlet documentation (a remnant of when it was podman-generate-systemd perhaps?) with every Quadlet file type (.container, .volume, .network, etwc) documented on one page.

The new docs split that out into separate podman-container/volume/etc.unit(5) pages, with quadlet.7 being the index page. So they're still linking to the same documentation, just the organization happened to change underneath them.

If you must see what they linked to originally, the versions docs are still the original organization (i.e. all on one page): https://docs.podman.io/en/v5.6.0/markdown/podman-systemd.uni...

Not podman user (but currently trying to install to give it a shot), this comment stream shows how even the documentation "randomly disappearing" on a project that claims in production-ready or stable state. (Or lack thereof)

On the contrary, docker documentation *is* stable, I had bookmarks from 10-years ago on the *latest* editions, that still work today. The final link may have changed, but at least, there is a redirect (or a text showing that has been moved) instead of plain 404/not-found.

This is a crucial part of the quality applications offer. There might've been 100s of podmans probably since Docker was launched more than 10 years ago, but none came close to maintain high-quality of documentation and user-interface (ie. cli commands, switches). Especially in the backward-compatible way.

The Podman reference section, which is what OP linked to, is a direct web version of the man pages. The main method of accessing it, the man pages, has not changed.

It's a different style of documentation organization: if you want to link to a specific version you should link to the specific version not latest. I won't argue it's necessarily a better way of doing things than Docker, but knowing it's the same thing as what's with the package is nice.

You can tell users that "you are holding it wrong" or fix the actual problem that exists in the first place. Good luck telling millions of people to not to bookmark certain version, instead use this or that... Maybe, add just a redirect, a simple page with the link that says "Hey, this documentation has moved to there, click here".

Just put this thread into a whatever LLM. I overall see 2 major themes here. Compatibility and stability issues, all over the place. Not just documentation, but with other tools. Compose schema v2 does not match the current/latest one, missing functionality (although this one is acceptable at certain level), etc.

Also, as soon as the docs were "posted", it became obsolete/useless/deprecated. I mean, what sort of quality are we talking about here?