Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Monday December 30 2019, @12:23PM   Printer-friendly
from the not-all-systemd-really dept.

Earlier this month we covered a story where we quoted the following:

Due to Debian developers having differing opinions on handling non-systemd bugs in 2019 and the interest/commitment to supporting systemd alternatives in the scope of Debian packaging and various related friction points, they've taken to a new general resolution over weighing init system diversity.

The results of the ballot to discover how the Debian devs feel about their earlier decision with the benefit of hindsight is now in:

Using its power under Constitution section 4.1 (5), the project issues the following statement describing our current position on Init systems, multiple init systems, and the use of systemd facilities. This statement describes the position of the project at the time it is adopted. That position may evolve as time passes without the need to resort to future general resolutions. The GR process remains available if the project needs a decision and cannot come to a consensus.

The Debian project recognizes that systemd service units are the preferred configuration for describing how to start a daemon/service. However, Debian remains an environment where developers and users can explore and develop alternate init systems and alternatives to systemd features. Those interested in exploring such alternatives need to provide the necessary development and packaging resources to do that work. Technologies such as elogind that facilitate exploring alternatives while running software that depends on some systemd interfaces remain important to Debian. It is important that the project support the efforts of developers working on such technologies where there is overlap between these technologies and the rest of the project, for example by reviewing patches and participating in discussions in a timely manner.

Packages should include service units or init scripts to start daemons and services. Packages may use any systemd facility at the package maintainer's discretion, provided that this is consistent with other Policy requirements and the normal expectation that packages shouldn't depend on experimental or unsupported (in Debian) features of other packages. Packages may include support for alternate init systems besides systemd and may include alternatives for any systemd-specific interfaces they use. Maintainers use their normal procedures for deciding which patches to include.

Debian is committed to working with derivatives that make different choices about init systems. As with all our interactions with downstreams, the relevant maintainers will work with the downstreams to figure out which changes it makes sense to fold into Debian and which changes remain purely in the derivative.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by Runaway1956 on Thursday January 02 2020, @09:43AM

    by Runaway1956 (2926) Subscriber Badge on Thursday January 02 2020, @09:43AM (#938536) Journal

    I've waded into that link. It gets deep. I'm running out of time, so skipped to the conclusion. That summation pretty clearly states what I've often heard, and in some cases experienced. My long holiday is ending, but I hope to find time to follow links and citations, to understand it better!

    In conclusion

    The typical interpretations of systemd all suffer from incompleteness and conceptual mismatch. The definition of systemd proposed herein is a superior model for examining and drawing remarks from the systemd architecture.

    Despite its overarching abstractions, it is semantically non-uniform and its complicated transaction and job scheduling heuristics ordered around a dependently networked object system create pathological failure cases with little debugging context that would otherwise not necessarily occur on systems with less layers of indirection. The use of bus APIs complicate communication with the service manager and lead to duplication of the object model for little gain.

    Further, the unit file options often carry implicit state or are not sufficiently expressive. There is an imbalance with regards to features of an eager service manager and that of a lazy loading service manager, having rusty edge cases of both with non-generic, manager-specific facilities. The approach to logging and the circularly dependent architecture seem to imply that lots of prior art has been ignored or understudied.

    To sum it up even more succinctly, it's something of a kludge. When SystemD doesn't do what is expected, someone shims it somehow, with little regard to "standards", then generally fails to document it.

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2