Text only | Skip links
Search 
WebWikiAll
This web page has been archived This web page has been Archived. Its content will not be updated. Use this link to obtain further details of our archive policy .

Linux Standard Base: What is it and why is it important?

Linux Standard Base (LSB) is a project which aims to standardise Linux platforms and Linux applications. It enables applications, data and personnel to move easily between different Linux distributions by fostering and documenting their commonalities. It develops and releases test suites which enable automated checking for compliance with the LSB standards. This compliance is certified by a related organisation, the Free Standards Group.

It is possible to certify several kinds of software, including:
  • an application;
  • a runtime environment (such as a Linux distribution).
If an application is certified, then that application should run on any certified runtime environment. If a runtime environment is certified, then that runtime environment should run any certified application.

The end result is that software vendors can release software that runs on a wide range of Linux distributions, including RedHat, SuSE, Debian and Mandrake. They can have confidence that their software will run without having to test it on each platform, greatly reducing the software vendor's effort. End-users also benefit as this process makes a wide range of software available to any certified distribution.

LSB standards relate largely to compiled applications. LSB compliant applications do not need to be compiled or debugged by the installer. Thus the installation process becomes as simple as unzipping a compressed file into an empty directory.

The LSB is mainly an organising standard, much of the actual standardisation effort is led by international standards bodies. These include:

  • the ISO which includes the standardisation of several programming languages and country names
  • the IEEE which includes the standardisation of floating point arithmetic and POSIX
  • the IETF which includes the standardisation of the OpenPGP and gzip formats
  • ad-hoc groups standardising issues such as filesystem layout and debugging formats

The most crucial standards are, however, the Application Binary Interface (ABI) standards, which specify in great detail how programs interact with each other. The ABIs allow software to be distributed as compiled binaries rather than source code.

The LSB periodically takes a snapshot of each of these standards and bundles them up by giving them a single LSB version number and building test suites around them. Since following these base standards is generally best-practice, most high-quality software already uses them.

Standardisation is generally thought of as a positive move but it does not come without a downside. Standards, by their very nature, embody assumptions and as Linux becomes more standardised it risks becoming increasingly ossified, harder to change and less flexible in new or unusual situations. This impacts in a number of ways:
Security flaws can be harder to fix
A number of assumptions which are now recognised as security flaws are included in the standards. These include the gets() function in the C standard library and the /tmp/ common temporary directory. Their inclusion in the standards makes these issues much harder to fix than they otherwise would be.
Only stable software is included
LSB emphasizes stability and correctness, so it can take a long time, often a very long time, before new releases and features get included in LSB-oriented systems. The trade-off between stable, reliable software and unstable, highly functional software is a common theme in differentiating Linux distributions.
No distribution-specific features
LSB applications are designed to work on a wide variety of distributions, which usually means that they don't work as perfectly as they might with any particular distribution. This normally means the applications may not appear in menus, may not be available through the distribution's normal software distribution channels, and GUI LSB applications may appear with a different look and feel than normal applications.
Innovations must provide backwards compatibility
Innovations in an LSB compliant system need to provide backwards compatibility so as not to break the LSB compatibility. While in some cases compatibility is not an issue, in many cases it is. Compatibility is often provided by compatibility layers, which are wrappers around the new libraries or applications which make them look like and behave like the old libraries or applications.

Despite these tensions, the LSB enjoys strong support, particularly from commercially oriented distributions and companies. Its supporters see the LSB as a way to reduce the effort needed to port proprietary applications to Linux and as a tool for ensuring that applications run on a wide range of Linux systems. Support for the LSB is less strong among open source advocates as it enables the proliferation of closed source software as compiled binaries, rather than encouraging software vendors to release the source code.

However, even these open source advocates acknowledge that formally specifying program behaviour and responsibility brings many advantages. It not only encourages interoperability between applications but also enables many bugs to be clearly assigned to a single application and greatly enhances the capabilities of autonomous testing. Such autonomous testing is widely used in large distributions to ensure changes in one package do not negatively impact any of the thousands of other projects. The more tightly the interfaces between the applications are specified, the greater the range of tests that can be performed and a larger proportion of bugs automatically detected.

Links:

Related information from OSS Watch:

Date: November 2004 (last updated Tue, 13 Nov 2007)
Last reviewed: December 2006
Author: Stuart Yeates

Unless otherwise indicated, this page is © 2004-2007 University of Oxford.
Creative Commons licence It is licensed under the Creative Commons Attribution-ShareAlike 2.0 England & Wales licence.
JISC logo OSS Watch is funded by the Joint Information Systems Committee.
OSS Watch values your input and questions.
If you have feedback on this document, or any OSS Watch activity, please send it to info@oss-watch.ac.uk
Follow our tweets via the OSS Watch twitter account at http://twitter.com/osswatch