| With the caveat that I haven't kept up closely with systemd 1. It is attempting to unify a bunch of previously disconnected functionality into a single program. Typically unix is composed of small single-purpose utilities that perform a single function, rather than a giant monolithic blob of code (with obvious exceptions, like emacs). 2. Partially because it has been around for so long and has so much history, and partially because it follows a unix tradition of using plain text configuration and shell scripting to solve problems. 3. The systemd folks believe that sysv init isn't capable of doing things that are important to modern systems (ex. dependencies between services, reacting to devices coming and going, intelligent daemon management, etc), and that doing those things correctly requires that an init system be 'more' than people previously thought it needed to be. They are also very....confident in their ideas, and don't hesitate to re-implement functionality (like logging) if it makes is easier to interoperate with their other code. People opposed to systemd believe that it is too complex for such a critical piece of system functionality. They also resent the fact that systemd seems to require tight coupling to the rest of the system, and that it is aggressively pushing into so many linux systems. Many of them also probably have a long history with sysv init, and are comfortable with the way that it works. (Some portion also probably recall pulseaudio, which had similar grand visions, was similarly aggressively pushed into use before it was fully baked). 4. I think 1-3 probably cover most of this. |
He still trots that disaster out as proof of his fitness to lead, so it's hard for me to trust that systemd is both well-designed and likely to not be abandoned by him for his next shiny pursuit of Windows. The involvement of other devs helps, but not enough to convince me systemd is worth getting near. Two years of audio fail made a good object lesson for me about Lenart's professionalism and dedication.