3 ms·
> If this had been an older GNU utility, the dependencies likely would have been libterm and libc. Yes, but then you are stuck with glibc + kitchen sink and GN
by nibbleshifter 4y ago
> If this had been an older GNU utility, the dependencies likely would have been libterm and libc.
Yes, but then you are stuck with glibc + kitchen sink and GNU code quality, which is atrocious.
- saagarjha 4y agoAtrocious but exceptionally battle-tested?
- nibbleshifter 4y agoIt was the best option a long while ago, and basically resulted in a kind of vendor lock in of sorts. Musl is far superior as a libc, but most Linux software is written for glibc and has quirks that make porting hard.
- saagarjha 4y ago> Musl is far superior as a libc Nope. It’s better at some things but with so many caveats that this is just dumb to claim.
- alerighi 4y agoMusl is liked since it has a non-copyleft license and thus can be used to produce statically-linked executable that are distributed with proprietary licenses. Also Musl is smaller than GLibc thus more suitable for embedded systems. Anyway, GLibc is just better, both in terms of performance (algorithms are more optimized, at the cost of a bigger executable size) and in terms of available features.
- enriquto 4y ago> Musl is liked since it has a non-copyleft license Not only for that. As much as I love copyleft, I'm really happy that musl exists so that I can easily test my programs locally for portability. Compiling stuff with different compilers and libraries exposes at once all sorts of weird bugs before you get to publish your codes.