5 ms·

I compared systemd vs. OpenRC code size in another post, but here is Musl vs glibc code size: $ git clone git://git.musl-libc.org/musl; cd musl $ wc `find

I compared systemd vs. OpenRC code size in another post, but here is Musl vs glibc code size: $ git clone git://git.musl-libc.org/musl; cd musl $ wc `find . $ -name \*.c -o -name \*.h $ -print` [...] 7 11 94 ./src/unistd/_exit.c 104637 330017 2883975 total $ git clone https://sourceware.org/git/glibc.git; cd glibc $ wc `find . $ -name \*.c -o -name \*.h $ -print` [...] 49 216 1647 ./wctype/wctype_l.c 1389414 6823487 52867225 total So 104,637 lines vs 1,389,414 lines. There are more human programmers on this planet who can audit 104,637 lines than can audit 1,389,414 lines. What is glibc doing that is so terribly useful that it needs to be 13 times the size of Musl? It's just standard GNU bloat. And why does GNU awk (gawk) need to add network socket programming support? Isn't this beyond the scope of what awk does well and does best? Keep adding features, keep increasing the attack surface....

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.
therealjumbo 5y ago
Do you think a manual audit of 100k lines of code will uncover multi-threading or memory issues or any other security issue? Experience has shown that for c code for the first two, no it won't. And for any language code, manual audits won't find issues in the last category either. It may help, but it won't excise them all (or even close to all). To get them out, you need real world testing. The system that sees more real world usage, probably gets more testing. Any security analysis would want to take this into account also. My earlier point about "what do you want to get out of your systems" is that you alluded to the reliability of debian being desirable. Distro maintainers by and large switched to systemd since it saved them a ton of work. They could then spend that extra time on the rest of the activities of being a distribution. So debian could focus on being more debian-like instead of debian-like + maintaining a creaky init system. So if what you want is debian, and you see very few distros like it that also don't have systemd, think about why and if what you're asking is detrimental to the other goal of what you want. FWIW, I've maintained embedded linux distros at a couple companies, at my most previous employer we used systemd, the current one we don't. It isn't the right choice in all scenarios, but it is a lot of the time.

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.

therealjumbo 5y ago

Do you think a manual audit of 100k lines of code will uncover multi-threading or memory issues or any other security issue? Experience has shown that for c code for the first two, no it won't. And for any language code, manual audits won't find issues in the last category either. It may help, but it won't excise them all (or even close to all). To get them out, you need real world testing. The system that sees more real world usage, probably gets more testing. Any security analysis would want to take this into account also. My earlier point about "what do you want to get out of your systems" is that you alluded to the reliability of debian being desirable. Distro maintainers by and large switched to systemd since it saved them a ton of work. They could then spend that extra time on the rest of the activities of being a distribution. So debian could focus on being more debian-like instead of debian-like + maintaining a creaky init system. So if what you want is debian, and you see very few distros like it that also don't have systemd, think about why and if what you're asking is detrimental to the other goal of what you want. FWIW, I've maintained embedded linux distros at a couple companies, at my most previous employer we used systemd, the current one we don't. It isn't the right choice in all scenarios, but it is a lot of the time.