5 ms·

I've used several Linux init systems over the years. OpenRC is the only one I've ever liked using. Not sure why it never seemed to catch on with any of the maj

by bamfly 3y ago

I've used several Linux init systems over the years. OpenRC is the only one I've ever liked using. Not sure why it never seemed to catch on with any of the major distros, even before Systemd made itself nigh-unavoidable.

taneliv 3y ago
I have serious dislike for what I perceive as (unnecessary) complexity of Systemd. I made a quick analysis of different init systems when that nigh-unavoidability had not yet happened. OpenRC seemed then the most reasonable of the ones I read about (for qualities I have since forgotten), and your comment stirred this memory. So, a question: why did/do you like using it?
- bamfly 3y ago
  Found the ergonomics of rc-update and other commands exceptionally decent, and consistent enough that I could usually guess the correct invocation even if I hadn't used it in a while. Never saw it break or tie itself in knots (which, on Gentoo, at least as I managed my Gentoo systems, was an accomplishment). I find the config syntax non-awful. Every other init system I've tried is worse (IMO, obviously) on one or more of those fronts, and not enough-better on any others to make up for it.
  - mid-kid 3y ago
    my biggest pet peeve is having "rc-update <action> <name>" vs "rc-service <name> <action>". systemctl does this consistently, at least.
- esarbe 3y ago
  With Systemd you have a configuration language and a defined surface. With OpenRC you have unconstained init scrips written in a Turing-complete language. How exactly is Systemd more complex?
  - taneliv 3y ago
    Whether it is actually more complex, I don't know. I didn't claim so for actual reasons, and your comment is one of them. I'm just a user, not a package or system maintainer, whose opinions are way more substantive than mine. Distributions have overwhelmingly chosen Systemd, so it seems obvious that it offers real benefits (including simplicity, I must assume). As a user I just lament the missed opportunity to simplify the system and service management also from my point of view. I don't see Systemd as simpler than other init systems, just different.
