\n"; ?>

LSB - The Standard for the Penguin

Jana Jaeger

So there is one more standard in the world - but do we really need it? This is a question that has probably been asked by many since June 29, 2001. In the Unix universe, standards are nothing unusual and they are numerous. Such standards have not always succeeded at achieving their noble goal (to make the world a simpler place). Rather, due to unreliable implementation, they have actually contributed to confusion in the programming world. In this context, there is a wonderful, if quite cynical, quote attributed to Andrew S. Tanenbaum, the father of MINIX:

"The nice thing about standards is that there are so many of them to chose from"

The purpose of this article is to lift the veil of secrecy surrounding LSB's objective, purpose and content and to present evidence why LSB won't be one of those standards that simply disappear into oblivion.

One For All - All For One

First, before addressing the details, a few words about LSB (Linux Standard Base) in general. Generally speaking, and leaving aside all the technical details, LSB will form the common basis for use by distributors, developers and independent software vendors, ISV. Below I will provide additional information about why this issue is so important and how those involved benefit from the standard.

By now, Linux has long outgrown the "X disks & 1 nerd" reputation that it used to have. More and more software vendors and individual developers have tasted blood and want to develop (as well as sell) software for Linux.

This ambition, however, quickly reveals a problem: as soon as someone wants to run his programs under Linux (i.e., a Linux distribution), he must either decide on using one system or individually compile his software programs for each kind of Linux. Different Linux vendors use different system library versions (e.g., glibc) that also use different versions or implementations of some subroutines and that sometimes hide their files, programs and initialization scripts in different locations.

As a consequence, for reasons of efficiency, many ISVs offer their software only for the few large distributions, or even for only one of them. In the long run, such behavior would quickly thin out the colorful world of Linux distributions, because some would not be able to say: "Company XYZ has certified its software for our Linux distribution." Sooner or later, the expenses involved in such actions would bankrupt one or the other participant.

One of LSB's goals is to help counteract this dependence on just a few distributions by enabling ISVs to sell software that conforms to LSB and that runs smoothly on all LSB-compatible systems.

This kind of situation would benefit anyone even remotely involved with Linux or software for Linux.

  • The user: It no longer matters which Linux/which distribution he is using. He can exchange software between them or add software any way he wishes. Packages that conform to LSB no longer depend on anything, except other LSB packages.
  • The ISV: Software that has been certified for a Linux version that conforms to LSB can also easily be used with other Linux versions that conform to LSB. In no way is the ISV dependent on the support of a specific distribution.
  • The developer: It is sufficient to write software so that it meets LSB requirements. It is no longer necessary to customize for individual distributions, as long as they support LSB.

The LSB initiative started in early 1998, with the original idea conceived by Bruce Perens and others to create an open and non-commercial reference distribution. The multitude of distributions on the market crystallized the danger of a potential split into many incompatible branches. In the long run, such politics would mean that the Linux distributions would cut off their own supply lines, since there would be confusion in the developer community, with respect to both the commercial sector (ISVs) as well as non-commercial interests, about how to develop their applications. With the "paper" standard, the LSB team intends to provide some kind of "guideline" along with a reference implementation. It should be simple for distributors to integrate the reference implementation in their actual distributions and thus provide a working reference platform for developers. Special test programs, called "test suites", can be used to check conformity to the standard, for distributions as well as for applications. The LSB project's first announcement in May 1998 summarizes its (ambitious) goals.

The inventors of LSB can be found among the ranks of the Open Source community's high-powered developers and thinkers (Linus Torvalds, Jon "Maddog" Hall, Bruce Perens, etc.), as well as among some of the distributors. As time went by, representatives of the large ISVs (Hewlett Packard, IBM, Oracle, ...) also discovered LSB and supported the project financially, as well as by contributing their expertise.

Looking Within

So how are those noble goals mentioned above implemented? What elements must such a standard comprise to succeed and which of them have already been implemented with LSB 1.0?

A system that conforms to LSB must be fully normed, that is, from booting up to the routines used. In the long term, this means that all of the following items must now be implemented so that applications will run on all LSB-Linux systems.

Shared Libraries (glibc, pthreads, ncurses, etc. )

Different Linux distributions use different system libraries. Thus, Linux distribution A may contain a more recent version than B, and C, in turn, can deviate significantly from anything near a common denominator. If an ISV now delivers a new software program, it is possible that the program will run smoothly on A, while it doesn't run at all on B. The problem in this case: the ISV has optimized his software to run with Version A. Unfortunately, even though applications are capable of working with current libraries, backward compatibility is a very different issue.
The high road: designate a specific version as the standard, name it accordingly, for example ld-lsb.so.1, and thus provide a firm reference point for the ISVs.
If this library is then included in all distributions that conform to LSB, all applications that need this standard library will also run. This does not mean that the distributions cannot also simultaneously contain other versions of this library that can be used to run special software typical for a distribution.

System Commands

Another point of contention for a reference system are the system commands being used. It is necessary to create a precise list of all commands, along with their locations in the file system, because that is the only way for programmers to stay on top of knowing which routine they are even allowed to call in their programs or scripts.
That is why LSB defines a minimum set of general UNIX commands (man, cat, grep, etc.) that a system conforming to LSB must be able to use (please go here for an overview). This brings us to the next important item:

File System Hierarchy

