Subject: Re: Wow. (Was benchmarks...)
To: None <mouse@Collatz.McRCIM.McGill.EDU>
From: Charles M. Hannum <mycroft@gnu.ai.mit.edu>
List: current-users
Date: 12/05/1994 18:27:19
   > I've spent the last two or so months getting the release out the
   > door, then travelling way too much, then changing cities.  I'm just
   > now getting to "important mail" that was sent to me at the _beginning
   > of october_.

   Might I recommend something like vacation?

Chris already uses vacation(1).  I know I certainly get enough mail
from it.

Maybe I should install it permanently, with something like:

I have many other things to do.  I'll read and reply to your mail when
I get to it.  This may be today, or it may be a year from now.

   >> I added an option for modifying the NFS mount options used when
   >> mounting the root when booting diskless.
   > i didn't see this, either.  however, there's a way to do this as a
   > kernel compile option,

   There is?  I couldn't see any such anywere, so I created a kernel
   config option for it.

I don't know which options you're specifically referring to, but the
diskless code already uses NFSMNT_RESVPORT, and if you use:

options	NFS_BOOT_RWSIZE=1024

will also override the default rsize and wsize.  This could probably
be made more generic.  I haven't seen your code.

   > I can't see why you'd need to make this a kernel option, in any case.

   _Need_ too, perhaps not.

That seems to be the crux of the matter, to me.  You could just as
easily put an echo command in rc.local.  That's what *I* do, on
machines running SunOS.  It is almost *always* inappropriate to add
more kernel options for something you can deal with quite adequately
elsewhere.

   >> I have gotten the feeling that there is no functioning back-channel
   >> for contributing stuff.
   > I think you're just being impatient.  That nobody has gotten around
   > to looking at your code certainly doesn't imply in *any* way that
   > they are slighting you.

   Oh, I assure you, I don't feel singled out.  A few private notes I've
   received and a couple more public ones have indicated I'm not alone in
   my "feeling".  Perhaps it's nothing but a PR problem [that's
   public-relations, not problem-report :-], but there's a problem of some
   sort.

I'm quite convinced that the problem is that people expect more than
they deserve.  Hell; I've seen patches sent to the X Consortium go
unacknowledged for *years*, and then mysteriously appear in a public
patch set later on.  Ditto for GNU software.  It is NOT REASONABLE to
expect prompt, formal, courteous replies to every message.  If you
want that, you HAVE to pay for it.  We don't have the time, and it's
extremely unlikely that any other volunteer organization does either.

Most companies don't even give you direct access to the actual
engineers.  Do you know why that is?  It's because their time is
better spent engineering, not answering questions and having people
flame at them.  And it costs those companies REAL MONEY to have
first-level support people to absorb all the nonsense.

   > If you had sent it with send-pr, then it would show up when I type
   > `query-pr -x -q' on sun-lamp; since you didn't, I had completely
   > swapped it out and probably never would have thought of it again.

   Shall I?

Why do you even need to ask?  I've told people repeatedly to use
send-pr.  It's there for a reason.

   >> I added tickadj to /kern.  Someone (cgd, I think) said it belonged
   >> in sysctl, which I can sort of understand, but can't understand why
   >> that would be cause to be uninterested in having it in kernfs.
   > 1) I already put it in sysctl, but I explicitly did *not* make it
   > writable.

   Then as far as my need goes you might as well not have bothered; the
   reason I put it there was so I could change it at runtime.

You've never justified *why* it's a good idea to patch it at runtime.
Is there some reason you can't change it in param.c?  If the default
is fundamentally wrong, then perhaps it should be changed globally.

   > To put it another way: We disagreed with you.

   To put it another way, _I_ disagreed with _you_.

That's too bad.  If we decide that something you did was wrong, and
that we aren't going to put it in our source tree, then you have no
choice but to live with that decision.  Whining and complaining only
wastes our time (and yours), and makes us less likely to deal nicely
with you in the future.

   > Deal.

   One can hardly term it a "deal" when one party's position is brushed
   aside in favor of the other's.

That was `Deal.' in the sense of `Deal with it.', not in the sense of
`Let's make a deal.'  Regardless of what anyone else would like, we
ARE the final arbiters of what goes in NetBSD.