2014/10/08 6:07 "Andrei POPESCU" <andreimpopescu@gmail.com>:
>
> On Ma, 07 oct 14, 12:00:57, Steve Litt wrote:
> >
> >https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708
> >
> > Read ^H^H^H^H skim the thread. Notice how, in the first 10 posts, after
> > insisting that alternate inits be part of the discussion, a guy named
> > Thorsten Glaser was ordered not to bring up alternate inits in the
>
> That doesn't match my memory of the entire debate, care to refresh my
> memory with a reference?
Well, I'll tell you, Andrei. I was raised on the idea that KISS is never an optional principle in engineering, and more especially to be strictly observed when working with anything that has to respond to real-world events in some pre-determined amount of time.
Perhaps that point of view colors my interpretation of the conversation in a way different from the way you read or watched it.
> > thread again. Again and again, the conversation is steered into the
> > most limiting set of alternatives, often trampling on those who say
> > "wait a minute, let's consider other things."
>
> As far as I recall OpenRC was indeed deemed unsuitable quite early, but
> this was done on technical grounds (not ready, lack of documentation,
> lack of features, etc.).
Lack of documentation is one kind of technical ground, I suppose, but it is a completely different topic from deterministic execution paths.
Lack of features is not a defect in a pid 1 process. If the traditional sysv inherited inits have issues, pid 1 being too simple is not one of the problems.
A good engineer can read code. No amount of engineering magic can read the execution of a pid 1 process that is chasing its tail trying to parse an error state. Pid 1 should never see anything more than three options to an event -- kill, pass it on, or ignore -- and the decision chain should have as few steps as possible, preferably less than three. Otherwise, and it doesn't matter how many processors you have going how fast, you are going to see the system freeze at odd times, punt at odd times, and fail to enforce at odd times, among other issues.
And these will be the quiet kind of errors where data gets corrupted and is lost and no one is aware of the corruption until months later, when you really need the data but there is no way to go back and re-build it. Months and data corruption if you're lucky, backdoors never discovered if you aren't.
All the fuss about race conditions, all the fuss about logging, the steady absorption of daemons, like cron, that should be separate, etc., all of these are not features. They are symptoms of the failure to keep it simple and avoid trying to make it too smart.
If openrc was not ready because of documentation, how can systemd ever be considered ready until pid 1 is stripped down to the bare minimum? Greater than 1M is two orders of magnitude beyond too big.
Does that help you see what Steve and others interpret as railroading?
Joel Rees
Computer memory is just fancy paper,
CPUs just fancy pens.
All is a stream of text
flowing from the past into the future.