[Registry] Re: LinuxRegistry in Freedesktop & KDE

[Daniel M. Lambea]

>> in features or ease or use.  In fact, it's a disservice to users,
>> because it would cause all existing knowledge and tools to become
>> invalidated.  With no other gain in usability in the new config
>> system, that's bloody pointless.
> Current tools are inconsistent. Current knowledge is poor. I want my
> mother to use Linux as she uses Windows. You'll find good knowledge in
> experienced sysadmins. (A free desktop isn't only for geeks). Please
> think in the big picture.

  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.

  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.

> Someday we'll have to set some standards in this area. It is inevitable
> for interoperability. We can speak here because we all agreed in the
> "english" standard, even if it isn't the best for everybody.
>
> TCP/IP is not big deal also. But before him, computers had to set up a
> raw communication. TCP/IP was a very simple, stupid, and straight
> forward solution. So simple that it works for everything.

  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".

>> Aside from the incredibly lack of efficiency in read/write speed
>> caused by using those separate files, there's also the extreme wasted
>> disk space.  Each and every file takes up a minimum amount of size
>> (usually something like 2K or 4K or something) on most FS.
>
> Take care here. It isn't so inefficient. It was not refined yet, and
> effieiency is not the only think you must look. Configuration gathering
> is a small part of what programs do at startup. And LR nature lets you
> get them on demand. So it isn't big deal. And I still want to see GConf
> benchmark numbers. So please open your mind and look at the benefits
> also.

  "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.

>>  Most of these keys
>> are going to be small numbers or very short strings.  LR causes you to
>> waste up to 4K or more of diskspace for each of those.  Small system
>> friendly, eh? *snort*

  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.

  Regards,
    Daniel M. Lambea