12 ms·

Why systemd is winning the init wars and other things aren't

129 points by onestone 13y ago

ChuckMcM 13y ago
Interesting follow-up, this stuck out for me: "To start with and as usual, social problems are the real problems." This really resonates with me. Once any organization gets to a certain size, getting change to happen is more "social problem" and less "technical problem." When you don't select for people at that stage who can move an entire organization over to a new way of doing things, your organization will stagnate and die. It used to really annoy me at Google when technical evaluators who dismiss those "soft qualities" in candidates. I had a fairly famous Googler tell me point blank that anyone could change the organization by shouting loudly enough. Which I tried to explain was just as false as saying anyone can solve a problem if they write enough code. But alas, they were not ready to hear that at the time. The author makes an excellent point that much of the root of the "disagreement" can be summed up with a strong sense of "I wouldn't have done it that way." Which is no doubt true, but it has to be combined with "I would do it like this, and I'm willing to spend the next 3 - 5 years listening to the community and addressing their concerns." I certainly see that is a much bigger commitment.
- theophrastus 13y ago
  yes indeed social problems. or as one of my favorite quotes goes: "Trust no one! The minute God crapped out the third caveman, a conspiracy was hatched against one of them!" --Col. Hunter Gathers, OSI (Venture Bros parody of Hunter S. Thompson)
  - teddyh 13y ago
    More likely, three conspiracies were hatched, one against each one of them.
  - bitwize 13y ago
    One of the reasons why the Blue Man Group perform in groups of three is because if you have one person, you have one person. If you have two people, they either agree or disagree. Three is the minimum number of people it took for there to be an outsider.
rdn 13y ago
Hopefully what happened with pulseaudio does not happen with init
- Elv13 13y ago
  press "E" in grub, then add init="/bin/busybox" to the kernel command line. Then apt-get purge systemd (mounting may or may not be necessary). That way you can still claim "the first thing I did was to remove it". But contrary to pulse, it will also be the last ;)
- stephen_g 13y ago
  It can't really - the problem with PulseAudio was that it was adopted by a major Linux distribution before it was ready for primetime. It worked well after a while. Systemd is has been the main init system of several distributions (like Fedora) for some time now, so I wouldn't worry.
throwaway092834 13y ago
This article is a bit off the mark. Daemontools and runit didn't replace init because they weren't designed to replace init, or to be exclusive technical choices in general. Non-exclusivity means no displacement, just happy co-habitation. Daemontools and runit work great under sysv init, BSD init, or under systemd. There's a little piece of insight which seems to escape many: there is no serious technical reason why systemd must run as init. Systemd could have been written to coexist in a number of various ways following previous models, running under init and doing things for init. Systemd is winning this war because it created the war, by conflicting with sysv init.
- Fasebook 13y ago
  Thank you for your excellent insight, as I would have never considered nesting inits.
- chrisbolt 13y ago
  runit seems to have been designed to be able to replace init: http://smarden.org/runit/replaceinit.html http://smarden.org/runit/replaceinit.html
  - throwaway092834 13y ago
    It's possible, but it's not designed to. It was designed to run under init, as a daemontools clone. Explained further here: http://smarden.org/pape/djb/daemontools/noinit.html http://smarden.org/pape/djb/daemontools/noinit.html "In contrary to Richard Gooch, I suggest not to implement service dependencies and runlevel handling in the Unix process no 1, /sbin/init, keep it small and simple, that is why I wrote the runit package"
- vacri 13y ago
  The article specifically says what you're saying: I don't think any of them have really been developed with replacing SysV init in Linux distributions or elsewhere as a goal. DJB daemontools certainly wasn't Systemd is winning this war because it created the war, by conflicting with sysv init. Upstart predates Systemd, systemd just has more traction.
