31 ms·

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 th

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)*.
    - thegeekpirate 11y ago
      fwiw, this post has a good list of all the binaries included in the systemd project, and their reliance on PID1 or the systemd (systemd-init) binary (as they use the API). https://news.ycombinator.com/item?id=9517040 https://news.ycombinator.com/item?id=9517040

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)*.
  - thegeekpirate 11y ago
    fwiw, this post has a good list of all the binaries included in the systemd project, and their reliance on PID1 or the systemd (systemd-init) binary (as they use the API). https://news.ycombinator.com/item?id=9517040 https://news.ycombinator.com/item?id=9517040