On Tue, 8 Feb 2000, Steve Schveighoffer wrote:
> 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
> 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
> 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
> 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.
You may like the registry because you know how to hack it, but many many
Microsoft users have suffered grievously when their registries have gone
south. Thus anything resembling it would have to be carefully considered
before anyone in Linux would use it.
1) Unlike Windows machines, Linux machines can be used by multiple users
and many Linux programs use not only a config file in /etc, but also a
personal config file in their home directories. Yes, you _could_ put the
"keys" in one file, but then you have the problem of what happens when Joe
Local Luser hacks up the file somehow while others are online using the
system. Problem is file permissions. You can't have a regular user hack
global config files in any way.
2) You're dealing with programmers all the way from Red Hat to ESR to Joe
Local Hacker building programs under Linux, all of whom think their method
of reading config files is the best. Sendmail has one of the worst config
files I've ever seen. So they'd all have to agree that the "Steve" way is
the right way. And if you even mention "Microsoft" to a lot of them,
they'll shut you down right quick.
3) Linux/Unix has always been the land of tools, where one program does
one thing very well. Making all these tools talk the same configuration
language is a tough sell, at best.
4) The LSB is not in a position to advocate for something like this. It's
about all they can do to get agreement from the "cat herd" of Linux
vendors on existing practice. Let alone a completely new "registry"
I haven't found Linuxconf to be dog slow, personally. And I think it's
actually a pretty impressive effort, considering the diversity of files it
must manage. And it's the most popular open source solution to this
problem. SuSE has its own tool (YaST), but it's not really "open source".
Others probably are working on other tools. I think our efforts might best
be spent propping up and improving Linuxconf.
Not to shoot you down in flames, but I just think what you're asking is
impossible to make happen.
Paul M. Foster