Bug#727708: tech-ctte: Decide which init system to default to in Debian.
"Thijs Kinkhorst" <thijs@debian.org> writes:
> On Wed, November 6, 2013 01:16, Russ Allbery wrote:
>> We'll want to look at both sides of that question, and try to
>> understand how much work like that is potentially on the horizon with
>> the various choices.
> Do you? In the past Debian has not shied away from making the choice
> that it considers technically (or philosophically) the most sound, not
> the one that implies the least amount of work. The choice will probably
> be made on just a few high-level factors, such as the chosen approach
> (dependency vs event based), best user experience and/or licensing.
Well, my choice won't be made on just those few high-level factors, for
whatever that matters. And I seem to have one. :)
Technically the most sound and implying the least amount of work are not
two unrelated factors. Apply reductio ad absurdum: vaporware is not
technicallly sound, regardless of what lofty design principles underlie
it.
We need to be realistic here about what we, as a project, can accomplish.
The ideal init system for Debian is, almost by definition, the one we
write ourselves from scratch to do exactly what we want it to do. There's
a good reason why no one has proposed that. We have certain realistic
limitations about what we can and can't do as a project, which in this
space, among other things, require us to adopt an existing project rather
than writing our ideal implementation from scratch.
The same also applies to other subsystems that go into our distribution.
We aren't going to, realistically, write our own new syslog
implementation, or our own new user session manager, or our own udev
implementation, or our own desktop environment, or our own kernel. We're
going to use existing projects, maintained by other people with other
goals, some with goals that have nothing to do with Debian's goals. We
need to choose useful, interoperable sets of those projects that can, at
the end of the day, come together into a coherent system for our users.
Since that's why we're all here.
As part of that process, we may well contribute to those projects, perhaps
substantially. But Debian is not an island to itself, and if we pretend
we are, we won't produce the quality of distribution that we want to
produce. We're part of a larger ecosystem, and that has quite a bit to do
with the specific decision of how we choose our init system.
> Facts are being gathered about the percentage of code comments, but I it
> seems unlikely that Debian would reject a solution that it thinks is
> architecturally superior because of it having fewer code comments.
That metric is trying to get at something that we do care about, namely is
a particular upstream project going to be excessively buggy (poorly
documented code implies harder to understand code implies people make
mistakes when they change it) and can we understand it well enough to make
whatever integration changes we need to make to it.
Percentage of code comments is a very rough and somewhat dubious metric to
use for getting at that question, but it's getting at something real.
Just like the discussion that we had about syntax is getting at something
real around the UI of the init system that we will expose to our users,
even if the specific question of how one embeds shell commands in the
startup script is not one on which the choice of init system will turn.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: