HDTenEightyP/NetNews huggingface dataset:
From: goykhman_a@apollo.hp.com (Alex Goykhman)
Newsgroups: comp.os.research
Subject: Re: Have we learned anything in the last 20 years?
Date: 9 Apr 92 18:31:27 GMT
Organization: Hewlett-Packard Corporation, Chelmsford, MA
Originator: osr@ftp

In article <32014@darkstar.ucsc.edu> ast@cs.vu.nl (Andy Tanenbaum) writes:
>
>I would venture to state that the following statements are now considered
>true by the majority of researchers in this area.  My question is, can people
>think of any more?  For fun, I have a second category of statements that I
>consider controversial rather than accepted as true.  Suggestions here, too,
>are welcome.
>
>GENERALLY ACCEPTED AS TRUE BY RESEARCHERS IN DISTRIBUTED SYSTEMS

>   - The client-server paradigm is a good one

        yes, in cases where the underlying communication between two objects
        is inherently asymmetric (i.e. one would not want to use the 
        peer-to-peer paradigm to communicate with a printer)

>   - Microkernels are the way to go

        somebody defined RISC as "any hardware architecture designed
        after 1985".  Same must be true about ukernels, except we can't 
        agree on what kernel is (what's an X-terminal running?)

>   - UNIX can be successfully run as an application program

        UNIX is no longer an OS but rather a collection of misc.
        interfaces/protocols.  An application program that emulates
        many enough of those is a unix.

>   - Caching at the file server is definitely worth doing

        yes, less so if clients do their own caching

>   - File server replication is an idea whose time has come

        yes, though more often to improve availability than performance

>   - Synchronous (blocking) communication is easier to use than asynchronous

        but it's usefulness is limited to certain classes of applications.
        It is not a question whether asynchronous communication is needed,
        but if it should be implemented via asynch. RPC, threads (my favorite),
        or some other mechanism.

>   - New languages are needed for writing distributed/parallel applications

        better support for threads/co-routines is desirable, but perhaps the
        current crop of "object-oriented" languages could be used to satisfy
        the need?

>   - Distributed shared memory in one form or another is a convenient model

        I believe so
>
>
>STILL HIGHLY CONTROVERSIAL
>   - Client caching is a good idea in a system where there are many more
>     nodes than users, and users do not have a "home" machine (e.g., hypercubes)

        c.c. a function of network latency/availability

>   - Atomic transactions are worth the overhead

        depends on the application's requirements/priorities





-- 
-----------------------------------------------------------------------------------
All opinions are mine, if you find one please return it to goykhman_a@apollo.hp.com
-----------------------------------------------------------------------------------
From: rminnich@super.super.org (Ronald G Minnich)
Newsgroups: comp.os.research
Subject: Re: Have we learned anything in the last 20 years?
Date: 7 Apr 92 03:17:11 GMT
Organization: Supercomputing Research Center (Bowie, MD)
Originator: osr@ftp

In article <32236@darkstar.ucsc.edu> craig@sics.se (Craig Partridge) writes:
>I can't agree with this view.  Distributed shared memory has the same
>latency problems as RPC and while I've seen some innovative ideas about
>relaxing consistency rules, I've yet to see work that suggests that 
>one doesn't at least sometimes get badly delayed by consistency requirements.

Actually, you have a point. Latency is there and won't magically go away
if you switch from RPC over a message-based network to a memory model over
a message-based network. How could it? 

BUT, the memory paradigm is something
I have found programmers can deal with MUCH more easily than RPC. 
The mechanics of pre-fetch are well understood (at least in my community)
and if you look at e.g. the Kendall Square machine (plug: or Mether)
you can also see an operation that KSR calls 'post-store' (we call it 
network refresh)- that is, 
pre-emptively store data in someone else's memory, knowing they will need
it, BEFORE THEY ACCESS IT. I have done some recent work here in which 
for a sample sort I would transfer data a megabyte or so at a time, using
post-store. Net results: since I used broadcast (i agree on 
broadcast/multicast, but don't have a handy multicast sytem available)
I post-stored the Mbyte into 15 processors. This gets me 15 times the 
effective bandwidth of my media (ethernet). And, when I was done, the 
applications just saw a big array to walk through, not a bunch of messages
they had to unpack. And they don't fault at that point. 

Also, in general, the people I work with have a much easier time
understanding (and dealing with) memory hierarchies that have 
varying latencies at each level than they do 'oh, you just went off-machine,
so now you have to use RPC or TCP or something'. At that point, most punt.

Our message-based progamming environments, from what I have seen, are doing
a lot to slow down the acceptance and use of distributed programming 
in many environments, except for the cases that can be handled 
'file-parallel'. 

If you want to see an interesting memory model, 
read the Dec Alpha architecture manual. This is pretty much the model
we use here for DSM. It is quite workable. They use memory barriers and 
relaxed coherency in their MP model for many of the same reasons we do
in our DSM.
ron
From: emery@Dr_No.mitre.org (David Emery)
Newsgroups: comp.os.research
Subject: Re: A challenge
Date: 13 Apr 92 20:33:20 GMT
Article-I.D.: darkstar.32804
Organization: The Mitre Corp., Bedford, MA.
Posted-Date: Mon, 13 Apr 1992 20:33:20 GMT
Originator: osr@ftp

>   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.

Now that I see what is blocked, I agree.  One of the major problems
with Ada running on traditional Unix systems is that, when one task
tries to do a system call (e.g. I/O), the entire process/Ada program
blocks.  This is true not only of Ada, but any other multitasking
language/program.  There are techniques in various flavors of Unix to
avoid this, but these techniques are not portable.  Thread blocking is
a good idea, as long as it doesn't have side-effects on the rest of
the program.

Incidentally, does everyone agree with the following:
	0.  Operating Systems are best implemented in high-level
	    languages.  
If so, does this argue for the use of higher-level languages in
contemporary O.S. implementations?  Is C (which has mediocre support
for data abstraction and/or object orientation) too low level?  

				dave
From: page@ficus.CS.UCLA.EDU (Thomas Page)
Newsgroups: comp.os.research
Subject: Re: Have we learned anything in the last 20 years?
Date: 6 Apr 92 16:39:38 GMT
Article-I.D.: darkstar.32229
Organization: UCLA Computer Science Department
Originator: osr@ftp

To the list of what we have learned, add...

Network Transparency.
	Ten years ago, there was considerable debate on this topic (see for
	example the debate held at the 1983 SOSP conference).  The debate
	strongly paralleled that held in the '60s over virtual memory.  On
	the one side, people said that humans could manage the limited main
	storage via overlays much more efficiently than could the OS.  On the
	other side, people said that the simpler programmer model was worth
	the slight penalty and that as programs got bigger, the lru algorithms
	might do better than hand overlays anyway.  Well, time has ruled pretty
	much in favor of virtual memory.  Similarly for network transparency.
	While few system (other than perhaps Sprite) have embraced transparency
	to the extent Locus did in the late 70s/early 80s, most distributed
	file systems and operating systems from NFS on have opted for a high
	degree of network transparency.  In fact, most people's complaints
	about systems like NFS concern precisely those points where network
	transparency breaks down, rather than where it hides machine boundaries.


To the list of controversial topics, add...

Optimistic vs. Pessimistic replica consistency control.
	Pessimism says, "inconsistency is so intollerable that we are willing
	to take expensive measures (like obtaining remote locks) to prevent it
	from occuring."  Optimism says, "inconsistent concurrent update is so
	rare in practice that it makes more sense to detect it and fix it up
	when it does occur than it does to go to great expense to prevent it."
	It sort of parallels deadlock detection vs. prevention.

	It seems that there is no right answer, but rather situations where one
	is best and situtations where the other is best.  So far, however,
	the conservative (pessimistic) approach (primarily inherited from
	the distributed database arena) has been most common.  Coda from CMU
	and Ficus from UCLA are examples of optimism in the replicated filing
	area.


Tom Page
page@ficus.cs.ucla.edu
From: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft)
Newsgroups: comp.os.research
Subject: Re: Have we learned anything in the last 20 years?+challange
Date: 14 Apr 92 14:01:27 GMT
Originator: osr@ftp


i) the best distributed system of any decent scale is the television
network (witness news from @#$% wars) - and the network news system:-)
however, there, reliability is not entirely an issue...=>

ii) failure semantics is the tricky bit 

- central systems fail in ways the average programmer can handle
- distributed systems fail in cute ways we get PhDs for studying

jon
From: jwang@white.toronto.edu (Jingwen Wang)
Newsgroups: comp.os.research
Subject: Tech. Report on Utopia Load Sharing Facility
Date: 11 Apr 92 20:51:14 GMT
Article-I.D.: darkstar.32707
Organization: CSRI, University of Toronto
Originator: osr@ftp


   As many people were complaining that the file for the report didn't print
well, we have found out the reason and reproduced the file. It should print
without problem this time. 

   The report has been updated with substential additions of new contents.
If you already got one before April 9, you may want to pick up the new 
version.

   The report is available by anonymous ftp to csri.toronto.edu or
snow.white.toronto.edu under directory white-technical-reports/257.


-- 
  {}
{}(){} -----> Jingwen Wang, Univ. of Toronto
  {}          jwang@snow.white.toeronto.edu
From: welch@parc.xerox.com (Brent Welch)
Newsgroups: comp.os.research
Subject: Sprite facts
Date: 8 Apr 92 17:04:09 GMT
Article-I.D.: darkstar.32423
Organization: Xerox PARC
Originator: osr@ftp


For the record:

The Sprite kernel is about 95,000 lines of code (written from scratch),
including one network protocol (kernel-to-kernel RPC), a distributed file
system that has a high-performance caching system and supports remote
device access, an upcall mechanism that allows a user process to implement
the naming and I/O interfaces of the distributed file system, process
migration so that running processes can move to idle workstations,
virtual memory, multiple threads per address space, including multiple
threads in the kernel, and multi-processor synchronization.  It is
4.3 BSD compatible and runs standard UNIX applications like X, mh,
emacs, csh, etc. etc.  It runs daily on Sun3, Sun4, DecStation 3100,
5000 architectures.  That's it, Sprite in a nutshell.

