[ On Saturday, March 18, 2000 at 00:09:48 (-0500), der Mouse wrote: ]
> Subject: Re: more work in rc.d [was Re: rc, rc.shutdown proposed change]
>
> This might be a valid argument, EXCEPT that this particular change
> (from monolithic to split-up rc) has been discussed multiple times, and
> ever time, including the most recent, it has generated a very noted
> lack of consensus.

I don't see how true consensus could ever be reached on these issues.
Compromises must be made on both sides.  I think the currently
implemented rc.d scheme has already made several compromises (as can be
shown by looking at some of the criticisms it is already receiving from
advocates of a more SysV-style /etc/rc?.d and /etc/init.d.

> The improved ease of mechanical management comes at a price in ease of
> human management.  To me - and this is where the judgement call comes
> in - the price is greater, much greater, than the benefit.

This human (i.e. me) finds it easier to manage both by hand and by
automation.  I fail to see how even those who baulk against change can
argue that the price they pay is *much* greater when at others find it
easier on all fronts.

> Because the vendor-provided way is never satisfactory out of the box.
> (Not once have I found a system, including any of the free ones, that
> was satisfactory out of the box.  I suspect that on *this* point I am
> very far from alone.)
> 
> That means that it needs modification, anywhere from tweaking to
> massive overhaul.

That argument is totaly useless in this case.  We're not faced with an
isolated and un-repsonsive vendor here -- from what I've seen the new
system is very much pliable within its design constraints and open to
suggestions for improvements.

> Doing that, maintaining it, rolling it forward to new OS revs, all of
> those involve understanding what's there.

This depends very much on how invasive your "overhaul" is.  I suspect
that with the NetBSD rc.d system most people will only change one or two
percent of the various scripts and if even half of those changes are
incorporated into the official distribution there will only be a tiny
number of changes to merge on upgrades.  Of those remaining merges they
will *all* be isolated into specific files and the entire framework
won't require hacking just to get an upgraded system hobbling along
again.

> Split-up rc files are a twisty maze of shell functions and script
> files.  When I want to find out where something happens (necessary to
> figure out enough about how it happens to know how to determine and
> apply the called-for change), I have to grep through dozens of files,
> filter out the false positives, sometimes search through auxiliary
> shell functions, read through scripts that try to do everything for
> everyone and as a result are longer than entire monolithic startup
> files, never mind just the relevant pieces thereof.

I think you're still making a mountain out of a mole-hill....  Once
adequate documentation is available I doubt your concerns will hold
water.

> If you can bring it down to no more than, say, twice the size of the
> old way, in file and line count, I might buy that.

If you take out all of the additional functionality provided, along with
all of the additional comments and blank lines, I think you'll already
be down to less than twice the size of the original....  That's
conjecture of course, but not entirely pulled from thin air as I have
read through all the scripts....

> Add or delete...maybe.  Change, I especially disagree; the amount of
> code you have to understand to change one component is more than the
> amount in the whole thing under the old way.

That's wrong -- all you need to understand is the programming interface
and that can be documented in a few simple paragraphs (and indeed it is
mostly documented now with internal comments in rc.subr).  The scripts
themselves are black boxes that the average admin should never even read.

> > The other issue with maintainability here is the fact that monolithic
> > blobs of code are impossible to localise on a microsopic internal
> > basis (shell scripts or not) without destroying the possibility that
> > they can be automatically upgraded.
> 
> Right.  This is one of the things that makes me feel most secure about
> the old way: because it can't be mecahnically "upgraded", nobody tries,
> which means that I don't have to worry about making sure installing
> something new hasn't nuked a localization somewhere in the rat's-nest
> of shell functions and dotted files.

Some of us, many perhaps, really hate the drudgery of repetitive
sys-admin tasks, especially those involved in upgrading a system.  The
more that these tasks can be simplified, and especially the more that
they can be automated, the better.

To that end it is very important to define system configuration items in
ways that allow them to be modified entirely by locally owned files (the
new rc.conf and rc.local.conf, badly named as they are, as well as the
separation of startup/shutdown actions into separate scripts for each
subsystem are examples of this while things like inetd.conf,
syslog.conf, etc. are *not*) the better.

No matter what you do an upgrade still requires careful comparison of
the old and new systems and if you've done your homework early you'll be
comparing not just the actual files but the three-way differences.

> > Being "*BSD-like" is not, IMO, about the sys-admin crud on top of the
> > system -- it's about the innards and the APIs!
> 
> If all you are is a systems hacker, perhaps.
> 
> I'm a sysadmin too.  It's as a sysadmin that I find this "not BSD".

As a systems hacker who has worked on, and administered, *everything*
from V7 onwards I can assure you that the variances I see in the
administration are definitely not what I would use to define the
heritage of a system.  Those who've had a somewhat narrower view of the
spectrum of unix-like systems over the years are no doubt prone to
defining these distinctions in different ways.

> ...= far more complex, and therefore more likely to bite you in the ass
> at a bad time.  As in, you add something new and rcorder happens to
> juggle the scripts differently, and all of a sudden your startup breaks
> subtly because there's a dependency someone didn't notice and hence
> didn't declare.  And you go nuts trying to find and fix it.

This is no different than trying to get all the lines in the right order
in a monolithic script, or indeed even of getting all the script names
to sort in the right order with a SysV SNN*/KNN* style system.

While it's true that controlling the "rcorder" tool requires looking in
each script and being able to understand state diagrams and dependencies
the additional power and flexibility are, in my considered opinion, a
fair trade-off.

For example there's been great debate over the proper way to make
critical filesystem mounting and network startup work to handle all
contingencies and the consensus usually seems to be that at least with a
monolithic script it is impossible to do without actually hacking the
script.  Though I've not yet seen or attempted an analysis of the new
system with the abilities of "rcorder" I suspect it will allow a lot
more flexibility without requiring script hacking.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>