pdkl95 13y ago
"none of these alternate init systems did the hard work to actually become a replacement init system for anything much" And yet again, the anti-init-choice people show how they still don't understand the argument many of us have against the systemd change. This accusation presupposes that a change was necessary or desired in the first place. Sorry, no, some of these things should not be tied together. Without that tying, we already have (known, tested) tools that cover most of these features. Yes, I understand that some people have needs that require more (or different) features in their init process. So they should use systemd or whatever else solves those needs. Requirements and uses for general purpose computers vary a lot, though - especially in an environment like UNIX that encourages customization. My needs, for example, were mostly met by OpenRC's reworking of sysvinit. Some minor customization solved that problem completely. I recognize that some people see systemd as a good fit for their needs. Why do the anti-choice people refuse to recognize that other people might have different requirements. Again, I'm fine with systemd, as an option. It's the bundling and takeover of all the other tools that is a large part of the problem. Blaming others because we didn't implement your made up requirements is another part. Acting like a monopoly and tying other projects together to force upgrade because of vertical integration is yet another part that makes me question motive in addition to the technical issues. You want us to support systemd? Disconnect it from other stuff like the INIT (pid=0), the logger, and IPC (dbus). Allow all those to remain as they were previously. Let systemd be just the process launcher/manager, and allow let all of those parts work stand-alone with existing tools. Note: providing more features when your tools are used together is fine (and expected). This way, the software can stand on it sown, and if it really is big of an improvement as the systemd supports suggest, the migration will happen naturally over time. If, on the other hand, using one tool continues to have the requirement of trading many other system-level tools that I already know and use, for unproven newcomers that seem to ignore the lessons of the past, well... I'm sticking with what already works.
- colin_mccabe 13y ago
  systemd runs as pid 0 so that it can relaunch processes when they die. If it were not pid 0, something would have to be managing it, which just leads to a "turtles all the way down" scenario. I'm not sure what you mean by "disconnecting from dbus," but I do know that some services require the d-bus service to be started before they run. A good init system must handle that. Similarly, a good init system needs to handle logging. It's frustrating to try to start a service and be unable to, and not know why because a message dumped to stderr went to /dev/null. I've been in this boat before and it's not fun. Smart people at Red Hat spent a long time thinking about the problems faced by a modern init system. They looked at what had already been done, including the Mac init system, upstart, and the Solaris init system, and came up with something cool for Linux. I think it's sad that so many people are attacking this. Anyway, nobody is forcing you to use anything. You can use Slackware or even one of the BSDs if you don't want systemd.
Fasebook 13y ago
"init wars" what a joke. the fact that systemd has "declared war" on other init implementations is all the information I need.
- krakensden 13y ago
  See, you're missing all the fun drama: http://lwn.net/Articles/583182/ http://lwn.net/Articles/583182/
  - Fasebook 13y ago
    No thanks.
falconfunction 13y ago
What about openrc? https://wiki.gentoo.org/wiki/Comparison_of_init_systems https://wiki.gentoo.org/wiki/Comparison_of_init_systems What's up with the words words words
- exDM69 13y ago
  According to one of the links in the original article, OpenRC and sticking with SysVinit were also evaluated as options early in the discussions.
  - falconfunction 13y ago
    I'm sorry could you post a link? I just really don't like how this stuff is couched in words from either an apt/yum dudes blog that focuses on boot time.
    - exDM69 13y ago
      No, I can't post a link. That phornoix article only links to other phoronix articles and I can't find a way to an actual discussion thread or meeting minutes from people that were actually involved and I don't have time to search for one.
      - falconfunction 13y ago
        It's cool, everyone digs monolithic stuff anyway.
- rcxdude 13y ago
  I believe the main reason it wasn't really considered in the debian discussions was that they couldn't find any real documentation of it.
bifrost 13y ago
This seems like a solution in search of a problem. Yes, restarting broken/dead processes is handy, but this is not the job of init. I can't wait to run regedit.py to fix my broken box...
dschiptsov 13y ago
The same way any other crap (such as Windows, Java, PHP, NodeJS, Docker - you name it) wins - its winning is due to a "catchy meme" about it, which triggers an automatic, ignorant snap-judgement of an unsophisticated consumer. Look, with Java you don't have to think about hardware and OS - a greatest meme ever (and you have to pay for tons of hardware because Java = waste). NodeJS - you could code server-side apps the very same way you write stupid web-pages (without any deep knowledge) - great meme. With Docker no sysadmins are required, and an underlying operating system is just viewed an abstract "container" for an app (they you will pay to "experts" who would spend weeks analyzing why your crap is so slow and unpredictable in production). With systemd you don't have to understand the subtleties, and it is run with Docker. Yay! The list could be too long.
- dschiptsov 13y ago
  I forgot "the web-scale database" with stop-the-world write locks and syncing-buffers-is-not-my-problem and other innovations.
- d0 13y ago
  At least windows has a decent and stable init system though!
  - mkesper 13y ago
    That was a good one! ;)
  - dschiptsov 13y ago
    I think it is debatable whether or not a relation between words "windows" and "stable" makes any sense.
    - d0 13y ago
      I disagree. The 400-odd Windows machines under my command are incredibly stable, reliable and well performing. It's not Windows 98 any more.
