Debian init systems GR
Posted on Sun 15 December 2019 in debian
This is my vote:
-=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
7b77e0f2-4ff9-4adb-85e4-af249191f27a
[ 1 ] Choice 5: H: Support portability, without blocking progress
[ 2 ] Choice 4: D: Support non-systemd systems, without blocking progress
[ 3 ] Choice 7: G: Support portability and multiple implementations
[ 4 ] Choice 3: A: Support for multiple init systems is Important
[ 5 ] Choice 2: B: Systemd but we support exploring alternatives
[ 6 ] Choice 1: F: Focus on systemd
[ 7 ] Choice 8: Further Discussion
[ 8 ] Choice 6: E: Support for multiple init systems is Required
-=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=---
I don't think that nowadays the choice of the init system can neutral: like the choice of a kernel, a libc and some other core components, you cannot just pretend that everything can be transparently swapped with anything else, therefore Debian rightly has to choose a default thing (Linux, glibc, the GNU userland, and now systemd) which is the standard proposal to the casual user. Systemd has clearly become the mainstream thing for a lot of good reasons, and it is the choice the most Debian users and developers should adopt (this is not to say that systemd, its development mode or its goals are perfect; but we have to choose between alternatives that exist, not between ideal ones). This is the reason why imposing that any init system should be supported at the same level is silly to me, and therefore why option E is the last one, and the only one below Further Discussion; in much the same way as it would be silly to impose that kFreeBSD, Mach and musl should be supported at the same level of their default counterparts (although I would be pretty excited to see that happening!). We cannot expect any Debian contributor to have the resources to contribute scripts/units for any init system randomly appearing.
At the same time, I like Debian to be Universal in the sense of potentially being home for any reasonable piece of software. Diversity, user choice and portability are still values, although not absolute ones, and nobody in Debian should make it impossible to pursue them. I also share the "glue" vision proposed by the principles of choices G and H. Therefore work extending support for non-default init systems (and, again, kernels, libc's, architectures, any core component) should be loyally accepted by all involved contributors, even if they do not see the need for such components.
For these reasons I consider option H the one that, despite being possibly a bit too verbose, spells out my thoughts. All the other options are essentially ordered in how close I percieve them to option H.
I'd like to thanks Ian Jackson for having proposed option H and for having collected a few important criteria to find a way in the jungle of all the available options.
Leave a comment
Comment will be manually reviewed before being published.
Comments
-
Anonymous said, on 2019-12-15 21:59:47+01:00:
Unfortunately, despite their titles, options H and D include a built-in delay of 12 months before making progress with any new feature.
-
Giovanni Mascellani said, on 2019-12-16 07:30:00+01:00:
I'm not defending all the individual details in H. Overall it seems the most balanced proposal that aligns with my thoughts. And one year is not an absurd time in the Debian release cycle.