HDTenEightyP/NetNews huggingface dataset:
From: ganesan@sybil.cs.buffalo.edu (Ravikanth Ganesan)
Newsgroups: comp.os.research
Subject: References on SUN OS
Date: 13 Apr 92 17:49:31 GMT
Organization: State University of New York at Buffalo/Comp Sci
Originator: osr@ftp

Subject: Referece request on SUN OS


I am a grad student and I have chosen SUN OS to give a term presentation on
the issues of Process Scheduling, Process Migration and Deadlock Detection.
Apart from the SUN Networkin Manual I have drawn a blank in locating informationon the above issues.

I am not looking for code. I am interested in the policy/mechanism of above
issues. (If you could provide info about an ftp site where I could get such
documentation it would greatly help me to complete this assignment). Please
let me know asap.

Ravi
From: yodaiken@chelm.cs.umass.edu (victor yodaiken)
Newsgroups: comp.os.research
Subject: Re: Have we learned anything in the last 20 years?
Date: 7 Apr 92 23:15:44 GMT
Organization: University of Massachusetts, Amherst
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
>   - 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. 

-- 


yodaiken@chelm.cs.umass.edu
From: bsmith@ecst.csuchico.edu (Charles Bennett Smith)
Newsgroups: comp.os.research
Subject: Microkernels and Nanokernels
Date: 6 Apr 92 16:36:37 GMT
Article-I.D.: darkstar.32228
Organization: California State University, Chico
Originator: osr@ftp


In the thread on 'Have we learned anything new in the past 20 years' mention
is made of microkernels.  In this months 'Embedded Systems Magazine' some-
thing called a nanokernel is mentioned.  Are these different names for
the same thing, or are they truely different concepts in operating systems
theory?

If you have information on the distinctions between these concepts, could
you please email to me?

-- Bennett

-- 

Lassen Research                                   Bennett Smith
300 Salem Street                                  bsmith@ecst.csuchico.edu
Chico California  95928                           (916) 343-6421
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:10:17 GMT
Article-I.D.: darkstar.32386
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Originator: osr@ftp

In article <32222@darkstar.ucsc.edu> werner@inesc.inesc.pt (Werner Vogels) writes:
>If this means that causal ordering can replace all other types of
>orderings (read atomic) I do not think this can stand. Causal ordering
>can be sufficient in those types of groups where the applications
>provides the serialization needed, for the types of applications that
>lack this type of support and that need stronger garantuees on how all
>participants receive messages, other orderings than causal are needed.
>
>-- 

Yes, but it is easy to build an atomic ordering over a causal primitive,
and the performance is just as good (lots of papers on this... including
one of mine, ACM TOCS Aug. 1991)

So, if the kernel is supposed to be small, and we won't lose performance
this way, doesn't Occam's razor argue for a user-level implementation of
atomic ordering?
-- 
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: arl@cs.hut.fi (Ari Lemmke)
Newsgroups: comp.os.research
Subject: Re: Have we learned anything in the last 20 years?
Date: 7 Apr 92 22:02:38 GMT
Article-I.D.: darkstar.32328
Organization: Helsinki University of Technology, Finland
Originator: osr@ftp


In article <32014@darkstar.ucsc.edu> ast@cs.vu.nl (Andy Tanenbaum) writes:
>      - Microkernels are the way to go

	Yes. But the term "microkernel" is not too good, because
	there are quite huge microkernels. Is there any better
	name for it?

>      - UNIX can be successfully run as an application program

	Sould be .. POSIX? But there has been fight already
	over this, like subjects "what's POSIX?" and "VMS gets POSIX",
	etc. [Still I feel UNIX is the interface and the kernel,
	and POSIX is just the interface].

>     - Message passing is too primitive for application programmers to use
>     - Synchronous (blocking) communication is easier to use than asynchronous

	Hmm. You're now thinking about programming with C?

	Message passing is not too primitive, if you hide it
	to some level ..

	Synchronous is easier to implement, but it really makes more
	complicated systems (Minix - heh ;-).

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

	Both - I like threads implemented kernel and user based, so
	one can tune his/her programs better. "microthreads".

>   Andy Tanenbaum (ast@cs.vu.nl)

	arl
From: bp@cs.brown.edu (Boris Putanec)
Newsgroups: comp.os.research
Subject: Re: Have we learned anything in the last 20 years?
Date: 8 Apr 92 23:30:16 GMT
Article-I.D.: darkstar.32426
Organization: Department of Computer Science, Brown University
Originator: osr@ftp

In article <32385@darkstar.ucsc.edu> ken@cs.cornell.edu (Ken Birman) writes:

   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.

Yes! 

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

But, if one has very cheap threads, RPC becomes attractive since
requests can be pseudo-asynchronous because they will not block the
entire program.

