Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Steve Langasek <vorlon@debian.org> writes:
> While it's fair to note that Canonical is a smaller company with fewer
> resources than Red Hat, Canonical is certainly not the only company
> working on technologies that don't fit into systemd upstream's model.
> On the question of cgroup management for instance, while there's broad
> consensus that we want to move to a single-writer model, there is not
> consensus about what that single writer should be; at the last on-line
> Ubuntu Developer Summit, developers from Canonical and Google discussed
> how to collaborate around their respective cgroup technologies (lxc,
> lcmtfy) to address the single-writer requirement for non-systemd
> systems.
> http://summit.ubuntu.com/uds-1311/meeting/21982/core-1311-cgroup-manager/
> We're not talking here about whether Google will contribute to upstart
> upstream, because this is code which is separate from upstart by design.
> But in the wider ecosystem of projects that exist in parallel to (and
> are incompatible with) systemd, there are other players besides
> Canonical.
> For logind, which is the main point of contention with respect to
> systemd 205 being usable on systems that don't use systemd as init, the
> main blocker is, again, around logind's use of init as the cgroup
> manager. In that same UDS session, a decision was taken to provide
> cgroup manager API compatibility with systemd via the systemd-shim
> package, which is a small Canonical-maintained compatibility layer (not
> yet in Debian, but that's easily addressed). This will enable use of
> logind 205 on systems running upstart (or, for that matter, sysvinit).
This is useful, thank you. So you believe that the necessary cgroup
functionality will be easy to maintain going forward in collaboration with
a different cgroup manager? How far away is this functionality from being
production-ready? My understanding is that this will need to be tested
and working for jessie.
> I don't believe we need to worry about sufficient manpower to keep up
> with systemd development. There are a fair number of people who have
> resigned themselves to systemd because they've been led to believe it's
> the only option. If Debian standardizes on upstart, some of these
> developers will be interested in collaborating with Debian to provide
> equivalent functionality / compatible interfaces. It may not be many
> developers in absolute terms, but the rate of development for an init
> system should not be high in absolute terms either.
Well, I partly agree with this, but I'll point out that upstart is
currently significantly behind in functionality. Contrary to some other
expressed opinions here, I personally do not consider systemd's support
for such things as private /tmp or other security and isolation features
to be minor side features or only marginally interesting. I think these
sorts of features are where the Linux ecosystem is moving, quite quickly,
and Debian badly needs those features as soon as we can get them. It's
going to take some time to adapt all of our software to use those
features, so the sooner our init system can provide them and we can get
started, the better.
I have a similar question about OpenRC: the lack of this sort of
functionality is, for me, a very serious issue, although one that would be
mitigated by a clear plan to add it that seems likely to happen.
> Well, I guess you wouldn't expect me to say "yes" here, or if I did, you
> wouldn't believe me; it's unrealistic for Canonical to commit to
> implementing some arbitrary - and hypothetical - future functionality.
> Canonical is committed to being a good steward for upstart for as long
> as Ubuntu itself uses it, and welcomes its use by other distributions.
> But this isn't an act of altruism, it's enlightened self-interest.
> Canonical isn't going to make an indefinite committment to maintain
> features it doesn't have need for itself.
> But I think the same can be said of systemd. If Debian concluded that
> systemd's cgroup manager design was wrong because it embeds it in PID 1,
> and wanted systemd to be compatible with other container solutions like
> lxc and lmctfy, I don't think we would expect Red Hat to make this
> happen for us.
The problem for upstart is that these are not comparable, precisely
because Canonical plays such a smaller role in the broader ecosystem. For
better or worse, integration with Red Hat and Fedora is extremely
important to most of our upstream projects, and Red Hat provides
significant development resources itself to many upstream projects. This
means that systemd integration is far more likely to happen without
Debian's assistance than upstart integration.
I think the argument for upstart relies on the assumption that such
integration is not horribly important or normally won't be a serious
issue. In essence, my understanding of how you view a world with upstart
(and the world that Ubuntu is implementing) is that we will use most of
the systemd services but not its init engine, replacing that and the
cgroup manager with upstart, and still participating in the rest of the
systemd ecosystem. This sounds quite reasonable provided that it's
relatively straightforward to do this, which is going to depend heavily on
how much core functionality is provided by the init component and how much
is provided by separable services.
> bzr lost the DVCS war not because Canonical was unwilling to invest in
> bzr, but because git had an early lead in performance and flexibility
> that made it the runaway choice for developers, and by the time bzr was
> catching up in functionality, network effects meant it was too late.
> Once it became clear that bzr would not deliver on its promise of being
> a universal DVCS because the world had already adopted git as a de facto
> standard, it was reasonable for Canonical to stop investing in bzr
> development.
True. However, I'll point out that a similar argument can be made for
systemd.
> So I don't think there's much similarity between what happened with bzr,
> and what would happen with upstart if Debian adopted it. If Debian
> adopted systemd instead of upstart, /then/ there would be hard questions
> about the future of upstart, in light of a clear consensus that systemd
> is the technically superior option. But if Debian /does/ adopt upstart,
> Debian + Ubuntu represents a critical mass to keep the project going for
> the foreseeable future.
And this is exactly the assumption that worries me. Debian certainly has
a lot of great developers, but we're perpetually understaffed to do the
things we've *already* committed to, and the desktop maintenance teams
(for which these issues are the most critical) are also some of the most
under-staffed. It's not at all clear to me that KDE or GNOME upstream
will be that heavily influenced, in terms of where they put development
resources, by which init system Debian chooses. I love Debian too, but
it's not clear to me that we swing that much influence with those
particular projects.
Now, that doesn't matter if Debian can use upstart and still "look like
systemd" from the perspective of the features that the desktop systems
care about, such as logind and some of the other services. And it sounds
like that's what you're saying can happen. I'm trying to feel out how
plausible that outcome is.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: