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. ] */