Hubbry Logo
Linux Standard BaseLinux Standard BaseMain
Open search
Linux Standard Base
Community hub
Linux Standard Base
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Linux Standard Base
Linux Standard Base
Linux Standard Base
View on Wikipedia
from Wikipedia

Linux Standard Base
The LSB logo
AbbreviationLSB
StatusPublished
First publishedJune 29, 2001 (2001-06-29)
Latest version5.0
June 2, 2015
CommitteeISO/IEC JTC 1/SC 22
SeriesISO/IEC 23360
Base standardsPOSIX, SUS
DomainSoftware compatibility

The Linux Standard Base (LSB) was a joint project by several Linux distributions[which?] under the organizational structure of the Linux Foundation to standardize the software system structure, including the Filesystem Hierarchy Standard. LSB was based on the POSIX specification, the Single UNIX Specification (SUS), and several other open standards, but extended them in certain areas.

According to LSB:

The goal of the LSB is to develop and promote a set of open standards that will increase compatibility among Linux distributions and enable software applications to run on any compliant system even in binary form. In addition, the LSB will help coordinate efforts to recruit software vendors to port and write products for Linux Operating Systems.

LSB compliance might be certified for a product by a certification procedure.[1]

LSB specified standard libraries (centered around the ld-lsb.so), a number of commands and utilities that extend the POSIX standard, the layout of the file system hierarchy, run levels, the printing system, including spoolers such as CUPS and tools like Foomatic, and several extensions to the X Window System. It also specified boot facilities, such as $local_fs, $network, which were used to indicate service dependencies in System V-style initialization scripts.[2] A machine readable comment block at the top of a script provided the information necessary to determine at which point of the initialization process the script should be invoked; it was called the LSB header.[3]

The command lsb_release -a was available in many systems to get the LSB version details, or could be made available by installing an appropriate package, for example the redhat-lsb package in Red-Hat-flavored distributions such as Fedora,[4] or the lsb-release package in Debian-based distributions.

The standard stopped being updated in 2015 and current Linux distributions do not adhere to or offer it; however, the lsb_release command is sometimes still available.[citation needed] On February 7, 2023, a former maintainer of the LSB wrote, "The LSB project is essentially abandoned."[5]

An example of LSB output in a terminal (Debian version 11)

Backward compatibility

[edit]
LSB aims to make userspace binaries portable

LSB was designed to be binary-compatible and produced a stable application binary interface (ABI) for independent software vendors.

To provide backward compatibility, the LSB adopted an interface deprecation policy to give application developers enough time to adapt in case an interface was removed from LSB. An interface that is to be removed would first be marked as deprecated in an LSB release; that interface would still be supported in that release and at least two subsequent LSB releases. This allowed the developer to rely on every interface in LSB for a known time and also to plan for changes.[6]

LSB 5.0 was the first major release that broke backward compatibility with earlier versions, as it removed Qt 3; applications dynamically linked with Qt 3 libraries were not guaranteed to run on all LSB 5.0-compliant distributions.[7]

Version history

[edit]
  • 1.0: Initial release June 29, 2001.
  • 1.1: Released January 22, 2002. Added hardware-specific specifications (IA-32).
  • 1.2: Released June 28, 2002. Added hardware-specific specifications (PowerPC 32-bit). Certification began July 2002.
  • 1.2.1: Released October 2002. Added Itanium.
  • 1.3: Released December 17, 2002. Added hardware-specific specifications (Itanium, Enterprise System Architecture/390, z/Architecture).
  • 2.0: Released August 31, 2004
    • LSB is modularized to LSB-Core, LSB-CXX, LSB-Graphics, and LSB-I18n (not released)
    • New hardware-specific specifications (PowerPC 64-bit, AMD64)
    • Synchronized to Single UNIX Specification (SUS) version 3
  • 2.0.1: Released October 21, 2004, ISO version of LSB 2.0, which included specification for all hardware architectures (except LSB-Graphics, of which only a generic version is available).
  • 2.1: Released March 11, 2005.
  • 3.0: Released July 1, 2005. Among other library changes:
    • GNU C Library version 2.3.4
    • C++ ABI is changed to the one used by gcc 3.4
    • The core specification is updated to ISO POSIX (2003)
    • Technical Corrigenda 1: 2005
  • 3.1: Released October 31, 2005. This version has been submitted as ISO/IEC 23360:2006.
  • 3.2: Released January 28, 2008. This version has been submitted as ISO/IEC 23360:2006.
  • 4.0: Released November 11, 2008. This version contains the following features:
    • GNU C Library version 2.4
    • Binary compatibility with LSB 3.x
    • Easier to use SDK
    • Support for newer versions of GTK and Cairo graphical libraries
    • Java (optional module)
    • Simpler ways of creating LSB-compliant RPM packages
    • Crypto API (via the Network Security Services library) (optional module)
  • 4.1: Released February 16, 2011:[8]
    • Java removed[9]
    • "Trial Use" modules from LSB 4.0, covering multimedia (ALSA), security (NSS) and desktop miscellaneous (xdg-utils) have been promoted as required submodules
    • Updated GTK+, Cairo and CUPS libraries
    • Three new test suites added
  • 5.0: Released June 2, 2015, This version has been submitted as ISO/IEC 23360:2021
    • GNU C Library version 2.10 (for psiginfo)
    • First major release that breaks backward compatibility with earlier versions (compatible with LSB 3.0, and mostly compatible with LSB 3.1 and later, with some exceptions[10])
    • Incorporates the changes made in FHS 3.0
    • Qt 3 library has been removed
    • Evolved module strategy; LSB is modularized to LSB Core, LSB Desktop, LSB Languages, LSB Imaging, and LSB Trial Use

