Die Gründungsmitglieder von United Linux sind auch Mitglieder der Free Standards Group, die aus LSB und Li18nux hervorgegangen ist. Ihr Ziel: Die Struktur der Linuxe einheitlich und für andere verdaulicher gestalten. Schon die Betaversion von United Linux läuft erstaunlich gut durch die zugehörige Testsuite.

Glaubt man seinen Mitgliedern, ist ein Hauptanliegen von United Linux, den Wildwuchs der Linux-Distributionen zu vereinheitlichen. United Linux basiert in weiten Teilen auf SuSE Linux, ein Vermächtnis, das in vielen Bereichen sichtbar ist (siehe Test ab Seite 30).

Die eigentliche Neuigkeit bei United Linux ist nicht die Technik der Distribution, sondern die Zusammenarbeit der teilnehmenden Distributoren SuSE, SCO/Caldera, Conectiva und Turbo Linux. Die Nähe zu SuSE Linux führt aber auch dazu, dass die von SuSE 8.0 und 8.1 eingehaltenen Standards fast unverändert für United Linux gültig sind. Aufgabe dieses Artikels ist es, auf diese Standards sowie die Parallelen, aber auch die Widersprüche mit United Linux näher einzugehen.

Es ist anzunehmen, dass die Gründung des Bündnisses United Linux für Scott McNeill (Abbildung 1), Executive Director der Free Standards Group (FSG)[1], eine große Bestätigung war. Schließlich ist es die Aufgabe seiner Organisation, dem Distributionswildwuchs babylonischen Ausmaßes durch Standards und die zugehörigen Testwerkzeuge eine gewisse Ordnung aufzuprägen.

Der Triumph des Schäfers

Im ersten öffentlichen LSB-Proposal vom 18. Mai 1998, einzusehen unter[3], findet sich der Satz (sinngemäß übersetzt): “Linux-Distributionen sollten das Basissystem nicht getrennt, sondern gemeinsam pflegen, wie dies schon beim Kernel passiert.” Das genau ist die Idee hinter United Linux. Und was könnte für einen Schäfer (Scott McNeill) schöner sein, als dass seine Schafe (die Distributoren) freiwillig in den Stall trotten?

Die United-Linux-Initiative wäre sicherlich nicht ohne einen starken Druck des Markts entstanden. Es scheint insbesondere für SCO/Caldera (die wohl ihr Kerngeschäft von Linux weg verlagern) und Turbo Linux günstiger zu sein, die eigenen, kostenträchtigen Entwicklungsaktivitäten einzuschränken oder gar ganz einzustellen.

Conectiva wiederum taucht in der Liste der zertifizierten Linux-Distributionen auf der LSB-Webseite nicht auf. Es ist für die Brasilianer durchaus sinnvoll, eine LSB-Zertifizierung auf dem Umweg über United Linux anzustreben. Auch öffnen sie so für ihre Businessprodukte Märkte außerhalb Südamerikas, die für Conectiva ohne die Mitarbeit bei United Linux nicht erreichbar wären.

Für SuSE wiederum, die den Kern von United Linux nahezu allein entwickelt, dürfte die Initiative aufgrund der Beteiligung der Partner eine günstigere Verteilung der Entwicklungskosten bedeuten. Dank der Dominanz von Red Hats Hauptkonkurrenten SuSE innerhalb von United Linux ist trotz Einladung wohl kaum mit einem baldigen Beitritt der Rothüte zu rechnen. Ähnliches gilt für Mandrake, die deutlich näher an Red Hat liegt als die anderen großen Linux-Distributionen. Auch würde Mandrake mit einem Beitritt zur United-Linux-Initiative eines seiner wichtigsten Verkaufsargumente preisgeben: den Installer.

Abbildung 1: Scott McNeill, der ehemalige Chef von SuSEs USA-Filiale in Oakland und heutige Executive Director der Free Standards Group. (Quelle: Rüdiger Berlich)

Die Free Standards Group

Entstanden ist die FSG erst im Mai 2000 als Zusammenschluss der Gruppe Linux Standard Base (LSB,[4]) und der Linux Internationalization Initiative Li18nux, heute OpenI18N genannt[5]. Die Linux Standard Base definiert im Wesentlichen ein Basisystems, zu dem alle Linux-Distributionen kompatibel sein sollten. Applikationen und Pakete müssen folglich nur noch für dieses eine Basissystem entwickelt werden, sie laufen dann automatisch auf allen LSB-standardisierten Distributionen.

