Antonio Terceiro wrote: > However, as with any piece of software, systemd doesn't and won't ever cover > all use cases. It should be possible for people to use other init it they > choose so, for whatever reason. How well those would work should depend only > on > the effort of those interested in doing the necessary work.
I think the discussion has concentrated too much on this principle in the abstract. The situation is clearer when you look at the more concrete details of what kind of changes there is controversy over. In short: there is little to no worthwhile work being done on any alternatives to systemd. What is happening is some people trying to keep sysvinit working to about the level it did in 2014, while doing very little fundamental development to the system that would fix its widely recognized flaws. Such work will not help innovation, will not produce a plausible alternative to systemd, and is not worth supporting. It was already near consensus five years ago that sysvinit was seriously lacking and improvements were needed. The choice of systemd over Upstart was more controversial, but systemd opponents have not managed to create an alternative that would reach even the level that Upstart had back then. Even Ian, as one of the main authors of the "diversity" proposals, agrees that sysvinit is flawed and significant future development would be needed. Yet he argues that sysvinit work should be respected, that it should not be considered obsolete, and so on. I disagree: it's perfectly reasonable to consider sysv init scripts obsolete, and consider "try to keep sysvinit at 2014 levels indefinitely" activity a dead end. Note that I'm not saying that people shouldn't develop alternatives to systemd. But to be taken seriously, they'd need to display some real progress beyond sysvinit (and Upstart). Just "this allows to boot without systemd" is not a worthwhile "alternative". "I disagree with systemd decisions, here's my fork / alternative system" - this may be OK depending on system quality. "I disagree with systemd decisions, but, uh, I don't really have resources to create a credible alternative, so... uh... let's just keep using sysvinit indefinitely?" - this is not OK, not EVEN IF your criticism of systemd choices were valid, and activity which amounts to essentially this does not deserve support. As there currently aren't credible alternatives to systemd, not even at the level of Upstart, I think it's wrong to phrase the question in terms of whether Debian "supports innovation" and so on. The practical question now is whether Debian insists on supporting the obsolete sysvinit, not because of any positive qualities it has or potential for future development (and very little forward development has happened in the last five years), but only because it allows systemd haters to avoid using systemd. IMO encouragement for supporting alternative systems could be reasonable, but only for actual new innovation; maintainers should be explicitly permitted to remove any existing sysvinit scripts and refuse addition of similar scripts. Systemd units should be no worse a basis to bootstrap a new system. TL;DR You'd need real work to develop a credible alternative to systemd. Nobody has done or is doing that work. As long as the practical alternatives are crap, abstract arguments like "diversity" or "supporting innovation" are no reason to support anything else.
