On Mon, 25 Jan 1999, H.J. Lu wrote:
> >
> > I can very well understand them. First of all some Linux distributors have
> > been creative in the past and have moved rc[0-6].d/ and init.d/ to
> > interesting places like /sbin/ or /etc/rc.d/, probably just to be
> > ``different'' from a real System V. Just one of the small but annoying
> > differences between various UNIX flavours.
>
> Agreed. All the Linux distributors should get together to choose one
> directory for those rc scripts. I really don't care too much it is
> exactly the same as Solaris. But I prefer something under /etc. RedHat
> uses /etc/rc.d and Debian uses /etc. /etc/rc.d makes things easier to
> control.
I certainly agree that init scripts should live under /etc as well.
There is no point in being different unless there is an overwhelming
technical advantage to be gained thereof. The layout of the init
sequence is clearly NOT one of these cases.
> > I actually don't like the pile of symlinks that a SysV Init usually has
> > quite messy; a text file for the configuration or maybe one per package to
> > make things easier for package managers would have easier to manipulate.
> >
>
> Symlinks may be a little messy. But it does provide support for run level
> very nicely. A single text file or one per package is very bad. Since there
> may be dependencies among packages, we have to start them in certain
> order and new packages may be installed at any time. Symlinks works quite
> well here. It is very convenient for packages with rc scripts. I really
> appreciate that feature while working on knfsd.
There are several points to consider there. First, yes symlinks
simplify administration of packages or init segments. However, the
price one pays is that hand administration becomes MUCH more complex.
It is extremely easy to have just two or three boot/init scripts that
are executed in a certain order and add or remove a call by hand. SunOS
and Slackware follow that paradigm and both were trivial to manage IF
you know Unix and /bin/sh well.
The more layers of indirection one introduces, the harder hand edits
become. This is especially true when the tools designed to manipulate
the links and indirect scripts start getting cluttered with clever ideas
that simplify one task but aren't documented and can only be figured out
by reading the entire script and looking in two or three places. For
example, setting variables used in a startup script in /etc/sysconf/*
and then running the sttart/stop scripts from /etc/rc.d/init.d/* with
symlinks from /etc/rc.d/rc*.d isn't all that easy to follow -- by hand.
Adding a daemon to be started at some particular runlevel (one that
ISN'T already installed in /etc/rc.d/init.d) is a good example of a task
that is much harder than it should be and completely unsupported by any
kind of tool in e.g. Red Hat, but that is of course straightforward in
Slackware.
For my part, I can (and have) learned four or five different init
layouts over the last fifteen years or so, each with its "virtues" and
vices. I really wish only that everybody would cease being religious
about it and recognize a few key facts:
a) If one is going to build a GUI to front-end the administration
process, it doesn't make a damn bit of difference which layout is used.
A sufficiently smart tool could automate administration of daemons or
whatever in any layout, hiding the details from the user. That's what
programming is for -- to do the complex work once so that what remains
is simple. True, some layouts make the GUIFE programmer's job easier,
some harder, but the same basic tasks can be accomplished for ANY
layout.
b) Given a), the thing that should really determine the layout is
human (NOT GUI!) manageability. As in, I don't care which paradigm one
ends up with as long as I can go in and manage it easily and
reproducibly by hand in the not unlikely even that the GUI is "broken"
or unable to do some critical task (like add a daemon NOT already in the
boot sequence to the boot sequence). This is a matter of minimizing
redirection and indirection, careful documentation, and provision of
templates. It really argues against using symlinks and multiple, widely
separated directories unless one gains a significant advantage
therefrom.
c) I will grant that package management is such a possible
"significant advantage", but if so it should be arranged NOT to hide the
details from the administrator, but rather to organize them so that
hand-management is easy. Really, this will facilitate the development
of GUI tools and package managers as well -- jobs that are easy to
accomplish in an organized way by hand are usually the easiest to code
as well.
d) Finally, when coding these front ends and the like, ONLY SCRIPTING
LANGUAGES SHOULD BE USED. This is because scripts are self-documenting
and easily fixed when broken. Sorry, Red Hat -- rpm should not be a
binary, nor is there any possible reason that it should be (except that
as a script it would undoubtedly morph to a smarter, better form far
faster than the binary ever will). It drove me nuts when Sun converted
their system install programs from scripts which I could read into
binaries. It irritated me so much that I reverse engineered their
binaries and replaced them with scripts. Of course I had to, because
the binaries were broken if you didn't do things exactly the way Sun
"wanted you to" and who did? Nowadays, with tools like tkperl routinely
available (facilitating the simple creation of a single tool that shares
the core perl code to run on a command line, termcap-driven xterm
window, or full Tk GUI window) there is really no sane reason to do
systems management with "proprietary" binaries.
rgb
(More than 2c worth, I know, but these are very strong opinions with
many, many years of experience behind them. Drives me nuts when folks
confuse religious issues like layout with functional issues like "can I
manage it with a GUI". Heck, one could boot init from ONE SINGLE
monolithic rc script with a command line argument for runlevel and it
would work just fine and be probably even easier to either hand-edit or
runlevel-manage with a GUI than any of the paradigms we have today.)
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]