ISO/IEC standard

[edit]

The LSB, version 3.1, is registered as an official ISO/IEC international standard. The main parts of it are:

  • ISO/IEC 23360-1:2006 Linux Standard Base (LSB) core specification 3.1 — Part 1: Generic specification[11]
  • ISO/IEC 23360-2:2006 Linux Standard Base (LSB) core specification 3.1 — Part 2: Specification for IA-32 architecture
  • ISO/IEC 23360-3:2006 Linux Standard Base (LSB) core specification 3.1 — Part 3: Specification for IA-64 architecture
  • ISO/IEC 23360-4:2006 Linux Standard Base (LSB) core specification 3.1 — Part 4: Specification for AMD64 architecture
  • ISO/IEC 23360-5:2006 Linux Standard Base (LSB) core specification 3.1 — Part 5: Specification for PPC32 architecture
  • ISO/IEC 23360-6:2006 Linux Standard Base (LSB) core specification 3.1 — Part 6: Specification for PPC64 architecture
  • ISO/IEC 23360-7:2006 Linux Standard Base (LSB) core specification 3.1 — Part 7: Specification for S390 architecture
  • ISO/IEC 23360-8:2006 Linux Standard Base (LSB) core specification 3.1 — Part 8: Specification for S390X architecture

There is also ISO/IEC TR 24715:2006 which identifies areas of conflict between ISO/IEC 23360 (the Linux Standard Base 3.1 specification) and the ISO/IEC 9945:2003 (POSIX) International Standard.[12]

The LSB, version 5.0, is also registered as an official ISO/IEC international standard.

  • ISO/IEC 23360-1-1:2021 Linux Standard Base (LSB) — Part 1-1: Common definitions
  • ISO/IEC 23360-1-2:2021 Linux Standard Base (LSB) — Part 1-2: Core specification generic part
  • ISO/IEC 23360-1-3:2021 Linux Standard Base (LSB) — Part 1-3: Desktop specification generic part
  • ISO/IEC 23360-1-4:2021 Linux Standard Base (LSB) — Part 1-4: Languages specification
  • ISO/IEC 23360-1-5:2021 Linux Standard Base (LSB) — Part 1-5: Imaging specification
  • ISO/IEC TS 23360-1-6:2021 Linux Standard Base (LSB) — Part 1-6: Graphics and Gtk3 specification
  • ISO/IEC 23360-2-2:2021 Linux Standard Base (LSB) — Part 2-2: Core specification for X86-32 architecture
  • ISO/IEC 23360-2-3:2021 Linux Standard Base (LSB) — Part 2-3: Desktop specification for X86-32 architecture
  • ISO/IEC 23360-3-2:2021 Linux Standard Base (LSB) — Part 3-2: Core specification for IA64 (Itanium™) architecture
  • ISO/IEC 23360-3-3:2021 Linux Standard Base (LSB) — Part 3-3: Desktop specification for IA64 (Itanium TM) architecture
  • ISO/IEC 23360-4-2:2021 Linux Standard Base (LSB) — Part 4-2: Core specification for AMD64 (X86-64) architecture
  • ISO/IEC 23360-4-3:2021 Linux Standard Base (LSB) — Part 4-3: Desktop specification for AMD64 (X86-64) architecture
  • ISO/IEC 23360-5-2:2021 Linux Standard Base (LSB) — Part 5-2: Core specification for PowerPC 32 architecture
  • ISO/IEC 23360-5-3:2021 Linux Standard Base (LSB) — Part 5-3: Desktop specification for PowerPC 32 architecture
  • ISO/IEC 23360-6-2:2021 Linux Standard Base (LSB) — Part 6-2: Core specification for PowerPC 64 architecture
  • ISO/IEC 23360-6-3:2021 Linux Standard Base (LSB) — Part 6-3: Desktop specification for PowerPC 64 architecture
  • ISO/IEC 23360-7-2:2021 Linux Standard Base (LSB) — Part 7-2: Core specification for S390 architecture
  • ISO/IEC 23360-7-3:2021 Linux Standard Base (LSB) — Part 7-3: Desktop specification for S390 architecture
  • ISO/IEC 23360-8-2:2021 Linux Standard Base (LSB) — Part 8-2: Core specification for S390X architecture
  • ISO/IEC 23360-8-3:2021 Linux Standard Base (LSB) — Part 8-3: Desktop specification for S390X architecture

ISO/IEC 23360 and ISO/IEC TR 24715 can be freely downloaded from ISO website.[13]

