The Linux Programming Interface 73
Muad writes "Michael Kerrisk has been the maintainer of the Linux Man Pages collection (man 7) for more than five years now, and it is safe to say that he has contributed to the Linux documentation available in the online manual more than any other author before. For this reason he has been the recipient a few years back of a Linux Foundation fellowship meant to allow him to devote his full time to the furthering this endeavor. His book is entirely focused on the system interface and environment Linux (and, to some extent, any *NIX system) provides to a programmer. My most obvious choice for a comparison of the same caliber is Michael K. Johnson and Eric W. Troan's venerable Linux Application Development, the second edition of which was released in 2004 and is somewhat in need of a refresh, lamentably because it is an awesome book that belongs on any programmer's shelf. While Johnson and Troan have introduced a whole lot of programmers to the pleasure of coding to Linux's APIs, their approach is that of a nicely flowing tutorial, not necessarily complete, but unusually captivating and very suitable to academic use. Michael's book is a different kind of beast: while the older tome selects exquisite material, it is nowhere as complete as his — everything relating to the subject that I could reasonably think of is in the book, in a very thorough and maniacally complete yet enjoyably readable way — I did find one humorous exception, more on that later. Keep reading for the rest of Federico's review.
This book is an unusual, if not altogether unique, entry into the Linux programming library: for one, it is a work of encyclopedic breadth and depth, spanning in great detail concepts usually spread in a multitude of medium-sized books, but by this yardstick the book is actually rather concise, as it is neatly segmented in 64 nearly self-contained chapters that work very nicely as short, deep-dive technical guides. I have collected an extremely complete technical library over the years, and pretty much any book of significance that came out of the Linux and Bell Labs communities is in it — it is about 4 shelves, and it is far from portable. It is very nice to be able to reach out and pick the definitive work on IPC, POSIX threads, or one of several socket programming guides — not least because having read them, I know what and where to pick from them. But for those out there who have not invested so much time, money, and sweat moving so many books around, Kerrisk's work is priceless: any subject be it timers, UNIX signals, memory allocation or the most classical of topics (file I/O) gets its deserved 15-30 page treatment, and you can pick just what you need, in any order.
| The Linux Programming Interface | |
| author | Michael Kerrisk |
| pages | 1552 |
| publisher | No Starch Press |
| rating | 8/10 |
| reviewer | Federico Lucifredi |
| ISBN | 9781593272203 |
| summary | The definitive guide to the Linux and UNIX programming interface |
Weighing in at 1552 pages, this book is second only to Charles Kozierok's mighty TCP/IP Guide in length in the No Starch Press catalog. Anyone who has heard me comment about books knows I usually look askance at anything beyond the 500-page mark, regarding it as something defective in structure that fails the "I have no time to read all that" test. In the case of Kerrisk's work, however, just as in the case of Kozierok's, actually, I am happy to waive my own rule, as these heavyweights in the publisher's catalog are really encyclopedias, and despite my bigger library I will like to keep this single tome within easy reach of my desk to avoid having to fetch the other tomes for quick lookups — yes, I still have lazy programmer blood in my veins.
There is another perspective to this: while writing, I took a break and while wandering around I found myself in Miguel's office (don't tell him ;-), and there spotted a Bell Labs book lying on his shelf that (incredibly) I have never heard of. After a quick visit to AbeBooks to take care of this embarrassing matter, I am back here writing to use this incident as a valuable example: the classic system programming books, albeit timeless in their own way, show their rust when it comes to newer and more esoteric Linux system calls (mmap and inotify are fair examples) and even entire subsystems in some cases — and that's another place where this book shines: it is not only very complete, it is really up to date, a combination I cannot think of a credible alternative to in today's available book offerings.
One more specialized but particularly unique property of this book is that it can be quite helpful in navigating what belongs to what standard, be it POSIX, X/Open, SUS, LSB, FHS, and what not. Perhaps it is not entirely complete in this, but it is more helpful than anything else I have seen released since Donald Lewine's ancient POSIX Programmers Guide (O'Reilly). Standards conformance is a painful topic, but one you inevitably stumble into when writing code meant to compile and run not only on Linux but to cross over to the BSDs or farther yet to other *NIX variants. If you have to deal with that kind of divine punishment, this book, together with the Glibc documentation, is a helpful palliative as it will let you know what is not available on other platforms, and sometimes even what alternatives you may have, for example, on the BSDs.
If you are considering the purchase, head over to Amazon and check out the table of contents, you will be impressed. The Linux Programming Encyclopedia would have been a perfectly adequate title for it in my opinion. In closing, I mentioned that after thinking for a good while I found one thing to be missing in this book: next to the appendixes on tracing, casting the null pointer, parsing command-line options, and building a kernel configuration, a tutorial on writing man pages was sorely and direly missing! Michael, what were you thinking?
Federico Lucifredi is the maintainer of man (1) and a Product Manager for the SUSE Linux Enterprise and openSUSE distributions.
You can purchase The Linux Programming Interface from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Fiddleheads (Score:4, Insightful)
Michael, what were you thinking?
He was thinking he's the only person writing man pages for Linux so why does anyone else need to know how to do that?
Re:Anyone got a summary of the summary? (Score:1, Insightful)
Summary - If you need to know about the Linux, then buy this book using the link provided. We're not going to tell you that Slashdot gets a kickback if you use the link, but fuck it. Pudge is gone now and he was the only real journalist around the place, so we don't consider ourselves obligated to reveal conflicts of interest. Oh wait, Pudge wouldn't have given a shit about that either. Carry on, then.
Just as long as (Score:3, Insightful)
Other than manuals, there were 3.5 key Unix books (Score:5, Insightful)
back in the day:
(1) The Unix Programming Environment (K&P)
(2) The C Programming Language (K&R)
(3) Software Tools (K&P)
(4) The Elements of Programming Style (K&P) [optional]
In those days, I was always amazed that so many people tried to program on Unix without having read these books forward and back. After you read those, all that was left was to read the manuals cover to cover, which took a few months but was worth doing. That was a good spare time activity back in the days when compiling and linking took a long, long time.
It's an entirely different kind of world today. I doubt many people know even the standard Java libraries as well as we knew Version 7 and System III of Unix, not only the details but the design philosophy as well.
Ralph Waldo Emerson, in his essay "Self-Reliance", claims that society does not progress; it simply changes. We gain some things but lose others. I suppose that depends on your definition of "progress"; I certainly wouldn't want to go back to those days. We have unquestionably gained, but we've lost something too as programmers, a sense of mastery and control over our destiny. So much of our time today is spent dealing with the fallibility of others, in wrestling with frameworks that are powerful but so complex they're inevitably full of excruciating design flaws. We don't think it extraordinary at all for a good fraction of our time on a project to be working around flaws in other layers of the solution.
Re:Just as long as (Score:5, Insightful)
Yeah. I hate info. Actually, what I hate are man pages that say "use info $APP for the man page".
Re:Anyone got a summary of the summary? (Score:4, Insightful)
If you're not sophisticated enough to realise that a link to Amazon is going to have a referal perhaps it's time to hand in your badge and gun.
Re:Sentence fragment as the (Score:3, Insightful)
That's RMS for you. I'm surprised GNU-based systems don't say "Use emacs to edit $FILE" when you try to use vi....
Well, there's actually a functional reason for info's existence. It's a hypertext system, it's got hyperlinks and table of contents and hierarchical organization for documents... This makes it much more useful for relatively large documentation than a man page would be.
But I never liked actually using the info reader, I never took the time to learn all its key bindings. These days I think HTML documentation is a much better choice... Man pages still do well in their own little niche - brief summary-style documentation with a consistent, convenient interface... But I don't think info has a valid niche any more.
Re:Sentence fragment as the (Score:3, Insightful)
I don't think info ever had a valid niche to begin with... maybe as an add-on to man pages, but never as a replacement for them. "use info $APP for the man page" is a sad indictment to that poor design judgment.
Oh, agreed. I hate those stub man pages. Especially when (due to some documentation package not being installed, no doubt) calling up the suggested info page just leads me straight back to the same stub man page, except in the info viewer instead of the man page viewer.
But my point about info was that it's actually more of a full-featured help system, and much better suited to presenting large amounts of information than man is, because it can organize and cross-reference it better. In the face of HTML it seems largely superfluous, so it loses out 'cause it's neither as convenient as man nor as fully-featured as HTML. But info first appeared... what, early 1980s? Late 70s? A help file browser with hypertext functionality was a pretty substantial merit at that point.