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