Slashdot Mirror
Linux Programmer's Toolbox
Ravi writes "What does it take to start writing programs for Linux? Most people will guess a text editor, knowledge of a programming language, the compiler and libraries of that language. Ask a professional programmer and he will differ with you. Insisting that while those things can help get you started, other things come into play in writing efficient programs such as, a debugger, memory profiler tools and above all a good understanding of the inner working of the Linux kernel and its processes." Read below for the rest of Ravi's review.
Linux Programmer's Toolbox
author
John Fusco
pages
622
publisher
Prentice Hall
rating
9
reviewer
Ravi
ISBN
0132198576
summary
Teaches you the use of tools which help you become a better Linux programmer
The book The Linux Programmer's Toolbox by John Fusco is a storehouse of knowledge, which aims to make the average Linux/Windows programmer aware of the tools at his disposal, that can help him write better programs for Linux. The book is divided into 10 distinct chapters with the first 4 chapters describing various ways of boosting ones productivity while writing code.
In the very first chapter titled "Downloading and Installing Opensource tools", he talks about the different archive formats commonly used in Linux, various package managers such as Debian's own apt-get, Red Hat's Yum and how to properly authenticate the packages you download to ensure that they are not tampered with.
The second chapter deals with building tools from source. Here apart from describing the actual steps involved in compiling the sources, the author also delves into explaining the concept behind the MakeFile, the common variables used in implicit rules and so on. In this chapter one also gets to acquire an understanding of the tools used to create projects as well as examine how these tools work together in the build process.
The book has a chapter exclusively devoted to explaining ways of ambulating through the myriad of documents; tools such as man, info, as well as some of the not so obvious ones. One thing I like about this particular chapter is how the author has provided tables which list a number of recommended manual pages with a short description of each of them.
Linux doesn't have a comprehensive IDE on the lines of Microsoft Visual Studio to develop programs — at least not yet. Most Linux programming gurus are perfectly at home with coding using their favorite text editor. Any book of this stature would be incomplete without a mention of the different editors available for coding in Linux and their pros and cons. The 4th chapter of this book introduces the different editors including Vim and Emacs. There are numerous tips in this chapter to make writing code more efficient, productive and a pleasant experience for the average Linux programmer. As a Vi enthusiast, I couldn't help but admire how one can convert Vim editor to work as a code browser with the help of Ctags which is explained in detail.
The fifth chapter titled "What every developer should know about the kernel" is a turning point in the book and gives a comprehensive understanding of the working of the Linux kernel. It is by far the largest chapter — with nearly 100 pages devoted to this topic. In this chapter the author talks in lucid detail about the different modes in Linux, the process scheduler, device drivers, the I/O scheduler and the memory management in user space, understanding all of which is instrumental in writing better programs for Linux.
The next two chapters deal with Linux processes and the communication between processes. Here one gets to know more about the technical vagaries related to processes such as forking, cloning, process synchronization and the basics of inter process communication. The author has introduced several APIs and basic examples of each.
In the 8th chapter, the author introduces many tools that are installed by default in most Linux distributions which aid in debugging communication between processes. The tools include (but are not limited to) lsof, fuser, stat, hexdump, strace and so on. Each tool is accompanied by its usage and its output with a short discussion of the output.
In the 9th chapter titled "Performance Tuning", one gets to know more about fine tuning a Linux program. Here the author explains the factors affecting system performance as well as the tools for finding system performance issues.
Finally, the last chapter of the book explores some of the most common debugging tools and techniques for Linux. More specifically, I found the discussion on the use of GNU debugger quite informative.
At the end of each of the 10 chapters in the book, the author has provided a short synopsis of the tools that are used. Also many additional online resources have been listed where one can acquire more knowledge about the topic being covered. Throughout the book, noteworthy sections have been highlighted in dark background which makes it quite eye catching and also easy for quick reference.
The book is written with a slant towards the C language especially when depicting the examples in the latter half of the book, which can be understood considering that the bulk of the Linux kernel has been written using C.
Most programmers with a Windows background will be forced to make a paradigm shift while embarking to program for Linux. While the Windows programmers are used to taking deceptive comfort within the cozy confines of a Visual IDE, when they make the shift to write Linux programs, they are suddenly faced with the hard facts of programming as it really is. This book could be an ideal companion for this set of programmers who wish to lessen their learning curve and make programming for Linux a much more pleasurable experience.
I found this book to be an excellent resource for programmers (not necessarily only those with a Windows background) who wish to develop programs for Linux.
Ravi Kumar is a Linux enthusiast who maintains a blog related to Linux, Open Source and Free Software at linuxhelp.blogspot.com.
You can purchase Linux Programmer's Toolbox from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
The book The Linux Programmer's Toolbox by John Fusco is a storehouse of knowledge, which aims to make the average Linux/Windows programmer aware of the tools at his disposal, that can help him write better programs for Linux. The book is divided into 10 distinct chapters with the first 4 chapters describing various ways of boosting ones productivity while writing code.
In the very first chapter titled "Downloading and Installing Opensource tools", he talks about the different archive formats commonly used in Linux, various package managers such as Debian's own apt-get, Red Hat's Yum and how to properly authenticate the packages you download to ensure that they are not tampered with.
The second chapter deals with building tools from source. Here apart from describing the actual steps involved in compiling the sources, the author also delves into explaining the concept behind the MakeFile, the common variables used in implicit rules and so on. In this chapter one also gets to acquire an understanding of the tools used to create projects as well as examine how these tools work together in the build process.
The book has a chapter exclusively devoted to explaining ways of ambulating through the myriad of documents; tools such as man, info, as well as some of the not so obvious ones. One thing I like about this particular chapter is how the author has provided tables which list a number of recommended manual pages with a short description of each of them.
Linux doesn't have a comprehensive IDE on the lines of Microsoft Visual Studio to develop programs — at least not yet. Most Linux programming gurus are perfectly at home with coding using their favorite text editor. Any book of this stature would be incomplete without a mention of the different editors available for coding in Linux and their pros and cons. The 4th chapter of this book introduces the different editors including Vim and Emacs. There are numerous tips in this chapter to make writing code more efficient, productive and a pleasant experience for the average Linux programmer. As a Vi enthusiast, I couldn't help but admire how one can convert Vim editor to work as a code browser with the help of Ctags which is explained in detail.
The fifth chapter titled "What every developer should know about the kernel" is a turning point in the book and gives a comprehensive understanding of the working of the Linux kernel. It is by far the largest chapter — with nearly 100 pages devoted to this topic. In this chapter the author talks in lucid detail about the different modes in Linux, the process scheduler, device drivers, the I/O scheduler and the memory management in user space, understanding all of which is instrumental in writing better programs for Linux.
The next two chapters deal with Linux processes and the communication between processes. Here one gets to know more about the technical vagaries related to processes such as forking, cloning, process synchronization and the basics of inter process communication. The author has introduced several APIs and basic examples of each.
In the 8th chapter, the author introduces many tools that are installed by default in most Linux distributions which aid in debugging communication between processes. The tools include (but are not limited to) lsof, fuser, stat, hexdump, strace and so on. Each tool is accompanied by its usage and its output with a short discussion of the output.
In the 9th chapter titled "Performance Tuning", one gets to know more about fine tuning a Linux program. Here the author explains the factors affecting system performance as well as the tools for finding system performance issues.
Finally, the last chapter of the book explores some of the most common debugging tools and techniques for Linux. More specifically, I found the discussion on the use of GNU debugger quite informative.
At the end of each of the 10 chapters in the book, the author has provided a short synopsis of the tools that are used. Also many additional online resources have been listed where one can acquire more knowledge about the topic being covered. Throughout the book, noteworthy sections have been highlighted in dark background which makes it quite eye catching and also easy for quick reference.
The book is written with a slant towards the C language especially when depicting the examples in the latter half of the book, which can be understood considering that the bulk of the Linux kernel has been written using C.
Most programmers with a Windows background will be forced to make a paradigm shift while embarking to program for Linux. While the Windows programmers are used to taking deceptive comfort within the cozy confines of a Visual IDE, when they make the shift to write Linux programs, they are suddenly faced with the hard facts of programming as it really is. This book could be an ideal companion for this set of programmers who wish to lessen their learning curve and make programming for Linux a much more pleasurable experience.
I found this book to be an excellent resource for programmers (not necessarily only those with a Windows background) who wish to develop programs for Linux.
Ravi Kumar is a Linux enthusiast who maintains a blog related to Linux, Open Source and Free Software at linuxhelp.blogspot.com.
You can purchase Linux Programmer's Toolbox from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
And a true hate for Windows OS.
"Please, shut up. Just when I think you can't say anything more stupid, you speak again." -Archie Bunker.
one compiler to compile them all : gcc
one debugger to debug them all: gdb
one memory profiler to profile them all: valgrind
and in the darkness bind them : *EMACS*
"...While the Windows programmers are used to taking deceptive comfort within the cozy confines of a Visual IDE,..."
Deceptive comfort? And here I thought the visual IDE to be just as valid a tool as anything else, that being the one that solves the need of the programmer. Silly me. I guess I need to overdevelop my zealousy in computing.
Bearded Dragon
No folly is more costly than the folly of intolerant idealism. - Winston Churchill
I can't believe in this day and age someone would recommend starting with vi/vim. It's such an archaic modality. I'm not saying you can't be productive in vi (I used to be extremely proficient) or shouldn't know how to use it for emergencies, it just makes the entire system seem antiquated and stupid if you tell people that's how to code stuff in Linux. "Here's this crappy text-based editor, and then you can use these other command line tools to compile and then debug your program in text mode. Linux is pretty advanced!"
If you want to move into the murky world of C/C++ development these are IMHO the basic tools:
There are many more tools but those are good start. It also helps to have a thick skin, getting to know which library does what, being persistent and making heavy use of search engines rather than posting every problem to mailing lists and newsgroups. Also remember that a lot of enterprise grade software can be had for free under various conditions. Just to name two examples... OS X actually ships with the Xcode development suite and Oracle offers various developer suites as well as many of it's products for download under a development license if you sign up for an Oracle account.
Only to idiots, are orders laws.
-- Henning von Tresckow
Note: for faster performance you should remove all brake points in your release build.
...following the principles of Heisenburger's Uncertain Cat...
Actually, a decent logging system goes a long way towards making a debugger unnecessary. They're a good tool to have, but if you're spending more time in the debugger than you are writing code, you're doing it wrong.
A profiler, though, should be mandatory. I remember the first time I used one, I was able to improve my code to the extent that over 90% of its run time was spent in the database driver. It's also educational to do things like move loop invariants (which the compiler should do for you) and see how much your code's efficiency improves. Playing around with code and a profiler is pretty much the only way you'll learn what things really improve performance, and which are just folklore.
Just junk food for thought...
All in all, the book gives suggestions that will help you get a good grade at CS, and maybe Software Engineering, but probably not more formal courses (too little emphasis on the thinking part). It will help you write good programs, without a doubt, but not great programs and certainly not masterpieces. Nor will it help you with the history of programming (programmers predate text editors OR debuggers) or the future of programming (this book is only marginally useful on fourth- and fifth-generation languages, RAD, specification compilers, massively parallel programs, fuzzy logic, self-modifying code, and other such fun stuff).
All in all, there will be many people who will get great value from this text, but they will never be language-agnostic and they will never write the truly brilliant software that they are quite capable of. Yes, it's easy to criticise and harder to do, and it's most unlikely I would ever write a computer book. Mostly because nobody would be able to understand it - my writing style is hard enough to follow on Slashdot, I can guarantee you'd see people jumping off bridges if faced with 500+ pages of my degenerate writings. However, the fact is that there are many good books for novice programmers who want to be adequate, a few for adequate programmers to unlearn bad habits and become good programmers, far fewer that skip the middle step and go straight to good, and none at all that show someone how to go the extra mile that turns something good into something amazing.
That's the book I want to see someone write, and get reviewed on Slashdot.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Emacs would make an excellent operating system, if only if it had a good editor.
"Premature optimization is the root of all evil"
Ben Hocking
Need a professional organizer?
Ask a professional programmer, and a good source control system should be high in the list.
Saying that Java is good because it works on all platforms is like saying that anal sex is good because it works on all sexes.
/duck
Crappy by what standards? Since when is a powerful text-based editor bad for editing text? I was raised on the Visual Studio IDE, but as soon as I discovered vim I jumped ship and have never returned. I find vim/make/gdb to be a far easier/faster/more convenient way to code. However much of an "archaic modality" this is, it is superior for my needs, and something that I encourage any coder to at least try.
I acknowledge that the "command line" part of the equation may cause problems for debugging GUI programs, that it may be subpar for managing a large number of files, etc. Indeed, it certainly isn't for everyone or every task; however, for the majority of the data-slinging / scientific computation / non-graphical coding and development I do, I wouldn't use a visual IDE if I was paid. The reason why I believe Linux is pretty advanced is because it supports an array of powerful tools like vim, make and gdb.
If we start buying CDs then the terrorists have already won.
What a fantastic fantasy world to live in. Did I miss something, or is the software that millions of people run worldwide on Windows PCs somehow not 'real software'? Did the Windows developers who wrote large and/or mainstream applications such as Word, Photoshop, Quark, Winamp, Skype, etc somehow not actually know how to program?
I really would like to hear more about these 'hard facts' of programming...it makes it sound like it is harder to program for Linux - is this supposed to be a good thing? However, I don't believe this, and suspect it's the usual macho Linux bullshit that some F/OSS advocates seem to be afflicted with.
Luckily the rest of us can just get on with programming our software for whatever platform using the most appropriate tools, instead of banging nails in with our fists.
A statement like "[VIM] just makes the entire system seem antiquated and stupid" is foppish and itself ignorant. If text (and keyboard input) is antiquated, then I guess we should all get out of the programming game. Maybe do a little LabVIEW and then commit mass suicide.
In a way, [G]VI[M] and EMACS each represent a club. Clubs of people who took the temporary productivity hit to learn a difficult tool (and possibly put in extra hours to still make the deadline) with some promise of greater productivity in the end.
Is it a false promise? Maybe. There may be a little elitist ego in there, too, but I'd like to think that many who have learned those tools are people willing to put in effort for overall efficiency, and it seems to me to have been beneficial.
Each time I've coded a different "language" (Verilog, C, C++, javascript, Python, Magic VLSI text files, shell, SVG, POV-Ray, bill-of-materials files, SPICE models, config files, etc.) VIM has been there for me, equally handy and powerful. But it didn't look as pretty as Visual Studio, so I guess I shouldn't bother to tell anyone about it. And remember, these are not necessarily tools for a first-time programmer, but for a first-time Linux programmer.
I found that the C++ development was difficult if the project size was too large. The "build automatically" feature was hopeless if it was turned on. It fires every time you save a file and usually didn't finish before the next save if you were doing tweaks. Autocompletion got to be extremely slow as the symbol tables increased, though that might have been partially to the templates I was using. Without those features, a lot of the appeal for Eclipse went away for me.
The caveats are that I was using the gcj compiled version that came with FC4, and was using this when FC4 was current. It may have gotten better, but C++ is such a complicated language there may still be issues.
Kdevelop is very close to VS in features, and much better than Eclipse for anything other than Java. I have done lots of development in C++, PHP, and Python using kdevelop.
It's hard to tell if it's kdevelop itself that's better, or if I'm comparing Qt with MFC, but for me at least, developing in kdevelop is several times more productive than in Visual Studio.
Besides, the fact that Qt is now very well integrated with Python brings even more productivity because we do not need to use C++ for GUI development. I don't know how well Visual Studio handles GUI development in Python, but I certainly do not miss the old days when I did develop for Windows using MFC and C++. Even better, there is PyQt for Windows, so you can do multiplatform development in kdevelop.
In my experience, the most productive platform for code development is a kubuntu machine with kdevelop creating Python code with Qt, using C libraries where needed. For integrating C libraries in Python I use swig.
Yes, I'm elitist. That's because it's the only logical position to take. The human race is never going to advance until we abandon our pathetic obsession with the blatantly untrue claim that everyone has equal potential, and acknowledge that most technical jobs require special skills that only a fraction of the population will ever possess. (Until we grow mature enough as a species to accept the harsh reality that eugenics is the only way we will ever put an end to poverty, overpopulation, and all the other major sources of suffering in the world.)
But I digress. To put it bluntly, programming is actually very hard, and no visual IDE, however "sophisticated", will give monkeys the ability to do it properly. So they should find jobs they are actually capable of, like stacking shelves or flipping burgers or swinging from tree to tree like nature intended, and leave programming to the intelligent elite, who, being intelligent, are capable of learning to use difficult-but-powerful tools like emacs or vim properly and thereby being vastly more productive than the monkeys who rely on point-and-drool crap like Visual Studio.
Mod me "troll" or "flamebait" if I've hurt your feelings, mod me down into oblivion if you can't handle what I've got to say - but you know it's true.