Musl libc is a more preferable option if security and speed are important to you, compared to glibc, but is this currently the case? Do most applications still not work on musl? And how effective is gcompat?
You must log in or register to comment.
This doesn’t answer your question, I’m sorry, but I will say Void is an endlessly fascinating project
Btw, is it possible to chroot into a glibc sub-distro from a musl distro?
I don’t recommend it because of the allocator but if you want to switch to musl, start by checking if the distro you will switch to has the software you need. Signal for example does not work. I have to use the flatpak.
Saying musl is preferable if speed is important is a bit…loaded. It’s not always untrue, but it often is.
As a libc, musl has a much smaller footprint than glibc, so a computer which is short on memory capacity, memory bandwidth, or cache size could absolutely see a performance benefit. The flipside to this is that a lot of the ‘bloat’ in glibc are performance tricks including lots of architecture specific code.
As others have mentioned, the malloc implementation is less than ideal and can slow down highly threaded & memory intensive applications.
I work on a musl-based embedded distribution for my day-job, and also quite like using it personally for arm boards and my old ThinkPad. I wouldn’t really use it for my workstation though.
As far as applications working with musl, it’s not uncommon to see glibc-specific code which would need to be patched out of some applications (systemd comes to mind).
Personally, i prefer a smaller general codebase with equal speed vs. a bigger one with specific hacks and workarounds.
But honestly, at this level maybe for critical things like a high-security server (Alpine).
My distro is based on MUSL. I seem to remember finding something that would not build on it but I do not recall what that is. In addition to the thousands of packages I am using, I have compiled hundreds of applications. Compatibility is very high.
Certainly it is clear the “most applications” work with MUSL.
That is, the source code does.
gcompat is when you want to run something that is already a binary that wants to call into Glibc. I try to avoid that so I cannot comment much.
There is the odd time I have had a binary built for Glibc that I could not avoid. For example, bootstrapping .NET or the version of vcpkg that the Ladybird browser uses in its build system. To be honest, in those cases, I just reach for Distrobox and drop into a distro that has Glibc natively, like Arch. Or I might use a RHEL Distrobox for a commercial binary meant to target that distro.
Clearly running a binary without one of the dependencies it was built against is a problem no matter what library you are taking about. But if we are just asking what works on MUSL, I would say almost everything.
Google Crashpad is used for crash reporting by some program, and it can’t be built with musl. It also does not build in FreeBSD, and I suspect it only works with glibc outside of Mac OS, Windows, and Android.
It works, but the memory allocator implementation is way too slower compared to glibc. This especially becomes a performance bottleneck if application does a lot of heap allocation/deallocation.
I think Musl is a better choice when you work on embedded, low-end devices, or statically linked/self-contained applications. For high performance workstation usage, I still prefer glibc.
The default allocator is very slow but it can be changed. Chimera Linux, for example, uses mimalloc which is very fast.
Gcompat is not very effective but most open source software works with minimal patching.
Chimera Linux uses musl libc, Void Linux has the option of musl libc, and of course Alpine uses musl libc.
Gentoo also offers it as an option. If you’re very bored and curious about what doesn’t work under specific versions of musl, you can peruse the Gentoo compatibility tracker bugs..
So, 6 MUSL bugs for all of Gentoo?
And three of them are the same just for different versions of MUSL. And reading the bug report, it seems like a commit has been created and is awaiting review.
If all that is true, we have our answer. MUSL works with everything.
Not quite. Those are trackers: lists of bugs. If you open one, you’ll see a list of individual package bugs that are blocking these ones—up to a couple of dozen unresolved in some cases. Still, it isn’t that long a list, and a lot of the packages are minor or obscure.
The list is definitely longer than that. I switched to musl overlay about three years ago and I couldn’t daily drive it. I guess the six comes from no one is using it.
It works. Go ahead, try it.
but is this currently the case
sorry, is what the case?
