Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Andreas Barth <firstname.lastname@example.org> writes:
> 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?
I think it's worth noting that there are a couple of angles on this. One
is the direction that you note, but there's also the inverse direction:
committing to a particular init system may mean that we *can't* run some
other piece of software, at least without additional work on our side that
may constitute a fork.
For example, we're apparently already in that situation with logind. In
order to run logind with an init system other than systemd, we will need
to fork it (to a greater or lesser extent), possibly in conjunction with
Ubuntu and Gentoo. It would be good to know if there are, or will be,
other cases like that.
We'll want to look at both sides of that question, and try to understand
how much work like that is potentially on the horizon with the various
> 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
Yes -- I think both your question and my question are two sides of the
same coin, and what side we're looking at in any given case is largely
determined by whether there *are* any other implementations of that
Russ Allbery (email@example.com) <http://www.eyrie.org/~eagle/>