TCP/IP is indeed implemented at user-level.  It is not performance
critical in a Sprite network because most network traffic uses the
kernel-to-kernel RPC protocol. We were contemplating moving it into
the kernel, but I'm pretty sure it has not moved there.  The RPC protocol
will wrap itself up in an IP header if necessary, but the full routing
stuff associated with TCP/IP is not really supported in the kernel.

My comments on Mach and microkernels are just that I think important
functionality, in particular file system access, should be supported
in the kernel.  However, I also believe in general purpose ways of
implementing services at user-level so that the kernel doesn't have to
do everything.  A microkernel that moves all services outside the kernel
is an interesting academic exercise, but I think it will be too slow
to be competitive with a more traditional design.  Others might disagree,
but probe carefully to make sure they support all the quirky features
of UNIX such as shared I/O streams, signals, virtual memory, etc.
Mach is BSD compatible because it started with the 4.1 BSD code base.
After adding in a new virtual memory system and their IPC mechanism,
they have been pitching things out of the kernel.  For the code's sake,
I wish they had started from scratch, but...  The Mach microkernel was
about 60,000 lines last time I measured it, and the single-server for
the rest of the UNIX functionality was about 63,000 lines.  I wrote
a paper on this (The File System Belongs in the Kernel)
and presented it at the Mach Symposium, fall 91.  I've put a postscript
copy on parcftp.xerox.com in transient/welch/filesys.ps, and it will
linger there for a couple weeks before being removed.

	Brent Welch
	Xerox PARC
	welch@parc.xerox.com

--

	Brent Welch
From: page@ficus.CS.UCLA.EDU (Thomas Page)
Newsgroups: comp.os.research
Subject: Computer Security Course
Date: 6 Apr 92 21:25:03 GMT
Organization: UCLA Computer Science Department
Originator: osr@ftp

I am interested in developing a course on computer and distributed
system security.  If anyone has an outline of material they believe
should be covered in such a course, I would appreciate their sharing it
with me.  I have a tentative outline but I don't want to miss
anything.

Also of interest would be any comments on books available on the subject.
Thanks,
	Tom Page
	page @cs.ucla.edu
From: andrew@rentec.com (Andrew Mullhaupt)
Newsgroups: comp.os.research
Subject: Re: Have we learned anything in the last 20 years?
Date: 6 Apr 92 17:47:09 GMT
Article-I.D.: darkstar.32272
Organization: Renaissance Technologies Corp., Setauket, NY.
Originator: osr@ftp


In article <32100@darkstar.ucsc.edu> rminnich@super.super.org (Ronald G Minnich) writes:
>In article <32014@darkstar.ucsc.edu> ast@cs.vu.nl (Andy Tanenbaum) writes:
>>GENERALLY ACCEPTED AS TRUE BY RESEARCHERS IN DISTRIBUTED SYSTEMS
>>   - New languages are needed for writing distributed/parallel applications
>Absolutely. But new languages are needed for other reasons too :-)

I believe that the requirements of applications programming languages are
not the same as those of systems programming languages. How do OS people
feel about this?

Later,
Andrew Mullhaupt
From: stephen@estragon.uchicago.edu (Stephen P Spackman)
Newsgroups: comp.os.research
Subject: Re: A challenge
Date: 11 Apr 92 11:54:26 GMT
Article-I.D.: darkstar.32687
Organization: University of Chicago CILS
Originator: osr@ftp

In article <32644@darkstar.ucsc.edu> wkt@rodos1.adfa.oz.au (Warren Toomey) writes:
|> 3. RPC is a good idea to base your system on.
|>          SEND/RECEIVE primitives make I/O your central paradigm.

|Hell, make RPC your central paradigm for everything. The OS I've been working
|on (RHODOS BTW) has exactly _seven_ system calls: send,call,receive plus
|comms endpoint manipulation ones. Everything else is done by server processes.
|Makes the OS more modular and flexible, and easier to debug.

Be nice to pull it down to one. DoIt. But I'm a great fan of 1 as
God's Number. It makes it so much easier to predict what is going to
happen :-).

|> 4. Atomic group communication (broadcast or multicast) is highly useful.
|
|The provision of several types of multicast is even better, because each
|has a different purpose:

	   0 or more receive - non-blocking, no guarantee anyone will receive
			       it. Useful for transport protocols that want to
			       avoid state & can afford to retransmit a bit more.

	   At least 1 receive - blocking. Useful where there may be N servers,
				and a client only needs to get one answer back.

	   All receive - as per the reasons Andy stated.

But you also want at least $n$ receive, majority receive,
majority-in-this-partition receive, and so on. What's the appropriate
abstraction here? It's hard to find a clean line other than not
admitting to replication and trying to handle everything automagically.

|I'll add another lesson to the list: file mapping. This is great! It gets
|rid of multiple data copying (disk->buffer->user buffer), and means the
|whole of physical memory can be used as a disk cache. Moreover, if you
|use the paradigm of file-memory object equivalence, you can use the whole
|of the disk for paging, instead of just one partition. And the migration
|of processes and their memory can be done through a common file server,
|allowing the moving of the dirty pages only.

File mapping is only this efficient when you get a hit on local type
representation between the file and the processor. Unless - gasp! -
your files are untyped? ;-) So convert lazy, and use the same code as
for RPC....
----------------------------------------------------------------------
stephen p spackman         Center for Information and Language Studies
stephen@estragon.uchicago.edu                    University of Chicago
----------------------------------------------------------------------
From: geoff@world.std.com (Geoff Collyer)
Newsgroups: comp.os.research
Subject: Re: Controversy
Date: 8 Apr 92 14:57:48 GMT
Article-I.D.: darkstar.32387
Organization: The World @ Software Tool & Die
Originator: osr@ftp

Charles Shub:
>3.  you help me understand a rejection notice saying "why would
>    anybody in their right mind take that approach" is more reflective
>    of the bias of the referee (or my own inability to provide enough
>    context for the concept) than a comment on the worth of the idea.

Absolutely right.  Don't get too hurt by referees' comments; referees
sometimes are reviewing papers under deadline pressure, may be reading
material out of their field of expertise, may simply misunderstand, or
may have academic delusions that "people don't really do the awful things
you claim they do; they know better".  There is enough variability among
referees that it is often worthwhile to resubmit a paper, later, to the
same conference in the hopes of getting a better referee.

I have been a referee and I have seen examples of all the above in
referees' comments on papers I've written or co-written, so this is not
speculation.

