From owner-cvs-all Thu Dec 6 19: 1:57 2001 Delivered-To: cvs-all@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 0B65137B416; Thu, 6 Dec 2001 19:01:51 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id fB731Vi34013; Thu, 6 Dec 2001 22:01:31 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Thu, 6 Dec 2001 22:01:30 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Matthew Dillon Cc: Chad David , Luigi Rizzo , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/share/man/man7 tuning.7 In-Reply-To: <200112070040.fB70eJi59420@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 6 Dec 2001, Matthew Dillon wrote: > I really doubt that IDE tags can be both stable AND in wide-use > at the same time. Not for at least another, oh, 10 years. > Kinda like IDE in general :-( Always a moving target. > So leave it in please. I was simply observing that there are a number of seemingly absolute statements in the tuning guide that may become less absolute over time. I think adding some qualifications would be appropriate; not necessarily to that particular observation, but as a general strategy. Besides, your statement actually doesn't tell them not to use the tagging, it tells them not to buy the lines of drives that you list: Warning! These drives apparently have quality control problems and I do not recommend purchasing them at this time. If you need performance, go with SCSI. That seems to be a pretty different objection to the one you list above. > In regards to 'network suds'... some formalism is good, but don't > overdo it. There's certainly a lot of organizational work that > could be done but please don't go replacing words because they > sound 'too informal'. The Tuning document attempts to impart > a huge amount of information and if you don't inject a little > levity into it the users we are targeting with the document > will not be able to understand it, or will give up trying > to understand it after the first few paragraphs. Remember > our audience. With all due respect, what the hell is a network sud? Remember that while those of us who are familiar with the jargon may realize that's a cute joke, those who are not may wonder whether or not they have twisted pair suds, or whether their suds are suffering from interference from nearby power lines or an RF antena. (<-- this is sarcasm with a twist of seriousness) As before, I'm not suggesting we make this into a more dry document, rather, that if a choice of words ends up being less concise, it's worth chasing. Being informal about the content is not the same as obscuring the content. "mess with" probably means "modify", so why not say "modify"? While lending an air of levity to the situation is good, most of our users will be experimenting, tuning, or modifying, and not messing: let's take them seriously, because the chances are they take themselves seriously. "FreeBSD 4.3 flirted with turning off IDE write caching" doesn't necessary come across more clearly than "In FreeBSD 4.3, we experimented with disabling IDE write caching by default." Optionally adding "to address legitimate concerns with data integrity". It's still written in an informal tone (use of "we", et al) but it may be more clear. It not only makes us look more professional, but it also makes it seems like we don't consider our system a joke: we didn't flirt, we weighed the choices, decided on something, and later changed our minds based on available evidence and user needs. How about "Don't ever use it, it is far too dangerous." for async filesystems? Colloquial language is fun and all, but this does seem a little excessive. Some of the density problems may be addressable through re-structuring the document, and as we do that, increasing the level of professionalism is something that won't make the document harder to read--it might actually make it easier to read. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message