11–20 of 58 posts
It really ought to lead with the license of each library. I was considering dietlibc until I got to the bottom - GPLv2. I am a GPL apologist and even I can appreciate that this is a nonstarter; even GNU's libc is only LGPL!
Fun libc comparison by the author of musl. My getaway is: glibc is bloated but fast. Quite unexpected combination. Am I right?
For example, Chimera Linux uses MUSL with mimalloc and it is quite snappy.
Earlier quoted context omitted.
In case of glibc I think what you said is orthogonal to its bloat. Yes, it has complex implementations but since they are for a good reason I'd hardly call them bloat. Independently from that glibc implements a lot of stuff that could be considered bloat: - Extensive internationalization support - Extensive backward compatibility - Support for numerous architectures and platforms - Comprehensive implementations of op…
Ok, fair points, although internationalization seems like a reasonable thing to include at first glance. Is there a fork of glibc that strips ancient or bizarre platforms?
Earlier quoted context omitted.
Ok, fair points, although internationalization seems like a reasonable thing to include at first glance. Is there a fork of glibc that strips ancient or bizarre platforms?
It's called glibc. Essentially all that "bloat" is conditionally compiled, if your target isn't an ancient or bizarre platform it won't get included in the runtime.
That’s not the strongest example. I just meant it to be illustrative of the idea.
Earlier quoted context omitted.
Ok, fair points, although internationalization seems like a reasonable thing to include at first glance. Is there a fork of glibc that strips ancient or bizarre platforms?
What problem are you trying to solve? glibc works just fine for most use cases. If you have some niche requirements, you have alternative libraries you can use (listed in the article). Forking glibc in the way you describe is literally pointless
My own perf comparison: when I switched from Fil-C running on my system’s libc (recent glibc) for yololand to my own build of musl, I got a 1-2% perf regression. My best guess is that it’s because glibc’s memcpy/memmove/memset are better. Couldn’t have been the allocator since Fil-C’s runtime has its own allocator.
Pretty obviously made by the musl authors.
Yeah, pretty obvious when they state as much in the first paragraph.