Subject: RE: /etc/rc.d stuff
To: 'tech-userlevel@netbsd.org' <tech-userlevel@netbsd.org>
From: Jones, Carrie (Bowen) <carrie.jones@anchorgaming.com>
List: tech-userlevel
Date: 03/15/2000 09:11:49
I've only recently begun reading this mailing, so please forgive me any
mistakes of the technical nature.
I do feel that I need to add a datapoint here though.

I dislike the mucking about that is happening here. I dislike it for many
reasons, and I hope that their enumeration will bring on some constructive
discussion.

1. I work with FreeBSD and have NetBSD on my home computers. I can applaud
the idea of keeping the BSD's closer together, but taking this step seems to
me like jumping off the cliff with all the rest of the lemmings.

2. The trend seems to be taking NetBSD closer and closer to a System 5ish
sort of run level thingie. (Sorry for the modifiers, but I'm not technically
proficient enough to point out where in the code I'm getting this feeling.)
I realize that Linux is having a huge influence on the community, but I feel
that "giving into" the linux communities demand for systems to be more like
Linux is somehow wrong. I also work on a regular basis with a few of the
system 5 flavors and believe me, we don't want to go there.

3. I also have seen a huge amount of negative feedback from the community. I
have been reading other mailing lists of netbsd for approx. 3-4 years, and
I've never seen this kind of out and out bad reaction (I know, it's not that
long, but this has been rather extreme.) And what disturbs me most is not
just the negative reaction, but the response to it. The feel of the response
has been to the users who wrote in and said they didn't like it was: Tough.
You are being a sissy for not wanting to learn the nifty new way that we are
providing you. We know what is best and we obviously know more than you, so
sit back, learn how to use it, and get on with your lives, you are too set
in your ways anyway.
(I realize that this may not have been the intent of the replies, but as an
observer with a less than clear picture of this issue, that's what it
sounded like to me.)

I realize that I'm not knowledgeable enough to comment on the technical
specs of this disscussion, and I'm sure that there are good reasons for what
is being done, but in the email flying back and forth, I see no disscussion
of the advantages, and much disscussion of the disadvantages. If someone
would like to quietly explain to me (off mailing list of course if it's
going to be incredibly long) why this is thought to be such a good thing,
please, by all means do so!

But I (as a simple user) do *not* like these changes. Unless there are
incredibly compelling reasons for them, I would just as soon see them
removed. Sorry if this is hurtful to those who have spent so much time and
effort on them. I do appreciate the extra effort, but I think that it was
misdirected.

My .02$, appologies if it was just so much noise.

Carrie Jones
carrie@cjones.org




>get into *that* discussion! ;-) should override it in some way. That
>implies that some sort of configurable $RC_PATH (and support for its use

Sounds like a good idea.

>the scripts directly, but from some sort of wrapper instead? (eg "rcrun
>sendmail stop"))

Another good idea.

>Along similar lines - some people say that they don't like having to
>edit rc.conf to prevent a particular subsystem from running at startup,

Since I was the one that started the rc.conf must die stream, I'll just 
state again - for anyone still reading, that rc.conf is a good idea
for providing default options etc.  What I object to is the YES/NO business.

>and want to just remove the rc.d file to make it not run. Others say
>that removing the file is a pain, because then it's more difficult to
>turn it back on, and they would rather have rc.conf. Doesn't it work to
>just do a chmod -x of the file?  (This might require an extra tweak to
>rcorder to work really well; I'm not sure as I haven't looked at

And this in conjunction with the rcrun idea is, I think a very good
solution.  
Thanks!  I generally install my start/stop script executable so I 
can run them manually, but rcrun foo reload is no big deal, and toggling
the execute bit to signify enable/dissable solves the religious debate 
about link farms as well as the need for YES/NO in rc.conf.

I like it.  Thanks.


--sjg