Differences between revisions 24 and 25
Revision 24 as of 2013-10-31 23:02:48
Size: 5766
Comment: requesting a maintainer
Revision 25 as of 2013-11-13 11:34:39
Size: 5922
Editor: ?MarkoRandjelovic2
Comment:
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
    • http://bugs.debian.org/684396#10

    • http://bugs.debian.org/684396#30

    • 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.