Linux Application Development

r3lody (Raymond Lodato) writes "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. The book Linux Application Development, 2nd Ed., by Michael K. Johnson and Erik W. Troan provides much of what you need to know within its sturdy covers. Pitched to the intermediate to advanced programmer, all of the basic programming APIs are covered -- some in detail, some in brief." Read on for the rest of Lodato's review of this book. Linux Application Development, 2nd Ed. author Michael K. Johnson and Erik W. Troan pages 736 publisher Prentice Addison-Wesley Professional rating 9/10 reviewer Ray Lodato (rlodato AT yahoo DOT com) ISBN 0321219147 summary Covers just about everything intermediate to advanced programmers need to interface with Linux from their applications.

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.

Comments

question

[3cpo]

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.

Re:question

[l4m3z0r]

man pages are notoriously bad, and are all but useless unless you want a haphazard and incomplete list of features without proper examples(this is key in my opinion).

If anything in the OSS/Linux world needs some more thought it is the horrid man pages.

Re:question

[Wudbaer]

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.

Re:question

[l4m3z0r]

And mods, PP was not informative, it was a troll. (Did you look at the guy's user name?)

What does my user name have to do with the quality or content of my post? It's people like you who mod based on username or sig that make /. moderation the horribly biased and awkward system that it is.

I find it funny I'm branded troll for offering my opinion that man pages are inadequate. When someone says RTFM they more generally mean go online and look for real documentation as man pages rarely if ever cut it.

I wonder how I'd be branded if I further voice my opinion that xwindows needs to be replaced by something newer and fresher because the X code base is a disgusting hackjob. But hey my opinions shouldn't be judged on merit they should instead be judged on my user name, uid, race, religion, creed, political affiliation, sig, anything else you can use to toss a label on me.

Review?

[Anonymous Coward]

You call this a review? It's more like a table of contents. "This book covers X, Y, and Z." How's the writing quality? How good are the examples?

Re:Review?

[Anonymous Coward]

That's because the poster only want to get his referal link clicked!

Application development?

[DrXym]

I would expect a book about application development to concern itself with such matters as how to create a window, draw buttons, respond to keystrokes, draw graphics and well... how to write applications. As in, how to write graphic user interface programs. That is what most people would interpret the title to mean.

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.

Re:Application development?

[MikeBabcock]

You've never written Linux applications have you? How many GUI apps are on a Fedora Core 3 installation vs. command-line apps?

How many of those GUI apps use tools from this guide, in spite of being GUI-oriented?

Knowing how to write *nix applications without concerning one's self with the GUI is a necessary issue, regardless of the end-target.

Consider also that "drawing buttons" is done entirely by libraries that handle such things for you if you know what you're doing and you'll realize most of what you're looking for just isn't programming, its GUI design -- and shouldn't be done by programmers anyway. See grip for evidence.

Re:Application development?

[DrXym]

An application is generally considered to be a program with a user interface. Most people would reasonably expect a book with a title Linux Application Development to cover development of such programs. It doesn't.

Perhaps the distinction wasn't so obvious in 1998 or whenever the first edition came out, but it is now.

Fedora does contain console apps such as vi, emacs, mc, etc. that run through curses and respond to user input, but the vast majority are GUI based applications.

Command-line programs like grep, ls etc. are tools, not applications. Programs like sshd, inetd, apache etc. are daemons, not applications.

Re:Magic

[th1ckasabr1ck]

Just because the part about security comes last in the book doesn't mean that it is any more or less important.

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.

Re:Magic

[Anonymous Coward]

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?

The Art of Unix Programming..

[rjshields]

.. gives a good overview of the subject

http://www.faqs.org/docs/artu/

Re:The dedication turned me off.

[pclminion]

The first edition carries a dedication by Mr. Johnson, which reads "To the memory of my grandmother, Eleanor Johnson, who taught faith in God by example. . ." Proselytization is repugnant wherever it is encountered; between the covers of a science text it is inexcusable.

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.

Re:The dedication turned me off.

[InstBrad]

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

[Cryptnotic]

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

Good introduction aggregates appropriate man pages

[Anonymous Coward]

I found the book an excellent introduction to... well, Linux Application Development.

To become productive on a platform, you need to know what that platform is fundamentally capable of, and the APIs that provide access to that functionality. And, as a programmer, I find a quick and well-ordered tour through key APIs the best way to get a handle on both before diving in to some serious development.

Now man pages become useful - now that you know what you _can_ do, have a rough idea of the platform's design philosophy and capabilities, and so you know where to start looking with man.

Re:Isn't it time to move on?

[MightyMartian]

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.

autotools ?

[savuporo]

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 ?

Sophisticated?

[callipygian-showsyst]

The Linux operating system provides a sophisticated framework for running programs

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.