Original-URL des Artikels: https://www.golem.de/0409/33343.html    Veröffentlicht: 02.09.2004 11:52    Kurz-URL: https://glm.io/33343

Interview: Elektra, die Linux Registry

Von einem alten Unix-Nutzer für alte Unix-Nutzer

Auf der KDE-Konferenz stellt Avi Alkalay, Linux-Spezialist und Berater bei IBM, sein Projekt Linux Registry alias Elektra vor. Mit einem allgemeinen Backend für Text-Konfigurationsdateien will das Projekt eine einheitliche Registry für Linux etablieren. Die grundlegende Idee orientiert sich dabei zwar am Windows-Pendant, es sollen aber gezielt die Implementierungsschwächen der Windows Registry vermieden werden.

Golem.de: Worum geht es bei Linux Registry?

Avi Alkalay: Das Projekt soll eine Infrastruktur schaffen, die endlich den Albtraum der Linux-Konfiguration beseitigt. Programme sollen sich automatisch in das System integrieren, ohne dass der Nutzer eingreifen oder gar Konfigurationsdateien ändern muss.

Golem.de: Wie viele Personen sind an dem Projekt beteiligt?

Alkalay: Mehr als 30, es kommen viele Beiträge, Sprach-Bindings und andere Vorschläge.

Golem.de: Was ist denn falsch an der Art und Weise, wie Konfigurationsdateien heute gehandhabt werden? Du sagtest in deinem Vortrag, dass zur Verbesserung des Desktops die grundlegende Struktur des Betriebssystems weiterentwickelt werden muss, warum?

Alkalay: Im Desktop-Bereich ist viel passiert: DCOP, XML-RPC, Komponenten, Widgets, bunte Themes, Schriften usw., aber die Organisation des Betriebssystems hat sich nicht verändert. Es ist aber nicht möglich, ein wirklich voll integriertes System anzubieten, ohne auch das zu Grunde liegende Betriebssystem zu überarbeiten.

KDE und Gnome kümmern sich nicht wirklich darum, was mit eingesteckten Webcams oder neuen Grafikkarten passiert. Die Art und Weise, wie das heute gelöst ist, setzt menschliches Denken voraus und macht es notwendig, Text-Dateien wie modules.conf oder XF86Config zu editieren. Eine Software ist ohne eine gehörige Portion künstlicher Intelligenz nicht in der Lage, eine solche Konfigurationsdatei effektiv zu bearbeiten. Es ist von der Programmierung her gesehen sehr schwierig, für den Menschen lesbare Konfigurationsdateien auszuwerten und zu verändern.

Jedes Software-Projekt - ganz gleich ob KDE, Gnome, Apache oder Samba - muss einen eigenen Weg finden, um ein Format für Konfigurationsdateien zu definieren. Damit werden diese komplett voneinander getrennt und sind nicht ohne weiteres in einer Software zu integrieren. Konfiguration ist die Seele der Software.

Die Systemorganisation von UNIX wurde vor 30 Jahren designt. Sie hat viele Stärken, wie beispielsweise die Dateisystem-Hierarchie, für Konfigurationsdateien gibt es aber keine Festlegungen. Mit geht es dabei um ein einheitliches Format.

Auch bieten Hardware-Hersteller oft keine Linux-Unterstützung an, da sie sich nicht mit komplexen Installationen für die verschiedenen Distributionen auseinander setzen wollen.

Golem.de: Interessieren sich denn auch Entwickler anderer Projekte für das Konzept zur Speicherung von Konfigurationsdaten, das hinter Linux Registry steckt?

Alkalay: Es gibt Interesse von vielen Seiten. Einige Leute schreiben Patches, andere GUI-Werkzeuge oder Sprach-Bindings. Waldo Bastian will untersuchen, wie sich das KDE-Konfigurations-Framework KConfigXT mit einem Linux-Registry-Backend verhält.

Golem.de: Wie soll sich die Registry in existierende Frameworks wie KConfigXT oder Gconf integrieren?

Alkalay: Diese Frameworks arbeiten auf einer höheren Ebene und sind für eine eher spezielle Nutzung ausgelegt: Desktop-Software. Die Linux Registry stellt einen so allgemein wie möglich gehaltenen Ansatz zur Low-Level-Konfiguration des Systems dar, so dass sie als Backend für diese Frameworks genutzt werden kann. So wäre es auch möglich, Gnome-Programme mit einem KDE-Werkzeug zu konfigurieren und umgekehrt. Zudem könnten die KDE- und Gnome-Werkzeuge direkt auf die Basis-Konfiguration des Systems zugreifen.

Die KDE- und Gnome-Applikationen würden dabei weiterhin KConfigXT- und Gconf-APIs nutzen, als Infrastruktur würde aber die Registry dienen.

Golem.de: Was sind nach deiner Ansicht die Vorteile für Linux und speziell KDE von einem solchen System? Welche Rolle spielt das Ganze für den Nutzer?

