8 ms·

Why pro-systemd and anti-systemd people will never get along

98 points by uselessdguy 12y ago

hk__2 12y ago
Could someone ELI5 this pro-systemd/anti-systemd thing?
- deelowe 12y ago
  Linux/unix has a bit of an issue with it's init aging systems. One simple example is that they are serial, meaning that services start one by one with little to no concurrency. This causes several issues. Also, the most popular variant, system V is difficult to maintain having multiple directories for various run levels and other cumbersome features. I won't go into details here, just know that the popular init systems needed a refresh. There are other options, but systemd seems to have caught on as the popular option for a replacement. The issue that most people take with systemd is that it does much more than replace init. It replaces cron, has a login management hooks, has it's own network daemon, replaces the system logging facilities and more. It's a serious complex system. The issue some take with systemd has a few facets: 1) Some feel that systemd's approach to managing everything goes against Unix's core principles where services and applications are supposed to be small, self contained entities that work in unison to form a cohesive system. 2) It can be daunting task to switch over to systemd as you have to relearn many traditional unix tools that most take for granted (remote logging for example). 3) Security minded people are concerned that a single service is touching so many parts of the core system all at once. There have been many complaints levied that such a large change introduces too much risk into the ecosystem all at once. 4) Some have accused the dev team of having a "not invented here" problem. I've seen it asked many times why they really needed to replace cron or logging. The pro-systemd stance is that they are simply cleaning up many of the antiquated systems. Cron, logging, and init definitely all needed an overhaul. Linux never had a good network daemon and there are good reasons for the other things they are doing. The systemd team sees systemd as not just an init system but basically the system manager. So, by that view, this all makes sense. Ultimately, it's a fundamental difference of opinion about what services in general should or should not look like on a unix/linux system.
  - rthomas6 12y ago
    Could someone just fork systemd and make a version that relaces the init system and nothing else?
    - bkor 12y ago
      That's uselessd. Software however relies on the other bits, e.g. logind dbus interfaces. For that there is a systemd-shim, but was not there initially and used to lag behind systemd for a 6+ months. Apparently it was also quite buggy. Seems ok now though.
      - washadjeffmad 12y ago
        To clarify, uselessd (http://uselessd.darknedgy.net/ http://uselessd.darknedgy.net/) is "a project to reduce systemd to a base initd, process supervisor and transactional dependency system, while minimizing intrusiveness and isolationism", not just the parent making a joke in the phrasing.
  - hamburglar 12y ago
    I agree completely that cron, logging and init all could use a little (a lot of) modernization. I just think it's really bad judgment to tie all of those together into one all-encompassing project whose scope seems to grow and grow the more I read about it, and whose leaders seem to have such a low opinion of what anybody else wants. To make a stupid car analogy, it feels like having someone redesign your car's ignition switch and suddenly finding out that he also had strong opinions on the stereo UI so he made the changes together (and dependent on one another), and you're an idiot if you don't like it. A lot of people complain about systemd missing the "unix philosophy" and that gets derailed on specifics of what people think that philosophy means ("everything is a file" or "do one thing only and do it well" and "be modular") but one significant difference to me between unix systems and Windows or OSX is that unix is built of simple components whose scope is very limited. It's related to do-one-thing and modularity but it's not exactly the same thing. Systemd is not simple or limited in scope.
  - hk__2 12y ago
- ck2 12y ago
  One person decided the way microsoft windows handles services was awesome and it would be a good idea to make the linux service manager work like that with complex binaries and binary logs instead of editable, standardized bash scripts and text logs. No vote, only veto. Very anti-linux.
  - bkor 12y ago
    According to the blogs it is based upon what Mac OS does as well as Solaris. So it is very UNIX in mind.
    - wahern 12y ago
      Both launchd and SMF suck. Have you tried learning either? SMF utilizes XML all over the place. launchd uses .plist trees all over the place. They're both a gigantic pain to learn, with obtuse configuration syntax, and in fact very few people actually learn them. They're both environments that breed epic cargo cults because they're overly complex, yet provide so little benefit that there's little motivation to bother to learn them properly. All you normally care about is getting your little script to run on boot or login, so the rest is just food for bugs. SMF and launchd also organically grew to take over most of the management of /etc. Now neither is hardly any better than the Windows Registry. systemd is not only moving in the same direction, they're going to leap-frog them. Why have a separate ntpd or dhcpd when you can just build it into the init framework. Why listen for SIGHUP or SIGTERM when "good" services (in as much as service can be good which isn't shipped with systemd) just use the systemd C API to listen for DBUS events. That's the problem with systemd, SMF, and launchd. Like SMF and launchd, I have no doubt whatsoever that systemd will rocket past the boundary where the complexity exceeds the benefit.
- sandGorgon 12y ago
  Here's my take on some of the FUD around systemd - http://www.lambdacurry.com/systemd-nice-dont-afraid/ http://www.lambdacurry.com/systemd-nice-dont-afraid/
