Date: Thu, 6 Dec 2001 22:01:30 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.ORG> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Chad David <davidc@acns.ab.ca>, Luigi Rizzo <rizzo@aciri.org>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/share/man/man7 tuning.7 Message-ID: <Pine.NEB.3.96L.1011206214123.33559D-100000@fledge.watson.org> In-Reply-To: <200112070040.fB70eJi59420@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1011206214123.33559D-100000>