Andreas Barth <a...@ayous.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 choices. > 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? 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 particular service. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
