Why Linux Standard Base 2.0 won't matter

by Kyle Rankin

Related link: http://refspecs.freestandards.org/lsb.shtml

The latest version of the LSB has been released, and already there are some news sites discussing what it brings to the table with major companies giving their "we love standards" quote.

Personally, I applaud the efforts of the LSB, and even though I don't always agree with some decisions the group makes, I still think it's better on the whole for everyone to try to stick to the standards when possible.

I say all this to say that even if (and I haven't pored through LSB 2.0 yet) the LSB has some great new ideas in it, my fear is that it still won't really matter or be relevant for much of its audience because of many of the same problems that plague other standards.

For a standard to have teeth, people need to not only design their systems based on the standard, but also tout their compliance with the standard. We have seen this problem with HTML. Although HTML compliance is much better now than it has been, for a long time sites all across the Internet were littered with the "Designed for IE" or "Designed for Netscape" gifs.

For the life of the LSB much of the same thing has gone on. Certainly most major distributions now conform to the LSB and to a degree make a point to advertise the fact (especially to us in the Linux community). However, for the LSB to really have teeth, companies who develop their own software for Linux need to be touting LSB compliance, yet many don't. Why? It's not the LSB's fault. I lay most of the blame at the feet of two companies who really should know better--Redhat and SUSE.

Linux use, particularly in the server market, has really taken off in the past few years with Redhat and SUSE leading the pack with many Linux migration stories and lucrative contracts with large businesses. Both distributions do "get it" in terms of the benefits of adopting the LSB and both do comply with the standards, yet when a 3rd party wants to develop software for Linux, and Redhat or SUSE collaborates with them what do you get? A "compatible with Redhat X.Y" or "compatible with SUSE version X" label.

Why do you see this and not "compatible with LSB X.Y?" Branding. Both companies would love to be synonymous with the word "Linux" and for some time, at least in the United States, Redhat achieved that goal in the minds of the corporate market.

This spring I attended a talk with a Novell representative at Penguicon 2.0 and asked whether Novell's ownership of SUSE now meant that we would see them push for 3rd parties to adopt the LSB as a standard instead of SUSE. The answer was PR-speak for "no" and his tone reminded me of the way a Sun rep might answer when asked if Java will be Open Sourced.

I understand both of these companies need to make money to survive, but their branding not only causes annoyances (such as 3rd party software binding itself to particular kernel versions in particular distributions) but in effect makes the LSB carry little weight.

There seems to be no reason to think this practice is going to change any time soon, and since 3rd parties just don't have the resources to support every distribution and aren't being told to conform to the LSB instead of a particular distribution, the LSB will continue to be a great thing for companies to point to when the talk turns to Linux standards while continuing to carry little real weight where it matters.


2004-09-13 21:56:27
What LSB compatible really means
As a third-party developer trying to port some software to Linux (written in wxPython), I thought LSB would be a great way to support a lot of distros with one binary. Unfortunately, what I learned is that LSB doesn't do nearly enough to make this a reality.

To understand why, you have to realize that the LSB only covers a small number of standard libraries, up to X11. If you link *only* to these libraries, your software will be portable across distros. But, what if you need to link to Qt? GTK? wxWidgets? None of these things are covered by the LSB, and vendors do not build their copies of these software to be LSB compatible.

So, to make my software portable, I'd need to include my own copies of: glib, GTK, wxGTK, Mozilla, SWISH-E, etc. I'd have almost a mini-distro of software to include just for portability purposes. The other solution, building individual packages, is a pain, but it can be done quickly and mostly be automated.

I'd love to see portable binaries become a reality, but I don't see it happening anytime in the near (or possibly distant) future, and I do think that's a real shame.

2004-09-14 07:54:24
LSB 1.x was ignored because it didn't have C++. LSB 2.0 does.
LSB prior to 2.0 was not terribly useful in
practice for most software vendors because
it didn't cover C++. (It couldn't -- gcc's
C++ ABI had not yet been finished.)

LSB 2.0 fixes that, but only if you compile with
the special copy of g++-3.2.2 that comes with
the free LSB 2.0 development kit. Apps that
require newer versions of g++ will have to wait
for the next version of LSB.

That's one big barrier out of the way. The next
problem for adoption is that GUI libraries are
not yet part of the LSB. Therefore no Gnome or
KDE apps can be LSB-conformant yet. This makes
sense because Gnome and KDE are still evolving
rapidly, and it makes no sense to try to freeze
them into a standard.

Plain old X apps are fine, though; LSB-2.0
compliant versions of xpaint and xpdf are
available. Thus the Mozilla and OpenOffice
projects could produce LSB-2.0 compliant
versions if they liked, simply by avoiding the
use of the Gnome and KDE libraries. It would
be useful for them to do so, as it would
help clarify how the LSB needs to be improved
in its next release.

2004-09-14 10:58:46
wrong direction
Companies have always written standards and then not conformed to them. That's just normal. For example almost every working group in the w3c has multiple corporations who feel they are stake holders in a given technology sitting on that technologies working committe. Yet as you point out IE, Mozilla, Opera, Safari etc... all have different implementations of HTML / DOM / EMCAScript etc. There is a reason for this. The company involved in drafting the standard has a conflicting interest, marginalize competitors, or as some of the more optimistic companies would say "to innovate beyond the standard".

