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.
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.
What about Debian GNU/kFreeBSD? Isn't that the Debian distro of FreeBSD? Just because FreeBSD is still relatively obscure doesn't mean that its not going to end up in the same boat as Linux. Give it a couple more years.
Clickety Click
Dunno about you but I don't find Java all that easy across distros either.
Java apps aren't immune to dependency issues either and I'm not aware of any widespread effort on the scale of LSB to create a compatibility and deployment standard.
Dont forget the biggest dependency of all--you need a JVM to run Java. That still needs to be packeaged like any other app. Let me know when there is a GPL-compatible JVM, available in an LSB-compliant package that will install and run cross-distro...and wont break if you use a different X server or non-standard hardware...then we'll talk.
Yes, Java can be written once to run everywhere, but you often still have a few hurdles to clear during compilation and installation.
Writing an application to work reliably under all variations is not a slam-dunk.
s/a slam-dunk/possible/
Solution: Python, Perl, ANSI C, etc. i.e. don't code "for Linux" at all, just code. Of all the ports I've done, Linux is always the biggest pain in the arse, due to the joyous work of glibc, and of course Redhat's need to do everything their own way.
- Adam L. Beberg - The Cosm Project - http://www.mithral.com/
I don't know why anyone would put system-wide configuration data anywhere else but in
Yah, but that's not what he's alluding to. What about
Hence, make it all configurable. Then you don't have to worry.
Not trolling here, but that illustrates how M$ and Windows are being successful.
If this (LSB) actually takes off it could be what allows *nix to displace windows in the Joe Sixpack Desktop. All Joe currently knows is that he has a windows computer, so he looks for software that says Windows on it. With this as a replacement Joe's information complexity does not change just =~s/windows/LSB/g and Joe's happy.
What I see here instead is:
1) My way of implementing portability is best(Java)
2) No it's not (Python)
3) You're right, mine is (PERL)
Whatever people. Until the developers can agree on a minimum compatibility spec that can be advertised (possibly LSB) Linux will only be in the data center.
-nB
whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump
I'd like to state that in this case a layer lower than the virtual machine is not working.
If the virtual machine is not working properly, it's like running an x86 executable on a sparc.
If you mod this up, your slashdot background will turn into a beautiful sunset!
It's a poor craftsman who blames his tools.
... it's best to pick a language optimized for the task at hand. Or even parts of it: I've worked on many applications where I would use, say, C or assembler for time-critical or compute-bound modules, and something easier to work with for the GUI and file-management layers.
Absolutely true, and I can't tell you how many times I've heard otherwise-talented programmers blame their development environment for performance or stability issues. My attitude is usually something on the order of "Stop your bitching, get off your ass and deal with it."
Conversely though, it is a good craftsman who picks the right tool for the job. Most languages can, to some degree, accomplish most tasks, just not necessarily well
What irritates me are programmers that learn a couple of languages and insist upon using them for everything, whether it's a good design choice or not.
The higher the technology, the sharper that two-edged sword.
>At the moment, Java gui apps are neat toys.
I guess IBM, Oracle, SAP, Intel, Novell, Red Hat, Wind River, and others desperately need you as a consultant to tell them that they should stop using Eclipse and rewrite their developer tools in C. Why don't you email them and suggest that?
GNOME is pretty slow too. What's that written in again?
Qt is licensed under the GPL, with the option of a commercial license for a fee.
It's not LGPL, sure. That means that commerical developers must buy a license from TrollTech or make the source to their application availible under the GPL. Not ideal for developers, but TrollTech are not a charity, and in my view they're rather generous to permit Qt to be used under the GPL (yes, it's just good business, but still...).
I'd like Qt under the LGPL - or heck, the BSD license - too, but I don't see a viable way to keep Trolltech in business. I can't see any reason why they would release it under such a license, and think it'd be pretty dumb to ask them to. Additionally, TrollTech do the vast majority of the development on Qt, and I'd like it to continue improving so I can have more introspection and meta-object goodness in C++.
Commercial developers have two perfectly good options - use Gtk, or buy a Qt license. I don't see that as a big deal. Remember that the "competition" is hardly in the business of offering cross platform GUI toolkits.