Why is it another open source developer's obligation to satisfy your design desires? Are you paying them? If not, put your time where you aren't putting your money, become the purveyor of diversity, and submit a patch. Fork, if necessary and it matters to you that much--it's your right to do so.
The problem is basically that Linux used to be about choice (choose your distro! choose your DE! choose your shell! choose your browser!) but now that it's become big business, large corporations like Red Hat (developer of systemd) have transformed the evolution of Linux from a bottom-up consensus system to a top-down "we develop all the stuff you use and now it all uses our stuff so now you do too" approach. It's _very_ hard for me to build a system without systemd; I can use a niche Linux distro, I can use a BSD, or I can hack another init system (etc.) in myself. None of those are satisfying, I think for obvious reasons.
systemd is not well written, and it is not well designed. Its style and architecture are inconsistent. Parsing is mixed with validation and business logic. The types of CVEs its generated show that there was no coherent thought put into input validation, fuzzing, taint analysis, and so on. The effects of those flaws (your whole system crashes, etc.) show that failure strategies were never considered. And if all that sounds like overkill to you, maybe it is! But I can tell you that these techniques and design strategies are employed by experts to build software that must be robust, like software that controls medical equipment or transportation control systems. We know how to build software that works and that mitigates failures. Looking at systemd's code, it's clear they used none of that knowledge. And that, combined with its sprawling control over my system, makes me not want it on my machines.
I am not a systemd skeptic, but I'm also not somebody who cares that much. (Which might seem at odds with this thread, but I'm in a lot of meetings today. ;) I use it and it gets out of my way. For me, it's fine.
I'm not qualified to judge the quality of the code in systemd directly; I've browsed it a little but I am a middling C++ programmer and while it hasn't stood out to me as smelly I would defer to more knowledgeable heads. I get the drive for very rugged underpinnings, and I'm on board with that; in things that aren't C++ I frequently am the one with the scalpels making criticisms similar to yours, so that totally resonates with me. I am not, however, convinced that any of the alternatives that currently exist are materially better, so I kinda shrug a bit? Further, it seems to me that the generally modular nature of systemd (regardless of how coupled one believes those separate modules to be) suggests that a determined programmer could probably build a drop-in replacement--Rust? Where's my Rust Evangelization Strike Force?--that plays nicely with it and grows to replace poor and soft design.
The social aspect you bring up is, to me, the most compelling argument against systemd (because monocultures aren't great in general, etc.--I think most people agree on that). Thing is, though, I think that that bottom-up consensus model was doomed from the start. I don't think it was ever going to be tenable as soon as there's any money in it. Red Hat wants consistency, their stuff is going to have consistency, you can use it or go off-roading.
I don't think there's a great solution aside from "build your own ecosystem and don't let it get capitalism.txt'd to death." Which is a deeply unsatisfying and impractical answer. And to be clear, people who feel strongly about it should do that. I'm not being snarky when I say that. I'm a pragmatist--if it's better, I'll use it, too, and submit patches if needed and when I'm capable. ;)
> I don't think there's a great solution aside from "build your own ecosystem and don't let it get capitalism.txt'd to death."
I do, it's "if you run a big mainstream distro like Fedora or Debian, let your users swap out init systems". I know there have been debates on this, and I know the general consensus is "it's not worth the trouble / it's not as simple as just swapping out something like systemd". My counter arguments are: there are distros that are doing it, so it doesn't seem like it's that bad after all, and when dealing with something as important as PID 1 (or your libc, or your filesystem) we should be conservative and let users swap things back when making a huge change.
To that I'd just go "sure!", but I'm just a guy. The first thing that jumps out to me, though, is the question of who pays for the doing of it and the testing of it? From what I know (and I've been learning a lot today, it's been productive!), it seems like you're likely to undertake a Devuan level of effort to do it with Debian, and your patchset is going to be so broad as to effectively fork the core anyway. Is there value, then, in tagging along with that major distro? What do you get, then, if you're the second-class citizen? I'm reminded of stuff like Kubuntu, which (and I say this as a long-time KDE fan) has historically limped along with only moderate love--and that's a DE, it's a lot easier to handle DE differences than core init differences, service management differences, etc. (We have the XDG standards and the like, after all. Though I guess, in a certain light, systemd's trying to be XDG-for-the-core, which attacks the question we're looking at directly, yeah?)
The other thing that jumps out at me is just that this hypothetical is mostly kicking the can down the road. If Fedora suddenly decided to support multiple init systems I think it's hard to envision a future where the happy path wouldn't remain systemd; it's what the core folks think is best, otherwise they wouldn't use it now, and even with additional support the lion's share of attention would go to that happy path. To that end I think that any sort of init choice in those distros just becomes "so we'll support it for now, but the set of third party stuff that supports it is going to continue to shrink, so I hope you have an off-ramp in the future."
Between these two issues it seems like separate distros that have a firm commitment to not-systemd end up being necessary anyway and an ecosystem of not-systemd stuff will need to compete for value on those merits. What am I missing?
> Why is it another open source developer's obligation to satisfy your design desires?
I never said it is.
What I said is that if someone values diversity of software, then they should object to applications including a hard dependency on systemD. That's just logical, as including hard dependencies on systemD reduces software diversity by requiring that the system it runs on uses systemD rather than allowing them the choice.
