The Linux Standards Base

Written by: Finn Orfano • Edited by: J. F. Amprimoz
Updated Jul 4, 2011 • Related Guides: Linux Distribution | Linux | Libraries

To many, Linux is a standard. Experience, however, suggests otherwise. Aimed at delivering a win-win outcome for all stakeholders, the Linux Standards Base seeks to eliminate the interoperability challenges in Linux distributions and applications.

Next up: Enter the Linux Standards Base ►

Slide 1 of 3

About a decade ago, I was employed by a commercial provider of enterprise software. And though I had various roles, they were typically technical and customer-facing. Discussions that went well with prospects often included the question: "Do you support Linux?". The answer: "Absolutely!" And then and there, or soon afterwards, the dance of mutual clarifications would begin. As the vendor, we'd need to know the obvious: The prospect's Linux distribution and architectures of interest. In time, we learned we needed to be even more specific in asking about the Linux kernel ("uname -r"), the GNU C Library (glibc) and in further clarifying the architecture ("uname -m"). Armed with this information, we'd then consult our support matrix to see if we had a match. In the event we didn't have a match, we'd develop yet another Linux port (YALP). And if the request was particularly obscure, the port may have been at the prospect's expense.

There are at least two observations that can be drawn from the above anecdote:

There is no standard implementation of Linux.
Support complexity is not sustainable.

Enter the Linux Standards Base

Slide 2 of 3

The Linux Standards Base (LSB) aims to standardize the implementation of Linux. And in so doing, introduce sustainability for all stakeholders - from providers of Linux distributions and Linux applications to consumers of the same. In principle then, the anecdotal conversation I shared above would be brief: "Our enterprise software is compliant with LSB 3.2."

As the LSB-style response implies, there is some concept of a reference implementation of Linux. LSB 3.2 is comprised of the following specifications:

Core - Addresses the fundamental system interfaces, libraries, and runtime environment upon which all conforming applications and libraries depend.
C++ - Supplements the Core Interfaces by providing system interfaces, libraries, and a runtime environment for applications built using the C++ programming language. These interfaces provide low-level support for the core constructs of the language, and implement the standard base C++ libraries.
Desktop - Targets components found on an LSB conforming system.
Scripting Languages - Addresses components for runtime languages which are found on an LSB conforming system.
Printing - Addresses the multimedia components found on an LSB conforming system.

To make this more concrete, consider the LSB Scripting Languages specifications. In LSB 3.2, this translates to specific versions of Python and Perl that must be present. For example: "The default installed Python version shall be 2.4.2 or greater. Applications can depend on the 2.4 interfaces."

In addition to the mandatory specifications, LSB 3.2 includes trial-use specifications.

LSB 4.0 improves the breadth and depth of the five areas for mandatory specifications. In the case of the specifications for (scripting) languages, the Python and Perl specifications are being extended, while new specifications are being developed for Java and Mono, and potentially for PHP and Ruby. LSB 4.0 was anticipated for release in late 2008. And although progress is clearly being made, the release remains outstanding.

Although roadmaps beyond LSB 4 are not available, one might anticipate that working group activities may eventually put shape to such elaborations beyond what exists today.

The Broader Context of The LSB

Slide 3 of 3

From various perspectives, the LSB presents as a 'standards effort' - along the lines of the IETF or the W3C. With respect to these comparators though, the focus of the LSB is the implementation of Linux - as opposed to 'blueprints' for building an implementation. In other words, the LSB is primarily a binary interface definition.

LSB-Core, LSB-C++, LSB-Desktop, LSB-Languages and LSB-Printing comprise the LSB deliverables. These deliverables are achieved under the auspices of the nondenominational Linux Foundation. In addition to providing a rich ecosystem that facilitates the development and adoption of the LSB, The Linux Foundation is involved in a number of parallel measures relating to Linux as a whole.

All of this sounds great in theory, but how does it play out in practice? With respect to LSB 3.2, all major distributions have been certified, as have a number of Open Source and commercial applications. On the surface, this also appears promising - until you dig a little deeper. Take the popular Ubuntu Linux distribution for example. Ubuntu 6.06 LTS is certified against LSB 3.2 (2006-2008), with plans for Ubuntu LTS 8.04 to be certified against LSB 4.0 (2008-2010). Certification against the LSB takes time, and this time introduces a lag. Depending on your priorities then, and true in general for the LSB, the wait may be worthwhile.

◄ ●●● ►