October 22, 2016
Hot Topics:

Linux Vendors Team Up to Keep Linux from Splintering

  • May 11, 2000
  • By Paul Korzeniowski
  • Send Email »
  • More Articles »

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."

Page 2 of 2

Comment and Contribute


(Maximum characters: 1200). You have characters left.



Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Sitemap | Contact Us

Thanks for your registration, follow us on our social networks to keep up-to-date
Rocket Fuel