1. 25
  1. 11

    1.3 million lines but systemd is an umbrella term. How many sub-programs are in there? What is their LOC?

    1. 9

      Looking at Wikipedia, it contains at least:

      • init
      • logging
      • login
      • network management
      • device management
      • clock management
      • power management
      • boot manager
      • cron, at, watchdog substitutes
      • introspection and analysis tooling

      Is 1.3 LOC justified? We would need to compare it with a set of dozens of other tools it replaces. Nobody has ever done that afaik.

      A better comparison would be to compare a single component with a corresponding one. For example, compare journald with syslogd. Did anybody do that?

      Most people compare the feature set. One question is if init should be able to communicate via D-Bus? Some argue that it should defer that to another tool due to the Unix philosophy of “Write programs that do one thing and do it well”. It is a similar question to “should you use microservices or a monolithic server?” Personally, I’m not convinced that the Unix philosophy to create hundreds of executables is better than few executables which are modularized internally. We want loose coupling, but splitting into multiple executables does not achive that. For example, all the git-something executables are very tightly coupled.

      Defering the stuff systemd init does to other tools does not necessarily reduce the complexity of the system. Usually the complexity increases if stuff is separated into multiple processes (see microkernel vs monolithic kernel debates). You can reduce complexity by removing features. If systemd provides features you don’t need then “bloat” is a valid argument for your use case. However, systemd comes with various useful features (like faster boot times) that lots of people care about.

    2. 7

      When I started to use Linux, it’s SysVInit. Then ubuntu upstart. Then a bunch of similar thing: monit, supervisor…

      All of them has to figured with log file, pidfile, wrapper script to start your process etc. On top of that you have to roll your own log rotate process, and if your process is too spammy, you may have to manually add cron entry to invoke logrotate daily, plus the permission. UpStart is one step up, but still not very reliable to me. I had case where upstart will not refresh my config. Systemd is the only system that I tried that work on first try and bundle everything I need. It even has nice thing like ProtectHome/PrivateTmp out of the box…

      Probably for advanced users systemd suck but given me as a backend dev, I just need a Linux box and a thing that auto restart services for me, and also handle log properly without me have to manually write log rotate and signal the process.

      1. 5

        The complexity of systemd counted in lines of code is terrible. But what is even worse is the architecture and standardization.

        If systemd was modular, it would be possible to use only certain parts of it (and thus download and compile only the fraction of the SLOC). It would not hurt you, that there was sitting another modules in separate repositories, if you did not use them.

        If systemd have defined a standard API or even used an existing one, it would be possible to use drop-in replacement for particular modules with less complexity (or better performance, code quality etc.).

        It is not always systemd’s fault. Also authors/maintainers of other packages did bad decisions and made situation worse. Other software should never depend on systemd directly, but should depend on abstract interfaces. If such interface is missing, it is time to create it – hide a complex bulky software behind it and allow others to provide a better implementation of given interface.

        1. 9

          Unjustified complexity has a name: Bloat.

          1. 28

            Sure. How do you know the complexity in this case is unjustified?

            1. -1

              Sure. How do you know the complexity in this case is unjustified?

              It isn’t accompanied with a justification.

              1. 13

                But neither is your accusation?

                As someone who is too young for all the systemd hate, I really haven’t found any good explanation of why I should hate it too.

                1. 8

                  There is a lot of justification.

                  Most people care about the “Keeping the First User PID Small” aspect. The primary argument of Poettering is “shell scripts are evil”.

                  On my system the scripts in /etc/init.d call grep at least 77 times. awk is called 92 times, cut 23 and sed 74. Every time those commands (and others) are called, a process is spawned, the libraries searched, some start-up stuff like i18n and so on set up and more. And then after seldom doing more than a trivial string operation the process is terminated again. Of course, that has to be incredibly slow.

                  shell scripts are also very fragile, and change their behaviour drastically based on environment variables and suchlike, stuff that is hard to oversee and control.

                  Most of the scripting is spent on trivial setup and tear-down of services, and should be rewritten in C, either in separate executables, or moved into the daemons themselves, or simply be done in the init system.

                  1. 4

                    so his reasoning is that unix tools “have to be incredibly slow,” and it’s hard to control environment variables. i haven’t read much from poettering but i think i know now why people hate him.

                    1. 1

                      when you start any binary many times in a loop, it is slow. that’s why if you want your shell scripts to have good performance you want to do as much in pure shell as possible, especially in any loops. Also, environment variables are global mutable state, which by definition is difficult to control. The only way to do anything about them is use cgroups for everything, which systemd largely does and sysv does not.

                      1. 1

                        the theoretical reasons that starting external binaries could be slower than running a single program are not enough to say that something is slow in practice. i haven’t noticed any difference in speed between sysvinit and systemd, unless you count stalling at shutdown.

                        maybe we are talking about different things but there is stuff like env(1) and execle(2) which let you control the environment for a process, without cgroups.

                        1. 1

                          It’s “slow”, but with very fast values of slow. Sure, you probably don’t need grep and awk/sed (both have /regex/ as a core feature) - but IMNHO it’s a lot easier to read that way - and of course you don’t need a c++ compiler to fix a logic or “parser” bug.

                          “Speed” was one of the arguments for perl (over sh+awk+grep+sed) - still is. But it’s normally not a very interesting or compelling argument.

                          “70+ invocations of grep” might sound like a lot of “bloat”, but we’re effectively talking about quick process forks here, hot disk and cpu caches.

                          I don’t think I’ve ever seen init or login being slow due to “too many forks” - but doing some things safely in parallell can be an obvious benefit. But you can do that with shell too.

                2. 10

                  LOC is a terrible way to measure complexity.

                  (Note that I’m not saying systemd is not complex, just that trying to equate LOC to code quality/complexity is not an accurate way to measure quality/complexity)

                  1. 9

                    The article you linked doesn’t say that. Also the article agrees with the tone of ethoh’s comment. I personally think that more lines of code is almost always more complex. Whether it’s irreducibly complex or just complex is another question, but it’s probably complex.

                    1. 7

                      “I don’t need a calculator to determine if I need to pay taxes on a million dollars.” – Ian Malcolm, Jurassic Park

                      1. 2

                        it’s more accurate than any alternative

                        1. 2

                          Which is? A knee-jerk reaction to something you don’t like? At least come up with some arguments as to why you think it’s bloated.

                          1. 2

                            i think you responded to the wrong comment.

                          2. 1

                            There is much more accurate or meaningful alternative: cyclomatic complexity.

                            However SLOC is a good approximation and it is much more easier to count the lines.

                            In both cases you also must consider the complexity of the dependencies (libraries, compilers…).

                            1. 2

                              cool i never heard of that. are there tools to measure cyclomatic complexity?

                              1. 2

                                Yes. Some linters measure it.