3 ms·
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
by 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 agoUntil 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 agoSure 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.
- ofubd8kc 5y ago> 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 $ wc `find src/core \( -name \*.c -o -name \*.h \) -print` [...] 81604 249802 3001043 total So 81,604 lines for src/core vs 17,263 for OpenRC. So why does systemd need 677,446 lines of C code in its entire tree if src/core is 81,604 lines? I suppose the answer is that IBM/Red Hat make money shipping systems that they and they alone have the expertise to support and fix. Making systemd's tree over 600k lines so that Red Hat employee Lennart is pretty much the only human being alive who understands it all is conducive to that goal.
- zxzax 5y ago> So 81,604 lines for src/core vs 17,263 for OpenRC. So why does systemd need 677,446 lines of C code in its entire tree if src/core is 81,604 lines? Do you want a real comprehensive answer to this? You can just skim through the code to systemd to see what it's doing. Just in my experience, systemd has a lot more features than openrc; you could also read their respective documentation to get a full picture of what they do differently. All the other additional lines are for other optional daemons. I have been using systemd in debian for years and nobody I know has needed to pay Red Hat. That's just not really how open source works at the distro level. To the contrary, I've seen a good number of debian users/developers contributing their expertise upstream to systemd, as well as fedora users, arch users, etc.