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

91–100 of 250 posts

Re: Podman: A Daemonless Container Engine

#91

Post by oauea »

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…

> And yes, I know that Docker (and any other Linux container-based tool) also runs a VM—but it sets it up almost 100% transparently for me. I install docker, I run `docker run` and I have a container running.

Comments like this help reinforce the stereotype of lazy macos developers ;)

Re: Podman: A Daemonless Container Engine

#92

Post by zapita »

lima wrote: post #70
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.

It’s not for performance. It’s to settle an old grudge with Docker. All code coming from Docker must be erased.

See also: podman; cri-o; buildah.

Re: Podman: A Daemonless Container Engine

#93

Post by eeZah7Ux »

jnwatson wrote: post #86
SEJeff wrote: post #84

Earlier quoted context omitted.

It is almost 50% faster for launching containers. That’s considerable, and at scale could be an actual cost savings. If nothing else, efficiency is good. Also, small c projects can be written properly with discipline. This is a very talented team on a very small and well scoped project. It can be written properly.

There's also the copious amount of static analysis and warnings built into gcc and clang these days, not to mention safer build options. Writing C today is quite a bit better than even 10 years ago.

External static analyzers also improved a lot.

You can ensure memory-safety in C by enforcing strict rules since the first commit.

Re: Podman: A Daemonless Container Engine

#94

Post by [deleted] »

SEJeff wrote: post #85
coder543 wrote: post #72

Earlier quoted context omitted.

Yeah. I just don’t think “runc” has ever been a bottleneck in any systems I’ve worked with. It’s been years since I’ve been able to get excited about rewriting systems from a memory safe language into a memory unsafe language for “performance reasons”. As an industry, we have too much evidence that even the best humans make mistakes. Quality C codebases still consistently run into CVEs that a memory safe language wou…

“Any of the systems you’ve worked with” I suspect it has been a bottleneck in some of the systems redhat has worked with, or they would have no benefit in writing it. As the authors of openshift I’m sure they’ve seen some pretty crazy use cases. Just because it isn’t your use case doesn’t make it invalid.

[deleted]

Re: Podman: A Daemonless Container Engine

#95

Post by vishvananda »

lima wrote: post #70
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.

Go is actually a really poor choice for the container runtime because much of the container setup cannot be done from multithreaded code[0], so it has to be done in C before the go runtime initializes. I do think rust is a better choice for this layer than C because there are still security risks, but getting rid of Go for this layer is a win. I'm not sure why RH chose to rewrite it in C rather than using rust[1].

[0]: https://www.weave.works/blog/linux-namespaces-and-go-don-t-m... [1]: https://github.com/drahnr/railcar

Re: Podman: A Daemonless Container Engine

#96

Post by eeZah7Ux »

archi42 wrote: post #82
otabdeveloper4 wrote: post #58

Earlier quoted context omitted.

podman runs out of the box in normal user mode and doesn't require sudo.

This. SO MUCH THIS. We use docker for our CI, which is mostly okay. But we devs don't have root on our workstations, so we can't just load the docker image and test stuff in the CI env. Enter podman: I've written a small perl wrapper around it and now everyone can just call `ci-chroot` to drop to a CI-equivalent shell. They can get virtual root (default) or normal user (--user), and the script takes care of everythin…

> we devs don't have root on our workstations

What's the justification for this... while at the same time allowing the use of containers?

Re: Podman: A Daemonless Container Engine

#98

Post by SEJeff »

lima wrote: post #90
jnwatson wrote: post #86

Earlier quoted context omitted.

There's also the copious amount of static analysis and warnings built into gcc and clang these days, not to mention safer build options. Writing C today is quite a bit better than even 10 years ago.

Better, yes. Safe, no. Even with ASAN and modern C++, vulnerabilities happen all the time.

This is C, not C++. Modern C++ is kind of a mess with how much stuff they’ve added to the language. This is not relevant.

Re: Podman: A Daemonless Container Engine

#100

Post by SEJeff »

zapita wrote: post #92
lima wrote: post #70

Earlier quoted context omitted.

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.

It’s not for performance. It’s to settle an old grudge with Docker. All code coming from Docker must be erased. See also: podman; cri-o; buildah.

Grudge? You mean when Jessie Frazelle walked around dockercon with a badge saying, “I will not merge patches for systemd” just out of principal? In hindsight it is fairly obvious picking a fight at redhat summit was a very poor long term strategy from docker. It forced them to ultimately sell the orchestration parts of their business and massively limit the free tier of docker hub.
Post reply on HN