Hey, here's the message I was about to send out when I lost it over
Perry's comments.  I apologize for losing my cool, that is unprofessional.
It tends to happen every time I get into one of these arguments.
I think it is sort of like drinking, some people can't handle it.
Maybe I can't handle these arguments, so in the future, feel free to
prune me from the cc list and we'll all be happier.

I didn't really mean to attack Perry.  I did, and do, mean to be very
unhappy with kernel engineers that don't understand the benefits of
making things small and fast.  As a kernel engineer that constantly
meets with customers, is constantly working on performance (lmbench is
a side effect of my job, in no way is it my job), I am always screwed
by the stuff that people check into the kernel without thinking about it.

If you were in my shoes, or in the shoes of any other kernel engineer
in any other major Unix vendor, you would be singing the same tune.
*BSD may be small and fast now - wait a while.  They'll bloat up.
I'm concentrating my efforts on Linux because I depend on Linux.
If the *BSD community wants to think about these issues, that's fine.
If they don't, that's fine.    

I think that the bummer here is that David was trying to explain to the
BSD folks how he made stuff go fast.  In hopes that the BSD folks could
pick it up as well, given that they haven't seen the Linux light (big :-)
He was really saying "Hey, check this out, here's some engineering I think
is cool and I'd like you guys to think it is cool too or tell me how to
make it better".  Instead of getting "Thanks, we'll look at that" he gets
"you're stupid, you are wasting your time".  That's the bummer.

------- Start of forwarded message -------
Date: Wed, 23 Oct 1996 22:25:34 -0700 (PDT)
From: lm@neteng.engr.sgi.com (Larry McVoy)
To: "David S. Miller" <davem@caip.rutgers.edu>
Subject: Re: But why?

Hey folks,
	A couple of points.

	. This argument is stupid.  We are all relatively bright people with
	  similar goals.  We should be helping each other rather than eating
	  up each other's time with silly arguments (and this one is way past
	  silly).

	. lmbench was held up as a micro benchmark and labeled as useless.
	  Rest assured that at the point that lmbench becomes useless, I 
	  will be the first to throw it in the trash heap.  My goal with 
	  lmbench was to focus OS development on the areas that I, in my
	  career, have found to be hot spots.  It is a fact of life that 
	  these hot spots change.  I'll evolve lmbench (as I have time) to
	  reflect the latest and greatest.  If I can't do that, then lmbench
	  will quickly become useless.  My goal is for it to be helpful, if
	  you have real suggestions as to how to make it measure things that
	  you see as useful, let me know.

	. Micro optimization if bad, or so I'm told.  I disagree, from
	  an OS point of view.	The goal of an OS organization should be
	  to provide the features people want at zero cost, at infinite
	  reliability, and at performance levels that are as fast as
	  the hardware can go.	You'll never get there, obviously.
	  But I'm damn proud of the work that David and Linus and Alan
	  (et al) have done to strive towards that goal.  If you think
	  there is no point, that's fine, nobody is asking you to spend
	  your time doing the same thing.  I think there is more than
	  enough evidence to justify this work, so please acknowledge a
	  job well done, it is what you would expect people to do for you.

Finally, let us remember that we are not enemies.  We are friends, believe
it or not.  That crap from Redmond is the enemy.
- ---
Larry McVoy     lm@sgi.com     http://reality.sgi.com/lm     (415) 933-1804
------- End of forwarded message -------