Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Steve Langasek <vorlon@debian.org> writes:
> For the TC decision, what kind of information are you looking for about
> the plans, beyond "the Ubuntu developers expect to need to address this
> before upgrading from systemd logind 204 and will hold at 204 until a
> correct solution is known"?
I think the right way to put this is that systemd has significant
development resources behind it and is working in fairly close cooperation
with both kernel developers and GNOME developers to make available new
kernel functionality and to provide implementations of various other
interfaces. Multiple implementations are good, but there's potentially an
ongoing stream of development to keep up with, and (putting aside
arguments about coupling and appropriate ways to integrate that
functionality) I believe there is a general agreement that functionality
is desirable and will be used by other software that Debian wants to
provide.
So, one question is whether anyone outside of Canonical is in a position
to help with the heavy development (as opposed to the occasional patch).
Red Hat is clearly committed to systemd, and there's some convergence
towards it among other RPM-based distributions, so long-term resources for
systemd don't seem to be in doubt. Canonical is a smaller company, and
does not always have the resources to keep projects for which it is the
sole upstream vibrant and growing, even when it seems strongly committed
to them (c.f. bzr).
If Canonical *is* the sole upstream, the upstream future here is troubling
to me, particularly given Canonical's current strategic direction towards
Unity. To give a specific example of the sort of thing that I'm worried
about, suppose that GNOME Shell wants a new piece of functionality that
is, on Red Hat, provided via kernel functionality managed by systemd, but
Unity has no need for that functionality. Is Canonical going to develop
an upstart equivalent in support of GNOME Shell, when it is pushing Unity
over GNOME Shell?
Maybe this example is very artificial; I know it's not clear what piece of
functionality would be required from the init system and surrounding
infrastructure that would be required by GNOME Shell and not Unity. But I
think it's at least conceivable given different priorities around such
things as multiseat, and in any case it provides a concrete example of the
sort of scenario I'm worried about.
In other words, it's not so much a specific roadmap as it is a roadmap
approach and resource committment. Debian, by choosing a default init
system, is potentially investing a lot of developer effort on supporting
that platform for packaged daemons, somewhat akin to an organization
choosing a product on which to base a required piece of internal
functionality. I'm therefore asking the same sort of question that I
would ask of a vendor whose products we were evaluating for my day job:
what guarantees do we have that this product will continue to be developed
and supported going forward?
The situation with free software is a bit different from a vendor, of
course, since Debian could always patch or even pick up development of the
software ourselves, but I think we'd all agree that Debian ending up
committed to a system service family (since that's really what we're
talking about here -- not just the init system itself, but also how the
equivalents, forks, or refactorings of logind, D-Bus, cgroups, udev, and
so forth will be handled) whose pace of development has slowed to the
extent that bzr's has would be a very bad outcome.
At least superficially, that outcome looks more likely to me with upstart
than it does with systemd, so I'm looking for some reassurance for why the
risk of ending up in that situation is low.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: