Der steinige Weg zu Linux-Standards

15.05.2001
Seit den ersten Spezifikationen für Linux-basierte Anwendungen geht es um die Vereinheitlichung von elementaren Grundlagen und Differenzen der Distributionen. Das Projekt Linux Standard Base (LSB) machte angesichts großer Probleme eine tiefe Krise durch.

Vor ziemlich genau einem Jahr verbesserten sich scheinbar schlagartig die Perspektiven für Linux, die Gefahr einer Zersplitterung in inkompatible Distributionen schien gebannt. Am 8. Mai 2000 schlossen sich das Projekt Linux Standard Base (LSB) und die Linux Internationalization Initiative (Li18nux) zusammen. Hinter der neuen Dachorganisation Free Standards Group (FSG) standen mit Caldera, Corel, Debian, Red Hat, Suse und Turbolinux alle wichtigen Distributionen. Unterstützende Mitgründer waren auch große IT-Firmen wie IBM, SAP, SGI und Sun.

Das Ziel der Non-Profit-Organisation ist die Entwicklung einer Spezifikation, auf deren Basis Anwendungen geschrieben werden könnten, die auf allen standardkonformen Linux-Distributionen laufen. Diese Spezifikation hoffte damals Daniel Quinlan, ein bei Transmeta beschäftiger Softwareingenieur, der zum Vorsitzenden der LSB gewählt worden war, in rund einem halben Jahr vorlegen zu können.

Doch die Hoffnungen wurden enttäuscht, es ging viel langsamer voran als vorgesehen. Am 15. August 2000 erschien die erste Spezifikation Li18nux 2000 Globalization zur Vereinheitlichung lokaler Schriften und Sprachen. Und zwei Monate später kam die Version 1.0 der Linux Development Platform Specification (LDPS) heraus.

Die LDPS ist ein Zwischenschritt. Sie ist ausdrücklich nicht mehr als eine vorläufige Verabredung von Spezifikationen zur Reduktion von Portabilitätsproblemen. Nach der Definition der Free Standards Group wird die Spezifikation obsolet, sobald die Normen von Linux Standard Base "komplett, verfeinert und breit angenommen" sind. Die Veröffentlichung der LDPS bedeutete also zugleich, dass der Hauptstandard, die LSB, verschoben wurde, zunächst auf Anfang, dann auf die zweite Jahreshälfte 2001.

Damit standen Softwarehäuser vor einem Problem, das sie aus der Unix-Welt kennen. Sie müssen eine Anwendung jedesmal an feine Unterschiede anpassen, die sich in den Linux-Distributionen verbergen, ein personeller, materieller und zeitliche Aufwand, der mit der Größe einer Applikation wächst.

Bereits im Sommer und Herbst 2000 mehrte sich die Kritik an der schleppenden Entwicklung von Linux-Standards und an den Problemen in den vorgelegten Spezifikationen. Strukturelle und personelle Veränderungen wurden gefordert und führten Anfang dieses Jahres zu Konsequenzen in der LSB-Organisationsstruktur. Dan Quinlan trat seine Funktion als Vorsitzender des LSB-Leitungsgremiums an George Kraft von IBM ab und wurde Zuständiger im neu geschaffenen Organisationsbereich Free Standards Group Liaisons.

Faktisch ist Quinlan nun der Repräsentant der FSG im LSB-Projekt. Als "Verbindungsoffizier" zu den Teilprojekten fungiert Scott McNeil, einst der Suse-Mann in den USA, der jetzt als Open-Source-Evangelist auf der Gehaltsliste von VA Linux steht. McNeil war außerdem Mitbegründer der Firma Zenguin, die ein universelles Tool zur Installation der unterschiedlichen Linux-Distributionen entwickelt hatte - dem Unternehmen war allerdings kein Erfolg beschieden.

