linux registry (no, not that again!)

David T Hollis dhollis at davehollis.com
Tue Jul 27 22:38:18 UTC 2004


On Tue, 2004-07-27 at 16:56 -0400, Jeff Spaleta wrote:
> Looking at all the examples on the webpage, id saying making those
> changes at the distribution level is dangerous and adds tons of
> maintainership burden. This needs to be advocated upstream if this is
> going to be useful. At most, the this api can be contrasted with the
> current sysconfig approach for the distribution specific initscript
> stuff, but there is no way this is an appropriate approach for general
> usage (even if its technically better) unless upstream maintainers for
> projects agree to use it.  Like the webpage says, the trick isnt so
> much the technology but that people have to agree to use this. If
> upstream projects don't agree to use it, then then implementing it at
> the distribution level is going to just add that much more confusion.
> 
> 

This is exactly right.  No distribution is going to patch every
application to use this 'registry' instead of it's regular config file
format.  If the changes are made upstream, the distros will inherit this
and have to deal with it.  I think the there are at least three big
hurdles that this project faces:

1) Registry in the name - too many negative connotations
2) Linux in the name - it isn't Linux specific.  *BSD folks wouldn't
even think it's remotely relevant to them even though the project admits
that it isn't a Linux specific thing.
3) Upstream projects would need to migrate to it - I really can't say
that I see that happening en masse.

Nice idea, definitely better than the Windows implementation of the
registry (but then, what isn't?).  I would be interested to know what
kind of bog down it would face on a system with a bunch of applications
and the like and to start having either really large text files to parse
through for values or a whole bunch of little files that start showing
certain filesystems dislike of such situations....

-- 
David T Hollis <dhollis at davehollis.com>





More information about the fedora-devel-list mailing list