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.

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!

Dot Categories: 

Comments

by Pinaraf (not verified)

I think a lot of people don't understand the aim of the windows registry.
The windows registry is here to be big, hard (impossible ?) to understand...
Why ? Because the registry is the best way to store datas after removing a software. With the registry, a shareware can write when it was installed, and without a manual remove of the key, we won't be able to re-install the shareware...

by Corbin (not verified)

Luckily with the Linux Registry you will just be able to search the registry for any keys created on Date X, or search for keys that haven't been accessed in Y days, it will kind of improve that situation (it would allow you to use any normal search methods you use for normal files)

by Pinaraf (not verified)

It will be a text file, so it will be easy to make a diff between each install...
But I don't like the idea because if the file is broken by a software, what happends ?

by Avi Alkalay (not verified)

Different from the Windows Registry, the Linux Registry does not have a single file for storage. Keys are apread through the filesystem.

by Johannes Wilm (not verified)

As an example:

johannes@brinsley2: ~$ rg set -c "My first key" user/example/key "Some nice value"
johannes@brinsley2: ~$ cd .registry/
johannes@brinsley2: ~/.registry$ ls
user
johannes@brinsley2: ~/.registry$ cd user/
johannes@brinsley2: ~/.registry/user$ ls
example
johannes@brinsley2: ~/.registry/user$ cd example/
johannes@brinsley2: ~/.registry/user/example$ ls
key
johannes@brinsley2: ~/.registry/user/example$ cat key
RG002
40

Some nice value
johannes@brinsley2: ~/.registry/user/example$

by Richard Moore (not verified)

This could be very problematic on some filesystems, especially things like CDROM. I also cautious about the performance impact of this arrangement. If you have multilayered KDEDIRS (eg. because you are using kiosk to lock different aspects of the system down for different groups of users), then the number of files involved is immense.

by Johannes Wilm (not verified)

I don't get it, what does it have to do with CDROMs? Is it a question of ~/.registry/ being writable to? Wouldn't that also apply to ~/.kde/share/config/

Also, I don't get the part about kiosk. Sure, I get that you apparently have groups of different levels of what can be changed by the user. But isn't that pretty much useless if it only applies to KDE apps anyways? Shouldn't that be something that you implement in some future version of the registry itself so it will work for ALL apps?

I think this is really needed very urgently, as we should be able to simple link the entries for several entries in gconf and kconfig and with a bit of luck the entries are formated in the same way and we should be able to use the same folder for desktop and the same fonts, colors, etc. And it would actually be a clean way of doing it.

by Richard Moore (not verified)

> I don't get it, what does it have to do with CDROMs?

IIRC there is a pretty low file system limit on the number of files in the ISO9660 format. In a live CD running KDE, the large number of files this design requires could be a problem.

> Also, I don't get the part about kiosk.

I'm referring to large number of files that would need to be opened during application startup.

> we should be able to simple link the entries for several entries in gconf and kconfig

This is a very bad plan. It will quickly lead to corrupted configuration due to version skew. In any areas where there can be a mapping between the two desktops, it needs to be explicit rather than just common config entries.

by Johannes Wilm (not verified)

ok, I get the CDROM-argument. Well there is always still KConfigINIBackEnd, and that won't go away. The whole thing is set up to allow for different backends as far as I read the sources, but as there is only one implementation currently, it is hardcoded as being the one used. Also, if you watch the video from akademy, the linux registry is set up to have different backends (so for example when running windows it uses the windows registry as it's backend), so it should be possible to have a XML backend as well. Or am I wrong?

About the linking: the registry allows for symbolic links which make one and the same key available at two different locations. Without changing anything but the backends used in gconf and kconfig, some keys will probably be the same to start with (that is in format of the contents).

A tiny little python or bash script should be able to link all these to oneanother just for now. (just for testing of course or until the next kde comes out... and that could be in 1.5 years)

Then probably a freedesktop standard can be formulated over these and they can be put into /user/sw/freedesktop with other global kde stuff being in /user/sw/kde and gnome global stuff in /user/sw/gnome (all normal apps simply having their stuff in /user/sw/APPNAME, and if it is system wide and not just for one user it will be in /system/sw/... instead).

by Richard Moore (not verified)

