engineering management practices and systemd (Re: Installing an Alternative Init?)
On Thu, Nov 13, 2014 at 11:04 PM, Tanstaafl <firstname.lastname@example.org> wrote:
> On 11/12/2014 5:18 PM, Andrei POPESCU <email@example.com> wrote:
>> On Mi, 12 nov 14, 15:43:09, Tanstaafl wrote:
>>> Sounds good to me, but in reality, since the default *and only* init
>>> system for the last very many years was Sysvinit (this extremely salient
>>> point seems to be completely and totally lost on the systemd
>>> proponents), I think only systemd and sysvinit need to be there... but
>>> allowing for additions once required bugs implementing them are resolved
>>> as fixed.
>> You're forgetting about:
> It doesn't matter Andrei...
> 1. The *default* is what we are discussing.
> The *default* for Debian has been sysvinit since - forever?
> 2. The systemd proponents pushed to make systemd the *new* default - a
> massively major change from *all* previous releases since... forever?
> 3. A bug was opened to allow for the ability to allow a clean install to
> be performed with systemd on wheezy, while sysvinit was still the default.
> It should have been made mandatory that the systemd folks get this bug
> fully resolved and functional *on wheezy*, *and* commit to maintaining
> this ability in jessie, as a pre-condition to even getting the question
> of a change of the default init system for jessi on the ballot.
> Anything else, as I said, makes no sense.
To explain to the systemd advocates who refuse to understand the
engineering questions, this is the real engineering mistake in
The engineering question keeps getting sidetracked by people who
assert that we are talking about technical details, and then proceed
to question (foolishly) the necessity of modularity, or (rightly) the
meaning of modularity, etc. That all was and is still relevant, but if
proper engineering principles had been followed in bringing systemd
in, the open development practices our larger community claims as its
reason for existence would have taken care of the technical details.
Maybe it would help if I said, "engineering management", instead of
just "engineering", although you really can't separate management from
It was clear much longer than four years ago how deeply the changes
would effect the infrastructure which defines the system, and on which
the stability of the system depends. Every daemon package would be
effected, even if the systemd project had restrained themselves to
working only on the init part of the infrastructure. Every daemon
package needed to be fixed to the new interface, and tested under it.
(Many still need that.)
They didn't, of course they didn't, they've admitted many times that
the init system was not their ultimate target.
Therefore, every package that uses or provides authentication got
entangled in the changes and needed both careful editing and extensive
testing. The testing is still to be completed, because we are not
talking about context-free grammar simplicity here in any of the
Then every tool, package, application, etc., that used the
system-supplied copy/paste buffer got entangled, and, while they were
at it, they decided to try to absorb pretty much the entirety of
Careful re-write, extensive testing. The testing won't be complete yet
by the very nature of where they are changing things.
This all would have been okay for them, if they had followed proper
engineering (management) principles. As long as they were an
independent maverick, they could do what they want. That was correct,
that was good.
For Fedora, where it was first brought into a major distribution, the
proper way to bring it in would have been to break policy and set up a
parallel fork. Keep the damage that necessarily occurs with this kind
of thing restricted to a sub-community willing _and_ _able_ to deal
with the damage by cooperating in the separate bug tracking, triage,
etc. Keep the questions of direction somewhat independent so that the
systemd side and the "legacy" side don't have to be in lock-step on
every tiny detail. Allow separate of source so that regressions and
merges can be safely scheduled and safely carried out. Etc.
If they had done it right from the start, just about now, they would
be ready for beginning the integration process in earnest, which would
mean that about the beginning of this year, when the question came
formally before the committee here, Fedora would have been
implementing their own version of an installer that would allow
choosing the new init system on install.
The systemd folks were too impatient for whatever reason. They pointed
out that Linux itself was not done that way, but their version of
history is most politely described as colored by their desires for
quick success for their project.
"Throw it against the wall and see what sticks!" engineering is only
appropriate for maverick projects. (And it is very appropriate for
maverick projects.) Fedora may be testing for Red Hat, but it is still
mainstream in terms of the number of users and the broad spectrum of
the user base.
So Fedora is not, itself, really ready yet, except for two groups, a
certain group of workstation users who want and are willing to use
fairly new, relatively high-end hardware, including enough RAM and
processors to use VMs for certain things, and a certain group of
server-farm users who want and have budget for similarly recent,
relatively high-end hardware and lots of RAM and processors for lots
The rest of the Fedora users jumped ship.
Now, you who complain that Fedora and Red Hat are off-topic here,
remember that Debian is inheriting the results of Red Hat's work. Work
that did not allow a choice of inits on install, as one example of
where their work is incomplete. That choice was something we still
haven't got quite right yet, after how many months?
Debian set up kfreebsd to deal with these kinds of issues, relative to
replacing the linux kernel with the freebsd kernel. Setting up a
debian-sysd would not have been as extensive a project as setting up
kfreebsd, but would have been similar, because we are basically
pulling in a new layer between the kernel and the rest of the system.
The systemd folks claimed it wouldn't be necessary. If we had looked
at the situation with an unbiased eye, we would have known they were
being overly optimistic. We still turn a blind eye to the problems,
claiming that the only problems are a bunch of recalcitrant
noisemakers like yours-truly.
> It is *the systemd proponents* that wanted this change, so it should be
> *on them* to do the work. Period.