>> Because the vendor-provided way is never satisfactory out of the
>> box.  [...]
> It's not appropriate for the vendor-provided way to do absolutely
> everything a particular sysadmin would want done on hir box.

Oh, certainly.  I don't expect the system to be satisfactory straight
out of the box.  That was introductory to my next paragraph.

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

With NetBSD, neither have I, at least not since clear_tmp went into
rc.conf.

But if I "upgrade" to an rc.d system, I have 2600+ lines of boot script
I have to comprehend, instead of under 700, to determine whether all I
want can be done by whatever configuration mechanisms are provided.

Repeat for every new rev.  (Granted, diff can help - but the same is
equally true of the single-file way.)

I don't need that.  But NetBSD seems to think I do.

> I don't acknowledge that the mechanics of /etc/rc.d/*, or even
> /etc/rc.subr are all *that* difficult to understand.

They probably aren't.  But I'm quite sure they're more difficult to
understand than the old scripts.

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

I don't.  If I want to make a change, I have to understand most of the
startup system to be sure the change isn't going to produce some other
effect I don't want, or interact badly with something else.

Perhaps *you* are content just frobbing one thing that looks promising
and hoping it does what you want and only what you want.  *I*'m not.

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

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

Yes.  Not a critical one, perhaps, but a drawback.  I don't trust
programs that try to mess with my system's configuration; I've seen
them go wrong, very wrong, far too often.

					der Mouse

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