Reception

[edit]

While LSB was a standard and without a competitor, it was followed only by few Linux distributions. For instance, only 21 distribution releases (versions) were certified for LSB version 4.0, notably Red Flag Linux Desktop 6.0, Red Hat Enterprise Linux 6.0, SUSE Linux Enterprise 11, and Ubuntu 9.04 (Jaunty Jackalope);[14] even fewer were certified for version 4.1.

The LSB was criticized[15][16][17][18] for not taking input from projects, most notably the Debian project, outside the sphere of its member companies.

Choice of the RPM package format

[edit]

LSB specified that software packages should either be delivered as an LSB-compliant installer,[19] or (preferably) be delivered in a restricted form of the RPM Package Manager format.[20]

This choice of package format precluded the use of other existing package formats not compatible with RPM. To address this, the standard did not dictate which package format the system must use for its own packages, merely that RPM must be supported to allow packages from third-party distributors to be installed on a conforming system.

Limitations on Debian

[edit]

Debian included optional support for LSB early on, at version 1.1 in "woody" (3.0; July 19, 2002), 2.0 in "sarge" (3.1; June 6, 2005), 3.1 in "etch" (4.0; April 8, 2007), 3.2 in "lenny" (5.0; February 14, 2009) and 4.1 in "wheezy" (7; May 4, 2013). To use foreign LSB-compliant RPM packages, the end-user needs to use Debian's Alien program to transform them into the native package format and then install them.

The LSB-specified RPM format had a restricted subset of RPM features—to block usage of RPM features that would be untranslatable to .deb with Alien or other package conversion programs, and vice versa, as each format has capabilities the other lacks. In practice, not all Linux binary packages were necessarily LSB-compliant, so while most could be converted between .rpm and .deb, this operation was restricted to a subset of packages.

By using Alien, Debian was LSB-compatible for all intents and purposes, but according to the description of their lsb package,[21] the presence of the package "does not imply that we believe that Debian fully complies with the Linux Standard Base, and should not be construed as a statement that Debian is LSB-compliant."[21]

Debian strived to comply with the LSB, but with many limitations.[22] However, this effort ceased around July 2015 due to lack of interest and workforce inside the project.[23] In September 2015, the Debian project confirmed that while support for Filesystem Hierarchy Standard (FHS) would continue, support for LSB had been dropped.[24] Ubuntu followed Debian in November 2015.[25]

Quality of compliance test suites

[edit]

Additionally, the compliance test suites were criticized for being buggy and incomplete—most notably, in 2005 Ulrich Drepper criticized the LSB for poorly written tests which can cause incompatibility between LSB-certified distributions when some implement incorrect behavior to make buggy tests work, while others apply for and receive waivers from complying with the tests.[26] He also denounced a lack of application testing, pointing out that testing only distributions can never solve the problem of applications relying on implementation-defined behavior.[26]

For the vendors considering LSB certifications in their portability efforts, the Linux Foundation sponsored a tool that analyzed and provided guidance on symbols and libraries that go beyond the LSB.[27]

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Linux Standard Base

View on Grokipedia
from Grokipedia
The Linux Standard Base (LSB) is a collaborative project under the that establishes a set of open standards defining the binary interface, runtime environment, and supporting infrastructure for distributions, enabling greater compatibility and portability of applications across various implementations. Its primary goal is to minimize variations between distributions, thereby reducing the costs and efforts associated with developing, porting, and supporting software on the platform. Initiated in 2001 by the Free Standards Group (predecessor to the Linux Foundation), the LSB emerged from efforts by major Linux stakeholders, including distributors like IBM, Red Hat, and Caldera, to create a unified baseline for the ecosystem. The project produced its first specification, LSB 1.0, in June 2001, followed by iterative releases that expanded coverage to include core system interfaces, libraries, desktop environments, and runtime languages such as C++ and Java. Key milestones include LSB 3.0 in 2005, which introduced certification processes for compliant distributions, and subsequent versions like 4.0 (2009) and 4.1 (2011), which refined support for architectures including IA-32, AMD64, and PowerPC. LSB 3.1 was formalized as an international standard under ISO/IEC 23360, emphasizing a minimal environment for compiled applications and installation scripts. The LSB reached its final major release, version 5.0, on June 3, 2015, incorporating updates to the core, desktop, and imaging profiles while aligning with the (FHS) 3.0. Since then, the project has seen no significant updates, with major distributions like announcing the removal of LSB support in 2015 due to diminishing practical benefits amid evolving ecosystem practices. Although tools for compliance testing and certification remain available, the LSB's influence has waned as Linux distributions increasingly converge on standards through shared package managers and upstream kernel developments, though its foundational principles continue to inform compatibility efforts.

Introduction

Definition and Objectives

