On Tue, 26 Jan 1999, Dave Mielke wrote:
> I would like to add to this discussion by briefly stating what I think should
> be a major requirement in the design of the "ideal" paradigm. I work for a very
> large telecommunication firm, and have had lots of experience working on very
> large projects in very large environments. Any paradigm which combines code and
> data is easy to look at, and, in a small system, easy to manage. It does not
> scale, however, as the environment, and the corresponding administrative
> complexities grow. It is, in my opinion, essential to have a paradigm in which
> the data is kept strictly separate from the code if one wants to have a system
> which is truly scalable. The ease and reliability of long term maintainability,
> including things like upgrading, are far more important than the apparent
> simplicity of short term hacking and tweaking.
I would generally agree -- it is why we are moving away from Slackware
in a largish, increasingly inhomogeneous, and growing environment.
However, it isn't necessary to have data and code and symlinks strewn
all over the place, either. I could live with a SIMPLE paradigm like:
/etc/rc.d/init.d/network
/etc/rc.d/init.d/network.dat
/etc/rc.d/init.d/named
/etc/rc.d/init.d/named.dat
or
/etc/rc.d/init.d/network
/etc/rc.d/data.d/network
/etc/rc.d/init.d/named
/etc/rc.d/data.d/named
(where the data sources contain variables, but constant definition is
still permitted in the script -- if a constant needs to be varied, move
it over!) that was fairly rigorously adhered to. Script all inline in
the init.d directory (no fair sourcing all over, but perhaps a STANDARD
sourcing of functions only from
/etc/rc.d/functions/network
/etc/rc.d/functions/named
permitted as required). A couple of tools to control the symlinks. A
strongly worded /etc/rc.d/README threatening evisceration of anybody
that gratiuitously breaks discipline and a spanking for writing ugly
/bin/sh code. Finally, a blank TEMPLATE for starting/stoping generic
runtime, non-inetd daemons (like sshd) that can be trivially edited into
/etc/rc.d/init.d/sshd
for example. Surely this is script/tool manageable -- perl or sed or
awk or... can easily parse and edit a simple data file containing
variable definitions. It ought to scale as well or better than RH does
right now. It preserves the use of the SysV init (and the startup
ordering convention already in place for the symlinks). And HUMANS can
read or edit the network or named or whatever scripts as required, OR
can read or edit the network parameters and so forth in the associated
data file without needing days of work -- especially if a required
COMMENT at the head of the startup file lists all variables that are
sourced/set in the data file as they are sourced/set.
I apologize for the length of this thread and I'll quit now. Hopefully
the masters of spaghetti will get the point and decide that now is the
time to untangle the SysV startup so that humans can manage as well as
scripts and tools. I think any BSD afficianados could easily be
convinced to follow a simple ritual to install runtime entities, as long
as the ritual is indeed simple and well documented, and as long as it
doesn't end up requiring immense amounts of time longer than it would to
just hack it into a flatfile rc script. BSD-persons are not insensitive
to the need to scale nor to the desirable features of organization or
packaging, they just hate needless, pointless complexity.
rgb
Robert G. Brown http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567 Fax: 919-660-2525 email:[EMAIL PROTECTED]
