Story

Pretty much echoes my sentiments regarding SysVinit. It gets the job done with minimal resources, but it's not really appropriate for modern systems where a parallel and dependency driven init process is a major user requirement and resources are no longer an issue - especially on desktop and mobile devices where the user would like as near to instant on as possible. Despite that I find SystemD does what it is supposed to without too much fuss, and is in many ways more capable than sysvinit, I also think it's a bloated mess that was badly designed from the start, and when it comes unstuck fixing it is an absolute nightmare. Don't even get me started on the whole DBus integration/requirement thing; that sounds more like something Microsoft would have cooked up for Windows than the core principles of UNIX, and is one of the main reasons that I'm taking a good look at migrating as many of our Linux servers over to BSD as possible when they are next due for a refresh.

PID1 needs to just do the essentials and be a minimal piece of code that is pretty much as close to "hello world" as you can get to avoid complications and failures, everything else should either be an optional SystemD module or an external program depending on the the user's preference. Want SystemD to handle your logging, fine, tell it to load that module and off you go. Want to run a proper daemon that can listen for remote log entries too, then disable the SystemD module and use RSyslog or whatever you prefer. Some functions of SystemD are already modular, but that needs to go a lot further in my view, and requiring stuff like DBUS integration right there in PID1 is just asking for all sorts of stability problems, but it into a module, then at least there's a chance the system might be able to recover without a kernel panic.