Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Alan McKinnon]

On 24/02/2014 01:12, Mick wrote:
> On Sunday 23 Feb 2014 22:32:32 Alan McKinnon wrote:
>> On 23/02/2014 20:18, Canek Peláez Valdés wrote:
>>> I don't think forking would attract much developers. Writing something
>>> new trying to follow "the*nix design principles", but being modern and
>>> with the same features (all of them optional, of course) of systemd
>>> will have more chances; although I think it will fail because most of
>>> the people that can code "better" actually like the systemd design,
>>> and would prefer to contribute to it.
>>>
>>> And if you found enough of this mythical good-coders, good luck
>>> defining what it means "the*nix design principles".
>>
>> I've been wondering about this concept of "the*nix design principles"...
>
> Well, I'm no authority on this since I can't code, but here's a starter for
> 10:
>
>   http://www.faqs.org/docs/artu/ch01s06.html
>
>   http://people.fas.harvard.edu/~lib113/reference/unix/co-unix4.html

I really like documents like this, all airy-fairy and giving the
impression that the whole design was worked out nicely in advance. It
wasn't. the doc even quotes this fellow who had nothing to do with the
doc itself:

"Those who don't understand UNIX are doomed to reinvent it, poorly."
--Henry Spencer

Let me tell you how Unix was designed, how the whole thing took shape
once K&R had gotten C pretty much stabilized. It is most apparent in IO
error handling in early designs and it goes like this:

We don't do error handling. We don't even try and deal with it at the
point it occurred, we just chuck it back up the stack, essentially
giving them message "stuff it, I'm not dealing with this. You called me,
you fix it."

Doesn't sound like good design does it? Sounds more like do whatever you
think you can get away with. Good design in this area gives you
something conceptually along the lines of try...catch...finally (with
possibly some work done to avoid throwing another exception in the
finally). Unix error "design" does this:

exit <some arb number>
and an error message is in $@ if you feel like looking for it

Strangely, this approach is exactly why Unix took off and got such
widespread adoption throughout the 70s. An engineer will understand that
a well-thought out design that is theoretically correct requires an
underlying design that is consistent. In the 70s, hardware consistency
was a joke - every installation was different. Consistent error handling
would severely limit the arches this new OS could run on. By taking a
"Stuff it, you deal with it coz I'm not!" approach, the handling was
fobbed off to a higher layer that was a) not really able to deal with it
and b) at least in a position to try *something*.

By ripping out the theoretical correctness aspects, devs were left with
something that actually could compile and run. You had to bolt on your
own fancy bits to make it reliable but eventually over time these things
too stabilized into a consistent pattern (mostly by hardware vendors
going bankrupt and their stuff leaving the playing field)

And so we come to what "Unix design" probably really is:

"You do what you have to to get the job done, the simpler the better,
but I'm not *really* gonna hold you to that."

I still don't like what Lennart has done with this project, but I also
fail to see what design principle he has violated.



-- 
Alan McKinnon
alan.mckinnon@×××××.com