Mit der neuen Führungsriege kam frischer Wind in das LSB-Projekt. Anfang März 2001 war gerade erst die Betaversion von LSB 0.54 erschienen, rund einen Monat später war man bereits bei Entwurf 0.75 angekommen. "In den letzten Monaten hat sich einiges getan, und das Projekt hat an Geschwindigkeit gewonnen", lobt Markus Rex, Entwicklungsleiter bei der Nürnberger Suse Linux AG. "Noch sind wir mit den 0-Versionen in der Phase der Entwürfe, aber die sind recht weit gediehen und ziemlich stabil. Einige Distributionen fangen an, auf dieser Basis ihre Systeme anzupassen."

Der erste offizielle Standard soll mit der Version 1.0 offiziell im zweiten Halbjahr 2001 herauskommen. Auf einen genaueren Zeitplan möchte sich das Leitungsgremium nicht festlegen lassen. Den Grund beschreibt Lenz Grimmer, LSB-Ansprechpartner bei Suse: "Es gibt einige Bereiche, in denen noch viel Dokumentation fehlt, zum Beispiel in Sachen Manual Pages für Systemaufrufe einer LSB-konformen Plattform."

Der Knoten scheint gleichwohl gelöst zu sein. Inzwischen fürchtet LSB nicht mehr das alte Gesetz, dass verfahrene IT-Projekte durch mehr Entwickler nur schlechter werden. Vor kurzem wurde die Open-Source-Community mit einer ganzen Serie von Postings zur Bearbeitung von spezifischen Teilaufgaben, zum Beispiel zur Dokumentation fehlender Systemkommandos, aufgerufen.

Doch trotz erheblicher Fortschritte bleiben gravierende Unterschiede zwischen den Distributionen. Und die haben Ursache in ihrer unterschiedlichen Abstammungsgeschichte. Alle setzten auf ein damals noch ziemlich unterentwickeltes Linux auf und versuchten es anwendbarer zu machen. Vorbild war seinerzeit Unix, von dem aber gab es zwei Hauptrichtungen, System V und BSD. Dass sich mit Suse und Red Hat die beiden größten Distributionen auf System V bezogen, macht das Problem nicht geringer. Das Vorbild hatte selbst sehr unterschiedliche Ausprägungen.

Die erste Hauptdifferenz zwischen den Linux-Ausprägungen besteht in der Datei- und Verzeichnisstruktur. Obwohl der aktuelle Filesystem Hierarchy Standard (FHS) 2.1 schon recht gute Vorgaben macht, wie ein Linux-Dateisystem auszusehen hat, gibt es immer noch sehr viele Aspekte, die entweder gar nicht oder nicht ausreichend spezifiziert sind. So trifft er keine verbindlichen Aussagen über die Lage der Init-Skripte oder über die Verzeichnisse, in die CD-ROM- und Floppy-Laufwerke eingeblendet werden ("Mount Points").

Die Init-Skripte sind ein zentrales Element, weil sie den gesamten Startvorgang eines Betriebssystems steuern. Wer versucht, hieran etwas zu ändern, stellt wesentliche Aspekte einer Linux-Distribution zur Disposition. Entsprechend vorsichtig sind also Vorschläge zur Vereinheitlichung der Init-Skripte zu diskutieren. Ein Ausweg könnte darin bestehen, die verschiedenen Init-Skripte durch Übersetzung unter einen Hut zu bekommen. Nur haben Vorschläge in dieser Richtung den Nachteil, dass man dann noch einige weitere Dinge zum Standard erklären müsste. Rattenschwänze solcher Art machen Verhandlungen im Detail so zeitraubend.

Das nächste Problem sind die Paketformate und -namen. Jeder Distributor liefert seine Software in eigenen Formaten aus; zwei davon haben sich bis jetzt erhalten: RPM und DEB. RPM hieß früher "Red Hat Package Manager". DEB ist die Kurzform von Debian und wird nur von einer Minorität der Distributionen - neben Debian zum Beispiel Corel und Storm Linux - genützt. Der Trend geht zu RPM als Standard. Ein eigenes Subkomitee im LSB-Projekt, die "Taskforce-1", soll ein standardisiertes Paketformat entwickeln, hat aber noch nicht viel Verwertbares vorgelegt.

