What's wrong with systemd(landley.net)
landley.net
What's wrong with systemd
http://www.landley.net/notes.html#23-04-2014
21 comments
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/
[1] - http://smarden.org/runit/
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".
- 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".
I agree with your points, though am disappointed by this reality. I've been aware of daemontools for some years, but only recently read over the design (which I find quite brilliant) and began using an implementation (s6 at the monent [1]).
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/
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/
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.
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
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
"runit/daemontools definitely do things their own way"
And systemd doesn't?
And systemd doesn't?
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.
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.
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.
launchd makes heavy use of Mach IPC ( 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 and more recently https://github.com/rtyler/openlaunchd/blob/master/README.md .
systemd is essentially a reimplementation of launchd for Linux. The systemd devs explicitly acknowledge this inspiration.
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.
systemd took heavy inspiration from launchd and other sources, but provides extensive functionality that launchd does not.
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.
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/
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 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".
> 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.
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 :)
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 :)
> 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.
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.
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 think you are confusing 'a desktop environment' with Linux. He was talking about Gnome.
> And yet nothing integrated all those features well enough to get people to widely adopt them.
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.
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.
> 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.
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).
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).
So, GNOME made two mistakes. First, they moved to logind as a hard dependency with no deprecation plan for users who must continue to rely on ConsoleKit in the near-term (basically a "fuck you" to !systemd users). Second, they added a hard dependency on a non-portable, backwards-incompatible service management framework (basically a "fuck you" to !Linux users).
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 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.
> 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.
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
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
This is the longest HN comment I have read that includes exactly zero important things. The ultimate problem is the lack of a standard in the init family of software. If I have to write eight initialisation scripts to support eight different Unices, then the major problem is this, not the features, or the philosophy.
I was responding to the article, not writing a standalone article about systemd. Regarding standardization, I agree completely, and that's one of the problems systemd is trying to solve: rather than writing eight init scripts, you can write one systemd service file. That's partly due to systemd standardizing various features that distros previously had to reinvent, and partly due to a general philosophy that treats gratuitous differences between distributions as a bug to be fixed rather than a feature to be reveled in. When writing a systemd service, if you encountered an issue that would require you to have a distribution-specific service file, you could very reasonably report it as a bug and get it fixed.
What is systemd doing in terms of inter-Unix portability? Unix is not only Linux. Also; standardisation means not to be used all over. It means to be bound from below and above so that there is an interface that can be trusted to exist in all the adherents of that standard. For example, Linux may have send_sher_shcön(7) exposed exclusively, but we can be sure that there is send(2), for portability concerns.
edit: man numbers.
edit: man numbers.
Systemd detractors seem to view the pre-systemd landscape through rose-tinted glasses or at least completely ignore what has been going on with the desktop. I hardly think ConsoleKit embodied the UNIX philosophy, and if the various desktop environments end up replacing their own subtly different session managers with systemd user session management that seems like a step forwards to me, both for the Linux developer community and for the end user.
I can't speak for any other 'systemd detractor', but I can definitely confess that I've completely ignored what's going on on the desktop. Because it's been utter crap for the last 20 years and is clearly getting no better.
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.
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.
Agreed. In particular, systemd detractors rarely have answers for questions like "so how would you solve that problem?".
> http://islinuxaboutchoice.com/
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.)
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.)
Also, I'm not sure what you mean by "massive integration issues." Can you identify a "massive" (i.e. show-stopping) problem in Linux-based operating systems that (1) is due to software A not correctly interacting with software B, (2) that systemd solves, (3) that existing tools cannot solve, even with proper configuration, necessitating systemd?
I'm having a hard time thinking of any, but I'd love to know of some.
I'm having a hard time thinking of any, but I'd love to know of some.
A few examples, off the top of my head:
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.
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.
"booting faster" is a desktop concern from 1990. Are there really a bunch of linux users turning on and off their computers constantly and using linux on the desktop? Is this really an actual thing? Because I'd like to introduce these people to (a) real desktop environments maintained by smart people and (b) at the very least, suspend mode.
In practice, I see people boot Linux desktops under three conditions:
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.
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.
not a huge fan of systemd either, but I'm sure that if computers were able to boot in milliseconds then some of those practices would change.
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).
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).
Given that Unix has been booting successfully, safely, and rapidly for several decades, I would venture to agree that 'the same goals could be achieved with a more modular approach.'
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.
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.
None of the things you mentioned meet criterion (3) in my original question. Therefore, you have not convinced me that there is a need for systemd.
> 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...
> 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...
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
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.
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.
> So, basically you're advocating for a walled garden approach
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.)
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.)
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.
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.
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.
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?
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.
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_deba...
A link to the newsgroup discussion: https://groups.google.com/forum/#!topic/comp.os.minix/wlhw16...
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...
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.
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.)
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.
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.
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.
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...
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.
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.
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.
I've had great success with OpenRC.
Interesting how the evolution of GNU/Linux distributions and their interactions with other UNIX systems just look like the second coming of UNIX wars.
So, why not fork systemd and modularize it...?
I think OpenBSD is working on that this summer.
http://www.openbsdfoundation.org/gsoc2014.html#systemd
http://www.openbsdfoundation.org/gsoc2014.html#systemd
> 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.
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.
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.
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.
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.
This has more to do with the tint of your lenses (and those of the article's author) than the layout of the software.
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.
Not entirely irrelevant. Sociopath risk is real.
Not sure I understand. Are you implying that we should resist systemd because Poettering is a sociopath?
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.
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.
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.
> 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/InterfacePo...
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...
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
This time we have the right design! It will never need replacing, honest.
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.
As I commented elsewhere, I'm running systemd with syslog-ng, netctl, and cronie. It plays just fine with them. Do you have examples of pieces I'd want to swap in but can't?
How about swapping it the other way around; what about using journald or logind without the rest of systemd, in the future?
His argument would not apply to an actual standardization effort without the negative attributes explicitly called out in the article. (Non-standard, undocumented moving target, and a community of developers who go out of their way to antagonize competing projects.)
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.
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.
> 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
[2]: http://www.redhat.com/archives/fedora-devel-list/2008-Januar...
[3]: http://utcc.utoronto.ca/~cks/space/blog/linux/SystemdWhyItWo...
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...
> 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/
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."
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."
> People who favour systemd generally use it to get shit done [1], not write blog posts about 'freedom of choice' [2].
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.
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.
"someone gripes that systemd has dared to take over the functionality of invoking fsck on disks at boot time before mounting them"
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:
[1] - https://en.wikipedia.org/wiki/Unix_philosophy
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]
[1] - https://en.wikipedia.org/wiki/Unix_philosophy
This is a good example of a standard argument against systemd: a vague complaint about "monolithic" versus "the UNIX philosophy", with no response to the actual issue, and in particular nothing that could be put in a bug report. What's actually broken here? What doesn't work, or what feature or behavior is missing? What would the bug report subject be, "is systemd"?
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 [email protected]. 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.
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 [email protected]. 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.
The bug report would be along the lines of poor documentation, poor integration, poor testing, etc. Let's look at the man page for [email protected] for a moment http://www.freedesktop.org/software/systemd/man/systemd-fsck... . So, what files does it look for in checking filesystems for checking. What values does it return? How can I change its behavior not to drop to emergency.target if certain filesystems don't fsck properly? The complaints of systemd being monolithic come from its utter lack of user serviceable parts; it's of little consolation that it's several dozen poorly documented black boxes that don't work in isolation instead of a single binary.
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.
You know what your average user wants? A faster booting system. In most cases that will be systemd.
You couldn't be any more wrong. The average user has no idea that she is using Linux. The number of people using a Linux system that reboots frequently enough to be noticed is zero.
Are you talking about servers? Because it's not 2000 anymore; the idea of servers running single instances of Linux for months or years at a time and rebooting is so infrequent that an extra second or two is no big deal, is obsolete. The cloud is king, and in the cloud you want to have instances which can be started up and shut down quickly and safely. That means that systemd makes just as much sense on servers as it does on desktop and mobile systems, if not more.
My cloud instances already boot up quickly and safely, thank you. I don't need a mountain of technical debt and poorly designed architecture in order to increase the speed by two seconds.
I'm interested in seeing where those stats came from. Care to share?
do you disagree? Because essentially every phone, television, car, printer, appliance, sign, smart watch, web server, router, and modem uses Linux.
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.
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.
Counting embedded devices in this discussion as part of the Linux population is questionable at best. There isn't an init system debate for embedded devices. I've not seen any indication that Samsung will be changing the infra based on the init system war, any more than GE is going to change my microwave.
All of those devices are linux, and all have init systems. Currently, there are two core systems they use: bsd-like init.rc systems (and busybox variants), and sysv.
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.
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.
God save us from software that bends over backwards to help average users. The only thing worth doing with software is pushing it forward.
Actually, one of the goals of systemd is to standardize all Linux distros on a single set of tools. Which means that, yes, alternatives will go insupported. But in order for Linux to transition from just a kernel to a platform, you must have ONE userland stack and ONE set of APIs to cide to... for everything from system calls to UI layers and system management. This is an advantage that Windows had, and systemd finally brings it to Linux
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.
I'm pretty sure this change was initiated by Debian. I recall it was already the case on Debian stable circa 2008.
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
[1] https://wiki.ubuntu.com/DashAsBinSh
[0] https://wiki.debian.org/Shell
[1] https://wiki.ubuntu.com/DashAsBinSh
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.
> 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/
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/
I stand corrected. I did try to do some research, and what little I could find seemed to support my recollection, but apparently I was confused and failed in my research.
I concede the point.
I concede the point.
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-logind...
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...
It consists of multiple daemons which are relied on by userland applications, are so strongly interdependent that the systemd developers don't support running them independently, and which have no stable or documented APIs between the different components. Oh, and many of them are infeasable to re-implement according to said developers.
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.
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.
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-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.
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.
> 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/."
Quoting the page you linked to: "On disk, the backlight brightness is stored in /var/lib/systemd/backlight/."
I missed it. I guess I've gotten spoiled by BSD manual pages that have file locations in a subsection labelled Files instead of stuck in the description. At the same time, it gives a directory location, instead of an actual filename, which lends one to believe that the actual name and location will be subject to change without notice, as well as the contents of the file, format, etc.
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.
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.
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.
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
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.