I like Plan 9's notion of very cheap processes, but am not sure if I
want to have 30 processes exist just because asynchronous RPC links to
other machines are needed. There is still a need for multiple
threads-of-control within a single program, if only as a convenient
programming abstraction.

And, threads should be split-level. As much work as possible done in
user-mode (co-routines for free) but with kernel interaction to ensure
fair use and overall scheduling.

boris
From: fouts@hplmf.hpl.hp.com (Martin Fouts)
Newsgroups: comp.os.research
Subject: More Abstract versus Less broken
Date: 7 Apr 92 20:19:38 GMT
Article-I.D.: darkstar.32330
Organization: Hewlett-Packard Labs
Originator: osr@ftp

henry@zoo.toronto.edu (Henry Spencer) writes:
|> rob@alice.att.com (research!rob) writes:
|> >   - Microkernels are the way to go
|> >	False unless your only goal is to get papers published...
|> >   - RPC is a good idea to base your system on
|> >	Depends on what you mean by RPC...
|> >   - Threads should be managed by the kernel, not in user space
|> >	Better: have a decent process model...
|> 
|> I'm reminded here of a recent piece from John Ousterhout in OSR, arguing
|> that the customers do not *want* wonderful new abstractions -- what they
|> want, mostly, is better implementations of the old ones.  Sounded good to me.

A former boss once told me that it gets very frustrating trying to
sell electricity to your customers when they keep asking you for
cleaner burning wicks for their oil lamps.  The argument shouldn't be
what the customer wants, but rather if they can do their job enough
better with the new paradigm to justify their cost in switching.

Anybody have any electricity for sale?  I can hardly see from the
smoke. 


-- 
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: mday@jukebox.lcs.mit.edu (Mark Day)
Newsgroups: comp.os.research
Subject: Reference for PenPoint
Date: 14 Apr 92 05:24:38 GMT
Organization: /u/mday/.organization
Originator: osr@ftp

A number of people have asked me for more details about PenPoint.  Here's
the full reference:

Robert Carr and Dan Shafer, The Power of PenPoint. Addison-Wesley, 1991.
342 pp., $22.95
ISBN 0-201-57763-1.

PenPoint is a commercial product, developed by GO Corporation.
Their address is printed in the book:
   950 Tower Lane
   Suite 1400
   Foster City, CA 94404

   Phone: (415) 345-7400

I have no connection to GO other than admiring their OS.

Some excerpts from the Introduction:

"PenPoint is a new operating system designed and built from the ground
up by GO Corporation for the unique requirements of mobile, pen-based
compters.  It is a 32-bit, object-oriented, multitasking operating
system that packs the power of workstation-class operating systems
into a compact implementation that does not require a hard disk."

"Under PenPoint, the pen is the primary input device.  The pen is used
for pointing (by touching the screen), data entry (through
handwriting), and commands (through gestures)."

"Mobility brings a number of key requirements, including deferred data
transfer, detachable networking, and low memory and power consumption."

"The most innovative aspect of PenPoint's Application Framework is its
Embedded Document Architecture, which provides three key user
benefits: the document model, live application embedding, and
hyperlinks."

"In PenPoint, the operating system performs the clerical bookkeeping
steps of starting and stopping processes (running applications) and of
loading and saving application data.  This is called a "document"
model because the user never deals with application programs and data
files or with the need to associate the two by loading files.
Instead, users simply move from page to page and always see their data
as they last left it."

"Live application embedding refers to PenPoint's capability to embed a
live instance of one application inside another application....For
example, a text document can, with no special programming on the part
of its creator, embed any other PenPoint application, such as a
spreadsheet or business graphics application, within a text document
it creates."

--Mark Day

mday@lcs.mit.edu
From: Helge.Oldach@Stollmann.DE (Helge Oldach)
Newsgroups: comp.os.research
Subject: Re: A challenge
Date: 15 Apr 92 11:53:55 GMT
Article-I.D.: darkstar.32999
Organization: Stollmann GmbH, D-2000 Hamburg 50, Germany
Originator: osr@ftp

lowry@watson.ibm.com (Andy Lowry) writes:
| 1. Distributed applications are just too complicated for programmers
|    to deal with.

Unless the distribution mechanisms of the applications written by the
programmers are transparent.

| 5. Transparent fault tolerance will be crucial.
|    [...] Applications need to be made fault-tolerant, but
|    it has to be done transparently.  Transactions provide a
|    semi-transparent mechanism in this regard, but transactions are
|    applicable only to a small fraction of the applications that people
|    use, even today.

This is true for large-grainsize transactions only, e.g. database
applications. Consider a machine based on an atomic and efficient
memory transaction mechanism, and one may probably be able to cover
many more applications. If you even hide the memory transaction
mechanism under the microkernel hood, you will receive transparency -
see above.

