Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Wolfi: A community Linux OS designed for the container and cloud-native era

github.com

Post reply on HN
Print view View original

11–20 of 89 posts

Re: Wolfi: A community Linux OS designed for the container and cloud-native era

#11

Post by dlor »

aerfio wrote: post #9
mkl wrote: post #3

Seems to have a confusing lack of "getting started" documentation. On the plus side, I now know what the world's smallest octopus is, so the important stuff is covered!

From my side I'd love to see clear comparison to distroless[1] images, the best info I could find was this Github issue comment[2], although I would expect to find it in https://github.com/wolfi-dev#faq . Or maybe my google-fu failed me :( [1]: https://github.com/GoogleContainerTools/distroless [2]: https://github.com/tektoncd/pipeline/issues/5507#issuecommen...

I was (one of) the original creators of the Google Distroless project. The main difference is that Original Distroless uses Debian as the upstream. This is great in many ways, but makes it so stuff outside of Debian is hard to package in.

Wolfi is its own upstream - packages are sourced and built directly from source, without another Linux distro.

The rest of the differences stem from here - we get more control over what we package and how, and are able to more quickly add new versions of packages, or roll out CVE patches.

Re: Wolfi: A community Linux OS designed for the container and cloud-native era

#14

Post by dlor »

thomasfromcdnjs wrote: post #13

What is the benefits of using the container kernel? Does alpine generally do this if it installed in a container?

You don't really have a choice - containers always use the host kernel. So packaging the full kernel itself is a waste of space at best, confusing to CVE scanners, and something you just don't need to bother with if you work with containers only.

Re: Wolfi: A community Linux OS designed for the container and cloud-native era

#15

Post by dlor »

rcarmo wrote: post #12

I like the idea of having an SBOM as a standard, baked-in feature from the outset. That kind of thing is becoming critical in software supply chain management.

Thanks! By building the SBOMs as part of the build process we can ensure full coverage, vs. the other approaches that rely on "guessing" the contents after. We wrote a bit more about this approach here: https://www.chainguard.dev/unchained/make-sboms-not-guessbom...

Re: Wolfi: A community Linux OS designed for the container and cloud-native era

#16

Post by aerfio »

dlor wrote: post #11
aerfio wrote: post #9

Earlier quoted context omitted.

From my side I'd love to see clear comparison to distroless[1] images, the best info I could find was this Github issue comment[2], although I would expect to find it in https://github.com/wolfi-dev#faq . Or maybe my google-fu failed me :( [1]: https://github.com/GoogleContainerTools/distroless [2]: https://github.com/tektoncd/pipeline/issues/5507#issuecommen...

I was (one of) the original creators of the Google Distroless project. The main difference is that Original Distroless uses Debian as the upstream. This is great in many ways, but makes it so stuff outside of Debian is hard to package in. Wolfi is its own upstream - packages are sourced and built directly from source, without another Linux distro. The rest of the differences stem from here - we get more control over…

Do you see any significant changes in comparison to the "gcr.io/distroless/static" image, which is commonly used in Go ecosystem? Thanks for answer btw, really appreciate that.

Re: Wolfi: A community Linux OS designed for the container and cloud-native era

#17

Post by amouat »

iamstan23 wrote: post #10

Not sure an OS created to meet the specific need of VC funded startup, created exclusively by employees of that company should be called a "community Linux". It's almost the opposite of that in fact.

You're welcome to join the regular community meeting: https://github.com/wolfi-dev/community

We do fully intend for wolfi to be a community project, but it will take some time. We do say on the home page:

>What are the plans for long-term Wolfi governance? We intend for Wolfi to be a community-driven project, which means over time it will have multi-vendor governance and maintainers. For now we're focused on building the project and community, and will revisit this in several months when a community has formed.

Re: Wolfi: A community Linux OS designed for the container and cloud-native era

#18

Post by dlor »

iamstan23 wrote: post #10

Not sure an OS created to meet the specific need of VC funded startup, created exclusively by employees of that company should be called a "community Linux". It's almost the opposite of that in fact.

Totally understand the concern. We've tried to draw a very clear line between Wolfi (the project), and Chainguard Images (our product). They're in different GitHub organizations, have different maintainers, and are documented differently.

We (Chainguard) still represent most of the maintainers to Wolfi, but there are external folks too. We're going to need help scaling Wolfi to get it to where we want it to be, and that will require a real community.

We've also tried to be very clear on the business model for us, to avoid any "rug pulls" or "bait and switches" later. Here's some more context on that too: https://www.chainguard.dev/unchained/scaling-chainguard-imag...

Re: Wolfi: A community Linux OS designed for the container and cloud-native era

#20

Post by dlor »

aerfio wrote: post #16
dlor wrote: post #11

Earlier quoted context omitted.

I was (one of) the original creators of the Google Distroless project. The main difference is that Original Distroless uses Debian as the upstream. This is great in many ways, but makes it so stuff outside of Debian is hard to package in. Wolfi is its own upstream - packages are sourced and built directly from source, without another Linux distro. The rest of the differences stem from here - we get more control over…

Do you see any significant changes in comparison to the "gcr.io/distroless/static" image, which is commonly used in Go ecosystem? Thanks for answer btw, really appreciate that.

For static, not really just because there's so little in it. For apps that need CGO there's a benefit as more dependencies are required. CGO apps are broken right now IIUC in distroless/glibc-dynamic because of the Debian glibc bump.
Post reply on HN