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.
What about Mono www.mono-project.com
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.
Er, Java is the probably about the most deployed server app language on earth...do you actually know what you're talking about? Have you ever worked in a real situation with Java?
"As it is right now, it's a neat language whose practical applications are limited by the performance penalties."
Okay, so I've answered my own question: no. You may want to go and check out this company called IBM sometime.
And yes, I'm talking client side also. The Visual Paradigm UML tool is a nice example of a great Java app. Runs on Linux too, of course.
As an aside, there was a time on Slashdot when people actually knew what they were talking about when the subject of programming came up (back when I had a five digit uid). As the parent so clearly demonstrates, those days are gone.
Swing based GUIs do have a different look and feel: they look like crap and they feel sluggish. Even the native look and feel doesn't feel native. If you have a C++ app that responds as slow as a Java swing app, you must be using the worst C++ gui library ever.
Swing is *inherently* slow. The architecture is so reliant on delegations at various levels with pluggable look and feels that it has no chance of performing fast. Fortunately, a large number of applications do not require a super-responsive GUI. However, try building a decent Gantt chart that responds to clicks and drags like MS Project. You will find that Swing simply can't scale that well (and Project sets the bar fairly low).
Java file access is pretty damn slow, though it got a speed boost in 1.4.something. It's now at least acceptable as long as the file is text. Parsing binary data in java is a pain in the ass, and also inherently slow because it has to drop into native calls and then bounce back up into java code.
Java memory maps are fucking amazing. I can't imagine how anyone could develop something so slow and want to release it. They are a fucking joke. C and C++ memory maps are at least a hundred times faster.
What the fuck do you mean by "well written?" Do you mean "text based networking code?" Because that is the only thing that Java does extremely well. Java is incredible for text based protocols (and I think C sucks, but I probably just haven't found a good library yet).
Even on numeric stuff, Java would do well if it wasn't for the startup time. Compare a java app to a C++ app compiled with intel's compiler (no fair using g++, I they have some sort of rule that C++ must compile badly). Or compare it to gcc compiled C code. For small data files, the startup time kills the java app. For medium files, they perform about the same. For large files, Java runs out of memory and dies well before C or C++ (1.5 Gig memory limit? Why?). Oh, and also don't do a comparison on the Apple G5. The g++ optimizer is even more retarded on that (just stack allocate a 10000 by 10000 int array and set all values. Look at the awesome code that is generated).
I know how JIT compilers work. I know every JVM available for Linux and Windows. Linear sweep register allocation just doesn't compare to a good graph coloring allocator. On a register rich chip like the PPC, it shouldn't matter, but on x86 it certainly does.
Oh, and I have made simple string processing benchmarks that show Java performs better than C, it isn't that hard (hint: \0 terminated strings take linear time to check size).
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
From The Free On-line Dictionary of Computing (19 Sep 2003) [foldoc]:
Characters in filename names are a rare commodity, to be used wisely.
In a previous job, I was (among other things) maintaining a tool for installing updates to a big vertical-market ap. We got a bug report that it was throwing errors over some file. On investigation, we found a java file with a file name over 100 bytes long, which was more than 'tar' could handle.
We could have done some workaround on 'tar', but instead we bounced it back to the developers and told them to fix their *#$*%&#^ file name. Descriptive file names can go too far.
Quattuor res in hoc mundo sanctae sunt: libri, liberi, libertas et liberalitas.
LSB is nothing new. It's been around since 1998. It's also a vendor consortium, which means nonprofits like Debian have no say in the standards they publish. That fact alone will unfortunately limit its uptake to the commercial distributions, and in the end probably just cause a greater divide between the commercial and noncommercial distros.
LRC, the best-read libertarian site on the web
This discussion has been brought up several times here on slashdot. It always consists of the same arguments.
;)
There are those that feel it's not important. Those that feel it's absolutely critical. And those that claim it already exists.
Well, it is important and it doesn't already exist. Four package managers that usually work don't count as a standard. That's just the shotgun method of hoping one of them will hit the target.
What helps linux growth in one area hurts it in other areas. Developers and distros keep trying to reinvent the wheel. The worst is when it doesn't work, the response is "well, it doesn't work too well on windows so what do you think of that?" (not from developers, but comments on here).
I think the only way developers could agree on one standard would be if someone high up the chain like Linus either came up with an idea or picked one and people worked on improving it. However, it's been my understanding that this is not something he would want to do.
Until then, I'll keep using portage
Your argument isn't valid. If the cross-platform capability was what was hindering the C++ code optimization, then the same argument should apply to their C compiler. gcc generates very good optimized C code. The reason the optimizer is bad is because of the development history of g++. They evolved the compiler to support more and more of the standard (which is a good thing). In the process, however, more and more available optimizations were lost (which is a bad thing). It's that the available manpower is being spent on getting the C++ compiler standards compliant instead of making it generate fast code. I have no doubt that when the standards compliance is done that the optimizations will kick ass.
Oh, and I am the grandparent poster. I actually use g++ despite the bad code generation because it is the only compiler that actually compiles some of my C++ code correctly (although when the intel compiler does compile it, I use that -- yay test cases). Besides, it's still faster than my equivalent java code. I didn't mean to offend any gcc fans. It's just still fairly young in its development.
Actually the topposter is right. While there is a lot in java that we all use and sometimes it seems like we need no external libraries etc, we often do. Strangely there is little in the way of standardisation for this practice in java. there's the whole CLASSPATH thing, but this is where the problem occurs, cause where does the classpath point to on a distro? What libraries can be found there?
I've seen a lot of java programs that just ship their own copy of libraries, because it is so much easier than having to worry about where to find your libraries, or telling the user he needs to "install" a certain set of libraries, which doesn't really mean anything in java. At least, this is my take on things.