spartango 13y ago
Petty politics aside, it seems to me that the comparisons between Systemd and Upstart are analogous to those between launchd and Solaris' SMF. The crux of the comparison is whether init should explicitly follow a dependency tree or resolve dependencies dynamically. The other complaints fall out of that concern: in following the launchd model of dynamic resolution, systemd is forced to bundle in complex features. On OSX launchd serves as a hub from day one, so coordinating IPC and mount-watching is not so foreign. Similarly, this hub functionality restricts modularity, although launchd doesn't subsume autofs fully. The reality here is that we're looking at a philosophical difference. While religious wars start over which is the "right" view, I'm unconvinced there is one. Much as SMF and launchd are comparably functional, so will upstart and systemd be.
wila 13y ago
I read his article and didn't see anything besides "it is better because well.. it is better" without much technical explanations on the why. Then read over it again and saw a link to his earlier article. http://utcc.utoronto.ca/~cks/space/blog/linux/SystemdRight http://utcc.utoronto.ca/~cks/space/blog/linux/SystemdRight which does help defend his position even while I don't share his opinion.
pyalot2 13y ago
Have you actually looked at what systemd does? Here's a handy chart curtesy of wikipedia: http://en.wikipedia.org/wiki/File:Systemd_components.svg http://en.wikipedia.org/wiki/File:Systemd_components.svg That just seems insane to me, what do I know... (admittedly not much about init systems) Still, systemd tries to do everything under the sun, it just doesn't seem like an init system, it seems systemd basically wants to be an operating system and assume all responsibilities as such.
- exDM69 13y ago
  > That just seems insane to me, what do I know... (admittedly not much about init systems) > Still, systemd tries to do everything under the sun, it just doesn't seem like an init system, it seems systemd basically wants to be an operating system and assume all responsibilities as such. Traditionally the things that systemd does were either done by a huge mess of shell scripts or were not done at all. There's no shortage of people who insist on doing things the way they were done before but to me, systemd makes a lot of sense. It's true that it combines things that were previously done by cron, acpid, getty, pam, etc to deal with power management, network connectivity and login, etc. But I still find it a better alternative than having a lot of distribution specific shell scripts gluing all those individual services together. Besides booting faster, there are advantages like better fault tolerance and consistency.
  - pyalot2 13y ago
    All those components that systemd manages, that's easily, I don't know how many millions of lines of code, and it all runs as pid 1, which, when it crashes, takes the whole system with it. Just doesn't seem terribly smart.
    - Aissen 13y ago
      Yeah, except systemd is a more a collection of daemons and tools under the same umbrella (and project repository), than a huge monolithic PID 1 daemon. It's even described in the chart you linked.
    - 13y ago
