Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site sdcsvax.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!oliveb!hplabs!sdcrdcf!sdcsvax!hutch
From: hutch@sdcsvax.UUCP (Jim Hutchison)
Newsgroups: net.graphics
Subject: Re: V distributed graphics
Message-ID: <1189@sdcsvax.UUCP>
Date: Sun, 10-Nov-85 19:32:40 EST
Article-I.D.: sdcsvax.1189
Posted: Sun Nov 10 19:32:40 1985
Date-Received: Wed, 13-Nov-85 08:29:11 EST
References: <815@wdl1.UUCP>
Reply-To: hutch@sdcsvax.UUCP (Jim Hutchison)
Organization: UCSD EMU Project (Educational Microcomputer Unix)
Lines: 26
Summary: 

In article <815@wdl1.UUCP> jbn jbn@wdl1.UUCP writes:
>
>     The V kernel is a scheme for supporting very intelligent terminals using
>a large host as a master machine.  It's a lot like the support for the Teletype
>5620 in system V; you download editors and graphics packages, but anything big
>is done in the host.  The terminal at Stanford is typically an early-model
>diskless SUN, and the host is typically a VAX running UNIX.  It's a interesting
>idea technically, but the machine it runs on is powerful to act as a
>workstation in its own right, so why bother?
>
>					John Nagle

Because the kernel eats up about 1/2 meg of memory, and the various it
and the daemons eat processor time.  A Real-time Unix (Fert? No, Mert :-),
would solve that, but I don't know if Sun has one, or if you would want
to use it.

As a Intelligent terminal, a sun would not get the trouble you sometimes
experience when you compile something and try to run a large graphics
program at the same time (all in 1/2 meg, yuch!).
-- 
/*
	Jim Hutchison	UUCP:	{dcdwest,ucbvax}!sdcsvax!hutch
			ARPA:	hutch@sdcsvax
  [ Of course, these statements were typed into my terminal while I was away. ]
*/