Ein weiterer Punkt, zu dem sich Anwender Vereinheitlichungen wünschen, ist die Installation eines Systems. Die Art und Weise, wie eine Distribution eingerichtet und konfiguriert wird, ist inzwischen deren wichtigstes Differenzierungsmerkmal. Jede verwendet dazu andere Tools. Suse hat zum Beispiel "Yast", was zwar eine quelloffene Software ist, aber nicht kommerziell weiterverwertet werden darf. Red-Hat-Chef Bob Young hält hingegen überhaupt nichts von dem Ansatz, zentrale Bestandteile eines Systems mit Lizenzbedingungen zu beschweren.

Die Installations-Tools dienen in der Regel auch zur späteren Konfiguration und Administration eines Systems. Die Konfigurationsdateien finden sich bei Red Hat unterteilt nach spezifischem Zweck in Unterverzeichnissen von /etc/sysconfig, wie es viele Unix-Derivate machen. Suse lässt in diesem Punkt das Vorbild HP-UX erkennen, die Konfigurationsdaten finden sich in einer zentralen Konfigurationsdatei namens rc.config im Directory /etc. Es handelt sich dabei um eine Metadatei, aus der einige der eigentlichen Konfigurationsdateien dynamisch über Skripte in /etc generiert werden, was bei Änderungen vorteilhaft sein kann.

Solche Unterschiede zwischen den Distributionen und die resultierenden Probleme bei der Standardisierung zeigen an, dass der Open-Source-Charakter von Linux noch nicht per se eine Fragmentierung zwischen den Distributionen verhindert. Ihre gemeinsame Grundlage, die General Public License (GPL), verhindert aber das Schlimmste. Jeder Distributor muss GPL-lizenzierte Komponenten quelloffen wieder verfügbar machen, die Konkurrenz kann sich sofort an seinen technischen Verbesserungen bedienen.

Das müsste eigentlich eins zur Folge haben: "Gute Technologie setzt sich ganz von alleine durch", meint Dieter Hoffmann, Europa-Chef von Red Hat. "Sie wird von anderen Distributionen aufgegriffen." Das stimmt im Prinzip, aber bis es so weit ist, gibt es eine Zeitlang doch Unterschiede, die Anwendern und Softwarehäusern die Arbeit schwer machen. "Es bleiben bisher genug Unterschiede, die den ISVs Alpträume bereiten", meint ein Insider der Linux-Standardisierung. Trotz mancher Spezifikationen müssen ISVs ihre nicht quelloffenen Anwendungen bei einer Änderung an den Zielsystemen eben selbst anpassen, kompilieren, testen und neu ausliefern.

Die professionellen Anwender stehen vor einem ähnlichen Problem. Red-Hat-Ingenieur Joachim Kunze beschreibt es so: "System V ist für unsere Enterprise-Kunden wichtig, weil sie viele Programme haben, die darauf basieren. Es vereinfacht eine Konvertierung dieser Programme nach Linux wesentlich, wenn man sich an solche Standards hält."

Linux hat sich seit jeher an Unix-Standards orientiert, lange aber waren diese nicht offiziell als solche festgehalten. Jetzt finden sich im aktuellen LSB-Entwurf mit der Versionsnummer 0.7.5 mehrere System-V-Spezifikationen, unter anderem zum Application Binary Interface (ABI), die Interface Definition (SVID) 3, die Spezifikationen zum Common Application Environment (CAE) sowie Ausgabe 4 des X/Open Portability Guide. Vorschrift sind auch X11-Protokolle und natürlich die obersten aller Unix-Standards, die Posix-Spezifikationen der IEEE samt ihrer Erweiterung für Threads.

