HDTenEightyP/NetNews huggingface dataset:
From: welch@parc.xerox.com (Brent Welch)
Newsgroups: comp.os.research
Subject: Re: Have we learned anything in the last 20 years?
Date: 8 Apr 92 17:41:18 GMT
Article-I.D.: darkstar.32424
Organization: Xerox PARC
Originator: osr@ftp

yodaiken@chelm.cs.umass.edu (victor yodaiken) writes:


>In article <32014@darkstar.ucsc.edu> ast@cs.vu.nl (Andy Tanenbaum) writes:
>>GENERALLY ACCEPTED AS TRUE BY RESEARCHERS IN DISTRIBUTED SYSTEMS
>>   - The client-server paradigm is a good one

>Seems like a dreadful paradigm. Compare the process paradigm,
>or the UNIX "everything is a file" paradigm, both of  which really
>simplify design of fast, robust, systems, with client-server. 
>Client server seems to me to obscure the natural modularity of distributed
>systems. For example, file servers cause immense complications in that the
>information needed for local caching is encapsulated inside the file server
>where it can't do any good. 

>-- 


I don't understand this statement about file servers making client
caching difficult.  The Sprite and Andrew file systems are examples
of systems in which the file servers take explicit action to support
client caching.  Both systems work very well, wich client caching
reducing network and server load.  Of course, it is possible to design
a file server that makes it hard to do client caching correctly,
but this is just a design error.  Too bad NFS made it.  Finally,
client/server splits are natural reflections of modular boundaries in
a distributed system.  Granted, at some level you can hide the client
server split, but under the covers the split is important.

	Brent Welch
	Xerox PARC
	welch@parc.xerox.com

>yodaiken@chelm.cs.umass.edu
--

	Brent Welch
From: sivak-d@cs.Buffalo.EDU (D Sivakumar)
Newsgroups: comp.os.research
Subject: Article for comp.os.research
Date: 13 Apr 92 21:42:03 GMT
Organization: State University of New York at Buffalo/Comp Sci
Originator: osr@ftp

In article <32793@darkstar.ucsc.edu> glew@pdx007.intel.com (Andy Glew) writes:
>In article <32507@darkstar.ucsc.edu> ast@cs.vu.nl (Andy Tanenbaum) writes:
>
>>   2. Synchronous (blocking) communication is easier to use than asynchronous.
>>         Starting a send, then going off to do something, followed by getting
>>      an interrupt when the send is done is a nightmare to program.  If you
>>      must do something while waiting for the reply, put that code in another
>>      (synchronous) thread.  The biggest problem in the computer industry is
>>      not slow machines, but hairy, unreliable software.  Using asynchronous
>>      communication just makes the problem worse.
>
>Bogus!
>
>If you want synchronous communication, do
>
>    	sendid := asynch_send_start();
>    	wait_for_completion(sendif);
>
>I.e. synchronous communication is trivially synthesized from asynchronous.
>
>Asynchronous communication can be synthesized from synchronous, but
>you have to get another thread/process to do the actual op for you.

	This is what is called neatly twisting the point to
	suit one's own convenience.  Your observation about
	asynchronous/synchronous communication might be true
	(ok, it IS true that synchronous communication is a
	SPECIAL CASE of asynchronous communication), but that
	doesn't make Andy's remark a BOGUS.  The point that
	Andy made was that 

	* Synchronous communication is easy to handle while
		writing programs...

	You can possibly stretch your point a little further and
	say that "afterall, DETERMINISTIC PROGRAMS are special
	cases of NON-DETERMINISTIC PROGRAMS, so let's all write
	Non-deterministic programs".... the reason why we write
	deterministic programs is that they are easier to visualize,
	easier to understand, easier to manage, easier to debug
	than nondeterministic programs.  The same is true of
	synchronous/asynchronous communication.
	The fact that one can be simulated by the other is
	entirely beside the point.

	-Siva.
