5 ms·

500k in systemd itself, or inclusive of all the systemd-something pieces which, when debating with most, are part of it when convenient and separate when not?

• deleted 11y ago
  [deleted]
  • Karunamon 11y ago
    I wasn't aware it was in question a more complicated system is more difficult to throughly audit, and therefore more likely to have bugs, security bugs being a subclass of bug? Unless the systemd devs are immune to the same problems that plague literally every other software developer
    • deleted 11y ago
      [deleted]
      • Karunamon 11y ago
        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.
          • 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.
      • simoncion 11y ago
        > It's not immensely more complicated... Anything that requires DBUS is (at minimum, because it now depends on DBUS, which is -itself- rather complicated) substantially more complicated than a script that does exec "$@" Surely you can't argue with that?
        • deleted 11y ago
          [deleted]
        • bkor 11y ago
          If that complexity isn't exposed, then it isn't more complicated. Lots of init scripts used to be quite different across distributions and very long. Nowaways the systemd unit files are shipped upstream and you just package them. That's vastly less complex.
          • Karunamon 11y ago
            It's less complex in the same way that a C program is less complex than equivalent assembly - the complexity is just moved one layer of abstraction down, but it still exists, and can still bite you in certain ways.
          • simoncion 11y ago
            > If that complexity isn't exposed, then it isn't more complicated. It may not appear to be more complex to the user, but when your software has a firm dependency on a complex system, it becomes more complex because it is affected by the failure modes, quirks, and restrictions of the software on which it depends. [0] > Lots of init scripts used to be quite different across distributions and very long. I've talked elsewhere in these threads about how systemd's unit files simply shift the complexity for services that need (for whatever reason) complex pre-start logic out of the unit file and into hand-maintained tools. See [1] for my most recent comment on the topic. Make sure to check the footnotes in that comment, too. :) [0] Entirely valid anecdotal evidence on the relative stability of dbus doesn't invalidate my point. dbus is one of many complex software projects that others depend on. :) [1] https://news.ycombinator.com/item?id=10357379 https://news.ycombinator.com/item?id=10357379
      • illumen 11y ago
        Most people, including the authors of systemd would be very surprised if there were no problems with systemd. Here's a couple of fun problems from years past. Docs say NoNewPrivileges as yes "prohibits UID changes of any kind", but that's not exactly true. It's spammed so much debug info the system fails to boot. "systemd, when updating file permissions, allows local users to change the permissions and SELinux security contexts for arbitrary files via a symlink attack on unspecified files." "The rm_rf_children function in util.c in the systemd-logind login manager in systemd before 44, when logging out, allows local users to delete arbitrary files via a symlink attack on unspecified files, related to "particular records related with user session." It's complex software running on many different kernels, and many different distributions, doing many different things with lots of code written in C. There were over 80 people mentioned as contributing to the last release. Of course there are going to be problems!
        • deleted 11y ago
          [deleted]
      • vacri 11y ago
        > Oops, here come the downvotes! I hereby coin Vacri's Law: When a comment-maker announces incoming downvoting, they're aware their argument is weak and is instead trying deflect criticism through shaming others.
        • deleted 11y ago
          [deleted]
        • deleted 11y ago
          [deleted]
          • vacri 11y ago
            This is a much more measured response to my comment than your first attempt which started "yeah, you got me there". This is what downvoting does - it makes you moderate what you have to say. In any case, you're being a hypocrite. From your very first comment in this thread ("clearly done a full audit") you've been snarky, and now you're crying foul that people are being snarky back. I actually laughed out loud when you invoked the "good faith" HN guideline against Karunamon.