agorics.com, thus, is a fun, fun resource. Not that there's any single
application or product yet; just as a repository of ideas and accumulated
visions. And they seem to digitize stuff all the time. Here's a fresh
pointer:
http://www.agorics.com/KeyKos/Concepts/welcome.html
describing a capability-based OS from twenty years ago that ran on IBM 360s.
Listen up Ernie, they had much of our theology of object trust... Excerpts
follow.
I recall I once FoRKed their guide to auction types, which was at least as
effective an introduction to the space of market-clearing games as
Caltech's econ program:
http://www.agorics.com/new.html
They have a marketing architecture, WebMart, and a programming language for
distributed secure systems, called Joule. There's a company blurb at the end
of this post.
Rohit
[off to a long-awaited assignation aboard flight 18 to JFK, learning that
big, bright 13.3" displays are NOT coach-compatible...]
Random Note: Ellen Ullmann (author of Technophilia and its discontents)
suggested the world needs a full-blown Being Analog to rebut Negroponte's
Being Digital. (after a chapter title from Don Norman's new book on
infoappliances, in the NYT)
----------------------------------------------------------------------------
--- Chapter 1. Introduction to KeyKOSGeneral Description
This publication is intended to serve as an introduction to some of the concepts embodied in the KeyKOS operating system. KeyKOS, implemented today for IBM 370 architecture computers, addresses the significant computing requirements of today and tomorrow. It provides benefits in the areas of performance, reliability/availability, programmer productivity, and security. The KeyKOS architecture employs the concepts of "capabilities" and "objects" to implement a system which carefully controls all communication between entities.
The entities are called "objects", and they combine the functions of programs and data.
The "capabilities", or as they are known in KeyKOS "keys", explicitly designate the addresses that one object uses to send messages to others. Thus, KeyKOS architecture is a compact wedding of communications, processing, and data. Because KeyKOS architecture hides the details of processors and instruction sets, it is suitable for both centralized and distributed implementations, and for systems with more than one instruction set.
The control that capabilities bring to communication and the modular construction that objects bring to programs and data directly support the design, development, operation, and maintenance of complex systems.
As important as what is provided by the KeyKOS architecture is what is not provided. KeyKOS does not implement many of the policies commonly provided by conventional operating systems. Policies for accounting, auditing, security, information sharing, scheduling, exception handling, naming and referencing files, for example, are not part of KeyKOS. Instead, KeyKOS provides facilities for an application to implement such policies on a case-by-case or system-wide basis.
...
Design Objectives
To achieve the objectives of performance, conceptual simplicity, robustness, ease of use, maintainability, and security, the following specific design goals were incorporated into KeyKOS:
* Allow partitioning and compartmentalization of both applications and the operating system itself to reduce apparent complexity and increase reliability.
* Prevent failures of individual system or application components from affecting the availability of other applications running on the same system.
* Provide a fail-soft architecture for both the operating system and applications that run in it.
* Reduce the amount of code an application must rely on, since the reliability of an application decreases as the size of this code increases.
* Allow replacement of system and application components on a per user basis without affecting the other components and thus jeopardizing system reliability for other users.
* Architecturally enforce certain structured programming techniques at execution time.
* Provide "industrial quality" program execution facilities.
* Produce a high security environment impervious to attacks by sophisticated application and system programmers.
* Provide for invisible (undetectable) dynamic auditing of application and system components by assuring the anonymity of all components, and by hiding distinctions between system-level and application-level components.
...
Authority
A second, even more serious problem with conventional systems is that the authority to do things (run programs, access files, etc.) is associated with an individual user name or address space...
Policy
A final difficulty with conventional systems is that the rules for who can do what to whom are an integral part of the systems themselves, and are often diffused throughout the system. Examples are rules like, "any program which runs under a user name may have access to all of the files owned by that user" or "anyone who can produce the correct password may access the file" or "no one except the owner may access the file". (Note again: the file must be owned by a user, not by a program.)
...
In each of these three areas - system organization, authority control, and scope of policy - conventional systems have built-in architectural barriers. It is not possible to correct them, retrofit them, or remove the deficiencies without completely redesigning these systems. The most reasonable solution to these problems is to implement a new architecture, designed to eliminate the deficiencies and take advantage of the hardware available in the computers of the 1980s. Yet such an architecture must provide considerable compatibility to protect investments in existing programs.
KeyKOS is such an architecture.
...
Objects
A KeyKOS object serves much the same purpose as an address space or a virtual machine in today's systems: it provides a place for the program and its data to exist and to execute. One difference is that a KeyKOS application will typically consist of several objects, each containing a small subsystem (typically 50-1000 lines of source code) implementing a specific function.
Each object is completely protected from unauthorized access or modification by programs in other objects and from unauthorized programmers. In effect, each object must be considered a "black box" by other objects and by unauthorized programmers. An object's inputs and outputs are documented as part of its external specification. However, the internal data structures, program organization, and algorithms are visible only to a programmer with explicit, authorized access to the contents of the object.
...
Keys
In addition to a program and some data, each object has a set of "keys" to some of the other objects. These keys will be given to the object by either its creator or by someone with the authority to connect the pieces of the application together. An object communicates with another object by invoking its key to the other object, passing whatever parameters are appropriate.
An object may only interact with those objects for which it has a key. It is not possible for a program to counterfeit a key. The interaction between two objects may only be of the form specified by the key. For example, an object with a read-only key to a file may not write into the file.
...
A second advantage of separating policy from its enforcement is that nearly all of the KeyKOS kernel may be easily incorporated into microcode, further enhancing performance, reliability, and security.
...
Perpetual programs are made possible by the implementation of virtual reliability. Virtual reliability allows KeyKOS programs to experience software and hardware reliability far in excess of that provided by the basic system upon which they run.
Every KeyKOS system takes periodic checkpoints of the entire system - all data, all programs, all processes, and all working storage. In the event of a system failure of any kind, the entire system and all of the programs within it are restarted from the most recent system checkpoint.
...
The most common object in KeyKOS is a domain. All programs except the kernel run in domains. A domain consists of a very large (2^48 bytes) virtual memory, general and floating point registers, and a program status word. In this sense, it is similar to a virtual machine (except that it does not have the many hardware-oriented features such as disks, tapes, printers, storage keys, etc.) or to an MVS address space...
All of the keys a domain can access are accessed through its set of key registers, each one of which is called a slot. The key registers are implemented in a segregated portion of memory.
...
To take any action a domain must consume resources (e.g. CPU time). The meter key associated with a domain allows it to consume resources. When a domain attempts to consume a resource, and its meter does not contain a positive value for that resource, an implicit invocation is made of a meter keeper key associated with the meter. Meter keepers may implement policies (scheduling, accounting, etc.) associated with the consumption of the resources controlled by the meter.
The segment key associated with a domain specifies the address space perceived by a program executing in the domain. When exceptional segment events occur (e.g. an attempt to reference a part of the address space for which no memory is specified, or an attempt to write to a read-only address), an implicit invocation is made of a segment keeper key associated with the segment. Segment keepers may implement memory management policy (allocation, sharing, auditing, billing, etc.).
[Presumably there would be a bandwidth key too, today -- RK]
...
[They have proxy objects, and thus the potential to interpose transparent invocation reprocessing and auditing . They call them scaffold objects, by analogy to testbed harnesses. (though in a strict mapping to asymmetric keys, an invocation against B's public key could ONLY be read by B, with no possibility of limited delegation (i.e. B would have to share its private key with an anonymous inteceptor, a catastrophic mistake)]
...
[Infospheres] Distributed Processing
Distributed processing is much easier to implement in KeyKOS than in other systems. Since applications are constructed as a number of independent domains, it is a simple matter to move some of the domains to another system. A domain that implements a general KeyKOS import/export function is spliced into the connection between domains on different machines.
Note that this operation is completely transparent to the domains in question (with the possible exception of performance). All of the complex protocols for remote access of data are in the import/export mechanism, not in the application programs. It is easy to develop and test the application on one system without remote systems for debugging. Applications may also be developed for a single system and distributed at a later date without reprogramming.
...
[A bit of trivia from their discussion (defensive) of performance:]
Multiple copies of data on disk improve read performance
When multiple copies of data are stored on disk, then read performance improves, since it is possible to select a copy of the data which is available for reading. Telephone directory information systems employ eight copies of directory information to improve read performance for this "retrieval only" OLTP system. KeyKOS can provide this (or higher) level of data replication, transparently to the application code.
============================================================================ ==========
Introducing Agorics
Agorics, Inc., a computer software consulting organization, specializes in the architecture, design and implementation of market-leading electronic commerce applications and technologies. Agorics designs and develops custom applications based on WebMart, a technology infrastructure that supports a full-service online market for electronic and material goods, protected by cost-appropriate security, and featuring electronic clearing of payments. This technology infrastructure is an ideal foundation for Internet and Intranet application development for any industry that can benefit from electronic commerce, including business, entertainment, and finance.
...
The Ecology of Computation -- a seminal work in the field of agoric computing.
The Digital Silk Road -- a draft of a proposal for including low cost payment transactions right into the communications protocol.
Proving Properties of Instruction-Level Programs--This work-in-progress describes The Bouncer, a program that statically checks program modules before loading and rejects modules that do not pass specific static checks.
KeyKOS Documentation --These papers describe the design and implementation of the KeyKOS Operating System. Agorics has made this information available because it records early ideas that influence current development at Agorics.