5766
Comment: requesting a maintainer
|
5922
|
Deletions are marked like this. | Additions are marked like this. |
Line 14: | Line 14: |
* Init scripts can be improved using abstraction and addtional features can be implemented as suplemental software that could be used from shell scripts. |
sysvinit
RFA: a volunteer is sought to assume maintainership of this page, who may need to produce a position statement as detailed at 727708#305 and 727708#315 This has been drafted from arguments raised in debian-devel and elsewhere.
Pro
- It is integrated in the Debian ecosystem and this integration is well tested.
- It works on all supported architectures and kernels (sysvinit can successfully boot my system until now - or else I wouldn't be here writing this...)
- Has a long history (System V R4, 1988?), and so is widely used, well documented and understood by users of UNIX-like systems; /etc/rc.d initscripts are still used today by FreeBSD (since at least 1999), NetBSD since v1.5, OpenBSD uses something similar since v4.9; Red Hat from ??? up until RHEL6 and Debian since ???
Is the smallest and simplest initsystem available http://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems#Size_and_complexity
- Init scripts can be improved using abstraction and addtional features can be implemented as suplemental software that could be used from shell scripts.
- Many of us using sysvinit know how to fix an unbootable system: boot with init=/bin/sh and you can edit or invoke the initscripts by hand.
Contra change to another initsystem
- Any change at all involves work, learning something new, and therefore should be a choice; this decision feels somewhat forced upon us by some who insist it is better for us.
- If GNOME requires logind which requires systemd, it is unreasonable to impose such a change on the whole distribution, and ought to find an alternative which doesn't.
Unless the new initsystem retains backward compatiblity, and packages continue to provide sysvinit-style initscripts:
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. (Unless the new initsystem can be ported; this is most likely for OpenRC but completely ruled out for systemd).
- 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 a new initsystem.
- Some maintainers object to maintaining separate initscripts to support alternate systems.
Contra systemd
- Not portable, by design; uses Linux-specific functionality not available on other platforms.
- Violates traditional UNIX principles of simplicity and the separation of kernel/initsystem/userland duties such that components are interchangeable.
- Benefits mostly the GNOME desktop which uses its interfaces already, but comes at a cost to others who did not want to change their initsystem.
- Begins a precedent for disruptive change, which may happen again if systemd changes its APIs or deprecates some interfaces.
- logind can no longer be used standalone, as of systemd v205
- Questions over agenda / conspiracy theories surrounding GNOME, systemd, and Linux, particularly Red Hat's interest in them.
- Attitudes expressed by those pushing systemd:
- disinterest in Debian's ports, in "choice" and the ability to "combine everything with everything else":
- misunderstanding of the 'modular' concept; having "some 80+ binaries around" is bloat, it is not modular if they depend on using systemd and its interfaces together as a whole
https://plus.google.com/115547683951727699051/posts/8RmiAQsW9qf
- Lennart Poettering: "The only thing we won't take is patches that make systemd portable to the BSDs or Hurd."
- Throwing POSIX completely out of the window: where does reinvention end?
- "Systemd ships a growing number of useful, unified command-line interfaces for system settings and control (timedatectl, bootctl, hostnamectl, loginctl, machinectl, kernel-install, localectl)."
Contra upstart
- upstart is covered by the Contributor License Agreement; Canonical retains full BSD-like rights over its code and modifications shared back upstream, but the general public can use it only with GPL copyleft restrictions.
- Only available for Linux yet; anyone able and willing to port it would likely have to agree to the CLA, or otherwise fork a separate project.
- Questions over agenda of Canonical / Ubuntu project.
Contra OpenRC
- This initsystem is the least familiar to most of us yet (only recently packaged, and still in Debian's NEW queue).
Contra sysvinit
- Perhaps this section belongs on the other initsystems' pages?
- It is hard or at least non-obvious to support daemons starting on demand.
What about how OpenStack and such uses rabbitmq for this, without taking over the initsystem for everything on the system?
init scripts are not really user edit-able configuration. (https://lists.debian.org/debian-devel/2013/05/msg01787.html)
- Nor should they be; we have /etc/defaults and the rest of /etc for this
- No real process supervision, e.g. daemons are not automatically restarted when they crash.
- They shouldn't crash, but supervising parent process often handle this where needed; djb's daemontools and similar can be used more generally.
- No integration with udev, services cannot be started when specific hardware is discovered.
- This sounds like the specific goal of a desktop environment trying to be user-friendly, but isn't something everyone wants; tight integration between kernel, initsystem and userland is a high price to pay.