systemd is becoming de facto a standard init system for Linux. But even this choice of words is treacherous, because systemd is much more than an init system. It's basically an integrated redesign of all the low-level userspace of a Linux system, with great plans to change how software is run and organized.
Which is not a bad thing per se: Unix software can definitely benefit from improvements in this area, and the s6 suite, among other software, comes from the same assessment and ultimately has the same goal. But systemd suffers from a single conception flaw that sets it apart from the other initiatives, and that has both political and technical repercussions.
The single, overarching problem with systemd is that it attempts, in every possible way, to do more instead of less.
systemd attempts to cover more ground instead of less. In other words, rather than simply being an init system, it tries to be a complete overhaul of the way a Linux system is run, and tries to force other software to hook with it in order to be supported. This goes very much against:
The reason why systemd has become so prevalent is not that it has been accepted by the community. It's that it has manpower. It is backed up by open source software companies that can provide much more manpower than developers like myself working on free software on their own time. The distribution model of systemd, made of lobbying and bullying, is much more akin to the distribution model of Microsoft Windows than the one of GNU/Linux.
I claim that systemd goes against the bazaar approach; someone noted that the s6 development model is cathedral-like, and found it confusing. How can I blame systemd for not embracing the bazaar when I myself don't either? My answer was the following:
I actually do not support bazaar as a development model for a project. I believe that quality software can only be written by keeping a tight grip on what goes in, with a clear vision about the scope and design of the project, and that can only be achieved with very small teams. Free software following the bazaar development model is notoriously bad at quality control; the only way to have a project working is to have a small lead team performing integration control - this is the way the Linux kernel works, for instance, and it has a huge developer base.
(The other more or less viable development model for a project is to be company-driven: making up for the lack of technical excellence with manpower and procedures. Needless to say, companies usually do not produce either free or good software, and they are not efficient at doing so.)
However, I also believe that the scope of a project should be clearly defined and limited, and I very much support the blossoming of as many well-scoped projects as can be, and total freedom about the interfaces and communication points between all those projects. I support bazaar as a development model for a software ecosystem: everybody can write software that interacts with other software on their machine, in the way they choose. To me, that is entirely what free software is about.
systemd gets it wrong on all levels. It has a large developer base, so no really coherent vision (and the vision it has is technically inept, see below); its quality control is company-driven, with all the drawbacks that it has; and it has an insanely large scope and tries to enforce the use of its own interfaces for new software development, essentially proprietarizing the ecosystem, which is very much the opposite of bazaar.
Software that does more instead of less is, simply put, badly designed software. Trying to come up with an all-encompassing solution is always a sign of developer hubris and inexperience, and never a sign of good engineering. Ever. Remember sendmail, BIND, INN, and, definitely a better analogy, the early days of Microsoft Windows ? Yes, systemd is in exactly the same league. It's as if we had learned nothing from the mistakes of the past 20 years. The systemd programmers may be better at writing code than the BIND programmers - which isn't saying much - but they are just as bad at designing software, and when said software is process 1 and basically the whole low-level userland layer, it is frightening.
Yes, doing more instead of less is especially bad in the case of system software, i.e. low-level software that aims to make the machine work and that application software depends upon. The goal of an operating system is to make it possible to run applications, and system software should always partake in that goal. System software should stay the heck out of the way, which is exactly what systemd does not. In that respect, it is very similar to Microsoft Windows. Again.
Listing all the technical flaws of systemd is a lifetime's work; some people have pointed out the most glaring ones - there are a few links below. My point is that the "we will solve problems by doing more" approach chosen by the systemd developers is a newbie mistake, and the root cause of all those flaws; systemd is technically unsustainable.
s6 is my humble contribution to the fight against systemd, and I am committed to making it evolve so it becomes a real alternative.