Subject: Re: Posible virc(8) implementation
To: Miles Nordin <carton@Ivy.NET>
From: Greywolf <greywolf@starwolf.com>
List: current-users
Date: 05/03/2000 22:45:37
On Wed, 3 May 2000, Miles Nordin wrote:
# Here's my real question: the purpose of rc.conf.d is to permit heavy-fisted
# editing by the pkg system. Under your plan, 'virc -s' guarantees a successful
# unattended merge of these changes into the rc.conf text file. bsd.pkg.mk
# will presumably call 'virc -s' immediately after a heavy-fisted change.
Again. This should be configurable. Who is making the god damned decision
without user input on this one?
This is really irritating. rc.d solves a problem. rc.conf.d attempts to
solve a problem that does not truly exist, because, unlike rc/rc.d,
rc.conf DOESN'T NEED ORDERING! It's a bunch of variables, folks.
Scatter-gather I/O a la virc is a non-solution to a NON-PROBLEM!
# I thought about this proposed virc scheme and wrote a much longer earlier
# draft email about it, but the main points now seem to be:
#
# o it sounds really cool.
# o it sounds like it does everything it needs to.
# o it sounds like it does a lot more than it needs to, for foolish
# linguistic and political reasons.
You have the last one correct. You forgot one:
o it needs to be configurable as to where it intends to get the values
for the resources.
Please, please, please PLEASE (^NaN_INF), implementors, make this something
of an OPTION. I *hated* IRIX's way of splitting all this sh!t out, as I'm
sure many others did (why are we here, etc.). This needs to be implemented
in a FLEXIBLE manner as opposed to the less friendly approach taken with
rc.d.
Please. I'm not trying to gainsay, nor to make enemies (which I think
I'm doing, but reconsider, I beg you!). I am asking for something which
will make sense from the viewpoints of both sides.
That said, I saw something about config information being stuffed into the
rc.d module script itself for a given module. I saw something about that
being the wrong thing to do. I couldn't agree more. Two disparate points
of information is not something that cannot be handled in a more
intelligent manner than the brute force approach (to be polite) which
was given with rc.d.
--*greywolf;
P.S. Anyone want patches for a more aesthetically pleasing rc.d setup?