As you say, it sounds like it should possible to have multiple backends, though this would seem to remove one of its advantages.

> the registry allows for symbolic links which make one and the same key available at two different locations

The trouble is that there are often semantics associated with these values and it is easy to get into an undefined configuration set (ie. one that an application would never generate itself). If configuration is to be shared, then the contract between reading and writing applications must be explicit.

by Johannes Wilm (not verified)

What advantage does it remove that the LR supports multiple different backends? At almost all times you would probably use the one-key-one-file solution, an alternative backend for an xml-file could be a compile time option that is used for the rare cases where it is useful. The reason why the standard interface doesn't work with with a XML-file is library dependencies.

About the keys:

/user/sw/kde/Paths/Desktop would for example have the value "$HOME/"
and
/user/sw/nautilus/preferences/desktop_is_home_dir would have the value "true"

given my current configuration.

Now obviously, although these two things say the exact same thing, they are incompatible and for that a freedesktop standard is needed, I agree with that. But you can see how this will be so much easier to try out, etc. right? And it would not be possible with the current gconf/kconfig solution.

by a.c. (not verified)

>though this would seem to remove one of its advantages.

Actually, I think that is one of the better things about this. It will provide a nice clean seperation of policy vs. implementation.

by koos (not verified)

If large parts (that what isn't needed for boot) of the LR can be symlinked to either an untar'ed tmpfs directory or a loop cramfs, it would solve both the CDROM and KIOSK issues. Although each entry requires a system call, both methods make LR actually a shared memory implementation.

by Jakub Stachowski (not verified)

I like idea of consolidating configuration system but I don't think Linux Registry is best tool to do it. To be useful it has to be adopted by majority of applications and frameworks or it will be "yet another configuration system". And how big chance has system, that forces different API *and* configuration files structure? Small if you ask me. Another problem is that Linux Registry only deals with simplest case - configuration files stored locally on disk. No network-wide configuratio, no LDAP etc.
Instead of that I suggest looking at UniConf (http://open.nit.ca/uniconf.pdf). It has concept of many backends that deal with actual configuration files so it doesn't restrict developers to one particular format (like LR) but instead gives them ability to use *any* format undestood by backends (you happen to like XML? or maybe INI-style? fine, so KDE will use it). These backends can not only access local files but also get information from LDAP server, SQL, whatever. They can also be "stacked" allowing something following scenario of searching for config key: "first check if key is in read-only /etc/overrides.xml, if not check in user-writable ~/program.ini if still not found get default value from LDAP server. Ah, and our LDAP server is damn slow so its responses should be cached". Eh, I imagine simple GUI tool for admins to specify how programs should access their config - simplicity and user-friendliness meets power and possibilities. Multiple backends also mean that UniConf is useful even if not adopted by everybody. And this is where LR could have its place - as UniConf backend.

by koos (not verified)

> but I don't think Linux Registry is best tool to do it. To be useful it has
> to be adopted by majority of applications and frameworks ..
Why doesn't this apply to your UniConf too?

> These backends can not only access local files ..
NFS?

> They can also be "stacked" ..
KDE has that as long as I remember, ie. $KDEDIR/share/config gets overruled by .kde/share/config. And LR seems to have that too, a /etc/ global and $HOME/ userlevel override.

You forgot to mention how UniConf solves the access part on each entry. And how does it perform with a middleware?

by Jakub Stachowski (not verified)

>> but I don't think Linux Registry is best tool to do it. To be useful it has
>> to be adopted by majority of applications and frameworks ..
>Why doesn't this apply to your UniConf too?

Just to clarify: I'm not involved with this project. I just found it some time ago and thought that it was interesting.

>> These backends can not only access local files ..
>NFS?

LDAP? SQL? Caching? Persistent caching (for fault tolerance) ?

>> They can also be "stacked" ..
>KDE has that as long as I remember, ie. $KDEDIR/share/config gets overruled >by .kde/share/config. And LR seems to have that too, a /etc/ global and >$HOME/ userlevel override.

But these are arbitrary defined, not admin defined. My example was only example and nothing more - admin can setup it anyway he wishes.

>You forgot to mention how UniConf solves the access part on each entry. And >how does it perform with a middleware?

Huh? What "middleware"?

by koos (not verified)

> Huh? What "middleware"?

LDAP? SQL? Caching? Persistent caching (for fault tolerance) :-)
That what sits in the middle of the application and the final storage on disk. Which is IMHO a major slowdown on UniProcessor systems (as all look-ups require a server round trip)

by Eike Hein (not verified)

> To be useful it has to be adopted by majority of applications and frameworks or it will be "yet another configuration system".

I think the key to getting this off the ground is getting X.org to adopt it. If LR were to be installed with that key piece of software, other application developers (and X11 desktop environments) would soon start using it as well.

And since X.org is just at the beginning of becoming the most popular X11 implementation (with distros switching to it left and right), the time and opportunity for that change to occur is now.

by Avi Alkalay (not verified)

From my perspective, UniConf has several issues:

- It is too complex, with all its plugin systems
- It is a middleware, which again leads to complexity
- It is a daemon, so it stands for a single point of failure
- It does not provide a universal single namespace for key names. Each program define its own
- It is C++, not suitable for base system programs like /sbin/init. And, from the author, the C binding are still not good.
- It has too much dependencies like the wvstreams library, which is under /usr/lib, which can be unavailable to whatever runs before you get /usr mounted
- I tryied hard to find source code and download it to have a look (so then I can provide you guys more info about it :-), but it looks to be unavailable
- Weaker ecosystem then LR.

Be carefull with multiple backends, because in the end they just add too much options, and we'll end up having distro A using backend X, distro B using backend Y, distro C developing their own backend. And we don't want it.

Anyway, LR was designed to, after being compiled, to not have multiple backends, on purpose.
What is simple is good. What is good is simple. If its not simple its not good. If its not good its not simple (some chinese proverb).

One more point: the central points of LR is the key namespace and the API. So in the future, if somebody really need it, he can develop some fat plugin system. This is just operational details.

LR does not want to compete with network systems like NIS and LDAP. Its focus is only with those local multiformat human readable text files (99.9% of configurations). Period.
Besides, please don't think that migrating a local configuration to NIS ir LDAP is that easy. LDAP, as any other DB system, demand rules and an architecture.

by Jakub Stachowski (not verified)

> - It is too complex, with all its plugin systems

More features causes complexity. KDE is more complex than fvwm+xterm and I still like it.

> - It is a daemon, so it stands for a single point of failure

Not true. It can run without daemon just fine (as library).

> - It does not provide a universal single namespace for key names. Each >program define its own

I don't understand the difference - both UC and LR define tree of key-value pairs and every program should define 'root' in this tree.

> - It is C++, not suitable for base system programs like /sbin/init. And, >from the author, the C binding are still not good.

/sbin/init doesn't need features of UniConf so I agree that LR would be sufficient. And UC can coexist with LR just fine.

> - It has too much dependencies like the wvstreams library, which is under /usr/lib, which can be unavailable to whatever runs before you get /usr mounted

Agreed. I don't like wvstreams dependency either.

> - I tryied hard to find source code and download it to have a look (so then >I can provide you guys more info about it :-), but it looks to be unavailable

It is part of wvstreams source tree. cvs -d:pserver:[email protected]:/cvsroot co wvstreams

>- Weaker ecosystem then LR.

And what do you mean by that?

> Be carefull with multiple backends, because in the end they just add too >much options, and we'll end up having distro A using backend X, distro B >using backend Y, distro C developing their own backend. And we don't want it.

I really don't get that - it is like saying that we should have one distro, one window manager, etc. Why do you want to restrict admins always to use simplest case - bunch of files on local disk? Multiple backends are really no problem - it is transparent for applications and admin can set it as he like (I happen to like XML for example).

>One more point: the central points of LR is the key namespace and the API. So >in the future, if somebody really need it, he can develop some fat plugin >system. This is just operational details.

That seems good.

>LR does not want to compete with network systems like NIS and LDAP. Its focus >is only with those local multiformat human readable text files (99.9% of >configurations). Period.

And this is a problem. Suppose that you convinced Apache developers to switch to LR. It makes using central configuration via for example database impossible (because they would have to implement another API for that). With UC it is up to admin how and where he wants to store config data.

As I understand, LR is created to solve one particular problem: multitude of config file formats by unifying them.
UC solves that (another way - by making any format available to any application) AND gives additional benefits.

by Paul de Vrieze (not verified)

I agree that current linux registry seems to be too limited. What I would like is to be able to say: "This part of the registry needs to be stored in ldap (accounts)", "This part should live in a file (/etc/inittab)", or "this part should be stored flat in an ini style file".

In such a setup one would provide one or a few standard modules that live in /lib, but provide an ldap plugin in /usr/lib. It would even be possible to have that plugin do some caching with a daemon.

What I further would really like is that applications would be forced to use a single key in an identified location. Making it very hard not to do so would probably also work. In any case a windows-registry like mess should be avoided. The namespace should not become too deep or cluttered

by Nurul (not verified)

The registry should not be the palace applications look for their config files, but we do need some way other application can interrogate the configuration. My strong feeling is that there would be a hybrid system:

1. there is a /proc like file system for configuration. e.g. /configfs
2. Each config file has an associated script that will populate this /configfs - the config FS would look just like the registry
3. The subsystem associated with the config file should provide the script that populates the /configfs
4. For each config file there should also be a script that would perform a consistency check on the /configfs
6. Changes can be made to the /configfs dynamically but it will not have any direct effect on the underlying application or the underlying config file, bat a save operation would run the reverse script that would reverse the data back into the config file and a 'propagate' operation that would notify/restart the underlying application.

Benefits - we get a simple way for other applications to check configuration without complex ad-hoc parsing, existing applications do not change (what good is a global registry if only a few applications use it). We are not totally dependent on the application maintainers to benefit from the /configfs - although it would be best if the application maintainers write the scripts that would populate the /configfs but in fact anyone could dot it.

by Mike Hearn (not verified)

Hmm, without a daemon how can applications be notified of updates to the configuration? This is absolutely central to gconf for instance, and nothing that wants to replace it can lack this feature

by jmfayard (not verified)

Yep, Linux Registry has its drawbacks, some of them are described on freedesktop.org wiki :

===== http://freedesktop.org/Standards/config-spec
registry.sourceforge.net

This proposal stores every (key, value) pair in a separate file in the filesystem. On most filesystems, this is very inefficient, although systems such as reiserfs support it well. It also makes accessing the keys slow if many values need to be read (which is typically the case when an application starts, and especially at boot time when it causes many disc seeks). The registry does not support change notification, locking, networking or cascading, all of which are required for a desktop registry.
======

by Eike Hein (not verified)

Beats the myriad of configuration files we use nowadays, though.

Linux Registry is simple, straightforward. That's its biggest advantage over many other "the config system to end all config systems"-type projects, which may be superior in the feature department, but also have a much higher barrier of entry/adoption. I say let's go with something simple like LR - it can be improved upon and extended at a later date fairly easily.

Also, keep in mind that LR doesn't aim to replace e.g. GConf - it can act as backend for GConf, though.

by Avi Alkalay (not verified)

Exactly.

For GConf or KConfigXT, LR is a perfect common backend.
So you keep apps source code compatibility.

by Avi Alkalay (not verified)

This is an old post.
It currently supports change notifications etc.

A key point some people (specially FD.o folks) don't see is that LR was designed for super generic and base system usage. Then it can be used from that low level to anything up.

If all their requests are satisfied, LR will not be usefull for very base system programs like PAM, /sbin/init, etc, because it will have too much dependencies, and it will be too much optimized for desktop. If you optimize something for certain use, you'll deoptimize it for some other.

So LR was designed to be the simplest possible, and additional features (and dependencies) can be added on top of it easilly.

by Some random KDE user (not verified)

But one application could have a single key/value pair stored in the registry, with the value being the "real" configuration file of that application. This way, there would be at least a facility to conveniently and unambiguously locate a configuration file. Nowadays, most applications have a complex configuration file search mechanism, so that difficulties arise to determine the exact files which are chosen by the application.

by Avi Alkalay (not verified)

LR provides key monitoring and change notification, across programs and across users. It uses a mechanism similar to SGI's libFAM.

This is the API documentation you can use to get fine tunned change notifications of entire key sets or a single key:

http://registry.sourceforge.net/api/html/group__registry.html#ga16
http://registry.sourceforge.net/api/html/group__registry.html#ga17

You can get notifications like:
- When value changes
- When only key access permissions changes
- When key comment (description) changes
- Etc
- Any combination of all

by Simon Edwards (not verified)

What is the status of this project? What is working right now and what still needs to be done? and most of all, what is the status of all the un-fun work such as integrating LR with existing programs and distributions?

or are the LR people just doing the fun part of making a framework and hoping that other projects will jump onboard and do the thankless integration work?

Just trying to be realistic here.

--
Simon

by Eike Hein (not verified)

> are the LR people just doing the fun part of making a framework and hoping that other projects will jump onboard and do the thankless integration work?

With Avi Alkalay attending aKademy and giving a talk about the project, they're obviously investing both time and money in getting developers interested. Which is a fine way to get the ball rolling; to spark discussion of the issue LR tries to address. Once the manpower is there, I'm sure the development of patches to existing software is going to be the next logical step.

You have to admit: Convincing people "on the inside" is likekly to be more important than submitting patches as outsiders - we're talking about getting projects to replace their configuration backend with a new external dependency, after all. Evangelization is key.

by Avi Alkalay (not verified)

Simon, you touched the central point.
Actually this project is about 0.2% of software and 99.8% of evangelization and patching.
Actually, the software done, fully documented, etc. No we are making awareness....

Anyway, check

http://registry.sourceforge.net/#ecosystem

to see some things happening. GLibC is being patched too.
And yes, you can also help make that list bigger :-)

