FR version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
66% Positive
Analyzed from 2684 words in the discussion.
Trending Topics
#docker#podman#compose#don#files#containers#systemd#macos#rootless#run

Discussion (74 Comments)Read Original on HackerNews
[1] https://github.com/Mati365/hetzner-podman-bunjs-deploy
The new network stuff is a welcome improvement.
Especially if you want to go rootless (and you should).
For someone that isn’t “Linux first” (like a baby developer learning to containerize their apps), the idea of dealing with systemd unit files or kublet configs, and having to created dedicated local service accounts (and remembering to enable linger) is somewhat intimidating when compared to just installing docker, whipping up a docker compose file and pressing “start”.
I understand why they’ve taken this approach but it’s pretty clunky and a bit unfriendly.
Podman on macOS feels miles less refined. Orbstack is a way better choice.
I only use podman on Linux and there it is blazing fast. Even so, most features seem to be geared to be able to replace kubernetes in combination with systemd. And then something simple as docker compose support is flaky and it’s TUI/ux lags behind the original.
I'd love to be able to recommend people use podman but not having a good docker compose compatibility and missing inotify on volumes makes the DX just too problematic.
podman-compose never worked well for me but docker-compose on podman did.
I tried working through it with Claude, but after a few failed attempts I gave up. I'd like to use podman, but the docker compose + buildx compatibility gaps made it more trouble than it was worth for now. I'm definitely going to try it again.
Not even Tart or Apple Container support it, as far as I know. Maybe someone has found a way.
Works with OrbStack though.
In general this seems to be a common complaint here. If you're developing with cloud runners or on linux infra you won't run into this, but on macOS for local development it is impactful.
The other issue is minor differences from Docker, but small enough that a packaged up Docker compose doesn’t work out of the box. It’s not a good use of my time to debug that when I could just switch to Docker, have it work, and get on with my day.
And usability continues for being security’s number one enemy...
macOS had a seperate set of problems. I ended up just going with buildx and Colima on macOS. (We don’t use Docker Desktop.)
Long term I’d like to try to switch to podman again, but it needs to have a “be 100% compatible with Docker” mode as opposed to this:
https://github.com/podman-container-tools/podman/issues/1478...
Either an old experience you had, or a newer experience you had on vastly out of date packages and probably podman itself?
Docker is something we all already hate, milion edge cases and forever bugs but at least well documented and understood. Podman claim to be drop-in replacement does it mean it carry docker shitness? Examples: ufw punch through, env file handling, volumes, etc
Documentation has also gotten better.
For tools that require docker to work, like testcontainers and tilt, I've found some annoyances using podman, but ultimately I've been able to work around them.
For everything else, it's pretty much a drop in replacement.
So any time people talk about docker someone can go:
I use podman btw
Docker (the company) lost the plot in Linux containers, OCI got standardized, alternative runtimes came to be, and very few companies actually care to pay for Docker Desktop or the other services they sell.
Microsoft also is finally adding their own docker cli (wslc), due to having had enough pressure that many companies don't want to instal third party tools for Linux/Windows containers, even if API is compatible with docker daemon.
Apple is doing a similar approach on top of their virtualisation framework.
I've never interacted with anyone that knew them by another name. It's always (docker) container, where they may leave out the docker term, but if questioed what kind of container they mean theyll say it.
And the times I've called them OCI container (or image when talking about those) nobody knew what I meant until I clarified to docker
"OCI container" doesn't have same ring, unfortunately.
And most things are just clones of Docker, e.g. Containerfile. In a clone situation, the original brand will always have the staying power.
I have a lot of compose files in my homelab/automation setup and those are what I’m most concerned about.
The only issue I have is validation, there isn't a convenient built-in command to validate quadlet files and systemd doesn't warn you if any fail to generate. You either have to do a --dry-run first (and probably alias the full command to something reasonable) or check the journal for errors.
For quick conversions you can use compose files directly with podman-compose or docker compose pointed at the podman socket[0].
There's also podlet[1] which converts compose files into native quadlets. It does a pretty good job of taking care of everything for you and for a lot of simple to medium complexity compose files it will Just Work. There's talk of making it into a library of some kind so other tools can transparently convert compose files to quadlets so hopefully we'll see more stuff like it.
Otherwise, writing your own Quadlet files isn't too hard if you're at all familiar with systemd unit files. Most `docker run` or `podman run` arguments have direct quadlet conversions so once you get used to the INI format versus yaml it's pretty easy to see a compose file and churn out the equivalent quadlet(s).
[0] https://www.redhat.com/en/blog/podman-docker-compose
[1] https://github.com/containers/podlet
I have zero issues with it doing the builds I need. Works same same as Docker from what I can tell.
I took Docker completely off my Macbook which has a tiny drive in it. Hardly ever use it, except for testing. Podman is super lightweight and using a project I'm developing, launches containers with dev agents in it, just the same as Windows running Docker.
I have the feeling the docker company is communicating a lot with Apple because virtualisation got better and better over the years. I wonder if podman would be a speed downgrade here?
Highly recommend Podman overall; there are some quirky edge cases, but for the most part it’s a smooth replacement for Docker.
If you don’t want to give up compose entirely, podman-compose exists. I just prefer Quadlets so I haven’t used it much myself.
Absolutely zero regrets, would never go back.
Other than that, I haven't found anything that makes me consider using docker again.
The few cases where something was not directly translatable was <10 minutes with a coding agent to make some minor config changes, and then it just worked.
Regardless it works enough for me to run local Kubernetes and Tilt
There is however, the LLMs that pull their fair share of documentation, or rather, replacing it. Not opening that can of worms here, but heck am I glad I can query `$AI` about occasional Podman "burst pipe", instead of hitting Google and looking for [that one e-mail message from a guy who had exactly the same issue, solved it _and_ had the wherewithal to post the solution](https://xkcd.com/979/).
We never got into use of `docker compose`, not in any capacity to speak of, and these days we use Kubernetes and OKD/Openshift for things that Docker -- in my understanding -- solves with swarm and composition. It works well enough, I almost don't find it worthwhile to mention that it does :)
Having a heterogenous fleet can be annoying though, some Podman-only config values[1] stop Docker dead in its tracks because it hates unknown fields.
1. It was a while back, and I can't remember what specific field it was, but it had to do with namespacing and/or (sub)UID mapping.
On the other hand I could see it being hard for people to only install the cli part of docker. Luckily on arch that was simple due to how it's packaged.
I'm also using podman-compose that is small and delightful (I had to fix a few bugs there). It's just one Python file that you can copy.