- chipsy 12y ago
  It's political theatre, to some extent. The traditional "SysV init" mechanism is there to do things that are slightly above kernel space, but too global to be considered part of userspace; so things like user settings for power management, managing long-running daemon processes, and handling logins could all be part of the init. The problem motivating a switch is that init is an underpowered solution for the number of things that a distribution is asked to handle these days; it results in a lot of hand-tuned scripts with duplicated effort. Enter the politics. A lot of the value of a distribution can come down to how its init system has been built, since it means the difference between essential stuff working or not working. Systemd pushes the value and the accountability into a central location by annexing lots of different features that were traditionally just spread out amongst various interdependent scripts. There are a lot of straightforward technical advantages to centralizing some of these things(speed, simplicity of configuration, etc.), but everyone and their dog has an opinion about which things should or shouldn't be annexed, and the form in which it should be done. Many people's jobs are potentially at stake here. The more conspiracy-minded also view systemd as a power grab from Red Hat. Red Hat's business substantially involves contracts with the military, lending circumstantial evidence to the idea that they are doing deliberate harm to serve state interests - thus everything they do is viewed with some suspicion.
FreakyT 12y ago
Interesting discussion! I would have liked it if the author had provided some background information (for the uninitiated) about some of the other related issues mentioned. For example, what was meant by "the horrors of PulseAudio", "the udev debacle", and why was HAL bad? I realize that I could probably find out "bad things about HAL" via internet searching, but it would be more interesting to see the author's take on the issues in the context of the article.
- uselessdguy 12y ago
  I kind of stitched this essay together haphazardly, and it certainly does require some background knowledge to fully understand. Nonetheless, "the udev debacle" refers to systemd merging udev into its codebase, along with tying it to systemd's shared files, the recent "debug" parameter fiasco and the rather blunt statement by Lennart concerning migrating the transport to kdbus: http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html http://lists.freedesktop.org/archives/systemd-devel/2014-May... PulseAudio (originally PolypAudio) is a networked sound server most often used in Linux systems coming with a variety of centralized features (see here: http://www.freedesktop.org/wiki/Software/PulseAudio/About/ http://www.freedesktop.org/wiki/Software/PulseAudio/About/), which proved to be highly controversial initially and less so to this day. People realized it was buggy and unstable, and different factors were blamed: poor integration, sloppy ALSA drivers, or PulseAudio itself. The most common narrative these days is "PulseAudio was bad because Ubuntu rushed it", but I haven't studied things in enough detail to pinpoint exact reasons. As for HALd, it did solve problems at the time, but I'll quote the Ubuntu wiki: https://wiki.ubuntu.com/Halsectomy https://wiki.ubuntu.com/Halsectomy
  - adwf 12y ago
    Pulseaudio is still crap for me. I can't get consistent volume across applications and it's 50/50 as to whether it'll recognize my headphones on any given day. I still rate it as crap compared to my nice stable ALSA setup. So that really worried me when I found out Arch linux was switching to systemd! Thankfully it's all been ok as far as I can tell. Had to learn a few new commands and that's about it. Maybe it's different for the people actually configuring daemons, but as far as the end user goes, I haven't noticed any problems.
deleted 12y ago
[deleted]
Aardwolf 12y ago
I think most of it is ok, such as the init system, except the logging. Why did they have to touch logging, and change everything about it, and put it in a non-text format...
erhardm 12y ago
I see the whole pro/anti systemd as a philosophical debate. Basically each part is arguing where the complexity should be in the system and how dense it should be distributed. I think we need two competing init systems to really know maybe in 5-10 years what the best trade-offs are. A modern sys V init and systemd.
- fbt2lurker 12y ago
  Why two? As many as people would write. There is already a bunch of em.
  - erhardm 12y ago
    At least one of each side of the debate. Preferable there should be two, one on each side which implements the good/novel ideas and others where aggressive experimentation takes part.
    - kbenson 12y ago
      I think you have a much more stylized view of what a side of a debate is than reality suggests is the case. Creating an implementation for a side that wasn't already rallying around one would just exacerbate the differences in opinion on that side and fragment it into multiple smaller sides.
    - fbt2lurker 12y ago
      There aren't actually two sides of this. There are only in the scope of systemd vs everyone else (just because systemd is something that is pushed as THE solution). There are multiple solutions that all have their supporters. And we generally actually get along and work together pretty well. BEcause we don't think that one solution is necessarily better than the other in all aspects. It shouldn't be “provide a reasonable alternative to systemd and then we will compare”. “We” won't “compare” anything. Competition is awesome, “we” shouldn't “choose” just one implementation of anything just because the majority of distros uses it. It should be “let people do their thing and please don't hard-depend on this one init system or anything else without a really good reason to do so”.
burtonator 12y ago
emacs is the one true editor... same thing all over again :-P
pessimizer 12y ago
I have none of these objections to systemd. My objection is that it's both pervasive and unauditable. I can accept one or the other. I don't have to rely on 'many eyes' to tell me what's going on with init scripts, I can just look. systemd is sprawling, has no particular philosophy that I can notice, and all of its internal systems are heavily interconnected; this leads me to expect that very few people will be auditing the code that don't work for redhat, because very few will understand it. I expect it to increase the vulnerability of the entire system to accidental or intentionally inserted bugs by an order of magnitude. Therefore, I'd like to see it in the wild for 5 or so years before personally using it - but it looks as if to continue using many linux applications I have to switch to it while it is being written. I don't get the point (other than cgroups and boot times), I don't get the hurry, and I don't get the animosity to alternate and legacy init systems, and to alternate Unices.
- bkor 12y ago
  Red Hat has audited the code in the past. The boot time bit is an item from the linked article. The thing is that systemd provides more than just an init system. Stuff that's pretty useful.
  - pessimizer 12y ago
    >very few people will be auditing the code that don't work for redhat,
    - bkor 12y ago
      You also said: > My objection is that it's both pervasive and unauditable. You said it was unauditable, it has already been audited. Adding arbitrary limitations to this doesn't change that.
      - e7620 12y ago
        I didn't downvote you, but I want to audit it myself, thanks.
