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

Blulhsit

[DoofusOfDeath]

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

You need to know about kernel internals to start writing programs on Linux? Sure - maybe if you start your programming on Linux by writing device drivers.

One out of 20, at most, projects I've done on Linux required anything more than an editor, a compiler, and the "print" statement. It's not that I write simple programs, it's just that in real life these usually end up being sufficient (especially if you program in Python or Java as opposed to C or C++).

Re:Blulhsit

[bmk67]

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. I've been developing system applications for close to 25 years now, and I have found that this philosophy serves me well. I rarely use a debugger, I know how, but I have found that good application logs and a working knowledge of the source code allows me to debug code much quicker than a debugger does.

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. You're correct that modern compiler optimizations takes care of most of this. Profilers are useful, though perhaps not as useful as they used to be. I personally have not used one in years, with experience, you come to write fairly optimized code the first time through and the additional time spent profiling and refactoring isn't worth the effort if an experienced coder has done his job right. This is coming from someone who spends most of his time writing I/O intensive applications, not computationally intensive applications, so YMMV of course.

Re:IDE for Linux, yup

[dvice_null]

> There are several IDE's for programming on a linux system.

Code::Blocks is quite decent for that purpose and I personally use it. With other things, it offers a visual debugger (you can add brake points to the code and then step the code in the code view line by line and see the values of the variables). This is with the latest svn build at least. Haven't tried the stable version. http://www.codeblocks.org/

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.

I'll go a step further

[benhocking]

Back when we had to write code that would fit in about 590k or so, we would employ all sorts of "tricks" to reduce memory usage. The result was that the code was usually less readable and arguably more complex than it would otherwise be.

Short and Sweet

[Anonymous Coward]

Bloodshed Software - Dev-C++ (A free C++ IDE for Windows and Linux for MinGW/GNU compiler.)
or
SciTE (Scintilla Text Editor with Extensions) platforms include Windows,Linux,and Mac

Both travel well on USB 2.0

Be Safe and Good Hunting...

Re:IDE for Linux, yup

[Anonymous Coward]

And what about Ultimate++ ? ( http://www.ultimatepp.org/ )
It is a C++ cross-platform IDE and GUI
with multiple compiler support, visual designer,
with integrated code analysis and trasformation tools
debugger support integrated in the IDE, etc. etc.
Check the web site to see the Chameleon skinning support
( http://www.ultimatepp.org/www$uppweb$chss$en-us.ht ml )
lots of example applications
( http://www.ultimatepp.org/www$uppweb$examples$en-u s.html )
and full documentation for everything.

Re:All of these...

[Yoozer]

I'm honestly not trolling here but could you elaborate on that? (or is it one of those "if you have to ask, give up right now" things? ;) )

Re:All of these...

[jlarocco]

Personally, I find programming under Linux orders of magnitude more enjoyable than under Windows.

First of all, the tools are better. There are compilers, debuggers, IDEs, profilers, memory leak detectors, unit test frameworks, UML modelling programs, documentation generators, parser/compiler generators, GUI designers, version control software, and just about any other tool you can imagine. Those things all exist for Windows too, but they're usually really expensive and don't work together as well as the Linux software.

And the programming APIs are a lot better. Posix is huge, but it's well documented, and it's followed closely enough by all the Unix and Unix-like operating systems. There are differences and incompatibilities, but they're almost always documented.

Then there are perks like the shell and command line tools. The Unix shell and related tools (grep, awk, sed, sort, ...) are incredibly powerful and IMHO unrivaled by anything on Windows. I have to use Windows at work, and almost every day I find myself doing some simple task that takes 3x longer than it should, simply because I don't have a decent shell.

Overall it probably comes down to personal preference and "If you have to ask...", but it's not all machismo.

Re:A lot of good "Linux" IDEs exist

[tomhudson]

I hope I never go back to an IDE, unless its something along the lines of Borland's text-mode BC++/Turbo C version. It never "got in my way." My current "IDE" is a half-dozen shells opened at different parts of my source and release tree so I can run vi to dash of a quick 2-liner shell script or perl script, run ctags or mc; several copies of kate with different session hsitories, on different monitors; firefox for quick web searches (and to pop in on /.); and kopete so that everyone in the office can communicate. An IDE? My desktops ARE my IDE.

The only tools you REALLY need:

1. Multiple shells open, each with its own command history, so you can jump back and forth;
2. Text editor of choice that does syntax hilighting and code folding (vi, kate);
3. make;
4. some perl script fu, and some bash scrpt fu, and some python snake oil (great for automated testing);
5. mc (F2, 3 is handy for making quick tarballs);
6. a net connection so you can look up stuff fast;
7. IMPORTANT: a shelf full of O'Reilly books - do NOT skimp;
8. 2 or more monitors - this is an almost absolute necessity for serious coding;
9. a project wiki to keep track of things, etc.,
10. fgrep -n, ctags, doxys for a first peak at other people's code

Also, not a tool but equally essential: plenty of liquids (coffee, soft drinks, booze).