What is the comparison between using musl and traditional glibc?
Is there performance differences between the two?
I have been seeing musl used more and more in both Rust and Zig ecosystems lately.
Is there performance differences between the two?
I have been seeing musl used more and more in both Rust and Zig ecosystems lately.
"If it's a bug people rely on it's not a bug, it's a feature" Let me guess, he was thinking of the memcpy issue that broke flash. Or maybe something else. And I agree, nobody cares
The spec says that because it was the 70s and nobody had thought better of that or how things would work 30 yrs on, and going with it does not make sense.
And I feel the pain of this hardheadedness when any library deprecates an API when they didn't need. "Oh but it's cleaner now" Again, nobody cares
And it has so many weird quirks that you need to work around.
***
Static linking makes linking more painful, especially regarding global constructors (which are often needed for correctness or performance). This is not a musl-specific issue, but a lot of people are interested in both.
Just do your builds on the oldest supported system, and dynamic linking works just fine. You can relative-rpath your non-libc dependencies if they would be a pain to install, though think twice about libstdc++.
***
The major advantage of MUSL is that if you're writing a new OS, it's much easier to port.
> And it has so many weird quirks that you need to work around.
I was under the impression that musl stuck closely to the standard, and glibc frequently did its own thing, so 1. it's not musl that's quirky, 2. if you need to detect something, just detect glibc.
There are places where MUSL implements a broad set of GLIBC extensions in order to actually be useful. However, it does not indicate that in any way, and sometimes violates the conditions that GLIBC documents. This requires workarounds.
There are places where MUSL implements a standard interface in a particular way. If you're lucky, this "just" means giving up on performance if you don't know you're using MUSL.
Sometimes MUSL implements its own ABI-incompatible extensions. The time64 transition, for example, is a huge mess regardless, but musl provides no blessed way to figure out what's going on. The only reason it's not an even bigger disaster is that almost nobody uses musl.
you get weird bugs and failures that don't happen with glibc (like the incomplete dns resolving routines that would fail under some conditions) but you can brag about saving 30-40 mb of disk space.
this project seems to be compromising on quality overall, in the name of having smaller size.
Even BearSSL, by their own website is beta-quality: "Current version is 0.6. It is now considered beta-quality software" (from https://bearssl.org/).
I maintain a large codebase, widely deployed, cross compiled to many cpu architecures that's built atop musl. You're right that historically in the context of people blindly using alpine for their container base that sort of thing might be the case. The newest version of musl solves the thing you're describing and in general most of the complaints about malloc perf or otherwise have been addressed. Avoiding musl to me seems like an outdated trope, but there was a time wherein that take was valid indeed.
Would you accept that kind of reasoning for software running on your pacemaker, or on your insuline pump?
I think we should respect the developers here: they're not claiming production quality level (they're claiming beta-quality level) so it's not correct to use that library in any kind of product and claim any kind of production-level quality.
God helps me I wouldn't implant anything so fundamental in my body with hard dependencies on encrypted communication to a remote agent elsewhere, no matter the advantage.
https://github.com/kubernetes/kubernetes/blob/master/go.mod for one obvious example.
They eventually did fix this, as of musl 1.2.4.
There's some common FUD about rpath being insecure, but that only applies if the binary is setuid (or otherwise privileged) and the rpath is writable by someone other than the binary's owner (all relative rpaths are writable since you can use symlinks; absolute rpaths are writable if they point to /tmp/ or a similar directory, which used to be common on buildbots).
This is really not hard; working around all static linking's quirks is harder.
Global constructors no longer reliably fire unless you are extremely careful with your build system, nor do they run in a predictable order (e.g. you can call a library before it is actually initialized, unlike dynamic linking where only preinit - which nobody uses - is weird), nor can you defer them until dlopen time if you want (which is, admittedly, overdone).
It's possible to link to parts of multiple versions of a library (remember, you have to recurse into your dependencies), as opposed to dynamic libraries where at least you're guaranteed all-or-nothing (which is much easier to detect).
Linking is slower since it always has to be redone from scratch.
Not resilent against system changes. For example, old versions of `bash-static` (grab them from e.g. Debian snapshot and extract them manually; don't install them) are no longer runnable on modern systems since certain system files have changed formats, whereas the dynamically-linked `bash` packages still run just fine.
It also encourages bad stability habits, leading to the equivalent of NPM hell, which is far worse than DLL hell ever was.
You can't use LD_PRELOAD or other dynamic interception tools.
There are probably more reasons to avoid static linking, but I'm trying to ignore the handful from the popular lists.
I’m not sure it’s a great idea for an OS as in the OP, but I do like that they claim accurate incremental rebuilds, to ensure everything get updated. Certainly an interesting experiment!
Edit: just to clarify, I meant "app" as in "something that isn't part of the OS/distribution".
from my understanding glibc is not "religiously" against it, they're against it for technical reasons. In the sense, this is not a dogma. It's about internal details of their implementations.
See: https://stackoverflow.com/questions/57476533/why-is-statical...
[0]: https://neosmart.net/blog/a-high-performance-cross-platform-...
Edit:
Sorry, the correct link is this one: https://neosmart.net/blog/using-simd-acceleration-in-rust-to...
(Not that the codebase makes much string function usage.)
Looks like a "bug" or better put needed enhancement to LLVM.
https://opensource.stackexchange.com/questions/13588/how-sho...
https://wiki.musl-libc.org/functional-differences-from-glibc...