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

>> Easier to manage?  [...]
> You've agreed several times now to the fact that automated management
> is now at least possible

Well...more possible.

> and clearly that makes the overall management of the system much
> easier too

No, it is not "clearly".

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.

> (at least if you buy the premise that once you've automated some part
> of a larger task then the entire task becomes that much easier to
> perform).

Other things being equal, yes...but that's not the case here.

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

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.

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.

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.

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

>> More maintainable?  Certainly not by me.  Even on the reasonably
>> objective merit of sheer size, [...669&3 vs 2569&75...]
> There's a heck of a lot more to maintainability than just counting
> lines of code.  The new system is, in my *opinion* thats based on
> many years of experience, much easier to understand,

And in mine, based on many years of experience, harder.  As I said,
widely divided opinions.

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

> Indeed given the additional functionality that's presented by the new
> system I would have to say that it's rather elegant and one could in
> fact be pleasantly surprised at the relatively small increase in
> lines of code!

*Only* a factor of 3.84 (lines) or 25 (files) larger?  When it's doing
only some two-plus times as much (startup, shutdown, and
restart=shutdown+startup)?  Perhaps that's your idea of relatively
small.  It's not mine.

Oh, and I just noticed I forgot to include rcorder's source code.

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

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

> The *BSD crowd, when I was not de facto a member, always seemed to be
> so caught up in the innards of their systems that they never paid
> enough attention to making the system administration tasks
> "production quality".

Of course not.  They were doing a research system, and while as you
point out research and production are not entirely incompatible, this
is one point where you can't have it both ways, so of course they
picked the one that was better for humans who go grubbing around in
anything and everything.

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

> [...] and of course the far more flexible dependency controls [...]

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

No thanks.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B