fidotron 12y ago
It will be very interesting to see how this all plays out in the long run, though the short term is utterly depressing. My hunch is Lennart will be vindicated, on the basis that systemd as it exists right now is not right, but it can be evolved into something much better, and while that may not have occurred to other projects here the stakes are enormous. There is a definite strand to the resistance that any change to something so fundamental must be resisted. The bigger side argument about the Unix philosophy is also intriguing. Rob Pike claimed it was dead and Perl delivered the eulogy, which I can half agree with. The problem is shell scripting is archaic nonsense, but our script languages can't do what you can do in shell scripts well enough. The idea of a Unix where you get rid of bash/csh/whatever and just run a lua/python/ruby prompt and have your apps implemented largely in that same language (with shell commands being replaced by functions) may make some people squirm, but would make a lot of sense for reducing the overall learning curve.
- api 12y ago
  I agree. So far I've seen it as a classic conservatives vs. liberals debate. The conservatives have no interest at all in changing the Unix paradigm under Linux. It works perfectly well, thank you. The liberals see it as archaic and unsuited to a wide variety of new use cases including rapid-deployment VMs, containers, mobile and laptop computers, and the desktop in general. I side with the liberals here, but with a few caveats. I'm not a huge fan of systemd, though I agree that it'll probably get fixed and so far it seems better than the hairy old SysV-init mess. The debate is doing more harm than even a slightly broken systemd would do-- Linux is already far too fragmented to no benefit. I'm all for freedom but I don't like pointless forks that add nothing.
  - nova 12y ago
    “The whole modern world has divided itself into Conservatives and Progressives. The business of Progressives is to go on making mistakes. The business of Conservatives is to prevent mistakes from being corrected. Even when the revolutionist might himself repent of his revolution, the traditionalist is already defending it as part of his tradition. Thus we have two great types -- the advanced person who rushes us into ruin, and the retrospective person who admires the ruins. He admires them especially by moonlight, not to say moonshine. Each new blunder of the progressive or prig becomes instantly a legend of immemorial antiquity for the snob. This is called the balance, or mutual check, in our Constitution.” ― G.K. Chesterton
ck2 12y ago
I don't want anything bad to happen to Lennart, I just want him to take his football and go home. Then suddenly init.d will look very open and friendly again. Maybe the same thing can happen to grub2 and I wouldn't mind going back to good old grub.conf
- vidarh 12y ago
  > Then suddenly init.d will look very open and friendly again. Having used systemd on a few machines by now, I won't ever go back. It's utterly naive to think that systemd would go away if Lennart were to.
  - mercurial 12y ago
    Not to mention that quite a few people contribute to systemd [1], even if Lennart is still leading the pack. 1: https://github.com/systemd/systemd/graphs/contributors?from=2014-01-08&to=2014-10-21&type=c https://github.com/systemd/systemd/graphs/contributors?from=...
wmf 12y ago
If systemd is bad for servers, why did RHEL[1] and CoreOS adopt it? Are we to believe that these companies work against themselves? [1] AFAIK 90% of Red Hat's revenue is from servers, not desktops.
- pessimizer 12y ago
  You're either asking the wrong people, or making a silly argument. edit: both redhat and CoreOS have email addresses, as far as I know.
- makomk 12y ago
  It's a good weapon against Red Hat's proprietary Unix competitors like Solaris - by tying as many things as possible to systemd they ensure it can't run on non-Linux systems. Same reason the proprietary Unices had their own oddball service management frameworks, APIs, etc. Also, RHEL was still using the old, grotty sysvinit-based system where you had to manually specify the order in which services were started and stopped; almost anything's an improvement on that. (All the other major distros had migrated away from it ages ago.)
- e7620 12y ago
  > 90% of Red Hat's revenue is from servers just a correction, red hat revenue is from support contracts. > If systemd is bad for servers, why did RHEL[1] and CoreOS adopt it? Are we to believe that these companies work against themselves? I know of two theories: 1) making systemd a dependency for gnome and the rest, red hat is trying to exterminate *bsd, which is considered better for servers. 2) "Software that ain't broken doesn't sell $$$upport. "
