Latest LSB release continues to promote a common future

The Linux Standard Base (LSB) project aims to keep subtle differences between implementations of the operating system from making applications incompatible across distributions. Last month’s release of LSB 3.2 continues along that road, furthering compatibility and encompassing new standards for multimedia and scripting languages.

The original goal of the LSB project was to provide a vendor-neutral standard for running environments, libraries, formats, and other system software, thus defining a reference platform such that any program that could successfully run on it could run on all distributions that complied with the standard.

The project was born in 1998, and released LSB 1.0 in mid 2001. Version 2.0 came out in 2004, and 3.0 in 2005. The current version is 3.2, was released last month. As of 2005, LSB became an international standard (ISO 23360), further enhancing its importance and relevance. Version 4.0 is supposed to appear later this year and remain current until 2010.

Currently, most major distributions comply with the LSB and have certified (or are certifying) their latest versions, thus earning the right to the “LSB Certified” trademark and logo. In alphabetic order, the list includes Asianux (Server 3.0), Debian (Etch), Mandriva (2007), Novell (SUSE Linux Enterprise 10, openSUSE 10.2 but not 10.3 yet), Red Hat (Enterprise Linux 5), Ubuntu (Dapper), and Xandros (Server 1.0). In all these cases, certification is up to version 3.1, since 3.2 is too recent. It seems likely that more distributions will get certified (or recertified) for the latest standard in the upcoming months. Among common distributions, Fedora and Freespire/Linspire are the most outstanding omissions.

What does the LSB include?

The LSB is divided into six functional areas in the latest version:

• Core: Includes Executable and Linking Format (ELF), required base and utility libraries, execution environment aspects, required commands, system initialization, users and groups, and package formats and installation. These requirements assure users of a basic environment and installation tools.
• Desktop: Includes graphic and OpenGL libraries; GTK+, Qt, PNG, and JPEG libraries; font-related themes such as fontconfig and FreeType; and general environment aspects. In the 3.2 release some desktop integration concepts were added as a trial standard.
• C++: Includes details on low-level system information such as class and data representation, and required libraries. The included tests can help you determine whether you’ve used any nonstandard libraries in your code.
• Printing (new in 3.2): Includes Common Unix Printing System (CUPS) and new commands foomatic-rip and gs; this pair implies connectivity with most (if not all) spoolers, and the availability of PostScript and PDF output.
• Runtime languages (new in 3.2): Covers Perl and Python. Any application based on these languages can count on a standard set of features and libraries being available; for example, check the required lists for Python modules and Perl modules. Two test suites are included, one for each language.

A “trial use standard” covers two areas: sound and desktop integration. Advanced Linux Sound Architecture (ALSA), which is included with most current distributions, is part of the standard. The xdg-utils commands, from the Portland Project, are included: they provide command-line ways of installing or uninstalling desktop menu items or icon resources, file type handling, sending mail via the user’s preferred email tool, controlling the screensaver, and more.

Failure to comply with a “trial use standard” won’t disqualify a product from attaining LSB certification; these standards are included as a test, with the idea that they’ll become part of the standard in the future. The Core, Desktop, and C++ areas have both a generic specification and architecture-dependent rules for Intel 32- and 64-bit platforms, PPC 32 and 64 bits, System 390, and AMD 64 bits.

The standard also includes many tests required for certification. To certify your software, you have to run the appropriate tests — you will need either the Distribution Testing Kit (DTK) or the Application Testing Kit (ATK) — and fix any problems that the testing kit identifies. When your software passes all the tests, you can register with the Linux Foundation for a final audit, which involves submitting the test results, paying some fees (for example, for a distribution they can range from $250 to $5,000, depending on your member status and if it’s a first-time certification or a maintenance release) and signing a Trademark License Agreement. The Linux Foundation encourages products that have achieved compliance to use the LSB name and logo, as a proven compatibility indicator.

A few years ago, problems with the test suites caused correct distributions to fail or, worse, flawed distributions to achieve success, leading to criticism. However, these problems have been addressed.

If you want documentation on the LSB, a Web search for books produces just one, available online or from IBM Press, but it was published in 2004, so it’s a bit dated. On the plus side, it was written by several core members of the LSB, who certainly know what they’re talking about. (As an aside, check this 2020ok reference for a really serious misunderstanding; the book appears classified under “Microsoft, Development, Visual Basic”!) If you want up-to-date documentation, you’ll probably be better off with the latest standard and certification information.