Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Academic workstations

0 views
Skip to first unread message

Mike Cullum

unread,
Jun 8, 1989, 7:39:18 PM6/8/89
to
Greetings:

We are in the process of considering the purchase of workstations for
a small lab in our Computer Science Department. Our proposed
configuration calls for 8 workstations (8Mb RAM, 200+Mb disk, large
monochrome display) and a server.

We are vacillating between Apple AUX, NeXt, and Suns. What are
people using? Is there anyone who is using Apple AUX in a
lab situation regularly? Anyone using the DecStation 3100?
Any advice?

Thanks in advance for the help.

Mike Cullum
Lewis & Clark College
Portland, Oregon

UUCP: tektronix!reed!lclark!cullum
Bitnet: cullum@lclark

Paul Sweazey

unread,
Jun 9, 1989, 10:02:29 AM6/9/89
to
In article <5...@lclark.UUCP> cul...@lclark.UUCP (Mike Cullum) writes:
> We are vacillating between Apple AUX, NeXt, and Suns. What are
> people using? (Etc.)

>
> Thanks in advance for the help.
>
> Mike Cullum

Everyone here says I should tell you to use Apple AU/X. :-)
pauls

Paul Sweazey
Apple Computer, Inc.
pa...@apple.com
(408)-974-0253

Joseph T. Warden

unread,
Jun 9, 1989, 1:28:24 PM6/9/89
to

Another opinion (my own) is to go with the Suns - you have access
to a large volume of software (PD, etc), a large installed base
(esp. in Academia) and good pricing. An alternative is DEC, but
if you want to work with server/clients, I think Sun is probably
the easiest to implement and maintain. This opinion is from a
chemist, whose philosophy is to extract the greatest use from
the computer without being consumed by the process.

Joseph Warden
Renssealer
jtwa...@pawl.rpi.edu

Marshall Cline

unread,
Jun 9, 1989, 4:56:18 PM6/9/89
to
To avoid confusion, followups to this are requested to ONLY go to one
newsgroup. I suggest comp.unix.questions.

In article <5...@lclark.UUCP> cul...@lclark.UUCP (Mike Cullum) writes:

>We are in the process of considering the purchase of workstations for
>a small lab in our Computer Science Department. Our proposed
>configuration calls for 8 workstations (8Mb RAM, 200+Mb disk, large
>monochrome display) and a server.

>...
>Any advice?

Clarkson University has quite a number of workstations, so I guess I
have enough experince to answer. However (almost) all ours are Sun's,
so I can't compare. However, I can _STRONGLY_ recommend one feature
in particular:

We have a SINGLE disk server in our School of Engineering, all other
workstations being diskless (thin wire 10Mb/s Ethernet), being
connected via Sun's NFS. There are probably 20 or more "clients"
running off this one server. Although we're pushing the performance
of the disk server, the concept of a single disk server is the BEST
THING SINCE SLICED BREAD.

The problem can be illustrated with our micro-computers (5000 or so AT
class machines on the campus, well over 1000 with hard disks).
Consider a student "Joe". Joe's files are on a particular machine.
If that machine is busy today, he has to copy his files onto whatever
machine he happens to get. Thus he duplicate all his files on all the
machines he might be working on. Then there's the "which is the
latest version?" question. The end result is that our students have
to floppy-jocky everyday.

Having a central location for files (the disk server) means that each
workstation that you log onto acts like it has your files. No two
versions, etc.

Thus your comment for workstation having a 200+Mb disk is one which you
may want to reconsider.

There's a binary-compatibility problem with the NFS scheme, but we have
almost all Sun-3's (68020, 68881). When we go to SparcStations (Sun-4's),
we'll have to address the multiple /bin directories, etc.

Hope this helps.
Marshall
--
________________________________________________________________
Marshall P. Cline ARPA: cl...@sun.soe.clarkson.edu
ECE Department UseNet: uunet!sun.soe.clarkson.edu!cline
Clarkson University BitNet: BH0W@CLUTX
Potsdam, NY 13676 AT&T: (315) 268-6591

Arthur Stine

unread,
Jun 9, 1989, 8:25:32 PM6/9/89
to
Although workstation speed has increased dramatically over the past few years
(Sun, DEC, Apollo, etc all now have machines which run in excess of 5 mips and
the newer RISC technologies push this up to and past 15mips), the speed of the
local area networks have not (Ethernet is still widely used, with token rings
seeing some increasing use). One cannot realize the maximum potential of the
higher performance workstation by using them as a diskless workstation.

