Date:        Thu, 16 Mar 2000 20:43:42 -0500 (EST)
    From:        der Mouse  <mouse@Rodents.Montreal.QC.CA>
    Message-ID:  <200003170143.UAA12361@Twig.Rodents.Montreal.QC.CA>

  | 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.

This isn't really true, the two are pretty similar.   In each case either
you just use what is provided, and don't bother about it too much, or you
have to maintain your own alternatives (there aren't many NetBSD systems
around that will be running only a base installed system with nothing added
on at all - though such a system could just possibly totally ignore the
pkg system and do nothing of its own).

A major difference between this system, and Sys V, is that /etc/rc is
maintained, and init still runs /etc/rc when the system boots, and that
controls everything thereafter (as opposed to the mess that is inittab).

If you want a monolith /etc/rc you can do that, and you get to maintain it
for yourself, including upgrading it as necessary, etc.   That's just the
same as if you want your own ssh or bash or emacs, ignoring the pkg versions
of those.  You get to do things in your own way, no real constraints, but
you have to keep on doing that every time you do a system upgrade (unless
you eventually decide it is too much work, and just allow the people building
the systems to do it their way).

You get a clear choice here - either you do things the system way, or you
do things your own way.   The choice that you don't get is to force the
system way to be your way, just because you perfer it, and your life is
easier.

  | 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.

I thought you were complaining about this all not being the BSD way?

What you wrote there was *exactly* the BSD way - find something that looks
to be better (in the opinion of the small group deciding such things),
implement it, and ship it.   That happened over and over again.  How much
discussion do you think there was of the (then) new getty (along with 
gettycrap)?   That one I did, shipped it to Sam Leffler, he fixed a few
bugs, and a couple of weeks later 4.2BSD was being shipped with a totally
different getty than had been there before (including in the beta releases)
(and which amazingly still seems to be the basis of the BSD systems getty
to this day).   But it was exactly as you described it, I thought it was an
improvement, so it was implemented, and then shoved down everyone's throats,
regardless.

How many people do you think it was who decided that the autoconfig code
should get done, and included?

In hindsight now both of those might seem like obvious improvements, but
they were certainly both changes, and (in their different scopes) quite
major ones, and at the time, people who were used to what had been there
before, and found that adequate for their purposes, didn't all like
the changes and would have preferred that they hadn't been made.

If you want a system than responds to market pressures, attempts to
do everything in a way that will suit everyone, and will take a lot of
notice of whether people decide not to run it any more or not, then
Sys V is what you want.

  | The price that it exacts is that it is now significantly harder to do
  | anything outside of the "what the vendor provides" box.

There's some truth in that, though I'm not sure about "significantly".
If you want to add your own stuff, it will be harder than it was before.
On the other hand, if you get something from elsewhere, and just want to
drop it in, it will now be significantly easier -- I've seen the effects
of some systems that attempt to edit /etc/rc and install their startups
and have not been pleased at all (and I have adopted the practice of always
making sure there is an explicit (but hidden) exit at the end of the part of
the script I want to run, to attempt to defeat those rc editing systems
(they'll usually find the "exit 0" that is normally at the end of the
script and insert their noise before that ... but if one adds something
like

	. /etc/done

several lines earlier, where /etc/done is just "exit 0", the scripts
will usually just go and fiddle after that, before the (now irrelevant)
exit 0 that ends the script.

On the balance, I think that far more people just drop things in, and
would prefer not to have to bother learning how it should be done.  And
furthermore, the people who like to just edit rc for themselves, are the
kinds of people who can also manage to live in the new environment fairly
easily (or if they really don't like that, they can replace it).  This
looks to be a clear win.   Further the only arguments against it seem
to me anyway to amount to not much more than "I don't like it" or perhaps
"It will make things a bit more difficult for me", I don't recall seeing
anything at all which amounts to a specific problem, outside the area of
taste.


Before I finish I should state my biases - I have been using (and manually
adding) rudimentary startup script support in NetBSD since I first started
using that, and before that on other systems.   That is, on my (still) 1.3
system you'll find a "runscripts" function in /etc/rc.subr and a couple of
calls to that in /etc/rc (I didn't do all the work to split out all of
/etc/rc into separate scripts, so I needed to be able to run some scripts
early in the boot process, and others later).   In ages past (4.3 on a vax...)
I still had script support, and then needed one almost as the first line in
/etc/rc as I had hardware I had to init before much other stuff was done
(my driver back then didn't load its own microcode into the device the way
drivers seem to do these days - rather it just provided an interface to allow
user code to load the microcode, and then start things running).

So, in general, I think this is a definite step forward, and probably I
regret not pushing for the distribution BSDs to correct this 15 years ago.
(Certainly the BSD distributed rc.local was a total farce).

On the other hand, I don't much like "rc.d" as a name, I'd much prefer
/etc/scripts or something like that.   But that's just a trivial noise
matter, upon which anyone can have an uninformed opinion, and as I didn't
do the work to implement this, I'm not about to complain (well, not too
much anyway) about the names chosen.

kre