Over time, the number of packages that do will fall, because engineer convenience and cognitive bandwidth are incredibly high priorities; "that's the crusty old way while this is the new hotness"; and, "oh, but we need this one little thing systemd offers," &c.
And before you know it, those of us on the ops side are stuck supporting something we loathe, and having to rewrite a bunch of scripting and tooling in response to discovering new and exciting ways the "new hotness" ends up breaking things that worked perfectly well until it came along.
Literally, we're facing another iteration of that very cycle right now: our non-production environment refresh process suddenly fails to complete without being manually thumped at multiple points. Why? System fucking d.
But no: "It works fine for us, so it can't be a problem for anyone else, right? Right?"
However, dividing teams into developers and (Dev)Ops sides like warring factions is not healthy. I'm also an ops guy (more precisely a sysadmin who supports a lot of users and servers) in my day job, and a I develop stuff for academic world and for my own pleasure in my free time, so I know both sides of the so-called moat.
Using features because they're hot is not also OK for any application, but not using features which can solve real problems is unwise in my book. We also had hacks which were working perfectly fine until systemd came. We evolved, changed how we do things and moved along.
> "It works fine for us, so it can't be a problem for anyone else, right? Right?"
I didn't want to tell or imply anything resembling this. I just gave my own opinion, based on my experience.
The thing that many people don't understand about systemd is that they don't have to sell to users or developers, they have to sell to (and design for) distributors. Lennart and Kay know that because they are both working for distributors (Redhat and Suse, respectively).
To distributors, the promise of systemd is the promise of less integration work. It paves over a ton of useless idiosyncracies in distributions (e.g. compare systemd's /etc/os-release with the previous /etc/*-release files that you cannot even call by name because they were called something else on each distribution). Initscripts is the biggest bullet point in that list: Initscripts were always written by the distribution because each distribution had their own scripting layer on top of sysvinit to make it a bit nicer, and each of these was incompatible with those of other distributions. Systemd units, on the other hand, can be maintained by the application developers themselves, and several distros (e.g. the patch-hating Arch Linux) actively pushes systemd units upstream.
When the application developer takes care and has only one target (the de-facto standards forced by systemd), life gets a whole lot easier for distributors. And that's why distributors choose systemd.
[0] https://people.debian.org/~stapelberg/2013/05/27/systemd-sur...
SystemD caused problems at the time and there was no reason not to postpone the decision to Jessie+1, which is what Debian usually does in such cases: "more discussion needed".
Debian broke their social contract, showing that their priority was no longer with their users.
I didn't know that. I thought the poll was open to anyone to vote for the relevant time window.
> Debian broke their social contract, showing that their priority was no longer with their users.
Isn't this a little bold claim? AFAICS, the poll has spotted the potential problems and general grievances pretty well (like binary logs, etc.), and concluded that these reservations should be addressed before systemd has included in Debian?
I'm not trying to defend systemd here. As I said in my comments, I disliked it first, and then I learnt and got used to it. My teammates has shown bigger reactions to it, and then they liked it too, after we configured it to behave the way we like. I didn't migrate to systemd voluntarily. It fell from above on me in a pretty hard way.
There was a whole Hoo-Hah. It was years long. People resigned over it. The votes and discussions are often misrepresented by people recounting the tale. (Common misrepresentations: presenting it as a two-way contest between van Smoorenburg init+rc and systemd, when OpenRC and Upstart were both included, and both favoured over van Smoorenburg init+rc; presenting it as a single vote when there were several, including some votes on Debian General Resolutions by all of the club members; presenting the wiki pages written by the partisans and ignoring the lengthy technical reports from the TC members.)
During this period, I was a developer and so-called tech lead of a Debian derivative distro. We were working on some absurd requirement about generating system responses on some events, pulling continuous all-nighters. One day systemd packages arrived to Debian (sid or testing, I don't remember), and using it solved our problem. This is how I became aware that Debian packaged systemd, and it's gonna be the next default init, that's all.
As I said before, I don't blindly support systemd or anything. I'm just using Debian for 14 years or so, and I'm riding on what comes along. I don't have time to devote serious development time to them, however I wish I was able to contribute into Debian or any serious FOSS project. Hmprhf.
[0]: https://wiki.debian.org/Init