deleted 13y ago
[deleted]
awalton 13y ago
Wow. This is the sanest commentary about systemd and the state of things I've read to-date.
luuse 13y ago
The biggest fear i have after reading all of the latest articles popping up is that it's too monolithic, just as a lot of other people. However from reading on their faq it seems they've split out into several different processes and if the processes themselves are well scoped i can't really see the problem? I tried googling for something but i can't find any good documentation about what different processes systemd uses and how they interact and their roles in systemd? Anyone have any tips?
legulere 13y ago
Systemd is winning because it makes a Linux system to a modern one. The time where you compiled your own Linux kernel with the drivers you needed and got a static system are gone. The Linux kernel now works in a plug and play way. Block devices for instance can always pop up, not only after you wait and arbitrary amount of time at boot for all devices. The idea that the traditional unix process separation is enough is from the same time as the gets function. The Linux kernel here offers cgroups for better seperation.
- julie1 13y ago
  fallacy #23: argumentum ad novitatem
  - legulere 13y ago
    I'm not claiming that hot-plug is better, but that hot-plug is the status quo of the kernel. Modern here means that it integrates well with a modern linux kernel. Also grouping processes together and isolating them is not really new but a proven technology (FreeBSD jails, virtualization). It's also pretty hard to argue against that the knowledge about security of unix systems didn't increase. The irony about the fallacies is that just throwing them around even without writing a sentence goes against the very nature they were conceived in. The corresponding counter-question would be: "Why is modernity here something good?", but that question is already answered in the post to begin with.
    - julie1 13y ago
      You are right. I am actually in a phase of archeology where I read a lot of rob pikes, ken thompson, ted nelson, linus torvalds, esr ... (http://harmful.cat-v.org/ http://harmful.cat-v.org/) and I begin to question myself a lot of things. Even the statu quo. At work I deal with a lot of dependency hell (system and distributed software requirements, confinments (VM and chroot or jails)) and I begin to doubt some of "the wisdom and progress" I have been adopting. I search for answers now because I think some old "conceptual bugs" are bitting us very hard (like the way http url are built, threading, shared libraries, the abuse of concurrency) and I don't know anymore what progess is. I just kind of feel status quo is a very old hard rock band that should be forgotten :)
blueskin_ 13y ago
Because nobody wants Canonical to control a critical part of their distro.
- jude- 13y ago
  Upstart is "controlled" by Canonical in the same capacity that systemd is "controlled" by RedHat. Both have a team of full-time employees working on them (plus a surrounding community), and both control the APIs as well as the reference implementations.
- pekk 13y ago
  Better to have Red Hat in control of Debian, then?
  - blueskin_ 13y ago
    In preference to Canonical, yes. systemd is more open, has a greater count of contributors, and is already more widely adopted with more distros planning their move to it. I'm not saying it's without problems, but anything (including keeping sysvinit) is better than Upstart. GNOME is practically a Red Hat project these days, but people aren't advocating its removal (although yes, GNOME is awful since 3.x) As it is, Red Hat already maintain or otherwise have a hand in a lot of things that are in Debian - seeing them as somehow adversarial isn't true, while Canonical have a long tradition of keeping their own work close to their chest and not sending improvements upstream.
sparkie 13y ago
This article lacks any real substance, and perhaps that embodies my dislike of systemd in general. The demonstrate what I mean, I've modified the parent article, replacing "systemd" with "Windows", "sysv" with "Unix", and "init system" with "operating system", plus a bunch of other title changes to make it coherent, without really modifying the impression of the post: http://pastebin.com/sLsDVBG8 http://pastebin.com/sLsDVBG8 (Don't take it too serious.) Obviously this is just a bit of humor, but it sounds like something that could've been written in 1990, and the popular choice at the time has made at least a generation of developers and sysadmins suffer, and which some are still suffering from. I think the lesson we can learn is that "ideas" are not unimportant, and should be properly looked at before jumping to binding decisions, because what "solves your problem" now, may cause significantly more in the future.
evilDagmar 13y ago
There are _numerous_ problems with the argumentation being used here. Starting from the top, the first one is actually kind of silly. "none of these alternate init systems did the hard work to actually become a replacement init system for anything much." This conveniently overlooks whether or not there was any reason to do so. The scope of "classic" init is very simple. Its scope is well defined. It amounts to "start and stop the services when they're supposed to be started and stopped" and that is _all_. Those other init systems mentioned all expanded the scope of the problem of starting and stopping service a bit further, but only a tiny bit along the lines of deciding whether a county border should be on one side of a twisty creek or the other--in practice, very few people even care. Systemd expands its scope by _miles_ and strides boldly forth as a proud example of _scope creep_. The bulk of the rest of the argument amounts to "Well, systemd did all this hard work!". This isn't KINDERGARDEN. Its insane to argue that people should be giving systemd a free pass simply because the developers _worked really hard on it_. All those edge and corner and simply misbehaving daemon cases aren't things systemd should be more than peripherally concerned with--they're things to push back on the original developers to fix from the start, and in the meantime those workarounds should be held in their proper regard... as _workarounds_, not major features, because again... _scope creep_. Lastly, while they're busy giving systemd points for trying real hard and solving a bunch of problems that it shouldn't be bothering with, they ignore the fact that systemd was busily creating _new_ problems... but I'm sure they'll also credit systemd for solving those as well. Specifically Poettering himself recently posted about a "bug" with apparent filesystem corruption caused by systemd failing to properly unmount a filesystem when it's upgraded... during which at some point they appear to have decided that PID 1 is some mystical holy number (which it is _not_) and that going back to the initrd the system booted with is a completely fine and reasonable thing to do, and that it is not, in fact, a sign that one has seriously painted themselves into a corner. They're essentially arguing that they didn't paint themselves into a corner because they're standing in the middle of a long hallway... surrounded by paint... and that the real problem is the lack of roof access. It's a _huge_ workaround for what is simply not a problem for a small, simple initd that _only_ handles a small, well-defined problem and handles it correctly. ...but you pro-systemd people enjoy having to explain why half the core system functionality has to stop whenever you have to upgrade any of it. The rest of us will continue to use systems that do what they're supposed even while being upgraded.

