At 09:04 PM 12/27/00 -0500, Todd Vierling wrote:
>I presume you aren't blaming NetBSD's incarnation here?  After all, our rc.d
>is not like the other systems at all:  it has been spcifically designed with
>the lessons learned from the previous methods in mind.

I haven't used it enough to decide if it succeeds where the others fail. 
However, the entire "rc.d" concept is based on the flawed (IMHO of course) 
assumption that a file system based database is ever adequate. Now the RC 
system "expressed" as a file system and based on a database? That might 
have some possibilities. But the problem that one is trying to solve is the 
one alluded to earlier:

         "How can I customize the initialization and shutdown phases
          of system operation in such a way that all dependencies
          are accounted for and attempts to violate assertions of the
          modules are disallowed?"

And to solve this problem you need a vocabulary that can express 
interdependencies, transient relationships, and rules of invariance. The 
file system with its hierarchical names and symbolic links is not 
expressive enough to capture these attributes and hence applications to 
manipulate the same are overly complex and prone to failure.

That said, I don't like or dislike the current rc.d/ system, I only share 
my observations with others that it places an excessive burden on less 
powerful compute platforms. Is that burden to much? Certainly that is a 
subjective question which can only be answered subjectively. Is that burden 
sufficient to prevent adoption of 1.5 on some platforms, the answer is 
clearly yes to that question.

--Chuck