> [T]his is entirely about making a better system that's more flexible,
> more reliable, easier to manage, and more maintainable.  In all of
> those senses it is a step forward (and a big leap forward on some
> fronts!).

More opinion being stated as fact.  I think I've been careful to keep
my opinions marked as opinions; please do me the courtesy of doing
likewise.  (If I've slipped up on this, please call me on it.)

It most certainly is not a step forward in any of those areas for me,
with the possible exception of more flexible, on which point I reserve
judgement until I've actually had time to sit down and look at it in
detail.  Having used split-up OSes in the past, I doubt the additional
flexibility, if any, is anywhere near worth the cost.

More reliable?  It's new code, therefore almost axiomatically buggier.
There's more of it -> almost axiomatically buggier.  It involves more
steps -> more pieces that can break -> almost axiomatically buggier.

Easier to manage?  This is entirely a judgement call by the individual
sysadmin.  As I said, I've used monolithic systems and I've used
split-up systems, and on the latter I constantly find myself feeling
I'm fighting the system, rather than working with it.  (One could argue
that it's not the split-up nature of the scripts but the particular
implementation thereof.  In theory this could turn out to be
correct...and in theory, I could inherit six million dollars tomorrow.)

More maintainable?  Certainly not by me.  Even on the reasonably
objective merit of sheer size, "wc /etc/rc" on my monolithic (pre-rc.d)
system is 473 lines.  "wc rc.d/*" in src/etc in my supped-to-current
tree reports 2086 lines.  337 of those are in rc.d/network, it's true -
but pre-rc.d netstart is only 181 lines.  That you can sit there and
with a straight face try to claim that over two thousand lines spread
over 74 files is more maintainable than 654 lines in two files is
utterly astonishing to me.  (There is an rc.subr in the pre-rc.d
system.  It's all of 15 lines long.  If you want to count it in, things
get even worse: 669 lines in three files, versus 2569 lines in 75.)

>> like having to grok a complicated set of shell functions in order to
>> have a clue what's going on (and in particular what I need to do to
>> get some desired effect).
> If you're talking about what's in /etc/rc.subr, well first off I
> don't find it all that complicated, and it's well documented
> internally to boot.

Sanity check time.  As I said above, my monolithic rc file is 473
lines.  rc.subr *alone* is 483.

In short, however (un)complicated you may find it, it's a hell of a lot
more complicated than what we had before.

> I think that once the overall API is well enough documented in more
> obvious and traditional places there'll be no need to even peek at
> the underlying framework

Ah yes, once again "you don't need to care about that, it just works,
trust us".  I'll thank you to stop trying to tell me what I do and
don't need to know about my systems!

> Obviously all the lower level details are repetitive anyway so why do
> you want to see them in full all of the time?

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.

>> The resulting script is almost as much of a maintenance nightmare as
>> the original split-up files were.
> Well of course!  So, if you treat the result as an opaque blob much
> as if it was a binary executable then you'll not be tempted to try
> and maintain it as a single entity.  Edit the components as source
> and "compile" the monolithic script if that's what you feel you have
> to do....

You have managed to so completely miss the point of my wanting a
monolithic script that I wonder if it's even worth attempting to
explain it again.

Editing rc.d/* and "compiling" them into a monolithic rc file has all
the problems that I see in split-up rc files to start with, plus some
additional ones of its own.  (I once mentioned that the only benefit of
catting everything together is no need to grep around to see where
something is started.  If you have to edit the individual file rather
than the catted-together file, even that benefit is largely lost.)

Being in a single file, per se, is not what I like about a monolithic
rc script.  What I like is the comprehensibility and maintainability
benefits that result.  A few of them are because everything is in a
single file; many more of them are because everything is simple and
straightforward (at least as compared to the split-up way).

And besides all that, this is debating the proposal on purely its own
merits, and as I've remarked in other messagse, much of my outrage
derives not from what was done but from how it was done.  (Not all; I
still don't like rc.d regardless.)

					der Mouse

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