Advanced Unix Programming, 2nd Ed. 143
| Advanced Unix Programming, 2nd Ed. | |
| author | Marc Rochkind |
| pages | 736 |
| publisher | Addison Wesley Professional |
| rating | 9/10 |
| reviewer | Alex Moskalyuk |
| ISBN | 0131411543 |
| summary | An introduction and guided course through the world of Linux I/O and interprocess communications, with C++ source code provided for your viewing pleasure. More than 1100 functions explained. |
Advanced Unix Programming (AUP) has been updated to include information relevant to Solaris, Linux, FreeBSD, Darwin and Mac OS X. Rochkind has added more than 200 system calls, according to the preface. But who is the book for?
First off, if you look at the table of contents, you will find that AUP is largely a book on input-output in Unix operating systems. The input-output varies from Basic (Chapter 2) and Advanced (Chapter 3) File I/O to Interprocess Communications (Chapters 6, 7), Network I/O (Chapter 8) and Terminal I/O (Chapter 4). The rest of the book consists of purely informational chapters on fundamental concepts of Unix operating systems (Chapter 1), working with threads and processes (Chapter 5) and signals and timers (Chapter 9).
If you get the impression that this is an academic title, you're not mistaken - if your university has some kind of Advanced Unix/Linux or Unix Networking course, they probably use some AUP material. Note that the book is not a how-to or manual on setting up Apache, Samba, FTP, various filesystems or Jabber servers - it does have a chapter on networking but teaches Unix I/O concepts from developer's perspective only, meaning you have to know C and C++. If you prefer to look at the source code, it's on the author's Web site.
There are two types of readers for AUP: those who start off programming in Unix/Linux, and those who are quite good at it, have read the first edition and are now wondering whether the second one is worth it.
If you are just starting with programming in Unix/Linux environment, don't let the word "Advanced" scare you off. The first chapter is pretty good in getting the reader up to speed with the concepts discussed in the book. It talks about such common tasks as getting the system to tell you what it has in terms of POSIX, getting a Unix box to tell you the date and time inside a C++ application, and counting your app's execution time. In many aspects, the second half of each chapter falls under O'Reilly cookbook format, where you are given a certain task and then provided the source code and explanations of what needs to be done to accomplish the task.
The author also "falls" into the trap of using some quick solutions only to "discover" that they do not work on all the systems. For example, subchapter 3.6.1 Reading Directories first tries to access the contents of the directory via ec_neg (fd = open (".", O_RDONLY) and ec_neg (nread = read (fd, buffer, sizeof(buffer))) only to find out that under Linux the call retrieves unhelpful "*** EISDIR (21: "Is a directory") ***" message. After that we are introduced into proper, not quick and dirty ways, to access Unix directories via opendir(), closedir() and readdir().
From experience, it looks like most of the people I know who own a copy of the first edition of AUP bought it because of its section on Interprocess Communications. The author does indeed provide a great learning and reference resource when in Chapter 5 he takes the reader through Unix processes and threads, explains how fork() works. The simple pop quizzes are there as well. A way to win friends and amuse the opposite sex during watercooler talks is to offer the following example:
void forktest (void)
{
int pid;
printf ("Start of test.\n");
pid = fork();
printf ("Returned %d.\n", pid);
}
Run this example as forktest and you will get a message:
Start of test.
Returned 11111.
Returned 0.
Run this test as forktest > tmp and suddenly the message in tmp file changes:
Start of test.
Returned 22222.
Start of test.
Returned 0.
Why is "Start of test" printed twice in the second example? Warning: the book contains an early spoiler in 5.5 fork System Call
By this point, you probably wonder whether the code examples will work on your system. The author tested the code on Solaris 8, SuSE Linux 8, FreeBSD 4.6 and Darwin (Mac OS X kernel) 6.8. In the preface, he talks about using a Windows box with SSH client to upload the code to the destination systems and run them there.
The book is very convenient to read; the chapter numbering system always gives you a good feel of where you are at. As reading of the entire book is not required, and a lot of people use AUP as a reference, an index containing just functions and system calls is included in Appendix D. Don't know what tcgetpgrp() does? The index will point you to 4.3.4. All the code is printed in monospace font, so it's quite easy to differentiate from the regular text. All the function definitions are boxed with function name, description and signature provided. The signature itself contains comments on what the parameter represents. They also are not saving whitespace on function samples, using the style where each line of source code and each { gets a separate line in text. Overall, more than 1100 functions are covered.
The book is quite practical, too, so don't think of it as pure API rehash. For example, in 8.4.3 (the chapter 8 deals with Networking), you are given the source code for a text-based browser that's written in less than 50 lines of code (although it doesn't quite understand HTML and just dumps everything to standard output).
Overall, if any part of your job description or hobby list includes Unix/Linux development, especially if it's high on that list, this book is a must have. Moreover, looking at the job market defined by keyword "unix", it looks like half the positions include some kind of "Sr." or "Architect" or "Networking" attribute, for which the knowledge provided in AUP would be indispensable.
You can purchase Advanced Unix Programming, 2nd Ed. from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, carefully read the book review guidelines, then visit the submission page.
Marc vs. Stevens (Score:5, Interesting)
It's very unfortunate Stevens died so young, his books including "Advanced Unix Programming" are extraordinary.
Re:Marc vs. Stevens (Score:4, Interesting)
And I fondly remember MTS, too.
Re:Obvious question (Score:3, Interesting)
Buy APUE and Unix Network Programming volumes 1 and 2 all by Stevens if you're serious.
Re:*NIX (Score:2, Interesting)
In the corporate server market savings on Linux are minimal compared to Sun etc because of two things:
1. Server quality x86 boxes for hosting business critical applications can cost as much as Sun / HP Boxes. So no real hardware savings that justify the "risk".
2. Most companies do not have /dedicated/ Linux admin support skills and need to outsource some degree of support in order to provide that support level themselves. So no real support savings.
3. In some environments a lot of applications (that you may in turn be depending on) are supported on recent flavours of Unix but only on a particular Linux Distro ( and usually an old one given Linux release cycles) say Redhat 7.2. I suspect this is changing (especially as Linux distros are EOLing their releases a lot faster) but companies may not see potential ROI in testing against recent (not latest) releases of every major distro.
So whilst it may be good to have at home, or even in the Web Farm (where all required apps required are often better supported on Linux) there is still a lot of demand of *NIX - and in turn a lot of integration work with APIs of applications best supported (by their vendors) on *NIX.
Also the cowards argument - If the target platforn is *NIX, no one gets sacked for choosing Solaris. If it goes pear shaped it wasnt your fault :)
Re:Marc vs. Stevens (Score:4, Interesting)
If you're working in C (or C++ I suppose, Oh you youngsters!) on and form of Unix, you probably already have the first edition, or at least have read it. If not, go and get it (or this second edition). Along with The Unix Programming Environment, it's one of the classic texts that's not too large to read, but too useful to skip.
Liam
a true classic (Score:3, Interesting)
with K&R's C book and K&P's unix book as a must
have.
The style is light and engaging, and humorous.
e.g. on the 'new' lseek call there's a footnote:
"The extra letter (l) was available, since
creat was one letter short"
I still have my dog-eared copy which I refer to
from time to time.
HP distributed it with their first Unix systems
in lieu of a an official HP manual.
This 2nd edition adds a Java POSIX library
which is excellent. I am already using it
in production systems.
(Comparison's with Stevens book are a little
unfair as they have different emphases.
Rochkinds is on Unix, Steven's are less on
Unix and more on networking)
Re:a true classic (Score:2, Interesting)
No way. Stevens wrote a UNIX book, not just the networking books. The UNIX book is about file IO, directory operations, system data files (passwd), process control and job control, signals, terminals, mmap, daemon writing, pipes, shared memory, message queues, FIFOs, semaphores, passing file descriptors, serial port IO, PTYs, etc.
Best Linux programming books (Score:2, Interesting)
Those two books gain you an understanding of the linux kernel (and OS concepts in the meanwhile) only rivaled by reading the kernel source (and http://lxr.linux.no/ is the best for that!)
Re:Free Software (Score:5, Interesting)
As you say in the 2nd paragraph of the article, "Linux is the kernel: the program in the system that allocates the machine's resources to the other programs that you run. The kernel is an essential part of an operating system, but useless by itself; it can only function in the context of a complete operating system."
My book really is about the kernel API. There's nothing there about commands, shells, compilers, or anything else at the GNU level, except how to implement them. GNU commands are often used as examples, and the reader is pointed to GNU code for research material. (And encouraged not to read it before doing the exercises!)
I suppose we probably disagree about what the term "operating system" refers to. Back when I was at Bell Labs and studying computer science, we didn't think shells and other commands were part of the OS. In fact, removing the shell, the file access methods (e.g., ISAM), and lots of other stuff from the OS was one of the key contributions of UNIX.
The book and its website also strongly support part of your last point, the part about the importance of Free Software. The part about the evils is outside the scope of the book. (All of the code from the book is Open Source under the BSD license.)
Re:Obvious question (Score:3, Interesting)
A book with the rigour and depth of Stevens without the obsolete stuff (Stevens deliberately includes obsolete calls and functions, and with good reason, but it still can be frustrating at times) would be a worthy purchase. But I don't know if AUP has the same level of depth.
It all depends how you define "Timeless" (Score:2, Interesting)
Re:It all depends how you define "Timeless" (Score:2, Interesting)
Interestingly, this is the first comment I've gotten on the matter. I wasn't aware of it myself until about 18 months ago.