The Linux Standard Base (LSB) is a collaborative project under the , involving multiple Linux distributions, aimed at establishing a set of open standards that define the structure and interfaces of Linux-based software systems. This initiative seeks to create a unified baseline for the Linux ecosystem, specifying requirements for system libraries, utilities, and runtime environments to support consistent application deployment across diverse implementations. The primary objectives of the LSB include enhancing binary-level compatibility, enabling applications to run seamlessly across compliant distributions without the need for source code recompilation. It promotes by standardizing application binary interfaces (ABIs) and application programming interfaces (APIs), drawing directly from established open standards such as (ISO/IEC 9945) and the (SUS). Additionally, the LSB provides a minimal environment for installation scripts and runtime support, ensuring a predictable foundation for developers targeting platforms. By defining common interfaces for key system components—including libraries, commands, and filesystem hierarchies—the LSB works to mitigate fragmentation within the Linux ecosystem, allowing vendors to build and support products against a single, consensus-driven target rather than distribution-specific variations. This approach fosters broader adoption of standardized practices, ultimately lowering the costs associated with cross-distribution and maintenance.

Scope and Components

The Linux Standard Base (LSB) specifies a binary interface for compiled applications and position-independent executables, along with a minimal environment for dynamic linking and package formats, to promote portability across conforming distributions. It focuses exclusively on userland elements, including application programming interfaces (APIs), application binary interfaces (ABIs), libraries, commands, and utilities, while deliberately excluding kernel interfaces and behaviors. This scope ensures that software developed for one LSB-compliant system can run on others without modification, targeting user-space compatibility rather than hardware or kernel variations. The LSB is organized into modular components, each addressing specific aspects of the system environment. The LSB Core module provides the foundational system interfaces, such as standard C libraries (e.g., libc for I/O and system calls, libm for mathematics), utility libraries (e.g., libdl for dynamic loading), and essential commands (e.g., ls, cp), forming the runtime environment upon which applications depend. The LSB C++ module extends this with C++ runtime support, including the GNU libstdc++ library for features like exception handling and runtime type information. The LSB Desktop module covers graphical user interfaces, specifying libraries such as libX11 for X Window System interactions and components from Qt or GTK for desktop applications. The LSB Imaging module handles image processing, printing, and related tasks, incorporating libraries like libjpeg for format support and CUPS via libcups for print job management and rendering. The LSB Languages module ensures support for scripting languages, providing runtime libraries and interpreters for Perl (e.g., libperl) and Python (e.g., libpython), enabling consistent execution of language-specific applications. LSB conformance is structured around profiles to accommodate varying implementation levels and architectures, with the Generic profile establishing minimal, architecture-independent requirements for broad compatibility. Platform-specific profiles, such as those for (x86) and AMD64, supplement the Generic profile with architecture-dependent details like binary formats and instruction sets. The standards also encompass filesystem layout adherence to the (FHS), package formats like RPM for installation consistency, and environment variables (e.g., PATH, LD_LIBRARY_PATH) to define runtime behaviors. Supported architectures include , AMD64, and others like PowerPC, but the emphasis remains on userland portability without mandating kernel uniformity.

Historical Development

Origins and Formation

In the late 1990s, the rapid proliferation of Linux distributions led to significant fragmentation, complicating software development and deployment across varied platforms, which hindered Linux's adoption in enterprise environments. Commercial interests, including major vendors, recognized that standardization was essential to streamline application portability and make Linux a viable alternative to proprietary operating systems for business use. The Linux Standard Base (LSB) project was formally established on June 29, 2001, under the auspices of the Free Standards Group (FSG), a nonprofit founded in 2000 to promote open standards for free and open-source software. Initial sponsors included prominent technology companies such as , (HP), , , , and TurboLinux, which provided resources and expertise to drive the initiative forward. These organizations aimed to foster collaboration among Linux distributors and developers to mitigate the risks of platform divergence. Early milestones included the release of the LSB 1.0 specification on the same date as the project's formation, marking the first comprehensive document outlining binary compatibility standards for Linux systems. Initial working groups focused on the Core profile for essential system interfaces, with additional groups for profiles such as Desktop (for graphical environments) and others established later to address diverse use cases, enabling targeted standardization efforts. This foundational structure laid the groundwork for subsequent refinements while prioritizing interoperability in enterprise software deployment.

Version History

