<i>Regarding file ownership, not necessarily. If you run it as a session-based init, they&#x27;d be owned by the user it serves as an agent to.</i><p>Interesting.  I didn&#x27;t realize systemd had a &quot;user mode&quot; where it doesn&#x27;t run as pid 1.  Does systemd run as root (or root equivalent) in this mode?  I wasn&#x27;t able to find this from a quick skim of the information available online.<p><i>Upstart and launchd do not have the same issues. Upstart doesn&#x27;t have dependencies, but named preconditions and postconditions. launchd has neither that nor dependencies. They have many problems of their own, but different ones.</i><p>Sorry, but I have to disagree.  The terminology may be different, but ultimately upstart&#x27;s &quot;start on&quot; directive establishes a dependency.  Once you have a dependency you can have circular dependencies.  And once you rely on the init systems to establish ordering rather than having everything just start up in a deterministic order in simple single-threaded script, you can have race conditions where things happen to work on one machine but not another.  I&#x27;m not as familiar with launchd; maybe its socket activation makes the circular ordering harder to hit, but fundamentally there can always be races.<p><i>I&#x27;d assume the limited use of C&#x2F;R to simply cut down initialization times is feasible: <a href="http:&#x2F;&#x2F;criu.org&#x2F;Usage_scenarios#Slow-boot_services_speed_up" rel="nofollow">http:&#x2F;&#x2F;criu.org&#x2F;Usage_scenarios#Slow-boot_services_speed_up</a> </i><p>Perhaps for some processes this is feasible, but nothing on that site addresses my objections above: &quot;some processes deal with state in the external world, or with hardware, that makes checkpointing infeasible.&quot;  You will always need a notification mechanism even if you have checkpoint and restore.  And why have the complexity of checkpointing if you have a working notification system?<p><i>Running shell scripts doesn&#x27;t mean much when the underlying system has a large surface and ill-defined module boundaries. A plugin system most certainly does not have to be complicated: look at finit and initng for examples.</i><p>From a user&#x27;s point of view, I do not want a plugin system.  I want systemd to work the same on SUSE vs. debian vs. Red Hat.  It is usually better to put things into the base system than to have them live in a half-supported state outside the tree.  That&#x27;s why web browsers are killing plugins: in order to be useful, they have to reach deep into the guts of the program, which is not a place I want 3rd party code.<p><i>What about journald did you not understand? You lose control over the separate stages of collection, rotation and processing. Particularly having custom postprocessing is important for interoperability with foreign services that might expect certain format constraints.</i><p>I don&#x27;t understand why I would want separate daemons for collection and rotation, at least for dmsg, kmsg, and syslog.  logrotate always had a bunch of race conditions; it was never a great design.<p>I agree that journald doesn&#x27;t do custom processing.  However, I&#x27;m a little unsure whether I would really want it to, or whether I&#x27;d be better off running my own syslogd implementation at that point.  That is still an option, even when you are using the rest of systemd.<p><i>Having the logs be per-service instead of globally snarfed is also saner.</i><p>You can always set up important services to log to a file rather than to syslog.<p>My real criticism of systemd is that they made no effort at portability outside of Linux (and I don&#x27;t buy their arguments about why it&#x27;s too hard.)  It would have been a lot less controversial if they had at least pointed out how the BSDs could add support (even if they themselves didn&#x27;t do the work).