Neuerdings ist auch LANANA (The Linux Assigned Names And Numbers Authority,[6]) Teil der FSG, seine Aufgabe ist die Verwaltung des Linux-Namensraums. Es geht also zum Beispiel um die Vermeidung von Namenskonflikten bei Applikationen und Treibern. Die Open-Printing-Initiative der FSG befasst sich mit der Etablierung von Standards für eine skalierbare Druckumgebung im Linux-Umfeld.

Integriert in LSB ist der schon länger existierende Filesystem Hirarchy Standard (FHS), der seinerseits auf eine noch ältere Initiative zurückgeht. Die Free Standards Group kann man also als natürliche Evolution und Sammelbecken der Standardisierungsbestrebungen im Linux-Land verstehen.

Von Anfang an hatte die Free Standards Group die Unterstützung einer breiten Palette an Industrieunternehmen. Sogar SAP war am Anfang mit dabei, findet sich jetzt zwar nicht mehr in der Liste der FSG-Mitglieder, wird jedoch im United-Linux-Pressrelease interessanterweise wieder erwähnt.

Zu den heutigen Mitgliedern der FSG zählen die üblichen Verdächtigen: IBM, HP und Intel, aber auch Sun und Dell. Und selbstverständlich sind auch die großen Linux-Distributoren Red Hat und Mandrake und auch alle Gründungsmitglieder von United Linux mit von der Partie.[2]

Das geballte Interesse deutet auf die Wichtigkeit der Arbeit der FSG hin. Es scheint also Einigkeit über das Ob der Standardisierung zu herrschen. Nur beim Wie werden dank der Unwägbarkeiten kommerzieller Vermarktung des Linux-Betriebssystems gelegentlich neue Fragen aufgeworfen.

Um Scott und der FSG Gerechtigkeit widerfahren zu lassen: Die Liste der Distributionen, die die LSB-Zertifizierung erhalten haben (einsehbar unter[8]) schließt neben Mandrake 9.0 auch SuSE 8.1 und Red Hat 8.0 ein. Bei allen dreien geht die Zertifizierung bereits in die zweite Generation. LSB ist also durchaus erfolgreich.

Die Kommerzielle Ausrichtung ist nicht unbedenklich

Anders als man denken könnte, wirft United Linux bei der Free Standards Group auch einige Fragen auf. Der starke kommerzielle Hintergrund von United Linux wird nicht dazu beitragen, die Kluft zwischen Red Hat und SuSE zu überbrücken. Eine Basisdistribution ohne kommerziellen Hintergrund wäre wohl aus Sicht der FSG die wünschenswerte Alternative gewesen.

Dass im Wettbewerb mit harten Bandagen gekämpft wird, bringt gern auch mal einen anmaßenden Unterton ins Spiel. So findet sich im englischen “United Linux”-Pressetext vom 30.5.2002[7] sinngemäß übersetzt der Satz: “Die führenden Linux-Unternehmen Caldera International, Inc., Conectiva S.A., SuSE Linux AG und Turbolinux, Inc., gaben heute die Gründung von United Linux bekannt, einer neuen Initiative, die die Linux-Entwicklung und -Zertifizierung um eine globale, einheitliche, für das Business entwickelte Linux-Distribution herum gruppiert und rationalisiert.”

Fairerweise muss man sagen, dass dieses gemeinsame Statement der UL-Mitglieder im deutschen Pressetext von SuSE deutlich abgeschwächt ist: “[…] Demnach vereinbaren die vier Unternehmen die gemeinsame Entwicklung eines Linux-Betriebssystems, das speziell auf den Server-Einsatz in Unternehmen zugeschnitten ist.”

Der Testsuite sei Dank

Der Erfolg von LSB bezieht sich eher auf die frei verfügbaren Testsuiten (siehe Kasten “Die LSB-Testsuite”) als auf die Verwendung einer gemeinsamen Basisdistribution für alle kommerziellen und freien Distributionen. Die Testsuiten gewährleisten aber gleichwohl, dass LSB-konforme Applikationen automatisch auch auf allen LSB-zertifizierten Systemen laufen.

Einer der Nachteile des Ansatzes, eine gemeinsame Basisdistribution zu verwenden, machte sich im Test bemerkbar: United Linux Beta 3 (und übrigens auch SuSE Linux 8.1) erkannte den Tekram-DC-390U2W-SCSI-Controller des Testrechners nicht mehr selbstständig, das entsprechende Modul musste in »linuxrc« manuell geladen werden. Dieses Problem war bei SuSE 8.0 noch nicht zu beobachten.

