Note that the difference between this, and traditional security mechanisms is that processes have the authority to do things not because of who they are (owned by root, suid root, owned by a user, etc.) but by the list of capabilities that they have been given.
Note that a limited kind of "capability" can be implemented using ACL's and Unix groups. However, this kind of an implementation is difficult to manage, is error prone, and is missing the tools needed to do it well. In short, its not the right approach -- its a hack.
A very different example of a capability is the coupling of high-priority execution rights to an interrupt. Thus, a kernel thread can catch an urgent interrupt at a very high priority, pre-empting other threads. Once the interrupt has been handled, the thread can resume execution at a lower priority, allowing other threads to run, essentially allowing real-time operation.
Note that persistence gets you much of the way towards the ability to migrate a process from one CPU to another.
Versions exist for various Unix's, including BSDI. A sixty-node cluster of Pentium's and PPro's has been built. A version for the Linux kernel 2.2 is available as of now (January 1999). Contact: email@example.com (Amnon Barak)
Work item: clarify the actual compatibilities & incompatibilities in the above. What sort of testing has been done? What parts of a unified layering design have already been done, and are clean? What parts are not?
Can layered TCI/IP be exploited to allow for process checkpointing and migration on a cluster?