floatboth 12y ago
The referenced article that criticizes both SysV and BSD inits is from 2002. BSD systems have had separate scripts in a folder (rc.d) since, like, forever. And "[package installation] needs to edit one of the existing boot scripts" is the only criticism there. There might be more current issues, but I believe it's good enough. For example, BSD init doesn't have super web scale auto restarting and monitoring and log routing. Well... it doesn't need to. Just use it to launch supervisord or something. Also, it's not super fast because it uses the shell. Again, it doesn't need to be. It's fast enough for general purpose servers and desktops. For special cases like containers and whatnot you need special tools.
- JdeBP 12y ago
  That's an odd definition of "forever", there. NetBSD gained its rc.d system at the end of 2000, with the release of NetBSD 1.5. FreeBSD started porting work in 2001, and that carried on through 2002. FreeBSD 5.0 with rc.d was released in 2003. OpenBSD didn't get the rc.d system until version 4.9, released in 2011. Is just 3 years ago "forever" in World Wide Web time, now? If so, does that make the 11-year gap between NetBSD and OpenBSD "almost quadruple forever"? (-:
hello_there 12y ago
What I really dislike about these debates about systemd is that usually nobody mentions the alternatives. From reading the debate I get the impression that both sysvinit and systemd have major problems, but I'm never presented with a solution. So if I'm going to be against sysvinit as well as systemd, then what should i be supporting?
- exelius 12y ago
  The main alternatives seem to be OpenRC and Upstart. One of the biggest criticisms of systemd by its detractors is that it's unproven and not stable; and neither of these address that concern. Upstart was developed by Ubuntu, which has stopped supporting it and is adopting systemd because they recognized the need to standardize on a single system. After the Debian committee voted to go with systemd, Ubuntu (being a Debian derivative) followed suit.[1] OpenRC isn't really a replacement for sysvinit; rather it bolts on some functionality on top of sysvinit. My understanding is that OpenRC is not an incredibly mature codebase and would have needed a lot of work to come up to feature/stability parity with systemd. Because it doesn't fully replace sysvinit, it also doesn't solve all of the same problems as systemd. [1] http://www.markshuttleworth.com/archives/1316 http://www.markshuttleworth.com/archives/1316
  - vertex-four 12y ago
    > The main alternatives seem to be OpenRC and Upstart. There's also outliers like nosh[0], which implements at least some of the good bits of systemd (socket activation is in there), and the ideas and general architecture are solid enough that it could be extended to implement more (device/path dependencies through udev and inotify are two that I hear people wanting). Then separate pieces of software can implement the remainder of what systemd implements (its many dbus APIs). [0] http://homepage.ntlworld.com/jonathan.deboynepollard/Softwares/nosh.html http://homepage.ntlworld.com/jonathan.deboynepollard/Softwar...
    - exelius 12y ago
      This debate has been raging for the better part of two years and many of these alternatives didn't exist when it started. Really though, systemd has the momentum and I don't see anything else remaining a mainstream alternative unless it just emulates systemd's functionality.
nanoscopic 12y ago
That was a very long and detailed explanation of the sides of the argument. It misses one huge thing: Consistency. The elephant in the room is that most people who dislike systemd simply dislike it because they learned and used init.d scripts, runlevels, and chkconfig, and that is the extent of their understanding. The main hatred for systemd is coming from people simply being resistant to change. If it ain't broke, don't fix it. I like systemd for it's technical merits. I personally would prefer to use a distribution like CentOS in a mode where there is no systemd, simply because I like simplicity and systemd is more confusing to me. What I foresee happening: people who don't like systemd are going to go try other distributions that don't use it, and may abandon the ones that do because it is too much trouble to run them without it. The statement that it will lead to divide between graphical linux users and minimalists is likely very true. Runlevels may be simplistic and outdated, but they are easy to remember.
- jamescun 12y ago
  That is a rather broad estimation of all those who dislike systemd. While there are people who most likely dislike systemd because they are resistant to change, they don't constitute everyone with objections. I for one dislike systemd, not because I am resistant to change, but on a purely technical basis (which I won't discuss as it has already been reiterated ad nauseam). I must also add that I dislike sysv and like that the community is discussing alternatives; but the race to systemd, with some serious technical failings which have not been addressed, scares me.
- uselessdguy 12y ago
  No, I specifically addressed this: -------------------------------- "The rather huge scope and opinionated nature of systemd leads to people yearning for the days of sysvinit. A lot of this is ignorance about good design principles, but a good part may also be motivated from an inability to properly convey desires of simple and transparent systems. In this way, proponents and opponents get caught in feedback loops of incessantly going nowhere with flame wars over one initd implementation (that happened to be dominant), completely ignoring all the previous research on improving init, as it all gets left to bite the dust. Even further, most people fail to differentiate init from rc scripts, and sort of hold sysvinit to be equivalent to the shoddy initscripts that distros have written, and all the hacks they bolted on top like LSB headers and startpar(2). This is a huge misunderstanding that leads to a lot of wasted energy." ------------------------------- This isn't about people "hating change". It looks like it, because a lot of people who defend sysvinit aren't really doing that as much as they are defending minimal and transparent systems. In fact, there's way too many people who don't understand "init". Init is the first userspace process that is started. That's it. Init doesn't mean "manages services", "manages processes" or anything like that. Those are separate concepts. The sooner we realize this, the sooner we can have some more innovative architectures for managing services, as we're still trapped in this mental cage. Moreover, it's not just systemd haters who are resistant to change. A lot of systemd lovers are, as well. In fact, the reason we didn't fix the problem earlier and stuck with SysV for so long was precisely because people didn't care about init, and didn't want to change their flawed ways. Well, at least in the Linux communities. Many of the people who resisted change when presented with non-SysV approaches back in the day are the same who now support systemd and lament on how much "systemd haters don't like change". systemd, of course, went significantly beyond service management, and thus had a much bigger impact than previous designs which were rather focused on one problem domain. Thus, systemd simply became far more prominent (and controversial) than anything else because of its huge ambitions.
jude- 12y ago
Thank you for taking the time to write this up! (the link is also appreciated :) I think a lot of the rage and loathing regarding systemd is due to its coupling to the rest of the OS. I think a lot of !systemd users were quiet on this initially (and today even) since it's not hard to avoid systemd if you're not running a full-fledged desktop environment. I think it's the fear that this will change in the near-future that has prompted the backlash we're seeing now. I hope that Debian's new init system coupling GR will address this, both for itself and for its derivative distros. If the rest of the OS does not care about whether or not it's systemd managing the daemons or something else, then everyone wins.

