> From jonathan@DSG.Stanford.EDU Sat Dec 21 16:04:35 1996
> 
> Unacceptably poor network-stack performance, when compared to the
> alternatives.   Any serious STREAMS-baseed UNIX vendors special-case
> TCP/IP into non-STREAMS code.   The  performance of STREAMS
> 
> If you have to ask why STREAMS are slow, then that reflects poorly
> on the basis of your technical judgement that NetBSD should switch
> to using STREAMS.
>

Simply because some company has a poor implementation doesn't imply
the architectural model is bad. Just a poor implementation.

> 
> I beleive the NetBSD project works like this: if you want to advocate
> a change, then it's up to *you* to justify the change.  In constrast,
> Brad is advocating a change and expecting everyone *else* to justfy
> the satus quo.  Moreover, Brad's justification for this change is (by
> his own standards) without "technical details": all we have from Brad
> is "appearance factor".
> 

I'm NOT advocating we switch NetBSD to STREAMS. All I'm saying is that
I've found STREAMS to be a very valuable model for handling data from
devices into a user application. Someone else could propose a different
model to solve our problems with multiplexors, data movements, ttys,
and etc... Hopefully we could decide a better model based upon
experience and comments.

As for the issue of me advocating a change, I'm just getting tired of
hearing the mantra that STREAMS is bad because of "appearance". I've
worked on STREAMS on several different vendors platforms and found it
to be a good working model. Vendors implement it differently but that's
an implementation detail not a architectural issue.

And I'm not trying to start a holy war. But, trying to show that from
my experience using STREAMS, I've just found it to be better than
people say it is. I'm perfectly open to other ideas, whether they be
Mach, Project Flux, The Alewife Project or what not.

For now on, I'll just keep my mouth shut and sit in the corner..

-brad w.