On Sun, 2 Apr 2000 erh@nimenees.com wrote:

# [Note: rearranged a bit, and paragraph headings because I seem to
# have rambled on a bit.  I feel that all I said is worth saying though.
# (well, of course I do, I wrote it. :) )]
# 
# On Sat, Apr 01, 2000 at 09:13:25PM -0800, Greywolf wrote:
# > 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.
# 	I agree on this point.
# 
# > 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
# 	and I agree here.
# 
# > 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.
# 
# > 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.
# 
# 	However, I have to disagree on the idea of reverting to back to
# a monolithic /etc/rc.  (although, you of course are free to setup whatever
# repository you want)

No, not "reverting".  "Preserving".  More what I'm aiming for is the
splinter crowd that feels a bit abandoned by the rc->rc.d move and
probably even more so by the rc.conf split.  I'm not necessarily
saying that _everyone must run this way_.  I just wish it possible for
those who desire to do so.

# [enable/disable util:]
# 	The enable/disable script seems like it is irrelevant to the
# basic operation of this system because it is not necessary.  The default
# method of operation is the single config file modified using vi, emacs,... .
# 	Sure, it might be nice to have a util that can allow a configurable
# subset of users to change the configuration on certain commands, but I
# have a feeling that this is just asking for a bunch of security problems.

Splitting up security access among individuals is asking for that same
bunch of problems.  Get a competent sysadmin and stop dicking with
splintered access.

# [show default config util:]

Makes sense.

# [exit status dependancies:]
# 	Finally, the direction I think would be really cool for the rc.d
# scheme to move in is eventually allowing later scripts to depend on the
# actual exit status of what they depend on instead of just the
# PROVIDE/REQUIRE lines.

Makes LOTS of sense!

# [monolithic conversion scripts:]
# 	One great benefit of the rc.d scheme is that it is more flexible
# than the previous monolithic /etc/rc.  If you really want to see a single
# script that runs at startup it is fairly easy to convert from /etc/rc.d to
# /etc/rc.  You could even set things up so this happens as the first
# thing in the startup sequence (or perhaps the last in the shutdown) so
# you always have an up to date /etc/rc even if the contents of rc.d changes.
# This wouldn't be too hard even with the exit status dependencies.
# 
# 	If you really want a single rc and rc.conf I urge you to implement
# a method somewhat similar to this instead of creating a NetBSD micro fragment.
# There doesn't seem to be much sense in dividing our efforts on two completely
# disjoint configuration methods when the features of both can be easily done.

Your suggestion is noted.  I'll see if I can satisfy both ends,
to a degree.

# eric

				--*greywolf;
--
BSD: More Nines.