> 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.
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.