by Pedro Fayolle (not verified)

What about non-Linux systems? Most software running on Linux is able to run also on a plethora of other OSs. Wouldn't the implementation of this tie software to Linux? I know this could most likely be easily implemented anywhere, yet the current name of the project is "Linux Registry", and as far as I've seen it's also meant to be tightly bound to a Linux system.

by Avi Alkalay (not verified)

This took a considerable amount of attention. The idea is to let Apache use LR on Linux, BSD, Unix, Windows, etc, each port using a special platform backend, but calling the same API.

Linux is in the name only for "marketing". It uses only POSIX calls, so it is portable to Windows, Mac, Unix, BSD, etc. So on Windows for instance you'll use the LR API and namespace, but keys/values will be actually stored in the Windows Registry

I've successfully compiled it in BSD, already.

See the presentation I delivered in the aKademy, about this subject.
It is here: http://registry.sourceforge.net/registry.sxi

by David (not verified)

It seems to me that this "marketing" name is not aimed at the primary audience, the developers, but towards the secondary audience of suits and PHBs. "Registry" isn't going to appeal to the developer because of its connotations with Microsoft's centralized information model, and "Linux isn't going to appeal to those developers using a different operating system. I'm even imagining the reaction to my customers when I tell them they need a "Linux Registry" to run the native OSX application I made for them.

