The LSB is a set of guidelines on how you should program for Linux. You don't have to obey its rules. It's just a really good idea if you do.
This isn't just a truism. Thanks to Unix, we know exactly what happens when everyone does things their own way on the same system: utter chaos. Even if you were on the same hardware and used the same basic Unix you ended up with a mess. For example, UHC, Consensys, Interactive, and Dell (yes, the Dell you're thinking about), briefly all had their own versions of Unix SVR4 (System V Release 4) on i386 processors. You could no more run a program designed for UHC Unix on Dell's Unix than you could run a Toyota Prius on diesel fuel.
It was partly because of that that Unix never amounted to much on low-end servers and the desktop. Linux, however, learned from those mistakes.
One of those lessons is the LSB. Linux developers aren't idiots. They saw what has happened to Unix and they know if they follow a similar path instead of leading the Linux distribution pack, they'll end up as technology history trivia the same way almost all the x86 Unix vendors did.
That's exactly the point of the LSB, Ted T'so, a leading Linux kernel developer and the LSB's chief architect, said in a recent interview with James Turner. "The major people who benefit from it are ISVs, independent software vendors, who will be able to save costs by not having to release different product images for different Linux distributions. Back in the late '80s when we had the Unix wars it's been commonly accepted that one of the reasons why Microsoft was able to take over the desktop was that there was no standard ABI (application binary interface) and so software vendors that wanted to release products for Unix had to do so on half a dozen to a dozen different splintered Unix variants. And that cost a huge amount of money or they could just simply release on Windows. And so one of the reasons why the LSB was formed was to avoid a repeat of that situation."
Specifically, what this newest LSB brings to the table, according to the Linux Foundation release, "is a new application checker, a new shell script checker, and a new multi-version SDK (software development kit) that will enable developers to build applications to earlier LSB specifications without changing SDKs."
T'so added, in this document, that "We have a new set of LSB tools to make it much easier for ISVs to development applications that are LSB compliant, and to test to see how portable their applications are via the Linux Application Checker."
It's this AppChecker that I really love about the forthcoming LSB 4. It's easy to try to write to a standard. It's a lot harder to see if you actually pulled it off.
What AppChecker does is automatically decompress all the archives of your program and start testing the ELF (Executable and Linking Format, a.k.a. binary files), Perl, Python, and shell scripts. So far, this doesn't sound much more than just another fancied-up version of the forerunner of all program checkers, lint, but it's what AppChecker does next that will make it a must for any Linux software developer.
AppChecker then checks your program not only against the current and earlier versions of the Linux Standard Base (LSB), but also against all the Linux distributions in the LSB Database. So, it will tell you not only if your program is LSB 4 compliant, it will also tell you if your program will work not only on your Ubuntu development platform, but on say SUSE Linux Enterprise 10 and RHEL (Red Hat Enterprise Linux) 5 as well.
This, if you're an ISV is beyond cool. This is a killer development application.
You don't have to be a serious programmer to get goodness out of the LSB though. Even a do-it-yourselfer with shell scripts will appreciate its new shell script checker. This program checks, according to the Linux Foundation rlease, for "potential cross-shell problems in scripts, which means that a script on one distribution can run on another without blowing up." This is also really, really cool. I know system administrators who would have killed for this capability.
As you can tell, I'm really excited about the LSB 4. I know it may seem odd to some of you that someone could be so up about just another standard document, but that's the whole point. This isn't just another standard document; it also includes the tools you need to easily use the standard in your day-to-day programming and system management work.
In years to come, LSB 4 may be what people remember 2008 for rather than the rise of Linux-powered mini-notebooks or the release of new, important Linux kernels like the October's 2.6.27.