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.

Comments

All of these...

[Mockylock]

And a true hate for Windows OS.

My ToolBox

[warrior_s]

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*

Which ever tool provides the result

[Ngarrang]

"...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.

Re:A good IDE

[$RANDOMLUSER]

I wish linux did have a great IDE, but i guess Emacs is good enough :)

Great, now all I need is a decent text editor.

I have to say this doesn't sound like a good book.

[jd]

Good programmers think the most, design the cleanest, and write the least. Reusability is paramount, lines-of-code is unimportant. Good programmers also refer to reference manuals, sample code and other snippets, online texts and header files - you only need know A computer language for the structure, the rest can be gained by inference and reference. There is no debugger superior to appropriate printing of state in the code. A source debugger is helpful, but not very - I've got more mileage from debugging libraries and suitable test harnesses. The other tools are useless if you've any level of programming aptitude, except in very specialized circumstances. And even then, not much. I can inspect a binary file better in emacs, as it prints non-printable characters as escaped but leaves ordinary characters alone.

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.

Source control!

[eli173]

Ask a professional programmer, and a good source control system should be high in the list.

Re:Depends on the project

[Anonymous Coward]

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.

The best tool may not be the prettiest

[finiteSet]

I can't believe in this day and age someone would recommend starting with vi/vim .... 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!

While I agree that vim may not be the best place to start, I feel that it is a great place to end up, and I strongly disagree with calling it a "crappy text-based editor."

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.