1930
Comment: Add some arguments
|
2074
|
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.