|    The failure should be transparent not only to programs,
|    but also to users.  More general mechanism will be needed, based on
|    tracking dependencies among process states and restoring globally
|    consistent states via checkpoints and log.

Where dependancy tracking might be the crucial point, i.e. tuning
of memory grainsize and the implementation level of the transaction
model (hardware, microkernel, operating system kernel, user level,
etc.).

Both the transaction mechanism and dependancy tracking need to be
very efficient, due to the fact that they are just "escape mechanisms"
for the case of failure. They must be invisible in the non-failure
case. Without efficient implementation of these we will end at Andy's
"Who cares about a factor of two" position, yielding a (for general-purpose
computing) useless machine.
-- 
Helge.Oldach@Stollmann.DE
From: yodaiken@chelm.cs.umass.edu (victor yodaiken)
Newsgroups: comp.os.research
Subject: Response to Birman (was Re: A challenge
Date: 13 Apr 92 14:46:03 GMT
Organization: University of Massachusetts, Amherst
Originator: osr@ftp


In article <32625@darkstar.ucsc.edu> ken@cs.cornell.edu (Ken Birman) writes:
>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

I'm puzzled by these  claims, as they directly contradict the evidence in 
the field. In particular point (e)  flies in the face of the 
many versions of networked UNIX around and  point (c) seem to ignore the
success of the Tandem operating system. These systems work, and work
pretty well. Even worse, there are thousands of networked operating systems
out there, doing a job that someone appears to like, and based on operating
systems far more crude than UNIX. From the actual evidence, it seems that
with enough work operating systems of the uni-processor era *can* be
integrated into networks, and the the results can function pretty well.
If you are going to claim that their underlying paradigms
are wrong, you should elaborate a little more. BTW, it is instructive to
comapre published file copy timing of "from scratch" distributed O.S.'s
like with how well "cobbled together" commercial UNIX machines work.
Last time I did this, the numbers were about the same, despite the
somewhat rigged nature of the results published for the distributed o.s.'s
(e.g., with the whole file being in memory before the copy started). 

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

Don't these contradict each other?

-- 


yodaiken@chelm.cs.umass.edu
From: bellcore!gizmo.bellcore.com!mo@uunet.UU.NET (Michael O'Dell)
Newsgroups: comp.os.research
Subject: Re: not liking certain things.....
Date: 7 Apr 92 03:02:39 GMT
Article-I.D.: darkstar.32274
Organization: Center for Chaotic Repeatabilty
Originator: osr@ftp

AIX on the RS/6000 is embarrassing???

how about OS/MFT in 1968 having threads????

how about MCP on the B5500 having real VM??

how about Atlas??  I'm convinced that essentially
everything worth putting in an OS today was understood by the Atlas
designers.

so have we learned anything in 20 years?  hmmmmm........

	-Mike O'Dell
	 resident crank

Bellcore??? Bellcore isn't allowed to have opinions, so these be mine.
From: lm@slovax.Eng.Sun.COM (Larry McVoy)
Newsgroups: comp.os.research
Subject: Re: Andy Tanenbaum hasn't learned anything
Date: 7 Apr 92 04:23:24 GMT
Article-I.D.: darkstar.32273
Organization: Sun Microsystems, Inc.  Mt. View, Ca.
Originator: osr@ftp

rob@alice.att.com (research!rob) writes:
:    - Threads should be managed by the kernel, not in user space
: 	Better: have a decent process model and avoid this process/thread
: 	dichotomy.

I couldn't agree more.  There is very little difference between a
thread and a process.  People who like threads are really just covering
up the fact that their processes have gotten too chubby.  Put 'em on a
diet, I say.
---
Larry McVoy			(415) 336-7627			 lm@sun.com
From: henry@zoo.toronto.edu (Henry Spencer)
Newsgroups: comp.os.research
Subject: Re: Have we learned anything in the last 20 years?
Date: 7 Apr 92 16:19:57 GMT
Article-I.D.: darkstar.32276
Organization: U of Toronto Zoology
Originator: osr@ftp

In article <32099@darkstar.ucsc.edu> stephen@estragon.uchicago.edu (Stephen P Spackman) writes:
>The only quibble I have is with "new languages": I think a better
>position is that "new languages are needed", stop, and it's a great
>pity that the goal of a really generally useful language seems to have
>died.

Just to be a heretic for a moment :-), I think "seems" is the right word,
and it reflects the political incorrectness of C and (sigh) C++ rather
than the practical reality of the world.  The goal is alive and well
outside the somewhat-ingrown language-research community, and moreover
many people think it has been achieved, to useful first approximations.
-- 
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: glenn@ready.eng.ready.com (Glenn Kasten)
Newsgroups: comp.os.research
Subject: Re: Microkernels and Nanokernels
Date: 8 Apr 92 21:25:54 GMT
Article-I.D.: darkstar.32425
Organization: Ready Systems
Originator: osr@ftp


In article <32228@darkstar.ucsc.edu>, bsmith@ecst.csuchico.edu (Charles Bennett Smith) writes:
|> 
|> In the thread on 'Have we learned anything new in the past 20 years' mention
|> is made of microkernels.  In this months 'Embedded Systems Magazine' some-
|> thing called a nanokernel is mentioned.  Are these different names for
|> the same thing, or are they truely different concepts in operating systems
|> theory?

A microkernel is usually defined as a relatively small kernel which is
primarily intended to be used in implementing higher-level operating
systems, rather than application programs.  Ready Systems uses the term
"Nanokernel", to mean an even smaller kernel which is primarily
intended to be used in implementing microkernels.

-- 
Glenn Kasten
Ready Systems 470 Potrero Ave. Sunnyvale CA 94086 
glenn@ready.com (408) 522-7357
From: lowry@watson.ibm.com (Andy Lowry)
Newsgroups: comp.os.research
Subject: Re: Have we learned anything in the last 20 years?
Date: 9 Apr 92 09:16:41 GMT
Organization: IBM T.J. Watson Research Center
Originator: osr@ftp

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.  These guesses dictate how we
proceed.  In the case where one of our guesses turned out to be wrong,
we'll need to use rollback or some other mechanism to undo the effects
of everything that we did based on the wrong guess, and then set the
world right with respect to what actually happened on that call.  As
long as our guesses are right a good percentage of the time, this
should be an effective way to fight the latency that some perceive as
inherent in RPC.  In cases where the returned value is void, we can
obviously always guess correctly.  There are other cases where we can
do pretty well, like when the return result is a success or failure
indication on an operation that almost never fails.

If you find this approach interesting, check out the paper by Bacon
and Strom:

@inproceedings{bacon:optpar,
    author="David F. Bacon and Robert E. Strom",
    title="Optimistic Parallelization of Communicating Sequential
    Processes",
    booktitle="Proceedings of the Third {ACM} {SIGPLAN} Symposium on
    Principles and Practice of Parallel Programming",
    year=1991,
    month="April"
}
--
Andy Lowry, lowry@watson.ibm.com, (914) 784-7925
IBM Research, P.O. Box 704, Yorktown Heights, NY  10598
From: fouts@hplmf.hpl.hp.com (Martin Fouts)
Newsgroups: comp.os.research
Subject: Re: Plan 9 process/thread comment?
Date: 8 Apr 92 16:16:59 GMT
Organization: Hewlett-Packard Labs
Originator: osr@ftp

In article <32350@darkstar.ucsc.edu>, philw@alice.att.com (Phil Winterbottom) writes:
|> 
|> >From: fouts@hplmf.hpl.hp.com (Martin Fouts)
|> >Subject: Plan 9 process/thread comment?
|> >Date: 7 Apr 92 16:30:35 GMT
|> >
|> >I think I'm missing something about plan 9 from the limited reading
|> >I've done.   In particular, how do you deal with ...
|> 
|> We are very interested in multiple processes sharing address spaces. What we
|> are trying to do is make the overhead of doing the management so small that
|> we don't need to distinguish between processes in the operating system and
|> some kind of other thread mechanism. Various pieces of operating system
|> support make this viable:
|> 
|> [ excelent description deleted ]

OK.  This is all good.  But it doesn't really address the question of
interaction.  It still costs you 250 instructions to get into the
kernel, as opposed to 1 instruction to get into a library level
scheduler, and I doubt it is going to get any cheaper.  I guess that
is why you have a co-routine package.  The problem comes when I want
to use the speed of the co-routine package and multiple cpus.  With
your approach I give up one or the other.

Marty

-- 
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: drs0587@sc.tamu.edu (Dave Safford)
Newsgroups: comp.os.research
Subject: Re: Have we learned anything in the last 20 year
Date: 6 Apr 92 16:36:23 GMT
Article-I.D.: darkstar.32226
Organization: Texas A&M University
Originator: osr@ftp


In article 32014@darkstar.ucsc.edu, ast@cs.vu.nl (Andy Tanenbaum) writes:
>
>I was wondering if we have learned anything about distributed systems in the
>last 20 years.  I mean, are there any statements we can make that are largely
>accepted in the computer science research community?
>
>GENERALLY ACCEPTED AS TRUE BY RESEARCHERS IN DISTRIBUTED SYSTEMS
>   - The client-server paradigm is a good one
..
>Andy Tanenbaum (ast@cs.vu.nl)

I would venture to say that the only concept generally accepted by one 
or more computer science researchers in distributed systems is that no 
concept (including this one) can ever be generally accepted.  
(...then again, maybe not :-)

dave safford (drs0587@sc.tamu.edu)