Live data from Hacker News

Reasons to Drop Docker for Podman

developers.redhat.com

41–50 of 98 posts

Re: Reasons to Drop Docker for Podman

#41

This reads like an AI generated article. It covers some differences like pulling images with a gui vs a cli. Ok… thats incredibly unimportant.

It might be because an intern wrote it? I read it myself and I definitely think it’s not an easy read, borderline not make any sense at all, but I don’t think it’s AI because as crazy as it may be, I think an AI would have done a better job at this.

Re: Reasons to Drop Docker for Podman

#42
I started using docker a bit late, only about 3 years ago. My big question is if it is common knowledge that Docker Desktop creates a separate VM in which one's Docker Engine runs, not your host running Docker, but that VM inside your host. That separate VM indirection does not appear to be common knowledge, especially for 3rd party developers, because utilities that are supposed to work with Docker only work without Docker Desktop, or are unaware of Docker Desktop's VM and when installed claim there is no Docker on the host. It's really messed up, and as I tried to figure out what was going on I find nobody recognizes this gargantuan difference between these implementations with and without the "desktop" Docker is internally significantly different, requiring completely different runtime configurations for 3rd party integration.

Re: Reasons to Drop Docker for Podman

#43
post #39

Earlier quoted context omitted.

My guess is Kubernetes would be the way to go here? You can run k3s locally.

Or kind. And use Skaffold or Tilt to manage it all. This setup makes Docker Compose look like a toy. Developers should stop with this impedence mismatch of using Docker Compose when developing and K8s in prod.

It's not about just running the containers. It's that applications are distributed with a docker compose file as the setup medium.

Re: Reasons to Drop Docker for Podman

#44
post #38

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.

You think all programmers are HN-level passionate? Most of my colleagues don't know what a ssh public key is used for.

I was astonished by how few dev people in my company knew what git vs GitHub is, how to create an ssh key, why, etc.

Re: Reasons to Drop Docker for Podman

#45
post #22
post #7

What problem does Docker's daemon actually solve? To me it always felt over-engineered.

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 t…

> Why not have 1 daemon, rather than 1 daemon per container?

Having a daemon per container has this little advantage that if something manages to bring down one of the daemons, it won't bring down the whole shebang.

Re: Reasons to Drop Docker for Podman

#46

I started using docker a bit late, only about 3 years ago. My big question is if it is common knowledge that Docker Desktop creates a separate VM in which one's Docker Engine runs, not your host running Docker, but that VM inside your host. That separate VM indirection does not appear to be common knowledge, especially for 3rd party developers, because utilities that are supposed to work with Docker only work without…

> common knowledge that Docker Desktop creates a separate VM

I mean, I know that linux containers only run on linux (please ignore docker for windows which briefly did not need a vm, that is thing of the past now). I don't know if other people know that linux containers only run on linux.

> utilities that are supposed to work with Docker only work without Docker Desktop, or are unaware of Docker Desktop's VM and when installed claim there is no Docker on the host

> gargantuan difference between these implementations with and without the "desktop" Docker is internally significantly different, requiring completely different runtime configurations for 3rd party integration

It's not really that different though. Because docker has a daemon and API, anything that integrates with docker is supposed to talk to the "$DOCKER_HOST" environment variable to run docker containers, see if docker is running and what version, etc etc.

That should be identical whether "$DOCKER_HOST" is pointed at a unix socket on your host, or at a linux vm, or so on.

The implementation of those APIs should be identical.

Do you have an example of a specific utility? Did you not set "$DOCKER_HOST"?

Re: Reasons to Drop Docker for Podman

#47

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.

I prefer a desktop GUI to cli for a lot of stuff. That's why I use the docker integration into intelliJ.

Re: Reasons to Drop Docker for Podman

#48
post #22

Earlier quoted context omitted.

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 t…

> Why not have 1 daemon, rather than 1 daemon per container? Having a daemon per container has this little advantage that if something manages to bring down one of the daemons, it won't bring down the whole shebang.

Also side-channel attacks.

E.g. if one user downloads a container, and then for another user it is already in the cache, this gives the other user information about the first user.

Re: Reasons to Drop Docker for Podman

#49
post #16
post #8

Small fyi, the site seems to break the back button on mobile.

It has an annoying table of contents system that seems to move you to new urls constantly as you scroll up and down, so back just takes you to different parts of the page for a while till you finally leave.

Not an awful feature if it rewrote the existing URL in place, rather than pushing a new one (idk if the API actually allows that) - so copying it to share you'd always get the right anchor to where you're currently reading (or could remove it still if you intended to share the whole thing).

Re: Reasons to Drop Docker for Podman

#50

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

I tried using Podman for about 4 or 5 months on my M1 Mac, but eventually just gave up in frustration. I'm not doing anything too crazy, just running Minikube for some local development, but it just isn't stable enough and requires a lot of digging into threads to find the workarounds or the proper config.

I was wasting more and more time on it. It was constantly crashing/hanging so one day I just said fuck it and switched back to Docker Desktop, which not only worked better than when I switched but seems to have improved quite a lot in the intervening time as well.

Post reply on HN