The Linux Standard Base (LSB) began with version 1.0 as an initial baseline specification establishing a common system interface for compiled applications and installation scripts across Linux distributions. This version focused on core elements without architecture-specific details, laying the foundation for binary compatibility. Subsequent early releases introduced minor updates and expanded hardware support. Version 1.1 added specifications for the IA-32 architecture, while version 1.2 incorporated PowerPC 32-bit (PPC32) support. Version 1.3 further extended compatibility to IA-64, S390, and S390X architectures. These iterations maintained the Core profile as the primary focus, emphasizing generic interfaces applicable across systems.
VersionRelease DateKey ChangesAssociated Profiles
1.0June 29, 2001Initial baseline with common specifications for core system interfaces.Core (generic)
1.1January 22, 2002Minor updates including hardware specifications.Core (generic, )
1.2June 28, 2002Added PPC32 architecture support.Core (generic, PPC32)
1.3December 17, 2002Introduced support for , S390, and S390X.Core (generic, multiple architectures)
2.0August 31, 2004Restructured documents; added initial desktop and graphical support; omitted some prior architectures like PPC32 and S390 for simplification.Core, Desktop (generic)
2.0.1October 21, 2004Minor updates and preparation for ISO submission.Core, Desktop (generic)
2.1March 11, 2005Expanded architecture support and refinements.Core, Desktop (generic, multiple architectures)
3.0July 6, 2005Aligned core specifications more closely with standards; introduced new features for broader application compatibility.Core (generic)
3.1October 27, 2005 (Core); April 24, 2006 (full, including C++ and Desktop)Served as base for ISO ; added Desktop module and errata updates in 2007.Core, Desktop, C++ (generic)
3.2January 25, 2008Incorporated LSB- and LSB-Languages modules; made Qt4 mandatory, deprecating older elements.Core, Desktop, Languages, (generic)
4.0May 1, 2009Evolutionary focus on runtime environments and binary interfaces; refined modular structure.Core, Desktop, Languages, (generic and architecture-specific)
4.1February 16, 2011Bug fixes and minor refinements to previous runtime specifications.Core, Desktop, Languages, (generic and architecture-specific)
5.0June 3, 2015Final major release with modular restructuring; removed Qt 3 support, breaking some backward compatibility; aligned with (FHS) 3.0 for updated directory layouts.Core, Desktop, Languages, Imaging (generic and architecture-specific)
Over time, the LSB evolved from basic core specifications in early versions to include graphical environments and language runtimes starting with , enhancing support for desktop applications. Version 5.0 marked the culmination of this progression, prioritizing modern standards while streamlining for runtime efficiency, with no subsequent major releases announced.

Standardization Efforts

Technical Specifications

The Linux Standard Base (LSB) core specifications define the essential system interfaces, libraries, and runtime environment required for application portability across conforming distributions. These include mandated libraries such as for and C++ compatibility, along with libm for , libpthread for threading, libdl for , and others like libcrypt, libpam, libz, libncurses, libutil, and libstdcxx to support standard runtime behaviors. The specifications require POSIX-compliant commands and utilities, such as core system tools listed in the LSB command tables, ensuring a consistent set of executables like , cp, and with defined behaviors and options. Interfaces for dynamic linking are specified through the ld.so loader, which handles ELF binary execution and resolution, including requirements for the program interpreter path and symbol versioning to maintain binary compatibility. LSB aligns its filesystem standards with the (FHS), mandating directory structures such as /bin for essential binaries, /lib for shared libraries, /usr for user utilities, and /dev for device files to ensure predictable locations for system components. For packaging, LSB prefers the due to its benefits, requiring packages to include defined metadata such as name, version, dependencies, and file lists, while also supporting as an alternative for basic archiving; this setup facilitates installation verification and conflict resolution across distributions. LSB defines conformance through profiles tailored to different implementation scopes. The Generic profile provides minimal, architecture-agnostic requirements for basic system elements like core libraries and commands. The profile extends this to a full userland environment, incorporating architecture-specific details for platforms like , AMD64, and , with comprehensive coverage of utilities, libraries, and execution environments. The Desktop profile builds on Core by adding graphical requirements, including X11 for windowing, libraries for widget toolkits, and support for desktop environments to enable portable GUI applications.

ISO/IEC Standardization

The Linux Standard Base (LSB) achieved international standardization through adoption by the (ISO) and the (IEC) under the joint technical committee JTC 1, specifically subcommittee SC 22, which focuses on programming languages, environments, and interfaces. The , as the steward of the LSB specifications, submitted the relevant documents for review and adoption via the Publicly Available Specification (PAS) transposition process, which allows developed standards to be fast-tracked into ISO/IEC international standards after national body reviews and harmonization efforts. This process included multiple cycles of technical review, ballotting by national standards bodies, and alignment with related standards such as (ISO/IEC 9945) to minimize conflicts and ensure . The initial adoption occurred with LSB version 3.1, where the core specification was published as ISO/IEC 23360-1:2006, defining a generic system interface for compiled applications and a minimal environment for installation scripts. This standard encompassed multiple parts, including ISO/IEC 23360-1 for the core generic profile, with additional parts addressing specific architectures and extensions such as desktop and imaging profiles (e.g., ISO/IEC 23360-2 through 23360-8). The publication followed the Linux Foundation's submission of LSB 2.0.1 documents in 2004, refined through LSB 3.1 releases in 2005–2006, culminating in formal ISO/IEC endorsement on December 15, 2006, after resolution of discrepancies with POSIX standards. Subsequent updates aligned with LSB 5.0, released by the in June 2015, leading to a revised multipart standard published as ISO/IEC 23360:2021. This edition, finalized in 2021, replaced the 2006 version and incorporated modular structures for common definitions (Part 1-1), core specifications (Part 1-2), and architecture-specific profiles (e.g., Parts 3-1 for x86-32, 6-1 for desktop on ). The revision process involved further harmonization with , addressing areas of prior conflict such as behaviors and library requirements, through collaborative input from the and SC 22 working groups. This ISO/IEC formalization provides official international recognition of LSB compliance, facilitating its use in regulated environments, , and cross-border software certification by establishing a verifiable baseline for system interfaces. It enhances the LSB's credibility in legal contexts, such as disputes or contractual obligations requiring standardized operating environments, while promoting global adoption without mandating distribution-specific implementations.

