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

141–150 of 250 posts

Re: Podman: A Daemonless Container Engine

#141

Post by lmeyerov »

mbreese wrote: post #136
lmeyerov wrote: post #67

Earlier quoted context omitted.

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…

But RHEL repositories are always out of date, sorry, I mean "stable". The disconnect is when you try to `yum install docker` on a RHEL system, you get an old version. If you want a newer version of Docker, you need to use the Docker provided repositories. But this is the case for all software on RHEL. It's all older and more stable. Try installing any programming language, database, etc... it's always a version or tw…

Oof I wish more enterprises/govs could do that. In RHEL 8, a team would need to modify their trust chain to include centos 7 / epel to get at the old and still working `yum install` binaries, and that gets into IT signoffs before we even get into discussing updated versions.

I'd totally expect a trade-off for old & stable over new and shiny for RHEL: They're getting paid for that kind of neutral & reliable infra behavior. That'd mean RHEL is packaging docker / docker-compose, and maybe podman as an optional alternative. Instead IBM/RHEL is burning IT dept $ and stability by not allowing docker and only sanctioning + actively promoting IT teams use their alternative in unreliable ways.

Re: Podman: A Daemonless Container Engine

#142

Post by kragniz »

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.

Remember that runc contains quite a few lines of C:

https://github.com/opencontainers/runc/blob/4d4d19ce528ac40c...

https://github.com/opencontainers/runc/blob/4d4d19ce528ac40c...

Re: Podman: A Daemonless Container Engine

#143

Post by adev_ »

SEJeff wrote: post #98
lima wrote: post #90

Earlier quoted context omitted.

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.

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

Yeah and C++ would be a way better language to write critical system daemon in 2020 than C. Both safer and more productive while keeping the exact same portability and performance as C when necessary.

Most safety issues of C (buffer overflows, use-after-free, stack smash) are not a problem anymore in modern C++.

Yes, writing new userland software in C in 2020(1) is non-sense.

- Use at least C++ if you are conservative.

- Use Rust if you aim for absolute safety.

- Use Go if you accept the performance hit and do not need libraries.

There is zero excuses to C in userland in 2020.

The only excuse is some Red Hat folks seems to practice C++ hating as some kind of religion.

That exactly what give us "beautiful" monstrosities like systemd or pulseaudio with their associated shopping list of CVEs [^1]

Even GCC maintainers switched to C++, by the sake of god, do the same.

----

[^1]: https://www.cvedetails.com/product/38088/Freedesktop-Systemd...

Re: Podman: A Daemonless Container Engine

#144

Post by xyzzy_plugh »

vishvananda wrote: post #95
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.

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…

> Go is actually a really poor choice for the container runtime because much of the container setup cannot be done from multithreaded code[0]

This was addressed in 2017/2018 [0], it's no longer a poor choice.

[0]: https://github.com/golang/go/commit/2595fe7fb6f272f9204ca3ef...

Re: Podman: A Daemonless Container Engine

#145

Post by legulere »

CivBase wrote: post #123
tshtf wrote: post #118

Earlier quoted context omitted.

It probably isn't worth trying. djb wrote remotely exploitable C for qmail, applications written by the OpenBSD team have had exploitable memory issues, Microsoft still doesn't get it right, neither do Linux kernel devs.

You say that as if the likes of Microsoft or Linux kernel devs consist exclusively of elite C devs. I'm very glad languages like Go and Rust exist, but saying you shouldn't write C because you might create memory leaks is kind of like saying you shouldn't write multi-threaded code because you might create race conditions. Yeah, it adds complexity to your code, but it's sometimes worth the overhead it saves. Whether t…

It’s not just the developers. The code gets reviewed and merged as well. I don’t know which projects but those are the highest quality C code based.

Writing in C doesn’t create complexity but lots of traps to fall in. Writing in C doesn’t save overhead over Rust. Your rust code can be very low level and safe and C isn’t that close to hardware as it used to be anyway.

Re: Podman: A Daemonless Container Engine

#146

Post by coldtea »

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.

And yet NASA uses C, not Rust.

Re: Podman: A Daemonless Container Engine

#147

Post by zapita »

kbenson wrote: post #135
zapita wrote: post #105

Earlier quoted context omitted.

Thank you for illustrating my point perfectly. “Grudge?” (proceeds with details of grudge).

What was described could be the basis of a grudge, or it could be that Red Hat were convinced that the current project would not accept changes Red Hat would benefit by even if it helped many other people. At that point, and at the size of Red Hat and how important this technology is becoming for them, it only makes sense for them to secure some of the technological foundations they rely on. It costs them very little…

runc, containerd and the docker client are critical infrastructure to a whole lot of people, and they seem to be doing just fine running it and, when needed, contributing back. Only Red Hat seems to have a problem with using those projects without forking or re-writing them. Could it be because Red Hat considers it of strategic importance for their business, not just for those projects to be reliable (they are), but to be controlled by them to a sufficient degree that they can act as gatekeepers to upstream, thus preserving their business model?

Re: Podman: A Daemonless Container Engine

#148

Post by zapita »

hda111 wrote: post #140
zapita wrote: post #92

Earlier quoted context omitted.

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.

So why does podman include code from docker?

Excellent question, especially since the code is copy-pasted without crediting the original authors. Could it be that they’re trying to minimize the role of Docker as much as possible even when re-using their code?

Re: Podman: A Daemonless Container Engine

#150

Post by nednar »

yobert wrote: post #109

I've been trying to use podman in production and it is not working very well. I'm excited for this technology but it is not ready. - podman layer caching during builds do not work. When we switched back to docker-ce, builds went from 45 minutes to 3 minutes with no changes to our Dockerfile - fuse-overlayfs sits at 100% CPU all day, every day on our production servers - podman loses track of containers. Sometimes the…

What are the Github issue IDs for these 4 problems?
Post reply on HN