On Oct 10,  5:45pm, Jay Maynard wrote:
} On Fri, Oct 09, 1998 at 11:28:54PM -0700, John Nemeth wrote:
} 
} > } administration in a production environment, with clear boundaries between
} >      I operate a bunch of machines, including several based on SVR4,
} > in production environments.  I find the SVR4 machines to be a royal
} > pain in the neck.
} 
} I've got long experience in production environments too. I find NetBSD, as
} it stands, to be difficult to maintain due to the complete lack of
} delineation between what is intended to be modified and what's not: in
} NetBSD, _everything_'s intended to be modified.

     This is a good thing and a bad thing.  I do see your point.  But,
NetBSD is getting a lot better in this regard.  Look at the
/etc/*.conf files.  I think those are a great idea.  They maintain the
BSD flavour, yet help to delineate the boundary between user and
system stuff.  I think it is a lot cleaner then the SysV way of doing
things; I don't consider renaming/removing symbolic links or having to
hunt all over the system a gazillion different configuration files to
be the proper way to configure a system.  BTW, even with commercial
OS'es, personally, I feel that everything is up for grabs.  Of course,
I don't go changing things willy nilly (that would make a maintenance
nightmare), only things that are necessary.  But, if it's broken, or
doesn't work to my statisfaction, I'll change it.

} > } in BSD. In the face of NIH attitudes like this, why bother implementing it?
} >      Yes, it is a good idea, if implemented half decently.  But, SVR4
} > sure the heck doesn't have it.  NetBSD 1.3's /etc/rc.conf and
} > /etc/{daily,weekly,monthly}.conf are steps in that direction.  There
} > are very few "system" files in NetBSD that the user needs to modify
} > now.
} 
} You mean like /etc/ttytabs? or /etc/rc*?

     I'm not sure what you're getting at here.

} The NetBSD mechanisms for startup configuration are either inflexible or
} require modification of system files. If you want to add something at other
} than the places that hooks are provided, then you're back to modifying
} system files. The SysV mechanism, OTOH, is both flexible and maintainable.

     What you just said about NetBSD goes for SysV as well.  There may
be more hooks in SysV, but they aren't everywhere.

}-- End of excerpt from Jay Maynard