> 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. 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
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.
> 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?
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.
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.
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.
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.
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).
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.
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.
> 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.
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.
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).
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.
> 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".