Oh, that answer is bigger but pretty boring: the dumbest possible alternative doesn't account for the complexity of real life systems. Some examples: On your

Oh, that answer is bigger but pretty boring: the dumbest possible alternative doesn't account for the complexity of real life systems. Some examples: On your desktop, while you launch programs through the window manager, things like the window manager itself, and also the network daemon, and time-keeping daemon, and the daemon that logs go to, etc etc, all need to be spun up by something. Some of those daemons should restart themselves if they crash, and some of them shouldn't. Some of those daemons misbehave, so it's nice to be able to tell them "don't eat all the RAM" that rendaw is trying to use to do whatever you're using the desktop for. Some of those services shouldn't start until it's the right time in the sequence, but also you want booting to be fast, so where we can be parallel, it's nice to be parallel (this is where the graph comes in). And on the flip side, some of those services need to restart if a service they depend on restarts. I've run s6 (the project built by skarnet, the author of the original post here) on a variety of systems. I would highly recommend it as a very high quality example of the kind of minimalist init system you're envisioning. And likewise, I'd encourage you to try it out! It's possible you'd find that for some/all of your use cases, the value of simplicity outweighs the value of the conveniences. But the reason that systemd has seen so much success on modern Linux distros is that for the average distro and average user, the conveniences in terms of functionality and standardization are worth it.