Hacker News new | past | comments | ask | show | jobs | submit
Has Podman become more user friendly in recent years? I gave it a go about three or four years ago now when Docker began their commercial push (which I don't have an issue with).

This was for some hobby project, so I didn't spend a ton of time, but it definitely wasn't as set-and-forget as Docker was. I believe I had to set up a separate VM or something? This was on Linux as the host OS too. It's been a while, so apologies for the hazy memory.

Or it's very possible that I botched the entire setup. In my perfect world, it's a quick install and then `podman run`. Maybe it's time to give it another go.

Definitely more user friendly, and I love using Quadlets! For people using Flatpaks (Linux), check out the app 'Pods' as a lightweight alternative to Podman Desktop. It is still a young project, but is already a very useful way of managing your containers and pods.

As a side note, it is so _refreshing_ to observe the native apps popping up for Linux lately, it feels like a turning point away from the Electron-everything trend. Apps are small, starts immediately and is well integrated with the rest of the system, both functionally and visually. A few other examples of native apps; Cartero, Decibels, GitFourchette, Wike – to name a few that I'm using.

I've found it very straight forward to work with. I run the cli on macOS to spin up ephemeral containers all the time for testing and simple tasks. Never had an issue.

In the spirit of the OP, I also run podman rootless on a home server running the usual home lab suspects with great success. I've taken to using the 'kube play' command to deploy the apps from kubernetes yaml and been pleased with the results.

loading story #43130036
The biggest difference in my (admittedly limited) experience, is that you need to start a "podman machine" before you can start running containers. This is architecturally different from Docker's use of a daemon, in ways I'm not qualified to explain in more detail.

It's an extra step, but not a painful one -- the default podman machine configuration seems to work pretty well out of the box for most things.

Honestly, for my use-case (running Subabase stack locally), it was seamless enough to switch that I'm a little surprised a bash script like this is necessary. On my Mac, I think it was simply `brew install podman` followed by `podman machine start` and then I got back to work as if I were still using docker.

By far the most tedious part of the switch was fully uninstalling Docker, and all its various startup programs & background processes.

loading story #43128708
It's almost a perfect drop-in replacement for Docker so I don't see why it would be any less "set-and-forget".

I only ever found one thing that didn't work with it at all - I think it was Gitlab's test docker images because they set up some VMs with Vagrant or something. Pretty niche anyway.

loading story #43130476
loading story #43130045
loading story #43129672
It is not user-friendly, but it works flawlessly once you get used to it.

I stayed away from docker all these years and tried podman from scratch last year after docker failed to work for a project I was experimenting with.

Took an hour to read various articles and get things working.

One thing I liked was it does not need sudo privileges or screw with the networking.

The only snag I hit regularly is me forgetting to set :z or :Z on my podman volumes to make it play well with SELinux.

I used to use docker compose, but migrated to podman quadlets. The only thing I miss is being able to define every container I run in a pod in the .pod file itself. Having it integrate with systemd is great.

Hasn't become more friendly from what I've seen. The project seems largely centered around K8s, and isn't really investing in fixing anything on the "compose" side. I did the same thing as you when Docker first started going down the more commercial path, and after dealing with random breakages for a number of years, fully switched back to Docker (for local dev work on osx).

Podman machine is fine, but occasionally you have to fix things _in the vm_ to get your setup working. Those bugs, along with other breakages during many upgrades, plus slower performance compared to Docker, made me switch back. This is just for local dev with a web app or two and some supporting services in their own containers via compose, nothing special. Totally not worth it IMO.

This is mostly solved I think. I run Podman Desktop on macOS and just aliased Docker to Podman in zshrc and it just works for me. I don’t do any local k8s or anything crazy, but it works with my compose files. I’m going to guess there’s still rough edges if you want GPU passthrough or something with complex networking, but for a server and a database running together it matches Docker itself.
On NixOS it was as trivial as `podman.enable = true;`. IIRC on Arch it was just a matter of installing the package.

It's all daemonless, rootless and runs directly with your host kernel so it should be as simple as it an application of this kind gets. Probably you followed some instructions somewhere that involved whatever the podman equivalent for docker-machine is?

My container using is admittedly pretty simplistic (CRUD app with some REST services), but after initial setup I've found it to be extremely reliable and simple to use. They strive for 1:1 docker compat so I think it should be pretty easy to migrate.