🚀 go-pugleaf

    Newsgroups: sci.virtual-worlds
    From: carter@ecf.toronto.edu (CARTER EDWARD A)
    Subject: TECH: OS Design?
    Date: Sun, 20 Dec 1992 22:29:33 GMT
    Organization: University of Toronto, Engineering Computing Facility

    Bonjour.

    I'm curious as to the current efforts with regards to virtual
    environment Operating System design.  Specifically, have any standard
    metaphors been agreed upon or at least discussed?  I'd greatly
    appreciate information, such as books and periodicals, which discusses
    recommendations and proposals of such metaphors for an OS.


Howdy.

For OS designs which would be well suited for virtual environments (VE-OS),
first get familiar with the history of the key OSs.

It's too early inthe game to look for VE-OS standards.  Find what's the
best and what's standard in other OSs, then apply that to your *own* VE-OS
design.  (Just because the HITLab calls their system ``veos'' doesn't mean
it's the only way to do it; besides, there's peaceful disagreement within
the Lab about implementation designs.... :)


Here's what worked for me:

 1. Skim read _The Multics System_, Organik, MIT Press, 1972, for general
concepts which have been around for the past 25-30 years.

 2. If you're not intimate with Unix, check out a book by Rob Pike called
_Software Tools_ (I believe), where he stress the power of pipes and
filters through the use of simple little programs which all unix uses have
come to know and love.  The philosophy of the combined powere of these small
simple tools is what's important, not the details.  Again, just skim read
this one.  It's probably out of print by now.

 3. Moving on to the implementation details, get a copy of _The Design and
Implementation of the 4.3BSD Unix O S_, Leffler, McKusick, Karels, and
Quarterman, Addison Wesley, 89.  Focus on the chapters on communication:
ipc, rpc, and ip.  

And always read the history, goals, philosophy, and strategy chapters of all
these books....

Since VR is a mechanism for allowing people to communicate effectively,
become deeply familiar with networks, routing, and robustness.

 4. Work through _Computer Networks_, Tanenbaum, Prentice Hall.  Some prefer
the original 1981 edition, others the newer, 1990(?).  For the sake of
gaining familiarity, either will do, the earlier edition being easier to get
through since it has fewer implementations covered.

 5. Learn how a specific protocol works from the ground up.  Read
_Internetworking with TCP/IP, Volume II_, Comer & Stevens, Prentice Hall,
1991.  Play with KA9Q (check Archie), if you want to tweak existing code.


Then you'll know the factual history.

To learn about the creative side, seek out a net god (not necessarily a
net.god).  Find someone who worked on the original ARPANet project or a
similar one, if possible.  Monitor comp.dcom.telecom to find some.  Poke
around various campuses around the world to find others.  This is the most
valuable because these folks don't write much about this aspect of the
history.  Learning how they did what they did, why, and what not to do, will
save out tremendous amounts of time when you begin your own work.


Read comp.os.misc, comp.os.research, and comp.tech-reports to find out
who's who in academic OS work *today*.  

Grab (anonymous ftp)   titania.mathematik.uni-ulm.de:pub/DOSlist*.ps
(that's Distributed OS, not ms-dos)
It's an annotated bibliography with most/all-known current projects.


Then, for your own design work, begin with the question:

What is *a* reality?  (think in generic terms)

Here's my answer (formalized after the HITLab design discussions)--
the context which information is used, information being anything
acknowledged as anything (thus represented, when on a computer).

Then, think of what you want to do with that information and the types of
contexts you wish to provide/use.  For some, it's 3D graphics with
attributes and spacial sound; for others, it's simply message-passing,
leaving the rest up to the developer of the VE.  Remember, this is the OS
level.  You don't have to deal with all the top-level VE issues here, unless
you really want to.  (``you can, but you don't have to'' was a common
argument in our design group.)

Focus on this question and *your* answers, then re-examine the current OS
projects.  This will give you the bias you need to form your own design.

You will most likely believe that every paper you read contains your ideas,
but none may have all the pieces together.  That was the case with the
HITLab ``VEOS'' design, back in the summer of 1990.

I believe that a VE-OS is a systems project, requiring no new computer
science theory.  After all, let's play with what we have before rushing
off to create new paradigms.  That will all come eventually.  Hold off on
your wild and crazy ideas for your second OS....

But whatever you do, don't make my mistake:
Implement the damned thing.  Don't waste time trying to get approval or to
sell the idea on people.  Just research it, ponder it, then implement it.
If you have no funding where you are, find a way to subsidize yourself or
work elsewhere.  Don't let the muck of your organization get in your way.

 !
--
Pez@hitl.washington.edu

      ``Everyone has a little secret he keeps.
        I light the fires while the city sleeps.'' -MC 900 Ft Jesus