On Sat, Apr 01, 2000 at 09:13:25PM -0800, Greywolf wrote:
> Sigh.  Luke, you know, I appreciate the effort that's going in here, but
> splitting out rc.conf into a bunch of little files makes it a huge pain
> in the patella when trying to configure the box.  Never mind the cute
> little script that will be required to enable/disable "features"
> as needed.  Not being able to read a single config file to determine
> what is running on the system is really detrimental both in terms
> of functionality as well as, yes, what makes this BSD.  We are going
> to be the platform that is the duck-billed platypus instead of the duck.

I must vociferously dissent.

You like having one big file you can edit to configure the system. I don't.
I see it as one big fragile way to guarantee the system is as easy to keep
from bringing up as possible. There *MUST* be a way to make the system as
robust as possible *EVEN IN THE FACE OF MISCONFIGURATION*. If you screw up a
monolithic rc, or a monolithic rc.conf, you're *FSCKED*. If you mess up a
script that's part of a series of scripts that bring up the system, you're
much more likely to be able to bring it up anyway and fix the problem, and
even to restore the broken service without a further outage.

Put simply, do we want the system to join the 90s? Or do we want to keep
looing like v7? People are using BSD to provide real production services to
real people, and in that kind of environment, hardening the system against
admin screwups is a Seriously Good Thing.

> As soon as I get DSL going, I'm going to set up a repository, if I can,
> which will contain a preserved old-world-mode rc scheme.  This will be
> available for _and maintained by_ the people who determine that a monolithic
> rc, a monolithic rc.conf or both are preferable to the nightmare that
> a split-up rc.conf will be.

Fine. Just don't make it the standard config. The split rc.d is a step - or
sefveral steps - forward.

> You may consider this a strong vote against any further fragmentation
> of the RC configuration.  I don't think it's a practical move.  There
> has GOT to be a better way of handling this without going the way of,
> say, IRIX.

You may consider this a strong vote for making and keeping the system as
maintainable and robust as possible, and rc.d is the Right Way to get there.

> What's next, are we going to resort to a SAM-like interface from AIX?

People maintain systems every day without resorting to that kid of
interface...in the Real World. You know, where admins are overworked and
underpaid, and screw up from time to time.

> How much further isolated from how the OS works will we get?

How much more reliable and stable and robust can we make the system?