This project really needs a new name. It's not a Linux clone of the Windows registry, yet that's what its name implies. Not only are you marketing this to the wrong people, it seems that you're anti-marketing it to the right people.

by Eu (not verified)

Look, at some point, this is bound to happen. It is cost prohibitive to develop hardware drivers and software for every possible unix-like system.

Some people don't seem to realize, particularly older unix users, that changes such as these are necessary to bring Linux up to the level of usability of existing proprietary systems.

What we need to do, the whole FLOSS community, and in here I include the BSDs and Linux folks, is set our egos aside and ask ourselves whether we really need 10 different kernel or rather a really good one. If we ever expect Free Software to succeed, we will need to sacrifice some of our own pet projects for the greater good, by which I mean acceptance of FLOSS, greater hardware compatibility/availability and more ISVs developing to our platform.

Linux has become the defacto standard that many in the industry have been looking for in the past 20 years and I think that that is a damn good thing, even if it means that I'll have to switch my OpenBSD server to Mandrake, Red Hat or whatever.

by Roey Katz (not verified)

>Look, at some point, this is bound to happen. It is cost prohibitive to >develop hardware drivers and software for every possible unix-like system.

So what happens when some new app comes out for Linux and there isn't yet a fixed standard for the apps's Registry keys? One distro will start the keys at one point in the tree and another distro will start the keys in a completely different place. Who is going to mandate standards for Registry's key heirarchy? Are the big commercial Linux vendors going to follow it?
What's in place today to discourage divergent heirarchies among Linux vendors?

