:: Re: [DNG] Lead BusyBox developer on…
Top Page
Delete this message
Reply to this message
Author: Rainer Weikusat
Date:  
To: dng
Subject: Re: [DNG] Lead BusyBox developer on sysvinit
Didier Kryn <kryn@???> writes:
> Le 18/02/2016 12:37, Rainer Weikusat a écrit :
>> I mean that "Do you trust this code! It had at least one bug!" is a
>> silly statement.
>     I didn't read the same thing as you.

>
>     I read more trust is needed in pid1 than in any other program. I
> also read one cannot trust a program just because it's decades-old and
> widely used, which is something people sometimes admit only as a
> theoretical possiblity. Dennys pointed a real case.

>
>     Hence the argument already exposed by several persons on this
> list, in particular Laurent: let's pid1 do *only* what no other
> program can do.


That's a theoretical argument I agree with: I think the server/ service
management code shouldn't be part of init especially since it's
virtually unused but that's really a tiny addition to the process
starting code which more-or-less has to exist, anyway.

OTOH, I've been maintaining a sysvinit fork as part of my job for some
years (I keep adding features to, last one completed yesterday) and
certainly don't lose any sleep over 'trusting' this code despite I'm
somewhat familiar with it: I suspect that many people who are
(unspecifically) 'offended' by that suffer from a bad case of "But
that's not how I would have done it!" disease as it's written in a more
traditional UNIX(*) style which has gone thoroughly out of fashion more
than a decade ago.

When I encountered that for the first time (in the netkit FTP daemon
around the turn of the century) it surely offended me: "OMG! What's that!!
This must all be done completely differently!!!". But the reality is
that - while I knew how to write code by then - I was totally clueless
about anything except code written by myself, it's just that nobody
cared about my "I'm student and I tell you THIS ..." preciousnesses. I
hope to have progressed to "not entirely clueless" meanwhile :-).