It's funny what different people find interesting in Alpine. I started using it expressly because it uses musl. Void is a distro with similar principles that offers a glibc version, so I use that when I need GNU.

Don't get me wrong - musl is amazing, but I need CUDA on desktop and I can't get that with musl.

What's the benefit of musl that you don't get with glibc?

musl is statically linked, so each binary can update at their own leisure. There are no system-wide libc updates to break anything.

How much space is added to each app to include the needed parts of app-level libc?

I don't know, but for statically linked glibc, it adds a couple megabytes to each binary that uses it. That may or may not be great if you're concerned about cache optimization, which is one big reason why dynamic linking is still so popular.

Yep. There's a reason why macOS and iOS have a giant (easily 1GB) "shared cache" that is most of the libraries that make up the OS in a giant file, mapped into every process's address space.

Without shared linking, in your example you end up with a copy of glibc and whatever else in every process. Without some fancy page deduplication scheme (that would come with its own set of problems), the kernel cannot know that all these pages in all these processes are the same. And they might not even be, because different versions and just the process of static linking itself might make an arbitrary number of them look slightly different.

Not every program needs all of glibc, so not all of it will be paged in, but still, it looks like you will pollute your CPU caches with many copies of essentially the same thing.

I'd love to see some instrumentation demonstrating this. I've never been able to find any evidence whatsoever that it's the case. It makes sense intuitively but I yearn for proof.

Yeah, totally fair. I mean it's relatively hard for me to conclude otherwise, but stuff is super complex, you never know. If not anything else, after all you can do link time optimization on the actual whole program, including its libraries. But whether that offsets it...

I thought about whether there was some quick evidence already, but nothing comes to mind (maybe someone's less blind to it than me now).

Maybe you could take some self-building Linux distribution like Gentoo, and hack it such that it links everything statically? Compare that against an equivalent unhacked Gentoo-installation by doing a few tasks, measuring wall clock for a good first estimate?

No idea how hard that would be in practice, especially with people mentioning that glibc does not really support that. So maybe it's actually easier with one of the BSDs, e.g. OpenBSD, which is also feasible to build completely from source because it is very self-contained, depending on how that stomachs static linking for everything.

I'd also not do it in a VM. While that's not necessarily completely invalid, it does seem to skew things pretty significantly, what with at least one whole other OS running as the hypervisor and all that.

glibc doesn't actually support statically linking. (You can force it, but it breaks things.)

I'ts trivial. Only the functions needed are built into the binary.

I'm given to understand that musl tends to use less memory and disk, at the expense of being slower to execute. (YMMV on all counts)

What problems did you encounter? I installed Alpine on some laptops for desktop use and never had a problem except with one HP small netbook where the energy management seems broken as the kernel rewrites somewhere the screen backlight value with a value of 4 (= almost invisible) as soon as I pull the DC plug but doesn't update it when I plug it back. This also happens with ACPI and all power management uninstalled, so I sorta solved this by installing ACPI and making scripts to echo the right value back. This problem aside, I could install a lot of non trivial things, including for example WINE and Yabridge to use music plugins. Unless the system pulled them unbeknownst to me, I made no use of flatpaks and the like. The more I use Alpine, the more I like it.

> What problems did you encounter?

I personally found it difficult to get Nvidia drivers & Steam working. The latter worked with flatpaks, but Nvidia is always annoying.

Yes. You may laugh at me for trying to use Linux on a computer that was not built for it.

One of my favorite quotes, no idea about the author or the date, is "discoveries are made by not following instructions". Laughing because you're trying to get more from a machine that is built to give less would be really stupid; that is actually clever and admirable, and when one succeeds it gives extreme satisfaction. As for Nvidia drivers I can't help because my last experience with their cards is quite old, possibly older than the Nouveau drivers, but keep trying; it couldn't be a Alpine Linux failure as Nvidia, according to a famous Linus Torvalds quote, has already been less than friendly to Linux developers in the past.

And yet NVidia have the only graphics cards with working 3D acceleration and GPU compute capabilities.

Not true. It's just that AMD reserves those capabilities for the expensive server cards whereas Nvidia allows regular desktop gaming cards to do everything.

I bought a barebones PC specifically for my linux work station. One criteria from the outset was no NVIDIA.

Can't have CUDA without nvidia, and can't have nvidia without glibc