Re: new "sv status" flags and exit-tracking patch, and misc.

[Laurent Bercot <ska-supervision@skarnet.org>]

 I can't address all the points you're raising, but some bits I can answer:


> Why does runit use its own env_get() method rather than getenv()? [This 
> is just one example; there are *lots* of places where C library calls 
> are eschewed in favor of locally-implemented bits].
>
> (...)
> 
> Why define the same error methods and macros at the top of each file (as 
> with fail/failx/warn/warnx/etc)?
> 
> (...)
> 
> Why the huge number of distinct error handling functions and macros with 
> large numbers of parameters instead of just one or two functions using 
> varargs?

 This, my friend, is DJB-style coding. And strange as it may seem to the
profane, it's intentional. :)
 That coding style has its own reasons. All of which are of course
questionable, but at least, asking yourself questions is better than
blindly following a poor standard. If you like runit, then you're already
questioning System V or BSD init ; delving into runit's code is the next
step on the Path to Enlightenment, questioning more of your UNIX habits.
 Take a deep breath, coder, for what thou art about to see may change
your way of thinking forever.

 No, I'm not exaggerating. Well... maybe just a little bit. :)
 Anyway.

 The main points are:

  - when the standard is mediocre, don't follow it. Create a better
standard.

  - libc standards are often mediocre. UNIX is old, and bears the marks
of age (read: compatibility), but back then, good interface design wasn't
a science yet. Example of a deep-rooted legacy interface: stdio.

  - always wonder how something is implemented. Never forget library
overhead; having a nifty does-it-all function call available does not
mean it's a good idea to call it, because it may do way much more than
you need, and be a pain security-wise or performance-wise.

  - libc portability is a myth. When you want portable code, write
portable code, instead of relying on so-called portable functions that
will obscurely break on some architecture in situations you cannot guess
or control. Always play it safe.

 The strerr functions you're talking about are precisely _designed_
to avoid using varargs. The question is not "why not use varargs ?" -
the question is "why would I use varargs when I can do without them ?" :)

 If you want to dive in this "alternatively written software", take a
look at DJB's software, where it all comes from; especially daemontools
(which was the original inspiration for runit) and ucspi-tcp.

 That way of thinking has led to qmail instead of sendmail; djbdns instead
of BIND; tcprules instead of tcp_wrappers; runit instead of System V init;
runwhen instead of cron; ucspi-ssl instead of stunnel; execline instead
of sh (shameless and counterproductive plug here).
 And if nobody has yet come to write a working DJB-style news server to
replace that INN horror, it's because it's a huge amount of painful work
and we all have a life (sort of).

 That was my rant of the year. Time to go back to sleep.

-- 
 Laurent