> I want to be in control how my system works. To do that I need to be sure of what it is doing and how. As the complexity of a system grows, the number of thin

> I want to be in control how my system works. To do that I need to be sure of what it is doing and how. As the complexity of a system grows, the number of things it does under the hood grows. At some point I can't keep track of what's going on, and I no longer have confidence in my knowledge of the system, without setting aside time for a code review. > With pid 1 being incredibly simple, and the executables it runs being incredibly simple, I know what's going on, I know what the possible problems are and I know how to fix them. The more complex it is, the more difficult it is for me to know what's going on. That's all it comes down to for me. How is, say, sysv init better in this regard? Instead of having declarative service files that say what should be done, you have a collection of disparate shell scripts, all with their own implementations of basically the same things. The complexity isn't reduced, it's spread around (and IMO it's more complicated). If you want to have control over your system, wouldn't you want to use an init system that can actually keep track of all of the child processes of a service? Brittle hacks like pidfiles cannot ensure management over all child processes of a service -- this is only possible with cgroups. > As an aside: A lot of systemd is API-driven, meaning if you want a feature you have to build it into the system as new code. This means you have to be a C developer to leverage some new feature, instead of writing an interpreted script and interacting with it via pipes/plugins/etc. If your current system is dependent on some feature that doesn't yet exist in systemd, you now have to build it in, instead of using what worked with sysvinit before. No, you just use D-Bus, from whatever your favorite language is, using that language's D-Bus bindings. Systemd has a stable D-Bus API for this purpose that's guaranteed to work in the future. > Not only is systemd broken by design, it's still in its infancy, and does not support the same features that have been built into other systems for years. Out of curiosity, what features are you referring to specifically? > This additional load of development for many orgs serves no purpose, and is essentially ignored by the leadership that decide to change init systems by fiat. This would be more convincing if it were just Lennart & co. making the decisions, but in the absence of evidence to the contrary, I'm going to go out on a limb and assume that the technical leadership of Fedora, RHEL, OpenSUSE, Arch, and now Debian do not all make decisions by fiat for no reason.