Differences between revisions 14 and 15
Revision 14 as of 2013-10-30 12:55:23
Size: 3752
Comment: OpenRC ported
Revision 15 as of 2013-10-30 12:57:45
Size: 3784
Comment:
Deletions are marked like this. Additions are marked like this.
Line 21: Line 21:
   * Having two interchangeable init systems would demonstrate the features, robustness, performance of each in practice, and be able to evaluate them; popcon would measure their popularity, the BTS would give insight into real users' experiences.    * Makes for healthy competition; having two interchangeable init systems would demonstrate the features, robustness, performance of each in practice, and be able to evaluate them; popcon would measure their popularity, the BTS would give insight into real users' experiences.

multiple initsystems

  • Anyone may contribute to this page for now, in the hope of attracting the most ideas possible.

Supporting two specific initsystems for jessie would overcome a lot of current issues with deciding on a new default. On mainstream ports (Linux amd64, i386) where two initsystems are available, a package should be tested and made to work reasonably well on both. For example:

  • systemd and sysvinit
  • systemd and OpenRC subject to being ported almost done already

  • sysvinit and upstart (subject to finding solution for GNOME logind)

Some combinations would be infeasible however:

  • systemd and upstart - leaves nothing for non-Linux ports
  • sysvinit and OpenRC - not advantageous as OpenRC is backward compatible

Pro

  • Offers (most) users with choice, e.g. being able to remove systemd, if they object to it and don't need its functionality - this benefits some Linux users who specifically want this, not just the ports.
    • Allows users to keep what they have already (if at least one of the init systems is compatible with SysV init scripts); this may allow non-Debian packaged software to continue working without modifications.
    • Makes for healthy competition; having two interchangeable init systems would demonstrate the features, robustness, performance of each in practice, and be able to evaluate them; popcon would measure their popularity, the BTS would give insight into real users' experiences.
    • Could offer a heavyweight init system ideal for some desktop environments or servers; and a simpler init system for embedded systems and small VMs.
  • Would allow GNOME+logind+systemd+Linux to continue pursuing their goals without disrupting others.
  • Allows the ports (GNU/kFreeBSD, Hurd, and others) to continue to exist (if at least one of the supported init systems is available to them). A newly-developed port would be able to target whichever is easiest to implement.
  • Allows a smoother, less risky introduction of a new init system.
    • Easier to backport jessie packages to wheezy, if those packages still support sysvinit.
    • One of the init systems would likely use the SysV init scripts that are already there - this does not require new work (but could be an overhead for future package maintenance).
    • Perhaps systemd or Upstart would continue to use some packages' SysV init scripts, meaning there is support already for multiple init system without additional work or overhead.
  • Seems fitting with Debian philosophy of a Universal OS. Is similar to how GNOME, KDE and other desktop environments have been able to co-exist in the same distribution.

Contra

  • Some maintainers spoke objections to maintaining multiple init scripts / configs. However:
    • I believe people from both camps have an interest in helping packages work well on their preferred initsystem, so we should be able to collaborate.
    • The problem is reduced if at least one initsystem can reliably invoke the other's (perhaps already existing) initscripts.
      • It is impossible for systemd and upstart to run each other's units/jobs, but they both can run LSB SysV init scripts; OpenRC can also.
    • Automatic generation of systemd unit files from initscripts is being worked on.
    • Some packages will have upstart job definitions already, from Ubuntu downstream.
    • As a last resort, a non-essential package might set an explicit dependency on only one initsystem (similar to the situation where a package is declared 'linux-any', if porting is too difficult). This must be discouraged however, or the other initsystem becomes less useful.