There are no walls on the systemd garden; there's just a well-maintained garden that attracts an increasing number of people. You don't need walls to keep people in when you have sufficiently compelling technology that they want to stay.

The rationale for adopting systemd, is, I'm afraid more complex than simply "sufficiently compelling technology". It is the result of a variety of factors.

Just because a alternatives exist doesn't mean they all have to be equally well supported by every Linux distribution.

No one is saying that.

systemd helps there, by providing a set of components that integrate quite well, and by getting rid of some of the zero-value differences between distributions (/etc/hostname versus /etc/HOSTNAME versus /etc/sysconfig/..., for instance).

I have nothing against systemd's imposed standard configuration files, although ultimately they're not particularly meaningful (and thank heavens for that, I'm hoping it'll last...). /etc/hostname has been a Debian standard for years now that most other distros went to, even before systemd.

Linux, in not using the cathedral method, has a hard time making major changes to escape local maxima, and when such changes do happen it's typically through the focused efforts of a small group dedicated to fixing a particular class of issues.

The use of a bazaar is a good thing. It creates a decentralized system of autonomous channels. A community of thriving subcommunities, a marketplace of ideas where distribution maintainers are free to pick from a variety of flavors for their distros.

And personally, I wouldn't mind seeing Linux distributions learn something about organization from the BSDs, not least of which by requiring that all packages appear in the same version control system side-by-side on the same server.

So essentially you want a ports system? I have nothing against ports collections, but packaging models that involve strict separation of duties are not bad, either.

systemd refuses to work around bugs in other software unless absolutely necessary; when that software is FOSS, it can be fixed rather than worked around.

Yet evidently systemd cannot apply these same principles to itself.

logind needs cgroups. PID 1 needs to manage cgroups. There's a solution that works today, providing features that desktop environments need, for which alternatives do not yet exist. And if you're not a fan of that solution, there are people working right now to create an alternative solution using cgmanager.

It's good that alternative solutions are being made, but once again it's circular reasoning. You're using the premise to justify itself.

Yes, the systemd team is trying to make large-scale changes to the way Linux works. That necessarily puts them at odds with the way Linux currently works. That doesn't make them wrong: Linux is not yet perfect and could use further improvement. (It doesn't make them inherently right, either.)

And when you have such a huge undertaking in place, you don't just tell other people to "sit down and shut the fuck up". Finally, striving for perfection is a vapid sentiment. If this is what is considered "further improvement", then perhaps we need to rethink our needs entirely.