OT: It's a bike shed

It depends on how you define an "init system". To those of us who are familiar with SysV, an init system is something that starts and stops processes. This mostly happens during booting and software upgrades, and for all the criticism of SysV it does a serviceable job of it. That's hardly surprising, as it isn't a very big or complex job.

Systemd goes well beyond that definition. Yes, the starting point was an init system. But then they decided the init system provide containers for the sub-systems it's starting and stopping. This has multiple benefits. Security wise it isolates the subsystems, and this isolation makes dependencies between them explicit, which hopefully simplifying things and making them more reliable. I think it moved from there to "oh, lets put the users in their own containers too", for the same reasons.

But just putting everything inside turned out to be both fragile and complex, I think mainly because the existing utilities like pid 1(!), cron, network configuration (plus DHCP, DNS, nssswitch) and were designed for managing an entire LAN, not a set of containers. Done properly these would be split into client and server side, with the server realising it was managing a host and the client tailored to running in a container on that host. The solution was to write their own replacements for all these, which they have done. As part of that taking over udev was necessary because that is what makes resources (like tty's and networks) available to containers. They also need a way to communicate between all those containers securely. (It's a big issue, because whatever mechanism is chosen is also the first mechanism an attacker will look at for escaping the container.) DBus is apparently the chosen way. KDBus makes it more suitable for this task - in particular it brings security enhancements only the kernel can provide.

In short, they are trying to move from a world where we run a whole pile of services on one system which necessarily means everything is visible to everything else, to a system that isolates every individual service and user to its own virtual container and so the default becomes it can see nothing else the box is doing, unless someone explicitly arranges for it.

So now goal posts have moved from "init system" to containerisation system. Once you view yourself as providing a universal container, it's natural to also provide all the tools needed by your average container : network devices, mounted file systems, time, logging, setting host name, cron like services, providing mechanism via which the containers can communicate and cooperate, yada yada - there are a lot of them, which is why systemd re-implements world+dog. And there is a surprising one: managing what software packages are visible in the container, so for example only containers that need a setuid sudo have the sudo package. So claims that systemd aims to provide all of the next layer above the kernel aren't too far from the truth, although typical of all spin such claims don't tell you the underlying reason.

To me with my software engineer hat on, it's an inspirational vision. It reminds me of the developments in programming languages 50 years ago, when we went from one big program to deliberating providing well defined interfaces, and hiding everything else by default. It also addresses a frustration I have felt for the last decade or so - that we now rely on machine visualisation to isolate our systems. This is absurd. For a start it's hugely inefficient. That's obvious from one simple metric - the number of containers something like OpenVZ can support vs VMWare. But worse, it's a demarcation dispute that cuts deep into our terrority. We software guys are supposed to be kings of layers of abstraction - but here we are using the abstraction layers provided the hardware guys over own.

On the other hand to me, a sysadmin responsible for ensuring hundreds of machines runs smoothly - it is scary stuff. Just learning a new init system is a big enough chore, but tossing out my current expertise in configuring boxes for a new paradigm is going to be a metric fuckton of work. I am absolutely not going to contemplate doing that work until it there is proof the vision the software engineer is getting so excited about yields a better result, proof in the form of systems that are easier to set up, and have been deployed and stable for a long while. If Debian were to force me along that path before it is in my professional opinion prudent to do so, I would abandon Debian, even though I am a DD. I think this is what underlies a lot of the angst I see on the Debian lists. For jessie that's undeserved as Debian is only adopting this bits of the systemd init system that replicate what SvsV is doing. It's a fairly small step.

However there is no denying where the systemd developers want to take us. Once they succeed in enticing us to take this first inch, they fully expect us to walk with them along the full mile. I can't fault their strategy - it's the tried and true embrace, extend, control. Getting every distro to use the systemd init system is the embrace step, and it has been done amazingly well. It is indeed far better SysV init system that SysV ever was, and the work they have done on backwards compatibility is awesome. If they pull the rest off with the same competence, they may well have a hope of taking the entire Linix eco system with them.

And finally we get to the relevance of the sentence I quoted at the start - charactering this as merely a changing from an "init daemon" to an "init system" is missing the point. In fact you've missed the entire barn.