Sorry for the bogus return address, but I noticed some spam posted to the mailing list, and I prefer not to be spammed myself. If you need to send me personal email, follow the directions at the bottom.
Anyways, I am a veteran linux user and have used it since the 1.0.x days. I originally started by using slackware, then moved on to RedHat. I also have used some unixes, most prominently Solaris and IRIX. However, out of all these systems, I absolutely hate the way you must configure each piece of software differently. Before you delete this email hear me out. The one configuration system that has the right idea is Microsoft's registry. Now, I used to HATE the registry, it has all kinds of cryptic info, no editable text files, and no comments as to how the entries affect the program. However, as I began to learn how the registry was laid out, more and more, I found myself browsing to the correct location in the registry to configure something in a program that I knew nothing about. Then it hit me -- Window's layout of the registry is a defacto standard as far as windows applications are concerned, and that is why using the registry became so easy. Most global program info goes under HKEY_LOCAL_MACHINE\Software\<VENDOR>\<PROGRAM> and most user specific info goes under HKEY_LOCAL_MACHINE\Software\<VENDOR>\<PROGRAM>. I also used a tool on RedHat called linuxconf. Using linuxconf got me thinking too. It is a great tool, but it no doubt is unnecessarily bloated because it needs to know how to parse and edit multiple types of configuration files. Not only that, but it is DOG SLOW. When you think about how every program's configuration file is put in a different place with a different format, you can begin to understand why linuxconf is such a slug. My idea is simple. Take the organization and simplicity of the windows registry, and linuxize it. Use a file format that is human-readable and editable, use the linux filesystem to organize the "Keys" and the file permissions to implement security. Then, make the internal file format easily parsible by a program. Here are the advantages that I see we can have: 1. Organization -- it is easy to find the configuration for a program, you just look under /etc/config/<Category>/<Program> (for example). No more do you have to search on the internet to find out how to configure each individual program, you need only figure out how the configuration is laid out, then proceed to the correct file. 2. Elimination of redundancy -- if you have multiple types of config files, you have more than one instance of file-parsing code. There could be one shared library that exposes the correct methods to programmers to easily parse the files. 3. Streamlined and Global linuxconf -- the tool that edits/reads the current configuration does not have to contain all the redundant code from part 2. This allows a newbie user or normal everyday user to configure the system without having to edit configuration files. Since the directory structure is similar in all cases, the configuration program doesn't need to have special knowledge about which programs are on the system, it can just say "Hey, here's a directory inside the /etc/config, I will present the interface to configure it to the user". This allows the functionality of the tool to be worked on instead of having to add new parts to the tool when some new essential program comes out that the tool needs to configure for a newbie. 4. Improved security -- if most programs use this configuration system, security problems are contained within one library. Fixing security bugs in that library fixes the security problems for all programs. Right now, if some developer decides to introduce his tool with HIS implementation of a config file format, it is more prone to security problems, and every program must be tested instead of the global library. Here is one disadvantage to this system: 1. Time & Effort -- it will take time and effort to not only develop this system, but to migrate targeted programs to this system (something that I am more than happy to donate my time to). However, this does not prevent newer programs from being developed that use the system. I am not an expert on file parsing and security, so which file format is used is something I will leave up to whoever is the expert. However, from what I've been hearing about XML, it sounds like something in that direction would be good. It needs to be extendable, and very parsible by software, yet editable by a human. Something that a perl or shell script can manipulate will also be preferable for automation and installation. It might also be good to put a similar directory structure in the user's home directory for settings that are user-specific. OK, so there's my idea, I have typed all I can think of, I would appreciate some feedback, good or bad. Thanks for your time. -Steve -- To send email to me, send it to: nihil aht gis dot net.
