Slashdot Mirror


Professional Linux Programming

WrinkledShirt contributed this review of a Professional Linux Programming, a tome he says can "bend light" by its sheer size -- 1155 pages of multi-author, multi-language instruction and examples. Read on for his thoughts on the book's shortcomings as well as its strengths, and remember, lift with your knees, not with your back. Professional Linux Programming author Neil Matthew, Richard Stones, et. al. pages 1155 publisher Wrox rating 8 reviewer WrinkledShirt ISBN 1-861003-01-3 summary A brilliant book for anyone wanting to gain new Linux programming skills.

Introduction

Large programming books have a special sort of gravitational pull to them. It's a sort of siren's song for us techie types, with lyrics promising an endless fountain of information, more than you could ever possibly hope to use, superfluous only in the same way that you don't plan on reading the Encyclopaedia Britannica cover-to-cover anytime soon, either.

Unfortunately, this branch of the publishing industry responsible for these books is well aware of this, and as such there's a veritable critical mass of crap in that corner of the bookstore, some of it reading like blood being squeezed from a stone, with any number of useless chapters thrown in there just to meet some predefined page quota. Which is why it's such a relief to get a book like Professional Linux Programming that's 1155 pages long and contains a ton of material, with very little of it page-filler. Unless you already know it all, there is something valuable in this book for just about every Linux developer out there.

The Good

This book is loaded. Go straight to the table of contents if you need to see what I mean. The book's sheer ambition almost makes it worth picking up a copy. We need more like this -- not just for Linux, not just for programming, but for computer references in general.

If you've thought about developing for Linux, you've probably rubbed up against the impression that Linux and C go together like a wink and a smile. This book delivers on that impression, and it delivers huge. There are chapters on how to use C with PostgreSQL and MySQL databases, LDAP services, GTK+/Gnome/libglade and Qt/KDE, Flex and Bison, XML, sockets, RPC and CORBA (using ORBit). There are also sections on applied professional development theory, like design, debugging, security, deployment, and encryption.

If C isn't your bag, you might not find as much to get out of this book, but there are still sections on PHP, Python, documentation, package deployment, internationalization and shell database manipulation. Ever wondered how CVS or patching worked? It's in there. There's even material on device drivers and Beowulf clusters. By the end of this book you'll have more than just proof-of-concept familiarity with just about all the topics. For all but the more exotic subjects, you start at the simplest example, and the complexity gets increased with subsequent scenario, until the point where the chapter gets applied to the book's ongoing case study, which is the development of a hypothetical system to track a DVD store's business operations.

To give you an idea about what sort of depth to expect from this book, I'll talk about what it does with PostgreSQL. It shows you how to install it and maintain it from the command line; walks you through how to create basic databases; gets you comfortable with running SQL queries from the command line or scripts from a file; shows you how to interface with it using C (using both libpq functions and embedded techniques); shows you how to handle different kinds of transactions and cursors; talks about bringing it into PHP; and uses PostgreSQL for the core engine for the case study. Now, database work is obviously going to be getting special treatment when it comes to commerce development, but that's still only one of many subjects that this book tackles, most of which are designed to get you on the ground running before needing to resort to supplementary material.

As an aside, from a coordinating standpoint, this book is a marvel. Content was contributed from 15 separate authors and yet continuity is practically a non-issue.

The Not-So-Good

Typos. Oy vey. It's like getting a buddy to lend you his Ferrari, only to discover that there's a little bit of bird crap on the windshield that nobody can wipe off. Nice car, shame about the bird crap. Now, this book isn't horribly bad for it, but you shouldn't be surprised to find the odd error at the rate of one or two per chapter, usually in the form of an incorrect diagram symbol here or there or a formatting character that didn't quite translate into a code listing. Not too bad, but it's enough to be a mentionable problem. The Wrox people were good about putting up an errata page, but, unfortunately, it's empty. This may speak to the fact that the intended audience are hackers who can probably figure out the problem for themselves anyway.

Then there's the timeliness factor. This is a review of the first edition, which came out in September 2000, and it's unfortunate that with all the new technologies coming out (Bonobo, KParts, Mono, etc.) there isn't a second edition in the works as of yet. As such, people hoping to find useful information on programming with the more volatile APIs (specifically the GUI stuff) might want to look elsewhere. The information in this area isn't completely obsolete, just not as cutting edge as it was when the book first came out. Most of the other chapters are still current, and had this review been done near the publication date, the rating would easily be a 9 out of 10. That it still merits a review at this point, after being out for almost a year and a half, hopefully says something.

