6 ms·

I'd probably respect SystemD a lot more if it measured itself against a modern init system like Gentoo's OpenRC instead of pretending it's invented dependency h

I'd probably respect SystemD a lot more if it measured itself against a modern init system like Gentoo's OpenRC instead of pretending it's invented dependency handling. https://wiki.gentoo.org/wiki/Comparison_of_init_systems https://wiki.gentoo.org/wiki/Comparison_of_init_systems > OpenRC provides a number of features touted as innovative by recent init systems like systemd ...

ashark 10y ago
OpenRC's the only init system I've actually liked. It's one of the things I really miss from when I used Gentoo, and I don't know why more distros didn't adopt it years ago.
- ausjke 10y ago
  probably it is not related to technical, SystemD has Redhat in the back initially I think.
- dijit 10y ago
  You should check out SMF, if you have a couple of hours to play with Solaris.. it handles things that systemd does (socket activation, process management/watching etc;) but in an orthogonal way that makes sense. I like openrc, I also like runit (for different reasons) but SMF is the gold standard for me and I recommend more people check it out. Even if it has XML elements :(
- JdeBP 10y ago
  TrueOS has just switched from Mewburn rc to OpenRC. They've had some problems to overcome.
- johnny22 10y ago
  OpenRC was definitely my favorite init system before systemd existed. Definitely beat out the defaults of distributions who were using the debian/redhat style sysvinit.
edoceo 10y ago
I'm on Gentoo and remember the switch to OpenRC. I was nervous. But all the old stuff worked! And my custom init scripts? Changed only one or two lines to make them work and a few more edits to make them fully OpenRC like. Backwards compatible FTW! And, now with OpenRC it still "just works". Fast, predictable boot with logs in normal places that I can easily debug, manage and modify.
digi_owl 10y ago
Pretty much this. It is designed and developed by people that seems to think that RH's take on rc.d was the be all, end all of scripted init.
otabdeveloper 10y ago
Systemd isn't an init system, it's a service (a.k.a daemon) management daemon. Its primary purpose is to restart and diagnose failing daemons cleanly. Systemd won for one simple reason: it's the only tool that accomplishes this task without bugs. We've been running daemontools for almost a decade in production, and it's a nightmare of bugs. Very glad to be finally switching to systemd.
- prewett 10y ago
  I've used them, too, but while they always seem like a hassle, I haven't encountered any bugs. What are the bugs that you've found?
- semi-extrinsic 10y ago
  > Its primary purpose is to restart and diagnose failing daemons cleanly. If this is true, and speaking as a systemd user for close to five years now, it universally sucks at its primary purpose. Specifically, whenever a service fails, I've lost count of the number of times systemd has barked out useless errors with 200 lines that boil down to "service has entered failed state". Whenever a systemd service fails, odds are better than even I have to spend two hours debugging why by enabling internal logging in that service, running in debug mode etc. Like when I tried to switch to networkd, and had the wrong password for a wifi I was connecting to, networkd never told me this in any way I could find. Had to go back to the old solution (after an hour of pulling my hair out) before I realised the password was wrong.
  - Mic92 10y ago
    Networkd does not handle WLAN authentication. This is the job of wpa_supplicant, which is the defacto standard on linux in every setup until maybe iwd from Intel takes over.
    - semi-extrinsic 10y ago
      Yeah, but I'm sure you agree networkd should propagate errors from wpa_supplicant such that they reach the user, instead of piping them to /dev/null (not literally, but you get my point)?
microcolonel 10y ago
OpenRC is still more difficult to write init scripts for than systemd; and offers less flexibility in scheduling inits. For example, I can add a 'before' clause to a custom systemd service unit, and I don't need to modify the subsequent units to depend on my custom unit. This is especially useful when you want a custom forking or oneshot service to reliably run before a standard service shipped with a package in your distro. In a similar vein, systemd targets are considerably more useful than sysv/OpenRC runlevels. A typical sysadmin can read a couple paragraphs of manpage and set up a new target (analogous to runlevel) in systemd; and it can be used for debugging or recovery in the same fashion that runlevels are in other init systems. On top of this, there are powerful system services developed in tandem with systemd, in the same repository, which offer well-integrated standard alternatives to things which were superficially different on ever distro only four years ago.
- AstralStorm 10y ago
  Less flexibility how? Please be specific. Before clause exists in OpenRC and is typically rarely useful. The things it has are incomplete and too integrated, making them hard to replace with working alternatives that do what you want.
dom0 10y ago
(Or Solaris SMF)

ashark 10y ago

OpenRC's the only init system I've actually liked. It's one of the things I really miss from when I used Gentoo, and I don't know why more distros didn't adopt it years ago.

ausjke 10y ago
probably it is not related to technical, SystemD has Redhat in the back initially I think.
dijit 10y ago
You should check out SMF, if you have a couple of hours to play with Solaris.. it handles things that systemd does (socket activation, process management/watching etc;) but in an orthogonal way that makes sense. I like openrc, I also like runit (for different reasons) but SMF is the gold standard for me and I recommend more people check it out. Even if it has XML elements :(
JdeBP 10y ago
TrueOS has just switched from Mewburn rc to OpenRC. They've had some problems to overcome.
johnny22 10y ago
OpenRC was definitely my favorite init system before systemd existed. Definitely beat out the defaults of distributions who were using the debian/redhat style sysvinit.

edoceo 10y ago

I'm on Gentoo and remember the switch to OpenRC. I was nervous. But all the old stuff worked! And my custom init scripts? Changed only one or two lines to make them work and a few more edits to make them fully OpenRC like. Backwards compatible FTW! And, now with OpenRC it still "just works". Fast, predictable boot with logs in normal places that I can easily debug, manage and modify.

digi_owl 10y ago

Pretty much this. It is designed and developed by people that seems to think that RH's take on rc.d was the be all, end all of scripted init.

otabdeveloper 10y ago

Systemd isn't an init system, it's a service (a.k.a daemon) management daemon. Its primary purpose is to restart and diagnose failing daemons cleanly. Systemd won for one simple reason: it's the only tool that accomplishes this task without bugs. We've been running daemontools for almost a decade in production, and it's a nightmare of bugs. Very glad to be finally switching to systemd.

prewett 10y ago
I've used them, too, but while they always seem like a hassle, I haven't encountered any bugs. What are the bugs that you've found?
semi-extrinsic 10y ago
> Its primary purpose is to restart and diagnose failing daemons cleanly. If this is true, and speaking as a systemd user for close to five years now, it universally sucks at its primary purpose. Specifically, whenever a service fails, I've lost count of the number of times systemd has barked out useless errors with 200 lines that boil down to "service has entered failed state". Whenever a systemd service fails, odds are better than even I have to spend two hours debugging why by enabling internal logging in that service, running in debug mode etc. Like when I tried to switch to networkd, and had the wrong password for a wifi I was connecting to, networkd never told me this in any way I could find. Had to go back to the old solution (after an hour of pulling my hair out) before I realised the password was wrong.
- Mic92 10y ago
  Networkd does not handle WLAN authentication. This is the job of wpa_supplicant, which is the defacto standard on linux in every setup until maybe iwd from Intel takes over.
  - semi-extrinsic 10y ago
    Yeah, but I'm sure you agree networkd should propagate errors from wpa_supplicant such that they reach the user, instead of piping them to /dev/null (not literally, but you get my point)?

microcolonel 10y ago

OpenRC is still more difficult to write init scripts for than systemd; and offers less flexibility in scheduling inits. For example, I can add a 'before' clause to a custom systemd service unit, and I don't need to modify the subsequent units to depend on my custom unit. This is especially useful when you want a custom forking or oneshot service to reliably run before a standard service shipped with a package in your distro. In a similar vein, systemd targets are considerably more useful than sysv/OpenRC runlevels. A typical sysadmin can read a couple paragraphs of manpage and set up a new target (analogous to runlevel) in systemd; and it can be used for debugging or recovery in the same fashion that runlevels are in other init systems. On top of this, there are powerful system services developed in tandem with systemd, in the same repository, which offer well-integrated standard alternatives to things which were superficially different on ever distro only four years ago.

AstralStorm 10y ago
Less flexibility how? Please be specific. Before clause exists in OpenRC and is typically rarely useful. The things it has are incomplete and too integrated, making them hard to replace with working alternatives that do what you want.

dom0 10y ago

(Or Solaris SMF)