Zum Hauptinhalt Zur Navigation

Ziele für die Linux Standard Base 3.2 festgelegt

Treffen der LSB-Arbeitsgruppe in Boston. Auf dem LSB Summit 2006 in Boston haben die an der Entwicklung der Linux Standard Base (LSB) Beteiligten über die nächsten Versionen des Standards diskutiert. Dabei legten sie auch die Ziele für die kommende LSB 3.2 fest und stellten klar, dass die LSB kein Platz sei, um bestimmte Techniken zu fordern, um diese zum Standard zu machen. Stattdessen soll sich die LSB nach der Entwicklung richten, auftauchende Techniken betrachten und dann eventuell in die LSB integrieren.
/ Julius Stiebert
3 Kommentare News folgen (öffnet im neuen Fenster)

Die Linux Standard Base wird im Rahmen einer Arbeitsgruppe der Free Standards Group entwickelt, um die interne Struktur von Linux-Systemen zu standardisieren. So legt sie beispielsweise fest, welche Bibliotheken in welcher Version vorhanden sein müssen und wie die Dateisystem-Hierarchie auszusehen hat. Damit möchte die Free Standards Group unter anderem sicherstellen, dass LSB-konforme Anwendungen auf allen zur LSB kompatiblen Linux-Distributionen laufen.

Der LSB Summit(öffnet im neuen Fenster) , ein Treffen der an der Entwicklung der LSB Beteiligten, fand Anfang Juni 2006 in Boston statt. Mit dabei waren neben Firmen wie Red Hat, Novell, IBM, Intel und Canonical auch Projekte wie KDE und X.org. So war auch der KDE-Entwickler Aaron Seigo dabei und berichtet in einer E-Mail(öffnet im neuen Fenster) an die KDE-Entwickler-Mailingliste über die auf dem Summit besprochenen Themen.

Besonders die Ziele der nächsten LSB-Version 3.2 standen auf dem Summit zur Diskussion und wurden festgelegt. So soll die nächste Version der Linux Standard Base den GCC 4.1 und die Libstdc++ v7 beinhalten. Auch die Glibc 2.4 soll Bestandteil der Spezifikation sein. Darüber hinaus möchte sich die LSB der Internationalisierung, Accessibility, aber auch Multimedia, Drucken und dem Erstellen von Softwarepaketen widmen. Mit der freien Implementierung des Windows-API Wine könnte man sich ebenfalls beschäftigen, dieser Punkt ist laut Seigo jedoch noch mit einem großen Fragezeichen versehen.

Ferner wolle man sich verstärkt mit einheitlichen C++-ABIs beschäftigen. Beim Thema Multimedia waren sich die Beteiligten einig, dass es zu früh sei, um spezielle Frameworks wie GStreamer zu standardisieren, vielmehr müsse man sich erst den unterliegenden Schichten wie Alsa und Libao widmen. Damit soll sichergestellt werden, dass es eine einheitliche Schnittstelle für Multimedia-Frameworks gibt. Eine eigene Multimedia-Gruppe innerhalb der LSB wird sich mit diesem Thema weiter auseinander setzen.

In Zusammenarbeit mit LinuxPrinting.org(öffnet im neuen Fenster) soll auch Drucken unter Linux standardisiert werden. Allerdings wird auch hier erst einmal davon abgesehen, CUPS in den LSB-Standard aufzunehmen. Weitere Gespräche behandelten ein neues Paketformat, um Installationen auf unterschiedlichen Plattformen zu ermöglichen. Dabei handelt es sich jedoch nicht um einen Ersatz für Formate wie DEB und RPM, sondern um einen Weg, um mit dem verwendeten Paketverwaltungssystem zusammenzuarbeiten, ohne sich aber auf eine spezielle Distribution konzentrieren zu müssen.

Einig waren sich die Beteiligten auch beim Thema Accessibility, das als Pflicht angesehen wird. So sollen Spezifikationen, um GNOME und KDE mit der Tastatur bedienen zu können, in die LSB gelangen. Dies hänge aber auch davon ab, ob die LSB die D-Bus-Bibliothek aufnimmt, da KDE diese zukünftig nutzt . Damit einhergehend könnten auch andere Entwicklungen des Freedesktop.org-Projektes künftig Teil der LSB sein, inklusive des Portland-Projekts , das GNOME und KDE näher zusammenbringen möchte. Die meisten dieser Freedesktop.org-Entwicklungen sollen in die LSB gelangen, auch wenn die Art der Integration noch nicht komplett feststeht.

Zudem müsse es für LSB 3.2 bessere Testwerkzeuge geben, wobei mit Linuxtesting.org(öffnet im neuen Fenster) zusammengearbeitet wird, die auch auf dem Summit ihre Lösungen für automatische Tests vorstellten. Die Binärkompatibilität zwischen den LSB-Versionen – besonders von LSB 3 auf 4 – ist ebenfalls ein wichtiges Thema für die Arbeitsgruppe. IBM stellte überdies das "Chiphopper"-Projekt vor, mit dem man Software-Anbietern helfen möchte, Anwendungen für Linux zu schreiben bzw. auf Linux zu portieren. Dabei stellt IBM auch Werkzeuge bereit, um die LSB-Kompatibilität sicherzustellen.

Festgelegt wurde auch nochmals die Rolle der Linux Standard Base. Diese soll unter keinen Umständen neue Techniken fordern, um diese zum Standard zu machen, sondern auftauchenden Techniken bei der Standardisierung helfen. So sei die LSB beispielsweise nicht in der Position, um ein stabiles Application Binary Interface (ABI) im Linux-Kernel für Treiber zu verlangen. Würde ein solches ABI aber von den Entwicklern geschaffen, so sei es an der LSB, um dieses zu unterstützen, Tests durchzuführen und es zum ISO-Standard hinzuzufügen.

Ein Beispiel für dieses Vorgehen sei Trolltechs Bibliothek Qt: Da Qt 4 heute noch nicht in den gängigen Distributionen enthalten ist, wird es von der LSB als separates Modul behandelt. Dadurch wird den Distributoren gezeigt, in welche Richtung sich die LSB bewegt, so dass diese darauf reagieren können.

Aktuell ist die LSB 3.1 erhältlich, die portable Desktop-Anwendungen unterstützt. Die nächste große Version LSB 4.0 soll erst 2008, eventuell sogar erst 2009 erscheinen. Die LSB 3.2 hingegen ist für Anfang 2007 geplant.


Relevante Themen