Subject: Re: Updating /etc...
To: Rob Healey <rhealey@altair.helios.mn.org>
From: Greg Hudson <ghudson@mit.edu>
List: current-users
Date: 12/19/1995 22:51:32
>	Have you worked at a large UNIX site?

Yes, but MIT as a Unix site is so large that local filesystems aren't
terribly interesting to us, so my life generally doesn't involve the
problems you're describing.  Nevertheless, I think you're confusing
several issues with each other.

>	1: pkg* allows clean installation and removal of packages without
>	   having to scour a multigig filesystem tree looking for remnants
>	   or worrying some init file has been missed causing lockup or
>	   worse on reboot.

/etc/init.d is not the same as pkg*.  I have no objections to a
package utility (although the ones I've seen generally assume that the
local filesystem is interesting, and are thus useless in the MIT
environment).

Suppose you had a real configuration file (not a script in a
Turing-complete language) specifying the order of system startup tasks
(not necessarily by the order of the lines that appear in the file).
The package utility could have primitives for editing the file.  This
would be easier to understand, wouldn't involve symlinks, wouldn't
involve an extra directory, and wouldn't make life any harder on
third-party software than the System V approach.

I ask once more: what's so special about symlinks in directories that
makes life better?

>	2: /etc/init.d provide's ONE place where you have to look for
>	   scripts that start/stop each subsystem. It doesn't require
>	   careful examination of a HUGE rc.local file to try and find the
>	   pieces you need to comment out or alter or manually type in to
>	   start/stop a subsystem/package. Each script tells you what you
>	   need to know to start/stop a subsystem.

I'm not arguing for /etc/rc.local, since I don't think system
configuration should generally be done in shell scripts.  I'm arguing
against the ideas that:

	* It's acceptable to design a subsystem such that you need a
	  script to start it up and shut it down.

	  (I will admit that there is no obvious, standard way to shut
	  down subsystems as things stand.  "A script in /etc" doesn't
	  strike me as the best standard to introduce, since "a way to
	  shutdown subsystems" has nothing to do with "configuration
	  files".)

	* Alphebetized symlinks in a directory are a somehow superior
	  way to specify the ordering of system startup tasks.

> For personal systems it's convieniant to have /etc/init.d and pkg*,
> for large sites it's a neccesity.

For large sites it's necessary that the system be simple and
well-documented, both in terms of how the system works and in terms of
how easy it is to do the tasks that need to be performed.  I think the
startup systems of BSD and SVR4 both fail miserably by this measure,
and I'd prefer if people not lock themselves into an either-or
mentality when considering solution so this problem.