From: henry@zoo.toronto.edu (Henry Spencer)
Newsgroups: comp.os.research
Subject: Re: A challenge
Date: 12 Apr 92 00:18:19 GMT
Article-I.D.: darkstar.32708
Organization: U of Toronto Zoology
Originator: osr@ftp

In article <32507@darkstar.ucsc.edu> ast@cs.vu.nl (Andy Tanenbaum) writes:
>for the second act, I hereby challenge all the people who have commented
>on my list to do better.  List what YOU consider the five most important
>things we have learned about distributed operating systems in the past
>20 years.

1. A distributed operating system should look, to the customer, just like
a non-distributed operating system, apart from the possibility of more
creative failure modes.  Cleverness should go into hiding its distributed
nature, not exposing it.

2. Unix filesystem semantics -- resources organized in a tree structure
named by ASCII names, and operated on by open/close/read/write -- work
just as well in a distributed system as in a non-distributed one, unlike
most of their competitors.

3. Most resources are used by only one customer at a time, so it is
important to streamline the *un*shared case while handling the shared
case gracefully.

4. Pipes are an excellent interprocess-communication method, superior
to most of their competitors in flexibility and distributability (is
that a word? :-))... provided you have some way of establishing them
between unrelated processes, and preferably some way of passing them
between processes dynamically.

5. Most distributed-OS designers would rather design something new and
weird, in hopes that everyone will say "oh, how wonderful, we must
rewrite all our programs to use this at once", than observe point #1
above and build a distributed implementation of the same old thing,
on which all that software will run without change.
-- 
GCC 2.0 is to C as SVR4 is to Unix.     | Henry Spencer @ U of Toronto Zoology
                             -Dick Dunn |  henry@zoo.toronto.edu  utzoo!henry
From: yodaiken@chelm.cs.umass.edu (victor yodaiken)
Newsgroups: comp.os.research
Subject: Re: A challenge
Date: 10 Apr 92 14:25:27 GMT
Organization: University of Massachusetts, Amherst
Originator: osr@ftp


In article <32507@darkstar.ucsc.edu> ast@cs.vu.nl (Andy Tanenbaum) writes:
>
>Gee, reading this newsgroup is more fun than whacking a hornet's nest with
>a baseball bat.
>
>I am quite unconvinced.  While I could go after each of the comments posted
>here in the past couple of days, I will resist the temptation.  Instead,
>for the second act, I hereby challenge all the people who have commented
>on my list to do better.  List what YOU consider the five most important things
>we have learned about distributed operating systems in the past 20 years.

Here's four. Two are negative, but that's the breaks.

1. The "fast, clean, communication system" as a foundation for
constructing a distributed o.s. is a mythical object. Distributed o.s's
require different communication mechanisms for different purposes and there
is no single abstraction which can be used as a building block for all others
without a significant cost in performance and ease of use.

2. The UNIX "everything is a file" paradigm extends to networks pretty
well.

3. It is possible to perform significant, on line, "compilation" of
multi-layered o.s. code. The use of this method by Massalin, seems to me to
be one of the most significant advances in the state of the art in
recent years.

4. Current system design methodologies are serious impediments to advance.
Our inability to quickly prototype ideas, to concisely describe (in detail)
the workings of distributed algorithms, and to perform any kind of
verification of algorithms short of testing make o.s. research overly 
tedious. 
 

-- 


yodaiken@chelm.cs.umass.edu
From: anderson@icsi.berkeley.edu (David Anderson)
Newsgroups: comp.os.research
Subject: the next 20 years
Date: 13 Apr 92 23:59:05 GMT
Organization: International Computer Science Institute, Berkeley, CA, U.S.A.
Originator: osr@ftp

Let's think about the NEXT 20 years for a moment.
Eventually the dominant (in bits, CPU cycles, and $$) use of 
computer systems will be the communication, I/O, and storage
of digital continuous media (audio and video).
If you doubt this, think about