129 points by onestone 13y ago

Interesting follow-up, this stuck out for me: "To start with and as usual, social problems are the real problems." This really resonates with me. Once any organization gets to a certain size, getting change to happen is more "social problem" and less "technical problem." When you don't select for people at that stage who can move an entire organization over to a new way of doing things, your organization will stagnate and die. It used to really annoy me at Google when technical evaluators who dismiss those "soft qualities" in candidates. I had a fairly famous Googler tell me point blank that anyone could change the organization by shouting loudly enough. Which I tried to explain was just as false as saying anyone can solve a problem if they write enough code. But alas, they were not ready to hear that at the time. The author makes an excellent point that much of the root of the "disagreement" can be summed up with a strong sense of "I wouldn't have done it that way." Which is no doubt true, but it has to be combined with "I would do it like this, and I'm willing to spend the next 3 - 5 years listening to the community and addressing their concerns." I certainly see that is a much bigger commitment.

theophrastus 13y ago
yes indeed social problems. or as one of my favorite quotes goes: "Trust no one! The minute God crapped out the third caveman, a conspiracy was hatched against one of them!" --Col. Hunter Gathers, OSI (Venture Bros parody of Hunter S. Thompson)
- teddyh 13y ago
  More likely, three conspiracies were hatched, one against each one of them.
- bitwize 13y ago
  One of the reasons why the Blue Man Group perform in groups of three is because if you have one person, you have one person. If you have two people, they either agree or disagree. Three is the minimum number of people it took for there to be an outsider.

rdn 13y ago

Hopefully what happened with pulseaudio does not happen with init

Elv13 13y ago
press "E" in grub, then add init="/bin/busybox" to the kernel command line. Then apt-get purge systemd (mounting may or may not be necessary). That way you can still claim "the first thing I did was to remove it". But contrary to pulse, it will also be the last ;)
stephen_g 13y ago
It can't really - the problem with PulseAudio was that it was adopted by a major Linux distribution before it was ready for primetime. It worked well after a while. Systemd is has been the main init system of several distributions (like Fedora) for some time now, so I wouldn't worry.

throwaway092834 13y ago

This article is a bit off the mark. Daemontools and runit didn't replace init because they weren't designed to replace init, or to be exclusive technical choices in general. Non-exclusivity means no displacement, just happy co-habitation. Daemontools and runit work great under sysv init, BSD init, or under systemd. There's a little piece of insight which seems to escape many: there is no serious technical reason why systemd must run as init. Systemd could have been written to coexist in a number of various ways following previous models, running under init and doing things for init. Systemd is winning this war because it created the war, by conflicting with sysv init.

Fasebook 13y ago
Thank you for your excellent insight, as I would have never considered nesting inits.
chrisbolt 13y ago
runit seems to have been designed to be able to replace init: http://smarden.org/runit/replaceinit.html http://smarden.org/runit/replaceinit.html
- throwaway092834 13y ago
  It's possible, but it's not designed to. It was designed to run under init, as a daemontools clone. Explained further here: http://smarden.org/pape/djb/daemontools/noinit.html http://smarden.org/pape/djb/daemontools/noinit.html "In contrary to Richard Gooch, I suggest not to implement service dependencies and runlevel handling in the Unix process no 1, /sbin/init, keep it small and simple, that is why I wrote the runit package"
vacri 13y ago
The article specifically says what you're saying: I don't think any of them have really been developed with replacing SysV init in Linux distributions or elsewhere as a goal. DJB daemontools certainly wasn't Systemd is winning this war because it created the war, by conflicting with sysv init. Upstart predates Systemd, systemd just has more traction.

pdkl95 13y ago

