[See Alan Kay's Etech 2003 Presentation for something comparable
to what MOSES was intended to be.  The second half of that presentation
covers Croquet.  There was no affiliation between Kay and MOSES.]

CONTENTS

1. INTRODUCTION

In the context of pioneering network extensible virtual reality systems, MOSES is the Meta Operating System and Entity Shell from the early 1990's.

A decade following its origins, the design is reviewed from a contemporary perspective. Materials presented within our older documents are unnecessary since those emphasized qualities now taken for granted yet unique at the time.

The system architecture described below comes from a modern perspective using varying degrees of computer science concepts.

Forward-looking propositions are left for other papers.

Highlights of the system are presented without a comprehensive explanation of the design. Key details are stated when appropriate to illustrate uniqueness.

Most subsections include a brief statement putting that portion into context of the times-- past and present.

2. HISTORY

MOSES, the Meta Operating System and Entity Shell, was never fully implemented as a platform for virtual reality.

It existed only as a collection of technical documents. Even the archives at the Human Interface Technology Lab (HITL) in Seattle were incomplete. Many of the original documents were never published or even circulated at the Lab.

As an implementation, its source code was never released to the public.

The name for this system created a self-fulfilling prophecy. Some argued whether MOSES ever really existed. Consortium members of HITL such as Division from Bristol in UK investigated the architecture for their own products. This made the design historically significant.

3. CONTEXT

Putting the times into perspective, the early 1990's saw the creation of Oak (later renamed Java), HTTP and streaming media. MOSES was conceived before anyone heard of these other technologies outside of their respective labs.

On the wireless front: cell phones were bulky things mounted in cars, pagers still belonged primarily to medical staff.

Graphical user interfaces were yet to become mainstream as the Macintosh had only recently released it first color model, Windows286 was a novelty item, and NeXT was expected to be the future. The i386 processor was high-end, and the DEC Alpha (not yet Compaq Alpha) was still on the drawing board.

The term ``virtual reality'' had only recently been overheard from Jaron Lanier. VR meant using VPL's Data Glove and Eye-Phones, thus using a Macintosh II with dual SGI Iris workstations broadcasting onto their own private 10base2 Ethernet network.

SimCity was new, and the first force-feedback coin-operated arcade game, Hard Drivin', was introduced.

4. RATIONALE FOR THIS DESIGN

Our intentions were making computers easier to use.

Previous experiences with artists attempting to use early graphics workstations came as inspiration and motivation.

Building on the fact that people know how to interact with the world around them, we sought to mimic those familiar elements. It was about bending the tool rather than the person.

5. ARCHITECTURE OVERVIEW

MOSES was originally described as merely bringing together technologies from other disciplines.{Eclectic} That was paying respect to the underlying technologies. Distributed systems, network engineering, artificial intelligence, expert systems, as well as computer graphics were drawn upon.

In the end, many familiar with the architecture stated it was definitely more than just the sum of its parts.

Some familiar with the state of the art even proclaimed this to be a paradigm shift.

Unfortunately, the design was never manifested as a working system.

But even theoretical systems have value when understood and re-applied appropriately.

Data Versus Function

By design, there was a lack of distinction between data and function. Within a collection of data, each parameter may have been a static value such as ``4'' or actual code to be executed. The memory management structure would identify the data type and utilize it appropriately when accessed.

Today, good object-oriented style dictates using accessor methods for all member fields of a class structure. This effectively permits the same abstraction.

Note that the C++ language was still undergoing significant changes at the time. Those with direct knowledge of OO principles were obscure by even academic standards then, let alone finding anyone with extensive experience.

Beyond n-Dimensions

This was an information engine capable of supporting unlimited dimensions.

Previous VR systems were 3D. Animation environments were considered 4D (though technically just three and a half dimensions). Physicists claimed there were between eleven and thirteen dimensions to the universe.

Going beyond the limitation of the phenomenal world, MOSES supported an arbitrary number of dimensions. Specifying n-dimensions was limiting because a quantity for n would be required.

By thinking of it as arbitrary information, we transcended restrictions of ordered tuples. The value was the ability to override conventional uses of data.{Concept}