98 points by uselessdguy 12y ago

hk__2 12y ago

Could someone ELI5 this pro-systemd/anti-systemd thing?

deelowe 12y ago
Linux/unix has a bit of an issue with it's init aging systems. One simple example is that they are serial, meaning that services start one by one with little to no concurrency. This causes several issues. Also, the most popular variant, system V is difficult to maintain having multiple directories for various run levels and other cumbersome features. I won't go into details here, just know that the popular init systems needed a refresh. There are other options, but systemd seems to have caught on as the popular option for a replacement. The issue that most people take with systemd is that it does much more than replace init. It replaces cron, has a login management hooks, has it's own network daemon, replaces the system logging facilities and more. It's a serious complex system. The issue some take with systemd has a few facets: 1) Some feel that systemd's approach to managing everything goes against Unix's core principles where services and applications are supposed to be small, self contained entities that work in unison to form a cohesive system. 2) It can be daunting task to switch over to systemd as you have to relearn many traditional unix tools that most take for granted (remote logging for example). 3) Security minded people are concerned that a single service is touching so many parts of the core system all at once. There have been many complaints levied that such a large change introduces too much risk into the ecosystem all at once. 4) Some have accused the dev team of having a "not invented here" problem. I've seen it asked many times why they really needed to replace cron or logging. The pro-systemd stance is that they are simply cleaning up many of the antiquated systems. Cron, logging, and init definitely all needed an overhaul. Linux never had a good network daemon and there are good reasons for the other things they are doing. The systemd team sees systemd as not just an init system but basically the system manager. So, by that view, this all makes sense. Ultimately, it's a fundamental difference of opinion about what services in general should or should not look like on a unix/linux system.
- rthomas6 12y ago
  Could someone just fork systemd and make a version that relaces the init system and nothing else?
  - bkor 12y ago
    That's uselessd. Software however relies on the other bits, e.g. logind dbus interfaces. For that there is a systemd-shim, but was not there initially and used to lag behind systemd for a 6+ months. Apparently it was also quite buggy. Seems ok now though.
    - washadjeffmad 12y ago
      To clarify, uselessd (http://uselessd.darknedgy.net/ http://uselessd.darknedgy.net/) is "a project to reduce systemd to a base initd, process supervisor and transactional dependency system, while minimizing intrusiveness and isolationism", not just the parent making a joke in the phrasing.
- hamburglar 12y ago
  I agree completely that cron, logging and init all could use a little (a lot of) modernization. I just think it's really bad judgment to tie all of those together into one all-encompassing project whose scope seems to grow and grow the more I read about it, and whose leaders seem to have such a low opinion of what anybody else wants. To make a stupid car analogy, it feels like having someone redesign your car's ignition switch and suddenly finding out that he also had strong opinions on the stereo UI so he made the changes together (and dependent on one another), and you're an idiot if you don't like it. A lot of people complain about systemd missing the "unix philosophy" and that gets derailed on specifics of what people think that philosophy means ("everything is a file" or "do one thing only and do it well" and "be modular") but one significant difference to me between unix systems and Windows or OSX is that unix is built of simple components whose scope is very limited. It's related to do-one-thing and modularity but it's not exactly the same thing. Systemd is not simple or limited in scope.
- hk__2 12y ago
ck2 12y ago
One person decided the way microsoft windows handles services was awesome and it would be a good idea to make the linux service manager work like that with complex binaries and binary logs instead of editable, standardized bash scripts and text logs. No vote, only veto. Very anti-linux.
- bkor 12y ago
  According to the blogs it is based upon what Mac OS does as well as Solaris. So it is very UNIX in mind.
  - wahern 12y ago
    Both launchd and SMF suck. Have you tried learning either? SMF utilizes XML all over the place. launchd uses .plist trees all over the place. They're both a gigantic pain to learn, with obtuse configuration syntax, and in fact very few people actually learn them. They're both environments that breed epic cargo cults because they're overly complex, yet provide so little benefit that there's little motivation to bother to learn them properly. All you normally care about is getting your little script to run on boot or login, so the rest is just food for bugs. SMF and launchd also organically grew to take over most of the management of /etc. Now neither is hardly any better than the Windows Registry. systemd is not only moving in the same direction, they're going to leap-frog them. Why have a separate ntpd or dhcpd when you can just build it into the init framework. Why listen for SIGHUP or SIGTERM when "good" services (in as much as service can be good which isn't shipped with systemd) just use the systemd C API to listen for DBUS events. That's the problem with systemd, SMF, and launchd. Like SMF and launchd, I have no doubt whatsoever that systemd will rocket past the boundary where the complexity exceeds the benefit.
sandGorgon 12y ago
Here's my take on some of the FUD around systemd - http://www.lambdacurry.com/systemd-nice-dont-afraid/ http://www.lambdacurry.com/systemd-nice-dont-afraid/
chipsy 12y ago
It's political theatre, to some extent. The traditional "SysV init" mechanism is there to do things that are slightly above kernel space, but too global to be considered part of userspace; so things like user settings for power management, managing long-running daemon processes, and handling logins could all be part of the init. The problem motivating a switch is that init is an underpowered solution for the number of things that a distribution is asked to handle these days; it results in a lot of hand-tuned scripts with duplicated effort. Enter the politics. A lot of the value of a distribution can come down to how its init system has been built, since it means the difference between essential stuff working or not working. Systemd pushes the value and the accountability into a central location by annexing lots of different features that were traditionally just spread out amongst various interdependent scripts. There are a lot of straightforward technical advantages to centralizing some of these things(speed, simplicity of configuration, etc.), but everyone and their dog has an opinion about which things should or shouldn't be annexed, and the form in which it should be done. Many people's jobs are potentially at stake here. The more conspiracy-minded also view systemd as a power grab from Red Hat. Red Hat's business substantially involves contracts with the military, lending circumstantial evidence to the idea that they are doing deliberate harm to serve state interests - thus everything they do is viewed with some suspicion.

