Whofig Structure

The Root of the filesystem would typically be owned by the creator of the OS distribution.

/local

This is a whofig tree for local changes.

/local/admin

The local systemadin. This is the place were almost all changes (other than those desired by ordinary users) get made.

It's here that much of the configuration for the whofig system itself will be done, setting the rules for other config that will be imported, and what priority will be assigned to various owners. In theory such rules can be set at any level, but this is where they would be most commonly changed from their defaults.

/local/hard

A special subdirectory for items related to the actual local hardware the OS is running on. Driver settings and other information that would not apply on different hardware goes here. You want to split up your changes to the OS from what is done for the hardware, to make it easy to migrate your environment from one machine to the next.

/local/built

A place to put the files of the constructed whofig database, and also any other constructed "databases" for programs that need to have everything in one place or file, and for users to see for convenience.

For example, the /etc/passwd file is one that ends up being highly distributed in whofig, and a tool builds all the various components into a secure whole. Old tools could look at this file, in perhaps /local/built/login/passwd, which would be symlinked from /etc/passwd for old tools.

Such files should always be writable only by the whofig database and configuration builder.

/local/group

A typical name for configuration for a group of machines. An entry stored in /local/admin actually lists the other local file trees, and their precedence order. We might have several in a big company, such as /local/ibm, /local/yorktown, /local/accountingdept and so on.

In most cases, these would be imported local config that are mirrored from a master copy maintained by the actual custodian of that tree. In theory, these could even be network mounted file trees providing the real master copy, though for efficiency and reliability, a mirrored copy probably makes more sense.

/home, /home/userid/whofig

The home tree contains user's home directories, which belong to them. User's home directories contain whofig directories with their own custom configuration stores, such as ~user/whofig/packagename/file.

/import

The home for imported packages which are maintained by neither the OS distribution nor local sysadmins. In other words, the general packages usually installed by package managers. This actually includes most of the data in an OS distribution, which is usually 98% public packages.

/import/net/mozilla

The whofig concept does not demand any particular file structure for packages imported into this section. However, it would be encouraged to develop an easy to navigate namespace and file organization, since this is actually where most of the files on the computer will live in many cases. The above name is an example of where the files for the Mozilla browser might live. As is always the case, only the custodians of Mozilla would create and maintain files in this directory (though the sysadmins decide whether to install or remove it.)

/import/net/mozilla/1.7

Typically programs have many versions, and more than one might be imported for a variety of reasons. So more commonly files would live in a directory named like this.

This provides a very important ability -- to have many different versions of a software package on a machine at once in a formally laid out way. If this is combined with an easy way to switch what the "current" package is (perhaps even in an environment variable), developers can quickly test software in older environments, and find out what the "true" dependencies of their software are. Ideally they can test against stable "official" distributions as well as the latest packages they depend on. The result will be software that installs easily on as many systems as possible.

/import/net/mozilla/latest

For packages that do maintain or allow multiple versions to be present on the system, some standard symlink names make sense, including latest, and possibly other ones like stable/testing and so on. However, what version gets used may not always be the latest, due to customizations elsewhere, including in an environment variable.

/import/net/apache/whofig/login/passwd

If Apache wanted to create a userid for itself, it is modifying the configuration of the "login" system. Rather than writing into the passwd file with a custom command (useradd) as is done today, Apache stores its own customizations of the passwd file in its own tree. It does this by having a whofig directory within its configuration.

The configuration builder finds these and collects them to be available for the login & password system.

/data

This directory is a new location for things commonly placed in /var, /usr/spool and similar directories. Here programs can keep certain local data repositories. The same structure found under /import would be created under /data.

There is some merit to considering if data should also be distributed as to who it belongs to. That's a more complex problem which is much harder to make efficient. If you scatter data everywhere it can be hard to work with it efficiently. I welcome however proposals for how to design this.

The problem is made more complex by the existence of multiuser database systems like SQL databases. These often contain not just data maintained by different people but also configuration customizations of the sort the whofig system is supposed to compartmentalize.

/tmp

Same purpose as before. In theory /local/tmp would be a better name but for legacy reasons it can be kept the old way.

/etc, /usr, /lib, /bin, /var

These would largely be loaded with symlinks to the new homes of various files and directories.

/boot

Someday a bootloader might be written able to understand whofig, so that it can merge together a packaged kernel with distribution and sysadmin specific flags and changes.

Environment Variables

While users can have their own config, as a final level of customization, it would be nice if environment variables could specify the location of additional trees of customization. Of course, if this is done, it make take some time before running a program to calculate the special one-time environment for a process. Ideally the system that does this would cache such calculations in the database to make this efficient.

Environment variables would allow quick trials and tests of new configuration and customization, and also allow testing and running of programs in overall environments different from the standard one.

In theory, an environment variable could create a system that looks radically different to the programs on it, perhaps even looking like an entirely different distribution. That's because you could store the customizations of two different distributions on your system and switch between them.

There are, however, security concerns here. The system must not allow user customization or environment variable customization to trick privileged programs into running other programs they shouldn't, or accessing files they shouldn't.