OSDev.org

In the thread about windows registry it was asked what would be a better alternative for the registry or a set of configuration files. Since that's an OSDev topic, let's have the discussion here...

Personally, I would take a middle road... by designating two directories for configuration data (names are arbitary):

/settings
/settings/system
/settings/application
/settings/applications/<appname>

The /settings/system would contain system-level settings. The /settings/application would be a virtual link to the /settings/applications/<current_application>, automatically adjusted for each running process. This would be the only directory that application can directly write to.

Similarly:

~/.settings
~/.settings/system
~/.settings/application
~/.settings/applications/<appname>

Same setup, except user specific.

Ok, so that requires some OS support for the /s/app directory.

As for the contents of those directories, I'd just go with the Linux policy of configuration files, but provide some default libraries for handling a "default format" in hope to encourage using the same format when possible.

Whether you use a global / local directory structure, hierarchical database or a bunch of XML files doesn't really matter - I believe it's secondary to other considerations.

mystran wrote: As for the contents of those directories, I'd just go with the Linux policy of configuration files, but provide some default libraries for handling a "default format" in hope to encourage using the same format when possible.

Providing a strong default is usually the best way to avoid hassles. One advantage of not providing configurations in a plain text format in plain directories is to discourage applications fprintf()ing their configurations and users hacking them without any software to do basic sanity checking.

The necessity to hack stuff manually usually just points towards a major weakness of the software in question. (See version control: Many people prefer CVS because they can hack the back-end files - which they have to because CVS doesn't support many things. Subversion is blamed for having a binary, un-hackable back-end - which wouldn't be a problem if that backend would "just work", which unfortunately it doesn't.)

That being said, what is the "Linux policy for configuration files"? I couldn't find much similarity between the lingo of, say, httpd.conf, rc.conf, and sendmailrc...

Does anyone here know the details of the MacOS 'Preferences' folder? I know that programs are supposed to put configuration data there, but I also understand that many do not, which can cause a number of problems. Also, I expect that this system has become more complicated in MacOS X, which also has Unix style configuration files for some programs.

Solar wrote: That being said, what is the "Linux policy for configuration files"? I couldn't find much similarity between the lingo of, say, httpd.conf, rc.conf, and sendmailrc...

I think the policy is, think up a format that you like, then create a man page and tell others about it. Note, some forget the second part.

afaik, there isn't unfortunately "one" policy for configuration in Linux -- which is why it's so hard to configure a thing for the first time. The best you usually can do is call the manpage and hope you'll get a list of config files ...

btw, my policy will be much like mystran's one:
* you have system configuration for system tools, which applications cannot touch
* you have application default configuration and per-user applications preferences.which go to a "/settings/apps-default-config/<theapp>" and "/user/apps-preferences/<theapp>". Those locations are normally hidden by the system and presented (userprefs overriding app defaults) to the application as "self://settings".

If i had to write it right now, i'd probably go for something intermediary between plain text and pure binary (say some XML or BeEncoded dictionnary). The application is supposed to post another file which will describe options so that a system tool can present in a uniform interface all configurations options for any software from "apps://<theapp>/settings".

Oh, and btw, any environment variable or command-line flag can override those configuration settings aswell So "self://settings.compiler" is the compiler to be used regardless wether it was "setenv IDE_COMPILER gcc", "./ide --compiler=gcc" or "<compiler>gcc</compiler>" in a localpref file

Schol-R-LEA:
I did a quick search around Apple's developer section:
http://developer.apple.com/documentatio ... ences.html

hmm ... now that i'm re-thinking about it, it'd be 100% cool if we could have per-group options, so that changing the "defaut font" (poor example) in a member of the group could apply the change to all the members of the group (unless stated otherwise)

Those per-group options ring a bell with me. I was once contemplating to provide a system-wide template for configuration, some kind of IFF-CONF - so that two word processors from different vendors could share the brunt of configuration (e.g., paper sizes, styles, templates,...).

But that probably would require a better world to function...

well, i wasn't hoping StarOffice and MS Office to share configurations ... i was rather thinking at sharing config *within* one office suite, or among programs that reuse a common library (something like a "KDE Look&Feel" option group ?)

Preferences naturally come into groups (those tabs in your configure... window).

Solar wrote: The necessity to hack stuff manually usually just points towards a major weakness of the software in question. (See version control: Many people prefer CVS because they can hack the back-end files - which they have to because CVS doesn't support many things. Subversion is blamed for having a binary, un-hackable back-end - which wouldn't be a problem if that backend would "just work", which unfortunately it doesn't.)

I agree with you, but it's funny that you take Subversion as an example. I've not had a problem with it (at least not yet) and things I used to do with CVS by manually hacking the repository are quite easily done through the interface (or bindings) with Subversion. The only thing I sometimes miss is being able to fix miscommits directly; in Subversion you have to fix it with a new revision, which leaves ugly traces in the history... oh well..

That being said, what is the "Linux policy for configuration files"? I couldn't find much similarity between the lingo of, say, httpd.conf, rc.conf, and sendmailrc...

Yeah. I meant "Linux policy" (or more generally Unix policy) being that in the end, applications decide what they want. That said, having a standard library with enough functionality to handle the common cases, and having it right from the start, should encourage use of standard principles. And if someone wants to miss-behave, at least have them do in a single, well specified place.

As for the "supposed to put data there" I was actually thinking that it would be FORCED. That is, the /settings/application would be the only place that application COULD write their settings into.

That said, I also though of having several "logical" filesystems:

console: would represent the local console from which the user logged in, exporting devices local to a console such as keyb/mouse/video/sound/removables.

settings: would represent application's settings place. Application couldn't even SEE stuff outside that place.

user: would be user's "home directory" and only accessible to applications through standard open/save dialogs (and drag&drop service and similar), giving true capability security; the standard file-dialog automatically grants the necessary capability when a file is selected by the user.

public: would be a place were all the shared stuff would reside, acting similarly to the "user:" space, but in addition using standard user/group ACLs to restrict users.

But that has nothing to do with configuration files really...

mystran wrote: I agree with you, but it's funny that you take Subversion as an example. I've not had a problem with it (at least not yet) and things I used to do with CVS by manually hacking the repository are quite easily done through the interface (or bindings) with Subversion.

Until the day some dependency in your system updates your BerkleyDB and leaves you without access to your repositories...

The only thing I sometimes miss is being able to fix miscommits directly; in Subversion you have to fix it with a new revision, which leaves ugly traces in the history... oh well..

Some would argue that it is against the principles of version control to delete the history of anything, but I agree that there should be an administrative tool to "shave off" the topmost commit.

But that has nothing to do with configuration files really...

Correct.

Solar wrote: Until the day some dependency in your system updates your BerkleyDB and leaves you without access to your repositories...

Backups are a Good Thing

kinda OT but Im looking forward to when subversion is backended with firebird (my db of choice) or pgsql...

in the meantime, an every other day svnadmin dump is satisfactory.

Note that since 1.1 there's the FSFS backend available (plain text).