tl;dr: the author argues that:<p>* systemd is more similar to a traditional job scheduler than a traditional init system.<p>* systemd should not parse text files in pid1 because it might be a security risk.<p>* Because systemd handles order dependencies, it is sometimes susceptible to &quot;ordering cycles&quot; where a clear ordering cannot be established, &quot;dependency loops&quot; where jobs are continuously dropped and requeued, and race conditions if dependencies are accidentally underspecified.<p>* &quot;Imbalance between promoting laziness or eagerness&quot;: launchd, a predecessor of systemd, operated purely &quot;lazily,&quot; launching services only when other services needed them.  systemd also supports launching services eagerly, which the author argues is more complex.<p>* Checkpointing a process image could have been used instead of systemd&#x27;s readiness notification mechanism (?)<p>* Systemd does not have a plugin system<p>* Journald is criticized because it does too much<p>I would counter that:<p>* I agree that systemd is similar to a job scheduler, but I don&#x27;t necessarily believe that that is a bad thing.  Manual scheduling of jobs for startup and shutdown like we did in the rc.sh days is complex and error-prone.<p>* The text files systemd is parsing are owned by root, so even if the parser is exploitable, only root can take advantage?  Seems like a weak criticism.<p>* I agree that dependency ordering makes things more complex.  But upstart and launchd have the same issues.  It seems to be a tradeoff worth making.<p>* I don&#x27;t understand the argument against supporting both laziness and eagerness in dependencies.  It seems like some things are naturally modelled eagerly, like needing to perform a bunch of somewhat unrelated actions to suspend the system.  And some things are better handled lazily, like setting up a FUSE filesystem when a USB stick is inserted that needs it.  Shouldn&#x27;t we use the model that makes the most sense?<p>* I don&#x27;t think checkpointing a process image can ever really replace having a notification system.  Even if the checkpointing code could be make bulletproof somehow, some processes deal with state in the external world, or with hardware, that makes checkpointing infeasible.<p>* Regarding a plugin system: Systemd has the ability to run shell scripts, which can be useful in filling in gaps in functionality.  I don&#x27;t think a more complicated plugin system would be a good idea since it would add a lot of complexity (and potentially instability.)<p>* I didn&#x27;t understand the criticism of journald, maybe someone can elaborate.  The author presented some alternate approaches but I missed why these were better (other than the handwavey argument that journald was &quot;a bottleneck&quot;)<p>I enjoyed reading this, and it&#x27;s nice to see some more reasoned criticism of systemd.  I feel like the prose got a little bit purple at times.  We had to spend 10 paragraphs &quot;descend[ing] into an inferno with the same dead horse talking points&quot;, &quot;culminating into some rather heterodox conclusions&quot;, and &quot;progressively introducing and elucidating on concepts, applying some a priori reasoning at times, and backtracking to derive conclusions or reiterate on prior stated knowledge&quot; before we even saw a word of argument!  This needed an editor...