zh3 3y ago
Probably not a popular opinion in a systemd world (and being responsible for a lot of critical systems where things don't change much but absolutely have to work every day), the nice thing about sysv is all you need to know a little bit about shell commands and every day is groundhog day (i.e. not getting any calls because X has broken after touching Y). Not great for companies selling support, but great for those selling high-rel.
- linksnapzz 3y ago
  I agree; not so much that I've found systemd to be unreliable, so much as that it is far more opaque than even the most involved SXX/KXX SysV shell script; I can debug a shell script, but when systemd does do something unexpected, it's utterly inscrutiable.
  - hackerbrother 3y ago
    I will take the opposite opinion. I think that systemd overall reduces the quantity, or surface area, for bugs by making many standard types of service requirements for dependencies, restarting, etc. simple configuration options.
    - bandrami 3y ago
      Right but you never see what it's actually doing like you do with sysv. You have a high-level description of what you want to happen and when it messes up (invariably at 3am, invariably on a mission-critical system) you're completely in the dark about what it's trying to do. You can (and people do) mitigate this by just writing imperative startup scripts that systemd calls, but then that leaves the question of what the point is.
      - kaba0 3y ago
        Managing services and dependencies and orchestrating all of that is the point. That orchestration “boilerplate” has to be correct and you can reasonably know that it is with a program made for that. If you mess up your service’s config, the problem will be local (your service won’t start), while without a declarative stance your whole system would be in an inconsistent state.
agumonkey 3y ago
it's strange that "liked using" isn't the goal in general
JdeBP 3y ago
Timing. When the Debian Hoo-Hah happened, OpenRC was one of the several systems evaluated, but a lot of the features, in the version that Debian had, that people were looking for weren't there yet, and it wasn't even packaged up as a stable Debian package. The OpenRC proponents commented that the features could be added and it could be packaged. But the features and packaging weren't there at the time. (Indeed, ironically, the van Smoorenburg init+rc system actually added features a short while later that did away with much of the complaints about lengthy shell scripts full of mostly the same boilerplate. Similarly, it later became possible to drive something like s6 with OpenRC, to get proper supervision.) See https://lists.debian.org/debian-ctte/2013/12/msg00234.html https://lists.debian.org/debian-ctte/2013/12/msg00234.html and https://lists.debian.org/debian-ctte/2014/01/msg00067.html https://lists.debian.org/debian-ctte/2014/01/msg00067.html and https://lists.debian.org/debian-ctte/2014/01/msg00358.html https://lists.debian.org/debian-ctte/2014/01/msg00358.html and others. To quote Andreas Barth in 2014, months into the discussion, for starters: > For openrc, this is a moving target. When I looked at it first during the start of this discussion, it was not even in experimental (and still is not in unstable), and documentation was hard to get. This has improved but still it is worse then the others. Also having a no-double-fork-setup for demons is something really useable, and I haven't seen any answer on that during time of writing this.

by bamfly 3y ago

taneliv 3y ago

I have serious dislike for what I perceive as (unnecessary) complexity of Systemd. I made a quick analysis of different init systems when that nigh-unavoidability had not yet happened. OpenRC seemed then the most reasonable of the ones I read about (for qualities I have since forgotten), and your comment stirred this memory. So, a question: why did/do you like using it?

bamfly 3y ago
Found the ergonomics of rc-update and other commands exceptionally decent, and consistent enough that I could usually guess the correct invocation even if I hadn't used it in a while. Never saw it break or tie itself in knots (which, on Gentoo, at least as I managed my Gentoo systems, was an accomplishment). I find the config syntax non-awful. Every other init system I've tried is worse (IMO, obviously) on one or more of those fronts, and not enough-better on any others to make up for it.
- mid-kid 3y ago
  my biggest pet peeve is having "rc-update <action> <name>" vs "rc-service <name> <action>". systemctl does this consistently, at least.
esarbe 3y ago
With Systemd you have a configuration language and a defined surface. With OpenRC you have unconstained init scrips written in a Turing-complete language. How exactly is Systemd more complex?
- taneliv 3y ago
  Whether it is actually more complex, I don't know. I didn't claim so for actual reasons, and your comment is one of them. I'm just a user, not a package or system maintainer, whose opinions are way more substantive than mine. Distributions have overwhelmingly chosen Systemd, so it seems obvious that it offers real benefits (including simplicity, I must assume). As a user I just lament the missed opportunity to simplify the system and service management also from my point of view. I don't see Systemd as simpler than other init systems, just different.

zh3 3y ago

Probably not a popular opinion in a systemd world (and being responsible for a lot of critical systems where things don't change much but absolutely have to work every day), the nice thing about sysv is all you need to know a little bit about shell commands and every day is groundhog day (i.e. not getting any calls because X has broken after touching Y). Not great for companies selling support, but great for those selling high-rel.

linksnapzz 3y ago
I agree; not so much that I've found systemd to be unreliable, so much as that it is far more opaque than even the most involved SXX/KXX SysV shell script; I can debug a shell script, but when systemd does do something unexpected, it's utterly inscrutiable.
- hackerbrother 3y ago
  I will take the opposite opinion. I think that systemd overall reduces the quantity, or surface area, for bugs by making many standard types of service requirements for dependencies, restarting, etc. simple configuration options.
  - bandrami 3y ago
    Right but you never see what it's actually doing like you do with sysv. You have a high-level description of what you want to happen and when it messes up (invariably at 3am, invariably on a mission-critical system) you're completely in the dark about what it's trying to do. You can (and people do) mitigate this by just writing imperative startup scripts that systemd calls, but then that leaves the question of what the point is.
    - kaba0 3y ago
      Managing services and dependencies and orchestrating all of that is the point. That orchestration “boilerplate” has to be correct and you can reasonably know that it is with a program made for that. If you mess up your service’s config, the problem will be local (your service won’t start), while without a declarative stance your whole system would be in an inconsistent state.

agumonkey 3y ago

it's strange that "liked using" isn't the goal in general

JdeBP 3y ago

Timing. When the Debian Hoo-Hah happened, OpenRC was one of the several systems evaluated, but a lot of the features, in the version that Debian had, that people were looking for weren't there yet, and it wasn't even packaged up as a stable Debian package. The OpenRC proponents commented that the features could be added and it could be packaged. But the features and packaging weren't there at the time. (Indeed, ironically, the van Smoorenburg init+rc system actually added features a short while later that did away with much of the complaints about lengthy shell scripts full of mostly the same boilerplate. Similarly, it later became possible to drive something like s6 with OpenRC, to get proper supervision.) See https://lists.debian.org/debian-ctte/2013/12/msg00234.html https://lists.debian.org/debian-ctte/2013/12/msg00234.html and https://lists.debian.org/debian-ctte/2014/01/msg00067.html https://lists.debian.org/debian-ctte/2014/01/msg00067.html and https://lists.debian.org/debian-ctte/2014/01/msg00358.html https://lists.debian.org/debian-ctte/2014/01/msg00358.html and others. To quote Andreas Barth in 2014, months into the discussion, for starters: > For openrc, this is a moving target. When I looked at it first during the start of this discussion, it was not even in experimental (and still is not in unstable), and documentation was hard to get. This has improved but still it is worse then the others. Also having a no-double-fork-setup for demons is something really useable, and I haven't seen any answer on that during time of writing this.