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

[Mark David Dumlao]

On Mon, Feb 24, 2014 at 9:07 AM, Alan McKinnon <alan.mckinnon@×××××.com> wrote:
> 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."
>

*slow clap*

-- 
This email is:    [ ] actionable   [ ] fyi        [x] social
Response needed:  [ ] yes          [ ] up to you  [x] no
Time-sensitive:   [ ] immediate    [ ] soon       [x] none