Bug#727708: init system other points, and conclusion
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> Russ Allbery writes ("Bug#727708: init system other points, and conclusion"):
>> 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.
I should be clear that I've not actually run the system. I've tried to
track down documentation and tried to understand what the project goals
were. It's quite possible that I've gotten some details wrong, and I
would welcome any corrections from the OpenRC folks.
>> 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.
What I'm hearing from both GNOME and KDE maintainers is that assuming
systemd would save them a great deal of work. I think having systemd be
the only supported and tested option for at least some large package sets
that heavily use the systemd infrastructure upstream is a not-unlikely
long-term outcome.
In other words, I think the long-term portability future of GNOME (and to
a much lesser extent KDE, where the issue will be bitrot of unused
configurations more than an intentional maintenance choice, and where I
expect the system to at worst degrade functionality rather than stop
working) to non-systemd platforms is already in some jeopardy, because
it's not clear that resources will be available upstream to maintain those
projects outside of the APIs that systemd supports. That was, after all,
the forcing moment that brought this whole debate to a head.
One can, of course, have a wide variety of reactions to that. As someone
who considers portability to be an inherent good, I find it sad, although
I don't have a full appreciation for what problems GNOME is trying to
solve by increasing its reliance on systemd. But I'm highly dubious that
Debian will just single-handedly fix that, or that we would drop GNOME
because we don't like upstream's integration decisions.
> 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.
I hear that you have this impression, but I completely disagree. I find
the amount of bad will and assumption of malice aimed at the systemd
maintainers to be intensely depressing and unwarranted by any of the
interactions that I've seen, and I've been doing a fair bit of reading.
Lennart passionately argues his side. So do you. So do a lot of us. We
all tend to have strong technical opinions and a great deal of confidence
in our own judgement.
Personally, I'm putting contentions that systemd is doing a power grab or
is merging things for political reasons into the same bucket as
contentions that Technical Committee opinions are driven by current or
past employer relationships. I would prefer to assume good faith among
the people involved and understand their projects on their own terms.
> 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.
All upstreams do this. I have yet to meet an upstream for any piece of
software that doesn't care about that software working uniformly on its
supported platforms. systemd is entirely in line with normal upstream
practice of trying to pick the best solution to a given problem and
supporting it thoroughly, rather than incurring the maintenance burden of
supporting multiple ways to do the same thing.
This always involves imposing some decisions on downstreams unless
downstreams are willing to fork around that decision. It's already meant
that some of Debian's decisions are being imposed on Red Hat because they
were judged to be better solutions.
In places where Debian needs to take a different approach for reasons of
backward compatibility or existing integrations, obviously we should, and
we should be sure that we have the flexibility to do so. For example, I
think we should disable the current systemd binfmt support in favor of our
existing working solution. I have not seen any indication that would be a
problem.
You made multiple proposals that do not reflect what Debian is doing
*today*, and which are not *necessary* for Debian. I don't think those
are good test cases for upstream's willingness to accomodate Debian's
needs.
> My understanding was that Dimitri had got upstart running on BSD.
The latest that I have seen on this porting effort is here:
http://blog.surgut.co.uk/2013/11/libnih-upstart-dependency-ported-to.html
I asked previously on this bug if someone had later news. Do you have
more information than that?
The above is definitely not "upstart running on BSD." That's upstart's
underlying support library mostly working on BSD after disabling two
features (that are required for upstart). I haven't not heard whether the
porting of upstart proper has started. That will certainly be much easier
once libnih is ported, but there are, for example, direct uses of epoll in
upstart proper. (I don't know if kFreeBSD already has a portability layer
for epoll in terms of kqueue.)
> 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 think "worried" is an incorrect characterization of what I said. What I
said, rather, was:
I think we should make wise decisions about which areas we want to
invest project effort. I dislike investing significant project effort
in catch-up efforts that, when complete, merely get us back to where
we would have been if we'd chosen a different solution. I don't think
that's wise stewardship of project resources. I want to see Debian
focus its efforts on places where we can make a real difference, where
we can be leaders. That means adopting the best-of-breed existing
solutions and building on top of them, not reinventing wheels and
thereby starting from a trailing position.
upstart is a great project, of which its maintainers are deservedly proud.
However, I don't agree that it's better than systemd. My own research
convinced me of the opposite. But putting that aside, my point in that
section is that, given feature parity (and I mean "feature" expansively,
including adaptibility to Debian's needs), we should choose systemd
because it has more project momentum and better existing integration,
which means that we will have to spend less energy on it and will have
more energy to spend on other things.
It's absolutely worth doing our own, better things. What I don't want to
do is our own *worse* things. Or, for that matter, our own equivalent
things, when we could instead use work that already exists. It's a waste
of energy.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: