HDTenEightyP/NetNews huggingface dataset:
From: ken@cs.cornell.edu (Ken Birman)
Newsgroups: comp.os.research
Subject: Re: Have we learned anything in the last 20 years?
Date: 8 Apr 92 14:07:53 GMT
Article-I.D.: darkstar.32385
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Originator: osr@ftp

In article <32221@darkstar.ucsc.edu> stephen@estragon.uchicago.edu (Stephen P Spackman) writes:
>(on the subject of asynchronous communication requiring causality)
>Except, the user-perceived difference in the two is just that one
>works better. So are you really providing an argument against RPC, or
>just against naivete in its implementation?

I agree entirely with this.  What we favor is a "virtual" approach in
which the user sees the simplest possible user interface, while the
system cleverly sends messages asynchronously in such a way that nobody
notices.

With regard to RPC, though, the problem is that the actual semantics of
RPC are that the call is "done" when the caller regains control of the
processor.  So, this very strong semantic really limits the degree to
which an implementation can be clever...
-- 
Kenneth P. Birman                              E-mail:  ken@cs.cornell.edu
4105 Upson Hall, Dept. of Computer Science     TEL:     607 255-9199 (office)
Cornell University Ithaca, NY 14853 (USA)      FAX:     607 255-4428
From: rcbc@cs.cornell.edu (Robert Cooper)
Newsgroups: comp.os.research
Subject: Re: A challenge
Date: 16 Apr 92 21:04:53 GMT
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Originator: osr@ftp

In article <33002@darkstar.ucsc.edu> artg@minnow.watson.ibm.com (Art Goldberg) writes:

>    |> 1. If it's not written in C, nobody wants to hear about it.
>    |> 2. If it's not Unix or similar to Unix, nobody wants to hear about it.
>    |>
> 
>    Get real guys.  Just because the only computers you've used run
>    Unix doesn't mean that that's what the world uses.  There are
>    84 MILLION personal computers in the world.  Here is the breakdown
>    of the operating systems they run in 1991 (Source: InfoCorp via NY Times)
> 
>    71% DOS alone
>    9% DOS with Windows
>    7% Macintosh
>    9% Proprietary
>    2% Unix
>    1% OS/2
>   1% Other

What really bothers me about a lot of OS research is how insular much of it
is.  On the one hand many OS researchers do not have experience with
non-Unix operating systems and are unable to recognize the difference
between Unix system development and more general research. Many commercial
systems did think of some things before Unix did. Examples include threads,
virtual memory, virtual machines, typed files. (I'm not saying these are
all *good* ideas, but people should be aware of them.)

On the other hand, we have wildly successful commercial PC operating
systems like DOS which imposes memory restrictions on programs that are
orders of magnitude smaller than both primary and secondary storage limits
on current hardware, and provides not even rudimentary security features. 

This is a recipe for continually relearning five important things every
decade. 
                         -- Robert Cooper
--
--
From: rvinluan@cs.cornell.edu (Rolando Vinluan)
Newsgroups: comp.os.research
Subject: Re: A challenge
Date: 17 Apr 92 07:07:08 GMT
Article-I.D.: darkstar.33184
Organization: Cornell University, CS Dept., Ithaca, NY
Originator: osr@ftp

In article <1992Apr17.052821.9787@pasteur.Berkeley.EDU>, johnm@cory.berkeley.edu (John D. Mitchell) writes:
|> 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. :-)

	Since I'm sure most readers here don't read the comp.os.os2.misc
newsgroup (sometimes I wonder why I still do), a few weeks ago
Microsoft's Gordon Letwin (OS/2's first lead architect) went on record
saying that OS/2 has at least *1.6 million* lines of assembly code.
Though that figure might have applied exactly only to volume 1.x,
he says he's sure it's still more or less relevant to the new version.
While it's true that majority of the code is written in C, I wouldn't
call any operating system with that much assembly code as "portable."
From: mat@nella15.cc.monash.edu.au (mr m.j. hille)
Newsgroups: comp.os.research
Subject: Re: A challenge
Date: 14 Apr 92 02:40:08 GMT
Organization: Monash University, Melb., Australia.
Originator: osr@ftp

I am glad that there is finally some traffic in this news group.

% Yes, AST figured out a sure fire way to give me more work to do! --DL :-)

Here is my list of important ideas for distributed systems.

1. Object oriented design. The encapsilation of code and data with a
well defined interface. This allows objects to be accessed to be
accessed regardless of the location.