- broadcast and cable TV and radio,
- video rental and camcorders,
- local and long-distance telephone,
- CD distribution,
- etc., etc.

These will be folded into a single information "fabric"
based on fiber-optic and cellular radio networks.
The end-nodes will be computers, some of them disguised as
less functional appliances like phones and TV sets.
Negroponte and others predicted this a long time ago,
and the enabling technology is starting to fall into place.

What does this suggest to you about important research directions in
"operating systems"?  Should we stick with RPC and UNIX files?
Or will other basic abstractions perhaps be needed?


David Anderson
anderson@icsi.berkeley.edu
From: bellcore!gizmo.bellcore.com!mo@uunet.UU.NET (Michael O'Dell)
Newsgroups: comp.os.research
Subject: Re: A challenge (response) (response)
Date: 10 Apr 92 22:34:47 GMT
Organization: Center for Chaotic Repeatabilty
Originator: osr@ftp

I stand corrected on two counts:

Indeed, Henry Massalin's Synthesis kernel is very, very cool stuff,

as is....

Penpoint - one of the most interesting pieces of OS work
I've seen in a long time.

so maybe there IS something new under the sun, but interestingly
enough, they BOTH are VERY concerned about small and fast.

	-Mike O'Dell
	 Crank-in-Residence

Bellcore? Bellcore isn't allowed to have opinions. These be mine.

PS - Henry defended this thesis today and passed!!!!
Congrats Henry!!!!


Newsgroups: comp.os.research
From: johnm@cory.berkeley.edu (John D. Mitchell)
Subject: Re: A challenge
Organization: University of California, at Berkeley
Date: Thu, 16 Apr 1992 07:02:20 GMT

In article <33002@darkstar.ucsc.edu> artg@minnow.watson.ibm.com (Art Goldberg) writes:
[...]
>OS/2 2.0 is written in assembler, as is (i think) DOS.   The Mac OS
>is written in assembler and pascal.  The proprietary systems are written
>in everything from assembler, to C, to who knows what.

From everything I've heard, OS/2 2.0 is written mostly in C.  There are
sizeable chunks that are written in assembly language for better
performance.  A lot of the v2.0 restructuring was to make the system
portable to other (RISC'ish) platforms.

Since you're an IBM 'insider' maybe you know more than what I've heard. :-)

Thanks,
	John "What's the 'real' scoop?" Mitchell
	johnm@cory.Berkeley.EDU

P.S.	I speak solely for myself.
From: frazier@CS.UCLA.EDU (Greg Frazier)
Newsgroups: comp.os.research
Subject: Re: A challenge
Date: 10 Apr 92 17:39:45 GMT
Organization: UCLA, Computer Science Department
Originator: osr@ftp

Hello -
	I am (usually) a silent observer of this forum,
being a hardware person.  However, this has intrigued
me - I have a question.
ast@cs.vu.nl (Andy Tanenbaum) writes:

>I'll be a sport and go first.

>                              THE TOP FIVE

>   2. Synchronous (blocking) communication is easier to use than asynchronous.
>         Starting a send, then going off to do something, followed by getting
>      an interrupt when the send is done is a nightmare to program.  If you
>      must do something while waiting for the reply, put that code in another
>      (synchronous) thread.  The biggest problem in the computer industry is
>      not slow machines, but hairy, unreliable software.  Using asynchronous
>      communication just makes the problem worse.

Why are you interrupting a process after a send is done?  Why do
you care when the send is done? If you are using a machine that
supports distributed programs (hey, let's call it a multicomputer!),
then shouldn't the hardware be supporting communication primitives?
Please don't say "yes, they should, but currently they don't" - you
aren't designing OS's for current machines, I hope.  Not in research.

Also, why do you expect a reply for each send?  It seems (to
ignorant me), that in many situations, you don't expect one.  Even
when you do, you know that you can execute many instructions between
the send and the receive - stick them in there.  The arriving reply
does not have to interrupt the process - it can simply be queued up
until the process executes a receive (I should think).  If you must,
have the program issue a pre-receive to assign a memory location for
the arriving msg to be stored at.
-- 


Greg Frazier	frazier@CS.UCLA.EDU	!{ucbvax,rutgers}!ucla-cs!frazier
From: rminnich@super.super.org (Ronald G Minnich)
Newsgroups: comp.os.research
Subject: assumptions of OS builders
Date: 8 Apr 92 15:31:23 GMT
Organization: Supercomputing Research Center (Bowie, MD)
Originator: osr@ftp

Since this group seems to have revved up I thought I might 
drop in some comments on assumptions that some of us in 
the supercomputing community see in the research we 
have studied. Note: I want to differentiate "supercomputing" from 
"supercomputer". We do a lot of "supercomputing" here without 
touching a Cray, some of it via our own architectures. 

1) In a computer system, all significant computations performed on 
   data in the main memory are performed by fetching the data to the 
   CPU over the main memory bus, operating on it, 
   and storing it back to memory. (by significant I am trying
   to eliminate scsi interfaces, graphics hardware, etc. )
   
   This is manifestly false. It is currently true for all commercial 
   systems that OS researchers use, as far as we can tell, 
   but it is nevertheless false in general.

2) Due in part to (1),
   the limiting factor on networking bandwidth, application
   to application, is CPU-memory bandwidth.
  
   False.

