Why Linux Needs to be Elektrified
From Elektra Initiative
Today's GNU/Linux systems (or other UNIX) are a sum of independent components collected in a bazar. Each of them already have a working, but selfish configuration system. Please read this section thinking about a system as a whole, not a sum of many parts.
The Elektra Initiative tries to upgrade a 1+1=2 system into a 1*1=1 one.
Look into /etc/fstab file. Now look into /etc/modules.conf, /etc/passwd, /etc/ssh/sshd_config, /etc/httpd/conf/httpd.conf. I see here two terrible problems:
- They don't have a common file format.
- Their location in the filesystem may be different from Linux distribution to distribution.
These 2 issues leverages other problems:
- When two different softwares want to integrate themselves, it is programatically very hard to read, understand and correctly change its partner's configuration file. Think about installing a third-party video driver in XFree86, a new Apache plug-in, etc, and letting this new piece of software do the integration automatically, instead of the sysadmin vi the configuration file, understand and change it in the right way. So basic software integration is a pain today for ISVs (Independent Software Vendors).
- A software developer must waste a lot of time to write the plumbing code for configuration file parsing etc. It is completelly out of his scope to write code to interoperate with other software's configurations files.
- Different distributions tend to place different software configuration in different places with different formats. A regular SuSE system administrator, for example, will be lost when asked to work in a Debian or Slackware system. Think about the most primitive example: network configuration parameters. Each distro has its own approach.
- A system administrator must know all these formats.
- There is no way to know today what was changed in a specific configuration file. If /etc/shadow file time changes, there is no way to know if the change was related to nobody's or root's record.
- High-level system administration GUIs (webmin, redhat-config-*, SuSE's YAST, etc) are just a dream today. They can never track successfully all the changes that happens in the format of the configuration files of such a rich diversity of Open Source software (httpd.conf, smb.conf, modules.conf, fstab, etc, etc, etc). The approach of some of them is to keep the configuration ideas in a private database and regenerate the specific configuration file whenever a change happens in this database. Welcome to the inconsistency nightmare.
Other OSes solved this problem by centralizing their configurations, and creating a framework to access them. Configurations then are no more represented by 'configuration files', but by key-value pairs organized in a structured tree commited to some naming convetions.
To achieve multi-vendor/provider consistent software integration, and ease of administration across heterogeneous Linux distributions, Linux needs a key-value pair mechanism to store its configurations.