2. Incremental compiling. Besides being great for the development of
code. It also allows code to be migrated to other machine regardless
of the type of that machine.

3. Persistance. This removes the need for file systems. File systems
are always going to be a problem. The are given data to store, with
out the simple information that could make there work more efficent.
Persistant objects know about the type of data they hold. They can
choose the appropriate method of replication and update.

4. Reflection. This is an area that I am very interested in at the
moment. From my initial reading, reflection allows the behavior of
objects to be changed at a fundemental level. It also allows objects
to change behavior dynamiclly. It could for example be used to change
the behavior of an object at the point the object is migrated to
another machine.

A system constructed using these ideas will not run C code writen for
UNIX. IMHO it is these sorts of ideas that will produce the systems
that I want to use and program.

We have to start thinking beyond file systems, processes, RPC.

I would like to hear from anyone doing research about these sorts of
distributed systems.

In case my .sig does doesn't work my email is:
mat@nellads.cc.monash.edu.au

-- 
Matthew Hille, Department of Software Development, Monash University.
Mail: mat@nellads.cc.monash.edu.au
From: crispin@csd.uwo.ca (Crispin Cowan)
Newsgroups: comp.os.research
Subject: Re: Have we learned anything in the last 20 years?
Date: 6 Apr 92 15:50:59 GMT
Article-I.D.: darkstar.32225
Organization: Department of Computer Science, University of Western Ontario, London
Originator: osr@ftp

It seems clear to me from this discussion that in order to have a
successful distributed system, it is essential to plug your own system
in response to questions like this one.  :-) :-)

Crispin
-----
Crispin Cowan, CS grad student, University of Western Ontario
Phyz-mail:  Middlesex College, MC28-C, N6A 5B7
E-mail:     crispin@csd.uwo.ca		Voice:  519-661-3342 
"If you want an operating system that is full of vitality and has a
great future, use OS/2."  --Andy Tanenbaum
From: ken@cs.cornell.edu (Ken Birman)
Newsgroups: comp.os.research
Subject: Re: Have we learned anything in the last 20 years?
Date: 10 Apr 92 13:03:08 GMT
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Originator: osr@ftp

In article <32503@darkstar.ucsc.edu> lowry@watson.ibm.com (Andy Lowry) writes:
>In article <32428@darkstar.ucsc.edu> (Stephen P Spackman) writes:
>   In article <32385@darkstar.ucsc.edu> ken@cs.cornell.edu (Ken Birman) writes:
>   |With regard to RPC, though, the problem is that the actual semantics of
>   |RPC are that the call is "done" when the caller regains control of the
>   |processor.  So, this very strong semantic really limits the degree to
>   |which an implementation can be clever...
>
>   Surely the semantics are that the call be *seen* to be done when the
>   routine returns; the synchronisation can be delayed until at least the
>   next request (so long as it is understood that a Void return means
>   that NO information, not even there-was-no-error, is passed back).
>
>Even if there is information to be passed back, it's possible to take
>an optimistic approach here.  We allow calls to proceed
>asynchronously, and we make (hopefully good) guesses as to what the
>returned results are going to be.....

I was refering more to RPC as it is implemented by the major "standards"
groups, i.e. SUN/SVR4 RPC or DCE RPC, which doesn't use these sorts of
tricks at all.  Hermes, Mercury, and other enhancements all involve
system-wide changes that move from the domain of commercial practice into
expermental systems work.  For that matter, even Isis has a lot of
support for doing RPC-like operations asynchronously and collecting the
replies through a separate stream of return messages.  However, I wouldn't
call any of these "RPC systems".

I think it is important to distinguish between research and practice in this
area.  I don't dispute at all the idea that one could come up with a modified
type of RPC that would overcome the limitations of current RPC systems (and
I even agree that the systems you point to are very encouraging data points).

But, lets be realistic.  UNIX SVR4 has perhaps 80% of the market share
for UNIX workstations and the RPC technologies one sees over SVR4 are 
coverging towards DCE and SUN RPC.  So, I would tend to equate RPC with
these specific commercial products, and call all these other proposals
"extended RPC" or "asynchronous call-reply mechanisms" or anything else
that would clearly distinguish them from "commercial RPC."

Rephrased, then, my feeling is that RPC, in the form that the vendors
are providing it to the UNIX community, is hopelessly synchronous -- and that
the politics of the situation make it much more likely that this can be
attacked by introducing new abstractions (gasp!) like process groups and
group communication then by trying to talk the DCE people into changing
DCE to use something along the lines of the work done in Hermes or Mercury.



-- 
Kenneth P. Birman                              E-mail:  ken@cs.cornell.edu
4105 Upson Hall, Dept. of Computer Science     TEL:     607 255-9199 (office)
Cornell University Ithaca, NY 14853 (USA)      FAX:     607 255-4428
From: dm@think.com (dave mankins)
Newsgroups: comp.os.research
Subject: Re: Have we learned anything in the last 20 years?
Date: 9 Apr 92 03:36:52 GMT
Organization: Thinking Machines Corporation, Cambridge, MA (USA)
Originator: osr@ftp

In article <32422@darkstar.ucsc.edu> mjr@decuac.DEC.COM (Marcus J. "will do TCP/IP for food" Ranum) writes:
>daves@comp.lancs.ac.uk (Dave Stow) writes:
>>>   - Microkernels are the way to go
>
>	So the microkernel fanatics squeeze everything out of the
>microkernel and into user space. It's *STILL* there, and it's
>just as bloated - you've moved it. Big deal. [....] In the long run, what's
>the difference? 

The major difference I see lies in the vast superiority of the user-level
debugging environment.  KADB, bleah.  I want KSABER, or at least KDBX.

A second difference lies in the relative fail-soft behavior of user
programs versus kernel programs (my user-level server dies, I restart
it, maybe under dbx or Saber; my kernel-level server dies, I go get a
cup of coffee, and check the new acquisitions in the library while
waiting for the reboot and its disk-check to complete).  Loadable kernel
modules assuage this a bit, as long as your memory references stay
legal.

A further difference is: maybe it's not ``there'', maybe it's down the
hall.  After all, once you've put the narrow pipe between your
millikernel (probably really a decikernel) and your server, it is only
performance that keeps the server and the kernel on the same CPU.



-- 
david mankins (dm@think.com)	617-234-2756; FAX 617-234-4444
				Thinking Machines Corporation
				245 First Street; Cambridge, Massachusetts 02142
From: rminnich@super.super.org (Ronald G Minnich)
Newsgroups: comp.os.research
Subject: Re: assumptions of OS builders
Date: 10 Apr 92 10:55:16 GMT
Organization: Supercomputing Research Center (Bowie, MD)
Originator: osr@ftp

In article <32500@darkstar.ucsc.edu> kim@kowari.uwa.oz.au (Kim Shearer) writes:
>  Just telling someone their world picture is "false" is rather useless.
>  Could we have some explanation please, then we may learn something (other
>  than that you believe you are unquestionably correct).

Sorry if I was too strident. We all seem to be in a strident mood on this 
group  nowadays. Basically those points I raised were a reflection of 
reactions of supercomputing users to what they see as limiting assumptions
in work done in the OS (and particularly academic OS) community. 
We see a lot of assumptions that may make life easier for implementations,
and may work on campus, but fall apart when you get to our world. 
And they don't fall apart in small ways, either: they flat out don't work
at all. 

Which point do you have a question on? The points re files? 
People work with big files. Many of those files are bigger than the disks
on the workstations they use. Sometimes they are bigger than any one 
disk you can buy. Sometimes the data set is too large for any one site. 
Assumptions I have seen in print from the 
OS research world assumes either that "big" files can fit on the 
disk (all but the latest andrew work) or that it can even all be copied
into memory (Bullet). 

As for the point about the cpu-memory bandwidth not being the primary
bottleneck to getting computations done, that is just something I have
seen in action here at SRC as we have built this or that piece of hardware,
and then found the biggest single impediment to getting data out the door
was that the protocol stacks people are building, even the really fast ones,
assume that it is ok for the CPU too look at every byte of network data 
at least once (or in pre-van-jacobson code, many times).
Even the very fine work at Livermore is still willing to assume that 
passing over the data, from memory to cpu to network, is acceptable. 
But we can produce computational data at many times the cpu-memory bandwidth. 

We have found, for hardware that is sitting on a lab bench near me, 
that we need network architectures that don't require CPU involvement in 
moving every byte. I have at this point attended any number of conferences at
which OS researchers stated with confidence that the limiting factor on 
network bandwidth was cpu-memory bandwidth, that that would not change anyway
since the cpu had to do all the computations, so having the cpu handle every
byte was acceptable. It just is not so, at least for us. 
We have hardware here that belies this assumption and thus breaks a lot
of assumptions I see people making. 
And this is hardware that we have every reason to expect to see more of 
in workstations in the next few years. 

