[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#727708: tech-ctte: Decide which init system to default to in Debian.



* Russ Allbery (rra@debian.org) [131102 04:12]:
> 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?
> [...]
> 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 would like to ask this question even a bit more general (for all
involved init systems): 

How much would we have "vendor lock-in" by each init system? Means, is
there more software except the pure init system we might need to take
if we switch to that init system. Also, what can we expect for the
future? How much does the roadmap allow for exchanging other services
without changing the init service? And also looking from the other
perspective, if we would change the init service later on, which of
the nearby services would we loose at the same moment as the init
service?

For upstart, this might be the case described above.

For systemd, just one example (which might be as artificial as the
upstart example): there are more services included in the code base,
like IIRC a syslog server. Can we continue to run different services,
or do we de-facto need to switch to systemds implementations of the
services? Would upstream be interested to keep the non-systemds
implementation of the accompying services working?

(Examples for the other init systems are also possible, but I think I
can save the time of writing them down. But I would also be
interessted in answer for those.)




Andi


Reply to: