3 ms·

Apparently, we're speaking Lojban here, not English, so therefore I'm not allowed to use figures of speech as they may be evaluated pedantically by those who wi

Apparently, we're speaking Lojban here, not English, so therefore I'm not allowed to use figures of speech as they may be evaluated pedantically by those who wish to win an argument in bad faith. But fine, you wanted numbers. First, systemd's LoC count is 699,342 across 1,912 files as of a git clone of their SCM[1] and gitstats five minutes ago. That number was around 550,000 back in May[2], so kindly update your knowledge before regurgitating it mindlessly. Debian's (sid) sysvinit package[3], by the same methodology, is 32,151 lines across 235 files. Systemd is therefore about 22x (21.75179621162639) more complicated than sysv. I'd go run the numbers for Upstart, but I'm not going to go download bzr and appropriate profiling tool to conclusively prove something that's common knowledge to anyone not in an internet argument. And kindly stop complaining about downvotes - it's against the site rules. [1]:http://anongit.freedesktop.org/git/systemd/systemd.git http://anongit.freedesktop.org/git/systemd/systemd.git [2]:http://www.phoronix.com/scan.php?page=news_item&px=MTY5NjM http://www.phoronix.com/scan.php?page=news_item&px=MTY5NjM [3]:https://anonscm.debian.org/git/collab-maint/sysvinit.git https://anonscm.debian.org/git/collab-maint/sysvinit.git

deleted 11y ago
[deleted]
thegeekpirate 11y ago
To be fair, the numbers you're stating are for the entire systemd package, which is like comparing the entire Qt library to a single application. Single out the init management portion of systemd (and journald since it's a dependency), and compare those numbers. Everything else is an optional module.
- Karunamon 11y ago
  I don't think that's a fair comparison really - one of the main complaints against systemd is that it's taking on too many tasks, init plus NTP, cron, etc etc. Those modules are superficially optional, but in reality, a great deal of them will be turned on in any distro using systemd. The init system should be an init system and nothing else, IMO, so targeting all that extra complexity (which was my original point) is fair game.
  - thegeekpirate 11y ago
    That's just it though—each task is a completely separate application. You're comparing all of these applications (one of which is an init system) to just an init system (sysvinit). Whether a distribution chooses to include timesyncd or another ntpd doesn't magically make timesyncd an init system. If sysvinit also included an ntpd client, _then_ it would be appropriate to include that module as well for a fair comparison of SLOC. Another example would be to take vim, counting the SLOC including a bunch of downloaded plugins, _then_ comparing that number against emacs without any plugins. It's comparing apples to apples and oranges simply because they're in the same basket.
    - Karunamon 11y ago
      Those "separate applications" are still tightly coupled to the main, and therefore they share the complexity/attack surface concerns. If your system gets pwned, does it matter to the user if it was via the "systemd" binary itself or by one of the official "systemd-somethingd" binaries (that have no other purpose other than interoperation with the main app, developed by the same people) that come with every OS using it? Had the distro maintainers not shoveled an extra ~670,000LoC down their throat, they wouldn't have been pwned. If systemd wants to replace my freaking cron, DNS, ntp, and logging daemons, and the majority of in-production deployments use the application like that, I will be evaluating the application's complexity against how it's used in the real world. sysvinit doesn't attempt to replace resolvconf, ntpd, crond, and syslog-ng. systemd does.
      - thegeekpirate 11y ago
        > Those "separate applications" are still tightly coupled to the main, and therefore they share the complexity/attack surface concerns. They have no access to systemd-init, only to an API presented by it (as does every other application if they so choose to use it), and thus this statement is incorrect. A bug in one of those applications cannot magically get access to systemd-init (which I'm assuming is what you meant by "main" here). > If your system gets pwned, does it matter to the user if it was via the "systemd" binary itself or by one of the official "systemd-somethingd" binaries (that have no other purpose other than interoperation with the main app, developed by the same people) that come with every OS using it? Had the distro maintainers not shoveled an extra ~670,000LoC down their throat, they wouldn't have been pwned. It absolutely matters! A bug in systemd-init can do much more damage than a bug in timesyncd could. Also, I really don't care about your anger towards an open source project, please refrain from expressing it to me if you'd like to continue this conversation. > If systemd wants to replace my freaking cron, DNS, ntp, and logging daemons, and the majority of in-production deployments use the application like that, I will be evaluating the application's complexity against how it's used in the real world. You may want to create a separate post somewhere which compares the SLOC of all the applications systemd attempts to re-create (choosing perhaps the most popular from each) along with the complete systemd package, but I personally wouldn't have any interest in it since it would be a factually correct comparison. > sysvinit doesn't attempt to replace resolvconf, ntpd, crond, and syslog-ng. systemd does. That's exactly right, but systemd-init doesn't attempt to replace those either (besides syslog-ng (journald), which I already mentioned as being fair to include with the SLOC count)*.

deleted 11y ago

[deleted]

thegeekpirate 11y ago

To be fair, the numbers you're stating are for the entire systemd package, which is like comparing the entire Qt library to a single application. Single out the init management portion of systemd (and journald since it's a dependency), and compare those numbers. Everything else is an optional module.

