Re: I think this is a bad idea
> % The Registry isn't in one file, but
> % folder is an
> % actual folder, and each key is a file.
> % That means it can
> % use the filesystem's security.
> Holy cow!!!!! One of the comments above
> stated that each program having its own
> config file results in a fat and bulky
> system. Now, its being suggested that
> not only each program be included in a
> single registry, but *EACH KEY BE ITS
> OWN FILE*?!?!?!? And this isn't fat and
well if your file system is effiecient at saving small files then it's not bulky. If your file system is effecient at looking in large directories (use a modern system that uses hash tables for directories rather than flat dirs), then it will be fast. Ideally there should be little difference in performance between storing all your data in a single file using some effecient algorithms and storing each folder leaf as a file. Of course not ever file system is near this ideal, but most are pretty reasonable.
Performance of your configuration files should never be an issue. Applications would normally only look at configuration on start up, and perhaps occationally poll them to realize updates. If you have some small short life application that looks at configuration often (like procmail), then performance of configuration files would be an issue. But I would say that the model procmail uses is less than ideal, and perhaps you should have set it up in a batch mode if performance is critical.
> From a configuration managment this may
> seem like a good idea, but from a
> technical standpoint, the filesystem is
> going to suffer. Plus, managing 100+
> machines still isn't helped. For that
> matter, why not go one step further and
> instead of a system registry, make a
> network-based registry to house all the
> settings of all machines in one
Well the idea is with a generic API you could fetch configuration over LDAP or whatever transparently. This configuration file system would even work correctly over NFS.
> I agree that standard text files are
> still optimal. They are conducive to
> virutally *any* means of management.
> The registry requires an API, text files
> require human eyes...nothing more. Any
> scripting language can be used to write
> a script which traverses *thousands* of
> machines to adjust text files. This
> task would be much, much harder with an
> API-based registry.
registry is certainly human editable. It is designed specifically to allow you to edit, browse, back-up, search, etc using standard tools. vi to edit, cd and ls to browse, find to search, tar to back up. you can even edit a temporary copy and use mv to put it in place once you have verified your configuration is ready for production.
For space and performance a binary database would be ideal, but then you'd lose the benefit of being able to hand edit the configs if there was a catastropic failure.
every application implementing it's own flat file format results in a lot of duplicated code. Theoretically you could make applications smaller if they just linked in the same library for configurations and reused the same bit of code to read out of a registry. Although this registry is actual so simple, that you don't need a library (but it is recommended you use one). and generally implementations of this style of configuration are going to be a lot smaller than your typical XML-based or weird hierarchal formats (like bind or dhcpd)
> I commend the authors of the software
> for _wanting_ to make life easier for
> sys-admins of all stages. But I'm sorry
> guys, this does not _make_ it easier.
I think it has quite a bit of potential. And I commend the authors for having the guts to stray away from traditional Unix into something that might be easier. A major advantage of Free Software is that it can provide a way for an entire community to experiment with new ideas.
Also I'm not sure why you say so strongly that it does not make anything easier. Could you give an example of it not making things easier? All I saw were complaints about text files and having lots of files that would some how slow down a file system designed to have lots of small files on it.
Designed to be "stable" but is not yet.
This application, according to it's website is ment to be "stable" rather than featureful. Seeing as it segfaults as soon as I press hotsync on my PalmIIIx (linux 2.4.18) it makes me think that "stable" is a relative term and does not indicate that the code has gone through any sort of review or evaluation process. Sorry to slam the software so much, but it's not right to imply that the software is stable when infact it is not.