Aberdeen InSight: Linux Gets A Boost From Standards

Linux Gets a Boost – Standards
Linux has the fastest market growth rate of any operating system (OS) in the world, and it is being developed faster than any OS in history. However, for Linux to move into the enterprise and serve as the
host for enterprise applications, a set of common standards is needed. Without standards and common application
programming interfaces (APIs), independent software vendors (ISVs) and other developers must decide which of the
more than 250 Linux distributions to target for hosting their applications.


On the upside, standards will bring
a greater market share for Linux, allowing for its continuing growth. Developers, distributors, ISVs, systems vendors,
and especially users will surely benefit.

In response to the need for Linux standards, the Free Standards Group (FSG) has initiated two
key projects – the Linux Standard Base (LSB) and the Linux Internationalization Standard (Li18nux). The LSB provides
binary and behavioral protocols that increase compatibility among Linux distributions; it also enables LSB-compliant
applications to run on any LSB-compliant Linux distribution. Li18nux is a standard for creating a foundation for
language globalization of Linux-compliant distributions and applications.

Note that LSB 1.1 compliance and Li18nux 1.0 compliance are two separate concepts. Thus, a distribution
can be LSB 1.1 compliant without being Li18nux 1.0 compliant – and vice versa. (The focus in this InSight is LSB 1.1.)

Related Stories

Network and Systems Software Product of the Year 2001: Enterprise users give Red Hat Linux their approval

Linux Gains Legitimacy in the Enterprise

Linux Breathes New Life Into The Mainframe

Who’s Afraid of Linux?

The FSG Workgroups for LSB 1.1 and Li18nux 1.0 will deliver complete, written documentation articulating
what is needed to make Linux distributions and other Linux-based software compliant. In addition, they will deliver
compliance test suites for each standard. For additional LSB and Li18nux information, see www.freestandards.org.

The FSG is an independent, non-profit organization dedicated to accelerating the use and acceptance
of open source technologies through the development and promotion of standards. The FSG is backed by important
industry leaders including Caldera, Compaq, Debian, Dell, Hewlett-Packard (HP), Hitachi, IBM, Intel, Oracle, Red
Hat, Sun, SuSE, Turbolinux, and key members of the open source development community.

Motivation for Linux Standards

For the past several years, ISVs have struggled with the task of porting their applications to
multiple OS platforms including several Unix/RISC platforms. Porting efforts are often time-consuming and costly.
Once a port is completed, the ISV must support it.

More Aberdeen InSights

Linux-Based Software Management

New Opportunities In Microsoft’s CRM Push

Monitor a New
Point of View – The Customer’s

CIOs’ Top Application Investment Priorities for 2002

Will WideSky Help EMC Morph from Caterpillar to Butterfly?

ISVs want access to as many markets as possible, but they do not want to repeat the Unix/RISC
phenomena – making multiple ports to Linux. ISVs want to do a single port to Linux that will run on many Linux

Red Hat is the largest Linux distributor by far, but other distributions find significant favor
in many geographical sectors around the world. The LSB may be interpreted by some as a way to “level the playing
field” for distributors, but the real significance of the LSB rests in making long-term enterprise Linux deployments

Linux Standard Base 1.1

LSB 1.1 standardizes the core functionality of Linux and core/primary libraries. A Linux distribution will be viewed post-LSB 1.1 this way: At the lowest level are the Linux kernel, drivers, and hardware
(architecture)-specific code. None of this code is directly affected by LSB 1.1.

Above the Linux kernel is the LSB component. It also contains some hardware-specific code. The
LSB component is expected to grow over time with the addition of libraries, e.g., C++, but only those that are stable (subject to infrequent change) will be added to the LSB component.

LSB 1.1 defines an Application Binary Interface (ABI), which is very similar to the POSIX.1 and
POSIX.2 source specifications. The LSBs ABI defines the API for developers to program to, and it includes runtime
definitions for binary compatibility.

Presently, an LSB-compliant Linux distribution must supply 15 specific libraries that define
the ABIs. What LSB 1.1 does not define, applications must not use. For example, the vi (1) editor is not LSB-defined
or LSB-compliant; therefore, it should not be called, via popen, by an application (“popen” is a system call that
opens a pipe to a process).

Outside the bounds of the Linux distribution, but with direct access to the LSB-specified ABI,
are the development tool kit, commercial applications, etc. One of the features of compliant development tools
is that they will restrict potential missteps in developing compliant applications.

Today, the GNU tool kit, which includes the gcc compiler, is the only tool kit that has been
adopted for the development of compliant applications and middleware. In the future, however, other tool kits could
be shown to be compatible for developing compliant applications.

Any software package or library that is not specifically included in the LSB 1.1 specification
is considered to be outside the scope of the standard. Adding a non-conforming package to an otherwise conforming
Linux distribution does not prevent the distribution from conforming, unless the package removes or replaces a
conforming part of the distribution.

If an application developer goes outside the LSB ABI, there are special rules to follow. These
rules may require the application developer to static-link modules or bundle them with the application to attain

LSB Certification

The LSB certification program is currently under development; therefore, some of the information
provided below may differ slightly from the final published details. LSB 1.1 specifies separate sets of compliance
test suites for Linux distributions, Linux applications, and Linux build environments. The LSB Workgroup is responsible
for developing the test suites and making them available.

For application testing, the LSB checks to determine if the applications are using only LSB-specified
ABIs and libraries, the LSB runtime linker, and executable and linking format (ELF). In addition, a set of Filesystem
Hierarchy Standard (FHS) questions is asked about the installation of the application. Lastly, the application
is required to be tested to work on the LSB Sample Implementation (a minimal Linux system that contains mostly
just what is specified by the LSB) and two LSB-compliant distributions.

ISVs and other application developers can get a preview of the types of problems that they may
encounter in becoming LSB-compliant by running their application(s) on an LSB-compliant distribution (or the LSB
Sample Implementation) and examining the “error” reports.