"none of these alternate init systems did the hard work to actually become a replacement init system for anything much" And yet again, the anti-init-choice people show how they still don't understand the argument many of us have against the systemd change. This accusation presupposes that a change was necessary or desired in the first place. Sorry, no, some of these things should not be tied together. Without that tying, we already have (known, tested) tools that cover most of these features. Yes, I understand that some people have needs that require more (or different) features in their init process. So they should use systemd or whatever else solves those needs. Requirements and uses for general purpose computers vary a lot, though - especially in an environment like UNIX that encourages customization. My needs, for example, were mostly met by OpenRC's reworking of sysvinit. Some minor customization solved that problem completely. I recognize that some people see systemd as a good fit for their needs. Why do the anti-choice people refuse to recognize that other people might have different requirements. Again, I'm fine with systemd, as an option. It's the bundling and takeover of all the other tools that is a large part of the problem. Blaming others because we didn't implement your made up requirements is another part. Acting like a monopoly and tying other projects together to force upgrade because of vertical integration is yet another part that makes me question motive in addition to the technical issues. You want us to support systemd? Disconnect it from other stuff like the INIT (pid=0), the logger, and IPC (dbus). Allow all those to remain as they were previously. Let systemd be just the process launcher/manager, and allow let all of those parts work stand-alone with existing tools. Note: providing more features when your tools are used together is fine (and expected). This way, the software can stand on it sown, and if it really is big of an improvement as the systemd supports suggest, the migration will happen naturally over time. If, on the other hand, using one tool continues to have the requirement of trading many other system-level tools that I already know and use, for unproven newcomers that seem to ignore the lessons of the past, well... I'm sticking with what already works.

colin_mccabe 13y ago
systemd runs as pid 0 so that it can relaunch processes when they die. If it were not pid 0, something would have to be managing it, which just leads to a "turtles all the way down" scenario. I'm not sure what you mean by "disconnecting from dbus," but I do know that some services require the d-bus service to be started before they run. A good init system must handle that. Similarly, a good init system needs to handle logging. It's frustrating to try to start a service and be unable to, and not know why because a message dumped to stderr went to /dev/null. I've been in this boat before and it's not fun. Smart people at Red Hat spent a long time thinking about the problems faced by a modern init system. They looked at what had already been done, including the Mac init system, upstart, and the Solaris init system, and came up with something cool for Linux. I think it's sad that so many people are attacking this. Anyway, nobody is forcing you to use anything. You can use Slackware or even one of the BSDs if you don't want systemd.

Fasebook 13y ago

"init wars" what a joke. the fact that systemd has "declared war" on other init implementations is all the information I need.

krakensden 13y ago
See, you're missing all the fun drama: http://lwn.net/Articles/583182/ http://lwn.net/Articles/583182/
- Fasebook 13y ago
  No thanks.

falconfunction 13y ago

What about openrc? https://wiki.gentoo.org/wiki/Comparison_of_init_systems https://wiki.gentoo.org/wiki/Comparison_of_init_systems What's up with the words words words

exDM69 13y ago
According to one of the links in the original article, OpenRC and sticking with SysVinit were also evaluated as options early in the discussions.
- falconfunction 13y ago
  I'm sorry could you post a link? I just really don't like how this stuff is couched in words from either an apt/yum dudes blog that focuses on boot time.
  - exDM69 13y ago
    No, I can't post a link. That phornoix article only links to other phoronix articles and I can't find a way to an actual discussion thread or meeting minutes from people that were actually involved and I don't have time to search for one.
    - falconfunction 13y ago
      It's cool, everyone digs monolithic stuff anyway.
rcxdude 13y ago
I believe the main reason it wasn't really considered in the debian discussions was that they couldn't find any real documentation of it.

bifrost 13y ago

This seems like a solution in search of a problem. Yes, restarting broken/dead processes is handy, but this is not the job of init. I can't wait to run regedit.py to fix my broken box...

dschiptsov 13y ago

The same way any other crap (such as Windows, Java, PHP, NodeJS, Docker - you name it) wins - its winning is due to a "catchy meme" about it, which triggers an automatic, ignorant snap-judgement of an unsophisticated consumer. Look, with Java you don't have to think about hardware and OS - a greatest meme ever (and you have to pay for tons of hardware because Java = waste). NodeJS - you could code server-side apps the very same way you write stupid web-pages (without any deep knowledge) - great meme. With Docker no sysadmins are required, and an underlying operating system is just viewed an abstract "container" for an app (they you will pay to "experts" who would spend weeks analyzing why your crap is so slow and unpredictable in production). With systemd you don't have to understand the subtleties, and it is run with Docker. Yay! The list could be too long.

dschiptsov 13y ago
I forgot "the web-scale database" with stop-the-world write locks and syncing-buffers-is-not-my-problem and other innovations.
d0 13y ago
At least windows has a decent and stable init system though!
- mkesper 13y ago
  That was a good one! ;)
- dschiptsov 13y ago
  I think it is debatable whether or not a relation between words "windows" and "stable" makes any sense.
  - d0 13y ago
    I disagree. The 400-odd Windows machines under my command are incredibly stable, reliable and well performing. It's not Windows 98 any more.

