Advanced Programming in the UNIX Env, 2nd Ed. 128
| Advanced Programming in the UNIX Environment, 2nd Ed. | |
| author | W. Richard Stevens, Stephen A. Rago |
| pages | 927 |
| publisher | Addison-Wesley |
| rating | 9 |
| reviewer | Eater |
| ISBN | 0201433079 |
| summary | Essential classic for experienced C progammers working in UNIX environments |
Few technical authors have had such a great impact on the geek community as Rich Stevens, and because of this, any review of his books should include a few words about the man himself.
Stevens' work typically tops any "recommended reading" list when it comes to TCP/IP networking or UNIX programming. Stevens passed away on September 1st, 1999. In addition to APUE, he authored UNIX Network Programming (Volume 1: APIs and Volume 2: IPC) and TCP/IP Illustrated (Volume 1: Protocols, Volume 2: Implementation, and Volume 3: TCP/T, HTTP, NNTP, Unix Domain Protocols.) Stevens was posthumously awarded the USENIX Lifetime Achievement Award for his extraordinarily lucid teaching and generous spirit within the community, which was accepted on his behalf by his surviving wife and children. (Slashdot coverage of his unfortunate death is available.)
Stephen A. Rago, who has taken on the daunting task of revising Stevens' APUE, worked at Bell Laboratories as a UNIX SVR4 developer. His first contact with Rich Stevens was an e-mail regarding a typographical error in Stevens' first book, UNIX Network Programming. Stevens later acted as a technical reviewer for Rago's UNIX System V Network Programming. Rago reciprocated as a technical reviewer for the first edition of APUE, and has done a fine job of revising that same text for the new second edition.
After more than a decade of changes in UNIX and UNIX-like operating systems, the original edition of APUE holds up well. Rago's revision reflects the following:
- System V variants are being replaced by Linux, Solaris being the last of these with any reasonable market share.
- 4.4BSD was the last UNIX release officially maintained by Berkeley's CSRG, with subsequent derivatives being maintained by volunteers.
- The popularity of Linux and inexpensive x86 hardware has introduced a notable shift in development.
- Apple Computer has abandoned its previous operating system for one based on Mach and FreeBSD.
- The original book was based on the 1990 version of the POSIX.1 standard. The new edition has incorporated changes from the 2001 version.
- Chapters on threads and thread control have been added.
- Some material has been omitted to reflect changes in common hardware. For example, the "Modem Dialer" example from the first edition has been removed, and "Communicating with a PostScript Printer" (which focused on serial and parallel communication) has been replaced with "Communicating with a Network Printer".
The following platforms were used in Rago's edition:
- FreeBSD 5.2.1 on Intel Pentium
- Linux 2.4.22 (Mandrake 9.2) on Intel Pentium
- Solaris 9 on 64-bit UltraSPARC IIi
- Darwin 7.4.0 (Mac OS X, version 10.3) on PowerPC
A comparison of the tables of contents between the first and second editions indicates only minor organizational changes. When delving into the text, it's apparent that Rago has done a painstaking job of reworking the text to reflect the changes over the past 13 years.
Notably, Rago has included a few new helpful tables in the chapter on UNIX standardization. These tables compare the differences among the four platforms he used in writing this edition, making this text rather valuable for those trying to support multiple offerings.
An entirely new part of this edition is two chapters dealing with POSIX threads. Rago presents this material first with an introductory chapter on threads, POSIX.1 primitives available for creating and destroying threads, and a discussion of the fundamental issues when dealing with synchronization between threads. The follow-up chapter is on thread control, dealing with the specifics of synchronization, reentrancy, and thread interaction with process-oriented system calls.
Stevens believed that the best way to learn code was to read code, and his books reflect that philosophy well. The original edition contained a chapter titled "Communicating with a PostScript Printer" that included a complete program to communicate over a RS-232 serial connection to an attached printer. Most PostScript printers today are accessed via a network interface, and Rago has managed to rewrite the material reflecting this while still maintaining the original intent of the chapter. The first edition's chapter on modem communication has been omitted from the new edition, but is still available via the book's website.
This book is no superficial rewrite of the first edition. From cover to cover, it's apparent that Rago has carefully interpreted the original text and rewritten it to accurately reflect the changes of the past 13 years; he has also managed to preserve to original lucid and efficient presentation style of Stevens' classic.
The book's official website is available here, including all source-code examples and errata.
You can purchase Advanced Programming in the UNIX Environment, 2nd Ed. from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
troff/groff? (Score:4, Interesting)
-AP
Re:What I always liked about Stevens (Score:5, Interesting)
"What the hey," I thought. "I'll email him." So I did, and then went to lunch.
Imagine my surprise upon my return when I saw 2 return emails waiting! He explained in great detail what I was doing wrong conceptually, and gave exacting instructions on how to make a certain part work. In the second email, he said it didn't sit well with him to leave me with an "unoptimal solution" (his words), so on his own time he came up with an even better paradigm, and sent actual tested code to implement it!
What can I say? His books will always grace my shelf.
Re:What I always liked about Stevens (Score:4, Interesting)
Stevens as a Textbook - Memories (Score:5, Interesting)
About three weeks into it, though, I realized I was struggling. My lectures were flat and the class really wasn't getting much out of it. I asked Paul Banks, a student who'd taken several courses with me, what I was doing wrong. "You're reading your slides, Kevin. You're not interacting with the subject matter like you usually do."
I realized that, basically, I was intimidated as Hell by Stevens' mastery of the subject. I changed my approach. The next lecture, when there was something I couldn't entirely wrap my brain around, I tried something different. I stepped away from the lectern, sat down in the chair at the front of the class and admitted my ignorance. "I don't have direct experience on this. This is how I think this thing works. Is that how you guys read it?" Sure enough, someone in the class indicated that they'd touched on the issue in their code, but had been confused. The class came alive as my lecture became a discussion, which is my preferred mode of teaching.
Looking back, I guess I owe that success to Stevens as much as the problem (and, yes, the problem was really between my ears, thank you very much...). His books have always been about experimentation as a means of understanding, not dictating down lessons down to the reader. If only I'd taken that tack when I started the class I could have saved myself much trouble. I'm just glad I corrected my approach and that everyone got a lot out of that class.
Paul passed away a few years ago and I was glad that I had made a point of thanking him profusely for his advice. My only regret about the class is that I never did the same to Stevens for APUE.
Re:Another heavy book (Score:3, Interesting)
[minor irritation]
Yes. You are (according to your webpage) an Eclipse developer. This means that you would not be likely to run into OS-specific things any more than a Win32 developer would care about the details of how named pipes are handled on Unix.
I admit that most new lines of code out there are probably internal-use stuff that drive websites. For applications like these, getting the application out with a minimum of cost and use of expensive developer time is important, and if there are other concerns, they lie in the realm of reliability of security. Yes, performance doesn't matter much for systems like these, and it's fine to write these in Java.
However, there *are* those of us that still write embedded code, real-time code, CPU-intensive games, code for horizontal market applications (while I'm less familiar with C#'s prospects, Java has pretty much been a unilateral failure when it came to taking over the horizontal market application space -- take Corel's abortive attempt, for instance), libraries, and code for systems that do many things at once.
When I sit down to hack on, say, a P2P client, I don't write the thing in Java (granted, some people have). I don't do it because it's a background application that eats CPU cycles, and I don't want it bogging down my computer any more than possible. I don't want want hundreds of thousands of people to throw away megs of memory.
How the UNIX API changed that much since 1993?
C99 came out and a bunch of features got added. Threading, realtime scheduling, 64-bit support, large file support, IPC stuff has changed.
Re:What I always liked about Stevens (Score:4, Interesting)
This sort of quality you will never, ever get from some freelance, paid-by-the-hour indexer who doesn't know the problem space, who won't have their name on that book's cover. It does make a difference.
For an offtopic, fictional, and non-serious counter-argument, find a copy of Cat's Cradle by Kurt Vonnegut and read Chapter 55, "Never Index Your Own Book." [libr.org] (you'll have to scroll down with the link I provided, sorry.)
I'm giving the link because it's so weirdly applicable; how often do I get to reference a passage about authors who self-index? Back in reality, I agree with Tom: Friedl's book and index are perfect.