Compatibility and Implementation

Backward Compatibility

The Linux Standard Base (LSB) establishes as a core principle, requiring that implementations of a given major version number support binaries and applications developed for prior minor versions within the same major release. This ensures that software built against an older minor version, such as LSB 4.1, remains functional on systems conforming to a newer minor version like 4.2, without necessitating recompilation. To maintain support for legacy application programming interfaces (APIs), LSB specifications mandate the use of symbol versioning in shared libraries, allowing multiple versions of the same function to coexist within a single library file. For instance, the GNU C Library () employs version tags like GLIBC_2.4 for functions such as __fgets_chk, enabling dynamic linkers to resolve symbols to the appropriate implementation while preserving compatibility for older binaries. This mechanism, detailed in the ELF symbol versioning sections, prevents ABI breakage by associating symbols with specific version nodes defined in .gnu.version_d and required in .gnu.version_r sections of ELF objects. policies further support this by marking obsolete interfaces—such as tempnam in libc or sigpause in signal handling—for potential removal only at major version increments, providing developers with advance notice to migrate code. A notable challenge arose with LSB version 5.0, the first major release to intentionally break by removing support for Qt 3 interfaces, which had been included in version 4.0 under libraries like libqt-mt.so.3 based on Qt 3.3.6. This omission affected dynamically linked applications relying on Qt 3, requiring distributions to implement shims, compatibility layers, or alternative runtime environments to run legacy software without violating LSB conformance. The specifications recommend that distributions provide such alternatives or migration paths, emphasizing the deprecation policy's role in giving developers time to update to Qt 4.2.0 equivalents, such as libQtCore.so.4. LSB addresses through extensible profiles, such as core and desktop, which allow implementations to add optional features without disrupting base compatibility, while runtime behavior testing ensures consistent execution of legacy code across conforming systems.

and Compliance

The certification process for the Linux Standard Base (LSB) relies on the LSB Test Suite (LSB-TS), a collection of automated tools developed by The Open Group to verify compliance with LSB specifications across Linux distributions. This suite performs checks on essential components, including POSIX.1-1990 conformance for commands, partial pthread conformance for libraries, and runtime environments encompassing operating system calls (via LSB-OS tests) and the (FHS 2.x). Vendors run the suite on their distributions to identify deviations, with results submitted through a web-based system managed by the for evaluation. Certification levels range from self-assessment, where distributors internally validate compliance using the test suite without external review, to full certification by the Linux Foundation, which involves rigorous submission of test results, fee payment, and official approval to list the product in the certified directory. Full certification ensures verified interoperability and portability, though self-assessment allows quicker claims of compliance for less formal needs. Historically, LSB certifications peaked in the late 2000s, with nine major distributions achieving full certification for version 4.0 around 2010, including 5, Novell's SUSE Linux Enterprise 11, Oracle Enterprise Linux 5.3, and Canonical's Ubuntu 8.04 and 9.04. 5, released in 2007, demonstrated compliance with LSB 4.0 through successful passage of the , supporting binary compatibility for applications across certified platforms. However, the number of new certifications declined sharply after 2010, as focus shifted away from LSB maintenance and toward alternative standardization efforts. The LSB test suites faced significant criticisms for bugs and incompleteness, particularly in a 2005 analysis by glibc maintainer Ulrich Drepper, who reported that over 90% of issues identified during testing were flaws in the suite itself rather than implementation errors, leading to frequent false positives and negatives. For instance, timing-sensitive tests failed inconsistently on faster hardware like SMP systems, while workarounds in some distributions allowed erroneous passes, undermining the reliability of certifications. These shortcomings contributed to skepticism about the suite's ability to enforce true standards compliance.

Adoption and Reception

Industry Adoption

The Linux Standard Base (LSB) saw its peak adoption in the early 2000s, as major distributions pursued certification to enhance and attract independent software vendors (ISVs). In 2002, prominent distributions such as 8.0, MandrakeSoft Linux 9.0, and SUSE Linux 8.1 achieved LSB certification, marking a significant milestone in standardizing binary compatibility across platforms. By 2006, planned certification for its Drake release to support broader application portability. This momentum continued into the late 2000s, with 9.04 (Jaunty ) earning certification under LSB version 4.0. These efforts facilitated ISV support by ensuring applications could run consistently on certified systems without extensive re-porting. LSB adoption extended to enterprise environments, particularly servers and embedded systems, where standardization reduced deployment complexities for commercial applications. Key adopters included Red Hat, which committed to implementing LSB in future releases starting with version 8.0 to promote ecosystem growth. IBM-backed distributions, such as those aligned with its open-source initiatives, integrated LSB to bolster Linux's viability in data centers and hardware ecosystems. The standard's role in hardware certifications was evident on x86 platforms, where LSB compliance ensured compatibility testing for servers and embedded devices from vendors like those supporting Intel architectures. An LSB Embedded Specification further enabled its use in resource-constrained systems, aiding ISV development for industrial and networked applications. Across LSB versions, certifications numbered in the dozens for distribution releases, with 21 versions certified under LSB 4.0 alone, including 6.0 and Enterprise Linux 5.5. By 2010, nine major distributions, predominantly RPM-based like and , held LSB 4.0 certification, underscoring its prevalence in enterprise-focused ecosystems up to that point. Post-2010 adoption remained sporadic, with certifications tapering as distributions evolved independently.

