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

121–130 of 250 posts

Re: Podman: A Daemonless Container Engine

#121

Post by Brian_K_White »

SEJeff wrote: post #101
vishvananda wrote: post #95

Earlier quoted context omitted.

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…

This I entirely agree with you on but I’d expect it due to the resources available at the time were more fluent with C than rust. A shame really.

Or they want to be more platform-agnostic than rust and llvm.

Re: Podman: A Daemonless Container Engine

#123

Post by CivBase »

tshtf wrote: post #118
8fingerlouie wrote: post #111

Earlier quoted context omitted.

Contrary to popular belief, memory safe C is possible to write, and with modern linters it’s even easier. Yes it’s easier to shoot yourself in the foot, but with practice you can learn to miss every time.

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 that trade-off is worth it is always up for debate.

Re: Podman: A Daemonless Container Engine

#124

Post by tshtf »

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…

Oh, I agree it is a tradeoff. But the parent said "you can learn to miss every time". Can anyone point me to a C language project where the developers consistently miss every time?

Re: Podman: A Daemonless Container Engine

#125

Post by corty »

flowless wrote: post #56
corty wrote: post #23

Even less IPv6 support than docker. With docker you can at least get it to work somehow, even if it is totally different from IPv4, weirdly. Podman just has no IPv6 support to speak of.

Not entirely true. I was researching this few hours ago and according to https://github.com/containers/podman/issues/6114#issuecommen... it just works when you add another network. Docker registry having no IPv6 is another fun story tho.

Well, from that issue from 2020-12-24: "--ipv6 has not landed yet", so you cannot assign static external v6 adresses to a container. No activity on that bug since. There is tons of stuff in docker that works automatically, where in podman it is like "Please be aware you have to configure ip6tables (or whatever your OS firewall is) for forwarding.". Yeah, well, if i have to do everything by hand or program a ton of scripts around it, it is quite useless, isn't it?

IPv6 support is always like this: half-baked at best, someone got it to work somehow, developers declare it done since it worked for someone. Then crickets...

IPv6 support isn't done until you can replace IPv4 with it, with no changes to your config except addresses. Even docker isn't there yet. And podman's is still in a larval state.

Re: Podman: A Daemonless Container Engine

#126

Post by geerlingguy »

oauea wrote: post #91
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 ;)

It doesn't matter what platform I'm on, I like tools that let me be lazy ;)

Re: Podman: A Daemonless Container Engine

#127

Post by CivBase »

tshtf wrote: post #124
CivBase wrote: post #123

Earlier quoted context omitted.

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…

Oh, I agree it is a tradeoff. But the parent said "you can learn to miss every time". Can anyone point me to a C language project where the developers consistently miss every time?

Are you saying that every project written in C has suffered from a memory leak issue at some point? Most C/C++ code I've personally written doesn't even use the heap.

I work on avionics and we use C/C++ now and then. We have a ton of rules regarding memory management (pretty much everything stays on the stack) and I can't recall anything I've ever been involved with suffering from a memory leak.

Re: Podman: A Daemonless Container Engine

#128

Post by tshtf »

CivBase wrote: post #127
tshtf wrote: post #124

Earlier quoted context omitted.

Oh, I agree it is a tradeoff. But the parent said "you can learn to miss every time". Can anyone point me to a C language project where the developers consistently miss every time?

Are you saying that every project written in C has suffered from a memory leak issue at some point? Most C/C++ code I've personally written doesn't even use the heap. I work on avionics and we use C/C++ now and then. We have a ton of rules regarding memory management (pretty much everything stays on the stack) and I can't recall anything I've ever been involved with suffering from a memory leak.

All I'm saying is that it's a trivial oversimplification to say you can learn to miss every time.

Re: Podman: A Daemonless Container Engine

#129

Post by gobblegobble2 »

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.

The most security-critical part of container tech lives in Linux kernel and has always been in plain C.

Re: Podman: A Daemonless Container Engine

#130

Post by 8fingerlouie »

tshtf wrote: post #124
CivBase wrote: post #123

Earlier quoted context omitted.

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…

Oh, I agree it is a tradeoff. But the parent said "you can learn to miss every time". Can anyone point me to a C language project where the developers consistently miss every time?

It’s possible with rules, experience and guidance.

Granted, I learned to write C 25+ years ago, and have worked as a C programmer for 15 of them, writing mostly embedded software for mobile phones (pre smartphone), airport sorters, but have also written financial software (mostly for parsing NASDAQ feeds), but the point is that most of the software I’ve written has had close to a decade of “runtime”, and while I started out making the same mistakes as everybody else, you learn to put ranges on your heap pointers like strncpy instead of just blindly doing strcpy.

Checking the size of your input vs your allocated memory takes care of a lot of it. As for memory leaks, it’s not exactly hard to free a pointer for every time you malloc one.

People are terrified of C, and yes, Go, Rust, Java, C# makes it harder to make _those_ mistakes, but that doesn’t mean it’s impossible to write good C code.

And it’s not like projects written in Go or Rust are error free. They just struggle with different errors.

As for good C projects, check stuff like postfix, nginx, and yes Linux or FreeBSD.

Post reply on HN