FreakyT 12y ago

Interesting discussion! I would have liked it if the author had provided some background information (for the uninitiated) about some of the other related issues mentioned. For example, what was meant by "the horrors of PulseAudio", "the udev debacle", and why was HAL bad? I realize that I could probably find out "bad things about HAL" via internet searching, but it would be more interesting to see the author's take on the issues in the context of the article.

uselessdguy 12y ago
I kind of stitched this essay together haphazardly, and it certainly does require some background knowledge to fully understand. Nonetheless, "the udev debacle" refers to systemd merging udev into its codebase, along with tying it to systemd's shared files, the recent "debug" parameter fiasco and the rather blunt statement by Lennart concerning migrating the transport to kdbus: http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html http://lists.freedesktop.org/archives/systemd-devel/2014-May... PulseAudio (originally PolypAudio) is a networked sound server most often used in Linux systems coming with a variety of centralized features (see here: http://www.freedesktop.org/wiki/Software/PulseAudio/About/ http://www.freedesktop.org/wiki/Software/PulseAudio/About/), which proved to be highly controversial initially and less so to this day. People realized it was buggy and unstable, and different factors were blamed: poor integration, sloppy ALSA drivers, or PulseAudio itself. The most common narrative these days is "PulseAudio was bad because Ubuntu rushed it", but I haven't studied things in enough detail to pinpoint exact reasons. As for HALd, it did solve problems at the time, but I'll quote the Ubuntu wiki: https://wiki.ubuntu.com/Halsectomy https://wiki.ubuntu.com/Halsectomy
- adwf 12y ago
  Pulseaudio is still crap for me. I can't get consistent volume across applications and it's 50/50 as to whether it'll recognize my headphones on any given day. I still rate it as crap compared to my nice stable ALSA setup. So that really worried me when I found out Arch linux was switching to systemd! Thankfully it's all been ok as far as I can tell. Had to learn a few new commands and that's about it. Maybe it's different for the people actually configuring daemons, but as far as the end user goes, I haven't noticed any problems.

deleted 12y ago

[deleted]

Aardwolf 12y ago

I think most of it is ok, such as the init system, except the logging. Why did they have to touch logging, and change everything about it, and put it in a non-text format...

erhardm 12y ago

I see the whole pro/anti systemd as a philosophical debate. Basically each part is arguing where the complexity should be in the system and how dense it should be distributed. I think we need two competing init systems to really know maybe in 5-10 years what the best trade-offs are. A modern sys V init and systemd.

fbt2lurker 12y ago
Why two? As many as people would write. There is already a bunch of em.
- erhardm 12y ago
  At least one of each side of the debate. Preferable there should be two, one on each side which implements the good/novel ideas and others where aggressive experimentation takes part.
  - kbenson 12y ago
    I think you have a much more stylized view of what a side of a debate is than reality suggests is the case. Creating an implementation for a side that wasn't already rallying around one would just exacerbate the differences in opinion on that side and fragment it into multiple smaller sides.
  - fbt2lurker 12y ago
    There aren't actually two sides of this. There are only in the scope of systemd vs everyone else (just because systemd is something that is pushed as THE solution). There are multiple solutions that all have their supporters. And we generally actually get along and work together pretty well. BEcause we don't think that one solution is necessarily better than the other in all aspects. It shouldn't be “provide a reasonable alternative to systemd and then we will compare”. “We” won't “compare” anything. Competition is awesome, “we” shouldn't “choose” just one implementation of anything just because the majority of distros uses it. It should be “let people do their thing and please don't hard-depend on this one init system or anything else without a really good reason to do so”.

burtonator 12y ago

emacs is the one true editor... same thing all over again :-P

pessimizer 12y ago

I have none of these objections to systemd. My objection is that it's both pervasive and unauditable. I can accept one or the other. I don't have to rely on 'many eyes' to tell me what's going on with init scripts, I can just look. systemd is sprawling, has no particular philosophy that I can notice, and all of its internal systems are heavily interconnected; this leads me to expect that very few people will be auditing the code that don't work for redhat, because very few will understand it. I expect it to increase the vulnerability of the entire system to accidental or intentionally inserted bugs by an order of magnitude. Therefore, I'd like to see it in the wild for 5 or so years before personally using it - but it looks as if to continue using many linux applications I have to switch to it while it is being written. I don't get the point (other than cgroups and boot times), I don't get the hurry, and I don't get the animosity to alternate and legacy init systems, and to alternate Unices.

bkor 12y ago
Red Hat has audited the code in the past. The boot time bit is an item from the linked article. The thing is that systemd provides more than just an init system. Stuff that's pretty useful.
- pessimizer 12y ago
  >very few people will be auditing the code that don't work for redhat,
  - bkor 12y ago
    You also said: > My objection is that it's both pervasive and unauditable. You said it was unauditable, it has already been audited. Adding arbitrary limitations to this doesn't change that.
    - e7620 12y ago
      I didn't downvote you, but I want to audit it myself, thanks.

