Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


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

The Linux Development Platform 121

Posted by timothy from the robust-but-grainy dept.
honestpuck writes "Back before the advent of Mac OS X, my favourite (and for many years, only) development environment was one variety of Unix or another. The nicest thing about Unix was that the development environment stayed pretty much the same regardless of the variety; this stayed the same with the introduction of Linux." Honestpuck examines how true this still is (as well how accurate the chosen title is) in his review of Prentice Hall's The Linux Development Platform, below.
The Linux Development Platform
author Rafeeq Ur Rehman and Christopher Paul
pages 320
publisher Prentice Hall PTR
rating 7
reviewer Tony Williams
ISBN 0130091154
summary Good guide to developer tools

The Linux Development Platform might be better titled "The GNU Development Platform" since almost all of the tools discussed come from the FSF, and those that don't are nevertheless open source; as a result they will run on almost any Unix variety. You know that the 'Linux' in the title is almost just a marketing ploy, but we will forgive Prentice Hall and the authors. Certainly more people will buy this book to learn about using these tools under Linux than under any other *nix variety.

The book starts with a short chapter on software development per se before getting down to the nuts and bolts. It starts in the obvious spot, with editors, and quickly covers choosing an editor before taking a brief look at Emacs, Jed and VIM. The rest of the book is devoted to much less contentious issues.

As a whole, the text provides a good grounding in using gcc, make, CVS and GDB, with enough extra information on smaller tools and larger issues (such as cross-platform and embedded systems) that you will not need more than this book and, perhaps, the man pages to understand and use these tools. Of course others, have written entire volumes on each of these topics, but for most of us this book will provide the information we need.

The Linux Development Platform comes with a CD containing the source for a fair number of the tools discussed, so you can build any tools which happen to be missing on your platform, though some of the included apps are, of course, already a version or two behind.

The writing is mixed in quality: while never bad, it has a slightly heavy, technical feel to it, often a bit wordy or cumbersome. This rarely gets in the way of understanding, but it does slow you down. The topic coverage is good, moving from a beginner level right through to a good understanding of each tool discussed. More importantly, all the tools you will need are covered.

I imagine this would make an excellent companion text for any programming course: note that it doesn't provide details on any programming language, but covers everything else you need to know regarding the development tools. It is thinnest in the discussion of editors, really only giving a brief overview of each. I cannot really see this as a fault since detailed coverage really would take a separate book, and this quick look is better than pretending to cover the topic well and failing. The other possible weakness is that there is almost no coverage of general Linux usage, so calling the book The Linux Development Platform is a bit of a misnomer -- it is really devoted to the tools available for development, not the underlying operating system at all. Once again, I feel that this lack is not serious; most buyers should know enough about the operating system and any attempt to cover it adequately would have swelled the size and cost of the book.

Prentice Hall PTR have a site for the book with a Table of Contents or you can see the whole book in HTML format at FAQs.org.

I would recommend this book to anyone who would like a good, general introduction to developing software on a Unix platform. Though it's not a cheap book, it is a good one. It was certainly a relief for me to find a good book in Prentice Hall's 'Bruce Peren Open Source Series' after a couple of flawed ones.

You can purchase The Linux Development Platform from bn.com. Slashdot welcomes readers' book reviews -- to submit a review for consideration, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

The Linux Development Platform More

The Linux Development Platform

