Subject: Re: Proposed rc.d changes....
To: None <tech-userlevel@netbsd.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: tech-userlevel
Date: 05/07/2000 03:26:07
>> I would not call that a consensus, not by any stretch of the
>> imagination.

> However I think true consensus can only be reached now by the
> minority at least proposing in detail, if not actually offering a
> prototype implementation, of something that meets both their own
> requirements, as well as those requirements met by the current
> implementation.

No.  The onus has historically been on the pro-changer to do this.
That is, this is what the pro-rc.d camp should have come up with before
they were allowed to commit.  I am not going to let you use their
illegitimate (in this sense) commit to shift the burden onto the people
who are trying to get things back to where they should be.

>> I, at least, was saying more like "monolithic rc is significantly
>> easier for *human* boot script maintenance".

>> Like anything involving subjective terms like "easier", that's at
>> least partially a matter of opinion.  Yet in all the flap, I have
>> seen at most one lone message even disagreeing with it.

> Perhaps I am combining memories from more than one forum and I'm not
> sure if you're referring to any message I might have authored, but
> I'm sure there's been more than just anecdotal evidence presented in
> at least some related forum to show that in the long run a monolithic
> startup script is in fact harder to maintain.

Perhaps my memory was being selective.  If I thought it were worth it I
might go back and reread the archives to see, but I don't see any
reason to think it is.

Actually, thinking about it now, I don't think this can actually be
determined either way without making site-specific assumptions.  (A
simple example of such an assumption might be "human tweaks to boot
stuff are less frequent than OS upgrades".  Another might be "at least
25% of the boot script modifications needed cannot be done with the
provided and advertised configuration mechanisms".)

					der Mouse

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