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.
LSB rpms depend by their very nature NOT on other stuff ... forcing administrators to hold multiple disparate copies of the same libraries, and have to keep track of the security of each individual copy. Or perhaps every lsb app is simply statically linked?
/opt/ and nowhere else.
...)
No, because they go to
The LSB standard doesn't guarantee this. It only suggests, and recommends that there be documentation of other modifications made. It does not prevent modification. (Chapter 5)
You haven't yet understand the purpose of LSB, have you?
Yes I have. LSB is a way for Redhat to impose vendor lock-in and attempt to hijack the Linux market. Too many distributions were popping up using dpkg instead of rpm because it was better, and they had to do something to stop their eroding marketshare. So they form a standards committee with HP, Sun, and other Microsoft friends, and try to brainwash the Linux community into thinking this is a great idea because standards are good, right? They make their filesystem layout the "standard", their package management tool the "standard", etc and then make everyone feel guilty for not following the "standard".
I have no guilt. Redhat are a pawn of Microsoft, being used to drive Linux into the ground with technically inferior "standards" and user interfaces that are just like M$ Windows but not quite good enough so desktop users don't feel compelled to switch. They could have used their old monopoly to further enhance Linux, instead they appear to have used it to buy up kernel developers so they can't speak publically against the company line, and to prevent good things getting into the kernel as long as possible (eg, reiserfs, devfs,
Their idea of a "community" seems to be "people who will do marketing for us for free!" as they have a proven track record of ignoring horrific bugs in their packages (both code/patch and packaging) that had been fixed by third-party rpms distributed via their own "community" mailing lists long before release of the next distribution version. Quality is second to profit. Wait, no, third to maintaining reputation.
I don't trust their business practices, their commitment to the real open source community nor their ability to create unbiased standards for that community, hence I won't use their distributions, nor advocate their standards, and urge the community to do likewise.
Matt