On Sat, Mar 18, 2000 at 12:09:48AM -0500, der Mouse wrote:
> > It is also important to remember that all other "ground shaking"
> > changes in -current are usually only mentioned after they've been
> > committed in current-users anyway.
> 
> 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.

FWIW, I agree with Mouse here.  I like the new rc.d, and I'm glad to
see it in tree, but I never got the impression from previous discussion
on the subject that it was coming.  In this case, at least some warning
should have been given.

> 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.

I don't believe the difficulty of human management has increased
enough to warrant that statement.

> > If you feel like you're fighting this system then you probably are,
> > but what's important is to ask the question "why?".
> 
> 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.)

It's not appropriate for the vendor-provided way to do absolutely
everything a particular sysadmin would want done on hir box.  What's
important is that it have the hooks in place so that it only needs
to be modified in the places it's supposed to be modified.  I've
never found myself needing to modify /etc/rc, or /etc/netstart.

> That means that it needs modification, anywhere from tweaking to
> massive overhaul.
> 
> Doing that, maintaining it, rolling it forward to new OS revs, all of
> those involve understanding what's there.

I don't acknowledge that the mechanics of /etc/rc.d/*, or even
/etc/rc.subr are all *that* difficult to understand.  Or, at least,
it isn't that difficult to work out the execution path of a
particular init script.  I'll acknowledge that the dependancy tree
might be a little tricky to figure out, but that's an easily
solvable problem with another tool that parses PROVIDE: REQUIRE:
lines, and can display the tree in a human-readable format.

> 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,

All the files are in the same place, and the order is determined by
rcorder.  'grep some_command `rcorder /etc/rc.d/*`' is almost
functionally equivalent to 'grep some_command /etc/rc'.

> 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.

They _need_ to provide for everything, or 3rd parties that need
everything would need to maintain their _own_ _unique_ everythings
for their scripts.  At least by providing everything, you only need
to figure out how it works once, rather than once for every 3rd
party service you install.

> And because of the vendor attitude of "it's just the interface that
> matters" (which as I just explained is not true), this all has to be
> done de novo with the next release.

I don't know what you mean, here...

> > Any other answer will no doubt be better applied to refining the new
> > system than to being used as an argument to kick it out again.
> 
> 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.

File count?  That completely removes the possibility of rc.d.  And
line count basically makes it much more difficult (maybe impossible)
for /etc/rc.d scripts to provide start/stop/restart, &c.  If you
lose both of these, there's no point to rc.d.

> > especially from the point of view of someone who only needs to add,
> > change, or delete one particular component.
> 
> 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.

I disagree entirely.  It all depends on the magnitude of the change.
Maybe all you need to understand is /etc/rc.conf, maybe all you need
to understand is the interface to run_rc_command, maybe all you need
to understand is 'whoops, this script runs "abcd" when we're running
"xyzd" instead'.  That's like arguing you need to know the syscall
interface if you just want to call printf() from your code.

> *Only* a factor of 3.84 (lines) or 25 (files) larger?

If you remove the
#!/bin/sh

# PROVIDE:
# REQUIRE:

. /etc/rc.subr
. /etc/rc.conf

preamble, I doubt the 'lines' count will be that much greater.  The
'files' count buys you granularity that was simply *impossible* to
get before.

> When it's doing
> only some two-plus times as much (startup, shutdown, and
> restart=shutdown+startup)?

It does startup, shutdown, and restart much more reliably, through
the check_pidfile/check_process functions.  It also has status and
reload, neither of which are useful at bootup or shutdown, but
which can be very useful when the system is running.

> > 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.

So, that the *possibility* of mechanical upgrade exists is a drawback?

> >> There didn't used to *be* any repetitive details - or at least no
> >> more than any repeated if clause is repetitive, and if that's
> >> repetitive, so is much of what is even now present in rc.d/*, like
> >> dotting rc.subr and rc.conf, assigning to command and name, etc.
> 
> > Please don't try to count sourcing files containing shared components
> > as "repetitive" in that sense.  That's mis-direction of the worst
> > kind.
> 
> I'm not claiming that the reptition is of the code in rc.subr or
> rc.conf.  I'm comparing "if [ -x ...]; then ... fi" with ".
> /etc/rc.subr; . /etc/rc.conf", pointing out that if the former is
> considered repetitive then the latter must also be.

Then it's just as repetitive.  Glad we agree. :-)

--aidan