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.
old skool linux (Score:0, Redundant)
- 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
Gee a bit old on the old linux front, no? Are a lot of people still using the 2.4 series?Re:old skool linux (Score:0)
Re:old skool linux (Score:2, Insightful)
In a way though, the distribution and the way the filesystem is organized is more important than the particular kernel.
Re:old skool linux (Score:2)
I have access to the first edition of APUE from the library, so I won't be running out to buy a new copy.
Re:old skool linux (Score:2, Insightful)
Not everyone can afford to be on the cutting edge.
Re:old skool linux (Score:0)
Re:old skool linux (Score:1)
Of the twenty-odd Linux servers I maintain here at work, most are running Red Hat 7.x, with the Opterons running RHEL 3. All are 2.4-based.
I'm upgrading one RHEL 3 server to RHEL 4 (with a 2.6 kernel) tomorrow purely to remain under a vendor's maintenance argeement. I'm not really happy about it.
My motto for systems administration: if it ain't broke, don't fix it. If it breaks and you can patch it without upgrading the OS, do that. Most RH8 and RH9 packages recompile fine in RH7 with a bit of tweaking. If they don't, then the source tarballs usually do.
Typically, I'll replace the OS when I replace the hardware.
Comment removed (Score:5, Insightful)
Re:old skool linux (Score:0)
Under what conditions does 2.6 perform more than 1 or 2% worse than 2.4?
Re:old skool linux (Score:0)
What I always liked about Stevens (Score:5, Insightful)
Re:What I always liked about Stevens (Score:5, Insightful)
Re:What I always liked about Stevens (Score:5, Funny)
Re:What I always liked about Stevens (Score:5, Funny)
The Department of Homeland Security has also been informed that you are in possession of terrorist devices, namely augmented dentition, which you could only have obtained if you were gene-spliced.
As someone who has defied and defiled creation through this gene-splicing, your name and location has also been handed over to the new ultra-secret, government-funded Fundamentalists for Human Purity, who will quickly show you the error of your ways during your upcoming "vacation".
Also, after running your words through Echelon, we have determined that "trees ... gnaw down" is code for "Bush ... knock off", or a threat to assassinate the president. Your room at Gitmo is being prepared even as you read this.
Re:What I always liked about Stevens (Score:4, Funny)
Re:What I always liked about Stevens (Score:2, Funny)
Wow, you must be one real eager beaver.
Thank you. I will be here all week.
Re:What I always liked about Stevens (Score:2)
Yeah, well I have an iron mine in my backyard. I'm refining the ore into steal, and then making a saw from that to cut down my trees, also growing in the backyard.
Now if I could just write a book worthy of the effort.
Re:What I always liked about Stevens (Score:1, Troll)
Re:What I always liked about Stevens (Score:2)
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)
Re:What I always liked about Stevens (Score:1)
Re:What I always liked about Stevens (Score:2)
Re:What I always liked about Stevens (Score:1)
I know the man pages are available, but the book is definitely better, and I end up lending it to a friend when he was doing the same course.
Re:What I always liked about Stevens (Score:1)
Re:What I always liked about Stevens (Score:0)
With the like of Dr. Knuth I think he would be managing you.
Some people are good in a particular area: Einstein. Some people are just good: Knuth and Feynman.
Comment removed (Score:1)
Re:What I always liked about Stevens (Score:2)
Re:What I always liked about Stevens (Score:5, Insightful)
You're right: that level of pride in workmanship is nearly (but not quite) unheard of in modern technical publishing. But can a publisher ever really measure up to the exacting standards of the most extreme of precise-minded (aka anal) authors? Probably not. That sort of author is apt to be seen as more than half-mad and too much of a hassle for the publisher to try to work with. "After all," says the publisher, "it's just a book." "Sure, but it's my book!" carps back the meticulous author.
You asked where one can find such people. The best living example of fastidious attention to detail that springs to mind is Jeffrey Friedl, as seen in his 500-page arcane tome, Mastering Regular Expressions [oreilly.com], now it its second edition. If I recall correctly, Jeffrey did the typesetting, indexing, etc, which means that he was his own production team. This is nearly universally deemed far more trouble than it's worth, but at least you'll have no one to complain about if, for example, the index doesn't measure up--which it seldom if ever does.
Check out Jeffrey's index [oreilly.com] for MRE (it's in PDF format). Give it a glance. Notice the richness, the usefulness. Notice the multiple levels of headings, rather than just two. Notice the careful treatment of fonts and of the ordering of analphabetic symbols. Many another gem is hidden within that index, which you'll notice if you skim it a bit.
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.
Whoops. We now return you from this unintentional pæan to MRE's production quality.
On Richard Stevens, he was a marvelous and wonderful human being, and he is missed, not just by me, but by many.
--tom
Re:What I always liked about Stevens (Score:1, Troll)
Did you go to a English public school?
Re:What I always liked about Stevens (Score:1)
Analphabetic is a word and it has many meanings:
noun
1. an illiterate person who does not know the alphabet
adjective
1. not alphabetic; "an analphabetic arrangement of letters"; "Jesperson's system of phonetic transcription is analphabetic"
2. unlettered having little acquaintance with writing; "special tutorials to assist the unlettered sector of society"
3. relating to or expressed by a writing system that is not alphabetic
As a side note, this term is usually used when trying to communicate without any type of alphabet, such as when 2 people don't speak the same language and try to communicate using pictures etc.
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.
what's new? (Score:1)
Re:what's new? (Score:1)
http://www.amazon.com/exec/obidos/tg/detail/-/020
Re:what's new? (Score:2, Insightful)
You say "similar" books... do you mean that you already have the first edition, or that you don't have any of Steven's other books? (If you did have any of his books, but not the first edition of this one, you already know what "can't be found in the other books").
I'll assume you mean you haven't yet read any of his books - beleive me, they're worth it. When I first took an interest in TCP/IP, I passed over his "TCP/IP Illustrated" series for a lot of reasons - they were expensive, there were THREE of them (!), they were out-of-date, they weren't specific to my target environment, etc. I bought some of the other, less expensive alternatives, never learned much that I couldn't learn from reading RFC's, and was finally loaned a copy of "TCP/IP Illustrated, Volume 1". I was blown away by the quality of the book, and the quality of the writing. I've never read such a well-written technical book in my life, and I suspect I never will again. Nobody can clarify like Stevens. He goes through the details (all the details), but still keeps the book interesting.
I have to clear book purchases with my wife these days (sigh...) but this is one of the books on my wish list. I'll admit I've never read "Advanced Programming in the Unix Environment", but I guarantee that if it was written by W. Richard Stevens, it makes all other books written on the subject useless.
Now, on the other hand, I have to take this reviewers word that this new guy can write as clearly and as interestingly as Stevens, and so will you.
Re:what's new? (Score:1)
He's right about the books, I have them all and use them on a regular basis - No better books on UNIX or IP out there.
He's wrong about checking with the wife. What you do is buy the books, all of them at once. Then tell your wife you blew the cash at the strip club.
Dan
Ah, yes... Cornerstone Books (Score:4, Funny)
Um, those books never get read - used as they are in making space for shelving to hold the other books!
Re:Ah, yes... Cornerstone Books (Score:2)
Great justification for sitting on the can for an hour at the office any day.
Re:Ah, yes... Cornerstone Books (Score:1)
No farm, no fowl.
well (Score:0, Offtopic)
Re:well (Score:3, Insightful)
I'd highly recommend it, even if you don't do a lot of C programming. For instance, big chunks of Python's os module are thin wrappers around POSIX systems calls. By knowing how those calls work at a low level, you'll be better able to leverage them in your Python code.
Love Stevens work, but... (Score:1)
Re:Love Stevens work, but... (Score:2)
Don't let the name fool you, no previous system programming experience required.
troff/groff? (Score:4, Interesting)
-AP
Re:troff/groff? (Score:2)
(pointing) Ha, ha! </nelson>
Nice recap of the Preface and Foreward (Score:0)
Nice "review"
Another heavy book (Score:1)
Re:Another heavy book (Score:1)
While many applications can be written for Java and C# or LAMP, or one of many other "platform indepedent" development environments, there are many types of applications that absolutely cannot be because they need access to OS-level or hardware-level APIs.
Re:Another heavy book (Score:2)
Re:Another heavy book (Score:1)
Re:Another heavy book (Score:4, Insightful)
Dry, unadorned documentation about APIs give no suggestions as to best implementation, or often where to look or what to try when things go wrong. Sure, you can look at other coders' code (if you can find something akin to what you're trying to accomplish), but it's obviously a sub-optimal solution.
Online knowledge is great, don't get me wrong... but when you have the masters of the art willing to author a condense tome filled to the brim with best practices accumulated over a lifetime of projects, it's worth shelling out some clams to have that handy. APUE, UNP (1+2) and TCPIP Illustrated (1,2,3) have saved my sanity on many an occasion, and I suspect they'll do so again.
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:Another heavy book (Score:1)
Professionally I'm Java developer but in my spare time I create computer languages primality in C++. My main argument is that large book that document APIs seems to be dated since nearly all of that material is available on the web. As I mentioned, I have a lot of UNIX, Win32 and Java books but I find myself using the Internet more then those books.
I'll give you an example, I bought a book on pthreads when I prototyping a virtual machine design. The book was about 2 years old and the examples in the book were outdated; the functions syntax had changed. I has able to find working examples and better documentation on the Internet. That being said, this is just how I find my information many of my colleagues still prefer books for reference material.
It's good to know that the UNIX APIs are being updated. The major revisions that I noticed were IPv6 and as you mentioned 64-bit support.
As someone new to (Score:2)
Bieng one of these people, would I benefit more from Stevens book than this title?
Or would this one make a better selection?
Should both of them grace my bookshelf?
Re:As someone new to (Score:2)
Re:As someone new to (Score:3, Insightful)
Table of contents (Score:2, Insightful)
I hate it when they do that, I'll have to look for it in the publisher 's website.
Re:Table of contents (Score:0)
Praise for Advanced Programming in the UNIX® Environment, Second Edition
Praise for the First Edition
Addison-Wesley Professional Computing Series
Foreword
Preface
Introduction
Changes from the First Edition
Acknowledgments
Preface to the First Edition
Introduction
Unix Standards
Organization of the Book
Examples in the Text
Systems Used to Test the Examples
Acknowledgments
Chapter 1. UNIX System Overview
Section 1.1. Introduction
Section 1.2. UNIX Architecture
Section 1.3. Logging In
Section 1.4. Files and Directories
Section 1.5. Input and Output
Section 1.6. Programs and Processes
Section 1.7. Error Handling
Section 1.8. User Identification
Section 1.9. Signals
Section 1.10. Time Values
Section 1.11. System Calls and Library Functions
Section 1.12. Summary
Exercises
Chapter 2. UNIX Standardization and Implementations
Section 2.1. Introduction
Section 2.2. UNIX Standardization
Section 2.3. UNIX System Implementations
Section 2.4. Relationship of Standards and Implementations
Section 2.5. Limits
Section 2.6. Options
Section 2.7. Feature Test Macros
Section 2.8. Primitive System Data Types
Section 2.9. Conflicts Between Standards
Section 2.10. Summary
Exercises
Chapter 3. File I/O
Section 3.1. Introduction
Section 3.2. File Descriptors
Section 3.3. open Function
Section 3.4. creat Function
Section 3.5. close Function
Section 3.6. lseek Function
Section 3.7. read Function
Section 3.8. write Function
Section 3.9. I/O Efficiency
Section 3.10. File Sharing
Section 3.11. Atomic Operations
Section 3.12. dup and dup2 Functions
Section 3.13. sync, fsync, and fdatasync Functions
Section 3.14. fcntl Function
Section 3.15. ioctl Function
Section 3.16.
Section 3.17. Summary
Exercises
Chapter 4. Files and Directories
Section 4.1. Introduction
Section 4.2. stat, fstat, and lstat Functions
Section 4.3. File Types
Section 4.4. Set-User-ID and Set-Group-ID
Section 4.5. File Access Permissions
Section 4.6. Ownership of New Files and Directories
Section 4.7. access Function
Section 4.8. umask Function
Section 4.9. chmod and fchmod Functions
Section 4.10. Sticky Bit
Section 4.11. chown, fchown, and lchown Functions
Section 4.12. File Size
Section 4.13. File Truncation
Section 4.14. File Systems
Section 4.15. link, unlink, remove, and rename Functions
Section 4.16. Symbolic Links
Section 4.17. symlink and readlink Functions
Section 4.18. File Times
Section 4.19. utime Function
Section 4.20. mkdir and rmdir Functions
Section 4.21. Reading Directories
Section 4.22. chdir, fchdir, and getcwd Functions
Section 4.23. Device Special Files
Section 4.24. Summary of File Access Permission Bits
Section 4.25. Summary
Exercises
Chapter 5. Standard I/O Library
Section 5.1. Introduction
Section 5.2. Streams and FILE Objects
Section 5.3. Standard Input, Standard Output, and Standard Error
Section 5.4. Buffering
Section 5.5. Opening a Stream
Section 5.6. Reading and Writing a Stream
Section 5.7. Line-at-a-Time I/O
Section 5.8. Standard I/O Efficiency
Section 5.9. Binary I/O
Section 5.10. Positioning a Stream
Section 5.11. Formatted I/O
Section 5.12. Implementation Details
Section 5.13. Temporary Files
Section 5.14. Alternatives to Standard I/O
Section 5.15. Summary
Exercises
Chapter 6. System Data Files and Information
Section 6.1. Introduction
Section 6.2. Password File
Sectio
I've got another one of his books (Score:2)
It's a really good book. My first network-aware programs were written using this book. There's examples for several different protocols and a deep discussion of Sun RPC. Concurrency takes a couple of chapters and ideas on server design appear throughout the book. It doesn't cover STREAMS (there was an alternate book for that) or deal with threading, but it's more than enough for most new network programmers.
I'd highly reccommend Stevens if his other books are as useful as this one.
Re:I've got another one of his books (Score:3, Informative)
Stevens wrote the "TCP/IP Illustrated" series and the "UNIX Network Programming" series, along with such other titles as "Advanced Programming in the UNIX Environment".
Re:I've got another one of his books (Score:2)
Re:I've got another one of his books (Score:1)
Re:I've got another one of his books (Score:2)
Later in the book Stevens goes on to explain the protocols in depth, developing ping and traceroute clients using raw sockets. With help from this chapter I successfully scared the crap out of a nearby friend by blasting his firewall with forged IP packets.
UNP comes off my shelf every time I have to write network-related code.
-John
Re:I've got another one of his books (Score:2)
Maybe you should try reading the book instead of using it as a reference.
A related recommendation (Score:5, Informative)
Re:A related recommendation (Score:2)
Re:A related recommendation (Score:2)
Sounds like a real hard-ass!!
Re:A related recommendation (Score:1)
I will certainly be picking Steven's book up at barnes and nobles when i get a chance to drop in. It looks interesting, and probably covers things that Rochkind did not go into.
Alternate Shopping Source (Score:0)
A Dilbert strip? Really? (Score:5, Insightful)
Not a problem. (Score:2)
He was a nice person. (Score:2)
His books were tops in the field. Glad to hear the revised edition is still good.
Your Review Helps (Score:2)
A friend recommended to me the book the Advanced Unix book, and I actually saw this book last week while browsing but was hesitant to purchase it. First because the Dilbert comic strip on the front made me wary that the content was superficial. And second because the extreme length suggested that the book was probably "dumped" from PDFs, man pages, and source listings rather than "written" with insight and an analytical mindset.
The book is a significant size so it will not fit comfortably into my lunch and bedtime reading routine, but if the binding on book of this size looks like it will physically hold up for me to read the parts that interest me then I'll likely shell out the money for it.
Thanks for the recommendation.
This book will cost $20 in India (Score:4, Informative)
Re:This book will cost $20 in India (Score:1)
Re:This book will cost $20 in India (Score:0)
Incidentally, it's the used book market and the blackmarket for foriegn editions that drive up the cost of new editions. Oh, and it's not your friendly college retailers fault that these prices are so sky high. The average margin on a new textbook is 20-25%, used nets around 35%. You can't sustain a multimillion dollar bookstore on that type of margin.
Re:This book will cost $20 in India (Score:1)
Re:This book will cost $20 in India (Score:2)
Besides being paperback, the quality of the binding and product overall was definitely substandard. Under heavy use, I'd expect the $80 hardcover to easily withstand more than 4x the abuse.
But what I really really want is a frigging PDF version of this book. I'd pay $50 for it. Hear me, publishers? Think of the profits!
Advanced Unix Programming, 2nd Ed. (Score:1)
Advanced Unix Programming came out with a 2nd edition in 2004, and I was lucky enough to spot it in a Half Price Books [halfpricebooks.com] here in Indy. This is very similar, in terms of upgraded content.
In particular, the test systems are the same between books. (FreeBSD, Linux, Solaris, Darwin.) Both books have grown considerably to take on the growth of Unix and the various flavors.
Of course, AUP came out in 1985, so it had a little more turf to cover.
For those not familiar with AUP, it is a slightly different beast from APUE. It only covers Unix system calls in C categorically, whereas APUE covers a wider range of tasks and subjects within Unix.
Modem chapter (Score:2)
According to the book's official site, the modem chapter was pulled from the print edition, but it was still revised, and is available as a PDF or Postscript file.
(The site is chock full of frames, but here's the inner content page [apuebook.com] talking about it and linking to the chapter's files.)
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.
I was wondering if they'd ever update it ... (Score:2)
Steven's APUE and Unix Network Programming are the books that turned me from a novice into someone who felt confident enough to pursue programming for a career. The first edition of APUE is so extremely well written - clear, concise and lucid. I'm definitely going to flick through the new edition, but the great thing is that the first one is still reelveant, in fact it's one of the five books I take with me to any new job.
Comment removed (Score:2)
Bought the first edition recently... (Score:2)
Having had both editions of Unix network programming (gives me one to lend out...)
Glad it has been updated, it seems superficially dated which might put people off, although there is actually lots of stuff thats still completely valid.
Advanced Unix Programming in one word (Score:3, Funny)
Platforms? (Score:2)
Re:Platforms? (Score:1, Informative)
OS X has tons of developers. It has 10% of the desktop market share. It has developers.
Aww Crap, just bought 1st ed (Score:1)
Re:How did he die? (Score:0)
Re:How did he die? (Score:0)
Re:How did he die? (Score:0)
Re:How did he die? (Score:1, Offtopic)
Re:Cornerstone (Score:0)
Re:Cornerstone (Score:1, Informative)
Re:Cornerstone (Score:5, Funny)
Re:Cornerstone (Score:2)
One man's Troll is another man's Funny, as we demonstrate.
Re:Cornerstone (Score:2)
It is not "this book would serve".
This book (along with UNP I and II on the other side) is the cornerstones in my bookshelf.
Re:Cornerstone (Score:2)
Do we need to singularize conerstones, or add 'among' after 'is'?
MOD PARENT +, ACCURATE MAC USER DESCRIPTION (Score:0)
Re:Why include crappy BSD ? (Score:0)