Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!mitech!gjc From: gjc@mitech.com Newsgroups: comp.windows.x Subject: Re: A tirade about inefficient software & systems Message-ID: <6172@mitech.com> Date: 2 Nov 90 10:25:07 GMT References: <1534@svin02.info.win.tue.nl> <1990Oct31.014133.14048@athena.mit.edu> Organization: Mitech Corporation, Concord MA Lines: 37 In article , tjo@its.bt.co.uk (Tim Oldham) writes: > CS 101: Network Window Systems > > I'd be extremely interested in hearing peoples' views on this. I personally > think that X is seen as far too much as a panacea for Unix HCI, and it > worries me that X has been seized upon as a ``standard'' with little > thought for the implications in terms of hardware and networking costs. > The fact that I hear people from Sun tell me ``Our implementation of > Open Look is great --- but you need 16 Meg in your SPARCstation'' alarms > me. The fact that a 68030 isn't enough CPU for a single user of an X GUI > under V.4 alarms me. My humble observations: X applications can generally perform better and with less CPU load than comparable applications in other window systems I have used extensively: APOLLO, LISPMACHINE, VMS-UIS/VWS. Quite possibly X is not as drop-dead "efficient" as directly writing to the machine registers of a IBM-PC style VGA or EGA board. The 68030 CPU is plenty CPU for a single user of an X GUI application. Perhaps the application you have in mind is a memory hog or your machine has too little free memory? Even the lowly VAXSTATION-2000 does pretty well with VMS DECWINDOWS when the machine has sufficient memory. ***-------MEMORY--------*** That seems to be the real issue of late. Seriously. This is across the entire field of computer science and engineering. You even have things like the source to XTERM aproaching or exceding the size of significant modules of a program like Macsyma. (Irony: People still think of programs like Macsyma as "large" and "unwieldy". Of course one reason for this is the piss-poor state of the art of commercial lisp implementations currently, especially on the other great panacea of our time, RISC machines). But I digress... -gjc