GuidesLinux Vendors Team Up to Keep Linux from Splintering

Linux Vendors Team Up to Keep Linux from Splintering

Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

"There are at least 15 English-language distributions of the Linux operating system for the Intel platform–and none of them are exactly alike.
"

When Burst.com Inc. decided to port its software to Linux, the company ran head-on into a dilemma: which distribution to run the firm’s software on. That’s because the San Francisco, Calif. streaming media software supplier quickly discovered–as have many other independent software vendors–that it couldn’t just port its code once and have it run on all flavors of Linux. The differences between the various Linux distributions meant that a separate porting effort would be required for each one.

Burst.com solved its dilemma by porting its software only to Red Hat Inc.’s Linux, forgoing ports to other Linux versions for the moment. "Obviously it would be simpler for us if all Linux distributions supported a common set of features," says Kyle Faulkner, chief technology officer at the company.

That wish may soon be granted. A new ad hoc consortium, the Free Standards Group, is outlining a common set of features that will enable application software to run on all Linux distributions without being recompiled. The group, which brings together two existing Linux standards efforts, the Linux Standard Base (LSB) and the Linux Internationalization Initiative (LI18NUX), expects the first fruits of those efforts to emerge later this year.

The problem carries a touch of irony. When the operating system first started to gain attention, application portability was viewed as one of its major selling points. Unlike Unix vendors, Linux distributors all work with the same operating system kernel, which should have enabled third parties to run their applications on various distributions with little or no effort.


No two alike

To date, that hasn’t been the case. There are at least 15 English-language distributions of the Linux operating system for the Intel platform–and none of them are exactly alike. Though each starts with a version of the same source code, their differences are such that there is no guarantee that a commercial application will run on all of them.

So, independent software vendors often have to test and tweak their products to get them to work on different distributions, and users have to worry about whether or not a new product will run on their systems. "Distribution inconsistencies are one of the reasons why Linux has not attracted more attention from ISVs," says Bill Claybrook, a research director for Linux and open source software at the Aberdeen Group, a Boston market research firm.

Operating systems rely upon shared libraries to provide applications with standard functions and utilities. Linux distributions usually include a handful of libraries, such as glibc, libm, and ncurses. Applications that are compiled with a given version of a shared library expect to find that specific library at runtime.

Unfortunately, that may not happen every time. For instance, glibc, the GNU C programming language libraries used to compile applications on most current versions of Linux, are often version-sensitive. Some distributions rely on a Linux C library called libc5, while many others have adopted the Free Software Foundation’s GNU libc 2.0, and applications designed for one will not run on the other. Also, various X Window shared libraries depend on the presence of specific C libraries.

Dealing with these sorts of problems complicates the porting process for software developers. "The more variations there are in operating system libraries, the more difficult it becomes for us to develop software for Linux," said Kris Magnussen, an open source architect at Novell Inc., in Provo, Utah.

There are other issues as well. The procedures for installing Linux, for example, vary between different distributions. The Red Hat Package Manager has been widely adopted, but Debian Inc. and Corel Corp. rely on Debian’s installation package format, and Slackware uses compressed tar archives.


Developing standards

"Unix vendors viewed the operating system as a way to sell more server
hardware and didn’t always pursue what was best for the operating system.
"

The Free Standards Group is trying to solve the problem by defining a standard set of guidelines and application programming interfaces (APIs) so developers can deliver products that will execute on all systems. The group combines the efforts of two autonomous Linux standards bodies: the Linux Standard Base (LSB), which was formed in 1998 and focused on increasing compatibility among Linux distributions so software applications would run on any compliant Linux system, and the Linux Internationalization Initiative (LI18NUX), which began in the fall of 1999 to try to insure that Linux software and applications could easily run in various countries.

The ad hoc committee’s initial emphasis is on a standard set of services, such as shared libraries, system commands, file system hierarchy, system initialization process, and scripts. The group’s goals are to assure cross-distribution operation and backward compatibility of Linux applications without impeding innovation.

To meet these goals, the LSB component defines a set of shared libraries as part of the base distribution and gives them unique names that identify them as LSB-compliant libraries. For example, the LSB version of libcrypt might be libcrypt.lsb.1. This naming convention establishes a known set of library definitions which application developers and vendors can depend on.

The separate naming convention also prevents installation programs from overwriting LSB-compliant libraries with new versions of the same library. If, for instance, a Linux provider included a version of libcrypt that provides new features added since libcrypt.lsb.1, it would be added to the library directory using a non-LSB naming convention such as libcrypt.so.1.2. This file may replace libcrypt.so.1.1, but it would not replace libcrypt.lsb.1. This insures that the new features are available to applications that need them without interfering with applications that rely on LSB libraries.

The fruits of this movement may be harvested quickly. "A number of LSB committee members have been trying to come up with common APIs for more than two years, so I expect us to have a 1.0 version of standard in place by the fall," says Dan Quinlan, chairman of the Free Standards Group.

In addition to the APIs, the consortium plans to deliver a test suite that measures LSB compliance and a sample open source LSB implementation that third parties can use as a starting point for product development or testing. The work has garnered support from more than two dozen Linux vendors, including Caldera Inc., Corel, Debian, IBM, LinuxCare Inc., Turbolinux Inc., Red Hat, and VA Linux Inc. "All of the major Linux distributors view adoption of standard interfaces as necessary for themselves as well as the community," says Benoy Tamang, vice president of marketing at Caldera in Orem, Utah.

Theoretically, vendors like Caldera and Red Hat will incorporate that support in their distributions and third party ISVs will develop compliant applications so incompatibility issues will disappear. However, that dream will probably never be fully realized. The specification leaves room for vendors to differentiate their wares by incorporating proprietary add-on features such as clustering, and applications written to take advantage of these features will run only on distributions with those features.

If the add-on features are widely accepted, they could someday be incorporated into LSB. "I don’t see a lot of changes being made to the LSB specification once it’s completed," says Quinlan. "Developers don’t want to work with a moving target; they want a specification that will be stable for a while."

So, distribution inconsistencies will continue to be a byproduct of the communal nature of open source products. However, LSB adoption should represent a significant improvement to current portability problems and a dramatic difference from the Unix wars of the 1980s, where attempts to consolidate proprietary interfaces consistently failed.

"Unix vendors viewed the operating system as a way to sell more server hardware and didn’t always pursue what was best for the operating system," says Aberdeen Group’s Claybrook. "That isn’t the case with Linux. For it to thrive, third party support is needed and LSB adoption should help attract it."

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories