Sanity's Journal: Unified configuration mechanism

One of the biggest problems with Linux (and I am certainly not the first to observe this), is the vast number of configuration files, many with completely different - and often nonsensical layouts, and most of which must be edited manually. It is a mess.

I would propose that someone come up with a unified Linux daemon which handled all configuration information - keeping it all in a well-ordered datastructure, perhaps based on XML. The idea would not be dissimilar to the Windows registry, although it could incorporate a number of features to make it even better:

• Security
  Different parts of the configuration tree could be given read and write security permissions on a per-user basis
• Backwards compatability
  Through the use of pipes, older software which doesn't directly support the configuration mechanism can read their configs from a file that is actually a pipe to the config daemon
• Network support
  Access to the config daemon could be handled over a network, or the local config daemon could be configured to "fall back" to a remote daemon - allowing centralized configuration for software, but still letting the user modify user-specific stuff
• Cross-configuration
  Often - software needs to base its settings on the settings of another piece of software in the system. This approach would make it easy for one piece of software to check the configuration of some other software.

I think such a mechanism would be one of a variety of necessary stages to creating a new environment which can be built around a Linux kernel to bring it closer to the kind of unified integrated approach we see in OSX.

No thanks.

[molo]

This would mean coordinating all the configuration files for every unix app. This is not necessary, and a ton of work, touching thousands of projects.

If you want a configuration utility, fine. Make it work with the existing configuration files.

If you want registry-like functionality, there's already gconf, which can be used on a per-project basis (mostly gnome2 stuff).

As for me, I'll keep my text files, thank you.

-molo

Re:No thanks.

[Sanity]

This would mean coordinating all the configuration files for every unix app. This is not necessary, and a ton of work, touching thousands of projects.

No it doesn't, no more so than every unix app needs to "coordinate" to use the same file-system.

If you want a configuration utility, fine. Make it work with the existing configuration files.

I explained how it could be made backward compatable, but ultimately the existing configuration files have to go as they are the root of the problem.

As for me, I'l

Re:No thanks.

[molo]

This is just bloat. Why does my mailer need to parse XML and all the crap that goes along with it? Do I really want a big bloated xml parser like xerces linked into every frickin program that the system runs? No thanks.

And yes, this would mean chaging thousands of packages. Someone needs to convince all of the maintainers that this is worthwhile, and then guide their implementations.

Your pipe idea isn't really backward compatible unless it will also work for writes as well as reads. That is, I still

centralized registries are terrible

[SparkMan]

Centralized registries like the Windows registry are a bad, bad idea.

Config info belongs in the directory of the piece of software the info applies to. If we must have a centralized config area, like /etc/, we at least should keep seperate config files for each piece of software, ex: lilo.conf, gpm.conf, inetd.conf, etc.

How I miss the days when I could "install" a program on a new computer by copying the program directory across the network from some other computer that already had that program. That's

Yep

[Paddyish]

This was one of the MAJOR hurdles I had to overcome in dealing with the Linux learning curve.

Flame away naysayers, but this man speaks the truth. This sort of confusion is often what keeps the average Joe from trying out a free OS.

my 2 cents

[Skeme]

Great idea. After using a lot of GConf, Plan 9 and Reiser 4, I want to say, please please please, no XML, and no daemons! Files are perfect for configuration. I admin a programming lab of 40 machines, and the GConf daemon locks files all over my user's home directories, or sticks around after they log out. When that happens, the can't log in. Quit the opposite of user-friendlyness.

Just use files. For example, in my programs, I make a configuration dir that has an exactly one file to one configuration

Re:my 2 cents

[bnavarro]

It sounds like you haven't worked too much with XML, except maybe editng XML config files with a text editor.

XML is a salvation. It's beautiful to work with inside a program with the XML DOM. the XPATH query language makes it a breeze to locate anything. XSLT makes it trivial to reformat it for another XML reading application, or make it into a more human readable XHTML document.

I have started using XML for all of my program's config files. Screw the Windows registry. Screw Windows 3.x style INI file

Re:my 2 cents

[Skeme]

Actually I have worked with XML a lot. In particular, I have written file saving and loading support for it in a program I wrote. XML is nice because its files are human-readable, and there are good libraries for programming languages.

On the other hand, XML is over-engineering for a system-wide configuration system. The filesystem provides a natural key->value binding that is security configurable through access control lists, exportable with network filesystems, auditable, and easily able to be back

Interesting.

[bnavarro]

I was just thinking about something similar. I hadn't thought about named pipes for the original configuration files, though; I had thought about using a daemon to mirror the original files into the new XML config file(s) and propigate changes from the originals into the XML files and vice versa. Dunno which method would entail more work; maintenance of the original files in any form seems like a nontrivial task :-(

I haven't worked too much with named pipes. One possible problem with them would be when

XML Complainers?

[Elwood P Dowd]

XML has nothing to do with this problem. All y'all gripe about him using XML to solve the problem when... XML is only like 2% of the solution.

The problem with your idea is that the Windows Registry is a bad idea. It's *hard* to make a flat file like that multi-user aware. It's *hard* to make it network aware.

Consider NetInfo as a prototype instead? I'm not sure if its security model is perfect, but at least some of these issues have been considered.