Subject: Re: rc.d
To: None <tech-userlevel@netbsd.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: tech-userlevel
Date: 03/16/2000 20:43:42
>> Recently (= approximately this past year), it seems, someone has
>> decided that a larger user base is a sufficiently good thing to be
>> worth dropping the niche people for, and this has resulted in things
>> like the package system and /etc/rc.d,

> You know, actually, I consider myself to be something of an OS
> hacker/ hardcore admin type.

> But I *like* the pkg system.

I have nothing against the package system, except possibly that it's
draining off developer cycles that could go to IMO-better uses - though
developer cycles are not a fungible commodity, doubly so for a
volunteer project.

You see, the package system has the property that if you don't like it,
you can ignore it and it will never bother you.

/etc/rc.d doesn't.

> But after my system is skrogged to the point that all I can do is
> nod, smile, wave and upgrade, the ability to use the pkg system to
> restore my system to a stable state (for prog in $list; do (cd $prog;
> make && make install); done) and then just walk away from it to come
> back after work, well, that's just cool.

Yes.  Having something of the sort is valuable.  I have something of
the sort, developed independently of the package system.  I have no
problems with packages; the one fear I had about them has, so far,
proven unfounded.

> I'm not entirely sure of the rc.d business, just yet, actually.  If
> it looks too much like sysV or Linux, well, yes, I'm going to be
> somewhat bitter about it.

I'm not especially bitter about what was done, not yet (I haven't
"upgraded" to an rc.d OS, yet).  I'm much more concerned about how it
was done.

The subject of split-up startup scripts has been brought up on the
lists multiple times.  Every time, it produces many opinions, widely
disparate and strongly held.

Yet this time, rather than taking from that the lesson that has been
taken the other times - that no such scheme has enough consensus behind
it to succeed - someone decided to go ahead and ram it down everyone's
throat regardless.

*That* is what *really* bothers me: the Project telling me (and others
who, like me, don't like the new way) "we know better than you do
what's a step forward; here's what you're going to use".  This, much
more than the mere fact of having split-up boot scripts, is what I've
been referring to when I've written of my feelings that the Project has
just decided to give me and my needs the finger.

> On the other hand [...], I have written more than one instantiation
> of a script which could be used to stop/start individual processes.

I've written such support myself, on occasion.

I use it when I judge it is appropriate, and don't when I don't.

NetBSD is no longer giving me that choice.  If I want anything but this
brave new startup system, I have to roll it completely alone.

Worse, this slap in the face leaves me with far less certainty that I
will like - or even be able to tolerate - any *other* change the
Project may decide to impose on its OS's users without discussion, or
(as in this case) in the face of much dissension.

> For people who _don't_ have that much time on their hands, for
> example.  I think I'm getting this.  I don't think it's an
> intentional slight toward the hackers as much as it's making it
> easier to start the system up.

Starting up a stock system has never been the least bit difficult.

And this does make it easier to mechanically add stuff to the startup
sequence.

The price that it exacts is that it is now significantly harder to do
anything outside of the "what the vendor provides" box.  If I didn't
mind being restricted to what some vendor thinks I need, I'd be running
a commercial vendor OS - and getting full support for all my hardware,
instead of having to hack on drivers myself.

*That* is the sense in which it is a slight towards the hacker types,
the sense in which I feel the Project is kicking sand in my face.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B