Linux Standard Base 2.0 promises a common runtime standard

The Free Standards Group’s (FSG) Linux Standard Base specification is an attempt to prevent the Linux marketplace from fragmenting by specifying a runtime environment where applications compiled for different distros can run install and run seamlessly.

LSB consists of two parts: The generic specification, which is common to every architecture, and an architecture-specific part. The generic specification describes those parts of the interface that remain constant across all the architectures, including the Filesystem Hierarchy Standard (FHS) and Executable and Linkable Format (ELF) Specification, which is common to all platforms. The LSB ELF is the definition of the object files produced by the C compiler on a particular system.

The architecture-specific specification describes items such as endianess, the size of data types such as long, and function calling sequence.

LSB 2.0 was released on September 14, and the LSB 2.0.1 spec was submitted to the International Standards Organization (ISO) on October 21.

What’s new in 2.0

LSB 2.0 has added support for Single Unix Specification 3.0 (SUS) and new architectures such as IBM’s PowerPC 64, S390, and S390X, and AMD’s 64-bit Opteron. Most significantly, LSB 2.0 has introduced a new Application Binary Interface (ABI) for C++. This will aid software vendors to port their applications to Linux and increase application choice for end users. According to Theodore T’so (during a talk at Sucon ’04), “The ABI defines the bare minimum binary compatibility layer needed for applications from one distro to run on another. Also, g++ releases have had several incompatible changes in the past, which had caused significant grief for enterprise vendors. Now with the inclusion of C++ in the LSB standard, things are bound to improve.”

If Linux has a standardized ABI, other operating systems can use it to implement an emulation layer to run Linux applications. FreeBSD already has a FreeBSD Linux Compatability Layer in place, and Solaris has started Project Janus to provide an LSB implementation so that Linux applications can run on it.

Red Hat Package Manager (RPM) v3.0 is also included in the standard. RPM users have a problem when installing RPM packages from different distributions, as different distributions use different package, file, and library naming schemes, which makes for a painful process of installing dependencies, known as “RPM dependency hell.” Inclusion of the RPM and FHS standards in the LSB should give end users relief from this pain. They should also find it easier to get support for LSB-certified applications, as the same binary will be used by an application’s vendor across different distros. This is good news for support engineers too, who should have to do minimal distro-specific debugging. All in all, LSB is a win-win situation for everybody in the free and open source software (FOSS) community.

Recently IBM Press published “Building Applications with LSB.” Developers who are serious about making their applications run on different distributions and OSes should follow the guidelines in this book. The book is written by the core members of the LSB team. The FSG’s Linuxbase Web site includes many tools as well as a reference implementation that developers can use to test whether an application follows the guidelines of the LSB 2.0 standard.

The FSG has tied up with the Open Group for the LSB certification process. A list of all certified products and distributions is available on the Open Group’s site.

There are many ways the community can get involved in the LSB standardization process. The easiest way is to join the mailing list and start contributing to the test suite and the reference implementation. Another area where volunteers can participate as contributors or observers is in LSB Futures, a sub-project that widens the scope of the LSB by incorporating new libraries into the LSB.

Benefits for enterprise vendors and ISVs

Already major commercial vendors such as Intel, AMD, Hewlett-Packard, IBM, and Novell have backed the LSB specification. More significantly, Red Hat, SUSE, Debian, and Mandrake, the four most widely used Linux distributions, back the standard and assure compliance. Matt Taggart, a Debian contributor has posted the results after running the LSB test suite on Debian (testing and unstable branches) In fact, the Open Group has already certified SUSE 9.2 Professional as LSB 2.0-compliant. This will be a huge relief to independent software vendors (ISV). In the absence of a common standard they now have to support different binaries for different distros.

Recently, Mandrake, Connectiva, Progeny, and TurboLinux announced a project called Linux Core Consortium (LCC) that aims to create a common implementation of LSB 2.0 on which each of these vendors will base their products.

Earlier efforts to unify the fragmented Unix market failed to have an the desired impact. Notable among them is Portable Operating System Interface (POSIX), which specifies only the programming interface and does not guarantee binary compatibility. Other attempts to provide a runtime environment, such as OSF/1, failed to find favour with the market. Theodore T’so states, “LSB has a good chance of succeeding, as it specifies a binary compatibility layer which is more rigid than POSIX while not as restrictive as OSF/1.”

According to everyone we spoke with, LSB has a great chance of succeeding where others have failed, as it has a much more pragmatic approach than earlier efforts, thanks to the support and involvement of enterprise vendors and ISVs as well as good support from FOSS community.

Vinayak Hegde is a open source software hacker who writes in his non-existent free time.