Linux Registry, not only the issues side
avi at unix.sh
Sat Apr 17 18:32:54 EEST 2004
Was very nice to see KConfig high-speed performances.
I still didn't worked hard to improve LR's algorithms, and this is also
the price I pay to make LR thread safe. But it will never be so fast as 1
file with many keys as KConfig's. But KConfig is KDE only, not system
I still would like to see GConf's numbers. XML is a different.
Are this discussion's e-mails being accepted in GConf list?
Anyway, I changed that paragraph about ReiserFS, putting this in place:
Some may think that one file per key will consume many filesystem
i-nodes. Actually, when not using Reiser4 filesystem, it may consume some
more disk space, and it may also be not so efficient than reading one
single text file, as KConfig does. But Registry's nature let applications
load their keys on demand; so it is possible to avoid the
read-all-use-some approach. Writing updated keys back to disk is also
more robust, because unchanged keys won't be touched, different from a
single file approach, that must be entirelly rewritten.
Besides that, big applications (like Mozilla, Konqueror, KDE, Gnome) key
gathering time is a very small part of what they have to do to start up.
And the benefits of an homogeneous registry to all system are much bigger
then these issues. Think about a common integration between everything,
flexibility, security granularity and openness.
It is here: http://registry.sourceforge.net/#keystor
SW & IT Architect :: Linux, Open Standards
Linux Impact Team :: ibm.com/linux
* avi at unix.sh
* 55-11-9659-9059 (mobile)
http://www.fastmail.fm - Sent 0.000002 seconds ago
More information about the xdg