spartango 13y ago

Petty politics aside, it seems to me that the comparisons between Systemd and Upstart are analogous to those between launchd and Solaris' SMF. The crux of the comparison is whether init should explicitly follow a dependency tree or resolve dependencies dynamically. The other complaints fall out of that concern: in following the launchd model of dynamic resolution, systemd is forced to bundle in complex features. On OSX launchd serves as a hub from day one, so coordinating IPC and mount-watching is not so foreign. Similarly, this hub functionality restricts modularity, although launchd doesn't subsume autofs fully. The reality here is that we're looking at a philosophical difference. While religious wars start over which is the "right" view, I'm unconvinced there is one. Much as SMF and launchd are comparably functional, so will upstart and systemd be.

wila 13y ago

I read his article and didn't see anything besides "it is better because well.. it is better" without much technical explanations on the why. Then read over it again and saw a link to his earlier article. http://utcc.utoronto.ca/~cks/space/blog/linux/SystemdRight http://utcc.utoronto.ca/~cks/space/blog/linux/SystemdRight which does help defend his position even while I don't share his opinion.

pyalot2 13y ago

Have you actually looked at what systemd does? Here's a handy chart curtesy of wikipedia: http://en.wikipedia.org/wiki/File:Systemd_components.svg http://en.wikipedia.org/wiki/File:Systemd_components.svg That just seems insane to me, what do I know... (admittedly not much about init systems) Still, systemd tries to do everything under the sun, it just doesn't seem like an init system, it seems systemd basically wants to be an operating system and assume all responsibilities as such.

exDM69 13y ago
> That just seems insane to me, what do I know... (admittedly not much about init systems) > Still, systemd tries to do everything under the sun, it just doesn't seem like an init system, it seems systemd basically wants to be an operating system and assume all responsibilities as such. Traditionally the things that systemd does were either done by a huge mess of shell scripts or were not done at all. There's no shortage of people who insist on doing things the way they were done before but to me, systemd makes a lot of sense. It's true that it combines things that were previously done by cron, acpid, getty, pam, etc to deal with power management, network connectivity and login, etc. But I still find it a better alternative than having a lot of distribution specific shell scripts gluing all those individual services together. Besides booting faster, there are advantages like better fault tolerance and consistency.
- pyalot2 13y ago
  All those components that systemd manages, that's easily, I don't know how many millions of lines of code, and it all runs as pid 1, which, when it crashes, takes the whole system with it. Just doesn't seem terribly smart.
  - Aissen 13y ago
    Yeah, except systemd is a more a collection of daemons and tools under the same umbrella (and project repository), than a huge monolithic PID 1 daemon. It's even described in the chart you linked.
  - 13y ago

deleted 13y ago

[deleted]

awalton 13y ago

Wow. This is the sanest commentary about systemd and the state of things I've read to-date.

luuse 13y ago

The biggest fear i have after reading all of the latest articles popping up is that it's too monolithic, just as a lot of other people. However from reading on their faq it seems they've split out into several different processes and if the processes themselves are well scoped i can't really see the problem? I tried googling for something but i can't find any good documentation about what different processes systemd uses and how they interact and their roles in systemd? Anyone have any tips?

legulere 13y ago

Systemd is winning because it makes a Linux system to a modern one. The time where you compiled your own Linux kernel with the drivers you needed and got a static system are gone. The Linux kernel now works in a plug and play way. Block devices for instance can always pop up, not only after you wait and arbitrary amount of time at boot for all devices. The idea that the traditional unix process separation is enough is from the same time as the gets function. The Linux kernel here offers cgroups for better seperation.

