Slashdot Mirror
Linux Application Development
The overall structure has the book divided into four major parts: Getting Started, Development Tools and Environment, System Programming and Development Libraries. Part 1, Getting Started, is a very high-level overview of Linux itself. The three chapters cover barely 20 pages, and discuss the history of Linux, its licensing, and the online documentation.
Part 2, Development Tools and Environment, gets more detailed, but ends up as a medium-level view of what tools you might use to actually create and debug your application. Six chapters covering about 75 pages discuss editors (Emacs and vi), make, the GNU debugger gdb, tracing, gcc options, glibc, memory debugging tools, libraries, and the environment. Each chapter feels a little lightweight except for the one on memory debugging tools. Here the authors dive into the common issues of buffer overflows and underruns, and the various utilities you can use to discover them. Not only the glibc features mcheck(), MALLOC_CHECK_ and mtrace(), but the memory profiler (mpr), Valgrind, and Electric Fence are discussed in enough detail to be useful.
If the first two parts seemed to just skim the surface somewhat, Part 3, System Programming, definitely dives into the deep end of the pool. Each chapter covers its topic in detail, and many code examples are given to clarify the concepts. Part 3 has 13 chapters and covers 450 pages, almost two-thirds of the total book. My major complaint with Part 3 is that related chapters appear to be separated by others. I will discuss them as I see the relationships.
Chapter 10 covers the Unix/Linux process model. Signals, job control, processes and threads are explained in detail. The authors also describe the 'gotcha's involved with setuid and setgid programs. The chapter ends with the first iteration of a sample shell program, ladsh. This shell is expanded as the book progresses to explain newer concepts. This topic should be followed by chapter 15 (Job Control), which goes into job control, including how to stop and start processes, move jobs between the foreground and the background, and handle job control signals.
Skipping back, chapter 11 introduces the file handling metaphor and how it relates to files, pipes, directories, devices, links, and sockets. It also explains inodes, file permissions, file descriptors, and the read/write/seek system calls. Chapter 13 expands on chapter 11 by discussing the advanced topics of multiple file handling, memory-mapped files, file locking, and scatter reads/gather writes. The next chapter goes over directory operations, such as handling the working directory, file name globbing, walking trees and directory change notification.
Signal Processing (chapter 12) discusses simple interprocess communication including signals and handlers. It describes the Linux and POSIX Signal API, real-time signals, and how to transmit data with a signal. Remote interprocess communication occurs over sockets. Chapter 17, Networking with Sockets, shows how to use the socket API, which can be used for IP, IPX, AppleTalk and Unix domain sockets. Michael and Erik show how to write a client and server, how to handle name resolution, the differences between session (e.g. TCP) and datagram (e.g. UDP) communications, and finish with an example tftp server.
Obviously, many programs need to interact with the user, and that's where chapters 16, 20, and 21 come into play. Chapter 16 talks about terminals (tty) and pseudo terminals (ptty) and how to program them. The POSIX termios interface is discussed in depth. Chapter 20 gives you tools to manipulate virtual consoles, which create the abstraction needed to multiplex different sessions on the same keyboard, video, and mouse. The following chapter talks about the Linux Console including text-based screen-drawing with S-Lang and curses, the terminal capabilities (termcap) and terminal information (terminfo) databases, ANSI Escape sequences, as well as direct screen writing.
Chapters 18 covers basic system calls for time/date representation and formatting and timer usage, and chapter 19 covers pseudo-random number generation and its use in cryptography. Finally, part 3 wraps up with chapter 22 discussing how to write secure programs. Common exploits such as buffer overflows and unauthorized directory traversals, and the ways you can prevent them (length checking and chroot, for example) only scratch the surface. The authors recognize this is just an introduction and refer you to another book to fill in the blanks.
The final part of the book covers the various development libraries commonly available to the programmer. The six chapters cover a wide range of topics. Chapter 23 covers the ins and outs of string handling, including processing regular expressions. A simple grep program demonstrates the ideas. Using S-Lang to handle the terminal is the main interest of the next chapter. Basic input/output handling, and line drawing using text characters seem mundane in this day and age of GUI interfaces, but they have their place. Check out a Red Hat install to see what I mean.
Chapter 25 discusses database interfaces. While gdbm and Berkeley db are better known, Michael and Erik chose to focus on qdbm, which is licensed under the LGPL, making it more attractive. Linux programmers are used to typing in commands with all of their options. Getopt and getopt_long are the standard for processing those options, but popt is detailed due to its extended capabilities, such as nested options which allow libraries to define options for them to handle which the main program can effectively ignore.
The final two chapters cover dynamic loading of shared objects (as opposed to shared libraries) with the advantages that provides, and user identification and authentication, covering id-to-name translation, and Pluggable Authentication Modules (PAM). As usual, example code shows clearly how to use the interfaces.
I know this review is lengthier than usual, but this book has so much packed within its covers, I didn't want to give short shrift to any part of it. When programming, one needs a number of reference books at hand, and Linux Application Development should definitely be one of the handiest. Just about every aspect of how to interface to Linux from your application program is covered, and the numerous code snippets and examples keep things understandable. An extremely useful book such as this deserves a high ranking. My only concerns were how the first two parts seemed skimpy compared to the rest of the book, and the part on System Programming could have been laid out better. That said, Linux Application Development rates a 9 out of 10.
You can purchase Linux Application Development, 2nd Edition from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Just FWIW, I reviewed LAD2 in LWN about a month ago.
Jonathan Corbet, LWN.net
"Finally, part 3 wraps up with chapter 22 discussing how to write secure programs" How come the "secure" part of coding, perhaps one of the most important parts of coding, is always last in the book?
Earn a free iRiver
Because the man pages are good references (most of the time at least) but not good for learning ? You don't try to learn a language by reading the respective dictionary from front to back either, don't you ?
I see the greater problem in the fast pace of Open Source development. Lots of books especially on new and developing topics are already outdated once they appear on the shelves.
While such things as pipes, regular expressions, setting date & time etc. are all fundamentals of any kind of programming, it seems a more apt name for the book would be Linux Command-Line Application Development, or Linux Daemon Development.
Maybe the author feels that in order to get the most out of a chapter about writing secture programs you first need a good base in the things discussed in earlier chapters.
> Because man(page)s suck.
I have to agree, man is not like it was in the old days. Manpages and a few AT&T reports and the 'C' book was all you needed.
But thats was then, and now is now, with all sorts
of stuff hidden away in info pages or some confounded desktop system. Its much harder to
find the clues you need to get things done.
I ended up finding what I needed in the man pages for various memory-related system calls, and in the very good but older Interprocess Communications in Unix by John Gray.
Please, do not rely upon the "Linux Man Page Howto". For example, in the "few thoughts about documentation", the following guidelines are given:
Documentation must be accessible.
Documentation must be reliable and accurate.
What about "Documentation must be cryptic!!!" Face it - if you're going to go through the trouble of writing a man page, would you rather have your target audience read it once, or tens and hundreds of times!
But proselytization about the evils of proselytization is not? Here you are, in an article about a technical topic, ranting about religion? I'd say that's inappropriate proselytizing, no?
Further:
1. This is not a "science text." Not by any reasonable definition of science.
2. The dedication is a personal statement. It is directed at the dedicatee, not you.
You're either a troll or a dimwit.
That's odd, I spend a LOT of time writing code that ends up in command-line programs. I wonder how I do that, given that you say there's no room for such a thing.
Just take a look on the open-source project where I write the most code, mjpegtools. It's the open-source MPEG2-video (i.e. DVD) creation package. You'll have to look at the CVS version to see my latest contribution, though; it's not officially released yet. It's called y4mdenoise; you can browse the CVS version here. It's a new temporal noise-reduction tool for digital video, that does such a good job of inferring clear images from several noisy examples of them, that it can make a videotape look like it came from a LaserDisc. No kidding.
You remind me of the head of the U.S. Patent Office in 1899, who said that everything that can be invented has been. I wish people like you would get the heck out of the way of people like me.
"Once we've identified and embraced our sickness, we'll have strength...and that's when we get dangerous." - John Waters
I looked on Websters to find the definition of "proselytization". Turns out that it means "to induce someone to convert to one's own religious faith."
So Mr. Johnson was not proselytizing. There was nothing in his dedication that attempted to sway you to his belief system. His grandmother may have been but even that is debatable since she was simply leading by example.
I picked up a number of computer books from my shelf and about half of them had dedications. Some mentioned "love", one mentioned "light of my life". All very untechnical. Do these offend you too? All I can read into your complaint is that you are incredibly sensitive to the idea that someone may discuss something you don't want to hear about.