Fehler dieser Art vererben sich notwendigerweise auf alle Distributionen, die United Linux als Basis verwenden. Mittelfristig wird die Produktqualität aber eher profitieren, dank der größeren Anwenderbasis und der Erfahrung der anderen Distributoren bei der Pflege der Installers-Hardwaredatenbank.

United Linux ist auf dem richtigen Weg

Dennoch: Insgesamt ist United Linux auf dem richtigen Weg. Er führt zwar nicht immer geradeaus, weil die Verbreitung von Linux untrennbar mit dem Erfolg oder Misserfolg kommerzieller Linux-Distributionen verbunden ist. Aber es ist beachtlich, was die United-Linux-Mitglieder bei der Standardisierung schon erreicht haben. (jk)

Die LSB-Testsuite

Wer die LSB-Zertifizierung seiner Distribution nachvollziehen möchte, benötigt die von [1] erhältlichen Binary-RPMs der LSB-Suite. Ferner sollten etwaige LSB-Pakete der Distribution installiert sein. Im Falle von United Linux ist dies das Paket »lsb«, das man in Yast 2 einfach mit der exzellenten Suchfunktion findet. Nach der Installation aller Pakete loggt man sich als Benutzer »vsx0« ein (laut [1] ohne Passwort, im Test musste es allerdings durch Root neu gesetzt werden) und startet das Skript »./run_tests«. Beim ersten Aufruf des Skripts sieht sich der Tester einigen einfachen Fragen gegenüber. Die Testsuite besteht aus vielen kleinen Einzeltests, die die Konformität mit dem Standard praktisch überprüfen. Das Ganze dauert selbst auf einem schnellen Rechner noch zirka sechs Stunden. Zum Schluss wird dann ein rund 320 Seiten langer Bericht erstellt, der das Ergebnis aller Tests detailliert beschreibt. Intern handelt es sich bei diesen Tests meist um Shellskripte. So überprüft etwa das Skript »etc-tc.sh« die Konformität des »/etc«-Verzeichnisses. Jeder der 38 Tests in diesem Skript kann einen Fehler generieren. Ist – wie anfänglich auf unserem Testsystem der Fall – beispielsweise die Datei »/etc/printcap« nicht vorhanden oder fehlt das Verzeichnis »/etc/sgml«, ist dies hinterher im Testbericht nachlesbar. Beispiel: Das Testskript 01 tp38() 02 { 03 tpstart "Reference 3.7-38(C)" 04 tet_infoline "If the system supports the subsystem" 05 tet_infoline "the /etc/sgml directory exists and is searchable" 06 07 lsb_test_dir_searchable /etc/sgml >out.stdout 2>out.stderr 08 check_exit_value $? 0 # should be zero 09 check_nostdout # should be no stdout 10 check_nostderr # should be no stderr 11 if [ $FAIL = Y ] 12 then 13 FAIL=N 14 tet_infoline "This test result needs to be manually resolved, returning FIP result" 15 tpresult FIP 16 return 17 fi 18 tpresult # set result code 19 } erzeugt im Testbericht diese Zeilen: Test Information: Reference 3.7-38(C) If the system supports the subsystem the /etc/sgml directory exists and is searchable /etc/sgml: directory not found exit code 1 returned, expected 0 This test result needs to be manually resolved, returning FIP result Der vom Linux-Magazin durchgeführte Test von United Linux Beta 3 erzeugte nur einen Fehler und einige harmlose Warnungen, was auch auf das etwas lieblos installierte System zurückzuführen sein mag. In jedem Abschlussbericht steht noch die Kategorie »Unresolved«. Das sind Tests, die aus irgendeinem Grund kein eindeutiges Ergebnis liefertern. Obgleich es zeitaufwändig ist, sollten Tester auch diesen Meldungen nachgehen, wenn sie Wert auf ein standardkonformes System legen. Für die meisten Benutzer spielen die Tests keine Rolle. Es ist Aufgabe der Distributoren, für die Konformität zu sorgen, nicht die der Käufer! Wichtiger ist die Möglichkeit, auch eigene Programme auf Konformität mit dem LSB-Standard zu prüfen. Zuständig dafür ist das Tool »lsbappchk«. Es gibt unter anderem Auskunft über nicht standardkonforme dynamische Bibliotheken und Funktionen. Abbildung 2: United Linux während des Tests auf LSB-Konformität.