Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bionet!ig!ames!pacbell!att!homxb!mtuxo!att!alberta!calgary!cpsc!freedman
From: freedman@cpsc.ucalgary.ca (Dan Freedman)
Newsgroups: comp.sys.apollo
Subject: Re: /sys/dm/color_map
Message-ID: <1196@cs-spool.calgary.UUCP>
Date: 22 Apr 89 18:02:32 GMT
References: <8904211745.AA10904@umix.cc.umich.edu>
Sender: news@calgary.UUCP
Reply-To: freedman@ksi.cpsc.ucalgary.ca.UUCP (Dan Freedman)
Organization: Knowledge Science Lab, U. of Calgary, Calgary, Canada.
Lines: 27

In article <8904211745.AA10904@umix.cc.umich.edu> FERGUSON@TMASL.EXXON.COM writes:
>
>Why not just make the link to people's user_data directories, and
>copy it in to all active accounts then? You can put these files anywhere
>you like, just remember that Apollo software updates don't assume
>anything and you'll need to re-create your changes with every update.


I think you just answered your own question.  Having to re-create
things when the software changes is quite time-consuming.  What makes
it worse, is that it is difficult to tell ahead of time which changes
will need to be re-done after the installation.  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.  This is done already for
some things.  For example, both a system administrator and a user can
hook extra directories into the shell's search paths.  This kind of
flexibility should be extended to all system software.  True, we can
make our modifications and patches, but really, the o/s vendor should
make the software flexible enough so that user's own customizations
can fit in without changes to the o/s.

Dan Freedman
University of Calgary Computer Science Department
2500 University Drive N.W.			      freedman@cpsc.UCalgary.CA
Calgary, Alberta, T2N 1N4	                   ...!alberta!calgary!freedman