Slashdot Mirror
Building Applications with the Linux Standard Base
I've been involved with IBM products and documentation since the late '70s, and their documentation has traditionally come in two flavors: user's guides, and reference manuals. The former are meant to be read cover-to-cover (more or less), and the latter are meant to be looked at for specific bits of information. This book falls more to the reference manual side of the spectrum. Consequently, reading it cover-to-cover was a little dry, but the information needed to get an application certified with the Linux Standard Base (LSB) was clearly laid out.
Building Applications with the Linux Standard Base (published by IBM Press and available on your favorite bookstore sites) is laid out in five large parts: Introduction, Developing LSB Applications, Certifying for the LSB, Contributing to the LSB Project, and Using LSB Resources. Except for the first part (Introduction), the book gives specific examples, and many, many references to the opengroup.org website's sections on the LSB.
It becomes obvious as you go through the book that the Linux Standard Base is still evolving. The authors (13 core members of the LSB team) frequently allude to how the project can (and should) be extended to increase its scope and sophistication. Two chapters (Adding New Interfaces..., and Adding New Architectures...) cover (albeit skimpily) what's needed to update the specification.
Backing up for a moment, Part II (Developing LSB Applications) describes in detail (with examples) the Dos and Don'ts of coding practices. It then explains carefully how an application should be packaged for distribution (RPM), and finally wraps up with a section on porting Solaris apps to the LSB. In each chapter, step-by-step instructions are given when appropriate. Differences in filesystem hierarchy, signal handling, and program options are all laid out to help you through.
Part III goes over the LSB Certification process. Both runtime environments (distros) and applications are covered. Again, the book lays out the process in a step-by-step approach.
The last part in the book talks about the various resources available: the written spec, the test suites, and various usage guides. The chapter on using the LSB test suites shows how much thought went into making sure a successful test ensures a certifiable (in a good way) application.
All in all, Building Applications with the Linux Standard Base, has what you need if you're developing a commercial-grade Linux distribution or application. Once your product has passed the testing described inside, you can be confident that it will work on almost anything Linux. Very dry reading, but a lot of useful information packed into a slim 246 pages. I'd give it a 7 for writing style, but a 9 for content: total=8/10.
You can purchase Building Applications with the Linux Standard Base from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, carefully read the book review guidelines, then visit the submission page.
Ah, yes, standards. So many good ones to choose from.
... writing apps that work across distros is really easy - it's called Java. :)
Does anyone see how one thing is supposed to follow the other?
-Peter
This is about the hundredth project of it's kind that I've seen since linux' infancy.
Good luck to it. I'd love see a "works with linux" stamp, and have distro choice be completely irrelevant.
It's absolutely necessary if linux is to go anywhere worth going commercially.
I don't need no instructions to know how to rock!!!!
...programs can break on subsequent versions of linux because something has been moved or changed. Come on, guys. Maybe the reason linux isn't mainstream yet is because it's so hard to get your feet on the ground before the rug is pulled out.
An effort to make device driver standards would mean a lot more to lots of us.
That would make it easier for manufacturers to make linux supported hardware and know that it worked.
Every linux user needs linux compatible hardware, but relatively few need commercial software.
File naming protocol
------
Characters in filename names are a rare commodity, to be used wisely.
Filenames should be abbreviated to the point of obfuscating any meaning:
Why use "print" when you can use "prin," why use "prin" when you can use
"pin," why use "pin," when you can use "xb."
Standard output formatting protocol
------
When printing a table of data to standard output, there is no need to
label rows and columns. Linux users are elite professionals, they
instantly know what the endless rows and columns of hex values,
abbreviated acronyms, and various other standard and non-standard
variables represent.
In the rare occasion that a Linux user is unsure what some data
represents, he will simply view the source, if the source is not
available, he will disassemble the executable, and read the assembly code.
If you must label columns and/or rows, please
follow guidelines set out by the "File naming protocol" section.
The biggest pain in the ass I find in writing complex apps that interact with other complex apps, across different Linux distros, is the different filesystems. Where's the meta-FS-standard, where either "make" or at runtime my app can access a filesystem path under one distro's namespace (ie, on which the app was designed), and have it translated to the distro under which it will run?
"That's the nice thing about standards... there's so many to choose from!" - Anonymous PHB
--
make install -not war
Actually, each distro has its own little additions and, consequently, quirks. Writing an application to work reliably under all variations is not a slam-dunk.
IMHO, this is one great advantage that the FreeBSD project has - there are no "distros".
Writing an application to work reliably under all variations is not a slam-dunk.
So it turns out that Microsoft's mutant penguin ad compaign was right all along?
For the past few years, I've been screaming about the negative effects of having so many different standards to choose from on Linux - this is why I personally use FreeBSD and OSX (well, okay, and Windows for games).
But the biggest problem (which also exists on FreeBSD), is QT. The shitty licence has caused so much damage by keeping cross-platform and commercial development off KDE (one of the most popular window managers). I know there's GTK, but I can't help think that Linux might have reached critical mass and become mainstream popular without it - GTK might not be perfect, but it is a STANDARD.
Monkey man Steve Balmer might have looked silly when he yelled it on stage, but he was right: "Developers, developers, developers." The Linux community should be bending over backwards to attract new developers into their flock, by making their passage into the fold as easy and as hassle-free as possible.
Chicken and the egg: applications for Linux, users for Linux. The Linux community can't force people to use Linux for the sake of using Linux, but they can bring applications to the platform - if they're worth using, users will follow.
First, that doesn't work in real life, where even the "real" UNIX systems don't follow the various UNIX standards perfectly.
Second, SUS and other UNIX standards don't cover binary portability at all, which is usually far more interesting to _users_ than source compatibility. I haven't and never will look at the source of most the apps I run, but I _do_ know that I want to be able to run them. I don't want to have to compile things myself, wait for others to compile and package them, and/or hunt through hundreds of packages for the same software to find the one that works on my systme. I want to go to the upstream software's site, click Install Software, and have it work. And that's 100% feasible, assuming the apps sticks to a standard like the LSB and your distro is LSB compliant.
Third, there's also then the issue of proprietary apps which don't even have the option of making users compile the source. Unfortunately, there are proprietary apps out there, there are people who _want_ to use proprietary apps even in the face of existing OSS alternatives, and that's that. The LSB largely exists to serve those apps, in fact.
"Building Applications with the Linux Standard Base" has been (apparently) also published under the GNU Free Documentation License. Here is the Online version.
While this is true there are programs that ran on 98 that don't run on XP. If they don't make a newer version of the program you are SOL. With OSS you just recompile, which is relatively painless for small applications. Even if a simple recompile doesn't work it is still possible to modify the source to get it to work.
That way, GNOME and KDE could just be seperate shells on top of the same desktop, and they would happily run each other's apps.
That seems pointless to me. Why wouldn't you just make one shell with all the options of GNOME and KDE? It seems like after you got everything to work as one DE with different shells, you would only be one small step away from merging them completely into one.
I do think GNOME and KDE should integrate as much as they can to keep things compatible and consistent BUT it's good to have two seperate environments, especially since they seem to aim at different crowds. Also, competition is a good thing.
I'd also request a kernel driver API that unties them from the kernel--recompiling an entire kernel to support a new scanner I just bought is ridiculous. I should just be able to go online and download a special binary driver
I'm confused by this. You don't need to recompile your kernel to include a new driver. You can build modules without rebuilding the entire kernel. Also I build the madwifi-driver, which is partially proprietary and outside of the kernel, without having to recompile the kernel.
Time makes more converts than reason