Ontogeny Recapitulates Phylogeny

Charles Darwin

The Initial Keys

Slot 0 (WOMB_FACIL) Facilities: a fetch key to a node with:
Slot 0 (WOMB_FACIL_FUND) Fundamental Facilities; a fetch key to a node with:
Slot 0 (WOMB_FACIL_FUND_DISCRIM) The Key Discriminator {(p2,discrim)}

Slot 1 (WOMB_FACIL_FUND_DKC) The Data Key Creator {(p2,datac)}

Slot 2 (WOMB_FACIL_FUND_RETR) The Returner {(p2,retner)}

Slot 4 (WOMB_FACIL_FUND_SBT) A space bank transformer to whom the space bank (p3,initsb) is official. {(p2,sbt)}

Slot 5 (WOMB_FACIL_FUND_FACTORYC) A Factory creator {(p2,factoryc)} with no recall rights produced by the factory creator creator {(fcc)}

Slot 6 (WOMB_FACIL_FUND_FCC) The Factory creator creator (p2,fcc)

Slot 1 (WOMB_FACIL_SUPP) Supplementary Facilities: a fetch key to a node, or later, a read-only snode, with:
Slot 0 (WOMB_FACIL_SUPP_DCC) A domain creator creator {(p2,dcc)}

Slot 1 (WOMB_FACIL_SUPP_SNC) A supernode creator {(p2,snodecr)}

Slot 2 (WOMB_FACIL_SUPP_FSC) A fresh segment creator {(p2,fsc)}

Slot 3 (WOMB_FACIL_SUPP_GRCV) The transfer mechanism receiver {(p2,grcv)}

Slot 4 (WOMB_FACIL_SUPP_NEVER) The NEVER key {(p2,never)}

Slot 5 (WOMB_FACIL_SUPP_TSSC) The terminal support system creator {(p2,tssc)}

Slot 6 R3270F.

Slot 7 (WOMB_FACIL_SUPP_SWITCHC) The switcher creator {(p2,switcher)}

Slot 8 (WOMB_FACIL_SUPP_VDKC) The virtual domain keeper creator {(p2,vdkc)}

Slot 9 (WOMB_FACIL_SUPP_RCC) The Record Collection Creator {(p2,rcc)}

Slot 10 (WOMB_FACIL_SUPP_CLOCK) The System Clock Reader {(p2,clock)}

Slot 11 unused

Slot 12 (WOMB_FACIL_SUPP_BSLOAD) The bootstrap loader {(p2,bsload)}

Slot 13 unused

Slot 14 (WOMB_FACIL_SUPP_VCSK) A Factory for zero VCSK segments {(p2,vcorig)}.

Slot 15 (WOMB_FACIL_SUPP_PDDTC) The Peek DDT Creator {(p2,pddtc)}

Slot 16 (WOMB_FACIL_SUPP_BSTSCC) The Byte Stream to Segment Convertor Creator (p2,bstscc)

Slot 17 (WOMB_FACIL_SUPP_STRCCC) The Segment to Record Collection Converter Creator (p2,strccc)

Slot 18 (WOMB_FACIL_SUPP_BSCR) The Byte Stream Creator (p2,bscr)

Slot 19 (WOMB_FACIL_SUPP_FGRCV) The Factory GRCV (p2,fgrcv)

Slot 20 (WOMB_FACIL_SUPP_SRUP) The Segment Receiver and UnPacker (p2,srup)

Slot 21 (WOMB_FACIL_SUPP_VBSTIOC) The Factory VBS Terminal I/O Creator (p2,vbstioc)

Slot 22 (WOMB_FACIL_SUPP_PCSF) The Primitive command system factory (p2,cmdsysfact)

Slot 23 (WOMB_FACIL_SUPP_PROTCC) the Protocol converter creator (p2,protcc)

Slot 24 (WOMB_FACIL_SUPP_WAITCC) Wait Multiplexor Creator (p2,waitcc)

Slot 25 (WOMB_FACIL_SUPP_RFRSCC) the Remote File to Record Stream Converter Creator (p2,rfrscc)

Slot 26 (WOMB_FACIL_SUPP_AUXMANGRC) the Remote File manager Creator (p2,auxmangrc)

Slot 27 (WOMB_FACIL_SUPP_SEMACC) semaphore factory (p2,semacc)

Slot 28 (WOMB_FACIL_SUPP_BSLOADF) Bootstrap loader factory (p2,bsloadf)

Slot 29 (WOMB_FACIL_SUPP_EDITF) A factory for editors (p2,editf)

Slot 30 (WOMB_FACIL_SUPP_DDTF) The DDT factory (p2,ddtf)

{ni}Slot 31 (WOMB_FACIL_SUPP_BINDF) The empty binder factory (p2,empty-binder)

Slot 32 (WOMB_FACIL_SUPP_OSSIMF) An OS simulator factory (p2,ossimfact)

Slot 33 (WOMB_FACIL_SUPP_REGISTRYC) the Registry Creator key {(p2,registryc)}

Slot 34 (WOMB_FACIL_SUPP_MKEEPERC) a primitive meter keeper (p2,mkeeperc)

Slot 35 (WOMB_FACIL_SUPP_GNFDEF) a filedef factory (p2,gnfdef)

Slot 36 (WOMB_FACIL_SUPP_ADDLUDKY) add a key to the LUD (with restrictions)(p2,addlud)

Slot 37 (WOMB_FACIL_SUPP_SIAF) Small integer allocation factory (p2,sialloc)

Slot 38 (WOMB_FACIL_SUPP_CSWITCHC) A context switcher. (p2,cswitchc)

These entries will find that the initial bank {(p3,initsb)} is prompt.

Slot 2 (WOMB_FACIL_RES) Resource Facilities: a fetch key to a node with:
Slot 0 (WOMB_FACIL_RES_METER) A meter {(p1,meter)}

Slot 1 (WOMB_FACIL_RES_SB) A space bank {(p2,bank)} that does not require an account.

Slot 2 (WOMB_FACIL_RES_DOMKEEP) A domain keeper key. Recommended for domains without better domain keepers. This key currently produces a DDT whose communication port is available under SYSTOOL's switcher.

Slot 4 (WOMB_FACIL_RES_WAITC) (p2,waitc)

{arcane}Design note: I believe that this segregation of keys is modular. Slot 1 holds those things that are substituted when we build a substitution regime {(p3,sub-regime)}. Slot 2 holds those things that control resources both with regards to resource priority and duration of storage.

Slot 1 (WOMB_MEM) of the general keys node will contain a node key to the top node of the memory tree of the domain. This node is formatted as a red segment node with ssc=3. The initial slot count will reflect the number of pages. This node holds read/write page keys or DK(0) in the first 15 slots.

Slot 2 (WOMB_CALLER) will hold a resume key to which a result may be returned. This result is typically the contribution to the womb that was the reason for running this program. See (p3,wombtoday) about this resume key.

Slot 3 (WOMB_DOMKEY) will hold a domain key to this domain with databyte zero {all rights}.

Note: we may in the future restrict this key to disallow uses that can interfere with DDT.

Slots 4 and 5 may be initialized by other mechanisms.

Slot 6 may have a segment key to the symbol table to this domain OR it may have a the Domain Creator of the domain.

The other slots will be empty (unless otherwise specified).

Assembler language programmers can get symbolic slot definitions (without underscores) from DOMAIN MACLIB member WOMBDEFS.

Design Notes

We must distinguish the parts of the womb mechanism that must be trusted from those that need not be trusted.
The construction of the factory creator must be trusted but the building of the individual factories need not be. Some of the factories require components that must be constructed before the factory is complete. The logic to construct these early components should be isolated for they may be untrustworthy.

The logic of the factory building may thus be proprietary. It is not clear if we must provide for the protection of proprietary algorithms at womb time. We anticipate more elaborate environments to support the needs of proprietary system developers but our current womb-factory facilities must be sufficient to provide those environments.

This is not entirely academic: I need to run two strange algorithms to produce components that go into the VCSK factory.

An attractive thing about the ideas behind recent work with the womb keeper is that it makes manifest what depends on what. All of these advantages can be had as follows:
Each subsystem builder declares what facilities he requires and provides some pages of code that implement the requisite algorithms. The womb keeper then causes a domain with keys to the declared facilities to obey each of these algorithms. The algorithm would usually return a factory requestor's key.

If we advertise the output of such programs to be factories the womb-keeper could so verify. Now there is little ad-hoc, potentially proprietary code in the wombkeeper.

{spec}A (older) proposed alternative to the womb
We imagine a program ".starter" that runs where the wombkeeper now runs, perhaps pursuant to some mechanism such as described in (p1,bb).

The factory creator would already be intact and .starter would play the role of the builder of the standard factories.

This program would be simple unconditional key calls (mostly to the factory) that would make manifest what depends on what.

Another issue needs to be raised here. Which parts of .starter need to be trusted? Some parts need not be trusted and indeed may be private to the constructor of some facility.

{spec}Why continued big bangs
Some sequence of steps such as the womb evolution or something such as the IDL scheme described at (p1,bb) will be needed indefinitely I believe. I shall try to argue why here.

If we sell Gnosis to someone to whom security is an issue, we must deliver something in a "known security state". If the system starts from an IDL state then the customer has means of understanding and customizing the system for his own security requirements.

This requires that the software that we (and others) deliver to the customer must be in the form of data that may be interpreted by standard software in a Gnosis system in order to build the objects that will provide the service.

Objects designs are in one of the following categories:

They hold state (data) that they are unwilling to divulge.

They have no secrets and are designed to reveal their state without modifying the state.

They are designed to reveal their internal state according to some standard protocol.

Objects designs are in one of the following categories:
They hold authority that they are unwilling to yield.
Question: How do explain that a record collection is willing to yield all of its authority when it is willing to give you any of its stored keys but is unwilling to give you the key to its supernode"?

This is compatible with the IDL idea described at (p1,bb) but does not depend on it.

The Gnosis bootstrap problem is that most of the historical stages of software development support are "frozen into" the big-bang mechanism. This is unfortunate at least in that the logic of these obsolete and arcane mechanisms must be remembered when tracking down problems involved with big bangs. These problems occur as we test kernel and other fundamental code in Gnosis. These problems will also occur as we follow the strategy described at (more-bb).

It seems that the binder can play a strategic role in the rationalization of the Gnosis bootstrap problem in light of the following observations:

The binder is fundamental to most new software in the sense that a binder is able to "carry" an executable form of a particular piece of software. By this I mean that if we had just big-banged a Gnosis with a communication link to an old Gnosis, then we could haul over software if we could teleport binders.

Binders stem from binder factories and binder factories have the following features that make them "teleportable":

The .program of a binder factory (today at least) is a VCSK factory. The VCSK factory can be teleported.

The other components of a binder factory are rumored to be rather standard. When I get my hands on a builder's key to a binder factory I can try to teleport it.

Binders will presumably be a standard phase in software's development-deployment cycle. Thus a binder will generally be available to a suitably authorized individual. See (p2,binder-builder) about this security issue.

The teleported binder can bring with it hairy (moby?) programs written with the help of modern Gnosis development technology. Such programs are not now available until we have imported in turn each previous generation of software support technology.