4 ms·

I wish Podman wouldn't be a Docker replica, but a standalone product that competes in the container ecosystem with innovative features. Initially the main adva

by imiric 3y ago

I wish Podman wouldn't be a Docker replica, but a standalone product that competes in the container ecosystem with innovative features. Initially the main advantage it had over Docker was rootless mode, but this has been available in Docker for a while now. What currently sets Podman (Desktop/Compose) apart from its Docker counterparts? I've also run into issues running some containers with Podman that work fine with Docker. I still use it for some simple use cases, but I'm wondering more why bother with a copycat product that only plays catch-up to Docker, and has its own set of issues. And, incidentally, is run by Red Hat, and by extension IBM, which are increasingly hostile to OSS.

hu3 3y ago
Docker network effect is too important to ignore. That would be like swimming against the current. For example, Deno (https://deno.land/ https://deno.land/) initially launched with precarious compatiliblity with Node.js, but eventually had to make compromises and adapt so Node.js projects could migrate easier.
- imiric 3y ago
  All of that can be accomplished by being compatible with the broader OCI ecosystem. But Red Hat explicitly tries to be a Docker replacement (they suggest `alias docker=podman`, which actually breaks in many ways), to the point where I'm not sure why I should bother using a product that will always play catch-up to the real thing. This Desktop and Compose announcement is part of that roadmap, and I'm just wondering what Podman does better than Docker at this point.
  - LeFantome 3y ago
    Do you do embedded? Look at the size of crun vs runc and at the portability of Go vs C. Do you like having to have a daemon running? I don’t. Also, the “pod” in the name may yield a few hints. Finally, despite all the recent and undeserved hate, I know that Red Hat will keep their source open. I have no such faith in Docker. Have you priced out Docker Desktop and Podman Desktop lately?
  - freedomben 3y ago
    I find the Pod and Deployment support in Podman to be a killer feature personally. I've also gotten small apps running manually in podman, and once the config is working, podman can emit k8s compatible yaml that can be re-applied to a different podman or applied to a k8s cluster. Pretty sweet IMHO.
    - imiric 3y ago
      That's a good point, thanks. I haven't yet experimented with that.
- ragnese 3y ago
  > For example, Deno (https://deno.land/ https://deno.land/) initially launched with precarious compatiliblity with Node.js, but eventually had to make compromises and adapt so Node.js projects could migrate easier. And we have yet to see if that ends up being the right call. These things are always really tough. On the one hand, compatibility with existing stuff makes migration easier, but then if it's not actually different enough, we have no reason to change to the new thing.
eriksjolund 3y ago
Podman can run a socket-activated network server (such as docker.io/library/nginx) with the "--network=none" option. This improves security.
totallywrong 3y ago
Docker still requires a daemon, even in rootless mode. Podman does not.
zamalek 3y ago
> but a standalone product that competes in the container ecosystem with innovative features. It has tons of features, but people don't pay attention to them due to the Docker being the lowest common denominator. For example, there is absolutely no need for Compose. You create a pod and all the containers in it. You can then ask podman to generate all the systemd units for it. I am also very worried about the IBM issue though, I wonder how long it will be until they slay this golden goose.
stryan 3y ago
Big thing for me is Podman being daemon-less, making it a lot easier to integrate with existing tools since you don't have to treat it as it's own thing. It's already had easy systemd integration for a while now[0] and with Quadlet[1] I don't even bother writing compose files anymore; I just add a [Container] or [Volume] section to the same unit file templates I use everywhere else and it's all taken care of. Though to be honest, I mostly used bash script over compose files anyway since podman-compose never really worked as well. Someone else has already mentioned built in pod support, plus you can generate kube files from existing pods for easy deployment. So you end up with this nice progression of managing: 1. one-off/short term containers with podman run 2. longer running containers with podman generated systemd units 3. generation deployment of above long running containers with Quadlet 4. pods and more complicated setups on one machine with kube files 5. pods and more complicated setups across multiple machines with kubernetes Which is a really nice stack to work with since they all use the same toolbox. And that's outside of other small features like not having to worry about the docker package updating restarting the daemon and taking it all down, socket activation (through systemd units), and auto-updates. [0] https://docs.podman.io/en/latest/markdown/podman-generate-systemd.1.html https://docs.podman.io/en/latest/markdown/podman-generate-sy... [1] https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html https://docs.podman.io/en/latest/markdown/podman-systemd.uni...
rhatdan 3y ago
Do you run with Docker daemon running in rootless mode? Does rancher default to rootless mode? I hear Docker can run in rootless mode but does anyone really run it that way. If I want to start a single container in my homedir, I need to start up multiple docker daemons (dockerd, containerd) to run and then they run forever even if I run in daemon mode. Or I can shut them down until I need to interact with the container again. Have you tried running with Pods? Have you tried Quadlet? Have you tried to generate kube yaml from running pods and containers on your system? Have you used podman to generate pods and containers from existing kubernetes yaml files? Have you launched containers each in their own User Namespace with --userns=auto?

by imiric 3y ago

hu3 3y ago

Docker network effect is too important to ignore. That would be like swimming against the current. For example, Deno (https://deno.land/ https://deno.land/) initially launched with precarious compatiliblity with Node.js, but eventually had to make compromises and adapt so Node.js projects could migrate easier.

imiric 3y ago
All of that can be accomplished by being compatible with the broader OCI ecosystem. But Red Hat explicitly tries to be a Docker replacement (they suggest `alias docker=podman`, which actually breaks in many ways), to the point where I'm not sure why I should bother using a product that will always play catch-up to the real thing. This Desktop and Compose announcement is part of that roadmap, and I'm just wondering what Podman does better than Docker at this point.
- LeFantome 3y ago
  Do you do embedded? Look at the size of crun vs runc and at the portability of Go vs C. Do you like having to have a daemon running? I don’t. Also, the “pod” in the name may yield a few hints. Finally, despite all the recent and undeserved hate, I know that Red Hat will keep their source open. I have no such faith in Docker. Have you priced out Docker Desktop and Podman Desktop lately?
- freedomben 3y ago
  I find the Pod and Deployment support in Podman to be a killer feature personally. I've also gotten small apps running manually in podman, and once the config is working, podman can emit k8s compatible yaml that can be re-applied to a different podman or applied to a k8s cluster. Pretty sweet IMHO.
  - imiric 3y ago
    That's a good point, thanks. I haven't yet experimented with that.
ragnese 3y ago
> For example, Deno (https://deno.land/ https://deno.land/) initially launched with precarious compatiliblity with Node.js, but eventually had to make compromises and adapt so Node.js projects could migrate easier. And we have yet to see if that ends up being the right call. These things are always really tough. On the one hand, compatibility with existing stuff makes migration easier, but then if it's not actually different enough, we have no reason to change to the new thing.

eriksjolund 3y ago

Podman can run a socket-activated network server (such as docker.io/library/nginx) with the "--network=none" option. This improves security.

totallywrong 3y ago

Docker still requires a daemon, even in rootless mode. Podman does not.

zamalek 3y ago

> but a standalone product that competes in the container ecosystem with innovative features. It has tons of features, but people don't pay attention to them due to the Docker being the lowest common denominator. For example, there is absolutely no need for Compose. You create a pod and all the containers in it. You can then ask podman to generate all the systemd units for it. I am also very worried about the IBM issue though, I wonder how long it will be until they slay this golden goose.

stryan 3y ago

Big thing for me is Podman being daemon-less, making it a lot easier to integrate with existing tools since you don't have to treat it as it's own thing. It's already had easy systemd integration for a while now[0] and with Quadlet[1] I don't even bother writing compose files anymore; I just add a [Container] or [Volume] section to the same unit file templates I use everywhere else and it's all taken care of. Though to be honest, I mostly used bash script over compose files anyway since podman-compose never really worked as well. Someone else has already mentioned built in pod support, plus you can generate kube files from existing pods for easy deployment. So you end up with this nice progression of managing: 1. one-off/short term containers with podman run 2. longer running containers with podman generated systemd units 3. generation deployment of above long running containers with Quadlet 4. pods and more complicated setups on one machine with kube files 5. pods and more complicated setups across multiple machines with kubernetes Which is a really nice stack to work with since they all use the same toolbox. And that's outside of other small features like not having to worry about the docker package updating restarting the daemon and taking it all down, socket activation (through systemd units), and auto-updates. [0] https://docs.podman.io/en/latest/markdown/podman-generate-systemd.1.html https://docs.podman.io/en/latest/markdown/podman-generate-sy... [1] https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html https://docs.podman.io/en/latest/markdown/podman-systemd.uni...

rhatdan 3y ago

Do you run with Docker daemon running in rootless mode? Does rancher default to rootless mode? I hear Docker can run in rootless mode but does anyone really run it that way. If I want to start a single container in my homedir, I need to start up multiple docker daemons (dockerd, containerd) to run and then they run forever even if I run in daemon mode. Or I can shut them down until I need to interact with the container again. Have you tried running with Pods? Have you tried Quadlet? Have you tried to generate kube yaml from running pods and containers on your system? Have you used podman to generate pods and containers from existing kubernetes yaml files? Have you launched containers each in their own User Namespace with --userns=auto?