> The things I find distasteful are, unfortunately, largely cosmetic,
> so my complaints are, for technical purposes, unjustified.

Part of my problem with the direction NetBSD is taking is that it seems
that the only acceptable objection to anything is a technical one.

Perhaps that's the direction _NetBSD_ wants to go.  It's not the
direction _I_ want to go.  "Feel" is important - critical, almost - to
me, nontechnical as it is.

> The objection I perceive is that the ones who want to tinker are not
> the ones whose changes are being incorporated, which I'm not sure is
> at all true.

Well, the objection *I* have is that the changes - rc.d is the poster
child for this - make the system a great deal less pleasant for me.

> I'm also not convinced that the system has truly become any less
> suited to tinkering.

Well, as I wrote last spring, I've run rc.d-style systems, and
invariably end up feeling that they're designed to get in my way rather
than designed to work with me - that they're designed for "drop the cd
in the drive and click install" modifications, which is fine, except
that that's not the sort of modification I'm doing.

> The things I see that NetBSD has right now that I like:

> 1.  FFS.

Check.

> 2.  Despite objections, I *like* the fact that we can adapt to
>     interoperability with other operating systems.

Mostly, so do I, though for me it's more a Cool Feature than something
that I actually use; since I don't run software I don't have source to,
I have little use for binary compatability.  (I may someday have
occasion to set up a wipe-when-done machine for some special purpose.)

> 3.  ...exactly _how_ many platforms have we been successfully ported
>     to, now?

This is easily NetBSD's strongest point, to me.  I'm trying to collect
instances of as many different ports as I can.  I'm running /sparc,
/sun3, /i386, /macppc, and /mac68k routinely.  I've got /vax and
/next68k running, though they're dead at the moment because they're
diskless (see the "nfsd: locking botch" thread).  Once the hardware I
have on order arrives, I'll have /alpha too.

And /usr/src is identical on all.  So is /local/src.

> The other requirement in my mind is that we properly address *why*
> we'd do it this way.  "We're doing it to attract more users."  I'm
> sorry, but thanks for playing.  If it is technically sound to do so
> and it *happens* to attract more users, okay, but that should not be
> our primary motivator.

I agree.  Unfortunately, it seems - to me, at least - that that *is*
NetBSD's primary motivator.  I still can't see anything else behind the
rc.d disasater, for example.

> I may want [ACLs] someday, and that's the kind of attitude I take to
> most of the stuff that's happened:  "It may prove useful to me
> someday.  Until that day, I'll compile it out of the kernel."

I think this is why rc.d is the really sore point it is with me: it
*wasn't* made optional.  I can't install a new box, set some flag
somewhere, and have my comfortable, streamlined, and (most critically)
human-editable rc scripts back.

> And as one who's seen the innards of both BSD and SVRx, I must say,
> BSD did the better job.

Happy as I am to hear this, it really makes no difference to me until
SVRx goes open-source. :-)

					der Mouse

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