Alkalay: Das Design der Linux Registry wurde so angelegt, dass sie die Konfiguration aller Komponenten im System speichern kann, nicht nur die Konfiguration der Desktops. Wenn wir es schaffen, dass die Linux Registry auf breiter Front zum Einsatz kommt, werden wir mehr und mehr Programme sehen, die sich in andere Programme einbinden. Der Nutzer muss keine Konfigurationsdateien anpassen, die Software wird das alleine können. Dadurch wird das Leben auch für Hard- und Software-Anbieter einfacher, die mit ihren Produkten Linux unterstützen wollen. Ein neues Programm lässt sich auf diesem Weg leicht in das System einfügen.

Golem.de: Wie steht es um XML? Ist XML nicht geradezu wie gemacht für solche Aufgaben?

Alkalay: XML ist ein wundervoller Standard, um jede Art von Informationen zu repräsentieren, portabel zu machen und für Menschen wie Maschinen lesbar zu machen. Aber XML erhöht die Komplexität erheblich. Linux Registry soll überall und jederzeit auf jedem System verfügbar sein. Daher müssen alle notwendigen Bibliotheken in jedem Fall und zu jeder Zeit vorhanden sein.

Würde Registry XML als Speicherformat einsetzen, wäre die libXML erforderlich, doch in frühen Boot-Phasen ist das mitunter nicht der Fall und Registry-Schlüssel sollen auch für /sbin/init genutzt werden können, nicht das rund 30 Jahre alte /etc/inittab.

Dennoch nutzt Registry XML als universelles Format, um Schlüssel in die Registry zu schreiben oder aus ihr zu exportieren. Dadurch wird es einfach, eine Software-Konfiguration von einer Maschine auf eine andere zu übertragen.



Golem.de: Führt dieses Konzept von Bäumen aus Schlüsseln nicht dazu, dass die Registry für Menschen unlesbar wird? Anders gesagt: Ist ein Administrator immer noch in der Lage, Dateien direkt zu editieren?

Alkalay: Ja, kann er. Das wurde lange diskutiert und ist eine der Schwachstellen der Windows-Implementierung. Die Registry speichert ihre Informationen in einfachen Text-Dateien, die mit vi oder ed direkt bearbeitet werden können.

Aber aus zeitlichen Gründen wird ein Administrator die Keys nicht direkt editieren müssen. Eine Registry-Infrastruktur macht es sehr einfach, GUIs zur semantischen Konfiguration zu entwickeln. Setzt sich die Registry also mit der Zeit durch, werden Administratoren zunehmend mit semantischen Konfigurationswerkzeugen arbeiten, aber sie werden weiterhin in der Lage sein, die Schlüssel direkt zu editieren, wenn dies notwendig ist.

Golem.de: Glaubst du nicht, dass der Name "Linux Registry" problematisch sein kann? Viele Administratoren haben schlechte Erfahrungen mit der "Windows Registry" gemacht.

Alkalay: Meiner Meinung nach ist die Windows Registry eine gute Idee, die hinter einer schlechten Implementierung versteckt ist - eine Datei, sie alle zu speichern. Geht diese Datei verloren oder wird sie beschädigt, verliert man das gesamte System.

Im Gegensatz dazu wurde die Linux Registry nicht als Daemon, als "Single Point of Failure", angelegt. Sie speichert nicht die gesamte Konfiguration in einer Datei, wurde im Hinblick auf Sicherheit designt und legt die Konfiguration der User in deren eigenen Heimatverzeichnissen, die des Systems in /etc, ab.

Trotzdem bekomme ich viele E-Mails von Leuten, die das Design mögen, aber den Namen als Hinderungsgrund für die Adaption des Systems ansehen. Der Name soll den Leuten direkt klar machen, worum es geht, manchmal hat es aber die gegenteilige Wirkung. Daher wird sich der Name des Projekts demnächst ändern.

[Das Projekt wurde mittlerweile in Elektra umbenannt, Anm. d. Red.]

Golem.de: Wohin wird die Zukunft die Linux Registry führen?

Alkalay: Hoffentlich wird sie von einigen großen Projekten wie KDE, Apache oder Samba sowie in Distributionen genutzt. Zudem sollten mehr Speicher-Backends und Sprach-Bindings auftauchen. Das Projekt benötigt mehr Programme, die es nutzen, eine höhere Bekanntheit und breitere Adaption. Die Vorteile eines voll integrierten Systems werden erst dann zum Tragen kommen, wenn es von vielen Programmen genutzt wird.

Das Projekt ist frei, wurde für Unix designt und von einem alten Unix-Nutzer für alte Unix-Nutzer entwickelt.

[Das Interview führte Fabrice Mous]  (ji)


Links zum Artikel:
Elektra (.net): http://elektra.sourceforge.net/
Linux Registry (.net): http://registry.sourceforge.net/

© 1997–2019 Golem.de, https://www.golem.de/