On Thu, Nov 13, 2014 at 11:04 PM, Tanstaafl <tansta...@libertytrek.org> wrote: > On 11/12/2014 5:18 PM, Andrei POPESCU <andreimpope...@gmail.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 systemd. 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 engineering. 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 parts. 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 inter-process communication. 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 of VMs. 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. -- Joel Rees -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caar43iossr+k-+r-vuji7nsstzd3n6uzomg32j4t+vyxfbg...@mail.gmail.com
