Linux Standard Base (LSB) ist ein gemeinsames Projekt durch mehreren Vertrieb von Linux unter der organisatorischen Struktur des Linux Fundaments, um den Softwaresystemaufbau einschließlich der filesystem Hierarchie zu standardisieren, die mit Linux Betriebssystem verwendet ist. Der LSB basiert auf der POSIX Spezifizierung, der Einzelnen UNIX Spezifizierung und mehreren anderen offenen Standards, aber erweitert sie in bestimmten Gebieten.

Gemäß dem LSB:

Die:The-Absicht des LSB ist, eine Reihe offener Standards zu entwickeln und zu fördern, die Vereinbarkeit unter dem Vertrieb von Linux vergrößern und Softwareanwendungen ermöglichen werden, auf jedem entgegenkommenden System sogar in der binären Form zu laufen. Außerdem wird der LSB helfen, Anstrengungen zu koordinieren, Softwareverkäufer zu rekrutieren, um Produkte für Linux Betriebssystem zu tragen und zu schreiben.

Der LSB Gehorsam kann für ein Produkt durch ein Zertifikat-Verfahren bescheinigt werden.

Der LSB gibt zum Beispiel an: Standardbibliotheken, mehrere Befehle und Dienstprogramme, die den POSIX Standard, das Lay-Out der Dateisystemhierarchie, geführten Niveaus, des Drucksystems, einschließlich Druckpuffer wie TASSEN und Werkzeuge wie Foomatic und mehrere Erweiterungen auf das X Fenstersystem erweitern.

Versionsgeschichte

• 1.0: Anfängliche Ausgabe 2001-06-29.
• 1.1: Veröffentlicht am 2002-01-22. Zusätzliche Hardware spezifische Spezifizierungen (IA32).
• 1.2: Veröffentlicht am 2002-06-28. Zusätzliche Hardware spezifische Spezifizierungen (PowerPC 32 Bit). Zertifikat hat Juli 2002 begonnen.
• 1.2.1: Veröffentlichter Oktober 2002. Zusätzlicher Itanium.
• 1.3: Veröffentlicht am 2002-12-17. Zusätzliche Hardware spezifische Spezifizierungen (Itanium, Unternehmenssystemarchitektur/390, z/Architecture).
• 2.0: Veröffentlicht am 2004-08-31.
• LSB ist modularized zu:
• LSB-Kern
• LSB-CXX
• LSB-Grafik
• LSB-I18n (nicht veröffentlicht)
• Neue Hardware spezifische Spezifizierungen (PowerPC 64 Bit, AMD64).
• Synchronisiert zur Version 3 von Single UNIX Specification (SUS).
• 2.0.1: Veröffentlicht am 2004-10-21, ISO Version von LSB 2.0, der Spezifizierung für alle Hardware-Architekturen eingeschlossen hat (außer der LSB-Grafik, deren nur eine allgemeine Version verfügbar ist).
• 2.1: Veröffentlicht am 2005-03-11.
• 3.0: Veröffentlicht am 2005-07-01. Unter anderen Bibliotheksänderungen:
• C ++ wird ABI zu demjenigen geändert, der durch gcc 3.4 verwendet ist
• Die Kernspezifizierung wird zu ISO POSIX (2003) aktualisiert
• Technische Berichtigung 1: 2005
• 3.1: Veröffentlicht am 2005-10-31. Diese Version ist als ISO/IEC 23360 vorgelegt worden.
• 3.2: Veröffentlicht am 2008-01-28. Diese Version ist als ISO/IEC 23360 vorgelegt worden.
• 4.0: Veröffentlicht am 2008-11-11. Diese Version enthält die folgenden Eigenschaften:
• glibc 2.4
• Binäre Vereinbarkeit mit LSB 3.x
• Leichter, SDK zu verwenden
• Unterstützung für neuere Versionen von GTK und Kairo grafische Bibliotheken
• Java (fakultatives Modul)
• Einfachere Weisen, LSB-entgegenkommende RPM Pakete zu schaffen
• Geheim-API (über die Bibliothek von Network Security Services) (fakultatives Modul)
• 4.1: Veröffentlicht am 2011-02-16:
• Java hat entfernt

