Xref: utzoo comp.arch:20374 comp.editors:2377 alt.religion.computers:2333 Path: utzoo!utgpu!cs.utexas.edu!sun-barr!lll-winken!uunet!auspex!guy From: guy@auspex.auspex.com (Guy Harris) Newsgroups: comp.arch,comp.editors,alt.religion.computers Subject: Re: Quote from new book Message-ID: <5493@auspex.auspex.com> Date: 24 Jan 91 19:33:50 GMT References: <3349@uc.msc.umn.edu> <21349@oolong.la.locus.com> <1991Jan23.020831.7991@jarvis.csri.toronto.edu> <5490@auspex.auspex.com> Followup-To: alt.religion.computers Organization: Auspex Systems, Santa Clara Lines: 21 Well, there's a bit of an oversimplification there. Remember, there's also Gnot<->disk server traffic, since a Gnot is *(g)not* a Blit; it's a, well, diskless workstation, with a real virtual memory OS (basically the same one as runs on the compute servers) that supports access to a file system. Editors can run, in their entirety, on a Gnot (they can also run, in their entirety, on a compute server, as far as I can tell, but I think they typically run on the Gnot). Since the Gnot won't be running as many applications as a diskless workstation in a more typical workstation/file server configuration, you'll probably have less file access traffic over the network, but the situation isn't identical to that in the Blit/timesharing machine or X-terminal/timesharing machine case. > V9: the kernel where you can do > fgrep */*.[ch] > and not get "Arguments too long". (Well, *one* of the kernels where you can do that, anyway. I've yet to run out of the 1MB of arguments I get with SunOS 4.x, although if you use the C shell, *it* might impose a more stringent restriction.)