5 ms·

For many of us, our biggest beef with systemd is that it has no planned limitations to its scope. (This has already been discussed to death so I will try to be

For many of us, our biggest beef with systemd is that it has no planned limitations to its scope. (This has already been discussed to death so I will try to be brief.) Let's look at the actual current code size. I just cloned the systemd Github repo (git clone https://github.com/systemd/systemd.git https://github.com/systemd/systemd.git) and this is what I got: $ wc `find . $ -name \*.c -o -name \*.h $ -print` [ ... ] 37 89 1100 ./src/xdg-autostart-generator/xdg-autostart-service.h 677446 2077830 23953433 total (Simple wc includes blank lines and comment lines and we could be fancier but wc will do.) Now compare the same thing with OpenRC (git clone https://github.com/OpenRC/openrc https://github.com/OpenRC/openrc): $ wc `find . $ -name \*.c -o -name \*.h $ -print` [ ... ] 56 242 2209 ./src/rc/_usage.h 17263 53243 419162 total So 677,446 lines vs. 17,263 lines. Lennart just keeps adding to systemd and refuses to say when he will finally stop adding to it. How many skilled humans on this planet are available to audit those 600k+ lines of systemd code and are actually auditing it? (And how many work for intelligence agencies?)

ratorx 5y ago
Maybe your argument still holds, but this is a misleading comparison. The systemd repository contains a lot more than just an init system (e.g. systemd-networkd, which is an optional network manager). The appropriate comparison would be for the systemd the init system vs OpenRC.
- ofubd8kc 5y ago
  Why does systemd need an optional network manager? Will this optional network manager become non-optional in the future?
  - zxzax 5y ago
    It doesn't need it, I think it was just something that was interesting to have. I have not seen anyone saying there were any plans to make it non-optional, and that would probably not make sense to do that, because there are a lot of other network daemons that people use with systemd.
  - ratorx 5y ago
    I presume because they are using a mono-repo for all the related projects. A GitHub repository doesn’t have to map to exactly one output. Just because the code is in an adjacent folder doesn’t mean that it’s used in all the targets. If it became non-optional, then sure you can include the LOC then.
zxzax 5y ago
Most of the new features are being done in separate daemons from the init. The lines of code relevant to only the init are in src/core, so your comparison would probably only make sense if you compared that folder. >Lennart just keeps adding to systemd and refuses to say when he will finally stop adding to it. I'm not sure I understand, most projects only stop adding code when development is done. So the answer would probably be "when people stop using it." Are you a distro maintainer? If you want a stable version with fixes backported, you can use this: https://github.com/systemd/systemd-stable https://github.com/systemd/systemd-stable >How many skilled humans on this planet are available to audit those 600k+ lines of systemd code and are actually auditing it? (And how many work for intelligence agencies?) I'm not sure I understand this either, are you asking how many C programmers there are in the world that are able to perform code review on a C program for Linux, like systemd? And what subset of those C programmers work for intelligence agencies? It might be worth answering those questions, but I'm not sure how that is related to systemd specifically. If you look at the systemd github (or the github for any other big C program), you will see a good number of people already publicly reviewing patches, so you could get started there.
- ofubd8kc 5y ago
  Until formal verification becomes common, something the size of systemd is always going to have security bugs that intelligence agencies will know about before the rest of us. If you don't want North Koreans hacking your server you would do better to opt for non-systemd.
  - zxzax 5y ago
    Sure some people might know about bugs before others, and may seek to abuse that knowledge, but I don't think that is limited to intelligence agencies, and I don't think that has anything to do with the size of the project either. If you have some studies and data that goes over all the risk factors here, I'd love to see it. >If you don't want North Koreans hacking your server you would do better to opt for non-systemd. This seems to be fear-mongering and doesn't seem to follow at all from what you said either. There are a lot of other large projects used by the various Linux distributions, systemd is not out of the ordinary here. For an example of what you're looking at here, debian bullseye has 1.17 billion lines of code in total: https://sources.debian.org/stats/ https://sources.debian.org/stats/ Of course you would have to do a deeper dive to see just how much of that is expected to run as root or with CAP_SYS_ADMIN, or in kernelspace.

ratorx 5y ago

Maybe your argument still holds, but this is a misleading comparison. The systemd repository contains a lot more than just an init system (e.g. systemd-networkd, which is an optional network manager). The appropriate comparison would be for the systemd the init system vs OpenRC.

ofubd8kc 5y ago
Why does systemd need an optional network manager? Will this optional network manager become non-optional in the future?
- zxzax 5y ago
  It doesn't need it, I think it was just something that was interesting to have. I have not seen anyone saying there were any plans to make it non-optional, and that would probably not make sense to do that, because there are a lot of other network daemons that people use with systemd.
- ratorx 5y ago
  I presume because they are using a mono-repo for all the related projects. A GitHub repository doesn’t have to map to exactly one output. Just because the code is in an adjacent folder doesn’t mean that it’s used in all the targets. If it became non-optional, then sure you can include the LOC then.

zxzax 5y ago

Most of the new features are being done in separate daemons from the init. The lines of code relevant to only the init are in src/core, so your comparison would probably only make sense if you compared that folder. >Lennart just keeps adding to systemd and refuses to say when he will finally stop adding to it. I'm not sure I understand, most projects only stop adding code when development is done. So the answer would probably be "when people stop using it." Are you a distro maintainer? If you want a stable version with fixes backported, you can use this: https://github.com/systemd/systemd-stable https://github.com/systemd/systemd-stable >How many skilled humans on this planet are available to audit those 600k+ lines of systemd code and are actually auditing it? (And how many work for intelligence agencies?) I'm not sure I understand this either, are you asking how many C programmers there are in the world that are able to perform code review on a C program for Linux, like systemd? And what subset of those C programmers work for intelligence agencies? It might be worth answering those questions, but I'm not sure how that is related to systemd specifically. If you look at the systemd github (or the github for any other big C program), you will see a good number of people already publicly reviewing patches, so you could get started there.

ofubd8kc 5y ago
Until formal verification becomes common, something the size of systemd is always going to have security bugs that intelligence agencies will know about before the rest of us. If you don't want North Koreans hacking your server you would do better to opt for non-systemd.
- zxzax 5y ago
  Sure some people might know about bugs before others, and may seek to abuse that knowledge, but I don't think that is limited to intelligence agencies, and I don't think that has anything to do with the size of the project either. If you have some studies and data that goes over all the risk factors here, I'd love to see it. >If you don't want North Koreans hacking your server you would do better to opt for non-systemd. This seems to be fear-mongering and doesn't seem to follow at all from what you said either. There are a lot of other large projects used by the various Linux distributions, systemd is not out of the ordinary here. For an example of what you're looking at here, debian bullseye has 1.17 billion lines of code in total: https://sources.debian.org/stats/ https://sources.debian.org/stats/ Of course you would have to do a deeper dive to see just how much of that is expected to run as root or with CAP_SYS_ADMIN, or in kernelspace.