Subject: Re: rc.d
To: None <tech-userlevel@netbsd.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: tech-userlevel
Date: 03/17/2000 17:34:23
>> There has been no response that I can see.

> There have been considerable substantive responses so far.  Since the
> opponents of the change are just repeating themselves, there's really
> no point in repeating the responses.

Except that what's going on is that when we (me, greywolf, etc) say
"but this change breaks foo!", the responses we see are either "deal"
or "it does bar!".  Neither of which addresses the breakage of foo.

And most particularly, I have seen no responses, substantive or
otherwise, to the point that the change was rammed through without even
a vague approximation to consensus, without even so much as "we're
sorry had to do this, here's why".  It's been just "this is the way it
will be. deal".

Regardless of what the change under consideration is, that sort of
attitude is a major problem.

> The primary advantage of an rc.d-style system is that it enables
> fail-safe addition and deletion of daemons and other boot-time
> activities as part of packages.

*Mechanical* addition and deletion etc.  And I'm not sure I'd go so far
as to call it fail-safe, just somewhat less failure-prone.

Yes, it provides that.  I don't think any of the monolithic-rc
proponents have tried to argue it doesn't.  I'm fairly sure I haven't.

> Some of the more vocal opponents of rc.d seem to prefer that we
> continue to require that people hack their /etc/rc.local file by hand
> whenever they want to add services.

They seem to prefer that because those are the color of the glasses
with which you're reading what they're writing.  In a sense it's even
true.  What you don't seem to be seeing is *why* they want that.  It
seems to me that it's more like "your way loses this other thing that
we consider more important; yes it'd be nice to have that mechanical
ease, but losing this other thing is too high a price".  That's
certainly *my* position.

> I'd rather put my effort into improving NetBSD rather than
> administering my growing herd of netbsd boxes.

So would I.  And that's why I don't want split-up rc, because in *my*
experience, a split-up rc makes administration a stressful,
frustrating, and time-consuming experience instead of a smooth,
pleasant, and quick one.

					der Mouse

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