On 1 May 1999, Michael Graff wrote:
> Allen Briggs <briggs@ninthwonder.com> writes:

> > These two arguments are mutually exclusive and the source philosophies
> > seem to be at the root of most of the most flambastic (I like making up
> > words ;-) arguments that we've grown accustomed to.  To reduce them to
> > silliness...
> > 	"NetBSD doesn't run on my toaster, so it's not ready for the
> > 	 general public at all."
> > 	"Since NetBSD 1.4 runs much better for Mr. X, it's ready for
> > 	 release even if some platforms are lagging."
> 
> Or, how about:  ``Some ports don't have USB busses, therefore no port
> should.''  Or beter yet, ``some machines are diskless, therefore all
> disk support should be removed.''

I don't feel that those extremes reflect the intended meaning of my
analogy.  Certainly we hope to support each of the port architectures to
their fullest potential.  All of the architectures have their differences,
and those differences shouldn't be ignored or neglected to meet some
artifical common denominator.  But in cases where there are commonalities,
isn't it best to support them as uniformly as possible?  NetBSD's
extensive use of machine independent layers is a testament to this
ideology.  It's good software design (something which is obscenely rare
these days).

In the NetBSD family of supported systems there are alpha, pmax, and vax
workstations which have turbochannel busses.  Does it make sense to write
TC bus support into the kernel which only addresses the requirements of
alpha and pmax, but not the vax?  Or does it make more sense to write it
in such a way that all three architectures can make use of it?  Sure,
maybe it's more of a pain to distill the code across these platforms into
something uniform, but isn't it still "the right thing" to do?

My prejudice against CVSup perhaps isn't very practical.  I've stated
oh... 3 or 4 times now, that I certainly have no issues with its
functionality or its technical merits.  It will usefully serve the vast
majority of NetBSD users, and I see no fault in the service it may offer.  
My bias is only grounded in the fact that, fundamentally, there is no good
reason why CVSup couldn't run on all of the NetBSD platforms.  There's
nothing inherent to any of the ports which prevents the functionality
CVSup offers.

My bias against it is only in that CVSup exists in a form which makes it
more difficult to propagate across all NetBSD platforms, or for that
matter, all Unix platforms.  I don't believe there was any deliberate
intent on the part of the CVSup developers to do this.  But at the same
time, they weren't thinking in the same terms which I'm accustomed to
seeing from most of the NetBSD developers.

This argument is long tired, but I don't see it as pointless.  I'll
refrain from saying anything more on the subject beyond my opinion that...
If someone is intending to write a good piece of software, it's best to do
"the right thing" and implement it in a way which maximizes the number of
systems which can benefit from it.

-brian.
---
Brian "JARAI" Chase | http://world.std.com/~bdc/ | VAXZilla LIVES!!!