Subject: Re: Updating /etc...
To: Chris G Demetriou <Chris_G_Demetriou@BALVENIE.PDL.CS.CMU.EDU>
From: Scott Reynolds <scottr@Plexus.COM>
List: current-users
Date: 12/22/1995 13:11:46
On Thu, 21 Dec 1995, Chris G Demetriou wrote:

> my
> NetBSD boxes have _no_ modifications to /etc/rc, from the base
> distribution.

Unfortunately, mine do, to deal with network issues.  It is already 
painful enough on our HP-UX machines to deal with things like IP changes 
as machines move from building to building, and only somewhat better on 
NetBSD.  The bulk of the improvement of NetBSD over HP-UX is that there 
is *one* file to tweak things in and *one* place to find out what I need to 
do to start or modify various subsystems.  (Some other subsystems 
obviously use data from /etc/netstart, which in my mind is one of the 
biggest problems with NetBSD right now.)

> Why _make_ people modify the existing files to add something new
> to their system configuration?  it makes them need to understand them,
> it makes upgrading harder.

Understanding a single 6K script (which, incidentally, contains about 3K 
of actual shell script, the rest being comments) is not difficult.

> I dunno, i think i'd like them to all be seperate files.
> lets me go into init.d, throw away AFS _really_ easily.  8-)

It's really easy to throw away a large number of things right now; 'rm 
-rf /var/yp' comes to mind, for example.

On the other hand:  _something_ probably ought be done about having
network configuration information scattered around into various files and
scripts.  Some sort of net.conf file is really starting to sound like a
Very Good Idea, and for obvious reasons having some sort of rc.d/init.d
structure for installing 3rd-party subsystems will benefit NetBSD as well. 

It would seem that the benefits of moving the current rc functionality
into a bunch of separate scripts are only marginal at best for the
overwhelming majority of software packages available, though.  Starting
daemons, syncing/recovering database transactions, and the like could
easily be taken care of by this 'package' startup mechanism after the
operating system services have been started.  These are applications that
the Real World wants to use in a turnkey system; things like Kerberos and
AFS, while useful, are relatively limited in deployment. 

Like Matt Green said, if we're going to change things, let's change them 
because there is a clear advantage in general.


PS - I'm a few hours away from being gone until the new year, and this is 
likely to be the last thing I'll say on the subject.  Consider it to be 
my contribution to killing the thread. :-)