> The first issue is that Linux has always been a commodity white box OS built from interchangeable parts available from multiple sources, just like the PC. Systemd goes out of its way to break that, and in doing so represents an enormous loss of flexibility.
systemd goes out of its way to fix the massive integration failures we've had for decades (and seen as almost unfixable) because Linux is so focused on modularity to a fault. And because of systemd, we're finally starting to get a level of integration that previously only appeared in proprietary operating systems. http://islinuxaboutchoice.com/
Linux is good at evolutionary changes, but not nearly as good at escaping local maxima via large-scale cross-project changes. Not least of which because anyone attempting to make such changes has to be prepared for the anti-change "but the UNIX way!" flames.
Every time I see someone railing about the UNIX way, I think of how people flame each other about / versus /usr, and how the original motivation for /usr was "we ran out of space on /, put some of the less critical stuff on the user disk". Appeal to tradition is not an argument unless you have a concrete reason why the tradition is better, and I rarely see such reasoning in arguments leveled against systemd.
I've also found that well-articulated and well-founded arguments about problems in systemd don't tend to last long, because systemd will fix them. I'd encourage people who see a legitimate technical problem with systemd to go discuss it on the systemd mailing list; you might be surprised how quickly it gets fixed, if it has substance.
> Linux systems are modular, with multiple implementations of anything important.
Feel free to make something better than systemd, document it as extensively as systemd, spend years writing guides to its most compelling features that get people eager to switch, and do as much work as the systemd developers did to help the entire Linux ecosystem adopt it with shockingly few technical problems. There's nothing stopping you; you can even leverage the entire systemd codebase in the process. Fork it and change what you don't like, if you think you can keep up. Good luck; you'll need it.
> But systemd isn't like that. It's a single all or nothing blob
Refuted so many times that anyone still saying this is either intentionally misleading or utterly uninformed about what they're railing against. systemd runs incredibly little in PID 1; it has numerous separate single-purpose processes (typically named /usr/bin/systemd-foo or /lib/systemd/systemd-foo), as well as several libraries abstracting out key bits of common functionality for other code to use.
> Ubuntu did upstart, but ubuntu also did unity, and mir, and pointed /bin/sh to dash, and their launchpad is based on the obsolete "bazaar" source control system... People not following Ubuntu's technical lead is pretty deeply justified at this point.
Now this one is actually a very well-made point, and it's something few people have stated outright. There's a reason that few other distributions switched to upstart; while it adds a few key features over sysvinit (such as service supervision), it has some serious deficiencies as well. It's not at all clear that switching from sysvinit to upstart would have been an improvement. And the biggest key feature of upstart, service supervision, is actually something sysvinit already has but nobody uses: you can run a process directly from inittab, and sysvinit will restart it when it exits. But rather than using that, every Linux distribution just uses sysvinit to launch a shell script that launches a hundred other shell scripts.
That said, I applaud Ubuntu for actually trying to make major changes to Linux. Unity isn't what everyone wants, but it's certainly an attempt at a non-incremental improvement over other desktop environments, and it has some nice properties. Similarly, Bazaar was an attempt to do better than CVS and SVN, and it's not wildly awful; it just lost to an even better system for a variety of reasons (http://www.stationary-traveller.eu/pages/bzr-a-retrospective...). /bin/sh -> dash is, while not necessarily inherently better, an attempt to enforce an absence of bashisms in #!/bin/sh scripts, and an attempt to improve the performance of such scripts; in that, it has worked reasonably well.
There's no excuse for Mir, though. :)
> Android also has a no GPL in userspace policy
Not exactly, though Android certainly pushes back on GPLed code. They're willing to adopt it when there's no viable alternative. But systemd is LGPL these days, not GPL. And even if systemd were GPL, it would still be quite possible to use systemd as an init system to launch proprietary software.
Regardless of Android's allergy to copyleft, permissive-versus-copyleft is an ancient holy war that long predates Android. The only reason the argument comes up so strongly in this case is that systemd is the right combination of rapidly developed and too useful to ignore to make it a serious threat to people who don't want to use it. If systemd were less useful, or otherwise easier to clone, its copyleft license would be less of a concern to the opponents of copyleft. That's a feature, and it's exactly the kind of thing the authors of the GPL and LGPL had in mind: the existence of high-quality software under copyleft licenses that make life difficult for the proprietary software world.
Personally, I was rather disappointed when systemd switched to the LGPL; I would have rather seen it remain GPL.
> Those of us waiting to see how it shakes out feel we're having systemd shoved down our throats by a development team actively threatened by the idea of people _not_ using their stuff.
It couldn't possibly be that the software is sufficiently compelling that those without religious objections to it are switching to it to take advantage of its useful features. No, it must be a conspiracy.
> But even if it wanted to, android can't easily clone systemd, becuase it's (intentionally) a moving target with no standard and no documentation.
"no documentation" is insultingly misinformed; systemd is one of the best documented software products I've ever seen.
And in any case, why should the systemd developers go out of their way to make life easier for people who don't want to use systemd, when they could instead spend their time making life better for people who want to use systemd?
> We can't opt out and see how it goes, we must fight to stay where we are.
Sure you can opt out: just sit there doing nothing, and the world will pass you by. Or you can participate, and do as much work as the systemd developers are doing, in favor of your preferred system. What you can't do is try to stop other people from doing work you don't like without putting at least as much work into a better alternative. Keep up or get out of the way, don't shout "wait up" or "no fair".