The project was initiated in 1998 under the chairmanship of Bruce Perens, with the aim of preventing Unix's fragmentation from spilling over into Linux. In 2000, the LSB and LI18NUX projects joined to form the FSG, and efforts over the next four years culminated in the release of the LSB 2.0.
One of the primary motivating factors in all this has been the desires of ISVs to have a single unified scheme for porting, testing and certifying applications on Linux. With Unix, ISVs were forced to create a new port for every version, an expensive proposition; it is no surprise that Unix market share is steadily giving way to Windows and Linux.
"There was a big problem with the level of forking in the Unix community," says Red Hat analyst relations manager Nick Carr. "Applications wouldn't move around under any circumstances. It's not that it would take three months to port, it was that it wasn't going to happen."
The LSB builds on earlier efforts that attempted to prevent Unix fragmentation, such as the Portable Operating System Interface (POSIX) and the Single Unix Specification (SUS); it uses some of POSIX's source code standards and SUS' interface definitions. POSIX only defines programming interfaces and doesn't guarantee binary compatibility, while standards such as OSF/1, which aim for binary compatibility, were found to be too restrictive. The LSB aims to strike a balance between the two approaches -- it includes a binary compatibility layer, but isn't as restrictive as OSF/1.
The aim of the LSB isn't to create a single, monolithic Linux operating system, but to allow different LSB-compliant distributions to differentiate from the competition, while still running any LSB-compliant application.
LSB 2.0 was formed largely by ISV feedback, says FSG's Zemlin. Vendors wanted the specification to cover more of the libraries used in building applications, such components as additional runtime environments, cryptography, XML, PERL, PHP and Java. Version 2.0 added several significant features, such as support for SUS and an application binary interface for C++.
The standardisation project is necessary if application vendors and end users are to feel comfortable choosing open-source over a proprietary option, says Zemlin. "Without the standard, writing applications to multiple flavours of Linux becomes costly. By supporting the LSB, ISVs will achieve interoperability with a full range of Linux distributions, thereby reducing their costs for development and testing of their applications," he says. "Most significantly, the LSB brings assurance to Linux end users that they will have a broad choice of independent software for Linux."
Continued ...
4%
1%
Fragmentation is not the danger, the danger is huge companies like Microsoft pouring millions of dollars into marketing campaigns and legal action to cripple linux.