3) Due to (2), it is reasonable and acceptable for a networking architecture to 
   pass all data (that transits the network) through the CPU once. 

   false.

4) Files in a file system can be characterized statistically 
   as having some mean size, with a very small standard deviation from
   that size. 

   false, at least in the case of the 'standard deviation', for us. 
   as someone here commented, in the supercomputing world, standard
   deviations tend to be kind of large. 

5) "most" files are less than 4K. Stated differently, the mean file size
   is around 40xx bytes, with a very small standard deviation. 

   Maybe true in environments that don't do a lot of computing. 

6) File migration is practical 
   for all cases, e.g. there is always room on a workstation disk
   for files that are referenced from that workstation. 
   There is thus no need for remote file operations a la NFS. 

   false. Or as someone commented here, "... this might apply for 
   1,000 students writing 'hello, world' in pascal ...".

7) a 4 Mbyte file is "large". Thus, all files of interest can simply
   be mapped into memory, obviating the need for read/write. 

   false. Maybe a 4Gbyte file is "large".  For now anyway. 

8) Files are small enough to fit on a disk.

   false.

9) Data sets for one problem are small enough to fit on the disks at
   one site.

   false. 

10) Optical networks have such a low bit error rate that we don't have
    to worry about drops or misorders any more. 

    I can't even figure out how low BER justifies the assumptions
    re ordering and drops. But I have at least one paper that makes this
    statement. 

ron



Newsgroups: comp.os.os9
From: lharris@hubcap.clemson.edu (Larry Harris)
Subject: Re: MM/1 sound port
Organization: Clemson University
Date: Wed, 15 Apr 1992 04:57:54 GMT

kdarling@garfield.catt.ncsu.edu (Kevin Darling) writes:
>session@seq.uncwil.edu (Zack C. Sessions) writes:
>>bcwhite@demorgan.waterloo.edu (Brian White) writes:
>>>Radio Shack sells a 5-pin din to 4xRCA jack that works.  Sorry I don't have
>>>the part number, but you should find it if you just look around for a bit.
>>
>>This has been claimed a couple of times on the CoCo BITNET Listserver
>>also, but I have gone to all of my local shacks, and none of the sales
>>persons knew about this part, nor could they or I find it in the catalog.

>The stock number someone put up a while back was 42-2394A.  I can't
>find it in my catalog, so either it's very old (likely) or very new :-)

Probably old and discontinued like every other cool part Radio Shaft
previously sold.  I've heard that they have/are cutting there parts
stock in half...  Oh well, I guess it gives me an excuse to go crazy on
my mail order parts, especially since I just ran $150 worth of stuff on
my VISA :-)