For example, the point located at (x,y,z) took on other meanings when the geometry of the world is change. Transposing the meaning of the first, second and third elements, a different geometry effectively mapped the coordinates to (z,x,y). Coordinates translated within a database was too time consuming. This approach permitted on-the-fly alterations.

Such changes provided more value when dealing with larger numbers of parameters. More significance became apparent with textures generated as functions instead of stored as static values.

Recall that in 1990, interaction with databases was direct. (Similarly, CAD systems still shipped with their own sets of device drivers.)

Today, transposing of information would be done through a plug-in or broker mechanism-- the database driver could be changed at the very least.

That abstraction was rare if it existed at all then.

Changing The Geometry

Altering the use of individual dimensions essentially changed the geometry.

What does it mean to change the geometry? Few know the answer because few actually experienced it.

From a research perspective, we should instead ask:

1. What are the implications when we change the geometry from Cartesian to Spherical?
2. What advantages would an Escher-esque geometry allow? Consider recursion in just one dimension, then two and so on.
3. How might scientific visualization benefit from experimental geometry systems?

And that was the point of virtual reality then and now.

Even today, we lack sufficient understanding of this medium to effectively label it, much less utilize it beyond interactive games and simulations.

Recursion In The System Design

There were three primary elements to the architecture of MOSES:

• memory
• communication
• function/execution

Each was able to be described in terms of the others. For example, memory had read and write operations, hence, could have be categorized as `function' or `communication.'

Communication was also viewed as `memory' in that the parameters were stored remotely. As `function', read/write operations also applied.

Function was also seen as the activity of servicing `communication' or `memory' based upon the primitive methods that performed the operations.

The cross-over distinctions were subtle but significant. The mind-set offered recursion in the design. And as the classic tenet of design went, ``elegance means nothing else could be removed,'' our program code served multiple duties.

A design with recursion made the implementation simpler. This translated into a smaller and more efficient code base. That, in turn, led to reduced bugs and anomalies since core code served multiple features.

Such a goal is usually impractical to achieve.

It was, however, demonstrated within the tiny MOSES kernel.

Principles of Network Engineering

From studying under Dr. Dave Mills of the original Internet Protocol research team, his principles of network engineering were applied.{Mills}

The principles are as follows.

1. You cannot anticipate all the faults.
2. All fault scenarios will happen at least once.
3. No one single strategy will work.
4. The system must be self-correcting.
5. But each correction must not increase vulnerability.
6. No system will always obey these rules.

Amendment:

• No system works correctly.

Implementation Hint: Use unique time-outs such that even in combination they become signatures of where problems may exist. (This, for example, is how the phone company recovered from a major outage in early 1991.)

The principles applied to the system architecture were summarized in {Design}.

6. SYSTEM DESIGN

System Features

Just about everything listed as high points for MOSES in 1991 and 1992 became industry buzzwords since then.

1. scalable -- easily extended for capacity growth
2. distributed -- spanning local and wide areas
3. fault-tolerance -- graceful fail-over and recovery
4. robust -- handle various qualities of service and loads sufficiently

Some elements still uncommon:

• user-centric -- the person controls the views of data
• closure -- interconnections within data maps

User-Centric View of Data

In a time when most computer users were still isolated to the technology sector, focusing on people having control over their data was relatively novel. The idea existed for some time but was barely used. It wasn't until Archie{Archie} and later the Web that made this idea widely understood.

The approach for MOSES was permitting modification of the system while it was running. (See System Variables below.)

A user-centric view of data was coupled with the notion of closure in Archie.

Closure

What we meant by closure simply referred to all sides referencing one another. With these references when a change occurs, all parties referencing the data may be notified.{Closure}

Since this is still an uncommon feature, an example outside of computer science might help. Consider product registration for things from automobiles to televisions. Some manufacturers notify their customers when a new or related product is offered. Maintaining that relationship requires the customer notify the manufacturer should their address change. That's a manual technique but closure, nonetheless.

For distributed databases and caches, closure helped objects remain current without the problems of centralized or singular storage.

