Re: Anything like the Windows Registry or INI files for Linux/Unix?

From: Christopher Browne (cbbrowne_at_acm.org)
Date: 03/11/04 

Date: 11 Mar 2004 13:33:58 GMT

Oops! Vilmos Soti <vilmos@vilmos.org> was seen spray-painting on a wall:
> gazelle@yin.interaccess.com (Kenny McCormack) writes:
>
>> Now, before anyone starts flaming me, be aware that this is a serious
>> inquiry. There is something nice about the registry and/or INI files in
>> Windows and high level API functions to access them, both in terms of
>> saving you (presumably, you the C programmer) the pain of opening,
>> closing, and parsing files, and in terms of standardization (I.e., solve
>> the problem once and be done with it).
>
> Linux doesn't have anything like the registry. No wonder, since
> Linux is not a monolithic something like Windows. Many parts are
> developed independently. Also, the idea is somehow alien to me.
>
> The problem with registry, as somebody mentioned, that if it gets
> corrupted somehow, then you are hosed.

There's an extra "aspect of safety" to this...

In the "Windows Registry," the whole thing is pretty likely
implemented as a B-tree, and updates therefore affect potentially any
location across the whole set of data in the registry. ANY kind of
problem that occurs can "dump garbage" in with the potential to break
the tree fairly much arbitrarily.

In contrast, with the typical Unix application, each application's
configuration is in an entirely separate file, and those files are
typically opened in "read-only" mode. The risk of "accidentally
dumping in garbage" when a file is opened for read only is, well,
nonexistant.

> Also, if say, your system doesn't come up one day due to disk
> failure, and your backup is not really up to date, then you can
> still grep through te remainings of the disk to rescue anything you
> need. Or a good disk editor can help. Can you use something like
> that with the registry?

Yeah, that's of importance. Whether the Windows Registry is using
btrees or hash tables, it is, either way, "mashing together" a lot of
disparate information, and if you're recovering from a problem, it
won't be easy to tell if you actually have all the configuration for a
particular program. It only takes a single "block" of index
information being trashed to make the whole registry unusable.

In contrast, if you're piecing together fragments from a trashed Unix
filesystem, having configuration for each (well, usually) application
as an atomic file means you can fairly readily tell if any given
config file is either OK or that it needs to be recreated/recovered.

> Unix/Linux most of the time uses human readable config files so
> understanding them is easy. Many programs even include help in their
> config files. Can you do that with the registry?

There are two further advantages:

 - Text-based configuration files usually allow adding comments
   to explain what's going on, or to note what changed when and
   why;

 - You can use SCM tools (like CVS or RCS) to manage the text
   config files that may provide long term commentary of what
   changes and why.

> When I first heard about the registry, it sounded like a great
> thing. But the more I thought about it the more I appreciated
> the simple text config files used under Unix. Definitely not
> as sexy as registry, but on the long run, far more flexible.

There is merit to the idea of, say, writing new applications to store
configuration in a PostgreSQL database. Recent functionality adds in
the notion of "schema", so that you could have a single "config"
database which has a schema for each application, and where each
application may set up some custom tables for its own purposes.

That would lose benefits of the use of CVS and such, and it certainly
becomes more complex to merge configurations together.

The other sort of 'holy grail' that seems to me to be a big step
backwards is to use XML; that adds a big whack of fragility to the
system because it's easy for manipulations to turn XML into, well, "a
ball of text that isn't XML." 

-- 
(format nil "~S@~S" "cbbrowne" "acm.org")
http://cbbrowne.com/info/
You can lead a horse to water, but if you can get him to swim on his
back, you've got something.

Relevant Pages

  • Re: microsoft management console
    ... And if more help is needed with batch files I recommend posting in the ... Sc.exe uses the service key name from the registry. ... Server 2003 Family and Windows XP Operating Systems see the following ... Good Configuration control set will be overwritten. ...
    (microsoft.public.windowsxp.general)
  • Re: Starp up sequence
    ... > 6) WIN.INI [Windows] Load ... > All Users Startup Folder ... > the programs specified in the Computer Configuration setting just before it ... > AppInit_DLLs Registry value. ...
    (microsoft.public.windowsxp.customize)
  • Re: The Beginning Of The End For Micro$oft Reign Of Terror
    ... >>found in the registry. ... cryptic keynames and settings in the registry, someone has a lot to hide. ... > is just as easy to implement in Windows; ... > You're just defending the primitive text-based config files of Linux. ...
    (comp.security.firewalls)
  • (no subject)
    ... >>found in the registry. ... cryptic keynames and settings in the registry, someone has a lot to hide. ... > is just as easy to implement in Windows; ... > You're just defending the primitive text-based config files of Linux. ...
    (comp.security.firewalls)
  • Re: Where Have My Drives Gone?
    ... Windows cannot start this hardware device because its configuration ... A registry problem was detected. ... see the Registry Reference in the Microsoft Windows 2000 Server Resource Kit ...
    (microsoft.public.windowsxp.setup_deployment)
Loading