6 ms·

It got the job done by making the 99% majority of use cases more difficult in order to make the 1% minority simpler. This is a design pattern I think is being r

by jveld 11y ago

It got the job done by making the 99% majority of use cases more difficult in order to make the 1% minority simpler. This is a design pattern I think is being repeated in systemd. I kinda had the opposite impression. I first encountered systemd when I started messing around with arch for a couple little vps projects. At the time I was doing sysadmin that involved both Ubuntu and CentOS, and I definitely found day-to-day tasks easier with systemd (better built in monitoring, consistent syntax, etc). For simple cases, writing a unit file sucks a lot less than writing an initscript. The warts in systemd only started to irritate me when I was first setting up my personal machines (one laptop, one tower) to run arch [1]. Even then, the bloat in the design irked me more than actually using it. So, I'm in favor of systemd, but not thrilled (dbus everywhere is annoying). Then again, I don't maintain any packages with strange and/or complex daemons. If anybody's had a really hard time getting their stuff to work with systemd, I'd be interested to hear stories. 1: Not completely true. I want my damn log files back.

thaumaturgy 11y ago
This is why I suspect that most of the divisions in the sysadmin community regarding systemd are generational. For people (like me!) who have been writing init scripts forever and can do it in their sleep, they'd prefer the flexibility and familiarity of init scripts to a new system that at first glance appears more limited. For people who are less experien^H^H^H^H^H^H^H^Hcrusty :-), init scripts look like a horrifying way to manage a startup process, and just about anything -- including Yet Another Config File Format -- looks preferable. I think this is also why so little progress is being made on resolving conflicts over systemd. There really isn't a whole lot of room for compromise; one group simply wants things to stay more or less the same (or evolve incrementally), the other group simply wants to throw it all out and start over. I bet there would've been a lot less argument and vitriol about systemd if Debian hadn't made the decision to default to it, basically leaving all the crusty sysadmins homeless. Once Debian switched, there was a near guarantee that all of Linux was going to move to systemd. That suits one group just fine, another one not so much. On the plus side, the BSDs should be seeing a really nice upswell of installations over the next couple of years, which is great, because they've been quietly building some pretty great operating systems that deserve more love.
- chousuke 11y ago
  It's perfectly possible to run scripts with systemd unit files, so there's no real "flexibility" lost anywhere. The primary improvement is that systemd handles by default most of what used to be boiler-plate in every script, on top of calculating dependencies automatically. Then you get integrated process supervisor capabilities so that the init system actually knows whether services are running or not. Speed was certainly a major motivator as well, considering the increasing popularity of containers and on-demand virtual machines. To me it seems that "gradual evolution" was exactly what they did, and it wasn't really going anywhere. Lennart came up with systemd and convinced enough people that it's worth the pain of migration to get a clean start.
  - VLM 11y ago
    The key is the expense vs reward ratio. I don't know how to write sysvinit scripts any more than I know how to write fizzbuzz. What I do know is how to program and specifically how to write and maintain and debug shell scripts. I NEED that for other automation purposes and cannot get rid of that mandatory requirement so it used to dovetail quite well with init scripts. There are corner cases and security issues and tradition, which means copying a known good init script and editing nothing but the executable names is a great start, but its not really a serious problem. I don't care if its verbose, as long as its simple and understandable and most importantly, predictable. Now instead of applying a language and tradition I know to a simple task like init, I get to learn a whole new ecosystem and technology to do about the same thing I always did except vastly more complicated, and I can't even shed the old knowledge because its needed elsewhere. That makes overall systems harder to use, slower, buggier, and less reliable. And thats defined as "progress" because its new so it must be better.
    - EmanueleAina 11y ago
      I don't think it's really fair to compare writing unit files to being able to program in shell. True, knowing the systemd unit options is not a reusable skill, but it's not a huge effort either: the syntax is trivial (INI-inspired, the same as .desktop files) and the options themselves are rather well documented. And for sure, these options are immensely more reusable when writing a new unit file than mixing and matching shell snippets taken from different init script using different styles and conventions. (Not to mention how subtly tricky programming in shell is even when you're doing trivial things, see http://www.dwheeler.com/essays/filenames-in-shell.html http://www.dwheeler.com/essays/filenames-in-shell.html )
yellowapple 11y ago
The nice thing about initscripts, though, is that you can get the best of both worlds by sourcing in common functions, as is the default and recommended practice on OpenBSD. For example, here's the initscript for dovecot on my (OpenBSD-running) mail server (with some comments and newlines omitted for brevity): daemon="/usr/local/sbin/dovecot" . /etc/rc.d/rc.subr rc_cmd $1 Pretty straightforward: you set $daemon to the path of your daemon's executable (in this case, dovecot), source in rc.subr, and call rc.subr's rc_cmd command with $1 (which represents a command, like 'start', 'stop', 'restart', etc.). rc.subr, meanwhile, holds all the complexity one will ever likely need in an initscript, in the form of various shell functions encapsulating things like starting, stopping, etc. And if that's not enough for whatever reason, it's easy to add more functionality either to the individual initscript or to rc.subr, since it's shell scripts all the way down. In my experience, reasoning about this sucks a lot less than writing a systemd unit file, let alone an initscript on a system without such niceties.
- digi_owl 11y ago
  That is the crazy part, systemd at its core is a reaction to sysv (and upstart). In part part the reaction is to the boilerplate nature of sysv scripts, as they bring all their logic with them. but if you glance outside the RH/Debian sphere you find the likes of Slackware, that has been using BSD style init for decades.
  - yellowapple 11y ago
    Slackware's a bit of a peculiar case. It does indeed use /etc/rc.d in a somewhat-BSD-style manner, but there are two key differences: * Slackware doesn't use a BSD-style /etc/rc.conf. Instead, daemons are enabled/disabled by setting the executable flag on each initscript. While this loses some of the features of /etc/rc.conf, I personally like this method better. * Slackware doesn't include an equivalent to /etc/rc.d/rc.subr, which means there's a lot of boilerplate in its initscripts. But yes, systemd's primary objections to shell-based init systems in general seem to stem from a limited scope.

