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. - Sockets
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. - X11
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. - ELF
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.
Outlook
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.
|