8 ms·

What should we expect from a modern init system?

62 points by martius 13y ago

samworm 13y ago
I personally prefer systemd to upstart. I just hope that distros (in this case Debian) stick to a technical review and don't get drawn into ad hominem arguments. For many people it seems the answer to the question posed in the post title is "I would expect it to not be designed/authored by the man behind pulseaudio".
- martius 13y ago
  One argument that is on the edge: Lennart often takes controversial decisions, and in the case of systemd, he refuses portability patches that would allow systemd to run on other unixes than Linux (BSD, Hurd, etc). Since debian is supposed to be universal (hence, support alternative Unix kernels), choosing systemd barely means that they will have to drop this trait of the distribution.
  - krakensden 13y ago
    I suspect that if someone actually did the work to port systemd, upstream would be nicer. I have mixed feelings about the BSD & Hurd ports. "You shall not crucify Debian Linux upon a cross of Hurd" and all that.
    - adestefan 13y ago
      I'm pretty much done with Debian because of this. I have one last server to migrate and then I'll never have to deal with the personalities and preaching again.
  - fournm 13y ago
    Upstart also has the issue of being non-portable as of right now, so either way a porting effort has to be actually undertaken (even if Upstart is saying that it's planned)--And Debian is adopting large amounts of systemd for other systems. Lennart hate is fine, but let systemd stand on its technical merits (or lack thereof, if you really feel that way).
    - yxhuvud 13y ago
      A lot less non-portable though. There are people that have managed to boot it on kFreebsd. https://lists.ubuntu.com/archives/upstart-devel/2014-January/003010.html https://lists.ubuntu.com/archives/upstart-devel/2014-January... But yes, it is still a work in progress.
  - theophrastus 13y ago
    There is an observed situation in evolutionary ecology which the response to Lennart rather reminds me of: the case of the overwhelming singular adaptive advantage. An ecological situation arises which gives one subspecies a huge, but temporary, advantage. So huge that all the other subspecies are competed to extinction. But that advantage was an advantage in only one aspect of survival and now there's a monoculture (which we all know is more fragile against future threats). If there's a latent, (or perhaps overt?), Lennart-phobia, it's that he possesses that one temporary huge advantage which will lead us to a monoculture? ...or not, this is just a curious analogy [shrug]
    - codezero 13y ago
      Up until this debate, I don't think most people were aware that there was even an init-culture to fear turning into a monoculture :) I think your observation is true though.
  - bkor 13y ago
    Various features that systemd exposes have no equivalent in other kernels. This makes it impossible. He also explained various times why he refuses non-complete portability patches. This because you get more ifdefs and those are difficult to test/guarantee. He and Kay claimed that kdbus couldn't be used for Binder as well. Greg thought it was possible. Only after writing kdbus he came to the conclusion that Lennart+Kay had it right. Suggest to write a complete patch to make systemd work on FreeBSD. I assume you'll discover Lennart is right :-P
    - martius 13y ago
      Actually, feasible or not, I understand and somewhat agree with the fact that they don't want portability patches, it would probably force systemd to be limited to the lowest common denominator and add a lot of complexity to the project. However, I was wondering if platform-specific forks are a sustainable solution.
    - pmarin 13y ago
      You do not get portable code with ifdefs, you only get 2 non portable programs in the same file.
- Shish2k 13y ago
  > I would expect it to not be designed/authored by the man behind pulseaudio Having used a bunch of Lennart's software, I'm generally coming to the conclusion that he's better at ideas than code -- but once his projects take off and the bugs get fixed, the end result is significantly better than what we had before. (Using pulseaudio as a specific example, per-app volume controls and easily mixing and matching sound sources and playback devices; seamlessly switching from speakers to headphones to HDMI to a sound server on another PC entirely, etc -- features that are too high-level for the kernel and too low-level for applications, and thus can only be brought into existence by a fairly large change in the audio stack)
nitrogen 13y ago
I would prefer a parallelized dependency-based init system over an event-triggered system. I want to be able to say "start openssh" and have networking start with it automatically, for example, like Gentoo used to have (or still does?).
- Tuna-Fish 13y ago
  systemd does exactly that.
  - anaphor 13y ago
    Not exactly. It does do stuff concurrently, but not always in "parallel" since it may only have 1 core available or not get scheduled across multiple cores. I disagree with that particular wording of the systemd description because it perpetuates the concurrency == parallelism misunderstanding. Not that I don't like systemd, I've been using it for over a year and haven't had any issues, and its concurrent model does seem to improve boot times somewhat and there's no more figuring out how to order your daemons since it handles that for you.
    - ambrop7 13y ago
      And there is no need to make it parallel. There is very little computation the init itself needs to do - most of the time it is waiting for things to happen, and the time it takes to react to events is negligible.
- mverwijs 13y ago
  I would prefer to do my own thinking, not have the computer try to outsmart me. It can't, and it always hurts my sleepcycles when it tries.
  - Groxx 13y ago
    Not sure how this applies. I assume you automate some things that you could simply type in by hand every single time, why not this?
brokenparser 13y ago
I expect an init system to be an init system, not to also be pm-utils, (x)inetd, acpid, syslogd, watchdog, cron and atd. I also expect it to have configuration files I can change, not to have everything symlinked to /usr. (If I can even find the right configuration file in that mess of directories, that is.)
- antihero 13y ago
  It's quite trivial to override services - you just cp /usr/lib/systemd/system/myservice to /etc/systemd/system/myservice and edit it there. This has the advantage of not having you screw up the actual package managed files, too.
  - rodgerd 13y ago
    No, you don't copy it! Source it ( . /usr/lib/systemd/system/myservice at the head of /etc/systemd/system/myservice ) then override the lines you want to change. Much easier for upgrades.
    - antihero 13y ago
      Neat! Thanks for that.
- Elhana 13y ago
  If Lennart Poettering were building a bicycle, it would have multiple seats, 4 wheels, engine, conditioner, bar, sat tv, console and small pool on it. You would be able to remove most of it tho... maybe. If you try to remove the engine, it would complain that modern all bicycles are broken without engines, but you can do it at your own risk.
  - bkor 13y ago
    Your comparison makes no sense at all. E.g. systemd dependencies are minimal. My take: if he builds a bicycle it would be lean, fast and he'd analyse all existing designs to make that happen.
mverwijs 13y ago
I still do not understand what problem upstart or systemd are trying to solve. Slow boot times? Have you ever even booted an HP DL360? Or any server? Of the entire 8 minute or so process, sysv init only takes up 10 seconds. So what is the problem? Containers of Debian 7 (openvz) start in seconds, with sysv init. My laptop dito. What am I missing? Android? That takes forever to boot and I have no idea why. Could be that systemd fixes that problem. To me, Systemd and upstart come across as modern-for-the-sake-of-being-modern.
- icebraining 13y ago
  As far as I know, it's just features, features, features: http://0pointer.de/blog/projects/why.html http://0pointer.de/blog/projects/why.html
- agumonkey 13y ago
  Server hardware init is also a problem, the Coreboot project started because of that (IIRC one admin mentioned something in ~hour for a cluster).
- hdevalence 13y ago
  The post linked describes quite well an example situation systemd solves, and why something like systemd is needed. Perhaps you should look at it.
  - otterley 13y ago
    Isn't that an implementation detail though? sysvinit is just a series of scripts that are grouped by runlevel. It says nothing about what those scripts must do; it could very well be that a better implementation of the mounting scripts fixes the problem without having to throw out the baby with the bathwater.
    - mansr 13y ago
      OpenRC is exactly that.
    - 13y ago
scarmig 13y ago
PulseAudio was wonky in 2005, therefore sysvinit forever.
- sparkie 13y ago
  PulseAblipudio is still wonky in 2014 if you need to use it alongside JACK.
  - bkor 13y ago
    You can easily pause pulseaudio while the Jack program is running. I saw the development discussion to make that happen automatically. Further, there are various ways to do that. Seems at most a problem with how it is integrated in your distribution.
    - fmoralesc 13y ago
      You don't even need to pause PA. See, for example, what cadence[^1] does to bridge PA and Jack. [1]: http://kxstudio.sourceforge.net/Applications:Cadence http://kxstudio.sourceforge.net/Applications:Cadence
Myk267 13y ago
Does anyone else feel like the only reason to choose systemd is the systemd-journal? That thing is just amazing. The amount of leverage provided by not just appending to a log file somewhere will really get the juices moving in anyone who ever had to write some ad-hoc parser to do the same thing poorly. If anyone hasn't tried out systemd or journalctl yet, I suggest running a copy of Arch Linux in a virtual machine.
- Zancarius 13y ago
  I think the unit files are another reason. Over the years, my patience with differing ideas of how an initscript should function has waned to the point that it's almost an exercise in frustration if it's not something you regularly write on a platform you seldom use. Unit files alone make systemd a breath of fresh air, because familiarizing yourself with them requires reading only the manpages (and even then only the applicable portions). Even somewhat esoteric behaviors are readily supported without much effort. I realize initscripts are "simple" in the sense that they borrow immediately from the shell and therefore possess all the advantages (and disadvantages) implied by such. Unfortunately, the notion of a sane initscript seems to be greatly varied in the sense that it depends largely on the distribution and the package maintainers. It isn't that they're necessarily difficult to write as much as having the power of the shell available inclines some authors to do very stupid things. Comparatively speaking, a unit file should be exceptionally easy to understand at first blush.
chousuke 13y ago
Personally, I prefer systemd. I have quite a shallow understanding of upstart, but even so I find a dependency-based model much easier to reason about than an event-based model. I'm quite sure either would be a massive improvement over sysvinit though.
atmosx 13y ago
I'm tired reading about this. It seems to boil down to politics, mostly and features less... The team with the better players will win this. What is interesting though, is to see how the BSD ecosystem will handle this. Will they adapt in time or they will lag even further behind this? * NetBSD might reached the point of virtual insignificance long time ago. * OpenBSD is out of funds - which is a shame considering the software they produced (PF, OpenSSH, OpenNTPD), but their indifference for desktop makes them obsolete. * FreeBSD (I use it in both my servers) is the most up-to-date but now with system-d/upstart not supported, I think they will run into trouble relative soon. Darwin said it best: the ones most adaptable to change survive. Of course, the other happy scenario is that given the fact that these OSes power some big-corp servers, these big-corps will step in and fund these projects, I wouldn't hold my breath though.
- rodgerd 13y ago
  I'm pretty sure that FreeBSD are ressurecting their OS X-derived launchd experiment to get a better init. The argument that sysv "is Unix" is pretty much horseshit at this point. Solaris and OS X don't use a sysv style init, most of Linux doesn't any more (either upstart or systemd). At this point one is redefining "real Unix" down to NetBSD and HP-UX.
  - profquail 13y ago
    Here's the link to the port-in-progress of launchd to FreeBSD, if anyone is curious: https://github.com/rtyler/openlaunchd https://github.com/rtyler/openlaunchd
- Sssnake 13y ago
  You seem to be under the mistaken impression that netbsd and openbsd users demand the lastest in temporary, throw away, bloated, buggy shitware that linux distos are jumping on at any given moment. The fact that they don't use that crap is their main selling point. And no, netbsd is not "virtual insignifance", openbsd is not out of funds (they got over $100k just when they asked for $20k recently, and idiots take that to mean they are dead?). FreeBSD is not the most up to date, it is the most linux-like. Why do you think it is so impossible for them to also start using this pile of shit if that is what their userbase wants?

62 points by martius 13y ago

I personally prefer systemd to upstart. I just hope that distros (in this case Debian) stick to a technical review and don't get drawn into ad hominem arguments. For many people it seems the answer to the question posed in the post title is "I would expect it to not be designed/authored by the man behind pulseaudio".

martius 13y ago
One argument that is on the edge: Lennart often takes controversial decisions, and in the case of systemd, he refuses portability patches that would allow systemd to run on other unixes than Linux (BSD, Hurd, etc). Since debian is supposed to be universal (hence, support alternative Unix kernels), choosing systemd barely means that they will have to drop this trait of the distribution.
- krakensden 13y ago
  I suspect that if someone actually did the work to port systemd, upstream would be nicer. I have mixed feelings about the BSD & Hurd ports. "You shall not crucify Debian Linux upon a cross of Hurd" and all that.
  - adestefan 13y ago
    I'm pretty much done with Debian because of this. I have one last server to migrate and then I'll never have to deal with the personalities and preaching again.
- fournm 13y ago
  Upstart also has the issue of being non-portable as of right now, so either way a porting effort has to be actually undertaken (even if Upstart is saying that it's planned)--And Debian is adopting large amounts of systemd for other systems. Lennart hate is fine, but let systemd stand on its technical merits (or lack thereof, if you really feel that way).
  - yxhuvud 13y ago
    A lot less non-portable though. There are people that have managed to boot it on kFreebsd. https://lists.ubuntu.com/archives/upstart-devel/2014-January/003010.html https://lists.ubuntu.com/archives/upstart-devel/2014-January... But yes, it is still a work in progress.
- theophrastus 13y ago
  There is an observed situation in evolutionary ecology which the response to Lennart rather reminds me of: the case of the overwhelming singular adaptive advantage. An ecological situation arises which gives one subspecies a huge, but temporary, advantage. So huge that all the other subspecies are competed to extinction. But that advantage was an advantage in only one aspect of survival and now there's a monoculture (which we all know is more fragile against future threats). If there's a latent, (or perhaps overt?), Lennart-phobia, it's that he possesses that one temporary huge advantage which will lead us to a monoculture? ...or not, this is just a curious analogy [shrug]
  - codezero 13y ago
    Up until this debate, I don't think most people were aware that there was even an init-culture to fear turning into a monoculture :) I think your observation is true though.
- bkor 13y ago
  Various features that systemd exposes have no equivalent in other kernels. This makes it impossible. He also explained various times why he refuses non-complete portability patches. This because you get more ifdefs and those are difficult to test/guarantee. He and Kay claimed that kdbus couldn't be used for Binder as well. Greg thought it was possible. Only after writing kdbus he came to the conclusion that Lennart+Kay had it right. Suggest to write a complete patch to make systemd work on FreeBSD. I assume you'll discover Lennart is right :-P
  - martius 13y ago
    Actually, feasible or not, I understand and somewhat agree with the fact that they don't want portability patches, it would probably force systemd to be limited to the lowest common denominator and add a lot of complexity to the project. However, I was wondering if platform-specific forks are a sustainable solution.
  - pmarin 13y ago
    You do not get portable code with ifdefs, you only get 2 non portable programs in the same file.
Shish2k 13y ago
> I would expect it to not be designed/authored by the man behind pulseaudio Having used a bunch of Lennart's software, I'm generally coming to the conclusion that he's better at ideas than code -- but once his projects take off and the bugs get fixed, the end result is significantly better than what we had before. (Using pulseaudio as a specific example, per-app volume controls and easily mixing and matching sound sources and playback devices; seamlessly switching from speakers to headphones to HDMI to a sound server on another PC entirely, etc -- features that are too high-level for the kernel and too low-level for applications, and thus can only be brought into existence by a fairly large change in the audio stack)

nitrogen 13y ago

I would prefer a parallelized dependency-based init system over an event-triggered system. I want to be able to say "start openssh" and have networking start with it automatically, for example, like Gentoo used to have (or still does?).

Tuna-Fish 13y ago
systemd does exactly that.
- anaphor 13y ago
  Not exactly. It does do stuff concurrently, but not always in "parallel" since it may only have 1 core available or not get scheduled across multiple cores. I disagree with that particular wording of the systemd description because it perpetuates the concurrency == parallelism misunderstanding. Not that I don't like systemd, I've been using it for over a year and haven't had any issues, and its concurrent model does seem to improve boot times somewhat and there's no more figuring out how to order your daemons since it handles that for you.
  - ambrop7 13y ago
    And there is no need to make it parallel. There is very little computation the init itself needs to do - most of the time it is waiting for things to happen, and the time it takes to react to events is negligible.
mverwijs 13y ago
I would prefer to do my own thinking, not have the computer try to outsmart me. It can't, and it always hurts my sleepcycles when it tries.
- Groxx 13y ago
  Not sure how this applies. I assume you automate some things that you could simply type in by hand every single time, why not this?

brokenparser 13y ago

I expect an init system to be an init system, not to also be pm-utils, (x)inetd, acpid, syslogd, watchdog, cron and atd. I also expect it to have configuration files I can change, not to have everything symlinked to /usr. (If I can even find the right configuration file in that mess of directories, that is.)

antihero 13y ago
It's quite trivial to override services - you just cp /usr/lib/systemd/system/myservice to /etc/systemd/system/myservice and edit it there. This has the advantage of not having you screw up the actual package managed files, too.
- rodgerd 13y ago
  No, you don't copy it! Source it ( . /usr/lib/systemd/system/myservice at the head of /etc/systemd/system/myservice ) then override the lines you want to change. Much easier for upgrades.
  - antihero 13y ago
    Neat! Thanks for that.
Elhana 13y ago
If Lennart Poettering were building a bicycle, it would have multiple seats, 4 wheels, engine, conditioner, bar, sat tv, console and small pool on it. You would be able to remove most of it tho... maybe. If you try to remove the engine, it would complain that modern all bicycles are broken without engines, but you can do it at your own risk.
- bkor 13y ago
  Your comparison makes no sense at all. E.g. systemd dependencies are minimal. My take: if he builds a bicycle it would be lean, fast and he'd analyse all existing designs to make that happen.

mverwijs 13y ago

I still do not understand what problem upstart or systemd are trying to solve. Slow boot times? Have you ever even booted an HP DL360? Or any server? Of the entire 8 minute or so process, sysv init only takes up 10 seconds. So what is the problem? Containers of Debian 7 (openvz) start in seconds, with sysv init. My laptop dito. What am I missing? Android? That takes forever to boot and I have no idea why. Could be that systemd fixes that problem. To me, Systemd and upstart come across as modern-for-the-sake-of-being-modern.

icebraining 13y ago
As far as I know, it's just features, features, features: http://0pointer.de/blog/projects/why.html http://0pointer.de/blog/projects/why.html
agumonkey 13y ago
Server hardware init is also a problem, the Coreboot project started because of that (IIRC one admin mentioned something in ~hour for a cluster).
hdevalence 13y ago
The post linked describes quite well an example situation systemd solves, and why something like systemd is needed. Perhaps you should look at it.
- otterley 13y ago
  Isn't that an implementation detail though? sysvinit is just a series of scripts that are grouped by runlevel. It says nothing about what those scripts must do; it could very well be that a better implementation of the mounting scripts fixes the problem without having to throw out the baby with the bathwater.
  - mansr 13y ago
    OpenRC is exactly that.
  - 13y ago

scarmig 13y ago

PulseAudio was wonky in 2005, therefore sysvinit forever.

sparkie 13y ago
PulseAblipudio is still wonky in 2014 if you need to use it alongside JACK.
- bkor 13y ago
  You can easily pause pulseaudio while the Jack program is running. I saw the development discussion to make that happen automatically. Further, there are various ways to do that. Seems at most a problem with how it is integrated in your distribution.
  - fmoralesc 13y ago
    You don't even need to pause PA. See, for example, what cadence[^1] does to bridge PA and Jack. [1]: http://kxstudio.sourceforge.net/Applications:Cadence http://kxstudio.sourceforge.net/Applications:Cadence

Myk267 13y ago

Does anyone else feel like the only reason to choose systemd is the systemd-journal? That thing is just amazing. The amount of leverage provided by not just appending to a log file somewhere will really get the juices moving in anyone who ever had to write some ad-hoc parser to do the same thing poorly. If anyone hasn't tried out systemd or journalctl yet, I suggest running a copy of Arch Linux in a virtual machine.

Zancarius 13y ago
I think the unit files are another reason. Over the years, my patience with differing ideas of how an initscript should function has waned to the point that it's almost an exercise in frustration if it's not something you regularly write on a platform you seldom use. Unit files alone make systemd a breath of fresh air, because familiarizing yourself with them requires reading only the manpages (and even then only the applicable portions). Even somewhat esoteric behaviors are readily supported without much effort. I realize initscripts are "simple" in the sense that they borrow immediately from the shell and therefore possess all the advantages (and disadvantages) implied by such. Unfortunately, the notion of a sane initscript seems to be greatly varied in the sense that it depends largely on the distribution and the package maintainers. It isn't that they're necessarily difficult to write as much as having the power of the shell available inclines some authors to do very stupid things. Comparatively speaking, a unit file should be exceptionally easy to understand at first blush.

chousuke 13y ago

Personally, I prefer systemd. I have quite a shallow understanding of upstart, but even so I find a dependency-based model much easier to reason about than an event-based model. I'm quite sure either would be a massive improvement over sysvinit though.

atmosx 13y ago

I'm tired reading about this. It seems to boil down to politics, mostly and features less... The team with the better players will win this. What is interesting though, is to see how the BSD ecosystem will handle this. Will they adapt in time or they will lag even further behind this? * NetBSD might reached the point of virtual insignificance long time ago. * OpenBSD is out of funds - which is a shame considering the software they produced (PF, OpenSSH, OpenNTPD), but their indifference for desktop makes them obsolete. * FreeBSD (I use it in both my servers) is the most up-to-date but now with system-d/upstart not supported, I think they will run into trouble relative soon. Darwin said it best: the ones most adaptable to change survive. Of course, the other happy scenario is that given the fact that these OSes power some big-corp servers, these big-corps will step in and fund these projects, I wouldn't hold my breath though.

rodgerd 13y ago
I'm pretty sure that FreeBSD are ressurecting their OS X-derived launchd experiment to get a better init. The argument that sysv "is Unix" is pretty much horseshit at this point. Solaris and OS X don't use a sysv style init, most of Linux doesn't any more (either upstart or systemd). At this point one is redefining "real Unix" down to NetBSD and HP-UX.
- profquail 13y ago
  Here's the link to the port-in-progress of launchd to FreeBSD, if anyone is curious: https://github.com/rtyler/openlaunchd https://github.com/rtyler/openlaunchd
Sssnake 13y ago
You seem to be under the mistaken impression that netbsd and openbsd users demand the lastest in temporary, throw away, bloated, buggy shitware that linux distos are jumping on at any given moment. The fact that they don't use that crap is their main selling point. And no, netbsd is not "virtual insignifance", openbsd is not out of funds (they got over $100k just when they asked for $20k recently, and idiots take that to mean they are dead?). FreeBSD is not the most up to date, it is the most linux-like. Why do you think it is so impossible for them to also start using this pile of shit if that is what their userbase wants?