It may also be that copy editors think that because it is tech, that what they see, although it does not make sense grammatically, does make sense to other techies. For a tech review I am currently working on, I had to specifically call the editor and tell him that the chapters were very poorly written, had lots of poor sentence construction, not to mention bad grammar, and that he should specifically be aware that the text made no sense no matter who was reading it. Hmmm... come to think of it, I haven't heard from those people lately. I wonder if they fired me? ;->
I suspect that in this mad rush to get tech books out the door, many of the publishing houses are operating under the assumption that whatever a tech writer writes is correct. Kinda like the emperor's new clothes? Can't be understood by a fool? Chuck ""Priscilla Oppenheimer"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > At 12:21 PM 1/17/02, R. Benjamin Kessler wrote: > >I have a couple of "nit-picky" complaints about the book (as I do about > >almost every book I read). There are some typo's as a previous poster > >indicated. One of my biggest pet peeves is the use of the term "continuous" > >when the author (probably) means "contiguous" - one sees this most often > >when discussing OSPF. > > That says that the author didn't look at the copy-edited material. New > authors assume that publisher's copy editors have a clue. They don't. They > apply rules for "fixing" words and sentences without any idea what they are > doing. > > This means that you will probably find other minor mistakes in the book > too. Don't blame the author, although the author should have been more > careful during the final phases of the book project. > > Cisco Press copy editors once changed every case of Mbps to MByte in a > book! In my book, in the index, they changed long fat network (LFN) to long > file names. See RFC 1323 for the true meaning of elephant (LFN). > > Thanks for your thorough review of the book. > > Priscilla > > > Note, this book isn't unique in this mis-use of the > >term; there are many CCO documents that also make this "error." I'm > >assuming that this is the product of a spell-checker that didn't know the > >term contiguous, suggested continuous and someone hit "replace all." Before > >the flame-war starts, I know that these two words have *similar* meanings > >but in this case I - my personal opinion - think that contiguous is 'more > >right' - besides, it's the term used in the RFC. > > > >Since I'm picking nits; the author indicates that the OSPF process ID on a > >router should be thought of "as an Autonomous System ID. This number should > >be the same on all routers within the autonomous system." Per CCO, this is > >a locally significant setting used only to distinguish between multiple OSPF > >routing process on a particular router. If we were to apply the RFC2119 > >definition of "should" to this statement one might think that certain > >problems may occur if this practice wasn't followed. I don't believe this > >to be the case but I'm sure someone on the list will correct me if I'm > >wrong. There's nothing wrong with using the same process ID on all of your > >OSPF routers; I would guess that networks are configured that way more often > >than not; but isn't a requirement. Given that the lab exam is all about > >splitting hairs to the most minute detail and knowing the various protocols > >in depth, it probably should have been noted (as in other texts) that two > >adjacent routers can have different process IDs configured. > > > >There are some outright mistakes in the book - I just checked the CiscoPress > >site for an errata and didn't see one yet. Here one that I recall off the > >top of my head: > > > >EIGRP - (p.691) at the bottom of the page, the 'distance' command. > >- this is almost a direct copy/paste from the IGRP chapter; does not include > >the required information to change the admin distance of the EIGRP routing > >process (which requires both an internal and external distance); it only > >lists the syntax to change the distance of a specific neighbor's updates. I > >find it funny that the EIGRP chapter says "For a specific example and more > >practice with the 'distance' command, see" the IGRP chapter. When you look > >at the IGRP chapter, it uses the same sentence to point you to the RIP > >chapter. > > > >Anyone who has walked into an EIGRP network with multiple, unfiltered > >redistribution points into a RIP domain will know first-hand the importance > >of knowing how a router handles internal vs. external EIGRP routes. > > > >Additionally, I thought the section on PPP authentication could have used > >some more work on the one-way authentication options (both PAP and CHAP). > > > >Bottom-line, this seems to be a well written book; it gives you some good > >examples and labs to work on your own, etc. It won't replace any of the > >other "must haves" on the bookshelf (e.g. Doyle, Caslow, Thomas, etc.) and > >unfortunately, (as it seems with all of the books published these days) you > >have to play 'reporter' and verify the information in the book with some > >other source (CCO, RFCs, other texts) - this is a topic I could rant on for > >quite some time (considering the $thousands - literally - I've spent on > >training materials which contain errors). > > > >-----Original Message----- > >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > >Sent: Wednesday, January 16, 2002 7:18 PM > >To: [EMAIL PROTECTED] > >Subject: OT: First Impressions - CCIE Practical Studies [7:32237] > > > > > >Just got my copy. > > > >Reading the "About the Authors" section alone is impressive. All those > >associated with the book are CCIE's. I look forward to discovering if there > >are any errors in the book. One would hope not, given the credentials of the > >writers and reviewers, one of whom was the Halifax Lab Proctor for several > >years. > > > >So far I have browsed all of the first chapter "The Key Components for > >Modeling an Internetwork" > > > >This chapter covers in good detail all those basic questions - the config > >register, configuring a router as a frame switch, password recovery, show > >and debug ( called "the big show" and "the big d" respectively, throughout > >the book. ) building a terminal server, and much much more. This alone tells > >me that this book might be a good investment for those just starting out, as > >well as those prepping for the CCIE Lab. Sure, all of this information is > >available elsewhere, but with this book, it is in one place, easily located, > >and clearly explained. > > > >There is even a section about configuring networking on windoze computers. > >Considering the number of raw beginners who are coming into the > >certification process, this is helpful. > > > >I'll have more comments after I have had a chance to look at the "good" > >stuff. > > > >Chuck > ________________________ > > Priscilla Oppenheimer > http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=32350&t=32237 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