by jveld 11y ago

thaumaturgy 11y ago

This is why I suspect that most of the divisions in the sysadmin community regarding systemd are generational. For people (like me!) who have been writing init scripts forever and can do it in their sleep, they'd prefer the flexibility and familiarity of init scripts to a new system that at first glance appears more limited. For people who are less experien^H^H^H^H^H^H^H^Hcrusty :-), init scripts look like a horrifying way to manage a startup process, and just about anything -- including Yet Another Config File Format -- looks preferable. I think this is also why so little progress is being made on resolving conflicts over systemd. There really isn't a whole lot of room for compromise; one group simply wants things to stay more or less the same (or evolve incrementally), the other group simply wants to throw it all out and start over. I bet there would've been a lot less argument and vitriol about systemd if Debian hadn't made the decision to default to it, basically leaving all the crusty sysadmins homeless. Once Debian switched, there was a near guarantee that all of Linux was going to move to systemd. That suits one group just fine, another one not so much. On the plus side, the BSDs should be seeing a really nice upswell of installations over the next couple of years, which is great, because they've been quietly building some pretty great operating systems that deserve more love.

chousuke 11y ago
It's perfectly possible to run scripts with systemd unit files, so there's no real "flexibility" lost anywhere. The primary improvement is that systemd handles by default most of what used to be boiler-plate in every script, on top of calculating dependencies automatically. Then you get integrated process supervisor capabilities so that the init system actually knows whether services are running or not. Speed was certainly a major motivator as well, considering the increasing popularity of containers and on-demand virtual machines. To me it seems that "gradual evolution" was exactly what they did, and it wasn't really going anywhere. Lennart came up with systemd and convinced enough people that it's worth the pain of migration to get a clean start.
- VLM 11y ago
  The key is the expense vs reward ratio. I don't know how to write sysvinit scripts any more than I know how to write fizzbuzz. What I do know is how to program and specifically how to write and maintain and debug shell scripts. I NEED that for other automation purposes and cannot get rid of that mandatory requirement so it used to dovetail quite well with init scripts. There are corner cases and security issues and tradition, which means copying a known good init script and editing nothing but the executable names is a great start, but its not really a serious problem. I don't care if its verbose, as long as its simple and understandable and most importantly, predictable. Now instead of applying a language and tradition I know to a simple task like init, I get to learn a whole new ecosystem and technology to do about the same thing I always did except vastly more complicated, and I can't even shed the old knowledge because its needed elsewhere. That makes overall systems harder to use, slower, buggier, and less reliable. And thats defined as "progress" because its new so it must be better.
  - EmanueleAina 11y ago
    I don't think it's really fair to compare writing unit files to being able to program in shell. True, knowing the systemd unit options is not a reusable skill, but it's not a huge effort either: the syntax is trivial (INI-inspired, the same as .desktop files) and the options themselves are rather well documented. And for sure, these options are immensely more reusable when writing a new unit file than mixing and matching shell snippets taken from different init script using different styles and conventions. (Not to mention how subtly tricky programming in shell is even when you're doing trivial things, see http://www.dwheeler.com/essays/filenames-in-shell.html http://www.dwheeler.com/essays/filenames-in-shell.html )

yellowapple 11y ago

The nice thing about initscripts, though, is that you can get the best of both worlds by sourcing in common functions, as is the default and recommended practice on OpenBSD. For example, here's the initscript for dovecot on my (OpenBSD-running) mail server (with some comments and newlines omitted for brevity): daemon="/usr/local/sbin/dovecot" . /etc/rc.d/rc.subr rc_cmd $1 Pretty straightforward: you set $daemon to the path of your daemon's executable (in this case, dovecot), source in rc.subr, and call rc.subr's rc_cmd command with $1 (which represents a command, like 'start', 'stop', 'restart', etc.). rc.subr, meanwhile, holds all the complexity one will ever likely need in an initscript, in the form of various shell functions encapsulating things like starting, stopping, etc. And if that's not enough for whatever reason, it's easy to add more functionality either to the individual initscript or to rc.subr, since it's shell scripts all the way down. In my experience, reasoning about this sucks a lot less than writing a systemd unit file, let alone an initscript on a system without such niceties.

digi_owl 11y ago
That is the crazy part, systemd at its core is a reaction to sysv (and upstart). In part part the reaction is to the boilerplate nature of sysv scripts, as they bring all their logic with them. but if you glance outside the RH/Debian sphere you find the likes of Slackware, that has been using BSD style init for decades.
- yellowapple 11y ago
  Slackware's a bit of a peculiar case. It does indeed use /etc/rc.d in a somewhat-BSD-style manner, but there are two key differences: * Slackware doesn't use a BSD-style /etc/rc.conf. Instead, daemons are enabled/disabled by setting the executable flag on each initscript. While this loses some of the features of /etc/rc.conf, I personally like this method better. * Slackware doesn't include an equivalent to /etc/rc.d/rc.subr, which means there's a lot of boilerplate in its initscripts. But yes, systemd's primary objections to shell-based init systems in general seem to stem from a limited scope.