[dot] aKademy Interview: Avi Alkalay of Linux Registry Project

[Dot Stories]

URL: http://dot.kde.org/1093768930/

From: aKademy Team <akademy-team at kde.org>
Dept: 1 * 1 = 1
Date: Sunday 29/Aug/2004, @10:42

aKademy Interview: Avi Alkalay of Linux Registry Project
========================================================

     During the  KDE Contributor and Developer Conference
[http://conference2004.kde.org/devconf.php] at aKademy
[http://conference2004.kde.org/] one  of the speakers Avi Alkalay talked
about his project
[http://conference2004.kde.org/cfp-devconf/avi.alkalay-linux.registry.php]
 Linux Registry [http://registry.sourceforge.net]. We met him afterwards
and asked him several questions about this project...


     Please give us some background information on yourself.

     My name is Avi Alkalay, I worked with Linux for 10 years and the
last 2 years  I'm doing Linux and consulting for IBM in Latin-America.
Helping customers migrate to Linux and Open Standards.

     What's the focus of this project and how did it start?

     The objective is to provide an infrastructure to make the Linux
configuration nightmare disappear. This can be achieved through a way to
let programs  integrate automatically, without having to ask users to
manually  edit their configuration files.

     How many people are working on this ?

     30+ members ... many contributions, language bindings and
suggestions.

     Are you paid to work on this project.?

     No ...

     What's wrong with the current way we are managing configuration
files?  In your talk you question that we need to evolve the underlying
OS structure.  Why is that?

     A lot happened in the desktop space: DCOP, XML-RPC, components,
widgets, colorfull themes, fonts, etc etc. but  nothing evolved in the
base OS organization. You can't have a wholly integrated desktop (as a
computer for my mother)  without evolving the underlying OS. KDE or
Gnome don't really deal with plugged webcams, new video cards, etc.  And
the way you integrate this kind of things today in the system makes use
of your human brains and eyes to edit text files like modules.conf or
XF86Config. A software can't really write this configurations for you
effectively, without a considerable amount of complexity or artificial
intelligence :-) It is programatically difficult to parse and change
some configuration bit in a human readable configuration file.

     Each software project (KDE, Gnome, Apache, Samba, /sbin/init,
modprobe, etc...) has its own way to define the format of their (text)
configuration files, so this make them completely separate and
unintegrable software. Configuration is the soul of software.

     Current UNIX systems organization was designed 30 years ago. It has
many strong points, like the filesystem hierarchy, etc, but nothing was
defined regarding the format of the configuration files. I'm talking
about a common format.

     Also, commodity hardware (video cards, webcams, mice, keyboards,
USB, etc.) vendors use to not support Linux (even if the kernel has
drivers for them) because they don't want to deal with complex,
multi-distribution setups, like "in distro A, edit this and that file
this way; in distro B version N,  run tool XYZ, then edit those and
those files in this other way", etc. That's awful.

     Is there any interest from other developers or projects for this
concept of using key trees for storing configuration data
 A lot of interest is showed from many sides. We have people writing
patches, GUI tools, language bindings, etc. Check the project website to
see some of them. Waldo Bastian showed some interest to see how
KConfigXT (KDE Config framework) will behave with a Linux Registry
backend.
     How would the Registry integrate with existing frameworks like
KConfigXT and Gconf?

     These frameworks are more high level, designed for more specific
use: desktop software. Registry was designed to  be the most generic and
low level configuration system you can get, so it can be used as a
backend for these  frameworks. Then, you'll be able to access Gnome
programs configurations with KDE tools, and vice-versa. And also, 
access base system configuration with KDE or Gnome tools. KDE and Gnome
applications source code will still use KConfigXT and GConf API, but
their infrastructure will be a registry.

     So what do you think are the advantages for Linux and especially
for KDE? Is this something which is  of importance in Userland?

     Linux Registry was designed to be the configuration store of
everything on the system, not only for the desktop part. So if we get it
adopted, we'll be able to see programs more easily integrating with
other programs. You don't need to burden users to edit config-files when
software can do that on his own. This will make life easier also for
software and hardware vendors to deploy their products on Linux. So that
way a new program is easily pluggable into the system.

     The key names in your presentation at aKademy were similar to
existing configuration file names, but still confusing to the  newcomer
(e.g. user/env and system/init) Do you not think it would be a good
opportunity to rename these keys  (e.g. from "init" to "startup")?

     Those were just examples .. I choose those names just to be easy.
But keep in mind that keys should not be accessed directly by users.
Stable semantic-oriented GUI configuration tools will appear asking
things like "click here to install and configure your new webcam". Then,
the real keys and key structure that is happening bellow that is
sysadmin stuff, and hopefully he'll have to deal with them directly 
only in rare situations.

     The layout of nowadays configuration files are defined at the
packaging time. In the office of RedHat, SuSE, etc. This leads one Linux
to be slightly different to another Linux. But this small differences
makes impossible  automatic integration and configuration. Switching to
a tree of keys and values concept, makes the application development
team the owner of this layout (which should be unique). So distro A, B
and C, X.org, a video card vendor, a GUI configuration tool, etc, will
allways find the current video card driver in the key
system/sw/XFree/Device/Videocard0/Driver, instead of line 34 of file
/etc/X11/XF86Config on distro A (if user does not edit it), and line 42
of file /etc/X11/xorg.conf on distro B (if user didn't edit it).

     How about using XML .. isn't XML invented for this kind of stuff

     XML is a wonderfull standard to represent any information, make it
portable, human and  machine readable. It adds a considerable amount of
complexity too.  Registry was designed to be available anywhere, anytime
on the system. For this, all required libraries should be there
anywhere, anytime. If Registry used XML for its storage, libXML would be
required, and the XML library may not be available for some early boot
stage programs, like /sbin/init. Well, Registry keys can be used for
/sbin/init configurations, instead of the 30 years old /etc/inittab.

     Anyway, Registry uses XML as its universal format to import and
export keys into/from the key database. This helps on transferring
software configurations from one machine to another, backup, etc.

     Wouldn't using this concept of trees of keys be unreadable for the
human eyes. Better said: can an administrator still edit the files?

     Yes, he can. This was a long discussed subject, and one of the
weaknesses of the Windows implementation. Registry storage are plain
text files, editable with vi or ed. But, thinking out of the box 
(considering time), an administrator will not have to edit keys
directly. A registry infrastructure makes semantic  configuration GUIs
development be very easy to do. So with adoption and time,
administrators will use more semantic  configuration tools, and they'll
be able to edit keys directly too, if they need.

     Don't you think that this name, Linux Registry, can be problematic?
Many system administrators had bad experiences with the Windows
Registry.

     In my opinion the Windows Registry is a good idea behind a bad
implementation. It is one file to store it all. If you loose this file,
or it gets corrupted, you loose your system.

     On the other side, the Linux Registry is not a daemon (so no single
point of failure), does not store all configurations on a single file,
was designed with security in mind, and stores user's configurations in
each user's $HOME, and system's on /etc.

     Anyway, I receive many many e-mails from people liking the design
but feeling the name as an obstacle to adoption. This name was chosen to
make an automatic awareness in people's mind. Sometimes it works for the
wrong side.... So in a few days, the name of the project will change to
something very cool. Stay tuned !!

     Where do you see the future of Linux Registry going?

     Hopefully it will be accepted by major projects like KDE, Apache,
Samba, etc, and distributions. Also, more storage backends should
appear, more language bindings, etc. Linux/BSD/Unix today is a 1+1=2
system, and Linux Registry can help it become a 1*1=1.

     The project needs more programs using it, more awareness, more
adoption. The advantages of a wholly integrated system will only be felt
when many programs will be using it, so use it!!

     It is free, designed for Unix, by an old Unix user, to old Unix
users. So give it a try: http://registry.sourceforge.net
[http://registry.sourceforge.net] !!