Thor Lancelot Simon writes, re: Hesiod should be in libc:
#: 
#: I would love to hear what the justification for a bletcherous, horrible,
#: wrong, insecure, and just plain stupid piece of cruft like YP to be in libc
#: is, if Hesiod doesn't qualify.
#: 

Probably by simple virtue that not everyone uses Hesiod, but *everyone*
uses NIS (YP).

Even NIS+ hasn't taken off as well as Sun had hoped.

If the linker weren't smart enough to only integrate the right parts
of libc, I'd say we should split the YP/NIS stuff off into libyp.a or
whatever, but most compilers I know of are smart enough only to grab what
one needs and link that in to the resulting executable (assuming static
here).  nm will show this.  (I thought the entire libc would be integrated
into the program regardless at one point in time past, but maybe my memory
is more brain-damaged than the history of ld...)

Anywho, outside of generating a larger library (and that not by all that
much, if you think about it), what's the problem with stuffing NIS into
libc, bletcherous/wrong/insecure/stupid/crufty notwithstanding? :-)

I think I just answered my own question and I keep wanting to say, "so
let's move the NIS stuff into libyp" but I keep coming back to the answer
that NIS is just more firmly entrenched than any other Network Information
Database, along with BIND.  Unfortunately, BIND by itself has not
(historically) served any other kinds of necessary information such as
passwd, group, etc.  Had it done so from the outset, we probably would not
see the abomination of NIS today.

				--*greywolf;



#: Thor
#: