* Russ Allbery (r...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
