Live data from Hacker News

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

github.com

61–70 of 89 posts

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

#61

They could've just improved Alpine's supply chain (or built on top of it) rather than making a new distro :( But they're a company, so pushing out new products faster is more important than the community.

We work with much of the Alpine community and some of the maintainers. The glibc choice instead of musl alone means that a separate toolchain and distro is required, but there are also a lot of other distinctions.

We still work with them upstream on apk and apk-tools, and would be happy to collaborate on more tooling.

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

#62
post #53
post #52

I've attended a local CNCF meetup where the chainguard folks presented Wolfi and their related tools to create container images and SBOMs. I was already skeptical of the product, having heard of it before. Unfortunately, attending that talk confirmed to me that they've just re-invented a severely limited version of Nix powered by yaml files that can output SBOMs in a standard format. Their software repository only ha…

We're rapidly approaching 10k packages, here's today's count: / # apk update fetch https://packages.wolfi.dev/os/aarch64/APKINDEX.tar.gz [ https://packages.wolfi.dev/os ] OK: 9494 distinct packages available We're definitely coming at this from a different angle from Nix, but the approaches are pretty complementary. I'm a big fan of all the work they do. musl vs. glibc is one of the big departures we make from Alpine…

Hey, thanks for chiming in. How do they complement each other?

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

#63
post #60
post #56

Earlier quoted context omitted.

> OK: 9494 distinct packages available I opened that apkindex file and it had duplicate entries for a ton of packages with different versions, taking a look at https://github.com/wolfi-dev/os I only see about 840 yaml files which I assume define the packages. I don't think claiming to have 10k packages when only 10% of them are actually different pieces of software is a good claim to make. Nixpkgs would have millions…

I think it's more subpackages such as -dev, -lib and -doc variants. These are defined as part of the parent package but count as distinct packages.

Even so, I did a quick search on repology and Nix derivations with multiple outputs (the nix lingo analogous to the subpackages you mentioned) are counted as a single package. For example, bash has 5 outputs but only counts for 1 package in the 85k figure, so I think comparing 900 packages to 85k is a valid comparison.

Anyway, this is all besides the point I was trying to make which is that I don't see why I should use _yet another_ software distribution that has 1% of the amount of packages found in a mature distribution that already has frequent automatic updates and bleeding-edge software revisions.

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

#64
post #57

Before reading the linked page, I thought this was about a Linux distribution optimized to run both local but containerized applications and remote/cloud web applications, kind of a ChromeOS like distribution with the same focus on simplicity and security, but with an addition local execution approach based on containers, and less tied to Google. So, this is not at all this, but now I wonder if a distribution like th…

Sounds like you're looking for the CoreOS Linux successor FlatCar https://www.flatcar.org/

It's actually based on some ChromeOS update tools under the hood but is a regular Linux distro, just super minimal and designed to run containers.

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

#65
post #52

I've attended a local CNCF meetup where the chainguard folks presented Wolfi and their related tools to create container images and SBOMs. I was already skeptical of the product, having heard of it before. Unfortunately, attending that talk confirmed to me that they've just re-invented a severely limited version of Nix powered by yaml files that can output SBOMs in a standard format. Their software repository only ha…

Can anyone help me understand musl libc and DNS issues? Note that I’m most interested in this “DNS over TCP” issue, since the other case I’ve heard of is for custom DNS setup—not for resolving host names in a default configuration.

My reading indicates that DNS resolution simply might not work in certain cases. This seems like a huge problem, yet Alpine Linux is widely deployed and I think Zig uses musl libc as well. In fact , every fully static binary I’ve seen (except for Go?) relies on musl.

For what it’s worth, I’ve seen DNS errors on Alpine (specifically I was getting EAGAIN), but I assumed this was unrelated to musl (and am still unsure). In general, I feel like I see a lot more transient networking errors on Alpine, and I wonder if this is related.

Edit: I also didn’t think DNS would be in libc, so I’ve got a lot to learn…

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

#66
post #52

I've attended a local CNCF meetup where the chainguard folks presented Wolfi and their related tools to create container images and SBOMs. I was already skeptical of the product, having heard of it before. Unfortunately, attending that talk confirmed to me that they've just re-invented a severely limited version of Nix powered by yaml files that can output SBOMs in a standard format. Their software repository only ha…

As mentioned correctly in [2], DNS issues with musl stem from the fact that it follows the DNS specs strictly and exposed bugs in certain DNS servers.

For an HTTP server replying with 200 OK instead of an 404 Not Found upon ENOENT, the situation is clear that this is not a client-side bug. The same should be assumed of DNS/NXDOMAIN.

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

#67
post #57

Before reading the linked page, I thought this was about a Linux distribution optimized to run both local but containerized applications and remote/cloud web applications, kind of a ChromeOS like distribution with the same focus on simplicity and security, but with an addition local execution approach based on containers, and less tied to Google. So, this is not at all this, but now I wonder if a distribution like th…

VMware's PhotonOS is designed for use as a stripped-down container host. It's pretty good, and they're open to community contributions too.

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

#68
post #52

I've attended a local CNCF meetup where the chainguard folks presented Wolfi and their related tools to create container images and SBOMs. I was already skeptical of the product, having heard of it before. Unfortunately, attending that talk confirmed to me that they've just re-invented a severely limited version of Nix powered by yaml files that can output SBOMs in a standard format. Their software repository only ha…

Can anyone help me understand musl libc and DNS issues? Note that I’m most interested in this “DNS over TCP” issue, since the other case I’ve heard of is for custom DNS setup—not for resolving host names in a default configuration . My reading indicates that DNS resolution simply might not work in certain cases. This seems like a huge problem, yet Alpine Linux is widely deployed and I think Zig uses musl libc as well…

It sounds like DNS-over-TCP should be supported now: https://wiki.musl-libc.org/functional-differences-from-glibc...

Edit: Hacker News link from last month:

https://news.ycombinator.com/item?id=35964717

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

#69
post #52

I've attended a local CNCF meetup where the chainguard folks presented Wolfi and their related tools to create container images and SBOMs. I was already skeptical of the product, having heard of it before. Unfortunately, attending that talk confirmed to me that they've just re-invented a severely limited version of Nix powered by yaml files that can output SBOMs in a standard format. Their software repository only ha…

As mentioned correctly in [2], DNS issues with musl stem from the fact that it follows the DNS specs strictly and exposed bugs in certain DNS servers. For an HTTP server replying with 200 OK instead of an 404 Not Found upon ENOENT, the situation is clear that this is not a client-side bug. The same should be assumed of DNS/NXDOMAIN.

As much as I agree with your reasoning, I have experienced this kind of breakage first-hand due to cloudflare and DNSSEC and will continue using DNS resolving code that doesn't cause me pain and suffering (anything that isn't musl) because making this work with musl is quite literally out of my control.

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

