4 ms·

> The systemd ideology, ... , dumb down computers into appliancies. > Shells and sysvinit sure have their problems as the implementation. But at least they let

> The systemd ideology, ... , dumb down computers into appliancies. > Shells and sysvinit sure have their problems as the implementation. But at least they let me use my system as a general purpose computer. Why are you sure, you're perceived limitations of systemd compared to sysvinit are based on systemd's shortcommings instead of yours? I don't want to attack you personally, but I've had this conversation lot's of times before. Most of the time, people just had no clue how systemd works. In my experience it simplified lots of use-cases. And I have yet to find a use-case that was possible with sysvinit, but is not with systemd.

jampekka 3y ago
I have some clue how systemd works and manage to configure it to run the services I need. But to be frank, I'm quite clueless as to what most of its million LoCs do. I'm quite sure there's not more than a handful of people who do. Sysvinit did so little that it's almost trivial to understand. It has simplified lots of use cases but my criticism is that it focuses too much on these cases and makes other use cases more difficult. It makes the system quite opaque to the user, a bit like Windows or MacOS that become almost impossible to fix when they break.
- pkkm 3y ago
  > Sysvinit did so little that it's almost trivial to understand. This is only an advantage if you take an extremely short-sighted view of complexity. Yes, sysvinit itself is very simple, but by that metric you may just as well replace the init with a single exec to a user or distro-provided program. That would be even simpler, right? Well, not if you think about systemic complexity rather than just the complexity of that one program. A modern Linux system will include the monitoring of daemons, auto-restart, parallelized dependency-based boot, and so on. A lot of people also want features such as starting a daemon only when a connection arrives or a device is plugged in, or automatically redirecting a program's output to the system log. This stuff is inherently complex, and that complexity has to go somewhere. sysvinit just says "not my problem", so every distro needed to ship lots of scripts to do these things. Every program that wanted to act as a daemon had to do a whole dance of double fork, setsid, environment variable sanitization, umask, managing a pidfile, etc. You'd have this error-prone logic repeated dozens of times in your system, in different programs, often written by people who aren't Linux experts. That's not systemic simplicity. systemd takes all of this complexity onto itself, and centralizes it into one place that is written by Linux experts. This lets many other programs be simpler. > Makes other use cases more difficult. It makes the system quite opaque to the user, a bit like Windows or MacOS that become almost impossible to fix when they break. What use cases does it make difficult? How does it make things impossible to fix? Please give specifics, because my experience has been the opposite. When something breaks in a systemd system, I usually find good clues in the system journal and the fix can be a simple configuration change after googling the problem. It's a breath of fresh air compared to having to trace the workings of a hairball of distro-specific shell scripts.

jampekka 3y ago

I have some clue how systemd works and manage to configure it to run the services I need. But to be frank, I'm quite clueless as to what most of its million LoCs do. I'm quite sure there's not more than a handful of people who do. Sysvinit did so little that it's almost trivial to understand. It has simplified lots of use cases but my criticism is that it focuses too much on these cases and makes other use cases more difficult. It makes the system quite opaque to the user, a bit like Windows or MacOS that become almost impossible to fix when they break.

pkkm 3y ago
> Sysvinit did so little that it's almost trivial to understand. This is only an advantage if you take an extremely short-sighted view of complexity. Yes, sysvinit itself is very simple, but by that metric you may just as well replace the init with a single exec to a user or distro-provided program. That would be even simpler, right? Well, not if you think about systemic complexity rather than just the complexity of that one program. A modern Linux system will include the monitoring of daemons, auto-restart, parallelized dependency-based boot, and so on. A lot of people also want features such as starting a daemon only when a connection arrives or a device is plugged in, or automatically redirecting a program's output to the system log. This stuff is inherently complex, and that complexity has to go somewhere. sysvinit just says "not my problem", so every distro needed to ship lots of scripts to do these things. Every program that wanted to act as a daemon had to do a whole dance of double fork, setsid, environment variable sanitization, umask, managing a pidfile, etc. You'd have this error-prone logic repeated dozens of times in your system, in different programs, often written by people who aren't Linux experts. That's not systemic simplicity. systemd takes all of this complexity onto itself, and centralizes it into one place that is written by Linux experts. This lets many other programs be simpler. > Makes other use cases more difficult. It makes the system quite opaque to the user, a bit like Windows or MacOS that become almost impossible to fix when they break. What use cases does it make difficult? How does it make things impossible to fix? Please give specifics, because my experience has been the opposite. When something breaks in a systemd system, I usually find good clues in the system journal and the fix can be a simple configuration change after googling the problem. It's a breath of fresh air compared to having to trace the workings of a hairball of distro-specific shell scripts.