On Tue, 2013-10-29 at 00:45 +0000, Steven Chamberlain wrote: > a commitment to > support two chosen init systems. The question is.... would supporting two be enough to give a considerable benefit? I guess the competition will be mostly between: systemd vs. upstart. And not between sysvinit, anything else vs. systemd or upstart. sysvinit is simply too old and lacks many modern features. With anything-else, Debian would be more or less completely alone since all world (except *buntu) seems to settle on systemd. So from that POV, I'd even say upstart is already an island solution. Look at most core daemons and systems/technologies (read about CUPS and Wayland just a few days ago) - their upstreams seem to focus on systemd. So when Debian really supports two init systems... what could that be? Either a) systemd AND upstart I guess that would largely be a political benefit, since then the two major fractions are happy. b) (EITHER systemd OR upstart) AND sysvinit That could have a real technical benefit, with respect to !Linux flavours- since then we'd have systemd|upstart for Linux and sysvinit for !Linux. At least systemd does not support !Linux... and I guess it's the same for upstart(??). But then we'd have again the political problem of systemd vs. upstart, since only one could win. So *if* supporting multiple init-systems, and by supporting I mean, that every package must support _at least_ those, then supporting 3(!) seems to make more sense: sysvinit, systemd and upstart. I generally hope, that the tech-ctte will not *forbid* the use of any other init system, but just rule about a _minimum_ set of initsystems (or one) that MUST be supported. Cheers, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature