Jump to page content



If, from reading these notes, you conclude that I am off my rocker, you won’t be the first, and you may even be right.

No doubt there is a dozen and one reasons why none of this would ever work, but perhaps somewhere deep down there is a tiny fragment that could be used for something.



All software packages would be static and manifest-driven. A package is simply the directory inside an archive file, with a manifest file defining the package information. Installation of the package involves the package file being uncompressed to the Packages directory, after which the manifest is read and the relevant processing applied, e.g. registration of configuration slice definitions, registration of supported file types. The Multidimensional Filing System makes all the internal files available in their respective dimensions. Daemons are ratified automatically and made available for starting, and then started if needed, unless the manifest indicates that configuration must take place first in a supplied configuration utility included in the package.

Scriptable packages are too dangerous, as their activity is beyond the control of the operating system and thus beyond the control of the user. Package scripts are only reversible if the system goes to great lengths to record every action taken and provide rollback capability, and this is not practical.

File and protocol associations would be manifest driven as per the Macintosh. Layer Config slices would be observed directly. Any other system plugins such as for logging would be detected and obeyed as needed and as permitted.

Packages would allow nesting, e.g. the Foo Suite package could contain sub-packages Foo Writer and Foo Grid. This would allow the user to install and remove portions of the suite at the package manager level as well as to remove the entire suite collectively. Package nesting is completely distinct from package dependencies. Third-party depedencies could be nested if desired, or simply referenced to a central repository.

Installing a new version of a package should always leave at least one previous version of the package behind, at least for a while, so that the installation can be rolled back.

The original installation date of each package should be tracked, along with the date of the most recent update or upgrade and possibly even the dates of prior updates and upgrades. This allows the user (or administrator) to see not only when the package was updated, but when the package was first installed, as these are useful diagnostics clues.


The ability to keep multiple copies of a package simultaneously opens the possibility of allowing a program to be updated while it’s in use. Take the following example sequence:

  1. User A opens Foo Writer
  2. Foo Writer is updated, either automatically or as directed by a user or administrator; a new /Applications/Foo Writer is created alongside the existing one, with the new folder shadowing the old one, and user A continues to see the old package
  3. User B opens Foo Writer and sees the new version
  4. User A closes Foo Writer, releasing the package reference
  5. User A re-opens Foo Writer and now sees the new version

The implication here is that all the package containers (e.g. /Applications) are treated as dynamic maps: each time the user accesses a package, a dynamic map is created within their user session. When the package is deprecated and replaced, the user’s dynamic map continues to refer to the existing package directory. Once the user has closed all applications using that package, they will see the updates.

Library packages are versioned, and each version will be retained at least ast long as any other installed package requires it. Launching a program that requires an older version of a library will automatically receive the older version according to its package manifest.


Each package’s manifest provides the package version along with all dependencies and the supported version of each. When starting an application, all library access requests will be automatically directed to the most recent accepted version of the library package. A library package cannot be removed while any active version of any application exists that depends on it. Inactive packages (those that are used solely by deprecated packages and that not part of any dynamic maps) can be removed, but all packages that depend on them will be removed in the process, which the user must agree to.

Conceivably the manifest could also specify the IPC command set version, such that if two programs communicate via the New Event Model, discrepancies can be identified by the operating system.