Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!rice!sun-spots-request From: tacitus!clh@uunet.uu.net (Chris Hermansen) Newsgroups: comp.sys.sun Subject: Re: Setting up a Sparcstation lab. Keywords: Miscellaneous Message-ID: <3897@brazos.Rice.edu> Date: 9 Dec 89 20:34:43 GMT Sender: news@rice.edu Organization: Sun-Spots Lines: 73 Approved: Sun-Spots@rice.edu X-Refs: Original: v8n166, Replies: v8n192 v8n194 v8n198 v8n206 v8n211 v8n217 X-Sun-Spots-Digest: Volume 8, Issue 223, message 2 of 14 In article <3269@brazos.Rice.edu> chris@com2serv.c2s.mn.org (Chris Johnson) writes: >X-Sun-Spots-Digest: Volume 8, Issue 206, message 4 of 15 > >>It seems to me that 12 is a bad compromise. Either you limp along with 8 >>or you go whole-hog for 16. The German Sun Users' group electronic >>mailing list had a discussion about xview News/X and memory; 12M wasn't >>quite enough. The consensus was that future SunOS releases are going to >>want 16M in a compiling environment and at least 12 MIPS. > >Did this (and similar articles) strike anyone like it hit me? I started Well, I'm still picking myself up off the floor... >using Sun workstations with a 2/120. I could run compiles with 4 or 5 >windows open, plus 2 more processes off the asynch. comm. ports, and it >only had 2 (two) Mb of memory. Sure, it had to do more than a little >swapping, but it did work. ... >More and more, I get the feeling that either system developers (1and not >just the OS groups at Sun) are getting very spoiled by the ability to have >lots of memory, or they are just becoming incompetent. > >Frankly, I think it is completely undefensible for SunOS4.0.3 to require >16Mb in a machine that comes with 8Mb standard to function well. >Especially given that SunOS4.0.1 ran in 4Mb, and ran well in 8Mb (albeit >in a Sun 4/260), and further that SunOS3.5 ran well in 2Mb. I agree 100%. Every so often some crotchety neanderthal comes along and says `How come I need another 4Mb of memory to run the same application mix with the new release of the system', and hordes of salesmen and gurus shrug suavely and say `well, that's just the price of progress, and besides, memory upgrades are so cheap, it's hardly even a cost item'. Bulls**t, I say. WHY is every new release more of a hog than the previous one? Is it because the 4.0.x world is more complicated than the 3.x one? Or is it a bit of carelessness, like the four or five-level deep set of symbolic links that the configuration program generates around the executables exported by an NFS server? Don't try and hand us the argument that something actually needs to be that big. Remember Turbo Pascal? I haven't looked at 5.x, but 3.x, the last version I played with, took up less than 50k, including the editor, compiler, and a run-time monitor. No shared libraries, either. On my Sun 3, tacitus% ls -l /usr/ucb/pc -rwxr-xr-x 1 bin 73728 May 24 1988 /usr/ucb/pc tacitus% ls -l /usr/ucb/vi -rwxr-xr-x 6 root 147456 May 2 1989 /usr/ucb/vi Now guess which compiles faster - Turbo on a 4Mhz 8088, or pc on my 20Mhz 3/60? I haven't bothered (had the nerve?) to try the acid test; ie, which produces the fastest executable, but my money isn't on pc. WHY isn't size and performance a consideration in the UNIX workstation software market? I must admit that XWindows scares me a bit in this regard; I don't see how we can expect much in the way of a gain in performance over SunView, given the whole client/server orientation of the thing. Anyway, Mr. Johnson, if it's any consolation, there's two others in our office that feel the same way you and I do about this whole thing. I guess we don't constitute a groundswell of popular opinion, but maybe someone from Sun is listening. Chris Hermansen Timberline Forest Inventory Consultants Voice: 1 604 733 0731 302 - 958 West 8th Avenue FAX: 1 604 733 0634 Vancouver B.C. CANADA uunet!ubc-cs!van-bc!tacitus!clh V5Z 1E5 Disclaimer: This is the official opinion of the management.