- Roey

remove the turtles from my name to respond.

win95/98/me/NT35/NT4/Win2K/WinXP ... etc. etc.

as long as standardization on drivers for windows is driven and owned by hardware makers (and not MS doing another embrace and extend WinModem WinPrinter move) then it benefits Unix too.

From ZD.net:

FreeBSD 5.3 will ... introduce a software layer that lets Windows network drivers work with FreeBSD. This layer, dubbed Project Evil, means that wired and wireless network cards should be able to work with FreeBSD even if the manufacturers have not written any drivers for the operating system.

"Bill Paul (a fellow core team member) has done the work there," said Long. "His method was to write a Windows emulation layer that provides the API (application programming interface) hooks that the drivers use. It seems to work for quite a number of drivers so far."

still, hardware maker adoption of Registry without some standard to conform to almost guarantees that different vendors will come out with different key heirarchies. Besides, hardware vendors write their own drivers. They can stuff keys wherever they want in the Windows Registry, because it's only their own drivers that have to deal with it on that level.

Yuck.

As an administrator, I find it a pain to have even two ways (between Red Hat and Debian) to configure the same programs. If these FHS and LSB standards (1) provided usable standards and (2) were adopted by the big Linux vendors, my job would be easier.

How about FHS/LSB adopting the Linux Registry?