Umgekehrt Vereinbarkeit

Der LSB wird entworfen, um binär-vereinbar zu sein und eine stabile Anwendung binäre Schnittstelle (ABI) für unabhängige Softwareverkäufer zu erzeugen. Um rückwärts gerichtete Vereinbarkeit zu erreichen, ist jede nachfolgende Version rein zusätzlich. Mit anderen Worten werden Schnittstellen nur hinzugefügt, nicht entfernt. Der LSB hat eine Schnittstelle-Missbilligungspolitik angenommen, Anwendungsentwicklern genug Zeit zu geben, im Falle dass eine Schnittstelle vom LSB entfernt wird. Das erlaubt dem Entwickler, sich auf jede Schnittstelle im LSB seit einer bekannten Zeit zu verlassen und auch für Änderungen zu planen, ohne, überrascht zu sein. Schnittstellen werden nur entfernt, "missbilligt" für mindestens drei Hauptversionen, oder ungefähr sechs Jahre gekennzeichnet.

ISO Standard

Der LSB wird als ein offizieller ISO Standard eingeschrieben. Die Hauptrollen davon sind:

• ISO/IEC 23360-1:2006 Kernspezifizierung 3.1 von Linux Standard Base (LSB) - Teil 1: Allgemeine Spezifizierung
• ISO/IEC 23360-2:2006 Kernspezifizierung 3.1 von Linux Standard Base (LSB) - Teil 2: Spezifizierung für die IA32 Architektur
• ISO/IEC 23360-3:2006 Kernspezifizierung 3.1 von Linux Standard Base (LSB) - Teil 3: Spezifizierung für die IA64 Architektur
• ISO/IEC 23360-4:2006 Kernspezifizierung 3.1 von Linux Standard Base (LSB) - Teil 4: Spezifizierung für die AMD64 Architektur
• ISO/IEC 23360-5:2006 Kernspezifizierung 3.1 von Linux Standard Base (LSB) - Teil 5: Spezifizierung für die PPC32 Architektur
• ISO/IEC 23360-6:2006 Kernspezifizierung 3.1 von Linux Standard Base (LSB) - Teil 6: Spezifizierung für die PPC64 Architektur
• ISO/IEC 23360-7:2006 Kernspezifizierung 3.1 von Linux Standard Base (LSB) - Teil 7: Spezifizierung für die S390 Architektur
• ISO/IEC 23360-8:2006 Kernspezifizierung 3.1 von Linux Standard Base (LSB) - Teil 8: Spezifizierung für die S390X Architektur

Es gibt auch ISO/IEC TR 24715:2006, der Gebiete des Konflikts zwischen ISO/IEC 23360 (die Linux Standardbasis 3.1 Spezifizierung) und dem ISO/IEC 9945:2003 (POSIX) Internationaler Standard identifiziert.

ISO/IEC 23360 und ISO/IEC TR 24715 können von der ISO Website frei heruntergeladen werden.

Kritik

Der LSB ist dafür kritisiert worden, Eingang aus Projekten, am meisten namentlich dem Projekt von Debian außerhalb des Bereichs seiner Mitglied-Gesellschaften nicht zu nehmen.

Wahl des RPM Paket-Formats

Der LSB gibt an, dass Softwarepakete entweder als ein LSB-entgegenkommender Monteur geliefert werden, oder (vorzugsweise) in einer eingeschränkten Form des RPM Paket-Betriebsleiters Format geliefert werden sollten.

Diese Wahl des Paket-Formats schließt den Gebrauch des deb Paket-Formats von Debian aus, das rpm zurückdatiert. Das Ändern des zu Grunde liegenden Paket-Formats des Vertriebs von Debian, um den LSB zu befriedigen, wird ziemlich unrealistisch betrachtet. Der Gebrauch des Deb-Formats hat sich seit der Einführung von LSB nicht vermindert; im Gegenteil hat es besonders mit dem Advent von Ubuntu zugenommen.

