Hacker News new | ask | show | jobs
by BossingAround 886 days ago
I still don't really understand why Red Hat invests into creating a Docker alternative, but I really like it. Podman does pretty much everything Docker does, but it has more features (e.g. pods) or the way Podman does it tends to be better (e.g. daemonless container spawning process).

The main issue to a common developer would be Docker compose I suppose, which if you use simple compose files, there's actually a podman-compose script that attempts to be compatible with the Docker compose spec.

There's also using Podman as a backend for docker-compose [1]. Overall, in 2024, I see no reason using Docker at least on Linux boxes. Not sure how Podman fares on macOS or Windows.

[1] https://www.redhat.com/sysadmin/podman-docker-compose

5 comments

> I still don't really understand why Red Hat invests into creating a Docker alternative, but I really like it.

They originally tried to work together with docker to fix various issues (e.g. systemd compatibility for certain use case) which had popped up in the past but this turned out not very fruit full.

If you combine this that docker had and still has a uncanny amount of security issues(1) and docker like containers/images being very widely used by developers they had very little choice then to create their own implementation which is more in line with the values and approaches of RHEL.

(1): Like docker still not defaulting to rootless even through it can. For a hardened context both the the docker user group and the ways to run it without the group are security wise a no-go in many use-cases. Like docker initially doing way to little to make sure non privileged containers are at least somewhat sandboxed and taking forever to fix it even when it became known it's an issue. Like the way it interacts with firewalls and networks rules. Like the way it interacts with SELinux. Etc. In companies with dedicated Linux system administrators which care about security docker being banned is not that rare.

I use Podman on Windows. Docker on Windows has been an endless stream of annoyances and frustration for me, starting from the fact everything points you to install an aggressively user-unfriendly GUI that starts up heavyweight processes on boot, nags you to sign up for a cloud account for some reason, and then nags you again that you shouldn't be using this so-called open source product for work anyway. Installing "just the command line" docker as an unsupported alternative is unnecessarily complicated, and last time I tried most WSL VMs didn't even support it out of the box anyway.

Enter Podman, you just winget install podman and it gets out of your way. When you need to run a container, you start up the Podman VM. When you don't, your system behaves exactly as it always did before. If you need to run something in a compose file, podman-compose is there. Maybe it can't handle esoteric configs, but it's worked for my use cases. The only thing Podman doesn't do is integrate with VS Code properly, but honestly the struggle of getting Docker to behave itself on Windows is far more annoying to me than missing some keyboard shortcuts in VS Code, so for me it's not a problem.

I would (and do) recommend Podman as the default solution for containers on Windows. The only reason I can see to use Docker is if your company is paying for it, or if you have a complicated compose setup, in which case it might be worth moving to Kubernetes anyway.

They invest in it because Docker is waaay out of spec with how things are done on Linux. Doing things that break the system, struggling with rootless for years, and who can miss the vendor lock-in? Podman is open and compliant and compliments k8s as well. It’s just nonsense the amount of effort developers have invested in Docker because it was first to market for easy containers.
Docker is every bit as open and not locked in as podman. Perhaps even more so as it's so widely used and doesn't require redhat specific projects around it. Are you confusing docker with docker hub?
It’s really not if you’re talking about Docker Desktop or any of the commercial products: https://docs.docker.com/subscription/desktop-license/

Podman Desktop is completely open.

Well sure, then let's talk about podman desktop. I'm pretty sure the discussion was around docker itself, but maybe I got confused... Because otherwise you can just use other tools rather that docker desktop to manage docker containers (eg rancher desktop, which is also open source).
No, I’m not confusing requiring a DockerHub account to even install Docker. Though that is an excellent example of it’s non-openness, thank you.
What? That's just completely wrong. Even for docker desktop (which is completely different from docker engine) you don't need an account
It appears they have since reverted the decision in 2020 but it used to require logging in for Docker Engine:

https://github.com/docker/docs/issues/6910

I did not know this as I stopped using Docker long ago.

