Slashdot Mirror
The Linux Development Platform
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.
...you might also want to get GNU Autoconf, Automake and Libtool. 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.
The Army reading list
... 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
Physicists get Hadrons!
I'm sure this book will be quite valuable when they translate it to Hindi.
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.
Lodragan Draoidh
The more you explain it, the more I don't understand it. - Mark Twain
Kylix / C++ BuilderX
Why does the kernel go through stable and then unstable forks? Can't it always be a stable build, like with Windows?
As a matter of fact it also a question of how you phrase your question. If I'd asked: Most people wouldn't have a problem. Personally I'm just curious. Besides which, what use is money when you've got Karma? (Yep my Karma just jumped to excellant today, WAHOO!)
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?
BSD is designed. Linux is grown. C++ libs
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?
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
free ipod and free gmail!
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!
Mod down posts with a "Free Mac Mini/iPod" sig, they're spam!
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. A very good text to get you started in Unix programming.
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.
"The legitimate powers of government extend only to such acts as are injurious to others." Thomas Jefferson.
We'll call it GNUDE! That'll make it hot.
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?
Moderator hint: a comment is neither "Flamebait" nor "Troll" if it is true.
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.