4 ms·

It's dramatically simpler and more intuitive than what it replaced, so I'm super excited when someone comes up with something even better!

downerending 6y ago
Systemd has many pluses, but simplicity and intuitiveness are most certainly not among them.
- josteink 6y ago
  Simple... for what? I’d like to setup a service, which depends on another service, and which must always be running, and if it goes down, it needs to have all forked processes killed, must be restarted, and it needs to run as a specific user. With systemd? 5 lines or so of boilerplate, independent of distro. I don’t know about you, but I call that simple.
  - kelnos 6y ago
    I think this subthread is talking about the complexity of a system's implementation, not that of its user interface.
    - josteink 6y ago
      As a user, systemd wins for me hands down, because it is simple to use. That it masks complexity away from me is a feature, not a bug. This is also why distros is implementing it almost everywhere: It makes their job easier. Now if you are measuring the complexity of the system's (full) implementation, you can't really compare systemd to to SysV-init. You need to compare a systemd-based system to a SysV-init based system. And then you need to account for the 100s of inconsistently written shell-scripts, all the code distributed in the mess of third party dependencies (sh, bash, Perl, Awk, Python, su, supervisord, cron, etc) to ensure that the functionality of the systems you are comparing is really somewhat equal, not to mention the added complexity of the glue between all those components, and how it may fail. And when you do that comparison, I do believe you will end up concluding that 1. full systems are somewhat complex, for both systems, and 2. that systemd-based systems are not fundamentally more complex, and 3. systemd-based systems have the benefit of a single, centralized implementation for all these core functions, so that developers don't have to reimplement them inconsistently, and possibly buggy. With systemd, for better or worse, either your entire init-chain is broken or it isn't, so when it works, you know it works. With SysV-init you have no such guarantees.
      - esarbe 6y ago
        Downvoted for truth, I guess?
    - duncan_bayne 6y ago
      ... which is as I recall, one of the main differences between the New Jersey Style and the MIT Style (per Gabriel).
    - rcxdude 6y ago
      The implementation of a correct version of the above in sysvinit is no less complex, especially in its emergent behaviour.
  - majewsky 6y ago
    Technically (and I think this is what this thread's misunderstanding is coming from), this is not systemd being simple. It's systemd being easy. Simplicity is an intrinsic property of a product, describing that it solves a problem without needing many parts. Easiness is a property of the product's user experience, describing that it can be used without much training.
    - squeed 6y ago
      Systemd reflects the underlying system it is meant to support: the Linux kernel. And the Linux kernel is neither easy nor complex. That Systemd can make the mania of Linux knobs usable is, IMHO, a huge achievement.
  - downerending 6y ago
    I've run across a couple of cases where the "depends on" part seems to intermittently fail. That is, the implementation seems to end up with a race. That presumably means that the dependencies were specified incorrectly, but getting it right seems to be quite difficult. Or, conceivably, it's a bug in systemd, but debugging that is a lot harder than debugging a couple of tiny shell scripts. I'm not necessarily a "remainer" on the subject of systemd, but I think it's not correct to sell it as a huge win on simplicity. Maybe it is simple when everything goes right. When it doesn't, though, systemd is fairly nasty to deal with.
- theamk 6y ago
  Depending how you look? Here is a great example: disable the service before installing -- i.e. make sure that even if someone installs the service, it won't get activated. On systemd, it is "systemctl mask NAME". On sysvinit? Well, there maybe a file in /etc/default/ -- but each package has its own option name... and some of them cannot be disabled at all.
rleigh 6y ago
> It's dramatically simpler and more intuitive than what it replaced I hope you're being deeply ironic. It's several orders of magnitude more complex. It's more difficult to understand and reason about because its internal state is a black box, and the number of interfaces and file formats to understand is again orders of magnitude more complex. sysvinit had a socket interface with a single message type. It had a single and very simple configuration file (inittab). Everything else was delegated to higher levels. Simple, flexible, and extensible. But above all, understandable in its entirety, and completely predictable.
- jcelerier 6y ago
  > It's several orders of magnitude more complex. It's more difficult to understand and reason about because its internal state is a black box, and the number of interfaces and file formats to understand is again orders of magnitude more complex. As a user I 100% disagree. Before systemd I had to learn a few dozen of different config formats for various things * various distros, now all my systems are configured in a reliable & simple way, for init, network, timers, etc etc
  - dijit 6y ago
    It's interesting how many people have such wildly different experiences with systemd. For me systemd has hidden some really horrible things behind it's dependency graph (which is a black box) and socket activation issues (for instance, cockpit "listens" on a port, but it's really systemd's socket activation (PID1) and there was a RCE against it). The configuration file format is, in my mind, mysterious, with random keys in the unit file which have random meaning, and behaviour that is anything but deterministic. But I've been using systemd for a long time (since Fedora 21). Maybe we're all coloured by not only when we first encountered it but by our distro and how simple they make things? FWIW I'm using Debian and Arch these days and still struggle to "enjoy" systemd, but it definitely functions better on my arch machine.
    - jcelerier 6y ago
      > For me systemd has hidden some really horrible things behind it's dependency graph (which is a black box) and socket activation issues (for instance, cockpit "listens" on a port, but it's really systemd's socket activation (PID1) and there was a RCE against it). I don't understand how this is an horrible thing. Thanks to it you can do stuff as systemd-analyze dot > /tmp/foo.dot ; xdot /tmp/foo.dot and have an interactive representation of your boot flow graph, where you can click on any node to highlight any other dependent node. This is super nice ! systemd-analyze critical-chain was also very good to try to find out which service was keeping my NAS stuck for 5 minutes on boot. The configuration file format is, in my mind, mysterious, with random keys in the unit file which have random meaning, and behaviour that is anything but deterministic. To give you my experience I was never able to do anything with older systems without reading tutorials on the internet while with systemd I'm able to solve my problems with man systemd-whatever most of the time, e.g. just look at `man systemd.service` or `man systemd.network` with actual configuration examples for common use cases

downerending 6y ago

Systemd has many pluses, but simplicity and intuitiveness are most certainly not among them.

josteink 6y ago
Simple... for what? I’d like to setup a service, which depends on another service, and which must always be running, and if it goes down, it needs to have all forked processes killed, must be restarted, and it needs to run as a specific user. With systemd? 5 lines or so of boilerplate, independent of distro. I don’t know about you, but I call that simple.
- kelnos 6y ago
  I think this subthread is talking about the complexity of a system's implementation, not that of its user interface.
  - josteink 6y ago
    As a user, systemd wins for me hands down, because it is simple to use. That it masks complexity away from me is a feature, not a bug. This is also why distros is implementing it almost everywhere: It makes their job easier. Now if you are measuring the complexity of the system's (full) implementation, you can't really compare systemd to to SysV-init. You need to compare a systemd-based system to a SysV-init based system. And then you need to account for the 100s of inconsistently written shell-scripts, all the code distributed in the mess of third party dependencies (sh, bash, Perl, Awk, Python, su, supervisord, cron, etc) to ensure that the functionality of the systems you are comparing is really somewhat equal, not to mention the added complexity of the glue between all those components, and how it may fail. And when you do that comparison, I do believe you will end up concluding that 1. full systems are somewhat complex, for both systems, and 2. that systemd-based systems are not fundamentally more complex, and 3. systemd-based systems have the benefit of a single, centralized implementation for all these core functions, so that developers don't have to reimplement them inconsistently, and possibly buggy. With systemd, for better or worse, either your entire init-chain is broken or it isn't, so when it works, you know it works. With SysV-init you have no such guarantees.
    - esarbe 6y ago
      Downvoted for truth, I guess?
  - duncan_bayne 6y ago
    ... which is as I recall, one of the main differences between the New Jersey Style and the MIT Style (per Gabriel).
  - rcxdude 6y ago
    The implementation of a correct version of the above in sysvinit is no less complex, especially in its emergent behaviour.
- majewsky 6y ago
  Technically (and I think this is what this thread's misunderstanding is coming from), this is not systemd being simple. It's systemd being easy. Simplicity is an intrinsic property of a product, describing that it solves a problem without needing many parts. Easiness is a property of the product's user experience, describing that it can be used without much training.
  - squeed 6y ago
    Systemd reflects the underlying system it is meant to support: the Linux kernel. And the Linux kernel is neither easy nor complex. That Systemd can make the mania of Linux knobs usable is, IMHO, a huge achievement.
- downerending 6y ago
  I've run across a couple of cases where the "depends on" part seems to intermittently fail. That is, the implementation seems to end up with a race. That presumably means that the dependencies were specified incorrectly, but getting it right seems to be quite difficult. Or, conceivably, it's a bug in systemd, but debugging that is a lot harder than debugging a couple of tiny shell scripts. I'm not necessarily a "remainer" on the subject of systemd, but I think it's not correct to sell it as a huge win on simplicity. Maybe it is simple when everything goes right. When it doesn't, though, systemd is fairly nasty to deal with.
theamk 6y ago
Depending how you look? Here is a great example: disable the service before installing -- i.e. make sure that even if someone installs the service, it won't get activated. On systemd, it is "systemctl mask NAME". On sysvinit? Well, there maybe a file in /etc/default/ -- but each package has its own option name... and some of them cannot be disabled at all.

rleigh 6y ago

> It's dramatically simpler and more intuitive than what it replaced I hope you're being deeply ironic. It's several orders of magnitude more complex. It's more difficult to understand and reason about because its internal state is a black box, and the number of interfaces and file formats to understand is again orders of magnitude more complex. sysvinit had a socket interface with a single message type. It had a single and very simple configuration file (inittab). Everything else was delegated to higher levels. Simple, flexible, and extensible. But above all, understandable in its entirety, and completely predictable.

jcelerier 6y ago
> It's several orders of magnitude more complex. It's more difficult to understand and reason about because its internal state is a black box, and the number of interfaces and file formats to understand is again orders of magnitude more complex. As a user I 100% disagree. Before systemd I had to learn a few dozen of different config formats for various things * various distros, now all my systems are configured in a reliable & simple way, for init, network, timers, etc etc
- dijit 6y ago
  It's interesting how many people have such wildly different experiences with systemd. For me systemd has hidden some really horrible things behind it's dependency graph (which is a black box) and socket activation issues (for instance, cockpit "listens" on a port, but it's really systemd's socket activation (PID1) and there was a RCE against it). The configuration file format is, in my mind, mysterious, with random keys in the unit file which have random meaning, and behaviour that is anything but deterministic. But I've been using systemd for a long time (since Fedora 21). Maybe we're all coloured by not only when we first encountered it but by our distro and how simple they make things? FWIW I'm using Debian and Arch these days and still struggle to "enjoy" systemd, but it definitely functions better on my arch machine.
  - jcelerier 6y ago
    > For me systemd has hidden some really horrible things behind it's dependency graph (which is a black box) and socket activation issues (for instance, cockpit "listens" on a port, but it's really systemd's socket activation (PID1) and there was a RCE against it). I don't understand how this is an horrible thing. Thanks to it you can do stuff as systemd-analyze dot > /tmp/foo.dot ; xdot /tmp/foo.dot and have an interactive representation of your boot flow graph, where you can click on any node to highlight any other dependent node. This is super nice ! systemd-analyze critical-chain was also very good to try to find out which service was keeping my NAS stuck for 5 minutes on boot. The configuration file format is, in my mind, mysterious, with random keys in the unit file which have random meaning, and behaviour that is anything but deterministic. To give you my experience I was never able to do anything with older systems without reading tutorials on the internet while with systemd I'm able to solve my problems with man systemd-whatever most of the time, e.g. just look at `man systemd.service` or `man systemd.network` with actual configuration examples for common use cases