9 ms·

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/containe

by SEJeff 6y ago

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 https://github.com/containers/crun

cashewchoo 6y ago
Adduser vs useradd is older than I am and I still can't keep them straight. Just put this with the rest of the fire, I guess, heh!
- lrossi 6y ago
  Indeed. After 30 years of Linux, we should have got better at naming things.
- SEJeff 6y ago
  I think it is sort of a play on words. Since runc is written in go and is slower, crun is written in c and is faster. Stupid nerd joke I know.
lrossi 6y ago
Upside: At least they used a different name. On other occasions, they just hijack the name. Like they did with dstat.
- dralley 6y ago
  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 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.
Ciantic 6y ago
The podman targets the crun too: > Runtime: We use the OCI runtime tools to generate OCI runtime configurations that can be used with any OCI-compliant runtime, like crun and runc.
lima 6y ago
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.
- coder543 6y ago
  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 would have prevented. Rust exists, if performance is so critical here and if Go were somehow at fault... but it sounds like most of the performance difference is due to a different architecture, so rewriting runc in Go probably could have had the same outcome. I wish I could be excited about crun... I’m sure the author has put a lot of effort into it. Instead, I’m more excited about things like Firecracker or gVisor that enable people to further isolate containers, even though such a thing naturally comes with some performance impact.
  - lima 6y ago
    > I wish I could be excited about crun... I’m sure the author has put a lot of effort into it. Instead, I’m more excited about things like Firecracker that attempt to enable people to further isolate containers, even though such a thing naturally comes with some performance impact. gVisor is also very exciting due to how it handles memory allocation and scheduling. Syscalls and I/O are more expensive, though.
    - coder543 6y ago
      Heh, I actually edited gVisor in right before your reply. I agree completely!
  - SEJeff 6y ago
    “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.

by SEJeff 6y ago

cashewchoo 6y ago

Adduser vs useradd is older than I am and I still can't keep them straight. Just put this with the rest of the fire, I guess, heh!

lrossi 6y ago
Indeed. After 30 years of Linux, we should have got better at naming things.
SEJeff 6y ago
I think it is sort of a play on words. Since runc is written in go and is slower, crun is written in c and is faster. Stupid nerd joke I know.

lrossi 6y ago

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

dralley 6y ago
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 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.

Ciantic 6y ago

The podman targets the crun too: > Runtime: We use the OCI runtime tools to generate OCI runtime configurations that can be used with any OCI-compliant runtime, like crun and runc.

lima 6y ago

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.

coder543 6y ago
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 would have prevented. Rust exists, if performance is so critical here and if Go were somehow at fault... but it sounds like most of the performance difference is due to a different architecture, so rewriting runc in Go probably could have had the same outcome. I wish I could be excited about crun... I’m sure the author has put a lot of effort into it. Instead, I’m more excited about things like Firecracker or gVisor that enable people to further isolate containers, even though such a thing naturally comes with some performance impact.
- lima 6y ago
  > I wish I could be excited about crun... I’m sure the author has put a lot of effort into it. Instead, I’m more excited about things like Firecracker that attempt to enable people to further isolate containers, even though such a thing naturally comes with some performance impact. gVisor is also very exciting due to how it handles memory allocation and scheduling. Syscalls and I/O are more expensive, though.
  - coder543 6y ago
    Heh, I actually edited gVisor in right before your reply. I agree completely!
- SEJeff 6y ago
  “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.