Companies don't drive the implementation of standards. No matter how well intentioned the guy on the working group, companies have to differentiate themselves from other companies. Consumers drive standards. It took tons of web programmers complaining endlessly about having to write 2 to 3 times the amount of code neccesary to get browser manufactures to at least begin conforming to w3c standards.

If you want LSB 2.0 to mean something you have to demand to oracle that 10g run on all LSB 2.0 distros. Programmers have to stop using Linucies that don't conform and pressure the companies who say they do conform to really conform. Also might be a good idea to organize a users group in the same spirit as http://www.webstandards.org.

Or you're right, it won't matter.

2004-09-14 16:30:27
Portable Binaries
The LSB 2.0 is good news. Reigning in the distros is a problem though, and will likely to continue to be a problem as the fight for marketshare intensifies.

I'm not worried about another Microsoft. Computational consumers are well aware of that danger, and increasingly are requiring compliance with open standards as the fundamental threshold of consideration. The truth is that Microsoft has forever poisoned the water. Sun, IBM, Red Hat, and Novell will have to learn to live with that reality.

As proof of this reality, please refer to the recent EU announcement, “EU eGovernment policy-makers encourage the uptake of open document formats” at:


There is a surprising awareness amongst computational consumers of how important open standards, open source, and open XML technologies are. Proprietary vendors routinely use their participation in these efforts to either enter markets or get a leg up on their competition. All of which makes the “open mime” even more important. The problem of course is that of matching the rhetoric to the reality of products delivered. When it comes to transparency, proprietary vendors are more often than not lacking.

I truly believe though that we are at a unique point of marketplace awareness. The open source stack has moved from the Internet platform, to the universal operating system (GNU/LiNUX), and now to the application layer.

It's important to note that the core of this application layer is actually a portable application environment built around OpenOffice.org and Mozilla.org. I say environment because of the the OOo UNO component model, and the Mozilla Xpcom – XUL model. This isn't just a portable rich client for end users. It's also a portable application environment that developers can target.

OOo and Mozilla ship with run time engines and binary libraries that are reliably managed and maintained by the open source communities. Because of the UNO bridge model, OOo ships with both Java and Python environments. While it would be a good idea to throw in NetBeans, which has a very robust class library, plans are underway to extend the UNO bridgeway to include JavaScript, XUL, and MONO.

This might not be the portable binary model most people desire, but it's being downloaded and deployed at a significant rate. A recent cross community cooperative was initiated, the MozOO project. MozOO aims to create an integrated install based on the core of OOo and Mozilla, but extended to include other necessary desktop productivity tools such as Mozquito (SVG), SunBird (calendar) and NVU composer to round out the package.

The OOo OpenStack project will try to extend the MozOO effort and target developers. This would include an integrated version of the Sleepycat XML/Object/Relational DB, as well as richer subsets of the portable run time environments. The idea being to get above the distro level (including the many versions of Windows), and provide developers with a managed portable application environment they can reliably target without having to worry about shifting dependencies, version controls, and the problematic dilemma of end users having to manage their own systems.

Of course, what's so noticeably missing from the OpenStack design is a worthy replacement for OutLook and Access. At the recent LinuxWorld Expo we heard time and again from Windows based IT and consulting provisioner's that these replacements were the only thing holding back a mass migration to OOo and Mozilla.org. The Chandler Project ships with Sleepycat, and looks to be the missing link, but the project is a long way off.

Microsoft was able to block attempts by Netscape and Sun (Java) to establish an application environment on Windows not controlled by Redmond. I don't think they can similarly stop the explosive combination of OpenOffice.org and Mozilla.org. But it will have to be an open source community cooperative that actually delivers the goods. The GNU/LiNUX vendors each offer their own integrated stack solutions, built on the OOo/Moz application core. They offer their integrated stack solutions as alternatives to Windows. The MozOO and OpenStack Projects have something else in mind. A migration path to open source that promises to get above the bickering entrapments of the distros.


2004-09-15 12:41:07
Why doesn't the LSB group abide by *their* own standards?
It says the LSB package management system is .rpm:

  • http://www.linuxbase.org/spec//book/Packaging/Packaging.html#PACKAGEFMT

Yet, they are running Debian (.deb):

  • http://uptime.netcraft.com/up/graph?site=www.linuxbase.org

Their other sites are also running on Debian:

  • http://uptime.netcraft.com/up/hosted?netname=NETSW-207-235-77-144-28,,

The LSB group should kindly include Debian in the LSB package
management system spec.

For the record, package management in Debian has always been superior
to RPM based distros. (This is not a fanatic comment, it's true)

2004-10-11 07:12:33
Why doesn't the LSB group abide by *their* own standards?
Is there an actual problem here? Debian systems run LSB code just fine. All it takes is "apt-get install lsb" to set up. The LSB spec only requires the ability to install an rpm-format package, not that a distro be based on rpm. That was a long-ago compromise; basically Debian can handle rpms while rpm-based systems are far less likely to handle .debs.