Differences between revisions 5 and 6
Revision 5 as of 2013-10-28 13:52:06
Size: 1930
Comment: Add some arguments
Revision 6 as of 2013-10-28 13:54:29
Size: 2074
Comment:
Deletions are marked like this. Additions are marked like this.
Line 16: Line 16:
== Contra change to anoother initsystem == == Contra change to another initsystem ==
Line 18: Line 18:
 * [[https://lists.debian.org/debian-ctte/2013/10/msg00027.html|Estimates]] of up to 1200 Debian packages may be required to adapt to, and continue to support, such a change.  * [[https://lists.debian.org/debian-ctte/2013/10/msg00027.html|Estimates]] are that up to 1200 Debian packages may be required to adapt to, and continue to support, such a change.
 * If packages remove their current initscripts, ports like kFreeBSD and Hurd may be unable to use software that was working before this.

sysvinit

  • If someone assumes maintainership over this page as prescribed in the

    Debate page, please say so here. Until then though, I think we'd gather more information if everyone contributes freely.

Pro

  • It is integrated in the Debian ecosystem and this integration is well tested.
  • It works on all supported architectures and kernels.
  • Has a long history, and so is widely used and understood among UNIX-like systems; /etc/rc.d initscripts still used today by FreeBSD since at least 1999, OpenBSD since v4.9 and NetBSD.
  • Many of us using sysvinit know how to fix an unbootable system: boot with init=/bin/sh and you can edit or invoke the the initscripts by hand
  • 'It works' - sysvinit can successfully boot my system until now - or else I wouldn't be here writing this...

Contra change to another initsystem

  • Estimates are that up to 1200 Debian packages may be required to adapt to, and continue to support, such a change.

  • If packages remove their current initscripts, ports like kFreeBSD and Hurd may be unable to use software that was working before this.
  • Much third-party software outside of the Debian archive, or in-house projects within business, may no longer work without taking effort to port them to another initsystem.
  • Any change at all involves work, learning something new, and therefore should be a choice; this feels somewhat forced upon us by those who insist it is better but do not have everyone convinced.

Contra sysvinit

  • Perhaps the "against sysvinit" section belongs on the other initsystems' pages?
  • It is hard or at least non-obvious to support daemons starting on demand.
  • init scripts are not really user edit-able configuration. (https://lists.debian.org/debian-devel/2013/05/msg01787.html)

  • No real process supervision, e.g. daemons are not automatically restarted when they crash.
  • No integration with udev, services cannot be started when specific hardware is discovered.