9 ms·

What's wrong with systemd

110 points by uggedal 12y ago

SEJeff 12y ago
TL;DNR version: systemd breaks the one thing that makes Linux great, it's modularity and ability to swap out individual components with separate discrete implementations.
- akerl_ 12y ago
  As somebody who runs systemd with syslog-ng and cronie and netctl, it seems to handle the use of separate individual components just fine. I've seen some decent debates about the viability of systemd, but "it's monolithic" is one of the largest false idols I've seen. It's a collection of systems, the vast majority of which don't run as PID1.
  - SEJeff 12y ago
    The part of systemd that provides pid 1 is relatively small and self contained. Sure there is systemd-networkd, systemd-tmpfiles, systemd-logind, etc, but those all speak to systemd pid 1 via dbus mostly. Anything that wanted to pretend to be one of the various daemons can simply speak the dbus protocol. In fact, this was one of the discussion points in the Debian systemd debate recently.
    - vertex-four 12y ago
      Who defines the dbus protocol? Where's the relevant independent standards body? If we were talking about web browsers, most people would rightfully be livid, as we've seen browsers that decided to go off and do their own thing before, and we're still suffering from them.
      - whoopdedo 12y ago
        When has Linux ever been beholden to an independent standards body? This is an operating built on de facto standardization, not top-down bureaucracy. The W3 is a "tell me where the people are going so I can lead them there" type of organization. Almost every standardized feature in HTML was first implemented as an extension in some browser. When they did conceive of RDF in a committee it received only sparse adoption. We're no closer to a semantic web today than we were in 2002. Linux has only adhered to standards where the standards are actually useful. And it has never waited for an official standard before venturing in a new direction.
        vertex-four 12y ago
        > When has Linux ever been beholden to an independent standards body? It hasn't needed to be because nobody's tried to replace so much of userspace with such a tightly integrated set of programs before, and we've not had programs and services assume that such a mess is being used before. > Linux has only adhered to standards where the standards are actually useful. I would argue that at the point that a number of programs start to depend on complex functionality, where the API is defined by a grand total of one project, some form of standardisation is required. Otherwise, it is nearly impossible for others to reimplement the API correctly, meaning that we will never have meaningful competition within this space without breaking half the services anyone runs. That is not a good thing. Before systemd, I could replace any component of my system independently, and everything would keep working. To a very significant extent, I could even replace my kernel with a BSD, recompile everything, and it all keeps on working! Now, I can no longer do that, because of a variety of packages which have hard dependencies on systemd where previously they worked fine without it.
    - jude- 12y ago
      > Anything that wanted to pretend to be one of the various daemons can simply speak the dbus protocol. The internal DBus API that these components use is not stable and will not be stable for the foreseeable future; according to the systemd developers, parts of systemd cannot be re-implemented independently [1]. That effectively makes systemd a monolithic system--its components are tightly-coupled and cannot be readily swapped out. Note that a system can be both monolithic and modular--systemd, X.org, and the Linux kernel being examples. Systemd gets a bad rap about it because the components that make up systemd were once loosely-coupled, and the need for the new coupling is unjustified. [1] http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/ http://www.freedesktop.org/wiki/Software/systemd/InterfacePo...
- dsr_ 12y ago
  No, I think you got that wrong. TL;DR: systemd's supporters treat anyone who doesn't like it as an enemy to be defeated rather than a fellow traveller who is taking a different path. If I look at launchd or upstart or openrc or runit, I see a project which wants a competitive landscape where they can demonstrate their merits for various uses. When I look at systemd I see Microsoft.
  - akerl_ 12y ago
    This has more to do with the tint of your lenses (and those of the article's author) than the layout of the software.
  - PeterisP 12y ago
    Systemd's supporters might as well be devil-worshipping baby eaters, but that's not any argument for or against systemd as such, that's simply irrelevant.
    - felixgallo 12y ago
      Not entirely irrelevant. Sociopath risk is real.
      - ithkuil 12y ago
        Not sure I understand. Are you implying that we should resist systemd because Poettering is a sociopath?
matthewmacleod 12y ago
I'm kind of indifferent to system's adoption, but I've heard quite a lot of complaints about it that have subsequently turned out to be false. It can sometimes be hard to filter out the noise. However, it looks like most major Linux distributions are going to be using systemd. Fedora, Arch, Debian, Ubuntu (eventually), Redhat, SUSE, even CoreOS. What I don't get is why there would be comprehensive adoption across distributions if systemd was obviously the wrong decision.
rossjudson 12y ago
Seems like sour grapes from the author of another initialization subsystem (mdev). His argument would seem to apply to any effort to standardize initialization on Linux.
- tormeh 12y ago
  Yeah, that seems to be the point, that initialization shouldn't be standardized or at least should be standardized based on a formal spec. It's his entire criticism.
- akerl_ 12y ago
  The point he's making is that having One True System is the death of one of the biggest strengths of the Linux ecosystem: diversity. What he's ignoring is that the various distros that are making this change have done so because they think it's the best decision for their users. No higher power decreed "systemd or death" and forced it on the distros. They've adopted it on its merits, and most have retained the ability to run other init systems if the user wishes. This is a pinnacle of the Linux ecosystem, not a blemish on its record: the larger community is working towards better interoperability between distros.
  - makomk 12y ago
    What the systemd supporters are ignoring is that if the existing init system was as all-encompassing and heavily intertwined with the rest of the system as systemd is, it would be impossible to replace it with systemd no matter how much of an improvement it is.
    - sparkie 12y ago
      This time we have the right design! It will never need replacing, honest.
      - sunfish 12y ago
        One of my favorite phrases from the Refactoring world is "speculative generality". Adding customization points in the present can make adapting in the future easier if the future aligns with your expectations, and harder if it doesn't.
thegeomaster 12y ago
I developed an (unjust) animosity for systemd when a `pacman -Syu` installed it and broke my Arch system (which relied on a small password-prompt initscript written by me that I had completely forgotten about) but when I took a fresh look it didn't look bad. I have only a year of so of real GNU/Linux experience so take this with a grain of salt, but I think that even if systemd's got problems, they're not related to it being too monolithic. And although I haven't really measured, my ancient Atom-based MSI netbook seems to boot way faster than with initscripts.
hdevalence 12y ago
> The systemd developers are responding to upstart and launchd and android init as things they must _defeat_, an establish a new standard by crushing all the competing implementations. This actually... isn't true. If you feel like wasting valuable time of your life, try reading the Debian systemd flamewar: the people with the most rabid 'holy war' attitudes are the systemd opponents. People who favour systemd generally use it to get shit done [1], not write blog posts about 'freedom of choice' [2]. Fedora/RHEL, SuSE, Arch, and now Debian didn't decide switch to systemd because they were all strong-armed by Lennart's evil cabal or something, they did it because each of them decided that it was a superior system. Because it is [3], and no other system, save Upstart, actually put in the work required to be a potential replacement. [1]: https://lists.debian.org/debian-ctte/2014/01/msg00287.html https://lists.debian.org/debian-ctte/2014/01/msg00287.html [2]: http://www.redhat.com/archives/fedora-devel-list/2008-January/msg00861.html http://www.redhat.com/archives/fedora-devel-list/2008-Januar... [3]: http://utcc.utoronto.ca/~cks/space/blog/linux/SystemdWhyItWon http://utcc.utoronto.ca/~cks/space/blog/linux/SystemdWhyItWo...
- magpi3 12y ago
  > People who favour systemd generally use it to get shit done [1], not write blog posts about 'freedom of choice' [2]. I appreciate most of your post, but this line really bugs me because I hear it so often. Relevant xkcd: http://xkcd.com/743/ http://xkcd.com/743/ Valuing open systems/ecosystems is about more than valuing "shit getting done." You also have to value _how_ it gets done, and people who do value how it gets done should not be dismissed as bloggers writing about "freedom of choice."
- mackal 12y ago
  In most cases the opponents are mainly opposed because of Lennart, not technical reasons, not freedom of choice, but because of Lennart. Most of them will explain their reason with refences to technical or freedom of choice but once you get down to it, its just Lennart. You know what your average user wants? A faster booting system. In most cases that will be systemd.
  - rektide 12y ago
asb 12y ago
I fail to understand the swipe at Canonical for having /bin/sh point to dash. Having /bin/sh point to a lightweight POSIX compliant shell seems a wholly sensible choice. Indeed, the ability to swap out one implementation for another (made possible by the POSIX standardisation of the unix shell) seems to be exactly what he's arguing for elsewhere in the article.
- byroot 12y ago
  I'm pretty sure this change was initiated by Debian. I recall it was already the case on Debian stable circa 2008.
  - masklinn 12y ago
    According to each distribution's documentation, Debian switched to dash in 2011 with Squeeze[0] whereas Ubuntu switched in 2006[1] [0] https://wiki.debian.org/Shell https://wiki.debian.org/Shell [1] https://wiki.ubuntu.com/DashAsBinSh https://wiki.ubuntu.com/DashAsBinSh
    - teddyh 12y ago
      That is misleading. Debian seems to have changed earlier, but not done an official release for some time after the change; Ubuntu took, as they always do, this unreleased version of Debian and released it as the new version of Ubuntu.
      - masklinn 12y ago
        > That is misleading. No. Even if you don't agree that a stable release is the correct check point, that means the change was done during Squeeze's testing cycle and thus Lenny's lifetime, which started in 2009. Fact remains that Ubuntu switched years before Debian, as a number of sources confirm such as this LWN post from July 29, 2009[0] noting that, at that time, dash remained a topic of discussion on Debian mailing lists (and an unrealised goal for Lenny) whereas Ubuntu had switched 3 years prior. > Ubuntu took, as they always do, this unreleased version of Debian and released it as the new version of Ubuntu. That's not just "misleading", that's outright bullshit. Ubuntu switched to dash as /bin/sh independently from Debian and regardless of what Debian did. [0] http://lwn.net/Articles/343924/ http://lwn.net/Articles/343924/
intslack 12y ago
The vast majority of distros seem to agree that standardization is a good thing in the switch to systemd. If you don't want to be standardized maintain it yourself, see: GoboLinux. But modularity of Linux doesn't seem to be going anywhere. Contrary to what the author says, systemd is not monolithic but rather consists of protocols and multiple daemons outside of PID1. There doesn't seem to be any plans to stop one from using anything other than systemd on say Debian either. As far as I know the only hard requirement for systemd (really logind) is with Gnome on Wayland for user seats, because Consolekit is dead. Gnome seems to be willing to work with the *BSDs et al who have no plans to switch to systemd. https://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logindsystemd-thoughts/ https://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logind...
- Sanddancer 12y ago
  The problem is that while systemd is superficially a bunch of different commands, they are a clinking, clanking mess of poorly documented programs that do their job worse than the programs they replace. For a moment, let's look at one of these components, systemd-backlight, and it's terribly written manual page, http://www.freedesktop.org/software/systemd/man/systemd-backlight.html http://www.freedesktop.org/software/systemd/man/systemd-back... . Okay, so what return values can you expect? Where on the filesystem does it store the saved values so you can debug if things do go cactus? Why does it always overwrite the value at shutdown? These are all things that a reasonable program either should not do, or should document why and where they put things. Systemd just is not a responsible, well-engineered project. Furtnermore, the only real reason consolekit is dead is because Lennart again shows a complete lack of responsibility as a developer with that project. He'd rather shove everyone towards his new baby of systemd than to do a responsible hand-off. This is furthered in his inability to document the interfaces used so that people can write compatible software, so that people can debug software, and so that people can maintain things if he ever gets hit by the number eight bus going downtown. It's just not a good way to run things, period.
  - JoshTriplett 12y ago
    > Where on the filesystem does it store the saved values so you can debug if things do go cactus? Quoting the page you linked to: "On disk, the backlight brightness is stored in /var/lib/systemd/backlight/."
lasermike026 12y ago
I agree with this article. In addition, systemd, upstart, and launchd are just not up to it. Time to go back to the drawing board.
- duskwuff 12y ago
  The fact that you're mentioning launchd in the same breath as systemd and upstart suggests that you don't actually know a lot about the situation. launchd is a Mac OS X init equivalent. It has never, to the best of my knowledge, been ported to Linux at all.
  - lasermike026 12y ago
    You didn't read the article. Launchd is being ported to BSD. If you knew anything about about any of these inits you would see their similarities.
    - duskwuff 12y ago
      The article's not particularly accurate on that note. There is a project to port launchd to FreeBSD, but it's basically stalled: no commits or mailing list posts in over a month, and it's not clear that it's even been successfully compiled on FreeBSD yet. https://github.com/rtyler/openlaunchd https://github.com/rtyler/openlaunchd
erikb 12y ago
Aren't the init wars just over? I saw photos from the still running German Linux Tag were people are wearing T-shirts with "I survived the init war" (or something like that) on it. I think we better leave it at that.
- vezzy-fnord 12y ago
  The init war was never properly "fought" to begin with. It was presented as a false trichotomy between systemd, Upstart and OpenRC, when there were other options lying in plain sight that could have been researched, such as depinit: https://web.archive.org/web/20050206182736/http://www.nezumi.plus.com/depinit/index.html https://web.archive.org/web/20050206182736/http://www.nezumi... systemd was simply far more visible and offered more than Upstart, which wasn't all that well engineered, admittedly. OpenRC was largely skimmed over, for some reason. systemd also had that aura of being "innovative," even though most of its concepts are old and were done well by systems such as Solaris SMF (although it isn't without flaws, either). systemd came in at the right place, right time, was given a boost by a company as renowned in the developer community as Red Hat, and as such was adopted as a solution by people looking for a convenient fix, rather than actually trying to tackle the issue from the core.
  - sounds 12y ago
    I've had great success with OpenRC.
  - erikb 12y ago
    I agree that the two developers are really good community people and therefore are able to win over votes that might not be as objective as they should have been. But I think it's also a skill to tackle a community together and focus them on one goal. This also improves FOSS as a whole, even if the software might not be the best.
vezzy-fnord 12y ago
The main source of ideological disagreement between pro-systemd and anti-systemd users is just how much an init should handle. Anti-systemd side insists on init being just an init and not exceeding its duties, whereas pro-systemd are willing to make the init handle various other functions, due to the alleged benefits. I think at this point it's erroneous to call systemd an "init system," it's far more than that and Lennart himself freely admits it in (ironically) the article meant to dispel systemd myths (http://0pointer.de/blog/projects/the-biggest-myths.html http://0pointer.de/blog/projects/the-biggest-myths.html): Well, systemd certainly covers more ground that it used to. It's not just an init system anymore, but the basic userspace building block to build an OS from, but we carefully make sure to keep most of the features optional. You can turn a lot off at compile time, and even more at runtime. Thus you can choose freely how much feature creeping you want. I'm not entirely sure about how optional the whole package really is. I know for a fact LXC tools like systemd-nspawn, Python bindings, etc. can be removed from the build using ./configure, but I don't know the full extent to judge the veracity of his claims. Olav Vitters of GNOME and Debian (I believe?) later echoes the same sentiment in a somewhat self-contradictory manner: http://lwn.net/Articles/575790/ http://lwn.net/Articles/575790/ Systemd is meant to do one thing and do it well: be the basic building block for Linux. Of course, one must first define what a "basic building block for Linux" is, although that isn't really elaborated. Personally, I don't have any strong opinions in favor of or against systemd, but I do feel it was introduced in a rather rushed manner. I think it would have payed off better for the community if people researched certain alternate init schemes that were already present before systemd (not talking about launchd/Upstart), such as Richard Lightman's depinit: https://web.archive.org/web/20050206182736/http://www.nezumi.plus.com/depinit/index.html https://web.archive.org/web/20050206182736/http://www.nezumi... However, it's probably a bit late by now, since systemd's place has been set in stone, for better or for worse.
revscat 12y ago
Could someone with more knowledge about the subject explain why launchd was never taken up outside of OS X? I'm not an admin by any stretch of the imagination, but it seems to fit the bill fairly well, and I've always wondered why it has not been ported elsewhere.
- vezzy-fnord 12y ago
  Licensing issues at the time. That's what Upstart was initially meant to be, actually: a native launchd clone. If it wasn't for the Apple Public Source License that launchd was under back in 2006, Ubuntu would have probably been using it right now.
- vvhn 12y ago
  launchd makes heavy use of Mach IPC ( http://en.wikipedia.org/wiki/Mach_(kernel) http://en.wikipedia.org/wiki/Mach_(kernel) ) which makes a port to any other non Mach derived OS a non trivial effort. There was apparently an effort to port it to FreeBSD - https://wiki.freebsd.org/launchd https://wiki.freebsd.org/launchd and more recently https://github.com/rtyler/openlaunchd/blob/master/README.md https://github.com/rtyler/openlaunchd/blob/master/README.md .
- JoshTriplett 12y ago
  Partly because launchd didn't have a sensible Open Source license, and partly for the same reason systemd doesn't run on non-Linux kernels: it's designed for its target OS, and makes use of that OS's native functionality to the point that porting would become decidedly non-trivial. systemd took heavy inspiration from launchd and other sources, but provides extensive functionality that launchd does not.
- jordigh 12y ago
  systemd is essentially a reimplementation of launchd for Linux. The systemd devs explicitly acknowledge this inspiration.
jqm 12y ago
I have no problem with systemd but neither do I have a reason to use it (although I admit, Poettering's general attitude does bother me a bit). As long as Slackware doesn't incorporate systemd and alternatives remain I'm fine. If alternative disappear, I guess I'll cross that bridge when it happens.
pmoriarty 12y ago
Does anyone have any insight in to why something like runit[1] was never a serious candidate for a sysvinit replacement in any mainstream Linux distro? [1] - http://smarden.org/runit/ http://smarden.org/runit/
- zdw 12y ago
  A few reasons: - There's a general opposition to the djb's designs and tools, which has some basis in their licensing, and is why djbdns and qmail aren't in the default distro of most systems. Note that this is being reversed right now with the embrace of NaCL crypto (Salsa20/ChaCha/Poly1305, etc.) as alternatives to the mainstream. - runit is pretty much an reimplementation of djb's daemontools for service supervision. - runit/daemontools definitely do things their own way. Service directories make sense, but they tend to be shell scripts all the way down. Logging is quite different and non-centralized. Services need to be set not to fork and do their own daemon management. And the list tends to go on - this unusual-ness is generally not what people want from a core OS part. So, in short, there's no reason why people haven't used runit, other than "nobody else is doing it" and "it's different and has quirks".
  - pjscott 12y ago
    Note that both djbdns and qmail have been in the public domain for years now. The general opposition to their license seems to have long outlived their license.
    - zdw 12y ago
      I think that's more related to the non-unified, pre-DVCS patch centric model of development, and the fact that djb has better things to do/is no longer interested in developing them. If djb would have found an interested party to accept patches to the codebase, set it up on a code hosting site, then declared "this is the main repo for continuation of djbdns/qmail development", it would have gone a lot further than just "it's in the public domain" and no other guidance. This has lead to things like "dbndns", which are a good attempt, but definitely not a general, cross unix version solution: http://packages.qa.debian.org/d/djbdns.html http://packages.qa.debian.org/d/djbdns.html
JoshTriplett 12y ago
Replying to the article: > The first issue is that Linux has always been a commodity white box OS built from interchangeable parts available from multiple sources, just like the PC. Systemd goes out of its way to break that, and in doing so represents an enormous loss of flexibility. systemd goes out of its way to fix the massive integration failures we've had for decades (and seen as almost unfixable) because Linux is so focused on modularity to a fault. And because of systemd, we're finally starting to get a level of integration that previously only appeared in proprietary operating systems. http://islinuxaboutchoice.com/ http://islinuxaboutchoice.com/ Linux is good at evolutionary changes, but not nearly as good at escaping local maxima via large-scale cross-project changes. Not least of which because anyone attempting to make such changes has to be prepared for the anti-change "but the UNIX way!" flames. Every time I see someone railing about the UNIX way, I think of how people flame each other about / versus /usr, and how the original motivation for /usr was "we ran out of space on /, put some of the less critical stuff on the user disk". Appeal to tradition is not an argument unless you have a concrete reason why the tradition is better, and I rarely see such reasoning in arguments leveled against systemd. I've also found that well-articulated and well-founded arguments about problems in systemd don't tend to last long, because systemd will fix them. I'd encourage people who see a legitimate technical problem with systemd to go discuss it on the systemd mailing list; you might be surprised how quickly it gets fixed, if it has substance. > Linux systems are modular, with multiple implementations of anything important. Feel free to make something better than systemd, document it as extensively as systemd, spend years writing guides to its most compelling features that get people eager to switch, and do as much work as the systemd developers did to help the entire Linux ecosystem adopt it with shockingly few technical problems. There's nothing stopping you; you can even leverage the entire systemd codebase in the process. Fork it and change what you don't like, if you think you can keep up. Good luck; you'll need it. > But systemd isn't like that. It's a single all or nothing blob Refuted so many times that anyone still saying this is either intentionally misleading or utterly uninformed about what they're railing against. systemd runs incredibly little in PID 1; it has numerous separate single-purpose processes (typically named /usr/bin/systemd-foo or /lib/systemd/systemd-foo), as well as several libraries abstracting out key bits of common functionality for other code to use. > Ubuntu did upstart, but ubuntu also did unity, and mir, and pointed /bin/sh to dash, and their launchpad is based on the obsolete "bazaar" source control system... People not following Ubuntu's technical lead is pretty deeply justified at this point. Now this one is actually a very well-made point, and it's something few people have stated outright. There's a reason that few other distributions switched to upstart; while it adds a few key features over sysvinit (such as service supervision), it has some serious deficiencies as well. It's not at all clear that switching from sysvinit to upstart would have been an improvement. And the biggest key feature of upstart, service supervision, is actually something sysvinit already has but nobody uses: you can run a process directly from inittab, and sysvinit will restart it when it exits. But rather than using that, every Linux distribution just uses sysvinit to launch a shell script that launches a hundred other shell scripts. That said, I applaud Ubuntu for actually trying to make major changes to Linux. Unity isn't what everyone wants, but it's certainly an attempt at a non-incremental improvement over other desktop environments, and it has some nice properties. Similarly, Bazaar was an attempt to do better than CVS and SVN, and it's not wildly awful; it just lost to an even better system for a variety of reasons (http://www.stationary-traveller.eu/pages/bzr-a-retrospective.html http://www.stationary-traveller.eu/pages/bzr-a-retrospective...). /bin/sh -> dash is, while not necessarily inherently better, an attempt to enforce an absence of bashisms in #!/bin/sh scripts, and an attempt to improve the performance of such scripts; in that, it has worked reasonably well. There's no excuse for Mir, though. :) > Android also has a no GPL in userspace policy Not exactly, though Android certainly pushes back on GPLed code. They're willing to adopt it when there's no viable alternative. But systemd is LGPL these days, not GPL. And even if systemd were GPL, it would still be quite possible to use systemd as an init system to launch proprietary software. Regardless of Android's allergy to copyleft, permissive-versus-copyleft is an ancient holy war that long predates Android. The only reason the argument comes up so strongly in this case is that systemd is the right combination of rapidly developed and too useful to ignore to make it a serious threat to people who don't want to use it. If systemd were less useful, or otherwise easier to clone, its copyleft license would be less of a concern to the opponents of copyleft. That's a feature, and it's exactly the kind of thing the authors of the GPL and LGPL had in mind: the existence of high-quality software under copyleft licenses that make life difficult for the proprietary software world. Personally, I was rather disappointed when systemd switched to the LGPL; I would have rather seen it remain GPL. > Those of us waiting to see how it shakes out feel we're having systemd shoved down our throats by a development team actively threatened by the idea of people _not_ using their stuff. It couldn't possibly be that the software is sufficiently compelling that those without religious objections to it are switching to it to take advantage of its useful features. No, it must be a conspiracy. > But even if it wanted to, android can't easily clone systemd, becuase it's (intentionally) a moving target with no standard and no documentation. "no documentation" is insultingly misinformed; systemd is one of the best documented software products I've ever seen. And in any case, why should the systemd developers go out of their way to make life easier for people who don't want to use systemd, when they could instead spend their time making life better for people who want to use systemd? > We can't opt out and see how it goes, we must fight to stay where we are. Sure you can opt out: just sit there doing nothing, and the world will pass you by. Or you can participate, and do as much work as the systemd developers are doing, in favor of your preferred system. What you can't do is try to stop other people from doing work you don't like without putting at least as much work into a better alternative. Keep up or get out of the way, don't shout "wait up" or "no fair".
blux 12y ago
So, why not fork systemd and modularize it...?
- jude- 12y ago
  I think OpenBSD is working on that this summer. http://www.openbsdfoundation.org/gsoc2014.html#systemd http://www.openbsdfoundation.org/gsoc2014.html#systemd
Aloha 12y ago
I still sorta look at systemd as a solution looking for a problem. System V style init is just 'good enough' for most applications - and if there is anything I've found in my time, the only people more adverse to change then telecom folks are Unix system administrators.
Workaphobia 12y ago
There was a lot of repetition about X, Y, and Z being anathema to the systemd people. I would've appreciated some links backing up these claims of their hostility. I've heard so much against systemd, and so little that wasn't hearsay. (This is not a comment on the merits of the objections against systemd, just on the exposure to the arguments I've gotten from casually browsing hackernews.)
drdaeman 12y ago
> So the systemd developers are saying a billion android devices aren't interesting [...] Isn't being anti-GPL (and pro-vendor/anti-consumer) primarily Android's and not systemd's issue? Even considering that Android is a big thing, it's still possibly unwise to get rid of copyleft just to please Google and be accepted into phone vendors' proprietary blobs.
skylan_q 12y ago
The theme of Monolithic vs. Modular reminds me of Linux vs. Minix. The Tanenbaum–Torvalds debate was a debate between Andrew S. Tanenbaum and Linus Torvalds, regarding Linux and kernel architecture in general. Tanenbaum began the debate in 1992 on the Usenet discussion group comp.os.minix, arguing that microkernels are superior to monolithic kernels and therefore Linux was, even in 1992, obsolete. Other notable hackers such as David S. Miller and Theodore Ts'o joined the debate. http://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate http://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_deba... A link to the newsgroup discussion: https://groups.google.com/forum/#!topic/comp.os.minix/wlhw16QWltI[1-25-false] https://groups.google.com/forum/#!topic/comp.os.minix/wlhw16...
- jude- 12y ago
  More like a tightly-coupled (monolithic) vs loosely-coupled (non-monolithic) debate. Systemd is modular, but its components are tightly-coupled. The key difference between systemd vs the existing userspace, and Linux vs Minix, is that there's ~50 years precedent of loosely-coupled being the winning design paradigm in the long run. This is because a system made of loosely-coupled components allows the user to add, remove, and swap out parts independently of one another without having to drop the whole OS, thereby gaining the ability to adapt the OS to a changing set of requirements with minimal cost. Tightly-coupled systems do not have this advantage, and it makes them brittle in the face of change.
whoopdedo 12y ago
I've been a stick-in-the-mud about changing to systemd until I bumped into an ugly wart of sysvinit. While upgrading a service I moved the old daemon aside in case I wanted to downgrade again, then remembered that I hadn't killed it. So typed `/etc/init.d/myservice stop` and saw it did nothing. Huh? Oh, that's right. The simplistic script won't do anything if the daemon file doesn't exist. I had to manually kill the PID. So would I be correct in assuming that systemd would know the service names of all running daemons and be able to stop them without having to check to original file?
- vezzy-fnord 12y ago
  Well yes, systemd is far more sophisticated than sysvinit. No one here is advocating for sysvinit, as it does need a proper successor. "sysvinit or systemd" is a false dichotomy, however.
pjmlp 12y ago
Interesting how the evolution of GNU/Linux distributions and their interactions with other UNIX systems just look like the second coming of UNIX wars.

110 points by uggedal 12y ago

TL;DNR version: systemd breaks the one thing that makes Linux great, it's modularity and ability to swap out individual components with separate discrete implementations.

akerl_ 12y ago
As somebody who runs systemd with syslog-ng and cronie and netctl, it seems to handle the use of separate individual components just fine. I've seen some decent debates about the viability of systemd, but "it's monolithic" is one of the largest false idols I've seen. It's a collection of systems, the vast majority of which don't run as PID1.
- SEJeff 12y ago
  The part of systemd that provides pid 1 is relatively small and self contained. Sure there is systemd-networkd, systemd-tmpfiles, systemd-logind, etc, but those all speak to systemd pid 1 via dbus mostly. Anything that wanted to pretend to be one of the various daemons can simply speak the dbus protocol. In fact, this was one of the discussion points in the Debian systemd debate recently.
  - vertex-four 12y ago
    Who defines the dbus protocol? Where's the relevant independent standards body? If we were talking about web browsers, most people would rightfully be livid, as we've seen browsers that decided to go off and do their own thing before, and we're still suffering from them.
    - whoopdedo 12y ago
      When has Linux ever been beholden to an independent standards body? This is an operating built on de facto standardization, not top-down bureaucracy. The W3 is a "tell me where the people are going so I can lead them there" type of organization. Almost every standardized feature in HTML was first implemented as an extension in some browser. When they did conceive of RDF in a committee it received only sparse adoption. We're no closer to a semantic web today than we were in 2002. Linux has only adhered to standards where the standards are actually useful. And it has never waited for an official standard before venturing in a new direction.
      - vertex-four 12y ago
        > When has Linux ever been beholden to an independent standards body? It hasn't needed to be because nobody's tried to replace so much of userspace with such a tightly integrated set of programs before, and we've not had programs and services assume that such a mess is being used before. > Linux has only adhered to standards where the standards are actually useful. I would argue that at the point that a number of programs start to depend on complex functionality, where the API is defined by a grand total of one project, some form of standardisation is required. Otherwise, it is nearly impossible for others to reimplement the API correctly, meaning that we will never have meaningful competition within this space without breaking half the services anyone runs. That is not a good thing. Before systemd, I could replace any component of my system independently, and everything would keep working. To a very significant extent, I could even replace my kernel with a BSD, recompile everything, and it all keeps on working! Now, I can no longer do that, because of a variety of packages which have hard dependencies on systemd where previously they worked fine without it.
  - jude- 12y ago
    > Anything that wanted to pretend to be one of the various daemons can simply speak the dbus protocol. The internal DBus API that these components use is not stable and will not be stable for the foreseeable future; according to the systemd developers, parts of systemd cannot be re-implemented independently [1]. That effectively makes systemd a monolithic system--its components are tightly-coupled and cannot be readily swapped out. Note that a system can be both monolithic and modular--systemd, X.org, and the Linux kernel being examples. Systemd gets a bad rap about it because the components that make up systemd were once loosely-coupled, and the need for the new coupling is unjustified. [1] http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/ http://www.freedesktop.org/wiki/Software/systemd/InterfacePo...
dsr_ 12y ago
No, I think you got that wrong. TL;DR: systemd's supporters treat anyone who doesn't like it as an enemy to be defeated rather than a fellow traveller who is taking a different path. If I look at launchd or upstart or openrc or runit, I see a project which wants a competitive landscape where they can demonstrate their merits for various uses. When I look at systemd I see Microsoft.
- akerl_ 12y ago
  This has more to do with the tint of your lenses (and those of the article's author) than the layout of the software.
- PeterisP 12y ago
  Systemd's supporters might as well be devil-worshipping baby eaters, but that's not any argument for or against systemd as such, that's simply irrelevant.
  - felixgallo 12y ago
    Not entirely irrelevant. Sociopath risk is real.
    - ithkuil 12y ago
      Not sure I understand. Are you implying that we should resist systemd because Poettering is a sociopath?

matthewmacleod 12y ago

I'm kind of indifferent to system's adoption, but I've heard quite a lot of complaints about it that have subsequently turned out to be false. It can sometimes be hard to filter out the noise. However, it looks like most major Linux distributions are going to be using systemd. Fedora, Arch, Debian, Ubuntu (eventually), Redhat, SUSE, even CoreOS. What I don't get is why there would be comprehensive adoption across distributions if systemd was obviously the wrong decision.

rossjudson 12y ago

Seems like sour grapes from the author of another initialization subsystem (mdev). His argument would seem to apply to any effort to standardize initialization on Linux.

tormeh 12y ago
Yeah, that seems to be the point, that initialization shouldn't be standardized or at least should be standardized based on a formal spec. It's his entire criticism.
akerl_ 12y ago
The point he's making is that having One True System is the death of one of the biggest strengths of the Linux ecosystem: diversity. What he's ignoring is that the various distros that are making this change have done so because they think it's the best decision for their users. No higher power decreed "systemd or death" and forced it on the distros. They've adopted it on its merits, and most have retained the ability to run other init systems if the user wishes. This is a pinnacle of the Linux ecosystem, not a blemish on its record: the larger community is working towards better interoperability between distros.
- makomk 12y ago
  What the systemd supporters are ignoring is that if the existing init system was as all-encompassing and heavily intertwined with the rest of the system as systemd is, it would be impossible to replace it with systemd no matter how much of an improvement it is.
  - sparkie 12y ago
    This time we have the right design! It will never need replacing, honest.
    - sunfish 12y ago
      One of my favorite phrases from the Refactoring world is "speculative generality". Adding customization points in the present can make adapting in the future easier if the future aligns with your expectations, and harder if it doesn't.

thegeomaster 12y ago

I developed an (unjust) animosity for systemd when a `pacman -Syu` installed it and broke my Arch system (which relied on a small password-prompt initscript written by me that I had completely forgotten about) but when I took a fresh look it didn't look bad. I have only a year of so of real GNU/Linux experience so take this with a grain of salt, but I think that even if systemd's got problems, they're not related to it being too monolithic. And although I haven't really measured, my ancient Atom-based MSI netbook seems to boot way faster than with initscripts.

hdevalence 12y ago

> The systemd developers are responding to upstart and launchd and android init as things they must _defeat_, an establish a new standard by crushing all the competing implementations. This actually... isn't true. If you feel like wasting valuable time of your life, try reading the Debian systemd flamewar: the people with the most rabid 'holy war' attitudes are the systemd opponents. People who favour systemd generally use it to get shit done [1], not write blog posts about 'freedom of choice' [2]. Fedora/RHEL, SuSE, Arch, and now Debian didn't decide switch to systemd because they were all strong-armed by Lennart's evil cabal or something, they did it because each of them decided that it was a superior system. Because it is [3], and no other system, save Upstart, actually put in the work required to be a potential replacement. [1]: https://lists.debian.org/debian-ctte/2014/01/msg00287.html https://lists.debian.org/debian-ctte/2014/01/msg00287.html [2]: http://www.redhat.com/archives/fedora-devel-list/2008-January/msg00861.html http://www.redhat.com/archives/fedora-devel-list/2008-Januar... [3]: http://utcc.utoronto.ca/~cks/space/blog/linux/SystemdWhyItWon http://utcc.utoronto.ca/~cks/space/blog/linux/SystemdWhyItWo...

magpi3 12y ago
> People who favour systemd generally use it to get shit done [1], not write blog posts about 'freedom of choice' [2]. I appreciate most of your post, but this line really bugs me because I hear it so often. Relevant xkcd: http://xkcd.com/743/ http://xkcd.com/743/ Valuing open systems/ecosystems is about more than valuing "shit getting done." You also have to value _how_ it gets done, and people who do value how it gets done should not be dismissed as bloggers writing about "freedom of choice."
mackal 12y ago
In most cases the opponents are mainly opposed because of Lennart, not technical reasons, not freedom of choice, but because of Lennart. Most of them will explain their reason with refences to technical or freedom of choice but once you get down to it, its just Lennart. You know what your average user wants? A faster booting system. In most cases that will be systemd.
- rektide 12y ago

asb 12y ago

I fail to understand the swipe at Canonical for having /bin/sh point to dash. Having /bin/sh point to a lightweight POSIX compliant shell seems a wholly sensible choice. Indeed, the ability to swap out one implementation for another (made possible by the POSIX standardisation of the unix shell) seems to be exactly what he's arguing for elsewhere in the article.

byroot 12y ago
I'm pretty sure this change was initiated by Debian. I recall it was already the case on Debian stable circa 2008.
- masklinn 12y ago
  According to each distribution's documentation, Debian switched to dash in 2011 with Squeeze[0] whereas Ubuntu switched in 2006[1] [0] https://wiki.debian.org/Shell https://wiki.debian.org/Shell [1] https://wiki.ubuntu.com/DashAsBinSh https://wiki.ubuntu.com/DashAsBinSh
  - teddyh 12y ago
    That is misleading. Debian seems to have changed earlier, but not done an official release for some time after the change; Ubuntu took, as they always do, this unreleased version of Debian and released it as the new version of Ubuntu.
    - masklinn 12y ago
      > That is misleading. No. Even if you don't agree that a stable release is the correct check point, that means the change was done during Squeeze's testing cycle and thus Lenny's lifetime, which started in 2009. Fact remains that Ubuntu switched years before Debian, as a number of sources confirm such as this LWN post from July 29, 2009[0] noting that, at that time, dash remained a topic of discussion on Debian mailing lists (and an unrealised goal for Lenny) whereas Ubuntu had switched 3 years prior. > Ubuntu took, as they always do, this unreleased version of Debian and released it as the new version of Ubuntu. That's not just "misleading", that's outright bullshit. Ubuntu switched to dash as /bin/sh independently from Debian and regardless of what Debian did. [0] http://lwn.net/Articles/343924/ http://lwn.net/Articles/343924/

intslack 12y ago

The vast majority of distros seem to agree that standardization is a good thing in the switch to systemd. If you don't want to be standardized maintain it yourself, see: GoboLinux. But modularity of Linux doesn't seem to be going anywhere. Contrary to what the author says, systemd is not monolithic but rather consists of protocols and multiple daemons outside of PID1. There doesn't seem to be any plans to stop one from using anything other than systemd on say Debian either. As far as I know the only hard requirement for systemd (really logind) is with Gnome on Wayland for user seats, because Consolekit is dead. Gnome seems to be willing to work with the *BSDs et al who have no plans to switch to systemd. https://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logindsystemd-thoughts/ https://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logind...

Sanddancer 12y ago
The problem is that while systemd is superficially a bunch of different commands, they are a clinking, clanking mess of poorly documented programs that do their job worse than the programs they replace. For a moment, let's look at one of these components, systemd-backlight, and it's terribly written manual page, http://www.freedesktop.org/software/systemd/man/systemd-backlight.html http://www.freedesktop.org/software/systemd/man/systemd-back... . Okay, so what return values can you expect? Where on the filesystem does it store the saved values so you can debug if things do go cactus? Why does it always overwrite the value at shutdown? These are all things that a reasonable program either should not do, or should document why and where they put things. Systemd just is not a responsible, well-engineered project. Furtnermore, the only real reason consolekit is dead is because Lennart again shows a complete lack of responsibility as a developer with that project. He'd rather shove everyone towards his new baby of systemd than to do a responsible hand-off. This is furthered in his inability to document the interfaces used so that people can write compatible software, so that people can debug software, and so that people can maintain things if he ever gets hit by the number eight bus going downtown. It's just not a good way to run things, period.
- JoshTriplett 12y ago
  > Where on the filesystem does it store the saved values so you can debug if things do go cactus? Quoting the page you linked to: "On disk, the backlight brightness is stored in /var/lib/systemd/backlight/."

lasermike026 12y ago

I agree with this article. In addition, systemd, upstart, and launchd are just not up to it. Time to go back to the drawing board.

duskwuff 12y ago
The fact that you're mentioning launchd in the same breath as systemd and upstart suggests that you don't actually know a lot about the situation. launchd is a Mac OS X init equivalent. It has never, to the best of my knowledge, been ported to Linux at all.
- lasermike026 12y ago
  You didn't read the article. Launchd is being ported to BSD. If you knew anything about about any of these inits you would see their similarities.
  - duskwuff 12y ago
    The article's not particularly accurate on that note. There is a project to port launchd to FreeBSD, but it's basically stalled: no commits or mailing list posts in over a month, and it's not clear that it's even been successfully compiled on FreeBSD yet. https://github.com/rtyler/openlaunchd https://github.com/rtyler/openlaunchd

erikb 12y ago

Aren't the init wars just over? I saw photos from the still running German Linux Tag were people are wearing T-shirts with "I survived the init war" (or something like that) on it. I think we better leave it at that.

vezzy-fnord 12y ago
The init war was never properly "fought" to begin with. It was presented as a false trichotomy between systemd, Upstart and OpenRC, when there were other options lying in plain sight that could have been researched, such as depinit: https://web.archive.org/web/20050206182736/http://www.nezumi.plus.com/depinit/index.html https://web.archive.org/web/20050206182736/http://www.nezumi... systemd was simply far more visible and offered more than Upstart, which wasn't all that well engineered, admittedly. OpenRC was largely skimmed over, for some reason. systemd also had that aura of being "innovative," even though most of its concepts are old and were done well by systems such as Solaris SMF (although it isn't without flaws, either). systemd came in at the right place, right time, was given a boost by a company as renowned in the developer community as Red Hat, and as such was adopted as a solution by people looking for a convenient fix, rather than actually trying to tackle the issue from the core.
- sounds 12y ago
  I've had great success with OpenRC.
- erikb 12y ago
  I agree that the two developers are really good community people and therefore are able to win over votes that might not be as objective as they should have been. But I think it's also a skill to tackle a community together and focus them on one goal. This also improves FOSS as a whole, even if the software might not be the best.

vezzy-fnord 12y ago

The main source of ideological disagreement between pro-systemd and anti-systemd users is just how much an init should handle. Anti-systemd side insists on init being just an init and not exceeding its duties, whereas pro-systemd are willing to make the init handle various other functions, due to the alleged benefits. I think at this point it's erroneous to call systemd an "init system," it's far more than that and Lennart himself freely admits it in (ironically) the article meant to dispel systemd myths (http://0pointer.de/blog/projects/the-biggest-myths.html http://0pointer.de/blog/projects/the-biggest-myths.html): Well, systemd certainly covers more ground that it used to. It's not just an init system anymore, but the basic userspace building block to build an OS from, but we carefully make sure to keep most of the features optional. You can turn a lot off at compile time, and even more at runtime. Thus you can choose freely how much feature creeping you want. I'm not entirely sure about how optional the whole package really is. I know for a fact LXC tools like systemd-nspawn, Python bindings, etc. can be removed from the build using ./configure, but I don't know the full extent to judge the veracity of his claims. Olav Vitters of GNOME and Debian (I believe?) later echoes the same sentiment in a somewhat self-contradictory manner: http://lwn.net/Articles/575790/ http://lwn.net/Articles/575790/ Systemd is meant to do one thing and do it well: be the basic building block for Linux. Of course, one must first define what a "basic building block for Linux" is, although that isn't really elaborated. Personally, I don't have any strong opinions in favor of or against systemd, but I do feel it was introduced in a rather rushed manner. I think it would have payed off better for the community if people researched certain alternate init schemes that were already present before systemd (not talking about launchd/Upstart), such as Richard Lightman's depinit: https://web.archive.org/web/20050206182736/http://www.nezumi.plus.com/depinit/index.html https://web.archive.org/web/20050206182736/http://www.nezumi... However, it's probably a bit late by now, since systemd's place has been set in stone, for better or for worse.

revscat 12y ago

Could someone with more knowledge about the subject explain why launchd was never taken up outside of OS X? I'm not an admin by any stretch of the imagination, but it seems to fit the bill fairly well, and I've always wondered why it has not been ported elsewhere.

vezzy-fnord 12y ago
Licensing issues at the time. That's what Upstart was initially meant to be, actually: a native launchd clone. If it wasn't for the Apple Public Source License that launchd was under back in 2006, Ubuntu would have probably been using it right now.
vvhn 12y ago
launchd makes heavy use of Mach IPC ( http://en.wikipedia.org/wiki/Mach_(kernel) http://en.wikipedia.org/wiki/Mach_(kernel) ) which makes a port to any other non Mach derived OS a non trivial effort. There was apparently an effort to port it to FreeBSD - https://wiki.freebsd.org/launchd https://wiki.freebsd.org/launchd and more recently https://github.com/rtyler/openlaunchd/blob/master/README.md https://github.com/rtyler/openlaunchd/blob/master/README.md .
JoshTriplett 12y ago
Partly because launchd didn't have a sensible Open Source license, and partly for the same reason systemd doesn't run on non-Linux kernels: it's designed for its target OS, and makes use of that OS's native functionality to the point that porting would become decidedly non-trivial. systemd took heavy inspiration from launchd and other sources, but provides extensive functionality that launchd does not.
jordigh 12y ago
systemd is essentially a reimplementation of launchd for Linux. The systemd devs explicitly acknowledge this inspiration.

jqm 12y ago

I have no problem with systemd but neither do I have a reason to use it (although I admit, Poettering's general attitude does bother me a bit). As long as Slackware doesn't incorporate systemd and alternatives remain I'm fine. If alternative disappear, I guess I'll cross that bridge when it happens.

pmoriarty 12y ago

Does anyone have any insight in to why something like runit[1] was never a serious candidate for a sysvinit replacement in any mainstream Linux distro? [1] - http://smarden.org/runit/ http://smarden.org/runit/

zdw 12y ago
A few reasons: - There's a general opposition to the djb's designs and tools, which has some basis in their licensing, and is why djbdns and qmail aren't in the default distro of most systems. Note that this is being reversed right now with the embrace of NaCL crypto (Salsa20/ChaCha/Poly1305, etc.) as alternatives to the mainstream. - runit is pretty much an reimplementation of djb's daemontools for service supervision. - runit/daemontools definitely do things their own way. Service directories make sense, but they tend to be shell scripts all the way down. Logging is quite different and non-centralized. Services need to be set not to fork and do their own daemon management. And the list tends to go on - this unusual-ness is generally not what people want from a core OS part. So, in short, there's no reason why people haven't used runit, other than "nobody else is doing it" and "it's different and has quirks".
- pjscott 12y ago
  Note that both djbdns and qmail have been in the public domain for years now. The general opposition to their license seems to have long outlived their license.
  - zdw 12y ago
    I think that's more related to the non-unified, pre-DVCS patch centric model of development, and the fact that djb has better things to do/is no longer interested in developing them. If djb would have found an interested party to accept patches to the codebase, set it up on a code hosting site, then declared "this is the main repo for continuation of djbdns/qmail development", it would have gone a lot further than just "it's in the public domain" and no other guidance. This has lead to things like "dbndns", which are a good attempt, but definitely not a general, cross unix version solution: http://packages.qa.debian.org/d/djbdns.html http://packages.qa.debian.org/d/djbdns.html

JoshTriplett 12y ago

Replying to the article: > The first issue is that Linux has always been a commodity white box OS built from interchangeable parts available from multiple sources, just like the PC. Systemd goes out of its way to break that, and in doing so represents an enormous loss of flexibility. systemd goes out of its way to fix the massive integration failures we've had for decades (and seen as almost unfixable) because Linux is so focused on modularity to a fault. And because of systemd, we're finally starting to get a level of integration that previously only appeared in proprietary operating systems. http://islinuxaboutchoice.com/ http://islinuxaboutchoice.com/ Linux is good at evolutionary changes, but not nearly as good at escaping local maxima via large-scale cross-project changes. Not least of which because anyone attempting to make such changes has to be prepared for the anti-change "but the UNIX way!" flames. Every time I see someone railing about the UNIX way, I think of how people flame each other about / versus /usr, and how the original motivation for /usr was "we ran out of space on /, put some of the less critical stuff on the user disk". Appeal to tradition is not an argument unless you have a concrete reason why the tradition is better, and I rarely see such reasoning in arguments leveled against systemd. I've also found that well-articulated and well-founded arguments about problems in systemd don't tend to last long, because systemd will fix them. I'd encourage people who see a legitimate technical problem with systemd to go discuss it on the systemd mailing list; you might be surprised how quickly it gets fixed, if it has substance. > Linux systems are modular, with multiple implementations of anything important. Feel free to make something better than systemd, document it as extensively as systemd, spend years writing guides to its most compelling features that get people eager to switch, and do as much work as the systemd developers did to help the entire Linux ecosystem adopt it with shockingly few technical problems. There's nothing stopping you; you can even leverage the entire systemd codebase in the process. Fork it and change what you don't like, if you think you can keep up. Good luck; you'll need it. > But systemd isn't like that. It's a single all or nothing blob Refuted so many times that anyone still saying this is either intentionally misleading or utterly uninformed about what they're railing against. systemd runs incredibly little in PID 1; it has numerous separate single-purpose processes (typically named /usr/bin/systemd-foo or /lib/systemd/systemd-foo), as well as several libraries abstracting out key bits of common functionality for other code to use. > Ubuntu did upstart, but ubuntu also did unity, and mir, and pointed /bin/sh to dash, and their launchpad is based on the obsolete "bazaar" source control system... People not following Ubuntu's technical lead is pretty deeply justified at this point. Now this one is actually a very well-made point, and it's something few people have stated outright. There's a reason that few other distributions switched to upstart; while it adds a few key features over sysvinit (such as service supervision), it has some serious deficiencies as well. It's not at all clear that switching from sysvinit to upstart would have been an improvement. And the biggest key feature of upstart, service supervision, is actually something sysvinit already has but nobody uses: you can run a process directly from inittab, and sysvinit will restart it when it exits. But rather than using that, every Linux distribution just uses sysvinit to launch a shell script that launches a hundred other shell scripts. That said, I applaud Ubuntu for actually trying to make major changes to Linux. Unity isn't what everyone wants, but it's certainly an attempt at a non-incremental improvement over other desktop environments, and it has some nice properties. Similarly, Bazaar was an attempt to do better than CVS and SVN, and it's not wildly awful; it just lost to an even better system for a variety of reasons (http://www.stationary-traveller.eu/pages/bzr-a-retrospective.html http://www.stationary-traveller.eu/pages/bzr-a-retrospective...). /bin/sh -> dash is, while not necessarily inherently better, an attempt to enforce an absence of bashisms in #!/bin/sh scripts, and an attempt to improve the performance of such scripts; in that, it has worked reasonably well. There's no excuse for Mir, though. :) > Android also has a no GPL in userspace policy Not exactly, though Android certainly pushes back on GPLed code. They're willing to adopt it when there's no viable alternative. But systemd is LGPL these days, not GPL. And even if systemd were GPL, it would still be quite possible to use systemd as an init system to launch proprietary software. Regardless of Android's allergy to copyleft, permissive-versus-copyleft is an ancient holy war that long predates Android. The only reason the argument comes up so strongly in this case is that systemd is the right combination of rapidly developed and too useful to ignore to make it a serious threat to people who don't want to use it. If systemd were less useful, or otherwise easier to clone, its copyleft license would be less of a concern to the opponents of copyleft. That's a feature, and it's exactly the kind of thing the authors of the GPL and LGPL had in mind: the existence of high-quality software under copyleft licenses that make life difficult for the proprietary software world. Personally, I was rather disappointed when systemd switched to the LGPL; I would have rather seen it remain GPL. > Those of us waiting to see how it shakes out feel we're having systemd shoved down our throats by a development team actively threatened by the idea of people _not_ using their stuff. It couldn't possibly be that the software is sufficiently compelling that those without religious objections to it are switching to it to take advantage of its useful features. No, it must be a conspiracy. > But even if it wanted to, android can't easily clone systemd, becuase it's (intentionally) a moving target with no standard and no documentation. "no documentation" is insultingly misinformed; systemd is one of the best documented software products I've ever seen. And in any case, why should the systemd developers go out of their way to make life easier for people who don't want to use systemd, when they could instead spend their time making life better for people who want to use systemd? > We can't opt out and see how it goes, we must fight to stay where we are. Sure you can opt out: just sit there doing nothing, and the world will pass you by. Or you can participate, and do as much work as the systemd developers are doing, in favor of your preferred system. What you can't do is try to stop other people from doing work you don't like without putting at least as much work into a better alternative. Keep up or get out of the way, don't shout "wait up" or "no fair".

blux 12y ago

So, why not fork systemd and modularize it...?

jude- 12y ago
I think OpenBSD is working on that this summer. http://www.openbsdfoundation.org/gsoc2014.html#systemd http://www.openbsdfoundation.org/gsoc2014.html#systemd

Aloha 12y ago

I still sorta look at systemd as a solution looking for a problem. System V style init is just 'good enough' for most applications - and if there is anything I've found in my time, the only people more adverse to change then telecom folks are Unix system administrators.

Workaphobia 12y ago

There was a lot of repetition about X, Y, and Z being anathema to the systemd people. I would've appreciated some links backing up these claims of their hostility. I've heard so much against systemd, and so little that wasn't hearsay. (This is not a comment on the merits of the objections against systemd, just on the exposure to the arguments I've gotten from casually browsing hackernews.)

drdaeman 12y ago

> So the systemd developers are saying a billion android devices aren't interesting [...] Isn't being anti-GPL (and pro-vendor/anti-consumer) primarily Android's and not systemd's issue? Even considering that Android is a big thing, it's still possibly unwise to get rid of copyleft just to please Google and be accepted into phone vendors' proprietary blobs.

skylan_q 12y ago

The theme of Monolithic vs. Modular reminds me of Linux vs. Minix. The Tanenbaum–Torvalds debate was a debate between Andrew S. Tanenbaum and Linus Torvalds, regarding Linux and kernel architecture in general. Tanenbaum began the debate in 1992 on the Usenet discussion group comp.os.minix, arguing that microkernels are superior to monolithic kernels and therefore Linux was, even in 1992, obsolete. Other notable hackers such as David S. Miller and Theodore Ts'o joined the debate. http://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate http://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_deba... A link to the newsgroup discussion: https://groups.google.com/forum/#!topic/comp.os.minix/wlhw16QWltI[1-25-false] https://groups.google.com/forum/#!topic/comp.os.minix/wlhw16...

jude- 12y ago
More like a tightly-coupled (monolithic) vs loosely-coupled (non-monolithic) debate. Systemd is modular, but its components are tightly-coupled. The key difference between systemd vs the existing userspace, and Linux vs Minix, is that there's ~50 years precedent of loosely-coupled being the winning design paradigm in the long run. This is because a system made of loosely-coupled components allows the user to add, remove, and swap out parts independently of one another without having to drop the whole OS, thereby gaining the ability to adapt the OS to a changing set of requirements with minimal cost. Tightly-coupled systems do not have this advantage, and it makes them brittle in the face of change.

whoopdedo 12y ago

I've been a stick-in-the-mud about changing to systemd until I bumped into an ugly wart of sysvinit. While upgrading a service I moved the old daemon aside in case I wanted to downgrade again, then remembered that I hadn't killed it. So typed `/etc/init.d/myservice stop` and saw it did nothing. Huh? Oh, that's right. The simplistic script won't do anything if the daemon file doesn't exist. I had to manually kill the PID. So would I be correct in assuming that systemd would know the service names of all running daemons and be able to stop them without having to check to original file?

vezzy-fnord 12y ago
Well yes, systemd is far more sophisticated than sysvinit. No one here is advocating for sysvinit, as it does need a proper successor. "sysvinit or systemd" is a false dichotomy, however.

pjmlp 12y ago

Interesting how the evolution of GNU/Linux distributions and their interactions with other UNIX systems just look like the second coming of UNIX wars.