Dividing up the changes

In most of these essays, I describe a plan where each custodian (person responsible for a system or a package) puts their changes and files in a file tree just for them. This isn't the only way to explore how to divide up the changes.

Unix userid

One could keep a similar file structure to what we use today, as long as packages arranged to handle multiple configuration files, if every custodian got a userid (uid) and the file was owned by that uid.

The big advantage here is that the OS provides security on the powers of the individual changers without having to disperse the files. Sysadmins would not use their own uids, but would intead have a special uid for their sysadmin role, or more than one for multiple roles.

It is relatively easy to find all the files belonging to an owner and archive or manipulate them. However, a simple file backup is not possible as one can't be sure where on another system each file will go.

This could call for over 100,000 uids if there is one for each package author, but in fact you could pretty easily group all "foreign" packages under one uid and only issue uids to people really associated with the system.

Version Control System

In many ways, whofig reflects the goals of the version control systems people use to manage multi-developer software packages. These systems let everybody work on the whole system but track all their changes individually as they check them in and out.

Whofig could be accomplished by linking a version control system into package management and system administration. No changes could be made to system files and imported packages except through the VCS. Changes by the authors of those packages would be imported through the VCS, all changes merged together, and conflicts reported for resolution.

However, as everybody knows, using a VCS is not as easy as it sounds, and often there are complex conflicts which take a bit of time to think about. Without some structure to the files, things can get far out of sync with bad results, especially since many users don't upgrade for long periods.

Magic filesystem

It would be possible to build a magic filesystem that integrated concepts from version control systems and whofig so that packages would look just like they do today, but in fact each custodian's changes are kept apart from the viewpoint of the magic filesystem. As you edited a file, it would be broken down so your changes would be recorded in a file or section belonging to you, and the original file would remain intact. However, if you looked at the file, you would see it as you changed it. Again, incompatible changes present a real problem.

One can even imagine a system where two people change the same file but each only sees their own changes, if they are not changing the file at a high level. This becomes a subsitute for per-user configuration.

Of course to be efficient, such a system would have to cache the final results, but this would be invisible to the user.

The filesystem

As noted, I think that putting each custodian's changes in a private file tree has a number of advantages. It makes it easy to encapsulate them, back them up and move them. It makes it easy to have them on different media, with the OS on a read-only medium, the company sysadmin's on a network mounted filesystem and the local admin's changes on a USB thumbdrive if desired.

The big downside is that files for a particular package are scattered all over the place. You can't just look at a config file and see it all unless you have a special tool to do that. Certain things (like the $PATH variable) become impossibly complex, having to refer to thousands of directories.

Some of this can be fixed with special tools or with caches and optimizations. Links and symbolic links can restore name based associations between files scattered around the system.