[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: My analysis of the proposals



On Sun, 2019-12-01 at 18:43 -0500, Sam Hartman wrote:
> > > > > > "Uoti" == Uoti Urpala <uoti.urpala@pp1.inet.fi> writes:
> 
>     Uoti> IMO encouragement for supporting alternative systems could be
>     Uoti> reasonable, but only for actual new innovation; maintainers
>     Uoti> should be explicitly permitted to remove any existing sysvinit
>     Uoti> scripts and refuse addition of similar scripts. Systemd units
>     Uoti> should be no worse a basis to bootstrap a new system.
> 
> 
> This is what I tried to capture with Proposal B.
> I wrote a blog post yesterday which still should be on planet discussing
> my thoughts about this and discussing some of the risks of that
> proposal.

Based on your blog post, your technological views seem similar to mine.
Where my view differs, and why I think Proposal B is not particularly
satisfactory, is more about the social view of opposition to systemd.

Like you, I think that from a technological point of view you shouldn't
assume that those who want alternatives to systemd would support
sysvinit. However, as a matter of social reality, people who oppose
systemd almost exclusively do want to keep using sysvinit. People who
find systemd objectionable mostly just don't want to switch to it,
without really caring about whether their current setup is a
technological dead end or not.

Thus, in practice, I don't think there is any real conflict between
people who are trying to create innovative new systems and people who
want to use systemd (I count elogind as "now needed to keep sysvinit
working like in 2014" rather than any kind of innovation). There is a
conflict between people who want to stay with sysvinit and people who
want to use systemd. To resolve this conflict, the important part of a
resolution would be how to treat sysvinit in particular. I don't think
Proposal B clearly answers this question. It does not clearly say that
Debian has no need to explore sysvinit technology any more than it
already has, and it's now OK to throw away all sysvinit support. If it
DID clearly say that, I think most of the practical conflict would
already be resolved, and text beyond that would be mostly superfluous.



Reply to: