>>>>> "Jerome" == Jerome BENOIT <calcu...@rezozer.net> writes:
Jerome> On 19/09/2019 00:46, Sam Hartman wrote:
>> Init System Diversity =====================
Jerome> ....
>> So perhaps sysvinit and init scripts have had their chance and it
>> is time to move on. We could move away from init scripts as the
>> default representation. We could stop caring about sysvinit
>> (which isn't quite the same thing but is related). That would
>> leave non-linux ports in an unfortunate position. But right now
>> there are no non-linux ports in the main archive. So perhaps we
>> don't even care about that. Again, a change, but a change that
>> we can ask ourselves if we are ready to make.
Jerome> Otherwise I am very surprise that Devuan was not mention at
Jerome> all. May be it is time to work with the Devuan team and
Jerome> merge Devuan to Debian.
Devuan developers have been working with Debian to reduce the number of
differences. Several of the people involved in these discussions have
been Devuan developers as well as members of this community. I think a
couple might even call themselves Devuan rather than Debian, although
when you send that many messages to Debian bugs and lists, I personally
think you're part of the Debian community too.
I have explicitly been working with people in the Devuan community. But
it's never come up whether they represent Devuan. They were
constructively working to solve problems in both distributions so I
worked with them.
Jerome> This does not look as diversity.
What is diversity?
Is diversity about being able to develop new software? Is it about
trying new things, trying to build better init systems over time? Is it
about trying to consider solutions to the things people don't like about
systemd?
If that's diversity, sysvinit isn't very interesting. The design of
sysvinit has not evolved and changed significantly. It has not learned
from the mistakes of systemd. It's interface has been static for years.
Or is diversity because you actually want to be using sysvinit. If the
entire point of your interest in diversity is that static interface,
then sysvinit is interesting to you in the diversity argument.
We can judge the second category of users based on who actually uses
sysvinit. And honestly, that's not a lot of Debian users. Some of them
have probably migrated to Devuan or other distros. Many have realized
that systemd actually can meet their needs. But for whatever reason,
not a lot of people use sysvinit on Debian.
And honestly, a lot of these technical problems get more complicated
because we want to be able to swap out implementations. Elogind is a
lot easier to deal with if you know that your distro is always using
elogind. Init system choice is a lot easier to deal with if you know
that you only have one init system. Personally, I don't think there are enough
sysvinit users in Debian to justify keeping sysvinit around because
people want to use it. If sysvinit on Linux was the only thing to
consider, I'd recommend we look at having something like Devuan be all
sysvinit and Debian be all systemd. We could work with them as a
downstream and avoid needing to deal with the complexity of switching
init systems, libsystemd implementations, etc.
To me the question of future choice is far more interesting. First,
current users today cannot be used as an effective argument about what
we'll do in the future. So it's harder to answer the question.
Secondly, Debian has always put a fairly high value on enabling
experimentation and evolution. And a significant fraction of our
community do share some of the concerns about the Systemd design
approach.
In that model, sysvinit is much more of a stub than an init system.
It's something we can run inbetween experiments as a sanity check that
things still work without systemd and that we have not locked ourselves
into systemd. If some users actually want to run sysvinit, and it works
well for them, that's great, but at least for me personally, that is not
a priority.
Obviously some people have different values.
So, I think we have multiple questions on the table. What is init
system diversity? Do we want init system diversity? What are we
willing to do to get any init system diversity we decide we want.
--Sam
