What's wrong with systemd
landley.net
landley.net
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
[2]: http://www.redhat.com/archives/fedora-devel-list/2008-Januar...
[3]: http://utcc.utoronto.ca/~cks/space/blog/linux/SystemdWhyItWo...
I appreciate most of your post, but this line really bugs me because I hear it so often.
Relevant xkcd: 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."
You know what your average user wants? A faster booting system. In most cases that will be systemd.
If, charitably, you give 2% market share to desktop linux, and then multiply that by worldwide PC shipments (~80mm last quarter, so assuming ~320mm annualized), you end up with 6.4 million. Not bad. But there were 918mm smartphone shipments in 2013, of which android was around 75%-80% market share, so 688 million or so. That's over a hundred times as many users just in phones alone.
Similarly with servers: essentially all the web servers and application servers in the world are linux, and they also don't need the sort of windows-style 'architecture' that systemd brings.
In fact, I would venture to say that boot speed isn't even in the top 50 concerns of a desktop linux user.
So it's not just the tail wagging the dog; it's a nonexistent, badly drawn picture of a tail wagging several billion dogs.
Exactly. Half of the complaints I see about systemd don't even bother to make any arguments against it other than wanting to move away from it. For instance, see the most recent round of discussion on debian-devel, in which someone gripes that systemd has dared to take over the functionality of invoking fsck on disks at boot time before mounting them. The horror of this scenario clearly cannot be adequately conveyed in an email, or at least nobody in the discussion attempted to convey it.
This is a good example of what the original article complained about: systemd is a step towards monolithic systems and a step away from the unix philosophy:
"The Unix philosophy emphasizes building short, simple,
clear, modular, and extendable code that can be easily
maintained and repurposed by developers other than its
creators..."[1]
Something needs to invoke fsck on disks at boot time before mounting them. With sysvinit, that was handled by init scripts. With systemd, that's handled by systemd units like systemd-fsck-root.service and systemd-fsck@.service. As far as I can tell, the complaint in this response is that systemd isn't sysvinit and doesn't use sysvinit's init scripts.
Note that systemd could be configured to invoke sysvinit's init scripts, and that would work exactly as well (or as badly) as it did with sysvinit.
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.
I concede the point.
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.
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):
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/
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...
However, it's probably a bit late by now, since systemd's place has been set in stone, for better or for worse.
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.
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.
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.
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.
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/InterfacePo...
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.
- 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".
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
I know you weren't arguing against daemontools, but just wanted to share some thoughts:
> Service directories make sense, but they tend to be shell scripts all the way down
This is true, but what are you doing in your "run" script that is so complex? Also, any executable will suffice. s6 provides 'execline' [2] which simplifies some use cases (and complicates others...)
> Logging is quite different and non-centralized
Arguably a feature. I'm quite enjoying the "logging chain" where every service logs to stderr which either goes to its specific logger process or bubbles up to that of the parent process.
The typical usage of syslog is to collect all log messages in a centralized inbox and then (by some pattern matching; log messages must contain enough to be categorized) split them up again and write them to separate files. Skip all that with logger-per-service.
> Services need to be set not to fork and do their own daemon management.
Clearly a feature. There is no need for the redundancy of multiple, error-prone implementations of daemonization routines in every service. Also, language nitpick, it's not that a service can't fork. For example, daemontools can happily supervise a Unicorn master process that will fork off its own workers. The service must not background itself by severing ties with its parent (which involves forking of course).
But there are downsides and quirks as you say. Two examples:
If you really want something like Nginx or Unicorn to be able to restart without dropping http connections (e.g. fork+exec new master process, gracefully shutdown and kill old master process), then you will run into issues. It's possible to hackishly wrap this in a helper script. Daemontools would supervise the helper, which would in turn manage nginx via plain old racy PID files, just like init.d scripts.
I'm only familiar with daemontools and s6, but they assume TERM is the signal to use to stop a service, and don't provide configuration to send, say, QUIT which Unicorn interprets as "graceful shutdown". (Upstart also did not allow this until fairly recent versions.) It's one thing to get a service to not daemonize itself. It's another thing to expect upstream to modify its signal handling.
[1] http://skarnet.org/software/s6/ [2] http://skarnet.org/software/execline/
And systemd doesn't?
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-logind...
Now, the Gnome developers may argue that technically Gnome doesn't require logind, and technically they're right. You lose the ability to shutdown, restart, sleep or hibernate your PC from the Gnome user interface - all things that worked before and that normal users expect to be able to do - but you can technically run without it. The API for those things isn't itself terribly complicated, but because the systemd and Gnome developers don't give a fuck about anything other than systemd they've bundled it together with a whole bunch of complicated, poorly-documented multiseat stuff that can only be implemented as one single, monolithic all-or-nothing API.
Which is, I think, part of the reason why Ubuntu gave up and is switching to systemd; they can hardly ship something that requires users to use the command line to shutdown or suspend their PC.
Edit: Also, the bit about how "we specifically approved some patches to allow Canonical to run logind without systemd" is... well, outdated is probably the politest way to put it. Since then the systemd developers have announced that they're breaking the ability to run logind seperately in future, they never supported it in the first place, and Ubuntu should never have done it.
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-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.
Quoting the page you linked to: "On disk, the backlight brightness is stored in /var/lib/systemd/backlight/."
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.
systemd took heavy inspiration from launchd and other sources, but provides extensive functionality that launchd does not.
> 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/
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...). /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".
The fact that the desktop is now spawning lovecraftian horrors from the deep in the service of 'booting to the desktop faster' and 'supporting hot-plug devices better' and that those awkward, stupid requirements now threaten to invade the standard installation on my servers, that definitely has my attention now, though.
So, basically you're advocating for a walled garden approach, then you link to a novelty domain that points to a Red Hat mailing list discussion where some person rants like a demagogue in a disjointed fashion that doesn't prove jack shit.
Quite impressive.
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.
Or because Linux userland developers have historically been bad at cathedrals? The bazaar has always been more suited to the Linux community, and makes Linux distinct and refreshing compared to BSDs (which are an example of cathedral done right, by the way).
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.
If the systemd team's insistence on not taking patches for alternative libcs, Lennart's circular argument on why you should adopt systemd because of systemd-logind being tightly coupled and hard to reimplement (https://plus.google.com/+LennartPoetteringTheOneAndOnly/post...), the recent Kay Sievers controversy and other issues are anything to show, it is that the systemd team very much have their own convictions that are at odds with anyone else.
You can get integration without a walled garden. There are no walls on the systemd garden; there's just a well-maintained garden that attracts an increasing number of people. You don't need walls to keep people in when you have sufficiently compelling technology that they want to stay.
And you didn't actually respond to anything in the mailing list post about "choice", other than its tone. There's a key point to be learned from that post: just because a alternatives exist doesn't mean they all have to be equally well supported by every Linux distribution. Linux distributions, as one of their primary functions, make choices for the user: they select a set of components and make those components work well together. systemd helps there, by providing a set of components that integrate quite well, and by getting rid of some of the zero-value differences between distributions (/etc/hostname versus /etc/HOSTNAME versus /etc/sysconfig/..., for instance).
> Or because Linux userland developers have historically been bad at cathedrals? The bazaar has always been more suited to the Linux community, and makes Linux distinct and refreshing compared to BSDs (which are an example of cathedral done right, by the way).
I actually agree with this, but I don't see how it's a response to what I said. Linux, in not using the cathedral method, has a hard time making major changes to escape local maxima, and when such changes do happen it's typically through the focused efforts of a small group dedicated to fixing a particular class of issues. For instance, the Linux kernel is a bazaar, but major new subsystems are not typically developed collaboratively from scratch, they're provided in a functional initial form and then evolved from there. And when it finally comes time to replace them, they're typically replaced as a unit rather than incrementally evolved.
And personally, I wouldn't mind seeing Linux distributions learn something about organization from the BSDs, not least of which by requiring that all packages appear in the same version control system side-by-side on the same server.
> If the systemd team's insistence on not taking patches for alternative libcs
systemd refuses to work around bugs in other software unless absolutely necessary; when that software is FOSS, it can be fixed rather than worked around. And systemd does have some patches to handle less capable libc implementations, such as definitions of system calls that libc implementations might not have. On the other hand, it seems quite reasonable to require functions like asprintf rather than reimplementing them, especially for an init system specifically designed for Linux.
> Lennart's circular argument on why you should adopt systemd because of systemd-logind being tightly coupled and hard to reimplement
logind needs cgroups. PID 1 needs to manage cgroups. There's a solution that works today, providing features that desktop environments need, for which alternatives do not yet exist. And if you're not a fan of that solution, there are people working right now to create an alternative solution using cgmanager.
> the recent Kay Sievers controversy
In which kernel developers ranted about a bug in systemd that had already been fixed before the discussion ever started, and proposed childish kernel patches like "if PID 1 is named systemd, panic()"...
> the systemd team very much have their own convictions that are at odds with anyone else
Per my previous comment: 'Not least of which because anyone attempting to make such changes has to be prepared for the anti-change "but the UNIX way!" flames.'
Yes, the systemd team is trying to make large-scale changes to the way Linux works. That necessarily puts them at odds with the way Linux currently works. That doesn't make them wrong: Linux is not yet perfect and could use further improvement. (It doesn't make them inherently right, either.)
The rationale for adopting systemd, is, I'm afraid more complex than simply "sufficiently compelling technology". It is the result of a variety of factors.
Just because a alternatives exist doesn't mean they all have to be equally well supported by every Linux distribution.
No one is saying that.
systemd helps there, by providing a set of components that integrate quite well, and by getting rid of some of the zero-value differences between distributions (/etc/hostname versus /etc/HOSTNAME versus /etc/sysconfig/..., for instance).
I have nothing against systemd's imposed standard configuration files, although ultimately they're not particularly meaningful (and thank heavens for that, I'm hoping it'll last...). /etc/hostname has been a Debian standard for years now that most other distros went to, even before systemd.
Linux, in not using the cathedral method, has a hard time making major changes to escape local maxima, and when such changes do happen it's typically through the focused efforts of a small group dedicated to fixing a particular class of issues.
The use of a bazaar is a good thing. It creates a decentralized system of autonomous channels. A community of thriving subcommunities, a marketplace of ideas where distribution maintainers are free to pick from a variety of flavors for their distros.
And personally, I wouldn't mind seeing Linux distributions learn something about organization from the BSDs, not least of which by requiring that all packages appear in the same version control system side-by-side on the same server.
So essentially you want a ports system? I have nothing against ports collections, but packaging models that involve strict separation of duties are not bad, either.
systemd refuses to work around bugs in other software unless absolutely necessary; when that software is FOSS, it can be fixed rather than worked around.
Yet evidently systemd cannot apply these same principles to itself.
logind needs cgroups. PID 1 needs to manage cgroups. There's a solution that works today, providing features that desktop environments need, for which alternatives do not yet exist. And if you're not a fan of that solution, there are people working right now to create an alternative solution using cgmanager.
It's good that alternative solutions are being made, but once again it's circular reasoning. You're using the premise to justify itself.
Yes, the systemd team is trying to make large-scale changes to the way Linux works. That necessarily puts them at odds with the way Linux currently works. That doesn't make them wrong: Linux is not yet perfect and could use further improvement. (It doesn't make them inherently right, either.)
And when you have such a huge undertaking in place, you don't just tell other people to "sit down and shut the fuck up". Finally, striving for perfection is a vapid sentiment. If this is what is considered "further improvement", then perhaps we need to rethink our needs entirely.
Windows goes out of the 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 yet, Linux users don't clamor for Windows because of this.
> http://islinuxaboutchoice.com/
This is exactly the attitude the author is arguing against. Reaffirming this without justification doesn't make you right. Again, Windows is the operating system for people who don't want choice.
> 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.
Honestly, sysvinit and the existing userspace does all I need it to do. The extra benefits systemd offers I can do using existing tools. Need to reliably kill a service? Use the cgroups tools and put the service into its own cgroup, and then kill all processes in the cgroup later. Need tamper-evident logging? Use the rsyslog tools. Need dependency-based boot? insserv has got you covered. Need automatic device-node creation, and the ability to run programs based on device events? udev did this just fine before systemd.
> Refuted so many times that anyone still saying this is either intentionally misleading or utterly uninformed about what they're railing against.
Systemd's components are tightly-coupled. How, pray tell, do I run logind without systemd as PID 1? How, pray tell, do I remove journald? Oh, that's right. I can't. By design. That makes it monolithic.
> 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.
Or, it could be that people now have to choose between having a desktop environment and NOT having systemd. The tight coupling of systemd to layers above it compels its adoption, arguably more so than its merits.
By contrast, X.org and Xfree86 (an example from the article) were largely interchangeable.
> Keep up or get out of the way, don't shout "wait up" or "no fair".
Have fun running over the cliff to your new Windows-ix :)
And yet nothing integrated all those features well enough to get people to widely adopt them. systemd services make it trivial to run a process in its own cgroup, isolate it, log everything about it, activate services as needed, and manage and track services launched in response to devices. There's nothing stopping you from building your own Linux distribution that integrates all of those tools, and there are certainly enough systemd opponents to try. If they build something compelling, people might use it.
(Also, insserv doesn't come close to the parallel boot that systemd enables, via socket activation, bus activation, and similar. If B and C depend on A, insserv lets you start B and C in parallel, but systemd lets you start A, B, and C in parallel.)
> Systemd's components are tightly-coupled. How, pray tell, do I run logind without systemd as PID 1? How, pray tell, do I remove journald? Oh, that's right. I can't. By design. That makes it monolithic.
To run logind without systemd, you can wait for the cgmanager folks to provide an implementation of equivalent cgroup management functionality for logind to use. Until then, your complaint is much like the complaints about systemd not running on Linux: Linux has features other OSes don't, and systemd intentionally takes advantage of them, "by design". Does that make the combination of systemd and the Linux kernel "monolithic"?
This is "by design" in much the same way that a program using features from Python 2.7 that don't work in Python 2.6 does so "by design". And it's perfectly reasonable for a project to refuse patches for compatibility with Python 2.6 and say "upgrade to 2.7". Just like it's perfectly reasonable for some projects to say "run Linux" or "run systemd", because it has features that nothing else does.
> By contrast, X.org and Xfree86 (an example from the article) were largely interchangeable.
They were in the start, when X.org initially forked from the XFree86 codebase. But today, you cannot drop XFree86 underneath a modern desktop environment and expect it to work; it'll complain about the myriad X extensions introduced in X.org to make those desktop environments possible. And yet, nobody noticed, because nobody cares about XFree86 anymore.
I guess I'm an outlier these days in that I learned how to do all these things before systemd existed (and don't need any further integration than a shell), but I take your point on making it easier for less experienced people to do them. Everyone has their own desired level of integration.
However, systemd is arguably the wrong way to do this--it's too low in the stack to have the best impact. Cross-component and cross-system integration should happen in as high a layer as possible--systems in higher layers have more knowledge about the global state of the system, and thus are in a better position to know how to orchestrate them (i.e. the end-to-end argument).
A better strategy to control daemons in response to user, daemon, and system events would be to implement a session daemon that listens for these events, matches them against user-supplied rules/callbacks, and then dispatches the apporpriate commands to the other daemons and the system. Desktop environments prior to systemd largely did this, albeit in an ad-hoc desktop-specific fashion. However, we can achieve the same end in a standard way without replacing the plumbing layer or the init system by suppling a suite of adapters with the session daemon that allows it to talk them. This would allow us to develop the session daemon in a piecemeal manner (i.e. gradually add support for more daemons), a modular manner (i.e. you don't have to replace existing daemons), a portable manner (i.e. separate the rules and dispatching logic from the daemon/system adapters), and a loosely-coupled manner (i.e. it's designed to interoperate from the get-go). A desktop environment could depend on this session daemon, but the session daemon does not have to depend on an init system, or a kernel, or an IPC mechanism (like DBus).
> Also, insserv doesn't come close to the parallel boot that systemd enables, via socket activation, bus activation, and similar.
Of course not :) It's inetd/xinetd's job to do socket-based activation, not insserv's. I'm not sure why I need systemd to do bus-activation; if I needed bus-activation (and I don't, but could in the future), I would just modify inetd/xinetd to listen on a well-known DBus address instead of (or in addition to) a well-known port.
> To run logind without systemd, you can wait for the cgmanager folks to provide an implementation of equivalent cgroup management functionality for logind to use.
To run e.g. a GNOME session, I need logind. To run logind, I need systemd. It doesn't need to be this way. This cross-layer coupling is a step backwards from a usability standpoint--users that do not or (in my case) cannot run systemd are now locked out of using GNOME. As mentioned below, this is the equivalent of having a widely-used web page go from running in any web browser to running in only Internet Explorer. Sure, it's the web developer's choice to do so, but it's not something you'd be happy about if you don't use Internet Explorer.
> Does that make the combination of systemd and the Linux kernel "monolithic"?
I think you're confusing "non-portable" with "monolithic." A system is monolithic if its internal parts are tightly-coupled--I can't use part A without also using part B (i.e. logind with systemd-PID-1). Note that a monolithic system can also be modular; the Linux kernel being an illustrative example. Similarly, software can be loosely-coupled (non-monolithic) but non-portable as well: I can't run GNU coreutils on Palm OS, for example.
I do not expect systemd (or any service management system) to be portable. However, I do expect its components to be as loosely-coupled as possible (and prior to systemd, this was the case), and I do expect that other systems that address orthogonal concerns not be coupled to it. Loose coupling between components that address orthogonal concerns is simply good design--you don't replace your steering wheel in your car when you replace your tires, for example.
They are locked out of gnome until the cgmanager develops into usable software. They are currently locked out not because of "too tight integration", but because logind, through the use of systemd, through the use of cgroups provided a feature that was worth losing the compatibility to older systems. Specifically, session management that actually doesn't leak processes, unlike literally everything else ever shipped on Linux. People unwilling to use systemd can wait until a competing implementation is written (and which is currently unwritten not because of overly tight systemd integration, but because the no-one bothered to actually do the work to provide the functionality before the systemd team stepped up).
I know "move fast and break things" is a popular maxim these days (particularly in web development), but it's also a great way of pissing off your users and making sure that none of them ever make the mistake of depending on you or trusting your software ever again.
There's a reason Linus enforces his "don't break userspace" policy--he understands perfectly well that if he breaks layers above him frequently, he'll find himself without a userbase, since the developers who build on top of Linux will jump ship. Even when he has to break userspace (such as with X mode-setting), he and the relevant parties coordinate a flag day to make the transition as painless as possible. That's the level of responsibility and maturity I expect from people who maintain the lower layers of the software I run.
Far be it from me to tell the GNOME and systemd developers how to manage their projects, but by the same token they should not expect me (or people like me) to take them seriously if they're not going to be responsible with the power they presume to wield over the ecosystem.
I'm having a hard time thinking of any, but I'd love to know of some.
Socket activation (and related features like bus activation) are one of systemd's key improvements to the boot process. Activation avoids the need for explicit dependencies, because you don't need to depend on avahi to start using the avahi socket. And because of that, systemd can launch avahi and services using avahi in parallel, by opening the socket for avahi, and letting other services write to that socket before avahi fully starts, only blocking when they go to read from it.
You could do that with inetd or similar, but inetd doesn't integrate with the init system, so an inetd service can't declare any dependencies on other services, and won't get tracked alongside other services (e.g. with systemctl status). So in practice, very few distributions actually launched services from inetd in practice (notable exception: CUPS), while many distributions use systemd's socket activation.
People care about booting quickly. While mechanisms like bootchart existed before systemd, you had to explicitly boot with them to collect results for analysis, and they'd slow down the boot process. With systemd, you can run "systemd-analyze blame" or "systemd-analyze critical-chain" on a production system and see exactly what you need to work on to make the system boot faster. (That was one of the widely lauded features of DTrace: you could safely use it to diagnose production systems.)
Then there's journald's original reason for existence: "how can we make 'systemctl status' show the last few lines of log output from a service?". How would you do that on an arbitrary system running an arbitrary syslog implementation? (For extra bonus difficulty, do so while attempting to track the syslog implementation as a service itself, and avoid deadlocks.) Sure, you could recreate that functionality on a particular system with a particular logging configuration, and there are dozens of systems doing so, not counting the myriad production systems deployed with bespoke solutions for log monitoring. (Even then, most of those systems don't correlate a service's log output with that service.) But systemd makes it easy and universal.
And that integration extends beyond systemd as well. For instance, if fixing a problem requires adding a new kernel interface, they'll submit a kernel patch, and then have systemd use that new kernel interface, rather than hacking around the problem in systemd and producing a suboptimal solution.
1. Once in a great long while, perhaps when there was a power outage or a critical system update.
2. Daily, for a few people who shut down their computers when they finish work for the day and boot them in the morning. (I never understood this.)
3. When something has gone quite badly wrong.
Outside of that, there are desktops which hibernate, laptops which hibernate, and phones which are running Firefox OS or Android and boot about once a week.
If you have a journaling filesystem and no weird hardware, desktop boot times are not a problem.
Also, it's not only about desktop. Autoscaling of virtual on demand servers can greatly benefit of extremely short boot times. Surely you could use a simple and highly optimized boot system in such cases, but why not use the same if it works well.
It seems to me that it's more about systemd developers' attitude than with the actual goals. Perhaps the same goals could be achieved with a more modular approach.
The important thing is that distributions (or components that manage the deployment of services, e.g. package managers or custom service management solutions) need a simple yet powerful way to express their requirements. Not sure this requires this level of integration which appears more like a way to force people to use it (or simply because it's simpler to approach this problem by throwing away the complex legacy).
Which raises the question: why systemd? And the answer: desktop linux people, who are already mired in a world of overcomplicated and incomprehensible quarter-engineered freshman-level bullshit like gnome and dbus and pulseaudio and on and on, are sure that their problems are everyone's problems. In some cases it's because they don't know any better, I'm sure. But nevertheless, infecting the rest of Linux with the desktop philosophy is an extinction-class mistake.
> Socket activation (and related features like bus activation) are one of systemd's key improvements to the boot process...etc...You could do that with inetd or similar, but inetd doesn't integrate with the init system, so an inetd service can't declare any dependencies on other services, and won't get tracked alongside other services (e.g. with systemctl status).
This problem can be avoided entirely if you start avahi early and immediately swap it to disk. Then, it's not taking up resources when it's doing nothing, and the OS swaps it back into RAM automatically when it gets a connection. No need for systemd, or inetd even.
The only thing inetd needs to function are (1) networking, and (2) locally-mounted disks (i.e. for reading its config and loading server binaries), so the solution is to start inetd once networking and disks are up (that applies to pretty much any non-trivial service, btw). You shouldn't have to tightly-couple inetd to the init system anyway--simply have the program inetd starts be a script that first checks with the init system (which may or may not be systemd) to see if the service can be started, and block (or time out) until the service is ready for inetd to hand off the connection. Again, no explicit need for systemd.
> People care about booting quickly.
Get an SSD :) ducks In all seriousness, this doesn't qualify as a show-stopping problem on the desktop, since you're not rebooting that often anyway (I regularly go ~3 months between reboots on my laptop). Moreover, you don't need systemd to get fast boot times--it's also possible to compile your boot process to minimize I/O (which is the limiting factor of boot speeds). It's not that far-fetched of an idea--Pardus Linux uses (byte-compiled) Python scripts to boot the system, for example, and it gets excellent speed-up [1] (in the benchmark: 15s to get to KDM login on a P4 with a 5400 RPM IDE disk).
I can see boot times being a problem in mobile space, but you don't need systemd to get fast boots either. Just load up the GUI and log-in prompt once the rootfs is mounted, and then asynchronously start up the rest of the phone's internal services once the user has logged in (i.e. and unlocked the SIM card). Chances are, the user is only concerned about boot-time when they're in a hurry, and I'm going to take an educated guess that the hurry is caused by the pressing need to dial a number, get/send a text, or load a map (probably in that order). So, asynchronously start the telephony stack, the SMS daemon, and the location service (in that order) once the user logs in.
The telephony stack takes a while to initialize anyway (i.e. to register with the service), so there's space to use that time for starting non-essential services asynchronously after log-in.
> Then there's journald's original reason for existence: "how can we make 'systemctl status' show the last few lines of log output from a service?"
See my earlier comment of why integration of orthogonal concerns belongs in a higher layer than systemd. I would (1) set up the daemon to log to its own well-known place, and (2) run "cat $LOG | tail". I could even store a repository of service configuration /etc/conf.d, where each service has its own file that describes a few common environment variables, like where it logs to. Again, no need for systemd.
> But systemd makes it easy and universal.
Easy? yes. Universal? No. https://xkcd.com/927/ ;)
EDIT: wording
[1] https://web.archive.org/web/20090505144440/http://www.pardus...
edit: man numbers.
Hands down, this is the one of the most retard "arguments" in the whole debate.
>"ship everything and let the user chose how they want their sound to not work" starts with fallacy and ends with disaster.
Ok, if you think so use OS X, but stop braking linux, please. (By the way, it's 2014 and my network-manager does not work, it randomly crashes and needs to be restarted. Thanks god there is wird and linux is actually about choice.)
Come come, no need to pretend to be dense on this topic. Address the argument, rather than engage in rhetorical bluster.
You know, and I know, and everyone knows because it's public knowledge, that systemd is an incredibly tightly bound bundle of highly opinionated tooling, regardless of how many process IDs it uses. You know, and I know, and everyone knows because the maintainers say so[1], that no piece of systemd can be replaced, and indeed they further astonishingly assert that certain bits of systemd logic literally cannot be reimplemented by anyone else or removed.[1]
You know, and I know, that systemd is attempting to gain creeping control over an ever-growing pool of functionality normally handled by logically separated tools, frequently without regard to merit (e.g., stashing core dumps in a binary log; the 'debug flag' debacle[2]).
So if we know all of these things, then why do you pretend otherwise, and unleash vitriolic insults against people based on your straw-man specious reasoning? And if you can answer that, can you then tell me, why is this not just standard practice amongst the systemd advocates, but rhetorically uniform therein?
[1] https://plus.google.com/+LennartPoetteringTheOneAndOnly/post... [2] https://lkml.org/lkml/2014/4/2/420
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_deba...
A link to the newsgroup discussion: https://groups.google.com/forum/#!topic/comp.os.minix/wlhw16...
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.
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.
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.
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.