Hacker News Reader

Comment by phamilton | Hacker News Reader

Ah, another tale that includes getting bit by static linking and alpine.

Maybe I've just had a bad sample size, but I just haven't experienced a big enough win by using alpine to justify the weird scenarios that come up on occasion.

The idea is nice. A small, stripped down container that will load quickly and have very few maintenance issues (due to basically zero dependencies). But my debian-slim images work well enough and when I do hit a problem there's more community around it and it's more straightforward to fix.

View on HN

People keep saying they need a light and fast distro - no systemd, no glibc - but it breaks a lot of other software. So, you need to be prepared to patch a lot of stuff, and build packages from source.

Personally, I would love more of them to consider FreeBSD. It's got all of those features, a linux compatibility layer if necessary, a more permissive license, etc. I'd just love to see a lot more developers helping over there.

Except you can't run FreeBSD in Kubernetes really. Or really anywhere besides in VMs in the Linux monoculture.

Moving to FreeBSD would require patching even more things.

> a more permissive license

I see this as a net disadvantage. The great insight of the GPL licences is forcing changes to be contributed back to the project, companies can't easily privatize a public effort.

And this makes GPL based software like Linux stronger, more popular, more community to help

I am concerned about the Linux/glibc monoculture, and its effect on the broader ecosystem.

Whatever breaks on Linux/musl, is also likely to break on other operating systems.

Whatever breaks loudly elsewhere, is also quite likely silently broken on Linux/glibc.

If our default response is to double down on barely patching it enough to limp along, no wonder it keeps breaking.

Most the issues with alpine Linux people face are down to package maintainers breaking backwards compatibility constantly. Package renames are a regular problem.

One thing I love about NixOS so far is that when they do a rename, they can print a deprecation warning every time you use the old name while evaluating your config. When I get a moment, I go through and fix them.

You could probably do something similar in a traditional distro by creating an alias package that prints a warning on install, but then you actually have to watch the install logs to see that.

Alpine has at least the following deficiencies:

DNS TCP resolution doesn't work (https://christoph.luppri.ch/fixing-dns-resolution-for-ruby-o...). It's a feature that it doesn't retry truncated lookups or obey the relevant RFCs (https://twitter.com/RichFelker/status/994629795551031296).

Alpine has a 128k stack size (https://ariadne.space/2021/06/25/understanding-thread-stack-...), while most other OSes have at least a 512k stack.

Just to be clear, I'm not blindly defending musl/Alpine, rather noting the detrimental effects of monoculture.

Quite often fixing a build or a package on another system or architecture is a matter of a 3-5 line diff, and I've contributed quite a few over the years. It usually boils down to an incorrect assumption by the author/maintainer, stuff like "#ifdef __linux__" (when what you actually mean is: "any UNIX-like system with X11"), or hardcoding CC=gcc (where CC=cc just works).

DNS TCP resolution has been fixed this year

https://www.theregister.com/2023/05/16/alpine_linux_318/

Thanks for letting me know!

Alpine is a trap! For a Python product, we tried to make it work for about a year before throwing our hands up and switching to a plain Ubuntu image. We’ve had no regrets.

Small Docker image or small binary size is this decade's canonical premature optimization.

Especially base images. The size of your own layers might be worth worrying about, but not the shared base that should only be stored once for arbitrarily many containers

Glibc is very good. They should get plaudits somewhere by someone occasionally.

Alpine is also based on MUSCL rather than glibc which generally has fewer well known CVEs which helps from a security standpoint.

Is that because it's got better security, or fewer eyes on it?

Both.

It's also much easier to set up debugging tools when necessary.

Reply on news.ycombinator.com