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

IDE for Linux, yup

[jshriverWVU]

Linux doesn't have a comprehensive IDE on the lines of Microsoft Visual Studio to develop programs

C/C++ use Qt, kdevelop, or gnomes IDE
Java use Eclipse.

There are several IDE's for programming on a linux system. Also you have to define IDE, if you mean VS like then the previous should suffice. But there are also IDE's like rhide, but that is a bit old school.

Re:IDE for Linux, yup

[Constantine XVI]

Eclipse also does Python and C++ via plugins (pydev and eclipse-cdt respectivley)

Re:IDE for Linux, yup

[Doctor Memory]

Likewise, NetBeans does C/C++ and Ruby.

Re:IDE for Linux, yup

[insignificant1]

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.

My tools

[ggambett]

Editor - gedit for syntax highlighting
Compiler - gcc
Debugger - gdb
Mem Checker - valgrind
Build - make and a custom build system written in Python
Image processing - ImageMagick

That's it. Spartan, yes, but it forces me to write good code instead of relying in fancy tools :)

A few tools...

[Savage-Rabbit]

What does it take to start writing programs for Linux? That depends on what you want to do. If you are wanting to develop in Java, PHP, Perl, Python or (dare I say it) .NET you are best of setting up some super user friendly distribution like SLED or Ubuntu and using a GUI tool like Eclipse or NetBeans.

If you want to move into the murky world of C/C++ development these are IMHO the basic tools:

• vim/emacs: Popular command line text editors, deciding which one to choose is like choosing a religion. There are also a few excellent GUI suites.
  
• make: Automate compiling.
  
• gdb: The GNU debugger.
  
• gcc: GNU project C complier.
  
• g++: GNU project C++ compiler.
  
• cscope: Search and navigate through huge code trees.
  
• man: Linux manual pages, the cause of much head scratching.
  
• grep: Limited substitute for some of the stuff cscope does. I love the '-r' option failing that use: find /directory -exec grep "pattern" {} \; -print
  
• doxygen: Like javadoc but less language specific.
  
• goolge code search: Indispensable if you are stuck or need hints on which is the best way to proceed. It allows you to compare different solutions other people have used.
  

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.

A lot of good "Linux" IDEs exist

[benhocking]

Depending, of course, on how one defines that. Regardless, Anjuta is a great IDE for C/C++ coding and Eclipse is a great IDE for Java coding.

Re:A lot of good "Linux" IDEs exist

[NialScorva]

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.

Re:A lot of good "Linux" IDEs exist

[brainhum]

If you're holding yourself out as a programmer, you definitely have to be able to write good code. But technology work is not made up solely of programmers. I work with programmers, *NIX administrators, graphic designers, UI designers, animators, illustrators, subject-matter experts (usually with PhDs in non-technical areas), clients who are not geeks, etc. There are a lot of jobs in technology that do not require you to write any code whatsoever.

It sounds like you are the alpha nerd on your development team, but you have been forced to work with programmers who were sub-par and now you're bitter. Why is that? Maybe the people you work with are new to the industry and fresh out of school. Maybe your company pays crappy wages and can only attract the code monkeys, people with zero interpersonal skills and other deficiencies that force them to only accept lower paying contracts. But, as an AC poster, we'll never know.

Everyone has a different skill set, not all are cut out for coding. There is a place for everyone though; the cubicle down the hall, your parents basement, or even at McDonalds. Some may have a knack for novel algorithms but have trouble attracting mates - not an uncommon affliction among programmers. Don't worry, there is a place for you! As my old Comp. Architecture prof once said: "If you can't get laid, you might as well write some good code."

BTW: My editor of choice is JEdit, and eugenics has been thoroughly discredited except by Nazis and others who are fond of brown shirts. You may want to rethink your affiliation in that regard.

Just remember Knuth's warning...

[benhocking]

"Premature optimization is the root of all evil"

simple and effective KDE tools.

[twitter]

kdevelop is nice, but I don't do a lot of GUI programming. For what I do, Kate and kdbg work great.

Kate is a good GUI text editor and a joy to use. It has a file browser and quick picker for open files. Sessions act like project files, so you can quickly load all the files you need to work on. The editor itself has excellent syntax highlighting, tabs and split screens, so you can see multiple versions of the same file and compare it to others.

Kdbg is a GUI front end to the gnu debugger. It has all the usual things and a few nice extras all workable with a mouse. It has easy to manipulate step through, locals and watches. Variables that change are highlighted in red. One of the neat extras the watches has is the ability to do simple math and return values of functions used in your code. If you have a function dot_ab(a b) that returns dot products, you can put variables you are watching in and get back the answer you want.

Re:Win32 dev bad? NOT for Delphi/Kylix & Win32

[jshriverWVU]

Not sure if it still work or not. You use to be able to download Kylix (free? eval?) and that doesnt appear to be the case anymore. So it's not even that it's not supported anymore, I can't even find it. With no distribution channels there are no legal ways of buying it. In the end would it even be worth it? It might have had potential but alas it's gone for better or worse.

Re:Source control!

[jgrahn]

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

The reviewer didn't seem to mention it but, yes, that aspect is covered. At least according to the Amazon blurb.

What are the major differences, in your opinion?

[benhocking]

I used VS professionally for several years before returning to grad school. Perhaps it has improved a lot since then (I used VS6, not .Net), but I don't see any significant differences between it and Anjuta *or* Eclipse. What features do you think are missing from Anjuta or Eclipse?

kdevelop

[mangu]

In my opinion, linux would be many times more successful if there were something more directly analogous to Visual Studio

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.

Re:Blulhsit

[BillAtHRST]

I hate to be the one to recommend a MS practice, but one of the tenets that "gurus" in the MS world (McConnell, et al.) have regularly espoused, and that is apparently SOP at MS, is that developers have to step through all new/changed code using the debugger.

IMHO, this is one of the best things you can do. Like other things that are good for you but not much fun, I don't do it nearly as much as I should, but every time I do I am rewarded with insights to improve my code that I would not have gotten otherwise.

In the "old days" this was known as "desk-checking" -- actually stepping through your code on paper, even before compiling. With PC's and IDE's a debugger does the job much better by letting you actually see the results of the assignments and tests in a way that is much easier than using pencil and paper.

Not to mention, debuggers come in pretty handy when you actually have bugs...

P.S. I recently debugged a SEGV bug which happened when an app's "shutdown" function was getting called at odd times -- turns out, library code was calling socket's shutdown function (on a separate thread) and because of linkage problems (the app's shutdown was declared extern "C"), that function was being called instead of the socket libraries'. Good luck finding that with printf...

Give me a good (visual) debugger (e.g., ddd) any day...