The relevance of the Linux Standard Base [LWN.net]

Back in May, 1998, a group of high-profile Linux development and business figures (including Linus Torvalds, Jon 'maddog' Hall, Bruce Perens, Ransom Love, Larry Augustin, Eric Raymond, and others) proposed the creation of a Linux application binary interface (ABI) standard. This effort, called the "Linux Standard Base," would help to ensure that applications ran on all Linux systems. In this way, it was hoped, a great wealth of applications for Linux would be created, and Linux would avoid the sort of fragmentation which afflicted proprietary Unix systems. The LSB would include a formal specification and a reference implementation; applications which ran on the reference system could be expected to run on all LSB-compliant systems.

More than seven years later, version 3.0 of the LSB specification has been released. With this release, the LSB requires the system to have a relatively new compiler and toolchain (gcc-3.4 or newer), adds some libraries and interfaces, and cleans up some obsolete interfaces. There are two core variants of the LSB specification, depending on whether the target system is expected to have graphics capability or not. Sample implementations are available for eight different architectures. The release notes have more details, for those who are curious.

In many circles, however, the LSB 3.0 release is being greeted with a big yawn. Most Linux users probably have a hard time seeing how the LSB benefits them. Ulrich Drepper, who, as maintainer of glibc is faced with a wide range of LSB compliance issues, has recently claimed that the LSB lacks value and should be dropped. It is a rare Linux user who chooses a distribution or application based on its adherence to the LSB.

The stated purpose of the LSB was to encourage the availability of applications - both free and proprietary - for Linux. So it is telling that, among the available Linux applications, very few claim to be targeted at LSB-compliant systems. In fact, your editor found just one beyond the special versions of free applications in the LSB's own application battery: it's Appgen's MyBooks, which works on bleeding-edge LSB-compliant systems like SUSE 8.1 and SCO OpenLinux. In general, application vendors are not targeting the LSB; they are, instead, certifying specific distributions.

Not everybody feels a need for wide availability of proprietary applications for Linux. But, for those who do, the certification of individual distributions is exactly the sort of situation that the LSB was created to prevent. From that standpoint, the LSB would appear to have failed.

That said, the LSB effort has certainly had a positive effect in bringing Linux distributions closer, and in raising awareness among distributors of how their offerings diverge from the standard. Even if an application is not specifically aimed at LSB compliance, the fact that it probably just works on non-certified systems is, at least in part, attributable to the LSB. There is value in separating the core part of a distribution (that which, in some sense, makes it "Linux") from the additional features and services distributors throw in to add value to their offerings. The LSB helps to bring that separation about.

From the moment that Linux started to attract attention outside of the development community, detractors have grumbled that it would fragment in the same way that Unix did. Yet, despite the existence of hundreds of distributions, several of which are widely used, this fragmentation has not happened. Linux applications remain portable, and, just as importantly, switching from one distribution to another is (usually) nearly painless. Linux is Linux, regardless of the distributor. The reasons for this state of affairs include the use of a (more or less) common kernel and application base, and the fact that free licensing makes it easy for good ideas to move quickly from one distribution to another. But there is a place for standards as well. As long as the LSB continues to codify current expectations of what a Linux system should be, it will help to keep the Linux universe coherent.

to post comments

The relevance of the Linux Standard Base

Posted Sep 22, 2005 4:08 UTC (Thu) by kirkengaard (guest, #15022) [Link]

LSB has the Debian problem. If it released often, and truly reflected the state of current Linux components (which change as the developers of those components update them), then it could accurately describe a snapshot Linux distribution, at base expectation levels. People might even use it.

If it focuses too much on nailing down a stable and unified whole, of course it's going to wait forever between releases and lose relevance. The idea behind the LSB's proposed usefulness is predicated on top-down declarative design, when the LSB is actually a descriptive phenomenon of a bottom-up software environment led by component producers and the distributions that graze their output. The LSB, to be effective, needs to do the bleeding-edge grazing that the distributions do, and the distributions need to be able to rely on the immediacy and accuracy of its output.

The relevance of the Linux Standard Base

Posted Sep 22, 2005 11:44 UTC (Thu) by csamuel (✭ supporter ✭, #2624) [Link]

Ironically enough the worst problems I have with running applications across platforms is with java apps from a certain large vendor.

They insist on giving you their own JRE to run it with, and that's caused all sorts of hassles on different distros.

A few reasons LSB hasn't caught on yet...

Posted Sep 22, 2005 14:42 UTC (Thu) by dank (guest, #1865) [Link] (1 responses)

I can think of a few. Let me try to channel Mike Hearn
for a moment:

LSB versions before 3.0 didn't have serious
C++ support. Since most applications are
written in C++, that may be one reason it hasn't
seen much use.

LSB doesn't include support for KDE or Gnome APIs,
and is missing a few X libraries, too, I suspect.
This hurt GUI apps, of course.

LSB requires you to include private versions of
all libraries not in the LSB - i.e. you can't
rely on any other packages. This is a bit of
a shock to the averate Linux developer.

Building LSB packages is a pain, even more so than
building RPM packages, and there is a very small
community of people who have ever built one,
and not a whole lot of documentation on how to do it.

All of these problems are solvable with time and effort.

A few additionnal reasons LSB hasn't caught on yet...

Posted Oct 1, 2005 16:42 UTC (Sat) by renox (guest, #23785) [Link]

Let me add:
- Ulrich Drepper's reasons. Among other: the LSB testsuite is buggy.

He gave the example of the threading of the tests which test threading (got it? :-) ) being buggy.

- For the C++ part, I remember a serious flamewar with GCC developpers which disagreed strongly with the version of the C++ ABI that the LSB guys have chosed.
If in the future the C++ ABI stabilise, this won't be a problem anymore, but I expect to see it right after Duke Nukem Forever is released.

- For the KDE part, the LSB guys objects against Qt's GPL license, they want to recommand only LGPL or BSD licenses for the base library.
Considering that KDE has the majority of users in Linux world, this is a problem..

All this makes a quite long list of problems and I don't expect the LSB to be relevant anytime soon.

The LSB will never do what its supporters hope

Posted Sep 22, 2005 17:47 UTC (Thu) by JoeBuck (subscriber, #2330) [Link]

For companies that ship binaries (whether for a proprietary or open source program) and that are serious about supporting their customers, the LSB will never do what its supporters hope, that is, permit people to ship applications that will work (and be supported) on all LSB-compliant platforms. What will happen instead is that companies will support the top player, or maybe the top two (say, RHEL and Novell), because you can't support what you can't test. There's no way to test "any LSB system", you have to pick a particular one. If an important OS supplier has a bug in its LSB compliance, you still have to work, even though the bug is present.

That doesn't make the LSB useless; by keeping the various distros more similar than they otherwise would be, it makes it more likely that a program will work on an "unsupported" Linux flavor.