On Thu, 23 Feb 2012, "Bernhard R. Link" <brl...@debian.org> wrote: > * Roger Leigh <rle...@codelibre.net> [120223 01:47]: > > Yes, there is absolutely a big cost to pay in supporting multiple > > init systems. Choice is good when there's a benefit, but we should > > not ignore the cost we pay. > > If two init system are too much to support, I'd suggest to stay with > the init working for everyone and not support systemd at all.
What are the big costs of supporting other init systems? Systemd supports /etc/init.d/* scripts and I believe that upstart does the same. Therefore anyone who maintains a package of a daemon is not REQUIRED to do anything different for systemd (and I presume upstart although I have never used it). There are some daemons that can give a faster system boot by taking advantage of the way that systemd opens listening sockets. But I don't think that anyone is suggesting that every daemon must be modified to do that. I presume that people who are really enthusiastic about systemd will offer patches for the more commonly used daemons while less commonly used daemons will keep doing what they do now. I've got a few systems running systemd right now. So far the only problems I have encountered seem to be related to the use of cryptsetup. Cryptsetup is a little unusual in terms of daemons in that it may prompt the user for a password and therefore requires keyboard access (which must be unique) and a possible indefinite amount of time for startup. I wouldn't be surprised if cryptsetup needed a minor change to work well with systemd, but I don't think that counts as "a big cost to pay". Now if we were to have the installation process ask for a choice of init systems then it would be a more significant change. But so far no-one has asked for that. It doesn't seem unreasonable to have one default init system per architecture and then allow the user to replace it with a different one after completing the basic installation process. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201202240116.20958.russ...@coker.com.au
