Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!ig!bionet!agate!helios.ee.lbl.gov!nosc!peanuts.nosc.mil!dennis
From: dennis@peanuts.nosc.mil (Dennis Cottel)
Newsgroups: comp.sys.apollo
Subject: Re: /sys/dm/color_map
Message-ID: <1053@nosc.NOSC.MIL>
Date: 26 Apr 89 14:46:46 GMT
References: <8904211745.AA10904@umix.cc.umich.edu> <1196@cs-spool.calgary.UUCP>
Sender: nobody@nosc.NOSC.MIL
Reply-To: dennis@peanuts.nosc.mil.UUCP (Dennis Cottel)
Organization: Naval Ocean Systems Center, San Diego
Lines: 24

Dan Freedman says:

> The solution is to have the vendor *assume* that people are going to
> want to customize the o/s on both a system-wide and on a per-user
> level.  The vendor then provides oodles of hooks that both system
> administrators and users can hook their customizations into.

Exactly.  Another example: make the HELP command search a list of
directories.  A simple change to the program by the vendor, and lots
of ugly configuration tricks could be done away with.

Yet another example: the DPCC installation requires configuration
files to be modified down in /sys/dpcc making them global to the node
and not variable for specific users.  (Unless you make your own links,
but we're discussing a better way.)

Ok, now that I'm worked up: *all* the configuration files for various
products ought to be segregated into a common specific area.  That
way, rebuilding the disk becomes simply reinstalling the product
(binaries and unchangeable data files), and then reloading a single
small backup of this node's specific configuration directory.

	Dennis Cottel  Naval Ocean Systems Center, San Diego, CA  92152
	(619) 553-1645      dennis@nosc.MIL      sdcsvax!noscvax!dennis