Bug#727708: init system other points, and conclusion
Russ Allbery writes ("Bug#727708: init system other points, and conclusion"):
> We seem to be at the point of the process where at least those of us who
> did early investigation are stating conclusions. I think I have enough
> information to state mine, so will attempt to do so here.
Thanks.
> First, other choices besides systemd and upstart.
I agree with your comments here; it appears you've investigated OpenRC
in more detail than I have but I'm happy to take your word for it.
> 2. Core Service Management Functionality
...
> To my surprise, that's not what happened. Rather, I concluded that
> systemd has a substantial technical advantage over upstart, primarily in
> terms of available useful features, but also in terms of fundamental
> design.
I think we have fundamentally different ideas about what the
replacement init ought to be like. I don't think either of us will
convince the other.
> 3. Ecosystem and Portability
...
> 3.1. Ecosystem Reality Check
...
> Rather, we're talking about whether or not to swap out a core component of
> an existing integrated ecosystem with a component that we like better.
Unless you are proposing to make systemd mandatory for all Debian
installations, this is work that needs to be done anyway.
Also, I get the impression me that the "integration" of much of this
functionality into the systemd source package has been done for
political rather than technical reasons. Indeed to the extent that
there is a problematically tight technical coupling between these
components, I find it difficult to avoid doubting the good faith of
the people making those decisions. At the very least, I worry that
the systemd project as a whole is far too willing to impose decisions
of all kinds on its downstreams.
Under those kind of circumstances I am willing for the Debian project
as a whole to go to quite some effort (and, indeed, impose some effort
even on the maintainers of systemd in Debian) to retain the
flexibility that I think is important. That flexibility certainly
includes the ability for a user to drop use of parts of systemd that
they don't find desirable.
> Now, I am generally on the side that says loose coupling of ecosystems is
> an inherent good. However, I don't agree that it's such an inherent good
> that we should disassemble things just for the sake of having disassembled
> things. At feature parity, and absent any compelling reason to swap
> components, I think we should take the path of least resistance and use
> the integrations that other people have already developed. Debian has
> more than enough hard integration problems to solve without creating new
> ones for ourselves unnecessarily. But that's the key word: unnecessarily.
> If we do have a reason for doing this, we should seriously consider it.
If these problems have been created with reckless disregard for the
flexibility needs of downstreams and users, then I take the opposite
view.
> 3.2. Portability
...
> So, in short, I consider portability to be a possible benefit of upstart,
> but I'm inclined to discount that advantage for several reasons. One,
> it's not yet actually materialized and still may not,
My understanding was that Dimitri had got upstart running on BSD.
I can't imagine that this problem won't be solved (in Debian) for
jessie. We're not talking about some nonexistent hypothetical
patchset.
> 3.3. Project Momentum
I don't see the outlook here the same way as you do.
Furthermore, I am much less worried about Debian going it alone
(although, of course, it's not alone) than you seem to be. We have
historically been entirely unafraid to do our own better things, even
if it is more work and takes us longer.
I felt that way when Debian was very much a minority interest. That's
far from the case nowadays; I've heard it asserted that Debian-based
distros now account for a majority of traditional distro installs. I
guess numbers on that are all speculative but it is certainly true
that we have a thriving ecosystem of our own.
We have got where we are by doing things the way we think is best, not
by simply following the herd.
Of course you say that you prefer systemd, which still leads you to
the opposite conclusion. But I wanted to explicitly deal with this
argument.
Ian.
Reply to: