Software Distribution

There is much current public fuss about systems that are too hard to administer. How does capability design bear on this? Mostly well I think. Let me elaborate; but let me ramble first:

When I install a very simple application on my Mac I merely drag an executable file into my applications folder. When I want the application no longer I drag it into the trash.

Today few applications are so simple. Here is a moderate flame about the politics of installing software. Here are some of the shapes that a complex application assumes today.

In the “System Folder” there is the “Preferences” folder (“System Folder:Preferences”). Within that folder are many small files, most with a name reminiscent of some application that perhaps I ran in the distant past. These files seem to hold notes that the application makes about my preferences.
In “System Folder:Extensions” I see many files that are usually unassociated with any particular application. I think that most of these files hold relocatable code that is loaded with the operating system. This is middleware land. I don’t know who wrote it or where it comes from. Apple’s new release notes include a brief explanation of many of these. It is not clear who is responsible for putting things in and removing things from that folder. Occasionally some application will complain that some library is missing as a result of a file missing from Extensions. Some installers put things in Extensions. I don’t know who is responsible for removing them when the application is removed or superseded. I don’t know whether code from Extensions requires real memory or only virtual memory. I think that I know more than what Apple plans for a Mac user to know.

I think that Windows 95 is not better and Unix is merely more up front about expecting the administrator to be a programmer.

When you buy an OS from one direction, middleware from another and applications from yet another there are severe compatibility problems. I don’t know how to solve these problems with capability systems but I do know how to constrain things so that, at some loss of flexibility, these problems cannot happen. Such a flexibility loss is that the system will not try to run a browser that is not “rated” to run with the IP (Internet Protocol) suite that is found on the system. With the advent of middleware (a good idea I think) there arose the issue of how the middleware gets to a customer’s machine. This is closely connected with the question of who pays the middleware producer. Fonts are a form of middleware. A particular font is used across many applications, is bundled with the OS or bought by the user. Fonts are visible to the user. Most of their attributes are known to the user. More often middleware is invisible to the user. Lets take dial-up Internet Protocol software, for instance, of which the two common schemes are PPP and SLIP. These are sometimes bundled, sometimes downloaded as shareware and sometimes given away. Some installation packages supplant the installed IP package, perhaps with a version that is inferior or at least incompatible with other older software that is still needed on the machine.

Buying middleware is a bit like buying a modem. The user learns that a modem is required to run any of a growing list of applications. He learns that ISDN is an option. He may learn that which ISDN hardware he buys depends on decisions that his local phone company has made. It also depends on which computer he uses. The user cannot find the information required to figure out which modem or ISDN hardware works which which software. Often no one knows, or those that know are not motivated to tell. Middleware is scarcely simpler. Can the software industry do better?

A software vendor may decide to be serious about the reputation of his product. If that product depends on middleware then the vendor may choose to guarantee his software contingently on the version of version or brand of that middleware. If such contingencies are available online then a great deal of automatic configuration can be done. Schemes such as these can provide for tracking problems.

A Conceptual Landscape Suitable for Reliable Consumer Computing

Lets imagine how a non institutional computer user might choose products when the computing industry has done its job right. While I will speak mainly from the perspective of the end user, I have concrete underlying capability mechanisms in mind. Perhaps the software architect with a capability background will imagine similar ones.

There will be a variety of hardware producers building computers and communications gear of various degrees of compatibility. Some computers will be tamper resistant to a degree. There will be a variety of software producers. The software will range from operating systems thru high level applications. There will be at least one level of middleware but there will be no fixed set of levels. We use “platform” to refer to the combination of hardware and OS, perhaps with OS extensions from other vendors. The security-robustness features that we will speak of are properties of the platform.

Distinct from software and hardware producers there will be brokers and configurers (packagers?). Their business is to know what combinations work together. For some combinations of hardware and software they can sell you access to software with usage sensitive pricing on your own computer. Try before Buy.

The most significant difference in the future landscape may be that there is no presumption that new function added to your system can disrupt current function, at least if you are using a capabilities-based platform. About the only question will be is “Are there enough physical resources (space and CPU time, etc.) for the new function”.

Installing new software is, in our jargon, adding a new tenant. The new tenant will require local access to various standard resources and facilities. These facilities come with the platform or are provided by other older tenants. The tenant may have some assurance of what platform it is running on and may insist on certain versions of the facilities. Some features of the new software may be contingent on specified versions of facilities. Perhaps the features are available but unwarranted without the specified versions. There are no architectural impediments to multiple versions of the same facility. The Windows dll problem need not exist.

Tenants that gain local access to services of other tenants are said to be dependent on them. The system maintains this dependency in the lock mechanisms described below. Here is some arcane name theory. The user is not generally aware of this relationship. He may need to become involved if software needs to be removed for any of a variety of reasons. How much of his world will dissolve if certain software is removed? Question: Should we even think about removing middleware?

Better platforms will provide a kind of manifest separation of the tenants. By “manifest” I mean that there will be a simple graphical depiction of the tenants and whatever connections there are between them or the outsideworld. The only default relation between the tenants is how they compete for space and time.

The tenant will be an object T. Often T will merely serve to create application instances. As the tenant is installed these are some options that may concern the machine owner.

Can the tenant access Internet?
Can tenant instances do so?
Can instances talk to each other?
Can the tenant arrange for remittance (payment)?
Can the instance access the true date and time?

Such attributes are recorded by the platform for later reference. There are clearly additional issues. User actions to change such state are either prevented or recorded. All of these issues are negotiated between the tenant and the owner. The tenant has the option, of course, of refusing to operate unless the terms are OK. The owner always has the option of removing the tenant, subject to locks, see below.

The tenant has within its apartment a fully functional persistent world private from other tenants and the user (assuming tamper resistance). The user cannot tamper with the apartment except to delete it entirely, or shut off the power in a non destructive way. The only information that the user gets about the apartment is space and CPU usage, and what the tenant tells the user.

Locks (Safety Catches)

The user can lock some of the objects that he creates. When a tenant instantiates a locked object, then the tenant is also locked. This is so that the tenant cannot be removed before unlocking the instance. Facilities used by the tenant are likewise locked. When the user attempts to remove some software component (tenant) that is locked, the cause of the lock is displayed so that he can find things that he has locked and may wish now to unlock. This way I won’t delete the word processor while there are documents that need it, nor will I even delete a font that is in use!

Locks are to insure that tenants are not evicted by the user who is unaware that the tenant is supplying some service critical to the user. The lock is, in effect, a note from the user to himself. When tenant A subscribes to another te XXXXXX

Other Ramifications

Many of the extensions on the Mac may be unfeasible in this scheme. There is no obvious way to install a system wide file compressor. Screen savers are popular enough that hooks for that can be provided without undue complexity to the TCB. The cdev is probably doomed. Some Unix drivers might conceivably be caged and made harmless. Some drivers will be vouched for by the OS builder.

The OS vendor specifies the hardware possibilities. In case of tamper resistance the OS must be delivered with the hardware. Platform upgrades are more difficult in this world. Off site backup schemes such as provided here may play a role. Indeed the user’s world can be uploaded in trial fashion to another hardware platform for testing before committing the old platform to the new world. In Keykos kernel upgrades were easier than application upgrades. (Keykos can take a checkpoint to tape. Our system could take an encrypted checkpoint to an off site service.) Here we discuss schemes for partial software upgrades.