First, let me introduce a new blog topic, Sysadmin where I will cover computer system administration and OS design issues, notably in Linux and related systems.

My goal is to reduce the nightmare that is system administration and upgrading.

One step that goes partway in my plan would be a special software system that would build for a user a specialized operating system "package" or set of packages. This magic package would, when applied to a virgin distribution of the operating system, convert it into the customized form that the user likes.

The program would work from a modified system, and a copy of a map (with timestamps and hashes) of the original virgin OS from which the user began. First, it would note what packages the user had installed, and declare dependencies for these packages. Thus, installing this magic package would cause the installation of all the packages the user likes, and all that they depend on.

In order to do this well, it would try to determine which packages the user actually used (with access or file change times) and perhaps consider making two different dependency setups -- one for the core packages that are frequently used, and another for packages that were probably just tried and never used. A GUI to help users sort packages into those classes would be handy. It must also determine that those packages are still available, dealing with potential conflicts and name change concerns. Right now, most package managers insist that all dependencies be available or they will abort the entire install. To get around this, many of the packages might well be listed as "recommended" rather than required, or options to allow install of the package with missing 1st level (but not 2nd level) dependencies would be used.

Next, the magic packager must examine what files both in standard system packages and in new packages have been changed by the user. (These must be distinguished by files that were changed by other packages.) In such cases, one would want to store in the package at least a diff between the original and the current file, or even copies of both. This is very hard because of the issue of tracking changes that were made by programs rather than people. In the end a nice GUI may be needed to list these changes and let the user choose what files are important.

One way to make this easier, of course, would be to have an engine tied to the existing package manager. When a package is installed, the engine would look to note what files were changed by the package install rather than by hand-editing by the user. Watching the user as they administer and configure their system is the best way to learn the most about duplicating it.

Finally an additional package could be prepared containing well compartmentalized files, such as user home directories.

When completed, this super-package could be installed using a tool that will fetch and install dependencies. This will install the needed packages. Next its own install script would attempt to apply diffs to system files to set the system just the way the user likes it. This is of course also very hard, as there will be mismatches in the diffs for one thing. In addition, many changes will have been made by programs. For example, adding a user is normally done with useradd -- most changes to /etc/passwd are made with specialty programs. You might well need special case code for a number of crucial files to apply the right patch.

Of course, some nice packages might well adapt to this and start offering scripts to generate the "patch" for their files as the user changed. For example, the packages that own files that are machine edited might be able to calculate the diff (keeping around a copy of their virgin files) and express it in terms of calls to the command that is normally doing the edits. (/etc/passwd usually does not belong to a package so it needs its own solution.)

The goal of course is to be able to take a new virgin system, "Install" your special personalization packages, and turn it into the system set the way you like it. This would presumably work easily on a system that started identically to the way yours started -- in fact you can do this just by doing a more traditional file diff (with rsync) and applying the bulk patch -- but the real goal is to do this down the road, so that you prepare a package recording your changes for one release, and apply it to a later release, either because you wish to do this rather than face upgrade, or you're given a new machine and it's time to use the latest.

Chances are it would not work perfectly, but it might automate a lot of the drudgework.

It may also make sense to be able to build a personalization package that sits on top of an earlier package. This might allow you to express an incremental set of diffs, or to build your customizations starting with the recommendations of others and building on top of them. In a sense, this would allow people to release a package that says, "Here's Ubuntu, the way I recommend running it" almost in the sense that Ubuntu is itself a version of debian.

There have been efforts in this direction. Automatix2, for example, tries to simplify installing all the more unusual packages in a system to take the scutwork out of it. That's a good start.

It's not even out of the question to be able to do this to move from one distribution to another. In that case, the tool would have to be smart and understand how package names change between systems. In this case I doubt it would do it all, but it would be very handy if, for example, Ubuntu came with a tool you could run on your old Fedora system which gathered up all the packages you had installed and converted them to their Ubuntu/debian names, along with some of your configurations, and then created a .deb which would give you as much of your old environment as possible on your new system. This would encourage switching and it's a very common process in the commercial world.