[mekster]

> Not that it wasn't usable previously, you'd just run into a few issues.

I don't like that definition of "usable".

Compose v2.0 compatibility became available only since last month which was very late.

If podman isn't for technical benefit, is this all about political decision for RH to govern container ecosystem on their own instead of dealing with docker?

[jordemort]

Podman has a few tricks up its sleeve that Docker can't do. Among other things:

- `--rootfs` lets you start a container from a directory instead of an image

- You can configure alternate container storage locations, e.g. to share a common library of container images among multiple machines over NFS

- As previously mentioned, it has the k8s-like notion of "pods" which are multiple containers sharing namespaces with each other

- It will play nice with systemd, both inside and outside of containers, and can generate systemd services for containers

I think the last point is really why Podman exists in the first place; IIRC, Red Hat's developers made a valiant effort to get patches into Docker to improve its cooperation with systemd, but the folks working on Docker weren't interested. If Red Hat's patches to Docker had been upstreamed, Podman might not exist.

[lolcat_cowsay]

Sounds nice and all but I really liked docker compose for setting up containers, I'll have to find out if podman has full docker compose support yet, then maybe I'll switch.

Last time I tested it, it had some downsides, but "last time" was like at the start of this year so things maybe might have improved since then.

[jordemort]

4.1 fully supports both the old 1.x Python versions of Compose and the new 2.x Go versions of it - you need to use the docker CLI if you want 2.x though.

[skrtskrt]

I can understand the aversion to Red Hat control but the desire to use Podman is obviously arising from the concern about Docker control of the ecosystem.