We utilized closure within our distributed memory system, the DataSpace.

DataSpace

The DataSpace was shared memory management and storage.

The data elements being manipulated were similar to tuples {LINDA} but recursively nest-able. At the time, our definition violated the term, so ``grouples'' were used instead. (Gelernter later refined his definition of a tuple, accounting for nesting.{Lifestreams})

There were a few basic operations on the DataSpace:

1. New
2. Delete
3. Select
4. Copy
5. Evaluate
6. Substitute

Management of the DataSpace in a distributed environment was elaborate. Nesting and recursion were possible with the data structure. Only the depth immediately required would be transferred. This eliminated side-effects from recursive data.

Extensive research into caching was done to find elegant solutions for keeping data from becoming unsynchronized.

Most of the concepts today are considered standard design practices for any cache mechanism with two important exceptions: MOSES included closure and migration of ownership for preserving data integrity. (As stated above: Closure simply refers to having both sides reference one another so that when a change occurs, all parties referencing the data may be notified.)

Migration of ownership was more than data migration. In our distributed, shared memory facility, the design made it possible to control data in a foreign computer. As part of such management, relocating the data across the network was sometimes required-- but not always.

In addition, performance and reliability issues within the memory system were addressed through mediation of brokers and authority with authentication. With Kerberos-based schemes deployed in mainstream operating systems, this finally became a well-understood topic.

Inference

Building upon the VEOS design, the core of the system was an inference engine.{VEOS} In other words, ``match-and-substitute with execution'' was the heart of the system.

Think: expert system.

Programmable Protocol

For extensibility on the network, the communications protocol itself was programmable.

The general idea was to provide flexibility, customization and optimization in the host-to-host interaction.

