Setting up a Sparcstation lab.

[Chris Hermansen]

In article <3269 at brazos.Rice.edu> chris at 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.