[Registry] Re: LinuxRegistry in Freedesktop & KDE

Daniel M. Lambea martind at pirack.com
Wed Apr 21 15:08:47 EEST 2004


>> 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"
>
> That's most definately not everyday for me.  Every day, I have
> absolutely no clue how XFree stores it's keys.  If I remembered all that
> my head would explode and my brain would stain the carpet pissing off my
> wife.

  By now, I agree with George. Guessing XFree's keys would be a nightmare.
But if we take into account that: a) keys have comments, and b) keys
have values, then we soon realize that nothing prevents us from:

   a) doing it the heavy-metal way, as soon as I remember the key, and I
want to modify just that value. Pretty valid.

   b) opening our ncurses-based, or KDE-based, or GNOME-based, or
<put-here-your-prefs>-based key editor, then click down the tree until
XFree root key, then select the option "Show linear mode". In this
case, our pretty preferred editor would get the XFree's key tree, and
"compose" a linear-style window with the comments and the values for
each key (editable, of course).

  What do you get from the LR? Firstly, a common config editing software
for whatever you want, in key-by-key or linear mode (or whatever mode we
wanted). Secondly, a common configuration reading/writing routines,
getting stable as time comes, and giving benefit to every package that
relies on it. Thirdly, a system-wide self-consciousness, that by now we
don't have: one example:

  Do we have such a thing like "InstallShield" for Linux? No, we don't,
AFAIK. Does a company benefit from writing such a software that provides
installation routines to third party vendors? No, simply because this is
a configuration mess, and no one wants to move a finger to solve this.
Therefore, such a imaginary "InstallShield" company would prefer not to
exist, instead of doing five or ten different kinds of installators for
every configuration mess. The solution to several vendors is just to
write a self-installer (see NVidia's graphic drivers as an example of
this), that looks for the available packages (of the very same software,
I must say), just to realize that your distro is not in the list, and
you need to download and compile the sources. (nothing negative, from my
point of view... but how many lusers will want to do that? they are
simply scared by the word "compiler")

  Does it mean that, let's say, Macromedia, Adobe, etc. will want to
directly jump on Linux by porting their code? No, of course. They have
to do *tons* of things, apart from porting their code. What about
updates? What about end-user ability to install-and-try their products?
By now, impossible unless that end-user is good enough in administering
his/her Linux box.

  Simply because the linux box knows nothing about the linux box.

>  The way I usually try to edit config is that I lurk in /etc for a
> good sounding directory/file (same I would do with LR) and then once
> found I edit the file and hope that it is a nice (linear not registry
> style where I ought to open every key to get help) read that I will be
> able to figure out how to change it.

  Much like I do. I am an active Linux Evangelizer here, in my small
Canary Islands. I have tenths of people willing to jump on Linux and
forget their Windows box forever. I prepare a sample Linux box, they try
it, they want it for their office, and then they ask the inevitable: How
can I try that book-keeping software? How can I upgrade the Gimp? How
can I upgrade OpenOffice? How can I...?

  My answer is simple:

    - eeeemmmhhhh... well... open a shell, then try apt... or get the RPMs
by hand... try to upgrade them... well... don't forget to become
root... emmm... and then...

  They hear:

    - blahblahahhblah... blahblaaaahhblahh...

  They think:

    - Right. I had to reinstall windows after some months. But I was able
to try the software. I was able to upgrade. I was able to control my
own computer.

> The way LR looks it would be far
> harder to just read the whole thing in a linear fashion (my brain
> functions linearly as I suspect most people do).

  Normal luser brains do not. They want to click-and-install (in their
homes, of course: we don't loose the esence). Linux can be proud to say
that we have the servers, we're going to middleware, then we'll conquer
the desktop. But we have to do something to archieve that goal. We have
to risk something. Unless we wanted to stay on the server-side, didn't
we? Let other OSes to conquer the desktops, because we like our messy
/etc directory intact.

> If you are able to remember what keys are named, you are a better man
> then I am.  I am not able to remember my birthday sometimes and yet I
> manage to admin my own two computers and a webserver with no problem.

  No need for that. See above.

> Do I even remember the apache configuration file config format?  No way,
> I never needed to.

  It is some kind of fake XML. That's what I remember most. And the URL to
the reference, of course. Some parts are self-descriptive, but usually I
do nothing without the Apache's reference. Exactly what I'd get with the
imaginary "Linear mode" in the key editing tool: a "linear" file with
the contents, and the URL to the reference.

> I don't even remember what keys sound like.  But
> because of all the comments I was always able to do whatever I needed
> with very little trouble.

  Just like LR. The keys have comments, that can be, of course, the very
same comments you find in the Apache's configfile.

> And the trouble I had was with semantics of the keys and NOT with the
> format of the file.  LR would not help in my case at all.

  LR would give you no difference in this case, unless you wanted to
participate in some kind of global system integration project (like the
imaginary "Linux InstallShield"), where you will quickly find that
you're lost in the configfile-formats-and-locations nightmare.

  I would say I don't need GNOME as long as I use KDE. But I don't say
GNOME is bad. It is quite different than KDE in several aspects, and
after all, it is as good as KDE. Good for me, good for the sanity of the
community, good for the users who love it and good by itself.

> I also used to manage a server through webmin and never looked at the
> config file.  Note that webmin does not use LR and still manages to do
> this.

  And that's the reason why it needs so many modules to deal with the
nightmare. How easy it would be for Webmin to deal just with keys, and
their comments.

>> >   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".
> And how does LR help here?

  By providing some degree of standarization. Not given by the file
format. Not even given by the way it uses the filesystem. It is a global
effect: by providing a balanced storing format (balanced because nothing
is 100% good for everything), by allowing all-time availability, by
being light-weight (in the desired degree: one can decide to increase
functionality, as always), by providing a common way to do certain
things, like config centralization.

> Most arguments for LR tend to go along the lines of the Chewbacca
> defense.

  This is not the case. Unless one wanted to listen that way. Instead, I
would say most arguments against LR are in the line of the Lazy Boy
Defense.

  Ladies and gentlemen, we vote against LR because otherwise we would have
to do something. Of course, we spend less diskspace by staying in the
file-format nightmare. If we do nothing we won't have to deal with
user-space installers, and other tools to make Linux more attractive to
the companies and non-geek users (that, at the end, they are who push
Linux up or down, depending on their thoughts). If we do nothing we will
save 0.1 millisec in loading XFree (god!)... We don't want to think in a
plugin system that allowed LR to use D-BUS once it was available in the
system. We don't want to think in a better global system, because we
would have to migrate (slowly, with time) our filesystems to a better
one, and we would trash our config-parsing code (that is so lovely). If
we stay forever in ext2, we would save the installation time.

>> Yes. We have to think in a practical way.
> Yes, a practical way.  Reinventing the wheel that solves a different
> problem then the one you claim is the real problem is generally not
> considered practical.

  I don't think LR is reinventing the wheel. LR is just one of the several
solutions that ends up in a coherent system. The way it stores data on
disk is of course open to discussion. The way it might use D-BUS, or the
type of service (daemon or library), etc it's being proposed to open
discussion. But please, be constructive. Don't kill the idea before
thinking in the global benefit. And not only coder's benefit (we have to
do the job, of course), but also the economic, practical benefit: what
this will provide? will it mean ease of migration? will it mean
coherence? will it improve admin tasks? (not only from the code's point
of view) Will more people jump on Linux? (which does impact on the job
offers surrounding us).

  Regards,
    Daniel M. Lambea








More information about the xdg mailing list