Consider the Web with the original version of HTTP, also from 1991.{HTTP0} Imagine if the web browsers were able to collect the HREF tags from a single page and download the contents via batch processing. (Although HTTP/1.1 provides for this through a revision in the mid-1990's, remember that MOSES was specified in early 1991.)

It worked by using a simple syntax programming language such as Lisp as the basis. That much was identical to VEOS. MOSES introduced the notion of a meta-machine language which would be an optimized version: byte-compiled, marshalled/serialized/pickled, etc. Today, XML-RPC or SOAP could satisfy the functional requirements, but a terse form was preferred then.

The nature of the protocol was similar to the syntax of Common Lisp. The purpose was that grouping was available (nested lists that we called "sublists"), and named parameters (keywords) could be used. (The rationale is identical to advocacy for XML.{XML}) Beyond that, Lisp behavior was optional in MOSES yet enforced in VEOS.

The overall direction of Java's early research applied to MOSES. The key element was to make that lower layer inter-operable, then the high-level language syntax became irrelevant. As with Java's Class file structure, it would be possible to transcribe other languages into that form.

While attempting to resurrect MOSES in the mid-1990's, a project from the UK called Taos was available.{Taos} It was a hardware-independent machine language that translated to native code on-the-fly while being read from the disk or network. It offered distributed and parallel processing. This offered an ideal form of compiled code for the MOSES meta-machine layer. (See Meta Layer below.)

The intent of MOSES was to make communications more efficient than commonly available in the day-- particularly when sending updates from an entity that rapidly changed direction. Update messages were optimized, reducing network capacity and processor requirements. (Remember: megabit Ethernet was still a long way off, and fibre networks were still highly proprietary until FDDI was later ratified.)

The idea was to permit macros for automating and minimizing updates. If only the (x,y,z) coordinates changed, only that one tuple was sent. Likewise, if only orientation parameters changed, only that portion of the record was sent. It was deemed unwise to send the entire list of geometric qualities for each update. Qualities might have included: orientation normal, scale in each coordinate plane, color, textures, sound cues, etc.

Some information was of course sent during initial registration. From that base, macros would be generated within the communications protocol for abbreviating update messages.

The possibilities of a programmable protocol accounted for remote behaviors much like applets and client-side scripting from Web sites. (See Agents For Behavior and Remote Behavior below.)

Meta Layer

With a programmable protocol, the middle tier of software was also able to be implemented within this communications protocol.

All middle-ware --as the concept is commonly referred to now-- could be migrated from host to host. This was in terms of both file servers and application servers.

If a virtual environment required specific functionality otherwise unavailable by the host platform, the libraries were downloaded on demand. Again using Java as reference, the applet hype also applied here.

As with Java class files and virtual machines, system independence was the goal. This went far beyond hardware independence in anticipation of multiple vendors supplying unique implementations of the kernel. Likewise, within a server farm you were free to use a mix of hardware architectures such as from Sun, IBM, HP, etc. As long as there was a kernel available, the rest of the system was specified to behave identically. (And we know how well it worked for Java...)

System Variables

We took the concept from VEOS another step. Internal variables were directly accessible to the user. This was similar to later systems such FreeBSD with its sysctl utility.{FreeBSD} As with FreeBSD, security was controlled via access controls lists (ACLs) as the main differentiator from VEOS.

This feature permitted the system to be changed-- reconfigured-- from within. Focusing on user-centric views of data, such a level of user control was paramount.

Upgrade A Running System

Formally called dynamic linking, loading and binding-- this permitted software components to be upgraded while the platform was operational.

This seemed like a superfluous element yet was very significant. The servers that hosted virtual environments would needed to be operational for long periods of time.

The criteria paralleled contemporary Web and database servers today. While many techniques existed such as data redundancy, master-slave relationships, etc, this was another item for the arsenal.

If the server continued running throughout an upgrade procedure, the overall availability greatly increased. Server availability also became the focus of the Web content hosting community. The reasons were the same.

7. DATA STRUCTURE

The internals of the kernel relied upon a structure that resembled an inode from the Berkeley Fast File System for Unix.{BSD} This relation was only logical but initially explicit.

Final Structure

Ultimately, it was understood that high degrees of flexibility could be attained using lazy or late binding of data types. This lazy evaluation is well known to programmers of Python, Perl, Ruby, Lisp and others where values have type but variables do not.

The kernel data structure was merely a container for higher levels to manipulate.

The net effect provided for a mechanism similar to Python classes.{Python} With both environments, fields were inserted into a record dynamically. This was distinctly unlike most strongly typed languages where structures became frozen upon compilation.

The data type void* gave us flexibility such as insertion of a record from compiled C object code. The intended use, however, was that each element was free to have its own type.

Some record elements might have contained a type foreign to the local system. As long as that item was unused locally, interpretation of its value would never be evaluated.

Rather than elaborate upon how the higher levels would operate on the above structure, just refer to a contemporary implementation of Python.

Early Structure

Initially, however, all of the fields were presented explicitly. Each had a specific data type-- an additional record.

Going back even further, one document presents a two tiered data structure. The idea was to separate the management from the data being tracked. The structure in the paper submitted to SIGGRAPH 1991 {Entity} was a prototype that was never fully implemented.

Note: designs of data structures accounting for abstraction were still far from mainstream. The number of people with practical C++ experience then was relatively small since the language was standardized the prior year.

8. INDUSTRIAL QUALITIES

There are several qualities MOSES was to possess: scalability, a distributed system, fault-tolerance, active abuse prevention-- all to provide robustness.

Note that most of these terms became buzzwords in the mid-1990's and the concepts taken for granted only in the late-1990's.

Scalability

Referring to any architecture as `scalable' had many implications then and now. First, there was accounting for future directions of the technology and applications the designers never conceived.

Second, the system was expected to perform sufficiently under various loads. This applied to network congestion as well as within a single server or workstation. By accounting for various levels of detail (LoD), the protocol throttled how much information was transmitted and/or what was to be processed.

The various factors regarding LoD may be found in contemporary (circa 2001) works from Intel Architecture Labs. {MRM} {SDS}

Distributed System

By distributed system, we referred to an architecture that, as a whole, spans both local and wide areas.

Today, it might be called a server farm that supports some form of geographic load balancing.

The general idea was to account for both centralized servers as well as peering.

The model of a centralized server allowed for ease of telco style structure. This translated into benefits with authentication from a security perspective. The model dated back to the Multics project in the 1960's.{Multics}

The peer model is optimized for certain types of usage where there might be groups of participants collected in close proximity.{Amoeba}

Combining the two models, however, offered additional strengths. We were able to take advantage of propagation for data-flow as well as multicasting or broadcasting.

Questions were raised: What happens when the model switches from server-based to peer-based? What are the behaviors when either mode is used exclusively?

The implications of letting the system dictate its own laws of nature are still unknown. So many systems strive to mimic the phenomenal world that the intrinsic nature of a virtual environment are lost.

The intent was to support both types of data-flow, offering a wide range of applications and experiments.

Distributed Memories

Within a distributed system server farm, the load would be shared by all servers. This required memory sharing, caching, data migration and load balancing of network connections.

Memory within a shared environment worked by the distinction of entity ownership. Cached copies might have existed on several hosts, but only one was the owner. The owner might have granted permission for remote entities to send updates, or it might have transferred ownership to the remote entity even though it continued to reside locally.

The front-end load balancer has become a common element in Web content hosting server farms. The concept was to distribute network connections to any one of the available servers in the back-end farm. While MOSES specified this to work with agents measuring performance of back-end machines, that element was made obsolete as the computational power and network capacity grew throughout the 1990's.

Fault-Tolerance

Graceful fail-over and recovery were challenges for application service providers-- as they still are today. Effectively using level of detail (LoD) lent support for fault-tolerance as well as scalability. (See Scalability above.)

In addition, when a resource disappeared, it was useful to re-establish the previous connections permitting communications to continue where they left off. Apart from a catastrophic failure yet allowing for a server completely resetting/rebooting itself, this was an option. This functionality was directly supported by offering closure. (See Closure above.)

Abuse Prevention

Prevention and containment of abuse was addressed through Intrusion Countermeasures Entities (ICE). Intrusion detection agents were to run within the servers observing anomalous behavior.

This was more than just filtering since state values were maintained. Should sufficient sequences occur, the host system disabled an offending entity by denying it any further processing.

Recall that the early 1990's were still a time of trust on the Internet. Stateful firewalls only became mainstream as 2000 approached. Network firewalls were practically nonexistent then. There was essentially protection by isolation. The military dealt with the issue of bridging the `black' and `red' networks through strict regulations which led to the early firewalls.

Robustness

The MOSES specification demanded industrial qualities of robustness: whatever happened, the system would return to an appropriate fail-safe state.

In a virtual environment, having the system shutdown or crash was unacceptable. All non-military head-mounted displays (HMDs) obscured the view of the physical environment. Abrupt shutdowns left the participant completely disoriented.

The fail-safe mode was intended to preserve minimal orientation to the participant within an inclusive environment. For example, the system might have displayed only a minimal ground-plane and status message to maintain satisfactory continuity for the person using the system.

This addressed issues similar to what pilots face in extreme weather conditions where they must rely upon their instruments. Expecting such mastery by non-technical users, however, would be unacceptable by our criteria.

9. USING MOSES

Some concepts alluded to in this document are now explained further.

Conversational use of words such as `entity' and `space' were sufficient for understanding the basic ideas thus far.

Here are more formal explanations.

Entities

The base concept for using MOSES was the entity. Mathematically speaking, it meant ``that which exists.''

It was highly significant that graphical components were omitted from the basic element. Some entities lacked any graphical objects whatsoever.

An entity might have been an intelligent agent. Another might have been just a collection of graphical objects. Others might have included both qualities.

When graphical objects were mentioned in the context of MOSES, it was always in the plural. Other systems forced the grouping of graphical elements together into a single blob. A driving model was presenting a flock of birds. The next step was how to present a flock of unrelated objects such as a few light-seeking cubes, some sound-sensitive spheres and perhaps an reverse gravity dweller or two.

Using the recursive aspects of the design, each item was its own entity; yet, collectively, the entire flock was a single entity as well.

Spaces and Superspaces

The `DataSpace' was the functional component; `spaces' were what the participants deal with.

The mathematical definition of a space is simply to group or contain entities. And again, an entity is simply that which exists-- usually within a space or collection even if there is only one in the group.

A room in a building could have been represented as a space, or the entire building could have been a single space. It depended on the application.

A superspace accounted for multiple intersecting, overlapping spaces. The distinction was more for fine-tuning memory management yet provided an abstraction beyond the lower-level OS-like intricacies.

A superspace might have been represented as a single room with participants entering from various remote networks. The superspace allowed for additional constraints to be put on the room.

Consider a crowded room you've been in recently. There may be hundreds of people, yet you can only see and identify about a dozen. You must move or others must move through the crowd for you to see them.

And so with a superspace, the visible room was essentially segmented. It was unnecessary having geometric segments. It might have been based upon network proximity (hop count) or weight (speed, bandwidth, capacity).

A superspace might have been a room effectively spanning multiple servers.

Information was transferred by propagation: routed through the chain of servers before being passed to the participants. All the servers for the room, however, would not necessarily receive their updates before participants would. That, again, would depend upon intended application. So a participant within the server originating an update might process the message before other servers would even receive their updates.

Recall that there is always an intrinsic behavior of the system when all simulations are disabled-- sort of its own laws of nature. Experiencing a superspace distributed over a wide area would illuminate this nature. Yet this is the very nature most developers of distributed virtual environments seek to eliminate or hide.

The significance of a superspace beyond the distinction of a space was this: An intelligently written entity could have queried the system to determine the whether a superspace versus simple space was in use. Then that entity could have made appropriate decisions based upon the information. A perfect example of this was for negotiating common Levels of Detail (LoD) for all participants within a room for a simulation or teleconference.

In most applications, however, only the agents running on the servers hosting the virtual world needed to deal with this distinction. We encouraged keeping agents naive for simplicity.

If any system features relied upon that distinction, the base classes within the standard libraries for entities using that particular world would handle the complexities.

Agents For Behavior

Virtual bodies are now commonly referred to as avatars. (We too were toying with ancient terms. From the Yogic tradition, we sometimes used the words `atman' and `anatman.')

As humans in everyday life, rather than focusing on movement of individual fingers, we think about what object to grab.

Likewise, intelligent agents were specified to deal with peculiarities of moving each digit, each finger, each hand and possibly the entire arm.

These agents might have been simple rule-based bots or complete expert systems. It depended on the application. Applications spanning from training simulators to tele-presence control of robots on other planets were anticipated.

Remote Behavior

Today, running an applet or client-side scripts is the accepted state of technology.

This was a key element of MOSES for the sake of putting sensor and actuator code close to primary sources.

That permitted the sensor of an entity to be an agent grappling an object when many network hops must be traversed and immediate feedback was impossible. (Think of a hand picking up a tool, albeit one that is very far away.)

A common example used in discussions of networked virtual environments raised the following question: Is it more important to see proper placement of individual limbs from a squid dancing rather than merely having behavior that one might recognize as dancing?

Just as web sites used applets animating graphics, MOSES accounted for sending code to be executed for different types of behavior.

10. CONCLUSION

MOSES is a significant virtual environment system that never was. Its significance is the weave of features creating an overall behavior that is far more than the sum of its parts.

Many elements that were championed in the design are now taken for granted. We have the Web to thank for bringing many of these technologies to the general computer industry through web browsers, web servers, database servers and web content hosting server farms.

As an implementation, MOSES is dead and its source code never released.

Some of the elements are still unique to networked virtual environments. Further research into the state of computer science should be performed and this architecture revisited before moving forward.

As a researcher and developer, it's important to note something. Any system is going to have its own intrinsic nature. For a distributed system, there will be artifacts. When data migration is employed, side-effects will be apparent. Yet this is part of the system's natural behavior. Let the system have its own characteristics! Any simulation of the phenomenal world should be clearly identified as such, and keep such things at the application level so the user may easily change it.

For the only forward-looking comment in the paper, here is a suggestion of what the future holds for VR. People will use this technology first expecting it to mimic the phenomenal world around them. That is only natural. People need something familiar as a basis in order to learn something new. Yet once they've come to understand this new thing, turn off the simulations one-by-one. Let them know that some rules may be bent, others may be broken and understand that truly, there is no spoon. Free your mind!

---

11. REFERENCES

1. {Eclectic} Using Large-Scale Operating Systems' Design for An Eclectic Design, Pezely; TR-92-6, Human Interface Technology Laboratory, Washington Technology Center, University of Washington, Seattle, WA 98195 US; May 1992.
2. {Design} The Design And Implementation of the Meta Operating System & Entity Shell (MOSES), Pezely, Almquist, Evenson, Bricken; TM-93-1, Human Interface Technology Laboratory, Washington Technology Center, University of Washington, Seattle, WA 98195 US; May 1991.
3. {Entity} The Entity Model: A Second Step Towards Virtual Reality, Pezely, Evenson, Almquist, Bricken; TR-91-5, Human Interface Technology Laboratory, Washington Technology Center, University of Washington, Seattle, WA 98195 US; January 1991.
4. {Concept} The Design of The Virtual Environment Operating System, Pezely; hitl.7.everything, Human Interface Technology Laboratory, Washington Technology Center, University of Washington, Seattle, WA 98195 US; August 1990.
5. {Mills} Network Engineering, Mills, D.; Electrical Engineering Department, University of Delaware, Newark, DE 19716 US; 1991.
6. {Archie} The Virtual System Model for Large Distributed Operating Systems, B. Clifford Neuman; 89-01-07, Dept of Computer Science and Engineering, University of Washington, Seattle, WA 98195 US; April 1989.
7. {LINDA} ``Applications Experience with Linda,'' Carriero, N., Gelernter, D.; Symposium on Principles and Practice of Parallel Programming, Proceedings of the ACM/SIGPLAN, Volume 23, Issue 9, September 1988, pp. 173-187.
8. {Lifestreams} ``Lifestreams: An Alternative to the Desktop Metaphor,'' Gelernter, D., Fertig S. and Freeman E.; Proceedings of CHI'96.
9. {VEOS} The VEOS Project, Bricken, W. and Coco, G.; R-93-3, Human Interface Technology Laboratory, University of Washington, Seattle, WA US; 1993.
10. {HTTP0} The Original HTTP as defined in 1991, Berners-Lee, T.; World Wide Web Consortium, Massachusetts Institute of Technology, Cambridge, MA US; 1991. http://www.w3.org/Protocols/HTTP/AsImplemented.html
11. {XML} Extensible Markup Language, World Wide Web Consortium, Massachusetts Institute of Technology, Cambridge, MA US; 1996. http://www.w3c.org/XML
12. {Taos} ``Parallel Course,'' Pountain, D.; Byte Magazine, July 1994, starting p54. http://www.byte.com/art/9407/sec6/art1.htm See also: http://tao-group.com
13. {FreeBSD} The FreeBSD Operating System, The FreeBSD Project; 1995-2001. http://www.FreeBSD.org
14. {BSD} The Design and Implementation of the 4.3 BSD UNIX Operating System, Leffler, S.J., McKusick, M.K., Karels, M.J., Quaterman, J.S.; Addison-Wesley Publishing Company, New York, NY US; 1989.
15. {Python} The Python programming language, Python Software Foundation; 2001. http://www.Python.org
16. {MRM} Multi-Resolution Mesh, Intel Architecture Labs; 2001. http://developer.intel.com/ial/3Dsoftware/mrm.htm
17. {SDS} Subdivision Surfaces, Intel Architecture Labs; 2001 http://developer.intel.com/ial/3dsoftware/subdiv.htm
18. {Multics} Organick, E., The Multics System, MIT Press, Cambridge, MA US; 1972.
19. {Amoeba} Tannenbaum, A.S.; Renese, R. van; Stavern, H. van; Sharp, G.J.; Mullender, S.J.; Jansen, J.; van Rossum, G., ``Experiences with the Amoeba Distributed Operating System,'' Communications of the ACM, vol. 33, no. 12, December 1990, pp. 46-63.
20. {Closure} Neuman, ``The Need for Closure in Large Distributed Systems,'' Operating Systems Review, Vol. 23, No. 4, October 1989, pp 29-30.

---