Differences between revisions 2 and 3
Revision 2 as of 2013-10-29 00:11:20
Size: 1711
Comment:
Revision 3 as of 2013-10-29 00:14:45
Size: 1814
Comment:
Deletions are marked like this. Additions are marked like this.
Line 7: Line 7:
* systemd and sysvinit

* systemd and OpenRC (subject to being ported)

* sysvinit and upstart (subject to finding solution for GNOME logind)
 * systemd and sysvinit
 * systemd and OpenRC (subject to being ported)
 * sysvinit and upstart (subject to finding solution for GNOME logind)
Line 14: Line 12:
* systemd and upstart - leaves nothing for non-Linux ports

* sysvinit and OpenRC - mostly overlapping functionality with minimal benefit?
 * systemd and upstart - leaves nothing for non-Linux ports
 * sysvinit and OpenRC - mostly overlapping functionality with minimal benefit?
Line 25: Line 22:
 * At least one of the two initsystems would be available on GNU/kFreeBSD, Hurd, and a new port could target whichever is easiest.  * At least one of the two initsystems would still be available to GNU/kFreeBSD, Hurd, and other ports; a newly-developed port might target whichever is easier to implement.
Line 27: Line 24:
 * Seems fitting with Debian philosophy of a Universal OS.

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 default. On ports 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)
  • 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 - mostly overlapping functionality with minimal benefit?

Pro

  • Offers (most) users with choice, e.g. being able to remove systemd, if they don't depend on its functionality.
  • Allows users to not change from what they have now (if sysvinit is one of the supported options).
  • Allows for a smoother, less risky introduction of a new initsystem.
  • Might allow GNOME+logind+systemd+Linux to continue pursuing their goals without disrupting others.
  • At least one of the two initsystems would still be available to GNU/kFreeBSD, Hurd, and other ports; a newly-developed port might target whichever is easier to implement.
  • Could allow choice of of a heavyweight init systems for some desktops and servers; or a simpler init system for embedded systems and small VMs
  • Seems fitting with Debian philosophy of a Universal OS.

Contra

Some maintainers spoke objections to maintaining multiple init scripts / configs. The problem is minimised if one initsystem can reliably invoke the other's existing initscripts. I believe people from both camps would be able to help to make things work on their preferred initsystem.