This reads like an AI generated article. It covers some differences like pulling images with a gui vs a cli. Ok… thats incredibly unimportant.
Reasons to Drop Docker for Podman
41–50 of 98 posts
Re: Reasons to Drop Docker for Podman
#42Re: Reasons to Drop Docker for Podman
#43Earlier 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.
Re: Reasons to Drop Docker for Podman
#44I'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.
Re: Reasons to Drop Docker for Podman
#45What 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…
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
#46I 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…
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
#47I'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.
Re: Reasons to Drop Docker for Podman
#48Earlier 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.
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
#49Small 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.
Re: Reasons to Drop Docker for Podman
#50Anyone using Podman on a macOS? How's the experience compared to Docker Desktop?
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.