Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]
Philip Hands writes ("Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]"):
> I thought you said that your GR (i.e. option 1) was effectively a NOP
> for Jessie (that's certainly how I read the text of your clause 4)
> in which case the people that would prefer to avoid systemd have
> several years (until the end of jessie-LTS) to come up with
> alternatives that they prefer, so there is absolutely no reason to
> panic about it now.
I think this is a misreading of the situation. Encouraged by
systemd's vigorous and effective marketing campaign, changes by (some)
upstreams to introduce dependencies on facilities bundled with systemd
will continue apace.
I don't want to be having this conversation again in a year's time,
with those upstreams and their like-minded Debian contributors saying
things like `it is too late now; the world has moved on'.
> If we were to adopt Option 1, then we'll be dragging sysvinit behind us
> like a ball and chain long past the last person who clung to it notices
> that there are better alternatives available -- which presumably will
> come to pass eventually (or more likely happened some time ago, but the
> inertia in Debian is blinding us to that fact).
I am personally not a great fan of sysvinit. This argument is not
really about service startup, though. It's about systemd's graphical
console management, its replacements for syslog, cron, ntpd, acpid,
etc etc etc.
Certainly there is nothing in this GR that would prevent us dropping
sysvinit. But there is obviously plenty of effort available for
keeping sysvinit - as an init system - working. That's not the real
> Also, they'll be doing all that under duress, so will likely be irritable
> when anyone asks them to support a third init, whereas without this
> meddling in the natural order they'd probably be quite interested to
> adopt an emerging competitor to systemd that supports their needs.
In the battle between those upstreams and Debian contributors who want
everyone to use systemd, and those developers and users who don't want
to use systemd, _someone_ is going to experience duress.
The question is who.
systemd's adoption strategy combines vigorous and effective PR with
expansive bundling, and repeated assertions that systemd's competitors
(and I don't mean sysvinit) are obsolete and/or unsupportable.
This is a novel approach in the Free Software world. Traditionally
Free Software developers have attempted to win by convincing /users/
that their software is superior, rather than by convincing
/developers/ that there is no credible alternative.
It's not surprising that we're having a political storm as a result.
And it's not surprising that the biggest howls are from users rather
than developers. After all, the systemd adoption strategy
disenfranchises users - just as Debian's governance process does.