Die aktuelle LSB-Spezifikation definiert in zwölf Kapiteln Einzelaspekte des kommenden Standard-Linux. Es beginnt mit Objektformaten wie ELF sowie den Sprachen C und C++ und beschreibt dynamisches Linking. Sie definiert Basis-, Utility- und Grafik-Libraries. Eigene Absätze gibt es zu Package-Formaten und Installation, zu Kommandos und Utilities, zur Standard-Shell sowie zur Benutzerverwaltung (Users, Groups). Vorschrift ist das weit vorangekommene FHS. Abschließend finden sich Grundlagen zur System-Initialisierung mit ihren Jobs und Skripts sowie ein Appendix über SGML und XML.

Es ist also entgegen der verbreiteten Skepsis einiges in Gang gekommen. Schnell wird übersehen, dass die Unix-Standardisierung auch lange Zeit brauchte und trotzdem genug Raum für proprietäre Eigenarten ließ. Außerdem weist sie Lücken und Inkonsistenzen auf, oder die Standards sind technisch veraltet, so dass es nicht Wunder nimmt, wenn Linux-Entwickler manche Aspekte unterschiedlich implementiert haben.

Meistens vergessen die Kritiker auch, dass die Linux-Standardisierung ein Projekt ist, das Freiwillige starteten. Inzwischen zeigen alle bedeutenden Linux-Distributionen starkes Engagement. Suse-Entwicklungsleiter Rex: "Die Distributoren sind sich der Problematik der Fragmentierung durchaus bewusst. Sie wollen auf jeden Fall verhindern, dass sich die Unix-Geschichte wiederholt."

Vielmehr gibt es jetzt aus den Reihen der LSB selbst kritische Anmerkungen. So beschwert sich ein Aktivist: "Die Softwarefirmen, die am lautesten nach Standards schreien, glänzen durch Abwesenheit in den Gremien. Wenn die Industrie etwas mehr personelle Unterstützung beisteuern würde, käme der Prozess bedeutend schneller voran." Explizit ausgenommen sehen möchte er aus seiner Kritik IBM.

Wie die Standardisierungsaktivisten den Beitrag von IBM bewerten, zeigt sich auch darin, dass mit George Kraft ein IBMer auf eine der strategisch wichtigsten Positionen in der Linux-Welt, den Chefsessel des LSB-Projekts, berufen wurde. Dabei gibt es auch in dieser Initiative die Community-typische Meritokratie. Nur Engagement und Qualität der Arbeit zählen. IBM trifft in der Community nicht mehr auf Ressentiments, sondern gilt als Partner, der Manpower und Infrastruktur bereitstellt, ohne beherrschenden Einfluss auszuüben.

Selbst wenn der Standard 1.0 vorliegt, sollte man die Erwartungen an ihn nicht zu hoch schrauben. Mit der ersten LSB werden nicht alle Probleme behoben sein. Die Verantwortlichen gehen davon aus, dass es nicht nur zu Erweiterungen, sondern auch zu Nachbesserungen in verabschiedeten Punkten kommen wird. LSB 1.0 wird dem Projekt aber mehr öffentliche Aufmerksamkeit geben. Und damit ist die Hoffnung verbunden, dass mehr Softwarefirmen Mitarbeiter für das Projekt abstellen, um es voranzutreiben.

"LSB 1.0 wird ein durchaus brauchbarer Standard sein", meint Suse-LSB-Spezialist Grimmer. "Aber wir wissen, dass es noch viele Baustellen gibt, die wir bis zu dieser Version nicht mehr abschließen können." Diverse Dinge habe man bewusst zurückgestellt, weil sie einfach viel mehr Zeit brauchen. "Wichtig ist, jetzt einen kleinen gemeinsamen Nenner zu haben, auf dem man aufbauen kann", ergänzt sein Kollege Rex. "Wir müssen die ISVs motivieren, und wir wollen erfahren, ob sie mit dem Standard etwas anfangen können, was ihnen noch fehlt und was in erster Linie angegangen werden muss."