Xref: utzoo comp.windows.news:330 comp.unix.wizards:6689
Path: utzoo!utgpu!water!watmath!clyde!ima!necntc!encore!pierson
From: pierson@encore.UUCP (Dan Pierson)
Newsgroups: comp.windows.news,comp.unix.wizards
Subject: Re: Use of select in NeWS.
Summary: It's not an evil Sun plot
Message-ID: <2712@encore.UUCP>
Date: 25 Feb 88 16:03:26 GMT
References: <1376@vaxb.calgary.UUCP> <3189@bloom-beacon.MIT.EDU> <20164@bu-cs.BU.EDU> <7171@agate.BERKELEY.EDU>
Reply-To: pierson@encore.UUCP (Dan Pierson)
Organization: Encore Computer Corp, Marlboro, MA
Lines: 27

In article <7171@agate.BERKELEY.EDU> chapman@eris.UUCP (Brent Chapman) writes:
>Well, Sun _does_ have two different versions of NeWS, according to the
>instructors from Sun at the NeWS tutorial at the Phoenix USENIX last
>summer.  There's the fast, tuned, Sun-only version that is what Sun
>distributes binaries from, then there is the slower, portable version
>that they will sell source for to other vendors.

This does make some sense.  A Sun explained it at a NeWS tutorial last
fall, the fast, tuned, Sun-only version is fast and tuned because it's
built on top of SunWindows primitives which are neither portable nor
available in source form to competitors.  The slower, portable version
only requires a Sun frame buffer.  

It certainly makes a lot of engineering sense for Sun to want to reuse
their existing technology in a Sun-only product.  It also make sense for
them not to spend a lot of time and money creating a high-performance
portable *sample* server.  After all, there is not much point in using
the slow, sample server on a Sun when the fast server is available and
cheap.  A highly optimized sample Sun server might be *less* useful to
porters than the existing sample because the optimizations would
probably add a good deal of non-portable complexity to the server code.

-- 

In real life: Dan Pierson, Encore Computer Corporation, Research
UUCP: {talcott,linus,necis,decvax,ihnp4}!encore!pierson
Internet: pierson@multimax.arpa