How to fix the Unix configuration nightmare

Matthew Arnison
January 2002

Unix is steadily evolving into something much easier to use. The trick is to find tools that make things more friendly, but fit in well with existing tools and are easier for people to take and use for new projects.

The Linux distributions and the BSD ports system are like this, taking an existing wealth of software and working with its quirks to streamline the installation and upgrading of applicaitons and system software.

GNU have done a lot of good work in standardising the compilation of software on different operating systems (automake and configure), parsing command line options (getopts), and internationalisation (gettext).

One this that's still a mess, however, is configuring applications

There are useful general trends, like putting system-wise configuration in /etc, and personal preferences in files beginning with . in your home folder.

However, there is a complete zoo of configuration file formats. Some use the old Windows .INI format. Others use simple variable assignments. And some use natural language style syntax.

Now a certain amount of diversity is healthy. But in this case it makes it a bit of a black art to build user-friendly and powerful configuration tools for all the software on a machine.

There have been various noble attempts.

Some popular packages, like apache and samba, have had point-and-click front-ends built for them. But each front-end works differently. Other packages, notably the linux kernel and Debian debconf, have a range of different interfaces depending on the user's taste, from a raw text file and vi, to a text-based menu system, to graphical point-and-click.

Another approach is to custom build a consistent set of front ends for a lot of different software configurations, such as the GNOME and KDE control panels, the linuxconf project, and dotfile.

I don't think I need to go into much detail as to what a mess the Windows registry is. It does provide a certain amount of power for graphical applications, but the text-level access is shoddy and cryptic, and a binary database seems to be an inherently unstable and inflexible way of storing data.

A new approach

All of the above efforts have made things better. But none of these projects have quite pulled off the kind of user-interface consistency that Windows and MacOS have.

But despite an apparent messy situation, I think that Unix may not be very far off from a workable solution.

Obviously it's possible - reports are that MacOS X has pulled off a very nice graphical front-end to Unix. However, that front-end is the bit they're keeping closed, so the other Unix systems are going to build need something free.

The solution I think lies in combining the best of the approaches I listed above. It's vital that it be somehting that can work with existing programs, but also is attractive to developers to incorporate into new versions and new projects. Without integration into the applications, it's always going to be a bit of a dodgy hack (see linuxconf) that makes it difficult to change the configuration file in a variety of ways.

Like previous successful Unix evolutions, it needs to plug into current technology in a way that gives something back to the developer pretty quickly, and make it easy and inviting to be used in both existing and new projects. Getting the developer involved is crucial for making sure the configuration manager keeps up to date with changes in the application, which I believe is a big part of the success of standards like gettext and configure.

It needs to accomodate diversity (the opposite of the One Registry approach, which I think will never fly on Unix). And it needs to be tenacious: it should be useful even with minimal information, but take good advantage of as much information as is given.

It needs to help both the user and the developer. It helps the developer by automating and cleaning up the their configuration handling and documentation. It helps the user by providing flexibility and consistency.

Here's an outline of how it might work:

With such a system Unix could go even further than Windows and Mac, providing the ease-of-use of graphical configuration, with the flexibility and security of remote text-based configuration, and the power of programmatic access to read and change configurations throughout the system.

If this seems like a good idea, then all we need is a team of programmers and documenters to write it. It seems like a lot of work, but with the right touch, and strategic initial energy, it would be something that attracted contributions from a lot of different angles.