Author: JT Smith
Everyone agrees that the Free Standards Group’s goal of enhancing software compatibility between the Linux distributions, by using the new 1.1 version of the Linux Standard Base, is a good idea. Now, we’ll see if it actually happens.
In the short term, the idea is to have all LSB-compliant Linux distributions be able to install and run any LSB-complaint program. Eventually, this could lead to Linux program binary compatibility that would enable end-users to install software on
any Linux distribution as easily as they do Excel or Quicken on Windows.
John H. Terpstra, Caldera’s Open Source evangelist, is looking forward to all the Linux companies coming together to make a common Linux binary base because it “will bring sanity and unification to Linux that will encourage independent software vendors to port to the Linux platform.”
The LSB would do this by providing a full set of agreed-upon APIs, development environment, and certification package that will enable Linux independent software vendors (ISV)s to create programs that run on any LSB-certified Linux. This, in turn,
would improve the ISV’s time to market with new Linux software while decreasing development costs.
Thus, as Scott McNeil, the FSG’s executive director, says: “With written guidelines, test suites and build environments, the LSB and Li18nux (a FSG Linux internationalization initiative) create a foundation for language globalization of compliant distributions and applications will give application developers the tools they need to easily reach users world wide.”
It should come as no surprise then that many ISVs support the
LSB. For example, Raja Srinivasan, software architect of Oracle, thinks “LSB and
Li18nux provide a critical stability for Linux.” And, Jeremy Allison, a Samba project leader, believes that “the Linux Standards Base is the next stage needed in moving Linux into the enterprise to replace legacy systems.”
Linux leaders agree. From Linus Torvalds himself: “By using the same Open Source methodology and involving many of the same Free Software programmers, the LSB is a natural extension of Linux into the enterprise.” The LSB effort itself has such Linux/Open Source notables as Alan Cox, Eric Raymond and Theodore Tso
working and commenting on it.
Other service and hardware vendors who want to see Linux succeed commercially, like IBM, Dell and Hewlett-Packard, are also lending the LSB support.
But, for all this, the LSB is still a work in progress. Disagreements on such fundamentals as what should be placed, and what shouldn’t, in the /proc directory still happen. And the LSB Test Suite, while it made great progress in 2001, is still in beta.
Many Linux users also still misunderstand the LSB. The LSB demands that its compliant operating systems should have a select set of APIs, programs, directory framework and libraries. It does not, however, exclude other such programming constructs so long as they don’t conflict with LSB’s framework.
So, for example, on Slashdot recently, there was a discussion where some thought that because the LSB mandates the RPM program distribution package format for third-party software distribution, other such packages, like Debian’s DPKG, would no
longer be supported on LSB 1.1-compliant systems. That simply isn’t true, say FSG advocates. While it is possible, if LSB 1.1 becomes very popular, that non-LSB supported constructs like DPKG could fade into disuse, the LSB is about providing a minimal programming framework for third-party software, not excluding other frameworks.
Another problem is that, except for Caldera, LSB is seen as being more honored by lip service than by programming work by the Linux distribution companies. While the other major players, Debian, Mandrake, Red Hat, SuSE and Turbolinux, are on board with LSB, some critics question their level of commitment to the standard. Only time will tell if LSB certification will become the key element in Linux’s commercial success or just another three-letter acronym on the box.