-- 
-Larry Harris-                |  '86 Mustang lx 5.0 notchback
lharris@hubcap.clemson.edu    |  Meyer's Tow'd Dune Buggy
lharris@clemson.bitnet        |  OS-9, a leaner meaner UNIX
Clemson Computer Engineering  |  RUSH, YES, R.E.M, The Who
From: rlm7638@tamsun.tamu.edu (Jack McKinney)
Newsgroups: comp.os.os9
Subject: OS9 C problem.
Date: 6 Apr 92 15:17:09 GMT
Organization: Texas A&M University, College Station


    I have a Color Computer III,  running OS-9 Level II. I am trying to
print a 'long' as a hexadecimal number in C.  Here is the code I am us-
ing:

 ...
 long addr;
 ...
 printf("%08x- ",addr);

    however, the output I get is '00000000- ', no matter what the value
of addr is. I am certain that addr is nonzero since I have compiled and
successfully ran the program on a Sun 4. I have also rewritten my OS9 C
program to print  the long by breaking it into two 'int's.  This works,
so I  know that addr is !=0.  I have tried using pflinit,  and it still
doesn't work. Any ideas?

+---------------------------------------------------+------------------------+
| "A lot of stuff in school... you don't appreciate | Jack McKinney          |
|  'til you get to be older, you know, little       | rlm7638@tamsun.tamu.edu|
|  things, like being spanked everyday by a middle- +------------------------+
|  aged woman... Stuff you'd pay good money for     | Blessed be the ties    |
|  later in life."      -Emo Philips                |      that bind...      |
+---------------------------------------------------+------------------------+
Newsgroups: comp.os.os9
From: UweKloss@lionbbs.bs.open.de ( Uwe Kloss )
Newsgroups: comp.os.os9
Subject: OS9 for ATARI TT
Date: 9 Apr 92 22:04:36 GMT
Reply-To: UweKloss@lionbbs.bs.open.de
Organization: The Lion Town BBS, Brunswik, Germany
X-Software: HERMES GUS 1.00 Rev. Jan 16 1992

Hi, out there!

Some time ago I sqeezed the bucks out of my pocket to buy a decent
operating system for my old ATARI ST. OS9, you will guess it.

Now (new job, more bucks) I switched to an ATARI TT and want to sell
my old ST (well not THAT much more bucks I guess) and asked my vendor
for an upgrade.

   PANIC: There is none!

They didn't even state that they plan PLAN to make one!
'Not available from Cumana' is all they say.

So, has anybody out there heared of an implementation of
OS9 running on a ATARI TT?

I don't like operating TWO machines and I would like to keep
the TT not the ST. And use OS9 of course!

Thanks, Uwe
-- 
Uwe Kloss               UUCP: UweKloss@lionbbs.bs.open.de
Fasanenstrasse 65       BTX:  0531336908 0001
3300 Braunschweig       FIDO: not connected
From: bmaddox@cs.umr.edu (Brian Maddox)
Newsgroups: comp.os.os9
Subject: Info on Listserv Problem
Date: 16 Apr 92 03:28:11 GMT
Distribution: usa
Organization: University of Missouri - Rolla
Originator: bmaddox@mcs213j.cs.umr.edu


Hi.  I was reading my messages and accidentally hit n too many times.
Someone had posted the answer to the question of why some files from the
listserver were messed up (had periods at the EOL).  Could the person who
posted this please E-Mail it to me or repost it for there are some files
I need.  Thanks.
                     Brian Maddox (bmaddox@cs.umr.edu)
Newsgroups: comp.os.os9
From: session@seq.uncwil.edu (Zack C. Sessions)
Subject: Re: MM/1 sound port
Organization: Univ. of North Carolina @ Wilmington
Date: Mon, 6 Apr 1992 18:02:55 GMT

bcwhite@demorgan.waterloo.edu (Brian White) writes:

>Radio Shack sells a 5-pin din to 4xRCA jack that works.  Sorry I don't have
>the part number, but you should find it if you just look around for a bit.

This has been claimed a couple of times on the CoCo BITNET Listserver
also, but I have gone to all of my local shacks, and none of the sales
persons knew about this part, nor could they or I find it in the catalog.
I also called the Tandy Computer Center, and they likewise had never
heard of one. IF you can dig up a stock number, I would be most
appreciative.

-- 
Zack Sessions
sessions@seq.uncwil.edu
csc450zcs@vxc.uncwil.edu
University of North Carolina at Wilmington
Newsgroups: comp.os.os9
From: kdarling@garfield.catt.ncsu.edu (Kevin Darling)
Subject: Re: MM/1 sound port
Organization: North Carolina State University
Date: Mon, 6 Apr 1992 18:23:39 GMT

session@seq.uncwil.edu (Zack C. Sessions) writes:
>bcwhite@demorgan.waterloo.edu (Brian White) writes:
>>Radio Shack sells a 5-pin din to 4xRCA jack that works.  Sorry I don't have
>>the part number, but you should find it if you just look around for a bit.
>
>This has been claimed a couple of times on the CoCo BITNET Listserver
>also, but I have gone to all of my local shacks, and none of the sales
>persons knew about this part, nor could they or I find it in the catalog.

The stock number someone put up a while back was 42-2394A.  I can't
find it in my catalog, so either it's very old (likely) or very new :-)

kevin <kdarling@catt.ncsu.edu>
Newsgroups: comp.os.os9
From: smcgee%peruvian.utah.edu@cs.utah.edu (Scott Mcgee)
Subject: Can someone help with an interfacing question?
Date: 17 Apr 92 08:53:01 MDT
Organization: University of Utah CS Dept

I am consulting with an EE group working on a Gespac OS-9 system (OSK v 2.3)
and they have to interface to it, a Gespac bus interface card (GESWWB-12).
I was wondering if anywone could help me locate any information on how to
address such a card in the VPA field, what exactly the VPA field is, what
the vector address within it are, etc. In general, I personally know very
little about this and the guys working on it seem to know less, if anything.

Any help, information, or suggestions of likely places to look for info
would be GREATLY appreciated.

Thanks

Scott


       The 8080 was a great chip in it's day. Pity that Intel's not been    
   ___ been able to improve upon it.  -  Tim Kientzle ______________________
   | Fred paid me $5 to express these opinions! They are all his! NOT mine |
   |__________ email:  smcgee%boxelder@cs.utah.edu (Scott McGee) __________|
Newsgroups: comp.os.os9
From: mm1@hounix.org (John Donaldson)
Subject: OS9 Community Network
Organization: Houston Unix Users Group
Date: Sun, 12 Apr 1992 14:22:25 GMT

  I wish to thank all of you who have responded with request for membership.
I am currently adding all of you into a database so I can keep track of you
all. Also your infor is  being forward to the Membership Coordinator. The
Secartary no longer handles the memberships. His name is Greg Morgan. If 
you have then FIDO Network in your area. Feel free to contact them and 
request that they obtain the OCNet.
  I will be shortly sending to all of you via E-Mail copies of the Jan
and Feb Newsletter. The Newsletter is a on-line newsletter. It was decided
to publish it this way instead of hard copy. Cheaper too. 
  The OCN maintains regional software libararies. IF you wish to contribute
please contact me via E-Mail. IF you are looking for a perticular program
or type of program, also send me E-Mail. I will see what is availiable and
get back to you on how to get the program to you.
   Again Welcome to the OS9 Community Network.


John Donaldson

OCN - Internet Coordinator.
-- 
******************************************************************************
* John Donaldson & Kevin Winkler ------------ You never know which one it is *
* ...zaphod.mis.ohio-state.edu!menudo.uh.edu!nuchat!hounix!mm1               *
******************************************************************************