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
There may not be that many linux-specific high-quality standards, but linux follows closely most relevant unix standards. So why not just build your applications for the Single Unix Specification and ignore any linux-specific features?
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.
Please learn Java before commenting.
Thank you.
I am firmly convinced that Linux on the desktop will not break out of its niche until a binary installation/uninstallation API is developed that allows normal software developers like Adobe and Macromedia to write installers for their software. All you'd have to do is pop in a CD, autoplay would start, the thing would install, stick items into the "start menu" of the desktop environment, and provide an uninstall icon.
The API should remain sane so that you could install something from four years ago and still have it work. I can still run Windows 3.1 and 95 applications on my XP laptop. Try running a Linux binary from two years ago.
To really go all the way, there needs to be a unified framework, probably based on something like Mono, facilitating a desktop foundation and hopefully replacing X.org (Y-Windows looks promising if it would ever take off). 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.
I know what you're thinking--GNOME can already run my KDE apps and vice versa! No, what's happening is all those massive KDE libraries get loaded into memory when you run that KDE app. You have to install two entire huge desktop environments just to run all the apps you need. It's ridiculous. If there was a standardized library and GUI framework, this could have been avoided. But the obsession with "choice" when these projects were began has splintered the effort.
First things first--give me a binary installation/uninstallation API. A real API like the non-amateur desktops have, not some package manager built out of shell scripts. 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, or, better yet--using the binary installation/uninstallation API, just pop in a CD in my desktop environment and have it do it for me.
One can dream...
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.
> Don't assume your config file is /etc/thisapp.conf, don't /var/spool/thisapp.
/etc. I mean, I've been working around *nix for going on fourteen years now, and that was always supposed to be the place.
> assume your data is in
> Make it all configurable.
I don't know why anyone would put system-wide configuration data anywhere else but in
The only real solution to this is to make options for loading critical config data from environment, but that also seems so kludgy when compared with a proper file.
The world's burning. Moped Jesus spotted on I50. Details at 11.
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.
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.