> My understanding (I believe detailed in the article) is that Debian, at least, chose systemd because they were forced to
This (and much of the article) is incorrect. Debian went through an extensive evaluation process at the time, over the course of 4 months, considering several different init systems, and chose systemd based on this detailed technical evaluation. That evaluation also considered sysvinit, openrc, and upstart. All of that evaluation occurred publicly, and is archived on Debian's mailing lists and bug-tracking system.
Debian also ran a poll a few months ago in order to reevaluate that choice, at least partially. Quite the hint that all is not jimmy-dandy.
As a programmer in embedded, Systemd feels like it solves problems we didn't have, and introduces problems we didn't have. I what point is it more conservatism than "if it ain't broken, don't fix it"? God only knows.
Well, every time the Systemd topic pops on HN or Reddit (and even other places where you wouldn't expect it [1]), I go fetch some popcorn... It seems that different people have different needs and different experiences, hence the flamewars.
Can you reference that poll? There was a GR, which is entirely different than a poll. The outcome of that was also pretty clear, Debian as a whole is ok to depend a bit more on systemd. I don't get why you use it as an example of the opposite.
I might be misinterpreting the result, but "Systemd but we support exploring alternatives" means, to me, that there is some unhappiness here. To begin with, I believe the GR would not have happened if there was no issue to be discussed?
The GR happened because it wasn't clear what maintainers should do regarding alternatives init systems. Were they required to support them? Should they just focus on Systemd? The result of the vote was maintainers are required to support Systemd, but should accept patches to support other units.
The unhappiness was that the existing status quo made people afraid to actually use features of systemd, lest they invite flames from people about not supporting alternatives (which don't have those features). The GR changes the status quo to allow hard dependencies on systemd to actually use its features. The "but we support exploring alternatives" ensures that the GR does not preclude the possibility that people might create something better than systemd in the future.
All of my views come straight from primary sources which I meticulously uncovered, including Debian mailing lists.
I realize that you have been one of the more visible members of the pro-systemd side for years now, so I'd definitely like a more coherent rebuttal to both the historical and technical sections.
Of course, you'd probably consider any kind of response to be undignified, and I understand.
I participated in those discussions first-hand, and recall them rather well. At no point was "we don't have a choice" taken seriously as an argument; even most of the pro-systemd folks didn't consider that a valid argument for systemd, and many of the most judicious and respected voices in the discussion called out such arguments as being unhelpful. Debian is large enough and stubborn enough that they're more than willing (occasionally entirely too willing) to do their own thing if they think they have a better path.
As for the rest, I consider https://news.ycombinator.com/item?id=23062725 a good start. systemd was successful because it provided working code that people (including distribution maintainers) wanted to use, for a variety of reasons. This is the type of problem where no amount of architecture-in-a-vacuum discussions make up for actually doing the work and handling all the myriad cases that come up when people use it in practice. systemd did that; the next init system after systemd will need to do that as well.
This (and much of the article) is incorrect. Debian went through an extensive evaluation process at the time, over the course of 4 months, considering several different init systems, and chose systemd based on this detailed technical evaluation. That evaluation also considered sysvinit, openrc, and upstart. All of that evaluation occurred publicly, and is archived on Debian's mailing lists and bug-tracking system.