How does it benefit even the best of systems if it has standard libraries and system commands, yet they are hidden all over the file system? LSB contains the Filesystem Hierarchy Standard (FHS) Version 2.2, so that all programs and scripts of a standard-based distribution "know" where files are located. FHS specifications were used to organize most distributions even before LSB was developed. The entire current version is available at www.pathname.com, and also through www.freestandards.org.

Systems/Initscripts Initialization Process

As far as ISVs are concerned, a system is of interest even before it is fully initialized. Vendors of large database applications in particular must know which basic services (e.g., network) become available at which point in time. Some databases access the system at a very elementary level during the boot process. That is why LSB is quite concerned with how initialization files and scripts must be structured, with their sequence and their location within the system (see FHS above).

In this context, it is important that every system can use a defined interface to understand and implement the scripts correctly. However, this does not necessarily mean that the LSB's runlevel 5 is also a different distribution's runlevel 5. What is important is that the function intended by LSB is present, not how.

Implementing the POSIX.1 Standard (with glibc Extensions)

In order to inform Linux software programmers about which functions are available, LSB uses the POSIX (Portable Operating System Interface) standard, which is generally the most important standard for UNIX and UNIX-type systems.


Linux has always been planned as a very network-aware system from the ground up. Thus, LSB also covers how the system generally communicates with the Internet and with networks. Here, LSB sticks quite closely to existing standards, making them more powerful in the process.


Many, if by far not all applications need a graphical interface. Graphics applications can grow to considerable sizes due to static linking of several required libraries. LSB standardizes the lowest protocol layers in order to reign in this phenomenon in particular. At higher levels, programmers are free to do or not to do whatever they wish. Thus, they can continue to use X11 applications relatively freely on diverse (non-LSB or non-Linux) platforms, provided that the corresponding protocols exist.

Software Installation Basics

The use of a unified packet format for software installation is another item that LSB systems absolutely must agree on among themselves. The final LSB packet format corresponds (with some restrictions) to the widely used RPM format (defined according to Maximum RPM). LSB does not specify how to create the packets. However, there are clear guidelines on naming conventions and on specifying the individual packets' interdependencies. Logically, an LSB distribution's packets can be dependent only on other LSB packets. Again, using RPM as the standard packet format does not mean that a distribution must give up its own format in order to conform to LSB. Naturally, you can continue to use your "in-house mechanism" for non-LSB packets / non-RPM packets.


The "executable linkage format" is now a Linux standard and describes the structure of programs and libraries as binary files.

The definitions alone do not convey a standard's importance - after all, who can guarantee that "everything labeled 'LSB' actually does contain LSB"? As long as there is no reference system that can be used as a yardstick, or specific tests to determine the degree of conformity to the standard, the standard isn't worth the paper on which it is printed.

That is precisely why there is already a reference system in the works in accordance with all LSB rules. However, what is much more important at the moment is the fact that there are already a few "test suites" that can be used by a distribution's vendor to check how much his system conforms to LSB and that can also be used by an ISV to check if his applications will run on such a system. Still, at this point, test suites, just like the reference implementation, remain very much a work in progress. While the first steps have been taken, it will still take some time before these items are fully implemented, approved and officially released.


Even though the release of LSB 1.0 two weeks ago hardly caused a media frenzy, it would be wrong to conclude that this event will be remembered as no more than a footnote to Linux history. LSB will generate a lot of excitement as soon as the remainder of LSB is released as well and the certification process begins.

Taking a look at the project's backers (www.linuxbase.org) illustrates the importance of LSB and should dispel any doubts about its future. The trick of bringing the ISVs' commercial interests and the developer community's technical interests to the same table will succeed once the two sides sit down at the table, which is what is happening here. Both sides have a vested interest in advancing this cause - and if there should be any doubts, the "voice of reason" (i.e., preservation of common interests) will be sitting at the other side of the table ;-)

Similarly, fears that LSB will destroy the individual distributions' variety and uniqueness will have no basis in reality. LSB does not require that all distributions have identical structures, nor does it require anyone to include nothing but software conforming to LSB with his distribution. For many, LSB support will become another important, additional feature, instead of causing the Linux landscape to deteriorate into a monotonous culture. Besides, a distribution's success isn't solely measured by the distribution's software selection.

Below is a list of the different LSB add-ons available for a distribution.

The LSB base system
Meets LSB requirements and enables LSB applications to run.
The LSB package
All applications for an LSB system have been developed and packaged according to the criteria described above.
Test suites
A suite of test programs to determine conformity to LSB of base systems or packages/applications.
Development environment
In the future, special development tools will be available to develop program packages that conform to LSB.

Every distribution rated as conforming to LSB must contain the first element. The distributor can use the test suites and development environment to provide an additional service for developers and ISVs.

SuSE and LSB

Since LSB's entire package has not yet been released, it is not possible to certify a distribution as conforming to LSB 1.0. With SuSE Linux 7.1, SuSE has already largely implemented FHS.

SuSE is actively working on developing LSB. SuSE will also integrate LSB support into the distribution and obtain certification.

More about LSB

Those who wish to learn more about LSB will find the LSB project pages and the Free Standards Initiative of interest.

  • This is the home page of the LSB Project, which features many additional links to articles and talks about LSB.
  • This is the home page of the Free Standards Project.
\n"; ?>