4 ms·

I do not need to point at a specific security hole to prove the statement "more complex code is more susceptible to bugs".

deleted 11y ago
[deleted]
- Karunamon 11y ago
  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.
        11y ago
- dang 11y ago
  Your comments are breaking the HN guidelines both by being needlessly abrasive and by going on about downvoting in a way you're explicitly asked not to. Please reread the guidelines and follow them. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
  - chris_wot 11y ago
    Sorry about that.

deleted 11y ago

[deleted]

Karunamon 11y ago
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.
        11y ago
dang 11y ago
Your comments are breaking the HN guidelines both by being needlessly abrasive and by going on about downvoting in a way you're explicitly asked not to. Please reread the guidelines and follow them. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- chris_wot 11y ago
  Sorry about that.