Articles / How to Fix the Unix Configu…

How to Fix the Unix Configuration Nightmare

Unix is steadily evolving into something much easier to use. The trick is to find tools that make things friendlier, but which 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 applications and system software.

The GNU project has done a lot of good work in standardizing the compilation of software on different operating systems (automake and configure), parsing commandline options (getopts), and working with internationalization (gettext).

One thing that's still a mess, however, is application configuration.

There are useful general trends, like putting system-wide configurations in /etc and personal preferences in files beginning with . in your home directory. However, there is a complete zoo of configuration file formats. Some use the Windows .INI format. Others use simple variable assignments. Some use a natural language syntax. 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 to fix this.

Some popular packages, like Apache and Samba, have had point-and-click frontends built for them, but each frontend works differently. Other packages (notably the Linux kernel and Debian's debconf) have a range of interfaces that can be used, 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 frontends for a lot of different software configurations, as is done with the GNOME and KDE control panels, the Linuxconf project, and The Dotfile Generator.

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 have quite pulled off the kind of user interface consistency that Windows and MacOS have. However, despite an apparently messy situation, I think that Unix may not be very far from a workable solution.

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

The solution, I think, lies in combining the best of the approaches I listed above. It's vital that it be something that can work with existing programs, but which is attractive to developers to incorporate into new versions and new projects. Without integration into 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. 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 accommodate 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 configuration handling and documentation. It helps the user by providing flexibility and consistency.

Here's an outline of how it might work:

  • A core system would handle parsing, verification, and storage of text-based configuration files in one or two basic formats.
  • The master copy of the configuration is always left in the native text files (in /etc and ~/.*). This is where Linuxconf fell down; it started keeping its own copy of the configuration, which meant that if Linuxconf took over your system and then something stuffed up, it was difficult to edit a text file without losing Linuxconf completely.
  • In order for some features to work, it might be necessary for application developers to switch to the use of the configuration manager for their internal routines. However, this should be possible without breaking backward compatibility with the original configuration file format for most features.
  • A key element would be the configuration format description file. This would list the configuration options for a given piece of software, giving for each one the name, type (boolean, list, string, etc.), options, category (for subsections within the config), and help text (short and long).

    It would be good to be able to write descriptions of how options relate to each other. For example, one option might disable a bunch of other options.

    Ideally, you would be able to add optional hints to help with the layout of the options on the screen under various configuration editor systems.

    Done well, this could be a big attraction for developers, because it could automate a lot of the work involved in managing configuration systems. By creating a single place for storing such info, it could be used to automatically generate and update all documentation: user guides, man pages, Web page help, commented template systems and user config files, and programmatic help output.

  • Because so much language is involved in configuration options, it needs to be internationalized from the ground up.
  • This core system would be kept small and efficient, so that it is easy to add it to all sorts of projects without weighing them down. It would have interfaces in all of the common Unix languages: C, C++, Perl, PHP, shell, Python, etc.
  • Plugins would allow the addition of a lot of diversity, and would be of at least two types:
    • File format plugins would allow the programming of new configuration file formats. This includes parsing, verification, editing, and writing. You could expect heaps of such plugins, preferably provided with an application or by a third party.
    • Editor plugins would give various methods for changing configuration files. These could range from a wrapper on your favorite text editor, to text-based menus (curses), to graphical menus (GNOME, KDE, etc.), to distribution-specific methods (e.g., Debian's debconf), to Web forms (useful for Web applications that have a lot of configuration options). It should be possible to invoke an editor from within an application (using the application's File -> Preferences... menu, or a commandline option) or directly from the commandline (or a GUI equivalent that lists installed apps, like a control panel). It should also be possible to programmatically edit configurations, either through a standard commandline or through the various language bindings listed above. Network administrators would love such tools.
  • It all needs to be language, distribution, and operating system neutral, so as to avoid turning off any potential software developers who might find it useful.

With such a system, Unix could go even further than Windows and MacOS, 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, 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 would attract contributions from a lot of different angles.

Recent comments

03 Jan 2007 23:13 Avatar wwwalker

Re: unixconfig.sourceforge.net and mailing list now open


> some of the comments are very

> interesting. i really appreciate all the

> ideas flying around here.

>

>

>

> we've created an ongoing web site and

> mailing list for people to continue

> discussing, organising, and hopefully in

> the end coding. it's at

> unixconfig.sourceforge.net.

>

>

>

> meanwhile here's another link to the

> permanent home for this article. this is

> where i'm making revisions and adding

> links.

>

That site link is dead. I tried search sourceforge.net for unixconfig and got nothing.

26 Jan 2003 09:02 Avatar kjkhyperion

Re: avoid a global registry for local apps

> One of the biggest problems with having
> a single global registry like in Windows


no, it isn't a single, global registry. It's split up into many system-wide parts - namely, SOFTWARE, SYSTEM, SAM, and SECURITY - and a per-user part. Notably, the per-user part is stored in a file located in the user's profile directory. Not to lose your installed programs, you backup SOFTWARE. Not to lose drivers and services, you backup SYSTEM

And it can be done better than this

28 Jun 2002 02:01 Avatar linuxknight

Re: And what about using "Brain"

> installed under Program
> Files. The Linux community, and
> especially distro packagers would do
> well to take note.

Do you know ANYTHING about linux?
The programs are installed in one of 3 places:
/bin, /usr/bin, and /usr/local/bin.

Some programs install their files in /usr/<programname>.
For example, Mozilla installs in /usr/mozilla by default.
Is THAT hard to figure out? I personally think
that anyone who's so STUPID that they want to
use the STUPID Micro$oft Window$ operating system
just because it's EASY to use shouldn't be using a
computer at all!

Fools who just want to learn to "click the
mouse" and "use the easy control panel" have no place
using a computer. Go back to your typewriter!

(No offence to computer experts who use windows, this is
targeted at the idiots who want to use a computer the
Simple M$ way.)

13 Jun 2002 01:22 Avatar guodman

Re: why there is a problem?
RPM files are a much bigger problem than config files, and the advantage of the good package managers (like rpmdrake) is that they try to automatically install or remove packages to satisfy dependencies (they do fail often). The idea of going to a command line and opening a file scares many people. If there is a nice gui, the users can make modifications and be sure that they will not mess up the program by typing something wrong. before you start talking about how easy it is (and I would agree that it can be easier) remember that when you go to the general public, many people don't want to spend any time learning about their computer. With a gui, all of the available options can be listed for the user to pick from, and the user doesn't need to search for the file to configure.

25 Mar 2002 23:20 Avatar sharkey3

COAS
This sounds a lot like the COAS project started at Caldera. <www.coas.org> Like all things Caldera, it failed for lack of effort, but perhaps someone could pick up the pieces and make it work.

Screenshot

Project Spotlight

Kigo Video Converter Ultimate for Mac

A tool for converting and editing videos.

Screenshot

Project Spotlight

Kid3

An efficient tagger for MP3, Ogg/Vorbis, and FLAC files.