fidotron 12y ago

It will be very interesting to see how this all plays out in the long run, though the short term is utterly depressing. My hunch is Lennart will be vindicated, on the basis that systemd as it exists right now is not right, but it can be evolved into something much better, and while that may not have occurred to other projects here the stakes are enormous. There is a definite strand to the resistance that any change to something so fundamental must be resisted. The bigger side argument about the Unix philosophy is also intriguing. Rob Pike claimed it was dead and Perl delivered the eulogy, which I can half agree with. The problem is shell scripting is archaic nonsense, but our script languages can't do what you can do in shell scripts well enough. The idea of a Unix where you get rid of bash/csh/whatever and just run a lua/python/ruby prompt and have your apps implemented largely in that same language (with shell commands being replaced by functions) may make some people squirm, but would make a lot of sense for reducing the overall learning curve.

api 12y ago
I agree. So far I've seen it as a classic conservatives vs. liberals debate. The conservatives have no interest at all in changing the Unix paradigm under Linux. It works perfectly well, thank you. The liberals see it as archaic and unsuited to a wide variety of new use cases including rapid-deployment VMs, containers, mobile and laptop computers, and the desktop in general. I side with the liberals here, but with a few caveats. I'm not a huge fan of systemd, though I agree that it'll probably get fixed and so far it seems better than the hairy old SysV-init mess. The debate is doing more harm than even a slightly broken systemd would do-- Linux is already far too fragmented to no benefit. I'm all for freedom but I don't like pointless forks that add nothing.
- nova 12y ago
  “The whole modern world has divided itself into Conservatives and Progressives. The business of Progressives is to go on making mistakes. The business of Conservatives is to prevent mistakes from being corrected. Even when the revolutionist might himself repent of his revolution, the traditionalist is already defending it as part of his tradition. Thus we have two great types -- the advanced person who rushes us into ruin, and the retrospective person who admires the ruins. He admires them especially by moonlight, not to say moonshine. Each new blunder of the progressive or prig becomes instantly a legend of immemorial antiquity for the snob. This is called the balance, or mutual check, in our Constitution.” ― G.K. Chesterton

ck2 12y ago

I don't want anything bad to happen to Lennart, I just want him to take his football and go home. Then suddenly init.d will look very open and friendly again. Maybe the same thing can happen to grub2 and I wouldn't mind going back to good old grub.conf

vidarh 12y ago
> Then suddenly init.d will look very open and friendly again. Having used systemd on a few machines by now, I won't ever go back. It's utterly naive to think that systemd would go away if Lennart were to.
- mercurial 12y ago
  Not to mention that quite a few people contribute to systemd [1], even if Lennart is still leading the pack. 1: https://github.com/systemd/systemd/graphs/contributors?from=2014-01-08&to=2014-10-21&type=c https://github.com/systemd/systemd/graphs/contributors?from=...

wmf 12y ago

If systemd is bad for servers, why did RHEL[1] and CoreOS adopt it? Are we to believe that these companies work against themselves? [1] AFAIK 90% of Red Hat's revenue is from servers, not desktops.

pessimizer 12y ago
You're either asking the wrong people, or making a silly argument. edit: both redhat and CoreOS have email addresses, as far as I know.
makomk 12y ago
It's a good weapon against Red Hat's proprietary Unix competitors like Solaris - by tying as many things as possible to systemd they ensure it can't run on non-Linux systems. Same reason the proprietary Unices had their own oddball service management frameworks, APIs, etc. Also, RHEL was still using the old, grotty sysvinit-based system where you had to manually specify the order in which services were started and stopped; almost anything's an improvement on that. (All the other major distros had migrated away from it ages ago.)
e7620 12y ago
> 90% of Red Hat's revenue is from servers just a correction, red hat revenue is from support contracts. > If systemd is bad for servers, why did RHEL[1] and CoreOS adopt it? Are we to believe that these companies work against themselves? I know of two theories: 1) making systemd a dependency for gnome and the rest, red hat is trying to exterminate *bsd, which is considered better for servers. 2) "Software that ain't broken doesn't sell $$$upport. "

floatboth 12y ago

The referenced article that criticizes both SysV and BSD inits is from 2002. BSD systems have had separate scripts in a folder (rc.d) since, like, forever. And "[package installation] needs to edit one of the existing boot scripts" is the only criticism there. There might be more current issues, but I believe it's good enough. For example, BSD init doesn't have super web scale auto restarting and monitoring and log routing. Well... it doesn't need to. Just use it to launch supervisord or something. Also, it's not super fast because it uses the shell. Again, it doesn't need to be. It's fast enough for general purpose servers and desktops. For special cases like containers and whatnot you need special tools.

