systemd is reliant on dbus because Lennart Poettering's philosophy on Unix is slightly different than the philosophy of a great many other people. The quote he

systemd is reliant on dbus because Lennart Poettering's philosophy on Unix is slightly different than the philosophy of a great many other people. The quote here (https://www.linuxvoice.com/interview-lennart-poettering/ https://www.linuxvoice.com/interview-lennart-poettering/) summarizes it: What’s typical for Unix, for example, is that all the tools, the C library, the kernel, are all maintained in the same repository, right? And they’re released in sync, have the same coding style, the same build infrastructure, the same release cycles – everything’s the same. So you get the entire central part of the operating system like that. If people claim that, because we stick a lot of things into the Systemd repository, then it’s un-Unixish, then it’s absolutely the opposite. It’s more Unix-ish than Linux ever was! Pid Eins goes through his own "mythbusting" around the concept that systemd is not consistent with the Unix philosophy: http://0pointer.de/blog/projects/the-biggest-myths.html http://0pointer.de/blog/projects/the-biggest-myths.html But Ken Thompson and the people who were around him had a different view. http://www.catb.org/esr/writings/taoup/html/ch01s06.html http://www.catb.org/esr/writings/taoup/html/ch01s06.html (Doug McIlroy) (i) Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features. If you look through the abstracted rules esr proposes, they are often in complete contravention of the philosophy of systemd. The number of things systemd has broken by design or accident is quite substantial. The amount of things it touches in Linux is significant. It's pretty stunning to me that even experienced developers don't see anything wrong with systemd - it has had profound effects on system reliability, performance, usability, etc, most of them extraordinarily negative, for a benefit that is unclear. I think if the scope had been smaller, the vehement disagreement with the implementation/principles behind systemd would probably have been mitigated quite a bit. We are where we are. For better or for worse, systemd is taking over many Linux distributions, put there by people who have a very different view of what Unix is about. The people that support systemd are more or less supporting similar principles as Microsoft espoused for many years - an integrated system so tightly put together that it becomes difficult to tease things apart or to understand the working of the system, and an additional giant SPOF - something early Linux advocates protested about so vehemently. Those of us who know the difference use alternative distributions or BSD, the former of which is becoming harder as package maintainers and software authors are relying on systemd more and more. To be fair, commercial Linux is where the money is, and all this plays directly into Red Hat's business model. Funny, how in the end we adopt the same methods and principles we so vociferously argued against.