At 10:28 PM 12/27/00 -0600, Jay Maynard wrote:
>This is a simple design tradeoff, of the kind computer systems designers
>make daily.

Exactly.

>In general, if you can trade something for code that's executed
>once, it's a good trade.

This is one way of analyzing the trade-off.

>  How often do you boot a system? Yes, that
>varies...but what are we trying to build here, a playtoy, or a
>production-quality OS that you can depend on to be there when others are
>crashing around our ears?

Well to give you a "real life" example rather than a contrived one, I was 
the chief architect at a company called FreeGate. We built (and now Tut 
builds) an all in one Internet appliance using FreeBSD as the core OS 
(choice made before NetBSD was "real"). As the router/firewall, reboot time 
was a priority for us because during a reboot our customer wouldn't have 
access to the Internet. We spent a good three months tuning the system to 
boot in less than a minute. Here the cost of a slow reboot speed 
(regardless of how often it was done) was a problem. The generality did not 
apply.

>  There's a reason the one system I run that others
>depend on day-in and day-out is a NetBSD box. I'll put up with the BSDisms
>(my fingers are hardwired to do "ps -ef", and it drives me nuts) to get a
>real, live, production-quality system. Anything that improves system
>reliability and serviceability is a Good THing in my book. It should be, in
>the judgment of the designers, as well - or else we're just building a toy.

Clearly I disagree that one should imply a system that focuses on reboot 
speed should somehow be less robust or more toy like than one that does 
not. The issue as you correctly ascertain is what metric did the "system 
designers" use to make the tradeoff. One of NetBSD's tenets is that it runs 
on a "wide variety of platforms" and this is true, but making the rc.d/ 
choice has artificially cut off some platforms that it might otherwise run 
on so it directly contravenes that stated design goal.

If you want to make the argument that robustness is a stronger design 
principle than wide scale applicability then the logical extension of that 
argument is to focus exclusively on exactly one platform with one set of 
hardware. One can clearly maximize robustness in that way.

I've been designing systems for over 20 years now and the longer I do it 
the more I realize how much there is to learn. And as I mentioned earlier 
the design decision to go with rc.d was made and it limited NetBSD's 
applicability, is the choice worth it? I don't know, perhaps it is, would 
someone who is on the core developer list care to comment? Does it matter? 
Probably not.

--Chuck