1. 25
  1.  

  2. 27

    I am a very vocal person about systemd.

    With that said, I find the articles opening statements to be quite fair in all regards- However, it does seem to fall right into the trap of comparing systemd with sysvinit.

    Without fail whenever someone extolls virtues and waxes poetic on the subject of systemd being “easy” it is always with the preconceived notion that sysvinit was the alternative.

    My typical argument against systemd is precisely in that it’s so complex and ever changing as to be effectively a closed system; integration with systemd specifics ensures that there can never be a successor, we are locked in to systemd forever more. So it had better be damned near perfect architecturally; and given the compromises and nature of exploits I do not have faith that it is.

    evidenced by the lengthy but great run down of the events surrounding systemd and the recent system-down exploit.

    There were alternatives; runit being a good example, but now swapping out your init for any other will cause many bits of useful software (notably gnome, but more as time goes on) to no longer work.

    1. 14

      Even without comparing it with anything. What valid reason is there to increase the scope of what is generally percieved as an init system by some 1000%?

      I, like most people, like being able to define services just by creating a 4 line unit file rather than having those silly ad hoc old init scripts. But why not doing just that? Why do I all of the sudden need an application just to check logs?

      1. 6

        Counterpoint: with systemd the logs are now collected in a pretty consistent way instead of spread eccentrically around /var/log. I find it convenient that I don’t need to define what my logfiles are going to be called or what rotation will occur, etc. Those aren’t interesting problems to me.

        1. 6

          the logs are now collected in a pretty consistent way

          Few adjectives are missing: error-prone, inefficient, insecure. You can insert them after pretty and then your sentence is 100% spot on.

          Links:

          If you ask me if I want to trade the previous logging stack to this, I would say no.

          1. 3

            That’s your prerogative. I have not experienced any of those issues but have experienced issues with the traditional approach. In any case, all systems have faults.

      2. 7

        Most likely a system such as systemd is not correct or even possible to implement correctly because they’re not doing any formal verification to ensure every D-bus component conforms to their agreed upon interface.

        I’m just waiting for a cardhouse to fall.

        1. 2

          many bits of software, you mean

          1. 1

            Did any distros actually use runit?

            I used daemontools for a tiny project for awhile, and while it’s very elegant, I got the sense that you were also swimming upstream. It was more a thing I used on top of a distro (on top of sysv init or systemd), not really a replacement.

            I don’t know the details but I’d hope and expect that the projects that integrate with systemd would accept patches for non systemd inits.

            1. 8

              Did any distros actually use runit?

              Void uses it, Artix recently added it as an option, and Project Trident recently switched over to Void as their base so I believe they also use Runit now too.

              I don’t know the details but I’d hope and expect that the projects that integrate with systemd would accept patches for non systemd inits.

              I doubt it. Most programs I’ve seen that depend on systemd often have it as a hard requirement. Which forces users to use tools like elogind or consolekit or eudev, or patch the program themselves to not use systemd. It’s a trivial thing when using a distro like Gentoo, but I’m sorry for those who use distros like Debian because it’s near impossible to escape from systemd there.

          2. 11

            There have been many other arguments on this topic here and elsewhere across the internet which have brought up some great points in either direction.

            My personal reason for liking systemd is that its tight coupling significantly improves its user interface. I don’t think it’s the ultimate solution to the problem, but it meets my needs the best and is the most painless option out there for me.

            The thing that is missing from Unix is a balance between runtime introspection and robustness. While traditional init scripts are more introspectable than systemd’s C binaries, they are much more fragile, in my experience. Well-tested, mature C code can be very robust, but it is more difficult to interact with and modify at runtime.

            1. [Comment removed by moderator pushcx: Removing troll thread.]

              1. [Comment removed by moderator pushcx: Removing troll thread.]

                1. [Comment removed by moderator pushcx: Removing troll thread.]