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".
I think, until a Steve Jobs or Bill Gates comes out with a killer apps with a corresponding toolkit that takes over the market, we'll be stuck in the same boat.
The Kai's Semi-Updated Website Thingy
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.
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/
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
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.
You're FUDDing about the linux binary API, as I can install the quake 3 arena from 1999 (which I originally ran on redhat 5.2) on my suse 9.2 and it runs perfectly.
As to your windows backwards compatibility, you lose points for dishonesty. I know of quite a few w95/w98 apps that simply crash and burn on 2k/xp - and you claim all windows 3.1 apps run fine on xp?
I call bullshit.
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
The differences between Linux distros are what make Linux a vibrant community and drive innovation. I hope the LSB project fails miserably to remove those differences.
-73, de n1ywb
www.n1ywb.com
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.
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.