Criticisms and Limitations

One major criticism of the Linux Standard Base (LSB) centers on its mandate for the RPM package format, which created barriers for non-RPM-based distributions and alienated significant portions of the Linux ecosystem. The LSB Core Specification requires that compliant applications be packaged using RPM or provide an equivalent LSB-conforming installer, effectively favoring RPM-centric distributions like and SUSE over others. This choice necessitated tools such as Alien for users to convert RPM packages to the native DEB format, introducing conversion errors, dependency mismatches, and additional administrative overhead that undermined the goal of seamless . Debian's engagement with the LSB exemplified these tensions, as the project offered only optional support from Debian 3.0 (2002) through 7.0 (2013), but fully discontinued it in Debian 8 (Jessie, 2015) due to conflicts with Debian Policy and the perceived RPM bias. Debian maintainers argued that LSB compliance imposed unnecessary constraints, such as requiring RPM metadata extraction, which clashed with Debian's emphasis on native and principles. Furthermore, practical uptake was negligible, with Debian noting scant evidence of software distributed via LSB-compliant RPMs—only eight applications from six vendors achieved by 2015, one of which targeted LSB version 4 or higher—rendering the effort burdensome without tangible benefits. Broader critiques highlighted the LSB's slow development pace and incomplete coverage of evolving technologies, positioning it as a reactive rather than proactive standard that frequently trailed distribution innovations. Corporate influences in early decision-making often prioritized irrelevant or legacy features, slowing progress and excluding community-driven stakeholders like from shaping core specifications, which fostered perceptions of toward commercial interests. The project's compliance test suites drew particular scrutiny for being buggy and incomplete, further eroding trust in certification processes.

Current Status and Legacy

Decline and Abandonment

Following the release of LSB version 4.0 in 2009, project activity significantly diminished as Linux distributions became more mature and consistent, reducing the perceived urgency for a comprehensive standardization effort. Subsequent updates were infrequent, with version 4.1 issued in 2011 and the final major release, version 5.0, in June 2015; no new specifications or revisions followed. While the LSB 5.0 content was incorporated into the ISO/IEC 23360 standard series in 2021—covering core, desktop, and other modules—this merely formalized existing work without advancing the project further. Several factors contributed to this decline, including the maturation of distribution-specific ecosystems and the emergence of alternatives that addressed without relying on LSB compliance. The rise of cloud-native technologies, such as with tools like Docker, diminished the need for broad binary compatibility by enabling applications to operate in self-contained environments across diverse hosts. Prominent distributions also scaled back support; for instance, proposed removing most LSB packages in 2015, retaining only minimal components like lsb-base for legacy script compatibility, a move echoed by around the same time. The LSB's effective abandonment was formally declared on February 7, 2023, in a post to the lsb-discuss by a former project maintainer, stating that "the LSB project is essentially abandoned" due to insufficient interest and resources to sustain development.

Alternatives and Impact

The Linux Standard Base (LSB) left a lasting legacy by promoting the adoption of foundational standards such as the (FHS) and compliance across Linux distributions. Although LSB certification declined, its specifications explicitly referenced and aligned with the FHS, including versions 2.3 and 3.0, for directory structures like /dev and /etc, encouraging consistent file organization that persists in modern distributions. Similarly, LSB aimed to converge with ISO/IEC 9945 (), incorporating interfaces from POSIX 1003.1-2001 and planning long-term alignment, which reinforced as a baseline for application portability. This emphasis on shared hierarchies and interfaces helped normalize these practices, even as formal LSB efforts waned. LSB's challenges in achieving widespread binary standardization inadvertently paved the way for innovative inter-distro tools that address portability more flexibly. For instance, universal packaging formats like emerged to bundle applications with dependencies, enabling execution across distributions without relying on a uniform base, thus resolving fragmentation issues that LSB struggled with. These tools represent an evolution from LSB's goals, prioritizing self-contained distribution over enforced system-wide uniformity. In place of LSB's binary standards, contemporary alternatives have shifted toward and universal formats to achieve application portability. Container technologies such as Docker and Podman encapsulate software environments, allowing consistent runtime behavior across diverse hosts without mandating distribution-wide standards like those in LSB. Likewise, and Snap provide sandboxed, dependency-bundled packages that bypass traditional binary compatibility requirements, solving interoperability problems through isolation rather than convergence on a common base. Complementing these, de facto convergence has occurred via widespread adoption of as the system and as the C library, which now serve as implicit standards in major distributions, reducing variances without formal certification. Looking ahead, no revival of LSB is planned, as its maintenance ceased around with the redirecting efforts elsewhere. Instead, the Linux ecosystem emphasizes upstream, community-driven standards hosted by organizations like freedesktop.org, which now stewards the FHS and specifications for desktop interoperability as of November 2025, fostering organic alignment over rigid, top-down frameworks.

