Articles / Editorial: Alan Cox

Editorial: Alan Cox

Alan Cox, infamous kernel hacker and Red Hat employee, gives us his valuable opionion about the Linux Standard Base Project. He once again debates the packaging issue and states one important fact: Nobody is forced to make any use out of the LSB. If you don't like it, just don't use it. "There you are minding your own business and along comes someone to tell you how to run it..."

Thats the backside of a standardisation project. It is also the first step to the failure of any standardisation project and to fragmentation. In that way standardising something if it fails can actually be worse than pretending it doesn't need doing.

I'm sure the LSB will upset a few people somewhere as it redefines some cherished icons. The file system standard broke a couple of eggs - how many Linux people who first met Unix in the SunOS/BSD4.x format remember cursing the changes in Linux to use /etc/rc.3/S99* file formats and the long rumbling argument about just where users email really went ?

One thing the LSB is trying to do is to step on as few feet as possible. In most areas this is suprisingly easy to do. Because the LSB is about being able to install and use programs not about what user tools you get it can neatly sidestep the thirty odd year old editor war. It doesn't matter if you have vi or emacs when you install "quake 4, the ultimate massacre".

Thus the LSB is an exercise in minimalism. Every time someone thinks "we should standardise this" , the most important question is "Do we need to". Sometimes we can't avoid it - there really does have to be a single packaging standard. Right now it will probably be rpmlike. It may even be RPM but there are many things to discuss yet.

So how do we minimise the impact. Firstly the LSB wants to specify the format, and a command line interface but not the tools. Secondly to specify it only as an install format for LSB packages. If it happens to be RPM format it doesn't mean Debian has to throw away dpkg. Alien has already proved the package format conversion part of the problem is trivial.

If you want to get a good feel for what sort of issues the LSB has to solve take 10 debian packages, convert them with alien and try and run them on Red Hat (or vice versa). It's a great exercise in "almost" not being good enough, and I hope a good answer to the people who think the standard is an un-neccessary infringement of their freedom. The file system standard was a great beginning but as Linux moves into the mainstream userbase where questions like "What is a compiler" are not uncommon we need to go further.

Many things that need specifying can be done without involving applications. The entire Gnome/KDE bonfire thankfully falls well outside of the LSB. Applications need to be able to tell the window managers and desktops what icon to use and what name and category apply. What happens after that really isn't our problem.

To me at least the final success of the LSB will be measured on how much it manages to avoid specifying rather than how much it manages to specify.

And my final message to the doubters is this: The LSB will take nothing away from people. If you want to do things your own way, override the installer and fix the configuration files by hand the way you like it - go ahead. The LSB is only a Linux standard, nobody will come and kick down your door for not following it. I think most people will find however that life after the LSB is a whole lot simpler - commercial vendors, users and even free software authors.

Alan Cox

Comments can be posted to the LSB Forum.

RSS Recent comments

23 Nov 2007 04:27 johnevo

LSB
Excellant read & something to think about

john

Screenshot

Project Spotlight

JSXGraph

A cross-browser library for plotting and interactive geometry.

Screenshot

Project Spotlight

pynag

A Nagios plug-in and configuration library for Python.