There's also the fact that even though this book contains so much, it doesn't really act as a definitive reference in any area that it describes. For instance, I was toying with the idea of making a code mangler for an XML-type language, so the chapter on Flex and Bison had me drooling. It wasn't long after reading it, though, that I found myself needing to go to GNU's Flex website just to get a better listing of all the regular expressions I'd need to use. That's symptomatic of pretty much all the chapters here -- it doesn't take long to outgrow the material when you need to apply it to your personal project. In this sense the title seems misleading; if you wanted to program in some of these areas at a professional level, this book would only be a starting point to another, deeper reference.

The huge breadth of knowledge also makes some omissions seem glaring. There is nothing on Perl or some of the other popular shell languages. Outside of two chapters, C++ is avoided like the plague. The section on deployment using automake is tiny enough that it's practically not there, which is surprising given the amount of time a reader spends churning out source code throughout the rest of the book. There's also a brief section on multimedia that, given the context of the rest of the topics, just feels out of place. Some of these shortcomings are made up in the intended predecessor to this book, Beginning Linux Programming , so you might want to give that book a whirl as well (TCL, BASH, and Perl all get treatment there).

And just to leave no superficial stone unturned, the cover is just awful -- it looks like a police lineup. Although I suspect there's a focus group somewhere that needs to answer for this, maybe it bodes well knowing that, considering the slightly expensive nature of this book, none of that money went into its outer design.

Conclusion

There are some people who aren't going to want to buy this book. Specialists, or people who want to specialize, likely won't get enough of what they want on any of the subjects here. Also, this isn't so much a learning guide that will give you exercises and quizzes, so if you're still at the stage where you need that sort of thing, this book might be a bit rich. If you're hoping for bleeding-edge stuff, wait for a second edition.

Also, it's taken for granted that the reader understands C pretty well, so if you don't, invest some time in that area first.

However, if you've got the fundamentals of Linux programming down pat but don't know where you want to go next, buy this book. If you're a seasoned developer and just need to get the basics of a new area in order to apply it to your ongoing projects, buy this book. If you're a generalist or a hobbyist, buy this book. If you need to design application prototypes for the Linux platform, buy this book. If you want to compare different APIs without having to commit to buying different textbooks, buy this book. If you get off on knowing you can do more Hello Worlds than any of your friends, buy this book. And if you like your references so big and fat that they bend light, buy this book.

Table of Contents Introduction
Chapter 1: Application Design
Chapter 2: Concurrent Versions System (CVS)
Chapter 3: Databases
Chapter 4: PostgreSQL interfacing
Chapter 5: MySQL
Chapter 6: Tackling Bugs
Chapter 7: LDAP Directory Services
Chapter 8: GUI programming with GNOME/GTK+
Chapter 9: GUI Building with Glade and GTK+/GNOME
Chapter 10: Flex and Bison
Chapter 11: Testing Tools
Chapter 12: Secure Programming
Chapter 13: GUI programming with KDE/Qt
Chapter 14: Writing the dvdstore GUI using KDE/Qt
Chapter 15: Python
Chapter 16: Creating Web interfaces with PHP
Chapter 17: Embedding and extending Python with C/C++
Chapter 18: Remote Procedure Calls
Chapter 19: Multi-media and Linux
Chapter 20: CORBA.
Chapter 21: Implementing CORBA with ORBit
Chapter 22: Diskless systems
Chapter 23: XML and libxml
Chapter 24: Beowulf Clusters
Chapter 25: Documentation
Chapter 26: Device Drivers
Chapter 27: Distributing the application
Chapter 28: Internationalization
Appendix A: GTK+/GNOME Object Reference
Appendix B: DVD RPC Protocol Definition
Appendix C: Open Source Licenses
Appendix D: Support, Errata & P2P.Wrox.Com Related Links

You can purchase Professional Linux Programming at Fatbrain.

3 of 194 comments (clear)

  1. What I really want to see... by wls · · Score: 5, Insightful

    What I really want to see is a book that assumes you know how to sling code, but addresses the specifics on how to become part of the coding community.

    I've seen lots of lists that say:
    0. Get the latest version of the code from CVS.
    1. Read and understand the code.
    2. Make changes.
    3. Send your patches to the maintainer.
    4. Hope they get accepted.

    There are a lot of programmers out there who don't have the minimum set of knowledge to perform the admin part of steps, but do have the technical know how to write solid code.

    How many people have code but don't know how to set up a good makefile, but could if a decent template were explained? How many people would like to have configure scripts, but aren't sure how the magic works? How many people aren't sure how to put their code in CVS or upload it to SourceForge? How many people want to know how to build packages, whether by RPM or some other means? How many people don't know what questions users need answered in documentation, nor how to put it in a man/info page?

    Simply making a breadth, but shallow, offering consisting of nicely printed man pages that are indexed hasn't helped much. It'd be nice if someone took a simple project and followed it end-to-end.

    (At serious risk to my inbox, if enough contributors send me suggestions, tidbits, or the process as _they_ see it, I'll make a decent effort and putting something together.)

    1. Re:What I really want to see... by wls · · Score: 5, Insightful
      There are a lot of programmers out there who don't have the minimum set of knowledge to perform the admin part of steps, but do have the technical know how to write solid code.

      > I very much doubt that. The former is generally easier than the latter.

      I've written a number of various utilities and applications for the public domain. Some shareware was successful enough it still results in checks in the mail, some applications I personally witnessed in use by over 300 people each day over the course of four years, and many others have just faded away with time and platform changes. On the commercial front, I've written a lot of flagship products, directed development efforts, and been highly involved in QA and SCM. I like to think I can code my way out of a paper bag.

      Naturally to do all those things, I've needed to know various languages, compilers, bug tracking tools, version control systems, build automation, and documentation. I like to think I've successfully been involved with much of the software lifecycle.

      But, when I first dipped my foot in the Linux pool, I was trying desperately to map my prior experience from PC to Linux.

      I knew Microsoft and Borland's C++, but couldn't get certain parts of the STL to work with gcc. Oh, that part was broken (it's hence been fixed).

      I knew SourceSafe and PVCS inside and out and had been the CM manager of 70 people. Just mapping the terminology from those products to RCS/SCCS/CVS was a small barrier of its own when I first started. Things didn't help when the some standard CM tasks required implementation knowledge of CVS and tweaking the repository directly.

      In corporate environments, we had access to the version control system directly; we were immediately responsible for the code. There was no need to generate patches for submission, or apply them.

      In cases where the software wasn't designed to be portable, people never took that into account. The general philosophy had to change for Linux.

      Tired of Microsoft's or Borland's make? Use OpusMake. Want to build an installation package? Use InstallSheild or another varient. Hard core debugging? Soft/ICE. Powerful tracing? Any NuMega product. Documentation? Word. PageMaker. FrameMaker.

      But assuming I've got GNU Make, autoconf, RPM, gdb, LaTex, and a number other things under my belt -- everything has to be done in a way that's acceptable and receptive to the community.

      The point I'm going with is this: there's a lot of untapped talent out there, because of the transitional Rosetta stone is kept too close to our chest.

      We share our code, but not our process and techniques. We assume that just because people haven't cut their teeth on Linux, know GNU utilities inside and out, and know how to do things the way we do that they are neophytes. That needs to change.

      If the Linux and OpenSource community wants to tap the knowledge and talent of the commercial world, we need to not just provide software tools and grass movement marketing, but we need to provide the intellectual resources as well.

  2. Re:Undocumented Linux in 21 Days Unleashed Black B by Scooter · · Score: 5, Interesting

    "Do they pay the authors of these tomes by the pound? "

    Almost. I wrote a few chapters for an "Unleashed" Linux book by Sams which they canned unfortunateley, and they pay by the chapter which has to be around the 20 page mark (given a standard font, ruler settings etc.). They don't pay very much either - it was about $600/chapter back in 1999 (and they never paid anyway)and it was taking me about a week to 10 days to do one - as it's not like you're just offering your $.02 in a web forum - every claim, and fact has to be checked as much as possible.

    Yes indeed - C is still C when it's in a Linux environment. I think there is a place for these "lets cover everything" books but I think it's more appropriate at the "introduction" end of the market - I have a copy of Wrox's "Beggining Linux Programing" and its good - I still look in now if I need to see how to do soemthing simple in a language I don't really use that often - say like "what's the syntax of an if statement in Perl then?" a quicj flick through to an example will often provide the answers.

    Yes - the funky animal books are more in line with what I want: just the facts.