The true value of an idea does not depend upon the current fads, though
current herd direction does affect acceptance of papers.
-- 
Geoff Collyer		world.std.com!geoff, uunet.uu.net!geoff
From: andrew@rentec.com (Andrew Mullhaupt)
Newsgroups: comp.os.research
Subject: Re: A challenge
Date: 13 Apr 92 15:51:43 GMT
Organization: Renaissance Technologies Corp., Setauket, NY.
Originator: osr@ftp


In article <32708@darkstar.ucsc.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
>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.

No. Memory mapped files (i.e. no read/write interface) are better. It's
just as good an abstraction, it's simpler to use, and usually performs
much better. Memory mapping is also fine on the network. In fact it's
better because it means some swapping doesn't get done. It's better
for providing heavy communication between applications than things like
shared memory or IPC. It also simplifies the OS implementer's job and
results in higher quality of implementation in my experience.

>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.

Nope. Memory mapped files are not a replacement for pipes, but they can
in fact do a lot of this gracefully. They can allow the OS to determine
the resource consumption of communication but also allow the programmer
to have a say, (you can map /dev/zero and let the OS do it or you can
put the file where you want if you know better). They are already better
for distribution than pipes and the programmer has more control over the 
failure modes if systems crash.

Later,
Andrew Mullhaupt
From: gillies@m.cs.uiuc.edu (Don Gillies)
Newsgroups: comp.os.research
Subject: Re: What's New in O.S. research
Date: 17 Apr 92 06:47:20 GMT
Article-I.D.: darkstar.33186
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Originator: osr@ftp

I predict that in five years, every decent OS will have a semi-portable
on-line code generation facility.

Ever since peter deustch and others decided that it made sense to
compile smalltalk code on-the-fly, or at least, it made sense to
compile bitblt code on-the-fly, the idea of a code synthesizer
facility has just kept growing and growing and growing (like savings
bonds).

The challenge in next-generation OS's will be to implement an
efficient code generator for a superscalar or superpipelined machine.

I just saw some new technical reports on this subject from
U-Washington.

- Don
From: daves@comp.lancs.ac.uk (Dave Stow)
Newsgroups: comp.os.research
Subject: Re: Have we learned anything in the last 20 years?
Date: 8 Apr 92 11:28:29 GMT
Article-I.D.: darkstar.32384
Organization: Department of Computing at Lancaster University, UK.
Originator: osr@ftp

In article <32014@darkstar.ucsc.edu> ast@cs.vu.nl (Andy Tanenbaum) writes:
>
>
>GENERALLY ACCEPTED AS TRUE BY RESEARCHERS IN DISTRIBUTED SYSTEMS
>   - Microkernels are the way to go
>   - UNIX can be successfully run as an application program

Yeah - Microkernels seem to be a good way of providing modularity and easy
porting, as little of them _has_ to be machine dependent. The services that
microkernels should actually provide seem to be rapidly decreasing as
time goes on...

UNIX should simply be run as an application on top your handy microkernel.

I believe that the next version of SunOS is due to be based on Mach? 
(Someone confirm/deny?!)

>STILL HIGHLY CONTROVERSIAL
>   - Threads should be managed by the kernel, not in user space

Sorry, no deal - Threads should be managed by split level system such
as Schedular Activation's (in 13th ACM symp. on Operating System Principles),
or UCB's work on Split level CPU scheduling. (Same)

Split level scheduling allows thread operations to be mainly done at the user
level - which is more efficient, but be correctly scheduled with all the
other threads around, done by interaction with the kernel. So best of both
worlds: more efficient thread operations, but kernel gets to direct 
global scheduling issues, and handle stuff like I/O properly.

How about:
STILL EXTREMELY CONTROVERSIAL
In the future machines will have _vast_ address spaces and loads of memory,
and everything will interact via procedure calls rather than IPC...

-Dave Stow
daves@comp.lancs.ac.uk
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Subject: Re: A challenge
Organization: University of California, at Berkeley
Date: Thu, 16 Apr 1992 17:18:47 GMT


 >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)

there are nearly 1000 million phones in the world  - this does not
mean that fax is the right way to do multimedia confeencing:-)
j.