As for the comment on BER and its lack of relationship to drops and misorders,
any disagreement there? 

ron
From: jpab+@andrew.cmu.edu (Josh N. Pritikin)
Newsgroups: comp.os.research
Subject: Re: futures (was Async comm. vs RPC)
Date: 10 Apr 92 17:22:59 GMT
Originator: osr@ftp

> Futures allow RPC to be used intuitively *and* the RPC to succeed
> immediately w/o violating the semantics of the program. Futures are very
> efficient w/ tag memory support. However, futures can also be transparently
> supported through classes (C++ or otherwise) on systems w/o hardware
> support.

So what are futures?

( Josh Pritikin joshp+@cmu.edu
( It might be hot in Pittsburgh, but at least it's humid.
From: fouts@hplmf.hpl.hp.com (Martin Fouts)
Newsgroups: comp.os.research
Subject: Really Useful Language?  NOT!
Date: 7 Apr 92 20:15:19 GMT
Article-I.D.: darkstar.32329
Organization: Hewlett-Packard Labs
Originator: osr@ftp

henry@zoo.toronto.edu (Henry Spencer) writes:
|> stephen@estragon.uchicago.edu (Stephen P Spackman) writes:
|> >[...] it's a great pity that the goal of a really generally 
|> >useful language seems to have died.
|> 
|> [...] The goal is alive and well [...] and moreover
|> many people think it has been achieved, to useful first approximations.

On the other hand many people think that the set of commercially
viable useful general purpose languages is empty. (;-)

C and (perhaps) C++ are demonstrably useful for system programming
projects of the size of a single Un*x system on a single computer.  A
careful analysis of the difficulties which we are now facing trying to
support multiple platforms from the same source tree while dynamically
varing that source tree show that some of the problems could be
alleviated by facilities not present in these languages.   In
particular, there is not adequate support for runtime reconfiguration
or the underlying "package" (not to be confused with ADA packages)
semantic which would simplify much of the task currently faced by
those supporting multiple hardware platforms.

To understand the scope of the problem, you only need to spend time
comparing the various "configure" tools implemented by kernel
developers and then try to establish a way of resolving the same
problem with language facilities.  You quickly come to the conclusion
that certain language facilities coupled with more intelligent loaders
would make many of these problems "go away."

-- 
Martin Fouts                  |  M/S 1U-14
EMAIL:  fouts@hpl.hp.com      |  HP Laboratories
PHONE:  (415) 857-2971        |  1501 Page Mill Road
  FAX:  (415) 857-8526        |  Palo Alto, CA 94304-1126

Nothing Left to Say (c)
From: rminnich@super.super.org (Ronald G Minnich)
Newsgroups: comp.os.research
Subject: Re: A challenge
Date: 11 Apr 92 13:55:05 GMT
Article-I.D.: darkstar.32683
Organization: Supercomputing Research Center (Bowie, MD)
Originator: osr@ftp

In article <32622@darkstar.ucsc.edu> frazier@CS.UCLA.EDU (Greg Frazier) writes:
>If you must,
>have the program issue a pre-receive to assign a memory location for
>the arriving msg to be stored at.

hoo ha. In fact, take this a little further, and it starts to
look a lot like memory a remote write to your memory. 
Funny how people who know hardware like to think in terms of 
mapping network ops to stores at the receiving end, eh? 
ron
From: ken@cs.cornell.edu (Ken Birman)
Newsgroups: comp.os.research
Subject: Re: A challenge
Date: 10 Apr 92 19:52:11 GMT
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
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.

OK...

1) Distributed systems aren't like timeshared processors; the techniques that
   we used successfully on timeshared machines can't be used transparently
   in networks and hence are not adequate.  In particular:

     a) Fancy file systems aren't enough
     b) RPC isn't enough
     c) Distributed systems aren't transactional database systems
     d) Single threading doesn't suffice
     e) The UNIX model can't be supported as if the system wasn't distributed

   (all of these points are negative hence I'll count them as a single one)

2) Most complexity can be concealed from distributed systems users with an
   adequate base of tools, perhaps integrated into an OO language/environment.

3) Distributed systems need distributed programming constructs: IPC, RPC,
   process groups, causal multicast, failure detection services.

