Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Programming Books Media Software Book Reviews Linux IT Technology

Building Applications with the Linux Standard Base 282

Posted by timothy from the little-bricks dept.
r3lody (Ray Lodato) writes "Just because Linux is under the GPL, some people believe that it's pretty standardized. 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. The Linux Standard Base Specification seeks to provide the common ground that all Linux apps should adhere to, and therefore make reasonably sure that they will work as advertised. Building Applications with the Linux Standard Base is a reference manual for application developers to make sure their programs will work across the Linux map." Read on for the rest of Lodato's review.
Building Applications with the Linux Standard Base
author Core Members of the Linux Standard Base Team
pages 246
publisher Pearson plc publishing as IBM Press
rating 8
reviewer Ray Lodato (rlodato AT yahoo DOT com)
ISBN 0131456954
summary Very dry reading, but a lot of useful information packed into a slim 246 pages.

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.
This discussion has been archived. No new comments can be posted.

Building Applications with the Linux Standard Base More

Building Applications with the Linux Standard Base

Comments Filter:

  • Standards (Score:4, Funny)

    by Anonymous Coward on Monday December 20, 2004 @05:02PM (#11140405)
    Ah, yes, standards. So many good ones to choose from.

  • Actually... (Score:5, Funny)

    by drgroove ( 631550 ) on Monday December 20, 2004 @05:03PM (#11140420)
    ... writing apps that work across distros is really easy - it's called Java. :)
    • Good point...

      Now for me to write my drgroove loves java flame counter application that can be deployed across all distros.

    • Re:Actually... (Score:3, Interesting)

      by MrRuslan ( 767128 )
      What about Mono www.mono-project.com
    • Java solves the problem of cross-platform apps at the granularity of CPU/OS-API. The JVM doesn't solve problems of different Linux distros, because they all share the same OS API. If you're running the same binary across different CPU architectures, even the same distro won't run x86 binaries on PowerPC. And if you're recompiling from source for different CPU architectures, Java doesn't do anything at runtime that gcc doesn't do at build time. Java is a solution to a more fragmented platform, like "web serv
    • writing apps that work across distros is really easy - it's called Java. :)

      All major or popular distros have a common GPL'ed JVM and standard libraries? About time.

    • Re:Actually... (Score:5, Funny)

      by cthrall ( 19889 ) on Monday December 20, 2004 @05:29PM (#11140686) Homepage
      You misspelled "Python."

    • Re:Actually... (Score:5, Informative)

      by jo42 ( 227475 ) on Monday December 20, 2004 @05:35PM (#11140748) Homepage

      ...and I've see Java apps (i.e.InstallAnywhere [zerog.com]) that stopped running because a distro changed from XFree86 to X.Org. The (Sun) JVM was expecting a certain library to be there, it wasn't, and boom!! - it fall down...

      Mandatory "Java Sux!" - me

      • Re:Actually... (Score:3, Insightful)

        by Tribbin ( 565963 )
        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.

    • Re:Actually... (Score:5, Insightful)

      by WebCowboy ( 196209 ) on Monday December 20, 2004 @05:49PM (#11140886)
      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.
      • Neh, compilation is pretty fine. You just compile it on the developers machine, and if the PATH and CLASSPATH variables are fine, then the Java application runs fine. I admit that getting those paths right can be sometimes hazardous. Even though Java 1.5 has versioning support and more configuration options, they are not quite there yet.

        For your GUI: use SWT to use a GTK toolkit underneath. That will probably solve your X problems, and lets your Application have a native look and feel (which is a must IMHO
    • Um, sorry, name the operating systems and distros that ship with a JVM?

    • Re:Actually... (Score:5, Funny)

      by ScytheBlade1 ( 772156 ) * <scytheblade1@@@averageurl...com> on Monday December 20, 2004 @06:18PM (#11141193) Homepage Journal
      "Saying that Java is nice because it works on all OSes is like saying anal sex is nice because it works on all genders."

      --A friend of mine, aka Orlphar
      • Anal sex doesn't cover the Female - Female case natively. This can be worked around with conversion tools, but it's not as convienent as a case-specific protocal.

        In conclusion, your statement ("Saying that Java is nice because it works on all OSes is like saying anal sex is nice because it works on all genders.") seems highly accurate.
    • I can't even get a java app for my phone to run portably. It totals the java vm on some friends phones (they have to quit all java stuff to get back to sanity). Works great on Nokia.

      "Write once - debug everywhere" is horribly true.

    • # java
      -bash: java: command not found

      As long as their isn't a finished and useable Open Source implementation Java stays a major pain to use on an Open Source OS. Sure, Suns marketing speach might make you believe its portable, but I never had so much throuble with getting software to run than I had with java programms.

  • Non Sequitur (Score:5, Insightful)

    by pete-classic ( 75983 ) <hutnick@gmail.com> on Monday December 20, 2004 @05:04PM (#11140431) Homepage Journal
    Just because Linux is under the GPL, some people believe that it's pretty standardized.


    Does anyone see how one thing is supposed to follow the other?

    -Peter

  • "linux standardization" (Score:5, Insightful)

    by stratjakt ( 596332 ) on Monday December 20, 2004 @05:07PM (#11140467) Journal
    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.
    • Umm... I don't think the "Linux Standards Base" is the hundredth project of its type you'd have seen since the inception of Linux. Whereas there have perhaps been other attempts at standardization by small groups of individuals, the LSB has been (more or less) the first major attempt amongst the distros and major vendors to come up with binary standards.

      Check out the membership of the Free Standards Group (which governs the LSB) here [freestandards.org]. Note that it includes essentially all the significant commercial Linux d

    • Re:"linux standardization" (Score:4, Interesting)

      by runderwo ( 609077 ) * <runderwo@mail.wi ... rg minus painter> on Monday December 20, 2004 @06:41PM (#11141427)
      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.
    • 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
  • Does this mean the "make configure" checks will be shorter, because stuff if standardized? Or where will this be visible for end-users?

    Z
    • I doubt it. Even if everything is supposed to be standardized, the "make configure" checks still have to be sure whatever system its on conforms to the standard. Besides, most projects use the same checks as every other project, so there's not a whole lot of harm in checking to make sure everything is how you expect it to be before compiling.

    • Does this mean the "make configure" checks will be shorter, because stuff if standardized? Or where will this be visible for end-users?

      No, the whole LSB thing is pretty well irrelevant to software. It's about binary package compatibility, and only really interesting or useful for people that want to try and sell linux binaries instead. Which is one of the reasons you'll find lots of important people (Volkerding comes to mind) either apathetic or openly contemptuous of the thing, while the support for it c

  • it's lame that... (Score:4, Insightful)

    by xyeeyx ( 839193 ) on Monday December 20, 2004 @05:11PM (#11140513)
    ...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.
    • Linux has approximately 15% of the server market in 2003. And it just keeps growing. That sounds pretty mainstream to me.

      http://asia.cnet.com/news/systems/0,39037054,39207 175,00.htm [cnet.com]
    • What bugs me is that nearly every time there is a Firefox update, half the extensions I use are broken or disabled by Firefox because the extension doesn't mark itself as being compatible with a version number that didn't exist when the last extension revision was made.
      • How can the extension possibly claim that it is compatible with a version of the extensions API that didn't even exist when the extension was written?

        You have the choice between extensions being disabled (big deal--wait for them to be updated), or extensions breaking horribly, possibly causing data loss, when you upgrade...
    • ...programs can break on subsequent version of Windows becuase something has moved or changed. Come on, trolls. Maybe the reason windows spreads most of the viruses on the internet is because it's so hard to get your PC online without getting 0wn3d.

  • Application level isn't such a problem (Score:4, Insightful)

    by grahamsz ( 150076 ) on Monday December 20, 2004 @05:11PM (#11140518) Homepage Journal
    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.
    • It isn't a good idea and here's why [kroah.com].

      • Actually, the author has a simple reccomendation:

        So, if you have a Linux kernel driver that is not in the main kernel tree, what are you, a developer, supposed to do? Releasing a binary driver for every different kernel version for every distribution is a nightmare, and trying to keep up with an ever changing kernel interface is also a rough job.

        Simple, get your kernel driver into the main kernel tree (remember we are talking about GPL released drivers here, if your code doesn't fall under this category,

        • 2.6.8 to 2.6.9 broke ABI.

          --- QUOTE from someone who doesn't get the problem
          Simple, get your kernel driver into the main kernel tree (remember we are talking about GPL released drivers here, if your code doesn't fall under this category, good luck, you are on your own here, you leech .) If your driver is in the tree, and a kernel interface changes, it will be fixed up by the person who did the kernel change in the first place. This ensures that your driver is always buildable, and works over time, with very

  • Extract from book (Score:4, Funny)

    by oexeo ( 816786 ) on Monday December 20, 2004 @05:18PM (#11140581)
    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.
    • Remind me never to use utilities written by you. It means I won't be able to pipe the output through awk and get sensible results, without wasting my time addint corner cases to strip out the row and column headings. Thanks a bunch!
    • 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

  • metastandard (Score:4, Interesting)

    by Doc Ruby ( 173196 ) on Monday December 20, 2004 @05:21PM (#11140604) Homepage Journal
    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

  • FreeBSD has it figured out (Score:4, Interesting)

    by gtrubetskoy ( 734033 ) * on Monday December 20, 2004 @05:24PM (#11140641)

    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".

  • The problem I see here is that there is a group trying to put together a "standard" for writing to "Linux". However, what is Linux? Is it the Kernel that Linus keeps? Is it the CLI that runs many server apps? Is it the GUI that I run at home?

    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.

  • Oh reeeally.. (Score:3, Interesting)

    by Anonymous Coward on Monday December 20, 2004 @05:37PM (#11140772)
    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 [geocities.com] 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.

    • Shitty license? (Score:3, Insightful)

      by Craig Ringer ( 302899 )
      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 t

  • Online version w/ GNU Free Documentation License (Score:5, Informative)

    by AtomicJake ( 795218 ) on Monday December 20, 2004 @05:58PM (#11140991)
    "Building Applications with the Linux Standard Base" has been (apparently) also published under the GNU Free Documentation License. Here is the Online version [freestandards.org].

  • Radio Edit... (Score:3, Insightful)

    by Duncan3 ( 10537 ) on Monday December 20, 2004 @05:59PM (#11141008) Homepage
    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.
    • Linux is always the biggest pain in the arse, due to the joyous work of glibc
      That's a non sequitur. Why does glibc's high quality mean it's a big pain in the ass? Or were you being sarcastic, in which case you ought to be backing up your criticism?
      and of course Redhat's need to do everything their own way
      I think you're unfairly blaming Red Hat's poor release policy on glibc.
      • No, glibc was just one of dozens of libraries I could have used as an example. Not to mention the 39 flavors of installers/packaging systems out there, etc.
    • don't code "for Linux" at all

      Agreed. How many modern MS-Windows app developers are targeting the GDI? With "time to market" being so important, app developers need to consume as high up the protocol stack as possible. The same is true for linux app developers. Scanning the LSB spec, I expected recommendations for Qt or SWT; maybe glib as the lowest level API. Instead, I found that LSB has recommendations for libc, libGL, libX11, and libXt. These are way too low level for serious, modern app development.

  • because as good as their intentions are, it's never really going to happen.

    If we pretend for one moment that Linux is all about the desktop market, the LSB is only going to have relevance to the top two or four distributions, period. The server market is more restrictive, only two distributions, most likely sharing the desktop market. Forget the embedded market totally.

    NOTHING else will register, and there's no reason why it ever should.
    • Actually, you're pretty close. LSB is a vendor consortium, so it's only going to be relevant to the commercial distributions. For example, Debian, the largest nonprofit distribution, has no representation in the LSB. The LSB will just solidify the fissure between commercial and noncommercial distributions if it is widely adopted.

  • LSB is useless (Score:3, Informative)

    by n1ywb ( 555767 ) on Monday December 20, 2004 @06:41PM (#11141422) Homepage Journal
    http://www.gentoo.org/news/en/gwn/20030401-newslet ter.xml [gentoo.org]
    Portage 2.1 to adopt RPM format for LSB compliance

    In what will likely prove to be a controversial decision, Portage 2.1 will adopt the RPM format for all packages moving forward. The use of ebuilds will be deprecated in favor of the defacto RPM standard. The primary driver for this decision was to ensure compliance with the Linux Standard Base specification, which mandates RPM support for package management.

    The developers have been hard at work to make this migration as easy as possible. Already a proof-of-concept ebuild2rpm script is in place and being tested by a pilot group of developers. Unfortunately, because of the architectural differences between the two formats, some features will not be supported once Gentoo moves to RPM. USE variables are one such feature; sandbox security is another. However, the added benefit brought about by full LSB compliance should far outweigh the loss of these two minor features.

    Additionally, because of LSB's required library support, the xfree86 package will move to become part of the base Gentoo Linux system, rather than an optional addition. Users interested in learning more about the Linux Standard Base should read the LSB FAQ or the full LSB 1.3 specification.

    Note: This is an April Fool's joke.

    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.

    • Even so this is a aprils joke, LSB does NOT force you to use RPM for you distro, your distro can still use whatever you like and be it Linux-from-scratch, all that LSB requires that your distro provides some way to install LSB-conforming rpms in addition to what your distro already provdides. On Debian that means using alien to install the RPMs, nothing more.

Slashdot Top Deals

THEGODDESSOFTHENETHASTWISTINGFINGERSANDHERVOICEISLIKEAJAVELININTHENIGHTDUDE

Close