4 ms·

From what glibc developers have told me, glibc supports a huge number of systems, and a lot of the "bloat" in glibc comes from supporting various architectures

by zxzax 5y ago

From what glibc developers have told me, glibc supports a huge number of systems, and a lot of the "bloat" in glibc comes from supporting various architectures and operating systems accumulated over the last 30 years. In general, code is not deposited in glibc at random, so somebody did see a good reason to do whatever it is at the time it was done. Musl is nice but it's not a strict replacement for glibc in all cases, and the musl developers seem to be pretty honest about that, for example here: https://wiki.musl-libc.org/functional-differences-from-glibc.html https://wiki.musl-libc.org/functional-differences-from-glibc... Also in my experience, the attack surface cannot be strictly reduced by removing features -- if users want a specific feature, they will just get it from something else, so at some point one needs to have code on the machine somewhere that does it.

therealjumbo 5y ago
ofubd8kc: Right, so straight and such superficial comparisons are wrong for this reason. Most of the glibc code isn't used for any given compilation. Similarly for systemd, most of the code is being compiled into binaries outside of systemd-init, for things like systemd-networkd. Whether or not systemd-networkd should just be a separate git repo is a good question, but it isn't really relevant. A similar question would be should glibc carry around support for these other systems? Similarly, for systemd-init, the comparison should be, the other init system + all the code for the init scripts + all the code for all the utilities that are called inside the init scripts not counting the program being started. You should be looking at the system as a whole, not just a part of it.