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.
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).
Do you guys use the stock allocator?
Using mimalloc instead seems to work pretty well.
It does, I quite like mimalloc though I prefer to have programs compiled with their custom allocator rather than inserting them via LD_PRELOAD as I’ve found some issues when using it with programs like Firefox.
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).
The line between what is a hack and what is basic performance optimisation is both subject to taste and use-case. Horses for courses, right?
This doesn’t answer your question, I’m sorry, but I will say Void is an endlessly fascinating project
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.
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.
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.
Ah. Thanks.
Gcompat is not very effective but most open source software works with minimal patching.
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.
Btw, is it possible to chroot into a glibc sub-distro from a musl distro?
Yes
But I would just use Distrobox if you want to do that.
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.
musl is very cool and has very specific use cases. workstations are not one of them. you won’t be able to install drivers for gpus for example.
It works. Go ahead, try it.
but is this currently the case
sorry, is what the case?
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.
I don’t use Google Crashpad but when did you last try it.
I just read a bug report that says it fixed building on MUSL in 2023. The fix was to comment out a reference to user_vfp in thread_info.h and to put the change in an #ifdef.
I assume this is in the mainline by now.
I think it was around the same time when I disabled it altogether in the Makefiles of some software. Let’s hope it’s upstream now.