Karunamon 11y ago
I don't think that's a fair comparison really - one of the main complaints against systemd is that it's taking on too many tasks, init plus NTP, cron, etc etc. Those modules are superficially optional, but in reality, a great deal of them will be turned on in any distro using systemd. The init system should be an init system and nothing else, IMO, so targeting all that extra complexity (which was my original point) is fair game.
- thegeekpirate 11y ago
  That's just it though—each task is a completely separate application. You're comparing all of these applications (one of which is an init system) to just an init system (sysvinit). Whether a distribution chooses to include timesyncd or another ntpd doesn't magically make timesyncd an init system. If sysvinit also included an ntpd client, _then_ it would be appropriate to include that module as well for a fair comparison of SLOC. Another example would be to take vim, counting the SLOC including a bunch of downloaded plugins, _then_ comparing that number against emacs without any plugins. It's comparing apples to apples and oranges simply because they're in the same basket.
  - Karunamon 11y ago
    Those "separate applications" are still tightly coupled to the main, and therefore they share the complexity/attack surface concerns. If your system gets pwned, does it matter to the user if it was via the "systemd" binary itself or by one of the official "systemd-somethingd" binaries (that have no other purpose other than interoperation with the main app, developed by the same people) that come with every OS using it? Had the distro maintainers not shoveled an extra ~670,000LoC down their throat, they wouldn't have been pwned. If systemd wants to replace my freaking cron, DNS, ntp, and logging daemons, and the majority of in-production deployments use the application like that, I will be evaluating the application's complexity against how it's used in the real world. sysvinit doesn't attempt to replace resolvconf, ntpd, crond, and syslog-ng. systemd does.
    - thegeekpirate 11y ago
      > Those "separate applications" are still tightly coupled to the main, and therefore they share the complexity/attack surface concerns. They have no access to systemd-init, only to an API presented by it (as does every other application if they so choose to use it), and thus this statement is incorrect. A bug in one of those applications cannot magically get access to systemd-init (which I'm assuming is what you meant by "main" here). > If your system gets pwned, does it matter to the user if it was via the "systemd" binary itself or by one of the official "systemd-somethingd" binaries (that have no other purpose other than interoperation with the main app, developed by the same people) that come with every OS using it? Had the distro maintainers not shoveled an extra ~670,000LoC down their throat, they wouldn't have been pwned. It absolutely matters! A bug in systemd-init can do much more damage than a bug in timesyncd could. Also, I really don't care about your anger towards an open source project, please refrain from expressing it to me if you'd like to continue this conversation. > If systemd wants to replace my freaking cron, DNS, ntp, and logging daemons, and the majority of in-production deployments use the application like that, I will be evaluating the application's complexity against how it's used in the real world. You may want to create a separate post somewhere which compares the SLOC of all the applications systemd attempts to re-create (choosing perhaps the most popular from each) along with the complete systemd package, but I personally wouldn't have any interest in it since it would be a factually correct comparison. > sysvinit doesn't attempt to replace resolvconf, ntpd, crond, and syslog-ng. systemd does. That's exactly right, but systemd-init doesn't attempt to replace those either (besides syslog-ng (journald), which I already mentioned as being fair to include with the SLOC count)*.