The Linux Standard Base group has been slow to produce a full specification, but it's worth the wait.

Two weeks ago I outlined some of the impediments facing both open source and commercial software developers. The variety of companies and groups that distribute Linux-based operating systems has resulted in myriad file locations, install formats, and other fields within the base operating system. This extreme diversity has kept many developers away from Linux, and has caused others to waste time and resources making multiple versions of applications or installation procedures.

To combat the problem, Linux International created the Linux Standard Base group almost three years ago, with a mandate to develop a single platform specification that developers could target and distributors could implement. The group has hit a number of bumps since then, including a brief (but loud) challenge from the renegade Linux Standards Association in mid-1998 that lasted until the LSA faded away from lack of interest. And the LSB's original plans to create a basic standard that simply dictated revision levels for common components were deemed unworkable.

Since then the LSB has been working on the tough and unsexy tasks of defining a standard, creating a sample implementation, and testing for compliance. According to LSB organizers, the pace has picked up significantly over the last six months, sparked by additional resources from sponsors and by new members like George Kraft from IBM, who now chairs the LSB's technical committee.

The group has already met a number of important milestones:

• Release 1.1 of the Linux Development Platform Specification (LDPS) came out last month. It's a preliminary document designed to allow developers to write code that's easily portable to all major Linux distributions.
• The Linux Internationalization Initiative is working towards global standards that can be used in distributions worldwide, regardless of regional differences.
• Release 2.2 of the Filesystem Hierarchy Standard (FHS) recently came out of beta. This important part of the LSB specifies what files go where. It's already being implemented in many distributions, including Caldera and SuSE, as a stepping stone towards full LSB compliance.
• Most importantly, there's a first shot at a reference implementation of an actual LSB-compliant system. It requires an add-on package that installs on top of the public beta of Caldera's new distribution release. There's plenty more work to be done, but it's a critical first step.

Another welcome addition has been the participation of The Open Group (TOG). Known as X/Open during the Unix Wars, TOG became the custodian of the Unix trademark and is responsible for testing whether an operating system meets the criteria that allow it to be called Unix. In an effort driven by TOG employee Andrew Josey, the group now has provided the LSB with valuable test suites and other resources.

The Open Group's involvement is also good news for those who are interested in bridging the gaps between Linux and Unix standards. While Linux likely will never conform to The Open Group's Unix specifications, cooperation at this level benefits those moving between the Unix and Linux worlds.

So where exactly is the complete LSB specification at this time? Right now it's at version 0.7.4 and moving ahead rapidly. “You will see a successful LSB 1.0 in 2001 or I'll publicly eat my tennis shoe,” Scott McNeil, LSB spokesman, told me.

That's good to hear, because the LSB really needs to have its spec out this year. Waiting three years hasn't really been much of a problem. After all, it's taken that much time for Linux to reach an installed base (not to mention the technical maturity) capable of attracting conventional commercial developers. But as Linux moves further into the computing mainstream, the absence of a standard porting platform forces developers to take matters into their own hands, as I described in my previous column.

I'd especially prefer not to have a situation in which applications companies feel pressed into making their own Linux distributions, specially designed to run their software. This has already happened at least once, in the form of the Japanese Miracle Linux distribution, designed expressly by and for Oracle. Or, worst of all, developers will just shrug their shoulders at the whole perception of Linux fragmentation and not develop for the platform at all.

It's critical for the LSB specification to produce a stable target for Linux developers, especially for vendors of proprietary packages that won't come with source code. While it's important that LSB adherence be optional — not every specialized distribution has the need to run proprietary applications — the existence of a cross-vendor standard will become rapidly accepted throughout the community once it's out.

I know and like many people within the LSB. I like the path it has taken, and I think it has been correct to do it right rather than rush it. Would I have preferred a full spec sooner? Of course–who wouldn't? But in reality, the long wait is acceptable given the pubescent stage of Linux's maturity as a mainstream OS.

Still, there is a limit to patience, and in the absence of a standard, developers will either figure out their own or just stay away — and neither of those options is pleasant. If the LSB doesn't deliver a full spec this year we'll have more to worry about than the taste of Scott McNeil's shoes.

Has the LSB taken too long? Tell Evan in the ZDNet Linux Forum. Or write to Evan directly at [email protected].

 
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.