Respectfully: that "independent tools packaged together" line is repeated often - and it's just so much bullsugar. I run systemd in prod, on many machines, and

Respectfully: that "independent tools packaged together" line is repeated often - and it's just so much bullsugar. I run systemd in prod, on many machines, and am way confused as to why anyone thinks this is true. (The rest of this post isn't aimed at you, chimeracoder - but you've made an argument I've heard a few times, and I'd like to address it at length, because this is where systemd discussions usually devolve into namecalling instead of actual discussion.) Thinking of systemd utilities like unused kernel drivers - just harmless bits occupying disk space and never used until loaded - is simply an incorrect analogy. A client of mine is running systemd in prod, and I'm managing their system - so when I tell you this, what I'm saying is "whoever explained either isn't running systemd in prod on multiple machines, or is having a wildly different experience than I am." Ask whoever explained this to you if they are running systemd in prod! I would love to be wrong about this! I feel like I hear this explanation (excuse?) fairly often, so instead of setting up a straw man, lemme flip the script here: Could someone - anyone! - please point out a single distro or OSS project that a) makes use of systemd and b) doesn't end up building the same exact monolithic init.d re-implementation as everyone else running systemd? Systemd could potentially be used as a suite of independent tools, kinda, I guess - but that's not what the devs are aiming for from what I can tell, and I've never seen - or even heard discussion about - systemd being used in practice as anything besides a monolithic init.d replacement. Most arguments to the contrary fall apart really quickly, with a simple question: "How and why would you actually build this theoretical pick-your-own-utils-totally-not-a-monolith thing you're describing? Please show your work. Extra credit: explain why no one else appears to have attempted this, outside of the thought experiment that I've just proposed to you". My guess is, like it or not, I'm going to be stuck using systemd-resolve (the DNS resolver) and systemd-timesync (the NTPD replacement), I'm guessing, because I want to use systemd-network, and the best case scenario is that my old ntpd and nsd daemons are going to have some weird issue working properly with systemd-network. What weird issue? Well, those old daemons had some quirk or other that really should have been fixed for interoperability's sake, and mumble mumble DBus won't connect for some esoteric reason, so.... they'll still "work", but the systemd-* replacement we've written works so much more cleanly and with less random flaky bugs , and using them will stop that weird hanging issue you're seeing, so.... Ugh. (Again, sorry chimeracoder for the comment hijack. I have a lot of systemd angst, apparently.)