I was honored to give a keynote address at Linux Business Expo at Networld+Interop this year in Atlanta (see
Resources for a link). Unfortunately, due to an administrative mix-up, no one had posted signs for the keynote, so only a handful of people showed up. Red Hat's Bob Young had the same problem for his keynote, which took place the day before. Nevertheless, I tried to drill home my message to the few who attended.
My goal is simple. I'm out to drum up some support for Linux Standard Base, and I'm also out to give LSB a serious kick in the keister. (It is also my goal to chew some bubblegum, but I'm all out of bubblegum.)
My first message was to encourage others to support LSB. But by support I don't just mean to contribute to the project, although that is very important. I am also calling for the Linux community to shame LSB's mother organization, the Free Standards Group, into hiring a solid leader to get LSB moving, or to shame the existing leadership into getting off its collective bum and producing a comprehensive specification and a self-hosting sample implementation in our lifetime. And by comprehensive, I mean a spec that is encompassing enough to build sophisticated graphical applications. What I most certainly do not mean is the pathetic minimal standard slated for the LSB 1.0 specification. That way lies irrelevance.
After almost three years, the most significant visible achievement of LSB is a beta specification called the Linux Development Platform Specification (LDPS). LDPS is a paltry 1,800 words describing an inadequate set of building blocks for Linux applications. The specification itself is so simplistic that I was able to duplicate almost the entire list of requirements, version for version, in less than two minutes by asking the audience commonsense questions. Now, consider that there were only two or three Linux programmers in the audience!
It's even more embarrassing that LDPS does not provide accurate information about achieving its goal. For example, the specification lists several distributions that comply with LDPS. But those distributions do not in fact fully comply with even the tiny list of requirements LDPS covers. None of the distributions listed that I have used completely adhere to the Filesystem Hierarchy Standard 2.1, for example.
And in areas of the specification where distributions do comply, that compliance does not always solve the problem of compatibility. For instance, LDPS establishes the meaningless requirement that a distribution must include either ncurses version 4 or ncurses version 5. But distributions that include version 4 will have incompatibilities with programs compiled for version 5, and vice versa.
In short, both LDPS and the general LSB specification should identify many more pieces of the system than they do. The specifications should not pander to existing distributions, but require only those software versions that most benefit users and administrators. And then LSB should be aggressive about forcing distributions to update their products to conform.
And therein lies the problem: LSB has shown a total lack of aggression and willingness to be active. In fact, all of LSB's problems seem to stem from passive and inactive leadership. That is one reason I got frustrated and have stopped participating in LSB for a few months. (I'm attempting to become active in LSB once again now, which is the reason I'm trying to stimulate some change.) It's also why I suggested a few weeks ago that LSB participant Scott McNeil should take over the project. LSB has more than enough talent and technical heroes. But it also takes forceful action to push a specification forward, and it takes more of the same to make that specification clear and comprehensive, and ensure that distributions come into line. Scott has that to offer. And that's what LSB currently lacks.
The passive approach LSB now takes may please the distributions and members of the Linux community who are sensitive to being told which standards they should use. But Linux deserves better. And LSB no longer has any legitimate reason not to deliver better. Until recently, LSB defended its passive approach by saying that there weren't enough resources to lead Linux forward, that there were only enough to document what exists. The Open Source Development Labs, which vendors are ready to pour millions of dollars into, should solve that problem, leaving LSB without any more excuses.
So as of now, LSB, you are on notice. Get a leader, or get out of the way.
Learning from Debian
Debian is teaching me some things about how the evolving LSB standard should change course. (I really shouldn't use the word evolving, as it may encourage LSB to take a few million years more to produce its specification, but I think I've made that point well enough already.)
But before I tie together LSB and Debian, I should share how I got to this point. I'll explain how this topic ties in to LSB in a future column, because it deserves its own space.
First, I need to say thank you to Joe Barr for his excellent column on installing Debian 2.1. A lot of Debian fans were seriously bent out of shape because Joe tested an old version of Debian, but that error should serve as a lesson to VA Linux, which is a big supporter of Debian. VA dumped a few crates of Debian boxes on the show floor at LinuxWorld Expo in August in San Jose and gave them away for free. That's where Joe got his copy. The problem is that VA gave away those out-of-date boxes on the same day that Debian announced its 2.2 (aka Potato) release. If VA really wanted people to enjoy the benefits of the latest version, it should have mass-produced copies of Potato install disks and given those away.
All right, it's not quite as simple as that, but please spare me your nit-picking letters, since this matter was already discussed to death on the LinuxWorld forums. Besides, I'm becoming a fan of Debian anyway, although I'm not nearly as religious about it as many Debian fans seem to be.
But since I had pretty much the same experience as Joe, the reaction by Debian fans to the column inspired me to take a look at Debian again. So I'm getting to know Debian by using Storm Linux 2000, which is based on Debian 2.2. (I tried to install Corel's latest version of Linux on my notebook computer, but all it does is spit out the CD-ROM and reboot -- after which it convinces my notebook that it doesn't have a hard drive. I'll put Corel on my workstation as soon as I can.)
At first I had some real problems with Storm Linux, but most of them turned out to be my own fault. As Debian fan and expert (and LinuxWorld author) Rick Moen pointed out, I complicated my problems by not thinking like a Debian user. For example, I used the alien utility to convert some RPM packages into .deb format when I couldn't find native Debian packages to install.
I don't feel guilty for making this mistake. At first I was more interested in getting Debian working than learning a new philosophy. I had work to do, after all. But Rick was right in principle.
So once I felt comfortable enough using Debian, I installed Storm Linux 2000 again from scratch, this time confining all my installation of packages to the Debian apt-get, apt-cdrom, and dpkg commands whenever possible.
Then I installed Storm Linux 2000 on my notebook. That was a bit of a nightmare, but only because of XFree86. I know how to get XFree86 3.3.6 working with my notebook, but only if I have a kernel that supports frame buffers. Rather than recompile the kernel, I tried to get Storm Linux working with XFree86 4 on my notebook. But I couldn't get the cyberblade/i1 video driver working at all.
So I installed the Mandrake 7.2 beta instead. To my surprise, I couldn't get XFree86 4 working with Mandrake 7.2, either. That surprised me, because Mandrake 7.1 works beautifully on the same notebook. In retrospect, I suspect that the difference is actually between XFree86 4.0 (which Mandrake 7.1 uses) and XFree86 4.0.1 (which is what I used on Mandrake 7.2b and Storm Linux 2000 -- although I had to get unofficial packages to make it run on Storm). The Trident cyberblade/i1 driver must have broken between XFree86 4.0 and XFree86 4.0.1.
My final solution was to install Storm Linux 2000 again and recompile the kernel to support frame buffers. The only problem I encountered was that Storm Linux doesn't install the bin86 package by default, which is necessary to recompile the kernel on an x86 platform.
Now that I've been running Storm for a while, I must admit that there is a lot to be said for using apt-get to install and upgrade Linux packages. It isn't enough yet to make me switch from my beloved Caldera Linux Technology Preview or the flaky but enjoyable Mandrake 7.2b, but it's close.
Rather, I'd like to make a pitch for a hybrid method of installing and upgrading packages. And I'd like to suggest this hybrid as the standard that LSB should promote. Which, as I said, is a whole 'nother column. Stay tuned.
Resources