Comments Filter:
  • ...you might also want to get GNU Autoconf, Automake and Libtool [barnesandnoble.com]. It gives a pretty good overview of the standard GNU C/C++ source building tools.

    It also has a couple of handy little chapters in there on doing some basic stuff, like how to build and load a shared object library. Not rocket science, but it's nice to have it explained clearly.

    • Re:If you're interested in GNU dev tools... (Score:5, Informative)

      by pete-classic ( 75983 ) <hutnick@gmail.com> on Thursday December 11, 2003 @02:38PM (#7692406) Homepage Journal
      Or you could even patronize the GNU Press [gnupress.org]. Canonical documentation, and the money goes back to the fine folks that brought us the Free Software in question.

      -Peter

    • Re:If you're interested in GNU dev tools... (Score:5, Interesting)

      by ArchAngelQ ( 35053 ) on Thursday December 11, 2003 @02:49PM (#7692505) Homepage Journal
      I'll second this, with one note on it's quality. It really goes off on tangents with some very complex lexx and yacc code, which, not being that level of a system programmer, felt very hard to wade through. Not only that, but it felt as though it was there just to pad the book's length, as an included cd with the program's source would have been much more useful, rather than having the code, in full, in the book. It's not as if I can run gcc (or configure.sh) on the book.

      That out of the way, the coverage of the actual material, where it is covered, is excelent, absolutely as detailed as it needs to get, which is very. It's a complex topic, but one that will serve you well if you plan on building projects, rather than just contributing code, and even then, if there are new requirements you add to a project, knowing these tools is very handy.
      • > tangents with some very complex lexx
        > and yacc code

        Yeah, it certainly covers a lot of different areas - witness the chapter on "portable Bash programming", for example. It's got 4 authors; maybe that's why.

        > absolutely as detailed as it needs to
        > get, which is very.

        Yup, after reading it, I felt like I understood a lot of stuff better - and even more, I felt like I understood why it worked the way it did. I enjoyed some of the historical digressions, too; seems like they add some personal

  • It's the little things... (Score:5, Interesting)

    by Space cowboy ( 13680 ) on Thursday December 11, 2003 @02:44PM (#7692453) Journal
    ... like glib, gnet, gtk+ (hah! little!) but you know what I mean - these were things that people needed, so they wrote. We all benefit, and so does linux and unix.

    I guess one of the strengths of the unix development model is that my SGI and Sun boxes have all the linux libraries on them, and I don't think that's at all strange...

    Unix (before linux became mainstream) didn't have as much work in the class libraries (which like it or loath it, VC++ provided quite well).... Now it does.

    Simon
  • "Back before the advent of Mac OS X, my favourite (and for many years, only) development environment was one variety of Unix or another.

    Shouldn't there be an 'Even' before the 'Back before the advent of Mac OS X', seeing as OS X is a variety of Unix?

    Tk
  • I'm sure this book will be quite valuable when they translate it to Hindi.

  • Real programmers... (Score:5, Interesting)

    by Lodragandraoidh ( 639696 ) on Thursday December 11, 2003 @02:52PM (#7692557) Journal
    Give me diff, patch, CVS or RCS, make and emacs and I am a happy camper.

    Every year I have some yahoo come in and say how one IDE can do this, that, and the other thing - the best thing since sliced bread. Of course bells and whistles do not an IDE make (I would have said 'make an IDE', but, then I would be a liar on two counts).

    Emacs is fully extensible, and interfaces with all of the tools above. Additionally, I can run it over a telnet/ssh connection with ease (I don't use the mouse very much for two reasons; 1, I keep the keystrokes in my head for when I do need to use a telnet session, and 2, I have gotten to the point where I can do things faster using the keyboard than a mouse and keyboard combo in emacs.

    I even do my primary editing on my windoze box using emacs, and am in the process of writing python language equivalents to the most common unix command line utilities (already completed 'grep.py' - then want: make, diff, patch and other tools unavailable on the windows command line) as a learning process.

    • OT: Real programmers... (Score:5, Informative)

      by deadlinegrunt ( 520160 ) on Thursday December 11, 2003 @03:00PM (#7692623) Homepage Journal
      in the process of writing python language equivalents to the most common unix command line utilities (already completed 'grep.py' - then want: make, diff, patch and other tools unavailable on the windows command line) as a learning process

      I understand the "learning process" part but have you heard of MSYS [mingw.org]?

    • Re:Real programmers... (Score:5, Informative)

      by pclminion ( 145572 ) on Thursday December 11, 2003 @03:01PM (#7692626)
      You're aware of Cygwin [cygwin.com] which provides all the GNU tools, compilers, linkers, editors, etc, even the standard UNIX APIs, all ported to Windows? I understand that you want to learn, but there are other UNIX emulation projects out there, and they took person-decades to write. You're just one guy...
      • I went out and downloaded Cygwin, and messed with it a little bit.

        My major issue with it is it is really designed for porting existing applications into a Windows environment by using a system level DLL to map Unix system services to Windows system services. While that may be useful, it does not allow you to run native DOS and Windows applications from within Cygwin (I should be able to do anything on my machine from one interface - not have to jump around).

        This does not address my goal - which is to bui
    • You mean you where trying to do this? This should take care of all of the commands.

      def cmd_execute(cmd):
      p = popen2.Popen3(cmd)
      p.wait()
      return string.strip(p.fromchild.read())

      cmd_execute('grep -r looser /')
    • Just a little comment.

      I've seen a couple of projects re-implementing the standard *nix command set in things like PERL or Python. Each time, I've thought to myself, neat, but mostly just an exercise in amusement.

      But you point out something I had not considered before, it makes ap retty viable alternative to cygwin. Now where the hell did I put the gnat rpm?

    • When I was a kid and first confronted with VI, I was like, WTF?, and then this girl showed me EMACS, and it was like a breath of fresh air. Ten years later, I've been using VIM for a month, and doing stuff related to editing in VIM is soooo much easier than with EMACS. You can essentially write your own VIM IDE in a day. What was I thinking?

    • Hi, I'd like to do the same(unix->python) at some point in the future. Interested in sharing the code?

      • I intend on putting my stuff up on Freshmeat or equivalent sometime in the future.

        I'm going to do a little research first, and see if there is already a project that is a going concern before I do - that way I don't duplicate efforts.

        If you want to contact me regarding this, email me at this location [mailto] and I will give you what I've got (grep.py atm).
    • To me, an IDE is like one of those automatic breadmakers, where you throw in the ingredients, it mixes them, kneads the dough, and then bakes it. One of these can be nice if all you want to make is bread.

      Unix tools are akin to having an oven, mixing bowl, breadboard, pans, and all the other simple items that most kitchens have. You can make anything you want, in any shape you want. And it usually comes out much better.

    • Every year I have some yahoo come in and say how one IDE can do this, that, and the other thing - the best thing since sliced bread...

      Emacs is fully extensible, and interfaces with all of the tools above.

      "IDE" stands for "Integrated Development Environment". While the vast majority of IDEs are the kind that expect to run under some sort of windowing system - Win32, X, what have you - there is no absolute requirement that an IDE be a purely GUI-based tool.

      IMHO, emacs was one of the first successful I


      • emacs was one of the first successful IDEs.

        I certainly appreciated tags, M-x compile, M-x grep from within Emacs.

        IDE's have always felt like customized sports cars designed to fit someone else (like the author of the IDE).

        They're great if you like the fit, but if you find yourself fighting and cursing the design decisions that have been made for you too much of the time then it's time to climb out of the cockpit.

        IMO, the constant signpost reminder of IDE deficiencies has always been the need to preser

        • IMO, the constant signpost reminder of IDE deficiencies has always been the need to preserve Notepad on Windows.

          Heh. Well, I'm pretty much using either an IDE (Eclipse) or Cygwin + vi under windows these days... each has it's own strengths. Then again, Eclipse is a lot closer to emacs-as-IDE, in that it's the first GUI IDE I've ever worked with that gives me the opportunity to substantially alter the environment to suit how I want it to work. It may be a sports car, but if it is, it was designed by som

          • I have been meaning to take Eclipse for a spin.

            The only drawback with pure gui IDEs is my requirement to be able to do substantial work remotely.

            While you can export an X window - the overhead across the network is unbearable. Again, this is where emacs shines; I like the flexibility of being able to make changes from anywhere at anytime - quickly without any hassles - and check in the changes on my remote server's CVS repository - without leaving the interface.

            If I am WiFi'ing at the coffee shop, and I

            • Good points - I'll admit that exporting Eclipse across a LAN is perfectly fine, but over a 144 ISDN link from home it's a lot more problematic. I'd argue that a lot of it depends on your work habits, though. In your coffee shop example, I'd certainly have a current version of my dev environment on my laptop, so no need for a mad dash back to the office, and no need for network activity except to interact with the source control system.

              Now, if you could get Eclipse running with Cursed GTK [sourceforge.net], then maybe you'd

  • Just gcc? (Score:3, Insightful)

    by plcurechax ( 247883 ) on Thursday December 11, 2003 @03:02PM (#7692635) Homepage
    Does it just cover the GCC suite? gcc, g77, p2c and such or does it include commercial tools like the Intel C/C++ compiler for Linux, Borland's C/C++ compiler, Portland Group's Fortran and C++ compilers?

    Does it mention cross-platform or standards based (POSIX, or 4.3BSD and newer) development? That is likely one of the largest stumbling blocks for new developers who's project grows from meeting her needs into a popular project on multiple systems.

    Does it explain how to work well with (or within) an open source project, like the linux kernel, XFree86, or any one of thousands hosted at SourceForge?
  • Of course the environment was the same all those years -- the only way to do it was with a text editor. I don't really get why that is a big deal. Now that there are GUI's that people can attach onto UNIX/LinuX, different development environments have sprung up like dandelions.

  • don't forget Eclipse (Score:3, Interesting)

    by Chuck Bucket ( 142633 ) on Thursday December 11, 2003 @03:05PM (#7692655) Homepage Journal
    I've been using IBM's Eclipse IDE, and have been really happy with it. My requirements are more towards the CVS side with some coding as second, but it seems like a very polished tool that I much prefer over Ajunta.

    CB

  • UNIX (Score:4, Insightful)

    by HeghmoH ( 13204 ) on Thursday December 11, 2003 @03:06PM (#7692662) Homepage Journal
    Back before the advent of Mac OS X, my favourite (and for many years, only) development environment was one variety of Unix or another.

    So did he decide to switch to Windows when OS X came out or something? Mac OS X is a UNIX!
  • The Linux Development Platform might be better titled "The GNU Development Platform"

    Even better, call it "The GNU Development Environment". The installation of the GNU development tools won't change Solaris to GNU. The platform is still Solaris.

  • Programming wiht GNU Software (Score:5, Informative)

    by ziggyboy ( 232080 ) on Thursday December 11, 2003 @03:08PM (#7692684)
    You guys might also want to check out the O'Reilly's "Programming with GNU Software" by Mike Loukides and Andy Oram. It seems the content is pretty much the same, and may even be a more appropriate title than "The Linux Development Platform." It includes chapters on: free softwre, intro to Unix, editing source code with emacs, compiling and linking with gcc, libraries, debuggging, make, rcs and program timings. Here's the O'Reilly page on the book [oreilly.com].

    Many Linux programming books actually already contain most of the content of these kind of books including Wrox's "Beginning Linux Programming" by Richard Stones and Neil Matthew. You can find the book's webpage here [wrox.com]. A very good text to get you started in Unix programming.

  • Linux centric (Score:3, Interesting)

    by B'Trey ( 111263 ) on Thursday December 11, 2003 @03:10PM (#7692698)
    The Linux Development Platform might be better titled "The GNU Development Platform" since almost all of the tools discussed come from the FSF, and those that don't are nevertheless open source; as a result they will run on almost any Unix variety. You know that the 'Linux' in the title is almost just a marketing ploy, but we will forgive Prentice Hall and the authors. Certainly more people will buy this book to learn about using these tools under Linux than under any other *nix variety.

    Almost all of the tools (command line utilities, not major user apps) in Linux come from the FSF. How should this book have been different if it was oriented purely for Linux users? What tools should have been included that were left out? If you can't answer that question, then how do you justify commenting on using the word "Linux" in the title as a marketing ploy? The point you make, that it's applicable to other *nix systems, is a side effect of how *nix works and of the goals of the FSF. It doesn't mean the book is really a generic *nix book that they're calling a Linux book.
  • my favourite development environment was one variety of Unix or another. This stayed the same with the introduction of Linux."

    Hmmm, maybe that is because Linux is Unix. If it walks and talks like a duck I'm gonna call it a duck. gcc, GNU make, CVS, and GDB? Yup, I've got 'em all on Solaris. I guess this book should be "The GNU/UNIX development platform".

  • If you can get it online for free? (I only took a quick look at faqs.org so I may be mistaken..) I've seen this trend a few times this year.... I'm curious how these authors expect to make money if the entire book is online... Yeah, I hate to read online as well but it beats spending 50$. Especially when I can print it at work for free.

    I don't mean to be a troll.. I'm a DBA so I wouldn't be interested in this book but it doesn't make sense to me.

    • How *long* will the book be online for free? Can you dog-ear pages in the online book? Can you read it while you're riding the bus or taking a crap?

      • The book text is open source licensed. It will be online for free for as long as you can serve it from your own web site. And you can print it, too, and sell the printed copy, and edit a second edition because we give you the source. It need never die.

        Download it from The Bruce Perens Open Source Series [phptr.com] site.

        Bruce

        • It will be online for free for as long as you can serve it from your own web site.

          And suppose I can't or won't serve it up on my own web site? Am I supposed to trust that there will always be a good samaritan somewhere to serve it up for me? Longevity is one of the reasons people buy the hard copy. They don't have to worry about it suddenly dematerializing.

          There are three principles that make people want their own copies of things: longevity, convenience, and control. People buy DVDs even tho

          • I agree. If people didn't like paper, my series would not work economicaly. I just wanted to make it clear that the text would always be free.

            Thanks

            Bruce

          • There is another reason people would pay for it as well. Many people will buy free things merely as a show of support for the existance of said things, such as BSD or GNU/Linux distros, or the desktop they like, or web artists.

            Heck, most non-profits are built on that very idea. People will give money to things they like or wish to see continue.

    • I hate to read online as well but it beats spending 50$. Especially when I can print it at work for free.

      The operative phrase here being "at work".
      When you consider the cost of printer ink and paper, plus wear and tear on the printer head, it may come close to $50, especially for 1K+-page books that seem to be common these days.
      And the result is a physical document that is over twice as thick (because you are printing only on one side of the page, rather than both sides[1], because printer paper is usuall

  • Everything is a nail... (Score:3, Informative)

    by mugnyte ( 203225 ) * on Thursday December 11, 2003 @04:49PM (#7694094) Journal

    These kinds of books are great to inspire a population of hobbiests to write new and interesting programs (just one of a set of reader types). However, without a good grasp of the prior solutions to most technology issues, one is bound to spend a lot of time experimenting to create something that already exists.

    With all the tools OS/GNU and such, there should be strong emphasis on the myriad of projects already out there. Sadly, this amount of information may be too dynamic or large for printed matter. A lot of great minds are all designing bad MP3 players, for example, when the algorithm and code is pretty much commoditized.

    Eh. Don't get me wrong, I'm not to stifle innovation in existing concepts, but most subjects are vastly deeper than what a home-hobbiest is going to know when typing up their first few projects.
  • I would buy the book if it had
    a chapter on debugging tools,
    referencing, valgrind, efence,
    glibc malloc debugging, ...
    This is the stuff that's hard to
    find info on but is something
    every developer needs.

Slashdot Top Deals

If entropy is increasing, where is it coming from?

Close