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.)
Network and Systems Software Product of the Year 2001: Enterprise users give Red Hat Linux their approval
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 distributions.
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 possible.
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 compliance.
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.