Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Podman: A Daemonless Container Engine

podman.io

Post reply on HN
Print view View original

61–70 of 250 posts

Re: Podman: A Daemonless Container Engine

#61

Post by op00to »

lmeyerov wrote: post #47
runeks wrote: post #44

Sincere question: why would I want to use Podman over Docker? What does being "daemonless" actually buy me in practice?

$ for your favorite infra oss startup or volunteer rhel ~forces you to do podman in rhel 8+. They make it hard enough to do a docker install that corp policies will reject docker (non-standard centos 7 repos etc), while allowing ibm's thing. Ex: Locks podman over docker for a lot of US gov where rhel 8 is preferred and with only standard repos, and anything else drowns in special approvals. subtle and orthogonal to p…

Because people can’t install non-Red Hat software due to internal policy, that’s somehow anti-competitive?

Re: Podman: A Daemonless Container Engine

#62

Post by fillest »

Well, "daemonless" is kind of marketing - there is still this daemon-per-container 'conmon' thing https://github.com/containers/conmon and I don't get why it is needed because 1) who actually needs to re-attach anyway? 2) container's streams are already properly handled by whatever supervisor (e.g. systemd). You can't disable conmon and I'm not sure if its usage is not hardcoded throughout the codebase.

I would very much like to use Podman as a finally proper container launcher in production (non-FAANG scale - at which you maybe start to need k8s), but having an unnecessary daemon moving part in thousands lines of C makes me frown so far.

Re: Podman: A Daemonless Container Engine

#63

Post by greggyb »

runeks wrote: post #44

Sincere question: why would I want to use Podman over Docker? What does being "daemonless" actually buy me in practice?

I can't answer the question well, but I think the opposite is just as valid a question: What does a daemon buy you in practice? Why do you need to run the Docker daemon if it is possible (as appears so from podman's existence) to do the same thing without a daemon?

Re: Podman: A Daemonless Container Engine

#66

Post by quadrifoliate »

geerlingguy wrote: post #19

What's the status on ease of running on Mac? I know last time I seriously considered testing it out in my workflow, it was kind of crazy that I had to have a separate machine (VM or real) just to run container images... I see in the docs [1]: "Podman is a tool for running Linux containers. You can do this from a MacOS desktop as long as you have access to a linux box either running inside of a VM on the host, or avai…

Yeah without a transparent workflow like that for Mac, there is no reason for me to switch to this project.

I wish they had tried to collaborate with Docker and contribute upstream instead of this project.

Re: Podman: A Daemonless Container Engine

#67

Post by lmeyerov »

op00to wrote: post #61
lmeyerov wrote: post #47

Earlier quoted context omitted.

$ for your favorite infra oss startup or volunteer rhel ~forces you to do podman in rhel 8+. They make it hard enough to do a docker install that corp policies will reject docker (non-standard centos 7 repos etc), while allowing ibm's thing. Ex: Locks podman over docker for a lot of US gov where rhel 8 is preferred and with only standard repos, and anything else drowns in special approvals. subtle and orthogonal to p…

Because people can’t install non-Red Hat software due to internal policy, that’s somehow anti-competitive?

The main repos have plenty of non-rhel sw, and people can expend social capital working around IT policies, but that doesn't change it being against the grain.

We are fine because we use Ubuntu for the generally better GPU support, but I don't have control over the reality of others. I repeatedly get on calls with teams where this comes up, and I feel sorry for the individuals who are stuck paying the time etc. cost for this. Docker for RHEL 8 is literally installing Docker for Centos 7, so this isn't a technology thing, but political: A big corporate abusing their trusted neutral oss infra position to push non-neutral decisions in order to prop up another part of its business. This is all bizarre to operators who barely know Docker to beginwith, and care more about say keeping the energy grid running. ("The only authorized thing will likely not work b/c incompatibilities, and I have to spend 2w getting the old working thing approved?")

And again, none of this is technical. Docker is great but should keep improving, so competitive pressure and alternatives are clearly good... but anti-competitive stuff isn't.

Re: Podman: A Daemonless Container Engine

#69

Post by dralley »

lrossi wrote: post #52
SEJeff wrote: post #41

Under the covers, both podman AND docker use runc. Redhat is writing a new version named "crun" which is lower overhead and faster: https://github.com/containers/crun

Upside: At least they used a different name. On other occasions, they just hijack the name. Like they did with dstat.

That was a misunderstanding where they saw that there had been no commit activity for 3 years, and no responses to issues/PRs filed in the past 18 months, and assumed the upstream was dead.

Making that assumption was reasonable - moving forwards without at least making an attempt to contact the maintainer "just in case" was not. It would have been courteous to at least try.

But it's not exactly the deliberate hostile takeover that you make it out to be.

https://bugzilla.redhat.com/show_bug.cgi?id=1614277#c9

>> To my knowledge, there is no need (legally) to obtain consent to use the name 'dstat' for a replacement command providing the same functionality. It might be a nice thing to do from a community perspective, however - if there was someone to discuss with upstream.

>> However, dstat is dead upstream. There have been no updates for years, no responses at all to any bug reports in the months I've been following the github repo now, and certainly no attempt to begin undertaking a python3 port.

>> Since there is nobody maintaining the original dstat code anymore, it seemed a futile exercise to me so I've not attempted to contact the original author. And as pcp-dstat is now well advanced beyond the original dstat - implementing features listed in dstat's roadmap for many years, and with multiple active contributors - I think moving on with the backward-compatible name symlink is the best we can do.

Re: Podman: A Daemonless Container Engine

#70

Post by lima »

SEJeff wrote: post #41

Under the covers, both podman AND docker use runc. Redhat is writing a new version named "crun" which is lower overhead and faster: https://github.com/containers/crun

Great idea - let's rewrite the most security-critical piece of container tech in plain C!

Red Hat literally took a memory safe Go program and rewrote it in C for performance, in 2020.

Post reply on HN