Oh yeah to be clear, I absolutely agree that docker desktop as a whole is a mess especially since they keep introducing more ways to tie it up to docker hub etc. I wouldn't use it unless I'm on windows. So yes, avoid docker desktop but docker (the engine) itself is thankfully completely separate from docker desktop.
> doesn't require redhat specific projects around it.

that is like saying oh no docker requires docker (company) specific projects around it

and as far as I can tell docker in recent years mainly cares about docker desktop and swarm which are less open then podman given their business model

Docker still sees a ton of development. I wouldn't be surprised if it sees more dev than podman.

And my point was more so that podman is obviously designed around the rhel ecosystem. I'm not saying it's closed! Just that even if we were to (wrongly) argue that one of the two is more "locked in", it's clearly podman. Docker is so much more widely used, ported, is basically as completely "non locked in" as it could be.

The only possible "lock in" is maybe the docker images namespace defaulting to docker hub but imo that's trivial and basically more of an early design choice that can't be reverted.

By all means, we can argue about technical differences but the often repeated argument about docker being less open than podman or whatever is just not true

docker isn't really struggeling with rootles, it works with rootless since a long time

they just never bothered making it the default or officially supporting it

which in context with how they acted about other security problems int the past tells a lot about how serious the docker company takes security on linux

> I see no reason using Docker at least on Linux boxes. Not sure how Podman fares on macOS or Windows.

I hope the majority doesn't end up with your point of view. Docker is not RedHat/IBM. If Docker goes away RedHat gets to continue to push their corporate agenda with a heavier hand. There are some advantages to Podman, but there are also some things that have not been executed well in RedHat's mission to replace all things Docker. If you look at the history of how RedHat approached the container space they could have contributed, and improved, a lot of projects they ultimately wasted time and effort on. RedHat isn't a company that has an agenda of doing right by the customer and that's why you should consider what you hope for from a bigger picture perspective.

Red Hat had ample reason to develop Podman when they started the project and no reason now to abandon it.

Red Hat tried to work with Docker, but it didn’t go well. Docker also shot itself in the foot trying to push Swarm over Kubernetes and a bunch of other silliness until they had some serious management/leadership changes.

Podman, IIRC, is 100% FOSS. Not sure you can say the same for Docker. If Red Hat gets stupid with Podman, the rest the community can pick it up and carry on under a new name. Not true of Docker. If Docker gets bought by, say Broadcom tomorrow, the community can only fork the bits that are open.

> they could have contributed, and improved, a lot of projects

they tried to work with docker, it didn't work out, that is why we have podman

and given the headache "securely" using docker is I'm really happy that they did

Honestly, I trust Red Hat a lot more than Docker.

After the first two or so sentences, you don't mention a single specific thing in your comment, so it's difficult to understand what you mean.

I use Podman on Mac OS. I've found the experience better than Docker for the most part, especially when it comes to supporting older versions of Mac OS. The only major downside of Podman on Mac OS is that you cant use the host network in a container, but people will rarely want to use the host network in a container anyway. This is something to keep in mind if you want to experiment with network things in a container and want to retain the same hostname and IP address of your host, however. I manage to work around this limitation anyway.
> The only major downside of Podman on Mac OS is that you cant use the host network in a container

And this isn't even a Podman-specific issue, it's true of Docker Desktop as well [0]:

> The host networking driver only works on Linux hosts, and is not supported on Docker Desktop for Mac, Docker Desktop for Windows, or Docker EE for Windows Server.

[0] https://docs.docker.com/network/drivers/host/

I'm a podman beginner, trying to install ollama-webui(1) using Podman on M2 MBA.

I started up Podman Desktop, and did a terminal command "docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -v ollama-webui:/app/backend/data --name ollama-webui --restart always ghcr.io/ollama-webui/ollama-webui:main" based on Github's instructions, but it gave a error message something about "host".

the exact error message was ""Error": "failed to create new hosts file: unable to replace \"host-gateway\" of host entry \"host.docker.internal:host-gateway\": host containers internal IP address is empty""

Do you know what is the problem and how do I overcome this?

If I run the above command using Docker Desktop, it runs and installs Ollama-WebUI just fine.

Thank you.

(1) https://github.com/ollama-webui/ollama-webui ("Installing with Docker")