Um das zu richten, diktiert der Standard das nicht, welches Paket-Format das Softwaresystem für seine eigenen Pakete bloß verwenden muss, dass RPM unterstützt werden muss, um Paketen von Drittverteilern zu erlauben, auf einem sich anpassenden System installiert zu werden.

Beschränkungen auf Debian

Debian hat fakultative Unterstützung für den LSB bald, an der Version 1.1 im "waldigen" und 2.0 in "sarge" eingeschlossen, und spätere 3.1 darin "ätzen" und 3.2 in "lenny". Um RPM LSB-entgegenkommende Auslandspakete zu verwenden, muss der Endbenutzer das Ausländische Programm von Debian verwenden, um sie ins heimische Paket umzugestalten, formatieren und installieren sie dann.

Das LSB-angegebene RPM-Format hat eine eingeschränkte Teilmenge von RPM-Eigenschaften — um Gebrauch von RPM-Eigenschaften zu blockieren, die zu.deb mit dem Ausländer oder den anderen Paket-Umwandlungsprogrammen, und umgekehrt unübersetzbar sein würden, weil jedes Format Fähigkeiten der andere hat, fehlt. In der Praxis nicht ganzer Linux sind binäre Pakete so notwendigerweise LSB-entgegenkommend, während die meisten zwischen.rpm und.deb umgewandelt werden können, wird diese Operation auf eine Teilmenge von Paketen eingeschränkt.

Durch das Verwenden des Ausländers ist Debian für alle Absichten und Zwecke LSB-vereinbar, aber gemäß der Beschreibung ihres Pakets deutet die Anwesenheit des Pakets "nicht an, dass wir glauben, dass Debian völlig die Linux Standardbasis erfüllt, und als eine Behauptung nicht analysiert werden sollte, dass Debian LSB-entgegenkommend ist."

Im Allgemeinen müht sich Debian wirklich, den LSB zu erfüllen, aber es kann andere Beschränkungen geben.

Die Qualität des Gehorsams prüft Gefolge

Zusätzlich sind die Gehorsam-Testgefolge dafür kritisiert worden, verwanzt und unvollständig — am meisten namentlich zu sein, 2005 hat Ulrich Drepper den LSB für schlecht geschriebene Tests kritisiert, die Inkompatibilität zwischen dem LSB-beglaubigten Vertrieb verursachen können, wenn ein Werkzeug falsches Verhalten, verwanzte Testarbeit zu machen, während sich andere bewerben und Verzichtserklärungen davon erhalten, die Tests zu erfüllen. Er hat auch einen Mangel an der Anwendungsprüfung verurteilt, darauf hinweisend, dass Prüfung nur Vertrieb das Problem von Anwendungen nie beheben kann, die sich auf das Durchführungsdefinierte Verhalten verlassen. Jedoch ist der LSB-Testeinschluss bedeutsam in den letzten Jahren verbessert worden. Außerdem hat das Linux Fundament ein Werkzeug veröffentlicht, um Anwendungsvereinbarkeitsprüfung zu richten.

Links

• freestandards.org Archive der Spezifizierung (Gebrochen, adressiert zu http://www.linux-foundation.org um)
• Linux Standard Base (LSB)
• Das OLVER Testgefolge für LSB - öffnet Sich Linux Überprüfung planen
• Linux Fundament Linux Developer Network (LDN) - um Entwicklern zu helfen, die tragbare Anwendungen von Linux bauen.

Medien

• Vier Linux Verkäufer einigen sich über eine LSB Durchführung (slashdot)
• Am 26. August 1998 Presseinformation, die Depression von Mannschaften (zurzeit) beschreibt, und wer, vom historischen Interesse beteiligt wurde
• Ja, der LSB hat Wert - Antwort auf Drepper (2005) durch Jeff Licquia