Thank you for putting this argument across so succinctly and with such good research behind it. Everytime I hear the arguments in favor of systemd, I wonder whe

Thank you for putting this argument across so succinctly and with such good research behind it. Everytime I hear the arguments in favor of systemd, I wonder when these people actually come down from their ivory towers to do some real life work, where the rubber meets the road. The argument of "lines of code" in a startup script is such a stupid strawman, it defies belief. I design and build large scale production system, and have exactly zero interest in the size (or complexity) of a startup script. I am interested in being secure in the knowledge that a control script handles all possible cases, including edge cases, that might present themselves during the forseeable lifecycle of the service/application in a predictable and understandable manner. If it takes a bit more time and work to understand these scripts, so be it - what are a few extra hours (which, incidentally, force you into a better understanding of the thing your working on - always a good thing) when seen across the timeline fo the service lifecycle? systemd does a few cool things, and many blindingly retarded things. It is probably really nice to have on your laptop, what with the fast boot times and all, but many of the things touted as "advantages" really do not hold up for server work. What do I care if my boot time is a few seconds less on a server? rebooting a prod server is usually a scheduled event, with (depending on the context) can call for anywhere between a 30 to 120 minute maintenance window. The systemd people should be made to work building and maintaining a real-life backend environment for a while.