References

  1. https://refspecs.linuxfoundation.org/lsb.shtml
  2. https://wiki.linuxfoundation.org/lsb/start
  3. https://www.computerlanguage.com/results.php?definition=Linux%2BStandard%2BBase
  4. https://refspecs.linuxfoundation.org/LSB_1.1.0/gLSB.html
  5. https://lwn.net/Articles/658809/
  6. https://wiki.linuxfoundation.org/lsb/lsb-charter
  7. https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic.html
  8. https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Common/LSB-Common.html
  9. https://www.zdnet.com/article/linux-standardization-inches-towards-reality/
  10. https://linuxdevices.org/free-standards-group-releases-lsb-version-10/index.html
  11. http://www.cnn.com/2001/TECH/ptech/07/10/linux.standard.base.idg/index.html
  12. https://www.linuxjournal.com/article/6592
  13. https://www.hpcwire.com/2001/03/23/linux-standardization-efforts-move-ahead/
  14. https://refspecs.linuxbase.org/LSB_2.0.1/LSB-Core/LSB-Core.html
  15. https://refspecs.linuxbase.org/LSB_1.0.0/gLSB.html
  16. https://refspecs.linuxbase.org/LSB_1.1.0/gLSB.html
  17. https://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic.html
  18. https://refspecs.linuxbase.org/LSB_4.0.0/LSB-Core-generic/LSB-Core-generic.html
  19. https://refspecs.linuxbase.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic.html
  20. https://refspecs.linuxbase.org/LSB_5.0.0/index.html
  21. https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/book1.html
  22. https://refspecs.linuxfoundation.org/LSB_2.1.0/LSB-Core-generic/LSB-Core-generic.html
  23. https://refspecs.linuxfoundation.org/LSB_5.0.0/index.html
  24. https://www.open-std.org/JTC1/SC22/LSB/docs/ISO-IECJTC1-SC22-OWGLSB_N0001-23360-1-1-LSB-5-0-Common-Generic-2017.pdf
  25. https://knowledge.bsigroup.com/products/linux-standard-base-lsb-core-specification-3-1-part-1-generic-specification
  26. https://www.open-std.org/jtc1/sc22/open/n3632/n3632wd.pdf
  27. https://www.iso.org/standard/77865.html
  28. https://cdn.standards.iteh.ai/samples/77865/9182836573574505a62343c1ba21b331/ISO-IEC-23360-1-1-2021.pdf
  29. https://www.open-std.org/JTC1/SC22/LSB/docs/ISO-IECJTC1-SC22-OWGLSB_N0002-23360-1-2-LSB-5-0-Core-Generic-2017.pdf
  30. https://www.iso.org/committee/45202.html
  31. https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Desktop-generic/LSB-Desktop-generic.html
  32. https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic.html#SYMVERSION
  33. https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic.html#10.7
  34. https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic.html#TBL-LIBC-STAND-DEPINTS
  35. https://refspecs.linuxfoundation.org/LSB_4.0.0/LSB-Desktop-generic/LSB-Desktop-generic.html
  36. https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic.html#INTRO
  37. https://www.opengroup.org/testing/linux-test/
  38. http://linuxtesting.org/certification_system
  39. https://wiki.linuxfoundation.org/lsb/certifying-application-lsb
  40. http://www.dsilakov.ru/papers/rubanov_silakov_opencert.pdf
  41. https://linuxdevices.org/lsb-40-certifications-aim-to-heal-linux-fragmentation/index.html
  42. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/5/html/5.6_technical_notes/redhat-lsb
  43. https://www.linuxfoundation.jp/press-release/2010/12/linux-foundation-announces-certifications-to-linux-standard-base-4-0-and-public-beta-4-1/
  44. https://udrepper.livejournal.com/8511.html
  45. http://www.novell.com/news/press/pressroom/news_brief/archive/2002/suse_archive/lsb_certification.html
  46. https://lists.ubuntu.com/archives/ubuntu-announce/2006-March/000058.html
  47. https://www.linux.co.cr/distributions/review/2002/1008.html
  48. https://lwn.net/Articles/28059/
  49. https://refspecs.linuxbase.org/LSB_3.0.0/LSB-Embedded/LSB-Embedded.html
  50. https://www.linux-magazine.com/Online/News/Certifications-to-Linux-Standard-Base-4.0-and-Public-Beta-4.1-Announced
  51. https://www.debian.org/doc/manuals/debian-faq/compatibility.en.html
  52. https://wiki.debian.org/LSB
  53. https://www.linux.com/news/linux-standard-base-approved-international-standard/
  54. https://www.iso.org/standard/77867.html
  55. https://linux.slashdot.org/story/23/08/12/1835204/should-there-be-an-official-version-of-linux
  56. https://bugs.mageia.org/show_bug.cgi?id=33052
  57. https://lwn.net/Articles/1045405/
Add your contribution
Related Hubs
User Avatar
No comments yet.