Just some small comments... The binary log can be disabled if you don't want to use it. I personally dislike simple text logs and find them frustrating to use

Just some small comments... The binary log can be disabled if you don't want to use it. I personally dislike simple text logs and find them frustrating to use and would rather not go back to them, and using a traditional database engine is overkill here. (An on-disk log database only needs to support create and read operations) Regarding security and code base size, it's not clear to me that any other architecture here is going to be less error prone. The problem seems to be that a large number of operations that you probably want your service manager to do on Linux require root or CAP_SYS_ADMIN. It doesn't really seem to matter if you put that stuff outside of pid1, a program that needs the same elevated privileges can still stomp on your system and mess with the state of pid1. I've found systemd has extensive documentation (at https://systemd.io/ https://systemd.io/) and the developers on the IRC and mailing list usually seem to be responsive. I searched and I could not find any examples of this "bullying" on LKML. It looks like Greg was the person who was sponsoring it and trying to get it merged, not Lennart. And I'm not sure I would call their use of dbus to be abuse. I honestly think it would be cool if other low level daemons used dbus in this way because it makes integration (GUIs, automation, remote control, security policies, etc) a lot easier, as long as you familiarize yourself with the tooling around dbus. All that said, systemd is made for a general use case and is not ideal for containers or for embedded. I hope these other init systems can find their niche.