Here at Clarkson University, we have a number of Sun workstations (3/50's,
3/60's, 386i's) which are served off of a couple of 3/260 servers. The 3/50's
are primarily diskless, but the others all have local disk. We also have
15 Vaxstations (all diskless except for 1 with local page/swap) served off
of a vaxserver-3500. There are additional Suns in other departments which
are the same sort of technology (3/50's served from a 3/260). Performance
is adaquete for the diskless workstations, but when the network becomes
heavily used, the diskless stations feel the pinch.

Overall, the best bet is probably to use central servers for user files,
large applications, etc and equip the stations with local page/swap and
their own set of systems files (this applies to both Unix and VMS systems,
as the both will make heavy use of the network for I/O in the client/server
setup). This way, you can have the users files residing in a common place,
accessible from a number of places, but still realize the high performance of
the workstations. Making a DECstation or Sparcstation page/swap and do all
of its I/O across an Ethernet will not make the workstation seem very fast.
And it won't take many of the faster workstations to load down the net. Note
also that the RISC systems generally have larger images than their CISC
counterparts.

Diskless only stations (in my opinion) are the wave of the past. Without
higher bandwidth networks, they have become throttled by the available
network technology.

art stine
sr network engineer
clarkson u

Rick Daley

unread,
Jun 9, 1989, 9:10:17 PM6/9/89
to
In article <CLINE.89J...@sun.soe.clarkson.edu>
cl...@sun.soe.clarkson.edu (Marshall Cline) writes:
> We have a SINGLE disk server in our School of Engineering, all other
> workstations being diskless (thin wire 10Mb/s Ethernet), being
> connected via Sun's NFS. There are probably 20 or more "clients"
> running off this one server. Although we're pushing the performance
> of the disk server, the concept of a single disk server is the BEST
> THING SINCE SLICED BREAD.
>
> The problem can be illustrated with our micro-computers (5000 or so AT
> class machines on the campus, well over 1000 with hard disks).
> Consider a student "Joe". Joe's files are on a particular machine.
> If that machine is busy today, he has to copy his files onto whatever
> machine he happens to get. Thus he duplicate all his files on all the
> machines he might be working on. Then there's the "which is the
> latest version?" question. The end result is that our students have
> to floppy-jocky everyday.

The original question had to do with which UNIX workstation to buy for a
student lab. I'm obviously biased about that, but I do have a comment
about Marshall's push for a diskless environment. His argument is that
this keeps students from having to use floppies to move
their files between machines in the lab. Well, this is indeed important,
but it has nothing to do with whether the machines should be diskless.
All this means is that student's files should be stored on an NFS file
server. The machines could still have local disks which are used for the
OS and for paging. This should give you better performance because local
disks should be faster than networks, but it also adds to the cost and
administration effort.

Rick Daley
r...@Apple.COM

Barry Shein

unread,
Jun 10, 1989, 11:10:16 AM6/10/89
to

>This should give you better performance because local
>disks should be faster than networks, but it also adds to the cost and
>administration effort.
>
> Rick Daley
> r...@Apple.COM

Bad guess, go measure it, because servers almost always have faster
disks, controllers and bigger disk buffers remote disks are usually
faster than local disks (assuming a reasonable network loading which
doesn't have to be zero.)

An ethernet can deliver data at almost 1MB per second, go look at the
specs on your standard 27msec SCSI cheapo, 20KB/sec is not unusual for
maximum disk transfer rate, about 1/40th the speed of an ethernet.

In some cases remote disks are much faster, particularly where the
server CPU is much faster (and the disk system) and your process is
causing some amount of parallelism to occur (this doesn't have to be
purposeful, something simple like a find with a grep on each file can
end up exploiting both CPUs as one resolves the file system as the
other pumps away at the raw data.) Remember all those gripes about the
overhead of namei()? Where do you think namei() is running in an NFS
environment?

Many network load problems are due to badly configured or managed
networks with lots of junk traffic (eg. ARP or other broadcast
screamers going unchecked.)

However, I will agree that blaming it on the diskless workstations is
a wonderful alibi, the yokels believe you and rarely ask you to
actually do your job and find out what's really causing the problem.

It's the diskless workstations, it's the diskless workstations (we
know those diskless workstation users will never buy the local disks
you recommend so it's a safe bet to blame it on them.)

Another problem is political, the enforced memory shortage has
temporarily made the disk/memory balance unnatural. But don't confuse
economic realities with technical ones.

I agree none of this would apply to a Mac-II acting as an NFS server,
it doesn't support the disk architecture necessary to get any
performance advantage over a local disk.

I am not saying there aren't cases where a diskful workstation is far
better, I'm just saying most people don't know what they're talking
about or have motives other than understanding the technology.
--
-Barry Shein

Software Tool & Die, Purveyors to the Trade
1330 Beacon Street, Brookline, MA 02146, (617) 739-0202

Dirk Grunwald

unread,
Jun 10, 1989, 2:42:19 PM6/10/89
to

>> Bad guess, go measure it, because servers almost always have faster
>> disks, controllers and bigger disk buffers remote disks are usually

This isn't really true, you know, unless you always buy the most up to
date controller. Smaller disks get better faster, and your incremental
cost is much much lower.

E.g., we have two CDC Sabre drives, 741 controller serving a 3/260. Total
cost at the time (university discounts, etc), about $27,000 for everything,
and we get about 650Mb of storage plus a fast central server if you need
compute-bound jobs (although extensive use of the server slows down everyone
else). The disk has about 1.5Mb/second transfer and 16ms seek

You can buy SCSI CDC Wren-V's that have 1Mb/second transfer rates & 16ms seek
for about $2500. Pick up 10 of those for your 10 clients that you can
serve off the 3/260 & you get 6000Mb of storage, and you still have enough
left over to buy a 2Gb tape backup system.

You get system redundancy (i.e. if a disk croaks, make that station be
a client of another), higher aggregate throughput and 10x the storage.
You don't have the central server, but hey, that can be an advantage
since you can now mix & mach your configuration (i.e. you want 10 stations,
now you have have 5 Sun/i386 stations & 5 DEC-3100's).

--
Dirk Grunwald -- Univ. of Illinois (grun...@flute.cs.uiuc.edu)

Barry Shein

unread,
Jun 10, 1989, 4:26:10 PM6/10/89
to

Yes, Dirk, you're right, a PDP-1 with drum memory is probably not a
cost-effective NFS file server these days. Thanks for pointing out
this oversight in my message.

Brent Byer

unread,
Jun 10, 1989, 8:41:08 PM6/10/89
to
In article <32...@bu-cs.BU.EDU> b...@bu-cs.BU.EDU (Barry Shein) writes:
>.......
>Bad guess, go measure it, .....

>
>An ethernet can deliver data at almost 1MB per second, go look at the
>specs on your standard 27msec SCSI cheapo, 20KB/sec is not unusual for
>maximum disk transfer rate, about 1/40th the speed of an ethernet.
>

Hey, Barry: If you're going to be arrogant, make sure you're correct.
(i.e., don't make "bad guesses, go measure it" :-) )

Your data point of 20KB/sec is off by a factor of 5. At least.

I did measure it. Using a mundane Micropolis 1325, 70MB drive,
30msec access, controlled using a SCSI-ST506 adapter (even slower
than straight SCSI).

Real-world measurement: A tree of 220 .c source files totaling 1.58 MB
(reported by 'wc'), I do a

grep "^Z" */*.c

which completes in 15-17 secs (10 measurements).

Looks like 100KB/sec. [ No sleaze; only 800KB of system buffers ]

>
>I am not saying there aren't cases where a diskful workstation is far
>better, I'm just saying most people don't know what they're talking
>about or have motives other than understanding the technology.
>--
> -Barry Shein
>
>Software Tool & Die, Purveyors to the Trade

[ This does not prove anything wrt diskful vs diskless, but I
don't like to see professionals using gross exaggeration to
support their arguments.
]

What the heck, "We're all bozos on this bus."

brent byer

Dirk Grunwald

unread,
Jun 10, 1989, 10:18:24 PM6/10/89
to

oooo..cheeky cheeky

The 3/260 is less than a two years old.

At that time:
+ Wren IV had same bandwidth as Wren V, less density.
+ 741 was best controller available on the market, other
than Rimfire, which didn't work with 4.0

Hardly a PDP/1.

The point of the message was that disk aggregate bandwidth increases faster
for smaller disks; central file servers devote high $$ resources to
serving clients. The ability to incrementaly upgrade your system decreases
(witness that we still have that 741) and your total performance is poor.

For example, a 3/60 with a local CDC Wren-V runs small latex jobs about
10% to 20% faster than a 3/60 serviced by a an idle file-server on an
idle network. And it'll do it for less money.

Steve Cavrak,113 Waterman,6561483,

unread,
Jun 11, 1989, 7:52:12 AM6/11/89
to
> We are in the process of considering the purchase of workstations for
> a small lab in our Computer Science Department. Our proposed
> configuration calls for 8 workstations (8Mb RAM, 200+Mb disk, large
> monochrome display) and a server.
>

As a "generic" machine, the Macintosh is probably a better bet ---

1. when they're "obsolete" as unix workstation, they can be recycled
as "plain" Macintosh's and sold to "ordinary people". There is
a strong desktop publishing market --- you could even "donate"
them to the library or the alumni office.

2. even when they are NOT obsolete, they can be used in both the A/UX
environment and the Macintosh enviornment. This gives a nice degree
of flexibility. E.g. an alternative use for the machines during the
summer when C programs are not being reinvented, e.g. hypercard
development for language courses, etc.

3. Forget the monochrome, put the color on them.

4. Definitely network the machines, definitely ethernet them. But
keep an 80 mbyte disk on board.


Steve

Dirk Grunwald

unread,
Jun 11, 1989, 5:32:41 PM6/11/89
to
In article <12...@uvm-gen.UUCP> cav...@uvm-gen.UUCP (Steve Cavrak,113 Waterman,6561483,) writes:

1. when they're "obsolete" as unix workstation, they can be recycled
as "plain" Macintosh's and sold to "ordinary people". There is


I hate to tell you, but if you've ever used the apple UNIX, you'd know that
it's *already* obsolete. If you're looking for a color box that runs UNIX
*and* runs standard micro software, go for a '386 box, or a Sun-386i instead.

We have several Apple-IIx's running AU/X, and it's *awful*. The compiler
sucks and the machine is basically slow.

Tony Burzio

unread,
Jun 11, 1989, 8:20:21 PM6/11/89
to
In article <53...@rpi.edu>, jtwa...@pawl.rpi.edu (Joseph T. Warden) writes:
> In article <23...@internal.Apple.COM> pa...@apple.com (Paul Sweazey) writes:
> >In article <5...@lclark.UUCP> cul...@lclark.UUCP (Mike Cullum) writes:
> >> We are vacillating between Apple AUX, NeXt, and Suns. What are
> >> people using? (Etc.)
> >Everyone here says I should tell you to use Apple AU/X. :-)
>
> Another opinion (my own) is to go with the Suns - you have access
> to a large volume of software (PD, etc), a large installed base

I personally like Hewlett Packard, the number one workstation vendor. Other
people here like Suns and Apples (they make pretty pictures). All three
fit in pretty well together. The only vendor I would stay away from is that
other three letter initial vendor who sells (ugh) proprietary operating
systems... I think it is CED or EDC or something... :-)

*********************************************************************
Tony Burzio * Do humanity a favor,
Martin Marietta Labs * shoot a Communist...
mmlai!bur...@uunet.uu.net *
*********************************************************************

Todd

unread,
Jun 12, 1989, 11:45:57 AM6/12/89
to
In article <32...@bu-cs.BU.EDU> b...@bu-cs.BU.EDU (Barry Shein) writes:
[stuff deleted]

>However, I will agree that blaming it on the diskless workstations is
>a wonderful alibi, the yokels believe you and rarely ask you to
>actually do your job and find out what's really causing the problem.
>
>It's the diskless workstations, it's the diskless workstations (we
>know those diskless workstation users will never buy the local disks
>you recommend so it's a safe bet to blame it on them.)
>
[stuff deleted]

>--
> -Barry Shein
>
>Software Tool & Die, Purveyors to the Trade
>1330 Beacon Street, Brookline, MA 02146, (617) 739-0202

I have been doing traffic analysis, and it is our diskless
workstations which are pulling down our network. Our network
throughput is starting to drop because of the high collision rate,
BUT...

I work in a reasearch environment (and the two other places that I
have checked were research environments), so we have lots and lots of
workstations with lots of users pushing the workstations pretty hard.
If you have only a small isolated lab (or one connected to a larger
network by a bridge (not simply a repeater)), diskless stations may be
a better buy.

(The poor poster who started this thread probably has given up on
getting his original question answered)

Todd Heberlein

Mike Markley

unread,
Jun 12, 1989, 12:39:52 PM6/12/89
to
In article <5...@lclark.UUCP> cul...@lclark.UUCP (Mike Cullum) writes:
>
>>We are in the process of considering the purchase of workstations for
>>a small lab in our Computer Science Department. Our proposed
>>configuration calls for 8 workstations (8Mb RAM, 200+Mb disk, large
>>monochrome display) and a server.
>>...
>>Any advice?
>

It somewhat depends upon what your overall objective is but
here is my $0.02. If you want a distributed file system where
you have access to all of your files from any workstation
without having to copy them to the local disk buy Apollo
workstations. The Apollo file system is IMHO orders of
magnitude easier to administer than NFS. The Apollo registery
is also easier to set up and administer than Yellow Pages from
SUN. In SUNs favor is cost and amount of inexpensive software
available. This is becoming less of a factor now that SR10
from Apollo is available. Just configure your machine as a
BSD4.3 machine and the compatability questions dim. If you
need to develop graphics software the SUN is easier to program
unless you go with X-Windows and then the systems are the same.
The X11R3 software is much more stable on the SUNs then it is
on the Apollos. If you are looking for pure integer
performance than SUN is much more cost effective. The
SparcStations are very fast in the integer environment. For
floating point I would say consider buying a fast server and a
bunch of cheap diskless workstations. You can put 2.8Gigabytes
on an Apollo DN10000 and then run all of you diskless stations
of of this. It is several times faster than the SparcStations
for floating-point calculations.

My recommendation overall is to go with Apollo. Their
workstations are IMHO much easier to take care of and their
network is much easier to grow. A single command adds new
workstations, and the workstations file system(s), to the network.

Mike Markley
University of California, San Diego
mar...@celece.ucsd.edu
mar...@kubrick.ucsd.edu

George Kyriazis

unread,
Jun 12, 1989, 4:11:15 PM6/12/89
to
In article <12...@uvm-gen.UUCP> cav...@uvm-gen.UUCP (Steve Cavrak,113 Waterman,6561483,) writes:
>
>As a "generic" machine, the Macintosh is probably a better bet ---
> ...

>2. even when they are NOT obsolete, they can be used in both the A/UX
> environment and the Macintosh enviornment. This gives a nice degree...
>

But you CANNOT use Mac's running A/UX! Believe me, I tried!


George Kyriazis
kyri...@turing.cs.rpi.edu
kyri...@rdrc.rpi.edu
------------------------------

Bruce G. Barnett

unread,
Jun 13, 1989, 6:35:18 AM6/13/89
to
In article <31...@sun.soe.clarkson.edu>, abstine@sun (Arthur Stine) writes:
>
>One cannot realize the maximum potential of the
>higher performance workstation by using them as a diskless workstation.

I question this statement. See below.

>Here at Clarkson University, we have a number of Sun workstations (3/50's,
>3/60's, 386i's) which are served off of a couple of 3/260 servers. The 3/50's
>are primarily diskless, but the others all have local disk.

I would say you have your machines configured backwards.
The 3/50's need the disk because they are the ones most likely
to page, and if they have local disks, they won't flood the network.

>Performance
>is adaquete for the diskless workstations, but when the network becomes
>heavily used, the diskless stations feel the pinch.

I would say you have a network configuration problem.

>Diskless only stations (in my opinion) are the wave of the past. Without
>higher bandwidth networks, they have become throttled by the available
>network technology.

I will agree that an application that has to work with a lot of data
(Image processing, etc) will need a fast disk.

We have 300 Sun's here, and 80-90% are diskless. They are all on a single
Ethernet (with several seqments and smart bridges).

If a machine is slow, we add more memory. If we can't (like a Sun 3/50),
we try to add a local SCSI disk to eliminate the swaping.

Some high end servers have their own disk, that's true.
But with the coming of network window systems, and diskless machines with 64
megabytes of memory, I do not agree with your statement about diskless
machines being passe.

In our experience, we see a continued use of diskless workstations.
If we had to convert over to diskfull workstations, we would have to
double or triple the support staff needed to keep them all running.

--
Bruce G. Barnett <bar...@crdgw1.ge.com> a.k.a. <barnett@[192.35.44.4]>
uunet!crdgw1.ge.com!barnett bar...@crdgw1.UUCP

Jeff d'Arcy

unread,
Jun 13, 1989, 12:14:03 PM6/13/89
to
In article <32...@bu-cs.BU.EDU> b...@bu-cs.BU.EDU (Barry Shein) writes:
>
>>This should give you better performance because local
>>disks should be faster than networks, but it also adds to the cost and
>>administration effort.
>> Rick Daley
>> r...@Apple.COM
>
>Bad guess, go measure it, because servers almost always have faster
>disks, controllers and bigger disk buffers remote disks are usually
>faster than local disks (assuming a reasonable network loading which
>doesn't have to be zero.)

Certainly, servers (at least those configured by sane administrators)
are likely to have faster, bigger disks etc. than would be feasible
for individual workstations. However, latency is likely to suffer due
to the overhead associated with protocol encapsulation etc. especially
in heterogeneous environments. If the application is doing something
simple such as a huge block transfer the performance hit won't be that
bad, but more complex operations involving random disk accesses will
hurt.

>An ethernet can deliver data at almost 1MB per second, go look at the
>specs on your standard 27msec SCSI cheapo, 20KB/sec is not unusual for
>maximum disk transfer rate, about 1/40th the speed of an ethernet.

At risk of repeating myself, this observation only applies to the simple
case where transfer speed is the limiting factor. Unfortunately, latency
is frequently more important and is the first thing shot to h*ll in a
network environment.

>[very good points about parallelism and network administration
> deleted to save network bandwidth]

>However, I will agree that blaming it on the diskless workstations is
>a wonderful alibi, the yokels believe you and rarely ask you to
>actually do your job and find out what's really causing the problem.

>It's the diskless workstations, it's the diskless workstations (we
>know those diskless workstation users will never buy the local disks
>you recommend so it's a safe bet to blame it on them.)

>[attempted disclaimers deleted]

>I am not saying there aren't cases where a diskful workstation is far
>better, I'm just saying most people don't know what they're talking
>about or have motives other than understanding the technology.

"...don't know what they're talking about..."? Disagreement is not
a sure sign of one party's ignorance, Barry. I'm not saying that
local disks are the one and only way to go, but they are superior for
a wide range of applications. I make my living in this field and I
am probably not alone in being offended by your implication that those
who disagree with you on this point are either foolish, lazy or
dishonest.

Russell Shackelford

unread,
Jun 15, 1989, 6:46:53 AM6/15/89
to
In article <12...@uvm-gen.UUCP>, cav...@uvm-gen.UUCP (Steve Cavrak,113 Waterman,6561483,) writes:
> > We are in the process of considering the purchase of workstations for
> > a small lab in our Computer Science Department. Our proposed
> > configuration calls for 8 workstations (8Mb RAM, 200+Mb disk, large
> > monochrome display) and a server.
>
> As a "generic" machine, the Macintosh is probably a better bet ---

well, i dunno what the experience of other folks has been, but at Georgia
Tech people have gotten some measure of exerience with all three of the
choices (Mac, Next, Sun) mentioned in the original post. from what i've
heard.....

MAC AUX:
there's a couple labs full of those things and they mainly keep everybody
mad as hell. trouble getting it work with the net. trouble with the compilers.
things get fixed (by local sweat, not apple's) but in the process they make
everybody nuts. the prez had some scheme to get a couple truckloads of the
things. dunno what he's gonna do, but everybody around here wanted to tell
him to forget it.... the faculty who have the things in their offices mainly
use them as paper weights will waiting for the required permission to clean
the alleged-unix off the disk so they can actually use the things for
something...

Next:
couple of dozen or so scattered about. people seem to think they're pretty ok,
'specially the sexier things.... but they're buggy... getting better... but
still buggy.... and there's no software..... so nobody's really excited...
but then again, nobody is mad either.... people expect this sort of thing
from new products....

Sun's:
every CS faculty (almost) has got one on his/her desk. they use'm
everyday and nobody's mad.... the only fly in the ointment: they started
to check out alt sources of serv. contracts cause they were spending more
than they thought reasonable on the things...

does anybody else know of a shop that's used all 3?

--
Russell Shackelford
School of Information and Computer Science
Georgia Institute of Technology, Atlanta, GA, 30332
ru...@prism.gatech.edu (404) 834-4759

Ralph Hyre

unread,
Jun 16, 1989, 8:33:21 PM6/16/89
to
I can't understand why you folks are polluting info-apple, which is
about the Apple 2 series of machine, use comp.sys.mac if you want
to talk about the Macintosh in comparison with other machines.

--
- Ralph W. Hyre, Jr.
Internet: ralphw@{ius{3,2,1}.,}cs.cmu.edu Phone:(412) CMU-BUGS
Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA
"You can do what you want with my computer, but leave me alone!8-)"
--

Jeff Boone

unread,
Jun 17, 1989, 12:16:02 AM6/17/89
to
In article <8...@hydra.gatech.EDU> ru...@prism.gatech.EDU (Russell Shackelford) writes:
>
> does anybody else know of a shop that's used all 3?
> (Mac/AUX, NeXT, Sun)

Here at Oceanography we have a network of Macs, Suns, and NeXTs. These
are my opinions of the machines.

NeXT: I have to agree with you that the machine is bug ridden. I foolishly
chose to do my Master's (CS) project on the thing and I'm having a
heck of a time finding useful information in their WEAK documentation.
The box is much slower than we had anticipated. I know there has
been a big discussion lately about floating point and integer
arithmetic speed and the NeXT seems to fare pretty well, but I'm
talking about user response time (UNIX overhead kills).

On the plus side, I think the NeXT probably has more potential than
either of the other 2 product lines. It just needs time to work out
the bugs and get some serious software developed for it. It will be
interesting to see what the Canon stock purchase will mean for NeXT.

Sun: We have quite a few researches committed to the Sun product line.
They are great for graphical displays of huge oceanographic data.
There is certainly a lack of productivity software for them besides
the couple of very good publishing packages. Ever look at Sun Write,
Paint, and Draw? Can you say ugly stuff? Granted their only first
generation, but it's pretty poor software. If Sun is planning to
put their SparcIntosh onto desktops of anyone other than researchers
they need better productivity tools.

Mac: AUX is slow and System V based. In its current state it is not
very useful. We do look forward to version 2.0 which is supposed
to have a front end indistinguishable from the finder (we'll see :-).
The Mac has all its strength in the huge software base (isn't that
what the say about MS-DOS?). I think Apple has realized that the
Mac really can't compete with the other vendors within a workstation
environment, it is the cadillac of personal computers :-).

Here at oceanogrphy, almost all researchers have both a Sun and a Mac (not
running AUX) on their desks. The Sun to crunch data, and the Mac to do
everyday kinds of chores.

-------------------
These opinions are completely mine.
Jeff Boone
bo...@oce.orst.edu
College of Oceanography, Oregon State University

ma...@zaphod.ncsa.uiuc.edu

unread,
Jun 19, 1989, 2:16:01 AM6/19/89
to

In response to your complaints about the Sun Write/Paint/Draw -- did you ever
see the initial Mac Write/Paint/Draw? Sun's first attempts are definitly
superior to what Apple was releasing with their systems.

My comments are my own, not necessarily those of my employers.

Jeff Boone

unread,
Jun 21, 1989, 12:01:03 AM6/21/89
to
In article <600042@zaphod> ma...@zaphod.ncsa.uiuc.edu writes:
>
>In response to your complaints about the Sun Write/Paint/Draw -- did you ever
>see the initial Mac Write/Paint/Draw? Sun's first attempts are definitly
>superior to what Apple was releasing with their systems.
>

You're absolutely right. But I don't know if that is a valid comparison.
When Apple introduced MacPaint and MacDraw there was absolutely ZERO
competition. Now the market is much different, the standards have
been raised and nobody wants to go back to original MacPaint/Draw.

I think Sun has a very good line of workstations, but they are in
need of more productivity software to compete in the PC market.

--------------------
"My opinions"

Paul Raveling

unread,
Jun 23, 1989, 1:55:58 PM6/23/89
to
In article <53...@rpi.edu> jtwa...@pawl.rpi.edu (Joseph T. Warden) writes:
>
>Another opinion (my own) is to go with the Suns - you have access
>to a large volume of software (PD, etc), a large installed base
>(esp. in Academia) and good pricing. An alternative is DEC, but
>if you want to work with server/clients, I think Sun is probably
>the easiest to implement and maintain. This opinion is from a
>chemist, whose philosophy is to extract the greatest use from
>the computer without being consumed by the process.

Since I'm now involved with supporting workstations here,
I'll offer a relative rating of software/system quality
as I see it:

Best: HP
#2: DEC
Worst: Sun

HP & DEC are probably close, but we have mainly Sun & HP
workstations; I don't have much DEC experience to confirm
this suspicion. Sun's software (e.g., C compiler) is often
visibly less refined and more trouble-prone than HP's.

BTW, these are my opinions based on my experience.
Milage may vary for others...


----------------
Paul Raveling
Rave...@isi.edu

Erik E. Fair

unread,
Jun 24, 1989, 3:52:52 PM6/24/89
to
In article <87...@venera.isi.edu> rave...@venera.isi.edu (Paul Raveling)
writes:

> HP & DEC are probably close, but we have mainly Sun & HP
> workstations; I don't have much DEC experience to confirm
> this suspicion. Sun's software (e.g., C compiler) is often
> visibly less refined and more trouble-prone than HP's.

Just try getting Ultrix source from DEC. When you do, you'll find out that
it is "for reference purposes only."

Erik E. Fair apple!fair fa...@apple.com

Paul Raveling

unread,
Jun 26, 1989, 9:32:35 PM6/26/89
to

We haven't managed to get HP-UX source from HP either.
Having viewed things like this from the vendor side as well
as from the user side, I can't blame them much for not wanting
wanting to maintain a source product.

Instead I just mutter sometimes that a good operating system
shouldn't leave users with a need for its source. Unfortunately
that kind of need seems to keep arising on all the variants of UNIX
I've dealt with.


----------------
Paul Raveling
Rave...@isi.edu

Robert Cousins

unread,
Jun 27, 1989, 10:34:05 AM6/27/89
to
In article <87...@venera.isi.edu> rave...@venera.isi.edu.UUCP (Paul Raveling) writes:
>In article <24...@internal.Apple.COM> fa...@apple.com (Erik E. Fair) writes:
>>Just try getting Ultrix source from DEC. When you do, you'll find out that
>>it is "for reference purposes only."
> We haven't managed to get HP-UX source from HP either.
>Paul Raveling
>Rave...@isi.edu

Having watched this thread for a while now, I felt that I just COULDN'T
watch any more. First of all, when you want an academic workstation,
you sould go for a standard which allows you to buy compatible hardware
from multiple vendors and still run the same binaries. Secondly, any
vendor which will not sell the source code for their operating system
must have something to hide. The DG/UX sources are licensable and have
been licensed by several third parties and currently is being offered
for resale on their hardware.

When I was in school, the real issue with budgets was to get the most
bang on very few bucks. I recommend that you check into some of the
new 88K products (from a number of companies aside from my own). These
are faster than the machines discussed in this thread earlier AND cost
much less. In some cases under $500/MIPS ready to run.

To avoid turning this into a commercial for my product, I will close
here. If anyone is interested in 88K based products, just let me know.

Robert Cousins
Dept. Mgr, Workstation Dev't.
Data General Corp.

Speaking for myself alone.

Liudvikas Bukys

unread,
Jun 28, 1989, 11:22:59 AM6/28/89
to
In article <1...@dg.dg.com> uunet!dg!rec (Robert Cousins) writes:
>
>Having watched this thread for a while now, I felt that I just COULDN'T
>watch any more. First of all, when you want an academic workstation,
>you sould go for a standard which allows you to buy compatible hardware
>from multiple vendors and still run the same binaries. Secondly, any
>vendor which will not sell the source code for their operating system
>must have something to hide. The DG/UX sources are licensable and have
>been licensed by several third parties and currently is being offered
>for resale on their hardware.
>
>When I was in school, the real issue with budgets was to get the most
>bang on very few bucks. I recommend that you check into some of the
>new 88K products (from a number of companies aside from my own). These
>are faster than the machines discussed in this thread earlier AND cost
>much less. In some cases under $500/MIPS ready to run.
>
>To avoid turning this into a commercial for my product, I will close
>here. If anyone is interested in 88K based products, just let me know.
>
>Robert Cousins
>Dept. Mgr, Workstation Dev't.
>Data General Corp.

Speaking as someone who has just been through a long complicated
workstation purchase decision, I have the following things to say:

We took competitive bids from all the major workstation vendors, and I
must say that there were only two companies (and neither of them is DG)
with serious bids from the price/performance point of view. BTW,
competition is wonderful!

A number of people here had high hopes for the DG product, but all
these fast and loose $/MIPS figures that look so good are for seriously
underconfigured machines. Add in appropriate amounts of memory and
maybe a local paging disk, and things don't look so good any more.
(The design/win beta prices looked better, but those aren't the current
prices.)

DG needs to realize that it is a relative unknown in this field, and
will need to prove itself in the next year or two. Let me tell you how
this all sounds to a customer (who gave DG's product serious thought
but clearly made the right decision buying something else):

DG says: "DG/UX is great, new reliable filesystem, multi-processor support."
Customer thinks: "DG has no reputation as a Unix vendor yet. And just what we
needed, another vaguely incompatible Unix clone with underlying system
stuff that may or may not work well, and probably with a whole new
incompatible set of sys admin tools to support it."

DG says: "$/MIP."
Customer thinks: "We're trying to get rid of our 4-MB machines and this vendor
thinks we should buy more. And their memory is on these 4MB cards that
nobody else makes yet, so I pay through the nose for more, if I decide
I want a real machine."

DG says: "ABI"
Customer thinks: "AT&T and SUN thought of it first and I can buy Suns and Solbournes
(both machines that I might want) now. And there's a whole heck of a lot
more software for SUNs that I can buy right now. Also, there is a sizable
user community for SUNs. Who the heck owns DGs yet?"

DG says "88K"
Customer thinks: "I don't know who's going to win in the end; the vendors will be
leapfrogging each other for quite a while and whatever I buy won't be
`the best' for very long so I'd better not lose any sleep over it."

DG says "Available now."
DG salesman says "Can you delay your purchasing decision for a month?"
Customer says "Product not ripe. Also, Motorola tends to pre-announce A LOT,
and they haven't announced anything (other than DG's ECL implementation)"

My point is that a relative unknown like DG is breaking into a market where they
have not had a product before, and in which they have no reputation. From my
point of view, they need to do as little pre-announcing as possible, and just
deliver the product so people can try it out. Also, they should minimize the
touting of benefits that are really only theoretical right now, like the 88K ABI.

Dave_Waller

unread,
Jun 28, 1989, 11:40:14 AM6/28/89
to
The source code for HP-UX is available and easily orderable from HP. The
problem tht most of you will find when trying to get ahold of it is that
the SOURCE CODE LISCENSE, which AT&T requires you to buy before we can
give you source code, costs approx $50,000. HP cannot give you even the
source for 'cat' without selling you the liscense -- it's part of the
liscensing agreement with AT&T. If you have a gripe about not being able to
get pieces of the source code for a reasonable price, gripe at AT&T.

Dave Waller
Hewlett-Packard Co.
Workstation Group
Pacific Technology Park
1266 Kifer Rd.
Sunnyvale, CA
(408) 746-5324
[ucbvax!]hplabs!hpdstma!dave | da...@hpdstma.ptp.hp.com
+-----------------------------------------------------------------------------+
| Standard disclaimer: |
| The opinions expressed above are solely my own, and in no way reflect those |
| of my employer. |
+-----------------------------------------------------------------------------+

Snoopy

unread,
Jul 11, 1989, 8:59:52 PM7/11/89
to
In article <24...@internal.Apple.COM> fa...@apple.com (Erik E. Fair) writes:

|Just try getting Ultrix source from DEC. When you do, you'll find out that
|it is "for reference purposes only."

| Erik E. Fair apple!fair fa...@apple.com

Presumably this implies that Apple supplies full source code for all its
offerings.

_____ .-----.
/_____\ Snoopy ./ RIP \.
/_______\ qiclab!sopwith!snoopy | |
|___| parsely!sopwith!snoopy | tekecs |
|___| sun!nosun!illian!sopwith!snoopy |_________|

"But we're only up to the fourth inning."

0 new messages