The computing topics that interest me, alas, lend themselves poorly to the kind of writing treatment I'd like to see them given. Books like Expert C Programming are rare finds. Author Peter van der Linden is so comfortable with his subject that he's having power-nerd fun, but can also share that fun genially with the reader. Effective Java is also of this kind but in a different way. Where van der Linden has the manner both of an authority and a favorite uncle, Joshua Bloch has some manner of true wit, treating complex issues in programming practice with economical prose and evocative rationale.
Network Flow Analysis, by Michael Lucas, doesn't belong in the same league as these two books, but it surely climbs the same mountain. Network administration, never mind troubleshooting, is a dry, sometimes airless subject. As the cliche goes, computer networks may be more than the sum of their parts, but the only people who really appreciate that have handled each of those parts. Communication protocols, command protocols, wire protocols, internet protocols, data link management, router configuration, IP traffic management, firewall administration....Where mathematics or intricate programming techniques daze the disinclined mind, computer networking bludgeons it. As with higher math, network troubleshooting often falls upon those who simply get what they're looking at.
Lucas knows the trick to promoting his subject is to motivate the imagination, not the intellect. And so he writes in his introduction, "Network administrators all share an abiding and passionate desire for just one thing. We want our users to shut up." I for one can tell you where I was working and the problems I was dealing with when I first felt exactly that. And from that point on, the book flows quite neatly from one point to the next. The sequence of topics and the consistent tone and focus kept me engaged and confident that I could go as far as I'd like, with this book as a start.
To achieve that effect, such a book has to look and feel manageable in a reasonable amount of time. Network Flow Analysis is about two hundred pages long, but it is hardly thin. The pace of discussion is deliberate but covers a lot of ground. I can't recall a passage that wasn't backed by earlier discussion or wasn't detailed on the next page or so. Lucas narrates in a straightforward manner that does not succumb easily to distraction or concern for losing the reader. Where most authors tackle the subject with a compendium of summations or mostly-digested specifications, Lucas exhibits the guileless courage of someone who spends every day on a roof or under a sink. But there is also no need for him to map the network world. He has The TCP/IP Guide for that. The shameless shilling keeps Lucas' job simple; you'll eventually need a reference guide anyway, so hey. (My only reservation with The TCP/IP Guide is that it doesn't cover SCTP. I wish it did.)
The only surprise I found in this book came in Chapter 8, "Ad Hoc Flow Visualization," where Lucas writes, "gnuplot (http://www.gnuplot.org/info) has a notoriously steep learning curve and a reputation for complexity." Even though the rest of the paragraph mitigates this claim considerably, I bought and read Manning Publication's gnuplot in Action to make sure I hadn't missed something. I'm mostly thankful for this overreaction; gnuplot in Action also happens to be readable, thin without being light, and engaging. On the downside, I bought the electronic copy to get it immediately. Soon I'll send it to Kinko's for printing. E-books suck. No, I don't care about your super-good experience with them, or what a difference your reader makes. Don't share. What would be great is if Manning et al let me apply my ebook purchase price to the cost of a print copy.
Network Flow Analysis is not a book that would inspire you Dummies-identifying types to have a go, I don't think. No such book will ever be written. But if troubleshooting the network becomes your job, and you need more than a kickstart, and you do want to shut people up with the wild-ass talk about twisted cat's cables, or tell the guy who works closest to the wiring closet why cycling that "CSU/DSU" never helps, or show the finance department why it's bad to ping-bomb the server right after the guy from tech illustration dumps a draft of his dragon novel to the printer, you need a friend. You could do far worse than start here.
NOTE: You'll be happier about the tools described in this book if you're running Linux or some BSD variant. Getting them to work reliably on OpenSolaris will take more time than I'd like to wait before posting this review.
I purchased this book and Solaris 10 Security Essentials together, in part because they were authored by Sun's engineers, as the books state. I teach these topics, so I'm always on the lookout for better presentations or demo ideas that would improve my delivery and deepen my own understanding.
There are, alas, mostly off-putting elements in this book. I don't know what I had in mind for "Solaris System Engineers" as the authors, but it sure wasn't technical writers, who compose about half the group. Accordingly, some discussions seem re-phrased from a man page or online docs, and not so much improved by the effort. In other places, the technical information is laid out in about the least imaginative or helpful way I can conjure. Turning data structure elements into bullet points (see Chapter 6, "Managing System Processes"), then tabling a bunch of commands and showing one trivial example of each...c'mon, man, you're the engineers. That's all you know?
Why this book devotes a chapter to Fault Management, frankly, escapes me. You can go a long way in Solaris 10 and not know or care about FMA. It's of course a very useful thing, but essential to a beginner? No. The Service Management Facility (SMF), on the other hand, fundamentally alters the administrative landscape for Solaris. Where is it? It's got about seven pages at the end of Chapter 2, "Boot, Service Management, and Shutdown." It's an architectural discussion of the sort I expected the FMA chapter to be, high-level and not intended for much exploration at first. That's too bad. If anyone can figure out how to use SMF from this presentation, it's because you they knew what the authors meant to say.
Other elements I find bordering on silliness. Chapter 8, "Managing Disks," has an illustration of a hard drive that must be older than both my children, combined. Understanding storage technology today is well beyond mapping outdated disk anatomy to the logical view employed by Solaris device drivers. The authors don't seem to know: things have changed. A lot. And in Chapter 11, "Solaris User Management," eleven pages are devoted to no fewer than four topics: managing users, managing groups, creating a NIS domain (also largely outmoded), and managing roles. Fifteen pages for fault management, eleven for the foundation to identifying users on a network of systems?
Patch management in Solaris can be a complicated exercise in hair-pulling. To that end, the chapter on patching provides two tables, spanning six pages, that list and describe all the patching tools and document all the patch types. The rest of the chapter is a narrated if-then-else of when and how to patch; again, material you can find freely elsewhere, or just figure out. Of all the subjects where readers really want more insight than information, patching is probably first on the list. There's no help here.
In summary, the engineering authors seem to have contributed brief architectural overviews, while the tech writers seem to have covered well-known territory not so well. It's a disappointing combination. You can't really experiment much with the former, or learn much from the latter that you couldn't teach yourself. If you've bought prior books in this series, I recommend a careful look at new titles before laying down real money. Seems to me the editorial standards may have taken a dive.
I wanted to review this new edition of The Art of Assembly Language, or AoA as it's widely known, for several reasons. I've been reading assembler, as compiled from C, for a long time and wanted to improve my grasp of it. I wanted to get a sense of thinking in assembler, as I still marvel at how anyone can write long, complex assembly (or FORTH) programs in a reasonable amount of time. And I wanted to dig deeper into Intel's instruction families. There's far wider documentation on Intel assembler for non-experts than on SPARC, and I'm hoping a solid understanding of Intel will make SPARC's stuff easier to penetrate. The AoA book prides itself on being a book of choice for beginners, so it seemed a good fit.
AoA, it turns out, is a guide for using a language called High Level Assembly, or HLA. HLA was originally a teaching aid that simplified the task of programming by sugaring low-level assembly. It provides a library of helper routines and a syntax that users of Pascal or C/C++ might absorb faster. And so the book begins, simply enough, with an HLA Hello World example. It then discusses the setup needed to run the program, an explanation it describes as "OS neutral." To run on Windows requires parts of another assembler programming environment called MASM. In further fact, it was on a MASM discussion site where I found the help I needed to get my first program to compile. On those notes, I think the book's setup directions are better termed "over-written and incomplete." This condition plagues many technical details in the book. Many passages read like they were written out once, late at night, with ever more deadlines looming, and then sent off for printing.
As with many critics of this book, I didn't find using HLA to my liking. I wanted to get closer to assembly language, which is what I felt the book advertised. Instead I was learning a tool that kept me at a presumably safe, first-semester distance. It brings to mind Donald Knuth's infamous pseudo-assembler MIX. On a more practical point, it reminds me of W. Richard Stevens' Advanced Programming in the UNIX® Environment. That book supplies a header file as shorthand for its many code examples. The time I spent making sure I understood what this shorthand did -- which I then discarded anyway -- I would rather have spent on the topic at hand. This convenience, placed well before the details it managed could have been trivial or boring to me, impeded my learning. I appreciate conveniences for the effort they conserve, not the work they hide. I would prefer it if Stevens helped me build my own along the way. Still, the intrusion was a small one, and I knew enough C to work around it, as the book anticipated.
With AoA, there's no such hope. It's an HLA book. On page fifty and forward, the author says the book will teach you HLA, but the ultimate goal for "real" assembly program writers is to discard it. To my mind, that premise suits a college textbook. It is a contrived goal, best suited to a contrived deadline, such as a semester, and a familiar but also contrived lifestyle of many hours available for patient study and research. Complicating the fact, again, is that the title suggests a professional or even avid hobbyist programmer's goal: to acquire a broader understanding into which to fit the many details. I think the many eager buyers of this book who feel misled have a quite reasonable gripe.
I also gave this book some consideration as a reference. But it tends to introduce certain facts on each topic early on and expand elsewhere, with treatment that can be choppy and driven by caveats. Intel 80x86 architecture, notes on the memory subsystem, machine instructions, HLA control structures, data types, memory accessing...the ride careens at times. It's difficult to feel confident that this information comes together. One could gain a lot of weight trying to barrel through this book, and wear out a few squeeze balls too. Having spent some number of years as a writer and editor myself, I look out for ways to say things more concisely without losing meaning. Judging by the book's preface, there's been a lot of effort at doing that with AoA. Still, there's enough throat-clearing, redundancy and over-stating in the text to exhaust a cadre of editors. It seems like an enormous undertaking, paring this text down to its best parts.
What I'd like to see in a book like this is a clear foundation, a story to tell, and a systematic approach. All books are laid out in some sequence, but this subject needs a unifying vision, or at least an attempt at one. I'd suggest not calling it a book on assembly programming; it isn't. There may not be as eager a market for "the book that gets you a step closer to it," but perhaps from that acknowledgment there derives a presentation that doesn't try to punch above its weight.