@munin[0] did a pretty good illustration on why both pro/con systemd camps might be right about their reasons:
→ So, systemd is kind of a perfect microcosm of all the 'problematic' behavior in tech, all at the same time. It's a project that is dedicated to novelty and a specific set of goals - mostly speed-centric - above all else. And, to its credit, it -does- make certain linux systems boot faster than other, competing init systems. However. First, the way in which systemd has progressed has taken specific advantage of certain problems in the open-source community. Namely, that there are many projects that have little or no attention paid to them, despite being infrastructurally critical.
→ So there is little desire by various linux distributors to make the effort to maintain them - and when someone shows up offering to replace and maintain that functionality, taking the responsibility off the already overworked maintainers' plate? That's attractive.
→ Open source maintainers are always in a deep technical deficit trying to get these old bits and pieces maintained, so they're eager to get the help, and don't look too closely at what his 'help' entails.
→ And unfortunately, what this 'help' entails is the highly toxic systemd community - and I use 'community' in the loosest sense, because it really works out to being a sort of cult, spearheaded by a specific individual with the ultimate power of acceptance or rejection over anyone else's participation in the project.
→ Which is really unfortunate, because that guy's got an ego the size of Manhattan. And he continually refuses to take criticism over his design and implementation choices - take a look at what's left of any bug reports.
→ I say "what's left" because he has a history of purging anything he considers to be "un-useful" - that is, critical - from the archives
→ Now, certainly, you -could- go ahead and fork the project! Except now you have a giant codebase and no community to work with to fix it. You could always convince the distros to abandon it! ...except you're now up against a bunch of overworked people who, frankly, won't care. And, worse, now that it's a de-facto 'standard' in the linux world, you have a whole lot of institutional inertia to work against to try to replace it, and - unlike when they replaced init - a dedicated group of people who are utterly convinced they're doing the right things advocating against rolling back the changes. And, worse, there -are- some good points. SysVInit -is- grody as all get-out.
→ However, because of their dedication to novelty above all else, they're making not only all the same mistakes sysvinit had to learn...
→ [ And because of ego, rejecting these mistakes as being 'un-useful criticism' ]
→ But they're making whole new kinds of mistakes - things like https://cfp.systemd.io/en/systemdconf_2016/public/events/21 … which is just -staggeringly- WTF.
→ It's this whole fun trend of "fail fast" that, sure, looks great in a startup producing some new kind of app for making your phone go yawp
→ But it's not -really- a very good model for infrastructural type concerns - the things that need to be, by reason of their importance - conservative and slow to change. You want your infra to be -reliable-, not "full-featured" - at least if you've any sense.
→ So: You have the trend-chasing guys who show up to solve "all your problems" at the cost of making mistakes that could be seen a mile away. Eventually leaving you far worse off and making a huge mess that will be -extremely- expensive to fix when a reckoning comes. All in the name of some "change" that's needed from the status quo and without understanding why the status was quo. What's the solution here? Well, for one thing, take a look at the fine print when Mephistopheles shows up offering to take care of all your problems. It's too late for Linux - most Linuces are pretty much doomed at this point into becoming utter travesties that make WinMe look reasonable. Though the Devuan and Alpine folks seem to have some good impetus behind them.
→ Consider carefully what consequences are going to show up from adopting these new and nifty 'features'.
→ Consider that there is a very large difference in requirements between core infrastructure and user-facing things.
→ [ Because user-facing things can fail fast and be updated fast, but core infra is much more expensive and time-consuming to do either ]
[0] Source: https://twitter.com/munin/status/781257878321582080
Sorry about the above format, was too lazy to do a 'storify' or 'tweetlonger' also hoping he puts that into a blog.