Deploying OpenLDAP by Tom Jackiewicz

UNIX Filesystems: Evolution, Design, and Implementation by Steve D. Pate

As the author claims, this book supplements other UNIX internals books, because they lack a thorough discussion on filesystems. For example, for a long time I've been puzzled by the pseudo code for read(2) system call in Maurice Bach's book. An inode lock is taken even for read() (Design of the UNIX Operating System, p.97) That doesn't sound right. ufs_inode.h on Solaris implies that ufs uses rwlock (multi-reader/single-writer lock; forget the modern concurrent direct I/O for now). Jim Mauro's "Solaris Internals" talks about rwlocks and filesystems in separate chapters but not in the same context. Here Steve's book tells us that filesystems didn't use rwlocks almost until the time SVR4 came out, and Bach's book was written before that. This is just one example of the mysteries Steve's book solved for me. I also like Steve's examples of using Solaris crash(1M). (I even collected them in a web page: yong321.freeshell.org/computer/SolarisMdb.txt).

Superb technical details aside, this book is also written in good pedagogical style. Hands-on exercises always help. (How many people have read Goodheart's "Magic Garden" book for longer than a week?) Some code examples, pseudo or real, also help. Steve's book has both. Lastly, it comes with a mini-filesystem. I didn't test it but I believe it would help CS students tremendously.

Since the book is just much about Solaris as about Linux, I wish he talked more about Linux debugfs() and perhaps could use gdb to debug ext2 filesystems. I hope the new edition, if there is one, can give examples of Solaris mdb since crash is deprecated, and can expand the examples to include some new FSs, riserfs, Oracle's OCFS, etc. (Both have source code available to the public.) In chapters about cluster filesystems, the technical discussion seems to be less strong. There must be ways to debug these FSes just like using crash() and adb() to follow pointers in memory to debug UFS. It's just that cluster FSes are less understood and studied in this fashion.

Unix System Administrator's Bible by Yves Lepage et al.

2-star Better titled "UNIX System Management Leisure Reading", January 14, 2000

This book is for managers, not for techies. Quite different from Aelene Frisch's or Nemeth's books, this book talks a lot about management issues and sometimes tells us real world stories. However, writing too much about these in an overly verbose manner makes me feel uneasy about the price of the book. Verbose talk on such topics is typically published in magazines which you read once and discard. Since the authors want to distinguish them from Frisch and Nemeth by these topics, I'd love them to tell us more real world stories like the three cases in Chapter 13. Or tell us more on what to watch for in vmstat, iostat etc. in the context of a real working environment. In addition, authors' and editors' fault on letting screen output inappropriately wrap, frequent typos (such as "./etc" instead of "/etc") all reduce the value of this book. Some people find some code snippets in this book valuable. Me too. Such as timedexec (I assume the authors wrote this program). But in other cases such as the buffer overflow attack, the authors should at least describe the logic of the source code instead of just listing the original code. I guess it's too difficult for them too.

Visual Basic 5 Bible with CDROM by Douglas A. Hergert

5-star Very good, September 17, 1999

This is a very good book. There's something the author could improve on in the next version. Examples in the book don't seem to encourage good programming practice. E.g., two consecutive if-blocks should be combined into one if-elseif-block for performance reason because only one IF is valid judging from the context. Some identical processing is done on the WHILE line rather than before the loop. Performance shouldn't be a concern for a beginning programmer but if it doesn't take much to teach, why not? Other than this, this is a very well written book.

Linux Programming Bible by John Goerzen

5-star Highly readable

I'm only interested in the part on systems programming, so I didn't read chapters on Shell, Perl or GUI. This author may have solid teaching experience. Take the discussion on mmap() as an example. On p437, it clearly says that MAP_SHARED is for changes to the mapped area in memory to be reflected by change to the file. Compare this with the authoritative SVR4 systems programming book by David Curry, who says "when changes are made to the mapped object, these changes are shared among other processes that also have the object mapped". If this is the first time you use this function, the latter description will sure sound more cryptic.

A number of IDG Bible books err on the side of being too verbose (e.g. UNIX System Admin Bible). I think this book is right to the point. I enjoyed reading the chapters on building libraries, IPC programming, and Linux I/O. The interpretation of source code is accurate and adequate.

5-star Good Quality

This book is mostly on system programming. The title is accurate. The chapter on "Threads" is outstanding, which is not a topic in any other Linux book I've read. It talks about many pitfalls you may encounter and gives plenty of code with goodinterpretation. I don't have hands-on experience in threads. Reading this chapter helps understand Linux OS. The short chapter on in-line assembly is the most difficult to follow (my x86 experience started and stopped with 8086 instruction set). This also distinguishes this book from any other. Description of creating shared libraries is more thorough than Michael Johnson's book IMHO. Some topics, not really programming, are nonetheless interesting to read and hard to find in other sources (loopback filesystems e.g.) Overall, the book is technically sound and the text full of authors' wisdom.

The authors could have made the book more pedagogically easier. Small things like telling readers "in" in "sockaddr_in" and "sin_family" probably means "internet" and "un" in "sockaddr_un" and "sun_family" means "unix". Describing arguments of each syscall or function should be accompanied by syntax (synopsis). Some important topics such as file descriptor multiplexing and daemons are omitted. (Daemon could be discussed in Chapter 11). Termio is almost not treated. The IPC chapter, relatively weak, is missing message queues. Finally, the publisher chose a very small font completely ignoring the fact that the Linux people often burn midnight oil!

1-star Errors and sloppy writing, November 25, 2002

When it talks about nfsstat (p.160), it says "low good call-to-bad call ratio" when it meant the other way around. OK. Just a little sloppiness. Then before it talks about "vmstat 1" output, it says running vmstat "with no options" displays data "at one-second intervals". OK. It's for that vmstat command followed by 1 as in the example. Then it says "r" means processes running. He doesn't make a distinction between running and runnable. Most people don't anyway. Then it says the first line shows the statistics during the first second. That statement triggered my book review here. You can find a lot of superficial discussion in this book. I'd like to see how it explains the Ref column of netstat -r, the system tuneable maxusers, swap vs. tmpfs, free under vmstat, and other topics inexperienced Solaris admins often misinterpret. I can't find any (BTW, I don't know what good there is by omitting module names for module-specific tuneables on p.35, and why on p.255 he's not willing to tell people to set shmsys:shminfo_shmmax to its theoretical maximum). Then you find the title "Disabling IP Ports" (p.204) which makes you think a port is the concept at the Network layer. Let's also not be picky here about the terms network engineers usually use (Ethernet frame, IP packet, TCP segment/UDP datagram). Overall, the book is ambitious but the author didn't make a good effort. Being a PhD myself, I sincerely wish he had devoted the same energy to writing this book as to his PhD thesis.

1-star How to write a book adding value to manuals

Nowadays countless books are blamed for duplicating manuals. UNIX books copy man pages, Java books list JAVA APIs and Oracle books lump together Oracle manuals. Most readers feel uncomfortable buying such books. Others question what alternative there is. Here's the alternative. Let's say you want to talk about vmstat in a UNIX system admin book. You can say "the w column under procs should always be 0 otherwise...". Or in an Oracle book "in reality, some people set pctincrease to 1 just for the purpose of coalescing extents; some argue it's unnecessary because... Our opinion is...". I guarantee these words won't show up in manuals. But these words "The following section talks about...", "This chapter will discuss..." are typically used in product documentation.

This book apparently is overly verbose in uttering what is obvious to every junior DBA. What's not obvious is not obvious to them either. Take "SQL queries to monitor SGA utilization" (Chapter 6) as an example. The authors stopped when they need to talk about what the columns in those views mean (even if we can find this information in manuals) and what kind of values count as warnings to DBAs (this info is not likely in manuals). Whatever computer book you write, if you list the source code, you have the responsibility to talk about the code, at least the hard part of it. If you think that's going to make the book too big and that content should go to a Tuning book, well, there's already so much fat, i.e. verbose talk on easy things. If a big portion of your book is free somewhere, lower the price. There're some good books falling into this category such as Java in a Nutshell, VB&VBA in a Nutshell. But those books are also full of author's wisdom and tips accumulated over the years. How can this book compare?