It doesn’t make the news cause it’s a hobby os that was made important when we decided the size of the container mattered most.
Glibc is also such a mess that it still does not compile with Clang, after _decades_, due to all the crazy GCC extensions they rely on. An attempt is cyclically started and then promptly aborted when some new crazy nonsense is found. For instance, last time I checked they not only used the completely insane folly that GCC nested functions are, but they also relied on GCC attributes so nasty that LLVM never bothered implemented them (like renaming functions at code generation). Using these extensions are not really necessary, and I've a strong suspicious it was more of an attempt by the GNU authors to prevent distributions to ever consider not using GCC as their main compiler.
Also how name resolution is implemented in Glibc means you can't really statically link with it. If you've ever noticed, most "statically linked executables" are not in fact statically linked, but require ld.so just for libc. There are good reasons to disallow statically linking libc, but this is not one of them. Especially since the only stable API on Linux is the kernel interface, so the only way to not have to worry about future Glibc breakage is to either link with Musl or live with the risk.
I work in Python; pretty much no extension packages have a pre-compiled Musl version so you end up spending a ton of time compiling things!
>Using Alpine can make Python Docker builds 50× slower
Musl is a dire mistake.
glibc shouldn’t be statically compiled in because it’s lgpl and so immediately infects your code if you do.
The zig linker is quite nice here because it lets you pick what glibc you want to be compatible with.
Do you know if that's mainly due to the inefficient malloc, or if there are other important performance bottlenecks?
glibc has been more wildly tested, and fixed what was not working, while musl choices were mostly ideological
I'm no subject matter expert, [but support seems to be coming soon?](https://gitlab.alpinelinux.org/alpine/tsc/-/issues/43#note_2...)
Looks like the patch isn't very long either, so hopefully it'll be fairly solid:
https://git.musl-libc.org/cgit/musl/commit/?id=51d4669fb9778...
Not using the same thing everyone uses forces developers to care about standards rather than to assume compatibility just because it is how the favorite implementation works. Same reason why it is a good thing that a popular browser that is not Chromium-based exists.
Also every headache I've had with musl libc is because glibc is insane, not because there is a problem with musl. It should be trivial to swap out your standard library, as that is the entire point of dynamic loading. Yet you cannot actually swap out the dynamic library that nearly every program on your system will need, because it's not actually a library.
I’d be more likely to use CoreOS as at least I can claim peer pressure, and potential layer savings.
Also some programming languages, you can’t really populate the app’s dependencies without a bunch of its dependencies. And the only way to split the difference means you have to memorize every file that gets created during the build/install process to be sure you don’t miss anything airlifting them from one container to another.
All of which amounts to me becoming the package manager. Which gets much less fun the more containers you have running in prod.
I generally respect the curation that alpine does. Not too old, not too bleeding edge.
You can attach a debugging container with your tools temporarily: https://kubernetes.io/docs/concepts/workloads/pods/ephemeral...
On a related topic, I don't use Ubuntu, Debian, Alpine, Arch, Gentoo, Rocky, Alma, Fedora, or {Free,Open,Net}BSD. I use CentOS 9 stream for most things: it's basically RHEL's kernel and it powers 100M's-1 B machines.
Your position might be sufficiently extreme that it warrants reconsidering.
Only the truly insane would be lashing out at Alpine just because of its use of musl.