Live data from Hacker News

Red Hat to contribute container tech (Podman, bootc, ComposeFS...) to CNCF

redhat.com

71–80 of 89 posts

Re: Red Hat to contribute container tech (Podman, bootc, ComposeFS...) to CNCF

#71
post #54

I think people are missing the contribution of bootc and composefs. This is a big part of what undergirds Red Hat's new 'image mode' means of deployment. They're using container-related tooling to deploy whole operating systems, and it's a large part of where they're headed. I write this to say, "This is not them dumping abandonware." To me, it's them putting these technologies under the supervision of a neutral thir…

Composefs has a totally crucial feature that sold me immediately, which is that if two containers use the same file, the kernel can serve that file from the same page cache. This means you can hypothetically launch a lot of containers, and if they share some layers/base images, the memory usage can still be quite reasonable. Nice. https://github.com/containers/composefs?tab=readme-ov-file#b...

Re: Red Hat to contribute container tech (Podman, bootc, ComposeFS...) to CNCF

#72
post #51

Is CNCF new Apache foundation? Looks like everyone dumps their stuff there. Does not look promising. Am I missing something? Probably RedHat paid salary to podman developers, but who will pay salary to them now?

In the same way as how the Kubernetes ecosystem is the new Enterprise Java ecosystem? Often even from the same companies as back in the late 90s/00s. Look: I'm probably ignorant, but from the outside the similarities seem striking. Please explain why I'm wrong. I'm humble on this one.

Kubernetes is the new websphere. Yaml the new ANT.

Re: Red Hat to contribute container tech (Podman, bootc, ComposeFS...) to CNCF

#73
post #26

To all those interested in podman, this book by Daniel Walsh is a gem. Highly recommended and it is free. https://developers.redhat.com/e-books/podman-action

The font on that book is so awful. As someone with bad sight i have to strain my eyes a lot to read even a single sentence.

Re: Red Hat to contribute container tech (Podman, bootc, ComposeFS...) to CNCF

#74

Earlier quoted context omitted.

That would be news to me, as both are pointing to the exact same GitHub repository[0]. Can you name the differences? [0]: https://github.com/docker/compose

Previous docker-compose was a separate program, written in Python if I remember correctly, people usually preferred to them as v1. Later docker incorporated it into the docker binary itself as a subcommand so that’s v2

v2 is still a separate binary, it can just be installed in different ways (on Linux). If GGGP was referring to v1, then that's legacy software since 2+ years and they probably shouldn't use it.

Re: Red Hat to contribute container tech (Podman, bootc, ComposeFS...) to CNCF

#75

Podman actually works really well. Out-of-the-box virtually-no-configuration-needed rootless containers. It's also usable via docker-compose with a single env variable. (podman-compose wasn't up to par for us) We've been using it for a couple of years running and managing hundreds of containers per server - no feeling of flakiness whatsoever. It's virtually zeroconf and even supports GPUs for those who need it. It's…

Dumb question: is it rootless for users on something like macOS? I'd love to get the benefits of Docker without the battery drain and the Docker software, but I'm not sure if Podman would help much with either.

[deleted]

Re: Red Hat to contribute container tech (Podman, bootc, ComposeFS...) to CNCF

#76

Earlier quoted context omitted.

Previous docker-compose was a separate program, written in Python if I remember correctly, people usually preferred to them as v1. Later docker incorporated it into the docker binary itself as a subcommand so that’s v2

v2 is still a separate binary, it can just be installed in different ways (on Linux). If GGGP was referring to v1, then that's legacy software since 2+ years and they probably shouldn't use it.

The one problem I previously hit was that the ansible integration used the Python version; I hope they've fixed it now but haven't looked lately.

Re: Red Hat to contribute container tech (Podman, bootc, ComposeFS...) to CNCF

#77

Is CNCF new Apache foundation? Looks like everyone dumps their stuff there. Does not look promising. Am I missing something? Probably RedHat paid salary to podman developers, but who will pay salary to them now?

I'm sure Red Hat will continue to pay Podman developers, just like they continue to pay developers for the other upstream projects that are hosted at CNCF (like Kubernetes). I'm we can all think of some projects "abandoned" to foundations through the years, but in general, I'd call getting core infrastructure out of the control of a single company and into a place with more transparent and democratic governance a goo…

Maybe open source foundations should be more selective with the projects. I'm thinking of Oracle dumping OpenOffice, although it was obvious that LibreOffice is the way to go.

Re: Red Hat to contribute container tech (Podman, bootc, ComposeFS...) to CNCF

#78

Earlier quoted context omitted.

v2 is still a separate binary, it can just be installed in different ways (on Linux). If GGGP was referring to v1, then that's legacy software since 2+ years and they probably shouldn't use it.

The one problem I previously hit was that the ansible integration used the Python version; I hope they've fixed it now but haven't looked lately.

Looks like v2 is available: https://galaxy.ansible.com/ui/repo/published/community/docke...

Re: Red Hat to contribute container tech (Podman, bootc, ComposeFS...) to CNCF

#79
post #54

I think people are missing the contribution of bootc and composefs. This is a big part of what undergirds Red Hat's new 'image mode' means of deployment. They're using container-related tooling to deploy whole operating systems, and it's a large part of where they're headed. I write this to say, "This is not them dumping abandonware." To me, it's them putting these technologies under the supervision of a neutral thir…

Composefs has a totally crucial feature that sold me immediately, which is that if two containers use the same file, the kernel can serve that file from the same page cache. This means you can hypothetically launch a lot of containers, and if they share some layers/base images, the memory usage can still be quite reasonable. Nice. https://github.com/containers/composefs?tab=readme-ov-file#b...

If you swap to a content-based object store for container images (like OSTree/Flatpak), you could potentially save a lot of disk space too because you'll no longer need to be careful about your Dockerfile layers.

If two OCI images share the same file, they'll be de-duplicated on disk and only be downloaded once.

Post reply on HN