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.
Need to do web development? Try Zend + PHP
Driver or hardware layer coding? emacs/vi/gas/gcc
Cross-platform application? Java + eclipse
"...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
Kylix died a long time ago. From my understanding it sucked compared to Delphi and Borland never really supported it. Not trolling because I really wish it was still around. I just recently had to convert a lot of old Delphi code to linux so I had to translate it to C. Not hard work, but time consuming. If I could have just dumped it into Kylix it would have made life a lot more simple, and saved me a couple months.
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!"
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...
Ask a professional programmer, and a good source control system should be high in the list.
XEMACS, EMACS, KDEVELOP, Glade, hmmm... all I got to say is N00B!
And a memory debugger? I'm what you would call a professional programmer, and if you ask me if you need a memory debugger to start writing programs, then no, you don't.
Yes, Valgrind is great, and yes, I'd give it to any starter who needs to write something in C. But most programs would be better off written in some other language, like Python or Perl (or if you want or need static typing, I'd recommend something like SML or O'Caml). Or even Java. And I'm glad to claim that a huge portion of recent quality software for high level tasks is written in some language where you don't need the memory debugger, and that's the way it should be for high level programs.
The "instructions" given by the "professional programmer" seem in fact quite harmful to me. They make starting to program seem harder than it is. If you need to develop low level programs, then maybe yes, you need a memory debugger - and only then.
In a large crufty codebase, a good test harness may not be easily made. We had unit tests required for checkin at my last job. God I wish we had that where I am now...
As for printing state, depending on the system, printing may not be possible (embedded), or may throw off timing (or whatever) enough to make the problem go away...
A good debugger and skills in using it properly can be a huge advantage.
Awesome furniture, accessories and cabinetry in Santa Rosa, CA: http://humanity-home.com/
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.
Does an IDE make you dumber?
Or does the lack of an IDE just mean most people are turned away without even bothering to try?
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.
This needs to be repeated loudly and often. C/C++ is a great language, but there are only a very few instances where you really need to use it. C/C++ is optimized for making efficient use of hardware resources, CPU and memory in particular. On modern hardware, this is seldom the limiting factor -- you are far more likely to be constrained by I/O (network bandwidth / latency, database queries, etc). If you really need that kind of low-level control or cpu optimization, it's usually isolated to few critical functions -- the majority of the work that wraps those functions is better handled by a higher-level language. Writing an entire application end-to-end in C/C++ is usually a mistake
More importantly, most projects are constrained by PROGRAMMER TIME. A language that optimizes programmer efficiency rather than hardware efficiency provides a bigger benefit for the vast majority of development projects. Why write 100 lines of C or Java code when you can accomplish the same task with 10 or fewer lines of Perl, Python, or Ruby? Programmer productivity really soars when you have an easy-to-use repository of pre-written code modules like CPAN.
Why is it that the proponents of "one nation under God" are so eager to get rid of "liberty and justice for all"?
Shouldn't it be:
and in the darkness bind them : *ld*
I also like:
The first rule of optimization is: Don't do it.
The second rule of optimization (for experts only) is: Don't do it yet.
Of course, in these cases, what they're really saying is, don't start out sacrificing simplicity to achieve what you imagine to be greater performance. When you have achieved correctness in your program, this is a good time to whip out your profiler and actually figure out what does need speeding up. Always measure the before and after performance of your application. Often enough you'll find that your brilliant optimization doesn't speed things up at all, or worse yet, makes it slower.
# (/.);;
- : float -> float -> float =
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.
Personally, I don't mind operating without an IDE... I've done it before, do it all the time... I'm more likely to fire up my handy text editor for quick edits than to load a big IDE... However, a good IDE can improve productivity... Integrated source control is another nicety (though, I don't like source safe.. usually better to have a SVN/CVS plugin).
There are a lot of monkeys trying to write code out there, I will agree with that.. but I don't blame the tools so much for that, as I blame the twits who think they can be awesome coders because they saw some ignorant fool in a movie playing a l33t h4X0r role... Or think that being a web programmer is the key to making the big bucks. The advertising that technical trade schools push out is equally, if not more to blame... Sure, we can shove enough knowledge to pass an MCSD exam into your head in a few weeks, but won't actually teach you how to use that knowledge... It's all crap.
Michael J. Ryan - tracker1.info