#70
post #52

I've attended a local CNCF meetup where the chainguard folks presented Wolfi and their related tools to create container images and SBOMs. I was already skeptical of the product, having heard of it before. Unfortunately, attending that talk confirmed to me that they've just re-invented a severely limited version of Nix powered by yaml files that can output SBOMs in a standard format. Their software repository only ha…

Can anyone help me understand musl libc and DNS issues? Note that I’m most interested in this “DNS over TCP” issue, since the other case I’ve heard of is for custom DNS setup—not for resolving host names in a default configuration . My reading indicates that DNS resolution simply might not work in certain cases. This seems like a huge problem, yet Alpine Linux is widely deployed and I think Zig uses musl libc as well…

If you use Musl 1.2.4+ (or Alpine 3.18+), there are no longer the same DNS fallback issues: https://www.openwall.com/lists/musl/2023/05/02/1

To summarize the issue: DNS is done optimistically over UDP because it's faster, but this doesn't work when DNS responses are large because of the design of UDP. TCP should be used as a fallback mechanism when responses are large. This is uncommon normally, but increasingly DNS responses are large in special scenarios; for instance when you're querying an internal DNS for service discovery (read: k8s or nomad deployments, most commonly).

Musl's maintainer interpreted the spec for a libc's resolver to not require TCP fallback (source: https://twitter.com/RichFelker/status/994629795551031296?lan...), so for a long time Musl simply didn't support this feature, justifying it as better UX because of the more predictable performance.

I don't agree with the maintainer on this interpretation, but I am glad the feature was added and the issue is no longer a concern as an otherwise very happy Alpine user!

Post reply on HN