Re: Proposal: let’s have a GR about the init system
Thomas Goirand <zigo@debian.org> writes:
> Plus if we choose Upstart or Systemd, then that's effectively what we
> are going to do (I mean, we'd have to support 2 init systems, because of
> Hurd & kFreeBSD).
Not necessarily. We could also decide that whichever init system we pick
will need to be ported to Hurd and kFreeBSD (in some fashion, possibly
with functionality restrictions) or we'll drop support for those
architectures.
I'm not saying that's necessarily the correct decision, but I also don't
think it makes sense to proactively take it off the table. We've had lots
of discussions about this in the past, and it's clear there is not general
agreement on the relative priorities of supporting non-Linux kernels
versus adopting new and better (but non-portable) technology for Linux
kernels. There are a lot of strong opinions, but not agreement.
I think it's worth noting that, historically, the Hurd port has never
required us to hold back the Linux architectures. Rather, the Hurd
porters have worked hard on adding functionality to Hurd to support the
software in the archive by implementing Linux interfaces, and at turning
the required changes to packaged software into general and defensible
upstream improvements. I've always been very impressed by this effort,
and I don't think we should assume systemd or upstart could not be handled
the same way that many other things have been handled in the past.
(Also, while I'm not personally familiar with the issues involved and may
be missing some subtlety, at first glance it seems like an event-driven
init system would actually be a more natural fit for the Hurd's
microkernel model than the ordered startup forced by sysvinit. Conceptual
fits of course don't imply that the porting would be easy.)
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: