aKademy Interview: Avi Alkalay of Linux Registry Project

During the KDE Contributor and Developer Conference at aKademy one of the speakers Avi Alkalay talked about his project Linux Registry. We met him afterwards and asked him several questions about this project.

Please give us some background information on yourself.

 <p>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.</p>



 
 <p><strong>What's the focus of this project and how did it start?</strong></p>

 <p>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.</p>


 
 <p><strong>How many people are working on this ?</strong></p>

 <p>30+ members. Many contributions, language bindings and suggestions.</p>

 

 <p><strong>Are you paid to work on this project.?</strong></p>

<p>No.</p>



<p><strong>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?</strong></p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

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.



 <p><strong>How would the Registry integrate with existing frameworks like KConfigXT and Gconf?</strong></p>

 <p>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.</p>



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

<p>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.</p>





<p><strong>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")?</strong></p>

<p>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.</p>

<p>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).</p>






<p><strong>How about using XML .. isn't XML invented for this kind of stuff</strong></p>

<p>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.</p>

<p>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.</p>




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

 <p>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.</p>



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

   <p>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.</p>

   <p>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.</p>

   <p>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!</p>


 <p><strong>Where do you see the future of Linux Registry going?</strong></p>

 <p>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.</p>

 <p>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!</p>

 <p>It is free, designed for Unix, by an old Unix user, to old Unix users.
 So give it a try: <A href="http://registry.sourceforge.net">http://registry.sourceforge.net</A>!