On Saturday 22 December 2001 04:58 am, Eric S. Raymond wrote:
> Rob Landley <landley@trommello.org>:
> > If you're going with a uniform terminology argument, you should drop MiB
> > altogether. Unless you want to submit a patch to the kernel to
> > standardize all the other occurences everywhere else? :)
>
> Rob, you haven't looked at the actual changes I made, have you?
I looked at the patch, which was actually fairly small. But it didn't seem
to be the only potential change along these lines, and I thought I'd object
now and avoid the rush. (Yeah I know, "too late"...)
> If you had, you'd realized that I have not introduced "kibibyte",
> or "mebibyte" or any of those terms anywhere.
Maybe not in this patch, but I got the impression it signified a policy
decision to change terminology and stick with the new one uniformly, at least
in the help files.
Since then, another part of the thread has indicated (and the help file now
says at the top) that the help file will say "binary megabytes" instead of
mebibytes. "mebibytes" for binary megabytes? If this policy was there in the
original patch, I missed it.
> The Configure.help
> changes involve only the IEC-standard abbreviations KiB, MiB, and GiB.
I didn't know the ISO was merely rubber-stamping somebody else's standard,
but I can't say I'm suprised. Well, I suppose I'm all for "catalyzing
progress in the information-industry and university communities", as the
IEC's web page says (isn't google fun). Gee, we'd never be able to figure
out what to call things if these guys weren't around to make decisions for
us...
Specifically, it seems they adpoted it as amendment 2 to IEC 60027-2,
standardizing kibi, mebi, gibi, tebi, pebi, and exbi, with symbols Ki, Mi,
Gi, Ti, Pi, and Ei. (A PiB obvioiusly and unambiguously being the number of
bytes required to hold an accurate floating point representation of Pi. :)
This does not, in fact, remove the term "mebibytes" to the discussion. It
means the current policy is to selectively follow part of the standard, and
explicitly ignore the rest of the standard as too ugly to live. The prefix
"mebi" is, in fact, explicitly part of the IEC standard the ISO AOLed, thus
"mebibytes" is what "MiB" is short for. (I wasn't even the one to introduce
the term mebibytes into this thread.)
> Try criticizing what I actually did, as opposed to what you merely *assume*
> I did. You'll be more convincing that way.
Ooh, why start now? :)
What you did was announce a new editorial policy. Look at the subject line
of the thread. That's noticeably larger than a single patch.
My objection is that this switch does not seem to be based on improving the
understandability of the documentation to that documentation's intended users
(who, on the whole, consider "7K RAM" to be sufficiently unambiguous without
even a B). We've always used domain based differentiation (ram is binary,
networking is decimal, disk needs to be specified because manufacturers lie
for marketing reasons). This seems to be a solution in search of a problem.
Now I agree that as numbers get bigger the distinction matters more (2% per
kilobyte, 5% per megabyte, 7% per gigabyte, and almost 10% per terabyte).
But the binary or decimal nature of the measurement has always been
application specific up until now, and I'm curious why that's suddenly not
good enough anymore. The new method is a much more fine-grained level of
detail which is, in fact, easier to screw up.
Is the help file even currently accurate with this extra distinction made?
Look at NCR53c8xx SCSI support, which says the transfer rate is 80 MB/s. Is
that really, accurately a million decimal megabytes per second? Is it 80.3
or 80.7? Has anyone ever cared to confirm this who was not capable of
looking in the code to determine the answer? Is there a POINT in specifying
"Men in Black" units everywhere that is currently generally accepted practice
to default to binary (although using i for bInary makes as much sense as
using i for decImal, if you ask me)?
The switch appears to be based on the assumption that conformance to a
standard issued by a bureaucratic body is arbitrarily better than established
practice. And yet that's not what it does, because it refuses to use the
long form...
The help file STILL uses the prefix "mega" without specifying binary or
decimal in at least these sections:
Synchronous transfer frequency in MHz
Enable kernel debugging symbols
Virtual memory file system support
Remote GDB kernel debugging
GDB Stub kernel debug
Just looking at the first, do you really think saying "binary mega-transfers"
is going to be less confusing? How about "mebi-transfers", people will know
right off what THAT means without having to look it up...
And you've already implied you want to change the symbol set for
CONFIG_NINO_4MB and such. How deeply into the kernel will these changes go?
The patch is a can of worms, and abandoning the current domain-based
defaults (ram is binary, network is decimal, disk needs to pick one) is not
something I see as an improvement. But you're the maintainer...
Rob
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Dec 23 2001 - 21:00:30 EST