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.
Why so many books cover topics which are described in manuals (I mean man's for linux) ? In my opinion a good book should not repeat those things but describe only structure and philosophy of topic. For further reference you should then read mans.
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 mans suck.
Really, before you mod me down, do you really believe that the majority of mans provide enough information for people just learning the tool?
Socialism: A feeling of discontent and resentment caused by a desire for the possessions or qualities of another.
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.
"Writing Linux applications is not a simple endeavor. The Linux operating system provides a sophisticated framework for running programs, and learning how to take advantage of that framework requires some research." Oh boy, doesn't that just sound like fun.
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.
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.
Compare a book describing the "sophisticated APIs" with a "Visual Basic for dummies".
C'mon guys, where's the RAD for Linux?
The security section is exactly where it should be. You have to understand a system before you can secure it. If you try to secure it before you understand it, you will never make it secure. You a Troll?
My guess is hes an MCSE =)
i thought the apt-get faerie just creates them out of thin air...
pr0n - keeping monitor glass spotless since 1981.
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!
.. gives a good overview of the subject
http://www.faqs.org/docs/artu/
In this world nothing is certain but death, taxes and flawed car analogies.
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.
Embedded does not mean that there is no user, rather it just means that the software is part of a device. That device could be a cable box, a PVR, a radar dislay/interface system in an aircraft, the music browsing interface on your digital music player, or any of dozens of other devices. All of these are embedded systems.
(from someone who does embedded software development).
My other first post is car post.
On more than one occasion I've had to write a command line utility (often in scripting languages like awk, but sometimes compiled) to handle data translation and massaging. To write a GUI application to do this is not only time consuming and wasteful of resources, but also means that I actually have to have a GUI installed and running.
It seems there is an entire generation of programmers that think that everything they write has to have a user interface. The beauty of command line utilities, interpreted or compiled, is that they don't suffer from bloat of either code or usage. In the Windows world, it seems, the command line utility is some inferior life form.
I mean, for Christ's sake, to change basic application parameters, I'm stuck going into the frigging registry editor, while on a *nix box, we have text configuration files, and I can't grab my favorite text editor, alter the settings, kill -HUP the daemon and away we go. I find that Windows and its kazillion GUI frontends and horrific registry are far complex, and the look-alike tools starting to pop up for Samba, MySQL and the like for X on *nix machines are repeating this awful arrangement.
The world's burning. Moped Jesus spotted on I50. Details at 11.
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
Huh ? At this time and age, no mention of automake/autoconf at all or did the review just skip that part ?
Who in their right mind still uses handwritten makefiles ?
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.slashdot.org Errors found while checking this document as HTML5!
Is it sophisticated or poorly designed? Has anyone ever seen an X Application that looked and felt as nice as a native Windows (or Mac OS X) application? Has anyone ever gotten stuff like drag/drop between applications or ICCCM to work correctly? I'd say it's far from sophisticated--it's clunky, ill conceived, and hard to apply effectively.
Best Buy can have you arrested