Reasons to Drop Docker for Podman

Problems having a daemon solves:

1. You need a watchdog process anyways to handle stdout/stderr processing (to not block those pipes), namespace setup and teardown, etc. Why not have 1 daemon, rather than 1 daemon per container?

2. You need root to setup networking and various security controls (seccomp etc). Having a daemon lets an unprivileged user delegate to a privileged daemon. This was especially important in the early days when rootless containers and slipr4netns didn't exist or were immature.

3. You need to avoid contention between two "docker run" commands, such as avoiding downloading the same image twice, or running the same name twice, or so on. In-memory locks are really easy to get right and cheap

4. You need to be able to efficiently gather state for things like "docker ps" etc to work. A daemon lets you cache a lot of information very easily.

5. A daemon lets you provide a clean rest API to other components that want to "exec" or "list containers" or so on. Without a daemon, your API is just "exec this command, use stderr/stdout", which is worse, right? An API also helps immensely with "docker desktop" like stuff, where you want to run a client on the host, and run containers on a linux VM. I guess the daemonless answer there is "exec over ssh", which is slow, and also eww.

So, how does podman solve these? I'll number them the same:

1. Watchdog process per container (N daemons) plus centralized systemd daemon if you want to background a container, or for restarts to actually work.

2. slipr4netns, which is buggy and still less featureful than docker networking. It also just doesn't implement various security features that would require a privileged component to setup, and makes it harder to run root-ful containers.

3. Contention is avoided with an incredibly over-engineered filesystem locking scheme that has had a long history of deadlocks and bugs.

4. Again, the filesystem locking scheme and api. It's slow, can't cache well, and also has a long history of deadlocks

5. The API for podman is uh... "run a daemon" https://docs.podman.io/en/latest/markdown/podman-system-serv... lol. Except how does another app know if you ran the API because it's optional? This makes it so other applications that want to integrate with podman have to say "use podman and also run the podman daemon if you're not, and if you forget we won't auto-detect podman sorry".

In general, podman's answer to all the problems the daemon solves seem materially worse, and more overengineered. Except to the API bit, where their answer is to post all over the place "podman is daemonless", but then to package a daemon, which is just funny.

I wanted to try a while ago so I downloaded Podman Desktop, but I couldn't get past the initial setup due to issues in the desktop app. I was able to reproduce this on two or three Macs, can't recall exactly.

It has been a long-standing issue but seems as though it is on its way to resolution: https://github.com/containers/podman-desktop/issues/1633.

I am waiting for a few months to make sure it is all sorted and will try again to see if it works then.

I'm surprised to see RedHat thinking that programmers will prefer a desktop GUI interface to CLI for operations like starting containers. I thought that thinking had died out 20 years ago and that even Java and Windows people understood that it wasn't what programmers wanted.

My experience on Mac: - colima: Testcontainers cannot connect to the containers when the tests are ran from the command line (I have env vars DOCKER_HOST=unix:///Users/dxxvi/.colima/docker.sock and TESTCONTAINERS_DOCKER_SOCKET_OVERRIDE=/var/run/docker.sock). However, the same tests ran fine in IntelliJ. - Docker Desktop: doesn't have the above issue.

Don't know why.

> Anyone using Podman on a macOS? How's the experience compared to Docker Desktop?

Don't forget there is also Rancher Desktop[1]

[1] https://rancherdesktop.io