Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!usc!apple!mips!sony.com!dce
From: dce@sony.com (David Elliott)
Newsgroups: comp.sys.mips
Subject: Re: /usr/lib/sendmail.smtp
Message-ID: <1989Nov9.155527.22468@sony.com>
Date: 9 Nov 89 15:55:27 GMT
References: <1989Nov9.052724.21405@sony.com> <1000@uakari.primate.wisc.edu>
Reply-To: dce@icky.Sony.COM (David Elliott)
Distribution: na
Organization: Sony Microsystems Corp.
Lines: 29

In article <1000@uakari.primate.wisc.edu> bin@primate.wisc.edu writes:
>This business of munging through /etc/hosts nightly is a hack, too.  There's
>a cron script that puts a link in /usr/hosts for *EVERY SINGLE NAME* in
>/etc/hosts, so if your host file is any size at all (mine is, even though I
>use BIND) you end up with this huge directory full of links you'll never
>use more than a fraction of a percent of.

Well, you can't blame MIPS for providing this.  Take a look on any BSD
system and you'll find /usr/hosts/MAKEHOSTS, which does basically the
same thing.  On unmodified systems, it will actually create entries
for ucbarpa and ucbvax.

MIPS simply provides the service so that when you change your hosts
file, /usr/hosts gets updated.  If you don't want the service, you
can easily shut it off:

	touch /usr/adm/periodic/daily/10.makehosts.system.stop

In fact, the whole point of the periodic stuff is that a set of
services can be provided to help the general user ("Why doesn't
/usr/hosts get fixed when I add new hosts?"), but can be shut off
without causing problems when doing system updates (how many
systems require you to scavenge through the system, backing up
files you changed, just to do an update?).
-- 
David Elliott
dce@sony.com | ...!{uunet,mips}!sonyusa!dce
(408)944-4073
"You can lead a robot to water, but you can not make him compute."