On Mon, 25 Jan 1999, H.J. Lu wrote:
> > 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.
>
> Please tell it to FreeBSD folks. They are considering moving toward
> something like what we have. Even some BSD people are realizing the
> BSD init doesn't work that well. SysVInit certainly can use some
> improvements. But the BSD init is not the solution.
>
> BTW, if you do know Unix and /bin/sh well, SysVInit administration is
> not that complex at all. It is much easier than the BSD init. I have
> maintained and installed packages which need rc scripts on both SVR4
> and BSD, I can tell it from my experiences as a maintainer and an
> installer. On the other hand, if you don't know Unix very well,
> SysVInit is easier to deal with.
You miss my point. I'm perfectly happy to see ANY init paradigm
universally adopted, as long as it is easy to understand and manage by
hand (first requirement) and as long as any tools developed to make
management accessible to Dummies (see book series XXXX for Dummies for
the XXXX of your choice) are scripts that can be understood and modified
by hand (second requirement). To drive the init paradigm by the
requirements of management scripts or binaries puts the cart before the
horse. One has but to look at the nightmare of Windows 95/98 system
management to see what kinds of disasters lurk when one is completely
successful in hiding the details of the operating system from the
user/administrator, subordinating what actually needs to be done to the
GUI where folks must do it.
Without going into the question of what SysV and its init sequence and
boot layout "is", as there appear to be Irix and Solaris and Red Hat and
-- many more -- flavors thereof, I agree that SysV's basic paradigm of
symlinks to start/stop scripts under run level rc directories in one
directory space with parameter configuration and script control in
another distinct directory space, once learned, can be managed by hand,
although tediously and painfully, and is fairly easy to manage with
suitable tools. I would argue that it is not as easy to learn or do
quick and dirty management with it as BSD's simpler WSIWYG flatfile
schema. IMHO the simplest tasks are MUCH more complex to accomplish,
although the more complex ones are perhaps a bit easier and certainly
easier to automate or script, making it undeniably more scalable. You
are arguing that scalability should take precedence over the learning
curve or short-term ease of use.
Fine, for the sake of argument I'll concede that this is the
philosophically correct point of view -- scalability can be very
important. I still question whether or not the SysV init schema (at
least as incorporated by Red Hat these days) is the "ideal" that
realizes this philosophy optimally or whether it might be possible to
find a schema that is scalable (tool manageable, if I understand your
criterion) but MORE readily understood and hand managed as well.
To continue with the Slackware vs Red Hat comparison, let us contrast
their network startup. In slackware, this is handled by
/etc/rc.d/rc.inet[1,2], called in that order. These are human readable;
all network variables used (including those set by install scripts) are
set directly in the scripts where they are used. Consequently, the
scripts are trivial to modify by hand and you can read them and see how
they work at a glance. rc.inet1 is really totally trivial and yet
totally effective at starting up a network -- ifconfig, route, done.
rc.inet2 is messier, but still pretty readable and easy to change if you
know /bin/sh at all (and even if you don't).
Now let us meta-analyze the Red Hat/SysV network startup where:
a) mini-scripts for each network function live one place
(/etc/sysconfig/network-scripts/if[down,up]-*);
b) are configured/controlled, per interface in a second and third place
(/etc/sysconfig/network and /etc/sysconfig/network-scripts/ifcfg-eth?);
c) called from a symlink in a fourth place (really many possible fourth
places, /etc/rc.d/rc?.d/network);
d) pointing to a fifth place (/etc/rc.d/init.d/network, the actual
system network startup script?).
If I understand it correctly (yet) myself... oops, looking it over it
looks like I left out /etc/systeconfig/network-scripts/if[up,down]
themselves, which are symlinks to /sbin/ifup and /sbin/ifdown and which
do all kinds of things as well... SOMEWHERE in there I'm sure that
ifconfig and route are called for each interface but who knows where
without looking a rather long time? Who knows how to force one of the
less-commonly used options (one not anticipated by the GUI admin tool)
to be used for a given interface? Probably lots of folks, of course,
but the knowledge wasn't simply won...
Don't get me wrong, I AGREE that there is method in all of this madness.
I can follow (when I try hard enough) what is going on, and can see why
things are broken up the way that they are. However, this is a clear
example of the cart (GUI administration of the boot and network config
and startup process) leading the horse far from the realm where mere
mortals dare tinker with the underlying scripts without many, many hours
of work. Adding a relatively simple daemon (sshd) in the Red Hat/SysV
style took me only a few hours to figure out (as opposed to a few
minutes in Slackware). Adding a new network service (or nontrivially
modifying one that is already there) looks like it would be a fairly
major undertaking.
So, while AGREEING that one common init style would be good, and while
ACCEPTING that it may well be that SysV is, on the whole, more scalable
and disciplined, I cannot help but think that there shouldn't be a
better compromise between BSD flatfiles and SysV startup scripts,
symlinks and config entities that are fragmented and distributed across
what, five or six distinct directory paths (/boot, /etc/sysconfig,
/etc/rc.d, /etc/rc.d/init.d, /sbin) where a variable is set here, a
function defined there, a script that uses these invoked a third (and
fourth, and fifth) place...and then there are the symlinks to follow.
Can't we do better than a ratsnest of code with the file equivalent of
goto's all over the place that no programming instructor would ever be
pleased with in an assignment? Surely this could be simplified and
streamlined to the point where humans could follow it without spending a
week studying it while still retaining the basic SysV concept and a
decent degree of tool-manageability and scalability?
Just a plaintive cry in the wilderness, of course. But Slackware's
continuing popularity in SPITE of the flaws you mention (and more that
you don't) are evidence that simplicity and hands-on manageability is
appealing to many of us.
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]