JdeBP 12y ago
That's an odd definition of "forever", there. NetBSD gained its rc.d system at the end of 2000, with the release of NetBSD 1.5. FreeBSD started porting work in 2001, and that carried on through 2002. FreeBSD 5.0 with rc.d was released in 2003. OpenBSD didn't get the rc.d system until version 4.9, released in 2011. Is just 3 years ago "forever" in World Wide Web time, now? If so, does that make the 11-year gap between NetBSD and OpenBSD "almost quadruple forever"? (-:

hello_there 12y ago

What I really dislike about these debates about systemd is that usually nobody mentions the alternatives. From reading the debate I get the impression that both sysvinit and systemd have major problems, but I'm never presented with a solution. So if I'm going to be against sysvinit as well as systemd, then what should i be supporting?

exelius 12y ago
The main alternatives seem to be OpenRC and Upstart. One of the biggest criticisms of systemd by its detractors is that it's unproven and not stable; and neither of these address that concern. Upstart was developed by Ubuntu, which has stopped supporting it and is adopting systemd because they recognized the need to standardize on a single system. After the Debian committee voted to go with systemd, Ubuntu (being a Debian derivative) followed suit.[1] OpenRC isn't really a replacement for sysvinit; rather it bolts on some functionality on top of sysvinit. My understanding is that OpenRC is not an incredibly mature codebase and would have needed a lot of work to come up to feature/stability parity with systemd. Because it doesn't fully replace sysvinit, it also doesn't solve all of the same problems as systemd. [1] http://www.markshuttleworth.com/archives/1316 http://www.markshuttleworth.com/archives/1316
- vertex-four 12y ago
  > The main alternatives seem to be OpenRC and Upstart. There's also outliers like nosh[0], which implements at least some of the good bits of systemd (socket activation is in there), and the ideas and general architecture are solid enough that it could be extended to implement more (device/path dependencies through udev and inotify are two that I hear people wanting). Then separate pieces of software can implement the remainder of what systemd implements (its many dbus APIs). [0] http://homepage.ntlworld.com/jonathan.deboynepollard/Softwares/nosh.html http://homepage.ntlworld.com/jonathan.deboynepollard/Softwar...
  - exelius 12y ago
    This debate has been raging for the better part of two years and many of these alternatives didn't exist when it started. Really though, systemd has the momentum and I don't see anything else remaining a mainstream alternative unless it just emulates systemd's functionality.

nanoscopic 12y ago

That was a very long and detailed explanation of the sides of the argument. It misses one huge thing: Consistency. The elephant in the room is that most people who dislike systemd simply dislike it because they learned and used init.d scripts, runlevels, and chkconfig, and that is the extent of their understanding. The main hatred for systemd is coming from people simply being resistant to change. If it ain't broke, don't fix it. I like systemd for it's technical merits. I personally would prefer to use a distribution like CentOS in a mode where there is no systemd, simply because I like simplicity and systemd is more confusing to me. What I foresee happening: people who don't like systemd are going to go try other distributions that don't use it, and may abandon the ones that do because it is too much trouble to run them without it. The statement that it will lead to divide between graphical linux users and minimalists is likely very true. Runlevels may be simplistic and outdated, but they are easy to remember.

jamescun 12y ago
That is a rather broad estimation of all those who dislike systemd. While there are people who most likely dislike systemd because they are resistant to change, they don't constitute everyone with objections. I for one dislike systemd, not because I am resistant to change, but on a purely technical basis (which I won't discuss as it has already been reiterated ad nauseam). I must also add that I dislike sysv and like that the community is discussing alternatives; but the race to systemd, with some serious technical failings which have not been addressed, scares me.
uselessdguy 12y ago
No, I specifically addressed this: -------------------------------- "The rather huge scope and opinionated nature of systemd leads to people yearning for the days of sysvinit. A lot of this is ignorance about good design principles, but a good part may also be motivated from an inability to properly convey desires of simple and transparent systems. In this way, proponents and opponents get caught in feedback loops of incessantly going nowhere with flame wars over one initd implementation (that happened to be dominant), completely ignoring all the previous research on improving init, as it all gets left to bite the dust. Even further, most people fail to differentiate init from rc scripts, and sort of hold sysvinit to be equivalent to the shoddy initscripts that distros have written, and all the hacks they bolted on top like LSB headers and startpar(2). This is a huge misunderstanding that leads to a lot of wasted energy." ------------------------------- This isn't about people "hating change". It looks like it, because a lot of people who defend sysvinit aren't really doing that as much as they are defending minimal and transparent systems. In fact, there's way too many people who don't understand "init". Init is the first userspace process that is started. That's it. Init doesn't mean "manages services", "manages processes" or anything like that. Those are separate concepts. The sooner we realize this, the sooner we can have some more innovative architectures for managing services, as we're still trapped in this mental cage. Moreover, it's not just systemd haters who are resistant to change. A lot of systemd lovers are, as well. In fact, the reason we didn't fix the problem earlier and stuck with SysV for so long was precisely because people didn't care about init, and didn't want to change their flawed ways. Well, at least in the Linux communities. Many of the people who resisted change when presented with non-SysV approaches back in the day are the same who now support systemd and lament on how much "systemd haters don't like change". systemd, of course, went significantly beyond service management, and thus had a much bigger impact than previous designs which were rather focused on one problem domain. Thus, systemd simply became far more prominent (and controversial) than anything else because of its huge ambitions.

jude- 12y ago

Thank you for taking the time to write this up! (the link is also appreciated :) I think a lot of the rage and loathing regarding systemd is due to its coupling to the rest of the OS. I think a lot of !systemd users were quiet on this initially (and today even) since it's not hard to avoid systemd if you're not running a full-fledged desktop environment. I think it's the fear that this will change in the near-future that has prompted the backlash we're seeing now. I hope that Debian's new init system coupling GR will address this, both for itself and for its derivative distros. If the rest of the OS does not care about whether or not it's systemd managing the daemons or something else, then everyone wins.