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
Use emacs.
$50 at Amazon.com, and automatic free shipping.
eclipse.org
... 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!
"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
At some point, somewhere, the entire internet will be found to be illegal.
emacs
I'm sure this book will be quite valuable when they translate it to Hindi.
Vim
i havent seen a good linux ide either(i am checking eclipse.org, from child post), but i dont think that could possibly limit linux to being a tinker toy. for one thing, it isnt one right now...
you are probably correct to some extent, as far as linux on the desktop. if there was a very good ide available, it would make more apps available to the everyday user.
i sell illegal drugs
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?
Also, anjuta
Actually, I'd rather program with "here documents" from a bash shell than go back to microsoft api's. Is there really anyone with extensive programming experience on both windows and linux who would prefer windows?
I agree if you are developing GUI type applications. For
developing non GUI programs Visual Studio is way, way back behind emacs
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
What he really means is that VB does not run on Linux. Of course anyone that has really, really programmed on Linux would not even consider a using Windows machine ever again.
Got Code?
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.
stuff |
At least tinker toys are fun.
I'm not tense. I'm just terribly, terribly, alert.
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!
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.
Don't blame me, I didn't vote for either of them!
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.
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".
-- Thou hast strayed far from the path of the Avatar.
All it takes is licensing the UNIX(tm)
and the arguments can finally go away.
comment directly in my journal
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?
"Talk minus action equals nothing" - Joey Shithead, D.O.A.
"Talk minus action equals
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.
"Thanks to the remote control I have the attention span of a gerbil."
Back before the advent of Mac OS X, my favourite (and for many years, only) development environment was one variety of Unix or another.
Gee, I don't think I'll bother reading the review if the reader doesn't even understand that Mac OS X is yet another variety of Unix.
Remember, don't feed the trolls.
edlin
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.
You would also need to conform to UNIX standards. From what I understand it's not just a label. Don't know if Linux is a UNIX in that regard.
When thinking about it, don't know if i want Linux to be a UNIX (as the first thing you do to a UNIX box is installing 100 GNU packages to get some good programs).
Just do us a favor and get rid of those damned
'--' option arguments. One '-' suffices.
I mean, first you might have a local CVS pull repository and then your own area that you code in. Where is a good place for that? /home would seem good and most backup schemes assume you put your own goodies in there. But if you want to share it, then do you create a "developer" user and have everyone link to it, or what? I guess what I am trying to ask is, how can I best mesh my own personal kludgy way of doing things in a development environment?
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.
I found some additional reviews for this book at this site.