1711
Comment:
|
1814
|
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.