[Registry] Re: LinuxRegistry in Freedesktop & KDE

[Avi Alkalay]

>   About current knowledge, we must admit that any kind of user which is
> able to read and change XF86Config by hand would have not a single
> problem in going to /etc/registry/whatever/key/ and edit the keys
> inside. The current knowledge is not lost, since currently any admin has
> lots more knowledge than necessary to edit a file. Also, take into
> account that we could use command line tools to do that, apart from
> other UI-oriented utilities we might have (curses-based, KDE-based,
> GNOME-based, whatever). A simple key editing tool is as good editing
> XFree's configuration as editing the Apache configuration.

Actually, you won't edit the files by hand. Only in emergency situations.
The everyday usage is something like:

bash# rg set /system/sw/XFree/current/Screen0/resolution "1024x768"

>   And we code not only for end-user usability. What about system
> administration? Isn't it useful to share desktop background's
> preferences, keyboard layout prefs, mouse prefs? And then we could speak
> about file formats, and the tons of code needed to parse every
> configuration file in every piece of unix software.

You steal my words.



>   I agree with Avi. Linux still have no good software installer for
> applications, probably due to the heterogeneity of system
> configurations. Asking the user to "please, set permission to xxxx", and
> also asking for pathnames to locate things is not what I would define as
> "usability" and "user-friendlyness".

I hate these "documented post-installation instructions".




>   "Incredibly lack of efficiency" in needed code, in system
>   administration
> learning-curve, and, of course, in a wrong combination of hardware and
> software chosen by the user. Gaining 1 millisec in reading a complete
> configuration file is poor benefit compared to:
> 
>  * Ability to alter parts of the configuration file, while keeping the    
>   rest untouched. How many disk accesses we save now? And memory
> consumption?
>  * Ability to read just-what-we-want, instead of reading *everything*.
> (Why should I parse the complete Apache configuration file, just to tell
> the user the names of the virtual hosts?)
>  * Ability to read on demand, instead of preventive reading. (Why should
>  I
> parse the complete Apache configuration file, just for the user to end up
> changing only the admin's email address?)
>  * Ease in versioning. File format changes are evil.
> 
>   "Extreme waste of disk space" has not the same weight as ten years
> before. Hardware gets cheaper as we write. Harddrives from nowadays are
> duplicating their capacity vertiginously. Not that I'm saying we want to
> waste space just because we have it. But the reasons above are good
> enough. It is like storing just two digits for the year field, to avoid
> wasting space in the other two digits.

Man, you are in my team !!



>   There are other alternatives for filesystems that are much more optimal
> for small files, without introducing sensitive impact on bigger ones.
> Changing the filesystem is not a task to do every week, I know. But
> introducing the LR has not to be done today, is it? We can migrate as
> slowly as needed. The final benefit deserves it. After some years, we
> could end up in a better system, using better filesystems, and a common
> configuration architecture.

Yes. We have to think in a practical way.



>   Regards,
>     Daniel M. Lambea

Thank you, Daniel.


Regards,
Avi

-- 
http://www.fastmail.fm - Faster than the air-speed velocity of an
                          unladen european swallow