julie1 13y ago
fallacy #23: argumentum ad novitatem
- legulere 13y ago
  I'm not claiming that hot-plug is better, but that hot-plug is the status quo of the kernel. Modern here means that it integrates well with a modern linux kernel. Also grouping processes together and isolating them is not really new but a proven technology (FreeBSD jails, virtualization). It's also pretty hard to argue against that the knowledge about security of unix systems didn't increase. The irony about the fallacies is that just throwing them around even without writing a sentence goes against the very nature they were conceived in. The corresponding counter-question would be: "Why is modernity here something good?", but that question is already answered in the post to begin with.
  - julie1 13y ago
    You are right. I am actually in a phase of archeology where I read a lot of rob pikes, ken thompson, ted nelson, linus torvalds, esr ... (http://harmful.cat-v.org/ http://harmful.cat-v.org/) and I begin to question myself a lot of things. Even the statu quo. At work I deal with a lot of dependency hell (system and distributed software requirements, confinments (VM and chroot or jails)) and I begin to doubt some of "the wisdom and progress" I have been adopting. I search for answers now because I think some old "conceptual bugs" are bitting us very hard (like the way http url are built, threading, shared libraries, the abuse of concurrency) and I don't know anymore what progess is. I just kind of feel status quo is a very old hard rock band that should be forgotten :)

blueskin_ 13y ago

Because nobody wants Canonical to control a critical part of their distro.

jude- 13y ago
Upstart is "controlled" by Canonical in the same capacity that systemd is "controlled" by RedHat. Both have a team of full-time employees working on them (plus a surrounding community), and both control the APIs as well as the reference implementations.
pekk 13y ago
Better to have Red Hat in control of Debian, then?
- blueskin_ 13y ago
  In preference to Canonical, yes. systemd is more open, has a greater count of contributors, and is already more widely adopted with more distros planning their move to it. I'm not saying it's without problems, but anything (including keeping sysvinit) is better than Upstart. GNOME is practically a Red Hat project these days, but people aren't advocating its removal (although yes, GNOME is awful since 3.x) As it is, Red Hat already maintain or otherwise have a hand in a lot of things that are in Debian - seeing them as somehow adversarial isn't true, while Canonical have a long tradition of keeping their own work close to their chest and not sending improvements upstream.

sparkie 13y ago

This article lacks any real substance, and perhaps that embodies my dislike of systemd in general. The demonstrate what I mean, I've modified the parent article, replacing "systemd" with "Windows", "sysv" with "Unix", and "init system" with "operating system", plus a bunch of other title changes to make it coherent, without really modifying the impression of the post: http://pastebin.com/sLsDVBG8 http://pastebin.com/sLsDVBG8 (Don't take it too serious.) Obviously this is just a bit of humor, but it sounds like something that could've been written in 1990, and the popular choice at the time has made at least a generation of developers and sysadmins suffer, and which some are still suffering from. I think the lesson we can learn is that "ideas" are not unimportant, and should be properly looked at before jumping to binding decisions, because what "solves your problem" now, may cause significantly more in the future.

evilDagmar 13y ago

There are _numerous_ problems with the argumentation being used here. Starting from the top, the first one is actually kind of silly. "none of these alternate init systems did the hard work to actually become a replacement init system for anything much." This conveniently overlooks whether or not there was any reason to do so. The scope of "classic" init is very simple. Its scope is well defined. It amounts to "start and stop the services when they're supposed to be started and stopped" and that is _all_. Those other init systems mentioned all expanded the scope of the problem of starting and stopping service a bit further, but only a tiny bit along the lines of deciding whether a county border should be on one side of a twisty creek or the other--in practice, very few people even care. Systemd expands its scope by _miles_ and strides boldly forth as a proud example of _scope creep_. The bulk of the rest of the argument amounts to "Well, systemd did all this hard work!". This isn't KINDERGARDEN. Its insane to argue that people should be giving systemd a free pass simply because the developers _worked really hard on it_. All those edge and corner and simply misbehaving daemon cases aren't things systemd should be more than peripherally concerned with--they're things to push back on the original developers to fix from the start, and in the meantime those workarounds should be held in their proper regard... as _workarounds_, not major features, because again... _scope creep_. Lastly, while they're busy giving systemd points for trying real hard and solving a bunch of problems that it shouldn't be bothering with, they ignore the fact that systemd was busily creating _new_ problems... but I'm sure they'll also credit systemd for solving those as well. Specifically Poettering himself recently posted about a "bug" with apparent filesystem corruption caused by systemd failing to properly unmount a filesystem when it's upgraded... during which at some point they appear to have decided that PID 1 is some mystical holy number (which it is _not_) and that going back to the initrd the system booted with is a completely fine and reasonable thing to do, and that it is not, in fact, a sign that one has seriously painted themselves into a corner. They're essentially arguing that they didn't paint themselves into a corner because they're standing in the middle of a long hallway... surrounded by paint... and that the real problem is the lack of roof access. It's a _huge_ workaround for what is simply not a problem for a small, simple initd that _only_ handles a small, well-defined problem and handles it correctly. ...but you pro-systemd people enjoy having to explain why half the core system functionality has to stop whenever you have to upgrade any of it. The rest of us will continue to use systems that do what they're supposed even while being upgraded.