Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!pasteur!ucbvax!hplabs!sdcrdcf!trwrb!desint!geoff
From: geoff@desint.UUCP (Geoff Kuenning)
Newsgroups: comp.windows.misc
Subject: Re: Why I'm suspicious of NeWS
Message-ID: <1679@desint.UUCP>
Date: 15 Feb 88 07:20:08 GMT
References: <1677@desint.UUCP> <3835@megaron.arizona.edu>
Reply-To: geoff@desint.UUCP (Geoff Kuenning)
Organization: Interrupt Technology Corp., Manhattan Beach, CA
Lines: 35

In article <3835@megaron.arizona.edu> Mike Coffin (mike@arizona.edu) writes:

> I don't think programmability  itself is NeWS's biggest feature.

Frankly, I don't care whether programmability is its biggest or its
littlest feature;  I still think it's its biggest drawback.  (But note that
almost all published plaudits about NeWS cite the programmability
as the thing that makes it truly different and thus wonderful.  Actually,
this even extends back to Postscript -- see the "orange book".)

> The important thing is that the designers of
> NeWS realize that the most important constraint on speed in a network
> window system is bandwidth.

Only if (a) you run lots of applications remotely that push lots of
information across the net, and (b) you are running a net that is
current technology.  And don't forget the cost of interpreting NeWS,
as I pointed out in my original posting.  Most published accounts of
NeWS demonstrations that I've seen include a "boy, was it slow" component.

> Presumably context switches within the
> lightweight processes in the NeWS server are much cheaper than
> UNIX-style context switches.

Personally, I think "lightweight processes" are a foolish idea invented
by people who'd like to write their own OS, but aren't in a position to
do so.  "Process switches are expensive on MY hardware/software combination,
so I think I'll invent my on process-switching code."  Very satisfying,
but hardly good computer science.  Much better to spend that energy making
ALL process switches faster, or reducing unneeded process switching.

In the case of UNIX, I firmly believe that the real problem is the lousy
scheduler and swapper, not slow process switching.
-- 
	Geoff Kuenning   geoff@ITcorp.com   {uunet,trwrb}!desint!geoff