Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!ucsd!ucbvax!agate!shelby!lindy!liemandt
From: liemandt@lindy.Stanford.EDU (Joe Liemandt)
Newsgroups: comp.sys.next
Subject: Re: Basic system
Message-ID: <3289@lindy.Stanford.EDU>
Date: 27 May 89 21:23:14 GMT
References: <3256@uokmax.UUCP> <-290109996@hpcupt1.HP.COM>
Sender: liemandt@lindy.Stanford.EDU (Joe Liemandt)
Reply-To: liemandt@lindy.Stanford.EDU (Joe Liemandt)
Organization: Instruction and Research Information Services, Stanford Univ.
Lines: 40

In article <-290109996@hpcupt1.HP.COM> edwardm@hpcupt1.HP.COM (Edward McClanahan) writes:
>>
>>It depends on what you consider "work".  If you are developing applications
>>then you need a hard disk.  The optical doesn't cut it for that.
>...
>
>Okay...  Could SOMEBODY PLEASE EXPLAIN EXACTLY WHAT FUNCTIONS (of S/W
>         Development, etc...) WOULD BE IMPOSSIBLY SLOW?
>
>I really don't accept the notion that S/W development is particularly
>more resource (e.g. CPU, disc,...) intensive than any/all application
>execution.  After all, compilers (and Interface Builder and...) are
>merely applications themselves.  I think that is why the original
>poster asked the question.
>
>ed "SCSI disks getting cheaper every day" mcclanahan


I disagree with with your assertion that development takes no more resources
than "any/all application execution".  To write a paper in WriteNow, I
only need to load WriteNow, hit disk a couple times to save, and then print.

To develop WriteNow, I need Edit, IB, cc, gdb all running.  Loading
from the optical is slow, and I have to load 4 times as much.  And, by
loading all of these at once, I have overloaded RAM and NeXT starts
swapping. On an optical, good night.

You are correct in that if you are using apps that are very disk
intensive, the optical will be too slow (Databases for example).

I guess a better statement would be "If you are using the NeXT for anything
that is disk intensive or uses so much RAM that you will start swapping, the
optical will be too slow."

Development falls into the above.

Joe Liemandt
Stanford University
liemandt@s.stanford.edu