On Fri, Oct 09, 1998 at 11:28:54PM -0700, John Nemeth wrote:
> } There's a difference between turning BSD into SysV and importing good ideas
> } from SysV. There are elements of SysV designed for reliable system
>      If everything that a mere handful of people wanted implemented
> was done, then NetBSD would look very much like SysV from a system
> administration viewpoint.

You may dislike SysV based on your experience. I like it based on mine -
which includes not only Unix and NT, but also 15 years as an MVS systems
programmer.

> } 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.

> } system files and those meant to be modified by admins, that I'd like to see
>      SVR4 sure the heck doesn't have this.  Even worse, it spreads
> configuration stuff over a whole bunch of different places, so you
> have to do some serious hunting in order to find and change anything
> (especially if you administrate more then one version, since they have
> a nasty tendency to put the same type of stuff in different places).

find and xargs grep are your friends, if you have a problem with that.
To me, there are two kinds of files in a system: those that are supplied
with the OS, and those that are meant to be modified. When an OS upgrade or
bug fix comes along, and you need to replace some of the system-supplied
files, it's much more difficult and error-prone if you have to go through a
lot of files looking for changes you've made.

> } 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*?

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.

>  The problem that I see is that there is getting to be a whole
> bunch of configuration files.  Re-organizing things and putting all of
> the configuration files in one subdirectory off of /etc would probably
> be a good idea.

Probably so...but drawing a line between what the admin's supposed to go
modify and what the system needs to run properly, and enforcing it strictly,
would also help quite a bit.

>      IN CASE YOU'VE MISSED IT, EVERYTIME I'VE MENTIONED IT IN THE
> PAST, I'VE ADMINISTRATED JUST ABOUT EVERY VERSION OF UNIX, MANY OF
> THEM IN PRODUCTION ENVIRONMENTS.  NIH HAS NOTHING TO DO WITH MY
> ATTITUDE.  I'M VERY FAMAILIAR WITH SVR4 SYSTEM ADMINISTRATION, AND I
> DON'T LIKE IT!!!  HENCE THE REASON I USE A VERSION OF BSD.

Please, no need to shout. We can all hear you fine.

I'm not discounting your experience. Please don't discount mine.