🚀 go-pugleaf

>In <2694@sdcsvax.UCSD.EDU>, Gene Miya writes:
>
>.....
>problem is that putting a lot of heterogeneous stuff together is hard.....
>We have a tendency to solve easy problems and leave the hard stuff as
>"exercises for the reader ;-)."  To put together really heterogeneous
>systems (and I don't mean VAXen and PDP-11s, but Crays, Suns, Britton-Lee
>boxes, Evans and Sutherland CT6 systems, etc.) is
>1) expensive, 2) hard, 3) lacking in pay-off, appreciation, etc....
>....
I'd agree with 1) & 2), but I'm surprised at 3): I'd bet that most technical
shops have a wide variety of machines, and even if things aren't transparently
distributed, but they're at least networked together.  I'm sure AMES has a ton
of different computers linked together.  We're just a little place, and we have
Apollo, SUN, VAX, Cadnetix, and MIPS boxes all hooked together, as well as
occasional links to an ELXSI.  At least several important simulation programs
can be run on most of these machines, at and least some of the time, where they
run is load-dependent [i.e., look at several amchiens to find one that is not
in heavy use].  Anyway, the point is that there is often good payoff from even
simple things to let machines talk.

In the commercial world, there is substantial use of distributed systems;
although, again, they may not be wonderfully transparent.  Larger sites have
often grown by agglomeration, where individual systems have ahd to be connected
later.  For example, [to cite an example from experience], when you call 611
for telephone repair, you're talking to somebody who's using a distributed
system [older ones use 2-6 triplexed PDP-11/70s hooked to large IBM mainframes;
newer ones have 8600s in place of 11/70s, I think].  All of this is hooked with
various other computers, like 3B20s, and thousands of micros that do automated
testing, and which are also intimately hooked into the telephone switches,
which of course, form a classic distributed system amongst themselves.

Amongst homeogenous distributed systems, at least the following have been
around for a while: Prime's PrimeNet; Tandem's networking; DEC's VAXCluster;
Apollo DOMAIN.  These vary in what they do, of course, but they all look
like distributed systems to me.

>Oh, back to Dick.  He has a neat diagram of the problems:
>
>                            Communications
>                                 /  \
>                                /    \
>                               /      \
>                              /        \
>             Operating Systems -------- Programming Languages
>
>These three communities don't talk to one another.  He harps that the OS
>people are too infatuated with Unix (with relatively poor network support,
>brewed, too early on too small a machine), the PL people are infatuated
>with Ada, and the networking people, well, they have not been around as
>either community....
This seems a bit extreme.  There are plenty of people who do/have done at least
2 of the 3.  In particular, OS folks may often turn into networking folks:
as Greg Chesson puts it, "If you think networking people do weird hacks for
performance, they probably got that way by doing them as OS people beforehand."
(or something like that)

In article <2696@sdcsvax.UCSD.EDU> Marty Fouts writes:
>One of Gene's throwaway lines seems to me to be a key point.  The idea
>behind a lot of distributed systems seems to be that you could load balance
>and gain fault tolerance by distributing. Unfortunately, you can do both
>easier by using a multiprocessor, rather than a distributed system.
This is not instantly clear, depending on your idea of multi-processor.
Some forms of fault-tolerance absolutely prefer distributed systems over
close-coupled, shared memory multi's.  Tandem and Tolerant are good
examples.  Also, there are lots of applications where there is some technical
or political reason to use machines that are geographically dispersed, rather
than sitting in the same box. [This is not to knock multis, since they can do
some very convenient sharing of their own, especially taking advantage of
shared memory.  I just observe that you can't wave the multi wand over
every problem class and magically do better.  Consider the telephone system
again: clearly we should have one giant multi-processor telephone switch in
Kansas! :-)
>

To finish, I'd propose calling a distributed system any one that uses
multiple CPUs, other than those that are connected with shared memory and
use it that way [i.e., if you just use shared memory for high-speed
message passing, and the software doesn't care whether two CPUs are in
the same cardcage, across the room, or miles away, then it could be
a distributed system.  But if you really structurally make use of the
shared memory, the software is rather different, and doesn't feel quite like
a distributed system to me, anyway.]

It seems to me that there are many real-live distributed systems around,
although the degree of transparency is low, except for a few homogeneous
systems.  Some heterogeneous nets are starting to show signs of load-balancing,
but we have a long way to go.  Of course, the increasing prevalence of UNIX,
even with all of its faults, may at least help this.  After all, it hasn't
been all that many years since you not only could NOT do anything complex
in a portable way, but it was even hard to get the same FORTRAN program
to do the same thing on multiple vendors' machines.
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	{decvax,ucbvax,ihnp4}!decwrl!mips!mash, DDD:  	408-720-1700, x253
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086