Yong's Computer Book Reviews

Deploying OpenLDAP by Tom Jackiewicz

My review on Amazon (A book should be written with lots of sweat) is not duplicated here.

Errata, Important Warnings, etc.

p.16: The first ldapsearch should only return erparent attribute, not including name, firstname, lastname, uid. The second ldapsearch command should be one line; uid=91358 appears to be on a separate line.
p.26 1st para. 2nd line: "OpenLDAPorg" should be "OpenLDAPou".
pp.75-7: Literal copy and paste of RFC 1960, with no mention of the numbers in square brackets being references in RFC 1960. By the way, IA5 character set can be thought of as a superset of ASCII.
pp.81-9: Literal copy of man pages. Could be done better about font; text that should be italic is not, or wrapped between "_"'s.
p.117 line 6 from bottom: Missing ")"
pp.128,144: Perl code should better use "foreach", not "for"
p.129: All "idctl_" should be "ldctl_"
p.133: "ldap_init(3) is the preferred method of use" is not substantiated and contradicts Kurt@OpenLdap.org's comment "ldap_init(3) was obsoleted by ldap_initialize(3)". "This call [ldap_init] performs an LDAP bind and is ..." is completely wrong and contradicts his text in the pages that follow.
p.136 1st line under "API Calls": "Although the following API is" should read "Although some API's are". Regarding ldap_unbind and ldap_unbind_s, Kurt@OpenLdap.org also says "they're deprecated in favor of ldap_unbind_ext".
p.137: "ldap_Errlist" should be "ldap_errlist"
p.139 below 2nd para.: The "typical configuration session" is not shown. Middle page: "RPMs and" should be deleted. Solaris doesn't know RPMs.
p.143 middle: $result alone on one line may cause "Useless use of a variable in void context" warning.
p.144: %{ldap_get_all_entries($ld,$result)} probably should be &ldap_get_all_entries($ld,$result) (& may be omitted), or you may get "Ambiguous use of %{ldap_get_all_entries} resolved to %ldap_get_all_entries" warning.
p.174 last line: '@attrs")' should be '@attrs);'.
p.175 2nd line: "qw(:alforeach" should be"qw(:all); foreach".
p.189 line 11 from bottom: "qualified" should be "qualities". Not sure why the author could copy and paste other people's writing wrong!
p.192 3rd para.: "opressive" should be "oppressive". This parenthesized sentence is not in J. Tauber et al.'s 1999 article (I mean other sentences are).
p.238: Serious miss of information. /etc/ldap.conf should NOT be confused with OpenLDAP's ldap.conf (see p.114); instead, it's the config file for padl.com's NSS and PAM. Book index is not clear about this either.
p.239 6th line from bottom: "dc=compancn..." should be "dc=company".
p.242 Listing 7-14: NSS will be discussed on p.249. This is not the NSS on p.136. Note that RFC2307bis may have expired and deleted. See Also.
p.257: "OSTYPE(line)dsl" should be "OSTYPE(linux)dnl".
p.264 middle: "error" in "error 10 (a referral)" may better be called "return code" according to ldap.h about LDAP_REFERRAL. API Error Codes are listed separately.
pp.264-8: The section "Integrating Apache" is a partial copy of C. Donley's article. AuthLDAP and TransLDAP are no longer available on perl.apache.org, but they're found on cpan.org. The book author should tell us and possibly explain why they're dated 1998 and the Clayton Donley's URL is no longer valid. Some users have problems with these modules when they upgrade Apache to 2.0. Would be nice if we can get some analysis. p.266 talks about NT 4.0 and Perl 5.004+, "as of [Apache] 1.39". These few sentences are the author's own words. But he probably did not verify himself, at least not in recent years.
p.265 8th line from bottom: "URL" is better called "uniform resource identifier" as in RFC 2396, or W3C document.
pp.274- : "Integrating Samba" talks about Samba 2.2.4, which is dated May 2002. Would be nice if the author worked on a more recent version for a book published in 2005.

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

5-star Good supplements for UNIX internals, December 30, 2004

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.

Advanced Linux Programming by Mark Mitchell, et al

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!

Solaris 8 Administrator's Guide by Paul Watters

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.

Oracle Database Administration by David Kreines et al.

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?

To my Computer Page