I just wrote a review of this technical book for Amazon. Here’s the review.
http://www.amazon.com/review/R13Y2OQKI1HTQ/ref=cm_cr_rdp_perm
Copyright © 2010-2023, Glenn Story
I just wrote a review of this technical book for Amazon. Here’s the review.
http://www.amazon.com/review/R13Y2OQKI1HTQ/ref=cm_cr_rdp_perm
I considered making a list of errors and sending them to the author, but frankly I didn’t have the time to spend on such a project. I do agree it would possibly be a helpful thing to do. But I also think giving a negative review is a fair response.
In fairness, I did get value from the book despite its flaws.
Thanks for your comments.
Rather than blankly dismissing, you could have probably (A) gotten in touch with the author, who’s practically imploring feedback (B) checked out the book website. Arguably, some corners were rounded, and he could have explained more about the reverse engineering parts – but if you spot outright errors, you should point them out, and definitely tell the author. I agree with you wholeheartedly the editing is terrible. The editor was either non-existent or outright getting paid for nothing.
Tom
I quickly looked at this book and think about buying it, but your Amazon review sort of put my purchase on hold.
Can you point out an example of the errors you found? Is this just about typo or conceptual errors? What are the flaws?
Also, you wrote that it is incomplete. I read the previous reference (Amit Singh’s book) and this new one looks really complete and seems to include a lot of new info, acquired through reverse engineering of the different parts of the system.
Can you point out what you think is missing?
Reviews with 2 stars are pretty harsh and usually mean “don’t buy it”. So I want to go to the source of the comment.
Thanks
Leon
Maybe I should make it 3 stars. 🙂 I don’t have time to go back and dig out specific errors.
I was tempted to go back and get Amit Singh’s book, but it is pretty dated by now. In fact this book is starting to get dated. Lion is just coming out; Mountain Lion is in the future, and Mavericks doesn’t exist.
But: It is really the only book on the subject. So I’d say get it but be prepared for frustrating lack of detail in some places. (May be the grammatical/spelling errors don’t bother you.)
I found this blog by looking for reviews on the OS X internals book (I work for a company which makes OS X drivers) – you’re high on Google :-). Like the others, I’m somewhat put off by that 2 star review. But also puzzled. You seem to be in a minority opinion with other more favorable reviews; Either they didn’t spot the errors, or you know something they don’t, which piques my curiosity as to what and where. Plus, I would think if the factual errors are enough to merit 2 stars, you’d at least point out a but few of them (on this thread, or at least to the author). Mind you, even Singh’s (amazing) book has minor errors, and word for word, this book probably has more material than Singh does (less pages but smaller font). Dating is an unavoidable outcome of a hard copy, but from what I see from the website and the book (mostly dead) forum, the author is striving to keep things updated. Certainly the tools alone are worth it.
Your comment plus previous ones has caused me to up my star rating from two to three. I think your desire for specific details of editorial or technical errors is also quite fair. In hindsight I obviously should have made notes of such errors as I read. Unfortunately I didn’t.
You seem to have a specific purpose in mind for reading the book. I’d encourage you to go ahead and read it and use it in your work. Then post your own review with specifics of the value you got from the book. (Please don’t take this as “if you don’t like my review then write your own.” Rather, if you use the book to accomplish specific work then you will likely read the book and get value from it from a different point of view than I did–in my case I was reading for general curiosity.) Your more practical point of view would be a welcome addition to the comments about this book.
I did see you upped the review, though what is really puzzling me are which errors you’ve found. Those can be impactful if we design a product based on a wrong premise. If there is anything that springs to mind and/or you remember, it’d be appreciated. Especially if it’s a technical error (i.e. not that big of a deal if the NeXT history dates or versions are inaccurate). How many errors were there? I mean, are we talking few and far between, or all over the place?
OK, here’s an example of a technical error in the book:
At location 7575 in the ebook, it describes a “double fault” as “an abort, as if a fault is triggered twice in the same instruction, it does not make sense to retry. ” In the preceding table, it says that a double fault is “Generated the second time a fault occurs on the same instruction.”
In fact, a double fault is when a fault is generated while handling another fault. This is generally not on the same instruction.
According to the Intel(R) 64 and IA-32 Architectures Software Developer’s Manual, Volume #a, page 6-28, a double fault “indicates that the processor detected a second exception while calling an eceptiopn handler for a prior exception.”
An example of an editorial error, at location 16932: “…(due to the number of erase operations in a journal, which could shorten the underlying flash).” I assume this is meant to read, “shorten the *life* of the underlying flash.”
Location 5249: “…a BIOS has a processor interface, which is usually accessible by means of a specialized machine instruction (commonly INT 13h).” This sentence has two problems: (1) the BIOS is *always*, not *commonly* accessed via an INT instruction. (2) There is a separate INT number assigned to each service in the BIOS.
These are examples. There are more such error in the book. As I have said before, I would have to reread the book to find them all and I don’t have time to do that.
In answers to Brian’s questions:
I gave a couple examples of errors in my previous reply. In terms of quantity, I would say one or two per chapter. And the ones I spotted are in the background material, not the Apple specific material. I don’t know the Apple specifics enough to spot errors–which is why it makes me nervous to see errors in things I do know about.
As with any book or other source of documentation, you have to plan for (and therefore test for) some errors when writing code from such documentation.
Thanks for your inputs, Glenn. This is actually quite reassuring, in a way – Specifically, you’ve pointed out relatively minor issues – for example – “commonly” could be construed as exactly that there are MORE Int instructions (13h is actually one of the more popular ones, for disk access), so I don’t see that as much of an error, more poor wording – likewise, Editorial errors, well, yes. We’ve established the editor should have been executed by now 🙂 obviously, “shorten the life”, not “short circuit”. Go figure who does the proofing. Even in the first pages, the guy’s dedication to his wife has a misplaced full stop which changes the meaning of the sentence..
The Intel double fault is an obvious error, yes. But claiming these as “factual errors” would, IMHO, be not seeing the forest for the trees. Most readers neither care nor would be affected, as they just need a rough background. Let’s remember, the book is not about BIOS or low-level CPU programming. It’s about Apple stuff. Nonetheless, I think it’s a good idea to reach out to the guy. I’ll send him an email about it (and credit this to you)
Anyway, when it comes to the Apple stuff, the author seems to know it pretty well. And I see he *is* backing up his claims with the numerous experiments and tools he gives out as part of the book (these have already proven invaluable, though they’re free, so you wouldn’t need the book…). In that sense, I think there’s ample testing and verification that can be done in the code samples to justify whatever claims. Thus, the information looks “solid” enough to me, and you may have come down a tad hard on the guy – like I said, Singh also has errors here and there, but to err is human. Nevertheless, your observations are great – and if you find any other errors, please post them here (or let Levin know)