- Roey

remove the turtles from my address to reply.

by Avi Alkalay (not verified)

The utopia is to let the developers define their keys structure. This should be done in the development time, and not in the packaging time (which leads to differences between distros).

LR documentation provide about 4 bullets of good practices, and that should be enough, I think. They are here: http://registry.sourceforge.net/#bestpract

by David (not verified)

Funny, your same exact argument is often used to tell people to stop working on KDE and join the GNOME effort. The Free Software community has managed just fine without a centralized dictatorship, and I think we will continue to survive without it.

by Johannes Wilm (not verified)

Hey,
does anyone have some somewhat intimate knowledge of kdelibs/kdecore/kconfigbackend.cpp and kconfigbackend.h? KConfigINIBackEnd is hardcoded as being the one used so a quick hack to try out using linuxregistry as the backend would probably be very usefull.

I have tried, and I might try again if noone else does, but my main problems are that I don't have an intimate knowledge of C++ and especially conversion from one thing to another (`KConfigBase*' to `KeySet*'). I would probably find out, but it would take a while.

It is probably a real easy way to get a lot of credit within a few minutes.

by jmfayard (not verified)

See this mail from Waldo Bastian.
http://freedesktop.org/pipermail/xdg/2004-April/003711.html

Hope that helps.

by koos (not verified)

Recently I was looking at this (after reading a mail on kde-devel IIRC, about using threads for config files) but although the multi-backend and abstract KConfigBase, KConfig contains a 'KEntryMap aEntryMap;'. Which means that parallel reading from disc and querying entries (eg. block, join config thread, until entry is being read or all entries read) is simply not posible :-(

by AntiGuru (not verified)

is more flexible ...

www.esmith.org

Linux Registry is scary ... at least GConf only targets user and desktop applications.

by Douglas Phillipson (not verified)

Haven't we learned our lesson from windows about a all encompassing registry? I like all my settings for all different programs in separate files thank you! I would NEVER buy into another registry no matter how many other problems it might solve!

Doug P

by Nurul (not verified)

I agree completely, but we do need a better solution for handling configuration meta-data. I have posted a suggestion that would keep the current configuration information intact but extract the data from all the configuration files to act as a meta configuration knowledge base. This would allow other applications to easily interrogate the configuration. Security is an important concern so this meta data would need rather fine grained security. That has to be clearly thought through.

by Avi Alkalay (not verified)

The problem with the Windows registry is its implementation:
- single point of failure
- binary blackbox
- proprietary

The design of LR was made exactly to avoid these issues.

by Fabs (not verified)

I agree configuration may be painful but a registry may give root privileges to an automated userland process and virii will be a possible nightmare in Linux, its like [W/L]indows giving everybody root (or administrator) access just to make gadget configuration (like web cams or mem stick readers) "easy".

NO to Linux registry

Well as the Open Source world is a free world, anybosy is free to implement a Linux Registry but I really hope nobody will use it.

by Nurul (not verified)

The registry is totally broken in windows, let us not make the same mistake.