4) Distributed systems should be: self-managing, fault-tolerant, consistent,
   deterministic in the presense of concurrency, secure.

5) Latency is the bottleneck; avoid synchronous interactions at all costs.
   Buffer and cache if you can; use causal ordering to conceal asynchrony.
-- 
Kenneth P. Birman                              E-mail:  ken@cs.cornell.edu
4105 Upson Hall, Dept. of Computer Science     TEL:     607 255-9199 (office)
Cornell University Ithaca, NY 14853 (USA)      FAX:     607 255-4428
From: cosc161m@menudo.uh.edu (92s07275)
Newsgroups: comp.os.research
Subject: URGENT: OS/multimedia papers needed as soon as possible
Date: 10 Apr 92 05:49:34 GMT
Organization: University of Houston
Originator: osr@ftp


        I am writing a survey paper on "multi-structured I/O file systems that
use various techniques to provide higher data transfer rates for multimedia
applications on object-oriented distributed computing systems."  I would
appreciate it very much if anybody knows of any ftp sites for OS/multimedia
papers.  Also, if you have a copy of any of the papers (postscript format)
mentioned below or know how to contact the authors of the papers or have other
papers relating to OS/multimedia, could you please email the papers or any
information on how to obtain them or other papers to me as soon as possible.
My email address is:   cosc161m@menudo.uh.edu


I already have the three papers at the "icsi-ftp.Berkeley.EDU" site in the
directory "pub/dash".
********

        In particular, I am looking for the following papers:



"Designing file systems for digital audio and video"

Authors: P. Venkat Rangan & Harrick M. Vin
DEPTCSE., Univ. of California, San Diego
Proceedings of the 13th Symposium on Operating System Principles
ACM. SIGOPS 13 Oct. 1991



"Support for Continuous Media in the DASH systems"

Authors: David P. Anderson, Shin-Yuan Tzou & Robert Wahbe
Proc. 10th International Conference on Distributed Computing Systems
Paris, May 28-June 1, 1990.
IEEE



"Distributed processing of multimedia information"

Authors: E. Moeller, A. Schller & G. Shunmann
Proc. 10th International Conference on Distributed Computing Systems
Paris, May 28-June 1, 1990.
IEEE.

***************

      I am also trying to find any papers from the: 
Proceedings of the International Conference on Multimedia Information Systems,
Singapore, Jan. 1991.


"A Variable Rate Strategy for Retrieving Audio Data From Secondary Storage"

Authors: A. Park & P. English
Proceedings of the International Conference on Multimedia Information Systems,
Singapore, Jan. 1991, 135-146.



"Abstractions for Continuous Media in a Network Window System"

Authors: D.P. Anderson, R. Govindan and G. Homsy
Proceedings of the International Conference on Multimedia Information Systems,
Singapore, Jan. 1991.


*************
        And finally,


"A Testbed For Managing Digital Video and Audio Storage"

Authors: P.V. Rangan, W.A. Burkard, R.W. Bowdidge, H.M. Vin, H.W. Lindwall
         K. Chan, I.A. Aaberg, L.M Yamamoto & I.G. Harris
Proceedings of the 1991 Summer USENIX Conference, Nashville, TN, June 10-14,
1991, 199-208.



"Principles of Delay Sensitive Multi-media Data Storage and Retrieval"

Authors: J. Gemmell & S. Christodoulakis
ACM TOIS (to appear), 1991.

****************************************************************************
Rahul Aggarwal, Graduate Student at the University of Houston.

"Report Due at the end of this month, so PLEASE email replies soon"

                 !!!Resources at library are next to nothing!!!
****************************************************************************
From: eepjm@wombat.newcastle.edu.au (Peter Moylan)
Newsgroups: comp.os.research
Subject: Re: A challenge
Date: 14 Apr 92 05:40:15 GMT
Organization: University of Newcastle, AUSTRALIA
Originator: osr@ftp

In article <32798@darkstar.ucsc.edu>, axb@cse.nd.edu (Arindam Banerji) writes:

>    Most system and application software is written in high-level languages
>    these days (except in DOS ofcourse). Applications are built around the

I'd dispute this.  An awful lot of software - and I use the word
"awful" advisedly - is still written in C.

In response to the original challenge, here is what I personally
have learnt in the last 15 years:

1. If it's not written in C, nobody wants to hear about it.
2. If it's not Unix or similar to Unix, nobody wants to hear about it.

-- 
Peter Moylan                      eepjm@wombat.newcastle.edu.au