I guess it's a pretty quiet week in kernel-hacker land. Must be,
otherwise people would have better things to do than argue over KB
vs. KiB. The alternative would be to conclude that significant
portions of the lkml population prefer flaming to coding, and that
couldn't possibly be the case, could it?
Let me make a couple of things clear:
I am by no means in love with the new abbreviations described at
<http://physics.nist.gov/cuu/Units/binary.html>. I have the same
reflexes as the rest of you -- they kind of make me want to gag.
If there is a clear consensus from lkml, I will be happy to back
out this change. Perhaps this terminological standard does not
meet a real need, perhaps it will be rejected by most engineers and
deserves to wither on the vine. It's happened before.
However. In the *absence* of a clear consensus, I will follow best
practices. Best practice in editing a technical or standards document
is to (a) avoid ambiguous usages, seek clarity and precision; and (b)
to use, follow and reference international standards.
In fact, the first time David Woodhouse submitted this change, some
months ago, I rejected it. I have since, reluctantly, concluded
that I was wrong to do so. So when he re-submitted, I merged in
the patch.
My personal esthetic distaste for the new terminology (gack! "kibi"
sounds like something I would feed my cat!) is less important
than following best practices. I'm hoping it will seem less ugly as it
becomes more familiar.
I don't like my duty much in this instance. But my duty is clear.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
"As to the species of exercise, I advise the gun. While this gives [only]
moderate exercise to the body, it gives boldness, enterprise, and independence
to the mind. Games played with the ball and others of that nature, are too
violent for the body and stamp no character on the mind. Let your gun,
therefore, be the constant companion to your walks."
-- Thomas Jefferson, writing to his teenaged nephew.
On Thu, 2001-12-20 at 13:32, Eric S. Raymond wrote:
> I am by no means in love with the new abbreviations described at
> <http://physics.nist.gov/cuu/Units/binary.html>. I have the same
> reflexes as the rest of you -- they kind of make me want to gag.
I second that emotion.
> If there is a clear consensus from lkml, I will be happy to back
> out this change. Perhaps this terminological standard does not
> meet a real need, perhaps it will be rejected by most engineers and
> deserves to wither on the vine. It's happened before.
I'd vote for that.
> However. In the *absence* of a clear consensus, I will follow best
> practices. Best practice in editing a technical or standards document
> is to (a) avoid ambiguous usages, seek clarity and precision; and (b)
> to use, follow and reference international standards.
Perhaps if we could be so bold as to back Donald Knuth's KKB,MMB,GGB
proposal (of which I learned here:
http://www.linuxdoc.org/HOWTO/Large-Disk-HOWTO-3.html ). I understand
that muddying the waters is not the way to see clearly into the depths
of computer science for the unwashed masses, but the ambiguity that
currently exists is very real. I try to explain these issues on what
seems like a daily basis to many and the duplicitous terms are not
helpful.
> My personal esthetic distaste for the new terminology (gack! "kibi"
> sounds like something I would feed my cat!) is less important
> than following best practices. I'm hoping it will seem less ugly as it
> becomes more familiar.
It certainly rated high on my kibbles'n'bits meter as well :-)
Whatever we do with the abbreviations, I would strongly recommend we
spell out documention to help educate ( and ease the transition if we
switch terms) wherever possible. For example:
4 binary kilobyte pages
1024 decimal kilobyte disk
8.4 decimal gigabyte disks
4 binary gigabytes of memory
10 decimal gigabits of bandwith
or if that offends the sensibilities:
4 kilobytes (binary)
1024 kilobytes (decimal)
8.4 gigabytes (decimal)
I know that they are long on keystrokes, but in lieu of an accepted and
aesthetically pleasing standard, they are clear and unambiguous.
Regards,
Reid
--
Protect your rights, Geeks with Guns!
Reid Hekman <[email protected]>:
> Perhaps if we could be so bold as to back Donald Knuth's KKB,MMB,GGB
> proposal (of which I learned here:
> http://www.linuxdoc.org/HOWTO/Large-Disk-HOWTO-3.html ).
Hm. Attractive, but it doesn't have an ISO standard behind it.
> Whatever we do with the abbreviations, I would strongly recommend we
> spell out documention to help educate ( and ease the transition if we
> switch terms) wherever possible. For example:
>
> 4 binary kilobyte pages
> 1024 decimal kilobyte disk
> 8.4 decimal gigabyte disks
> 4 binary gigabytes of memory
> 10 decimal gigabits of bandwith
>
> or if that offends the sensibilities:
>
> 4 kilobytes (binary)
> 1024 kilobytes (decimal)
> 8.4 gigabytes (decimal)
>
> I know that they are long on keystrokes, but in lieu of an accepted and
> aesthetically pleasing standard, they are clear and unambiguous.
Good idea. I will make appropriate changes.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
Government should be weak, amateurish and ridiculous. At present, it
fulfills only a third of the role. -- Edward Abbey
On 20 Dec 01 at 14:27, Reid Hekman wrote:
> > If there is a clear consensus from lkml, I will be happy to back
> > out this change. Perhaps this terminological standard does not
> > meet a real need, perhaps it will be rejected by most engineers and
> > deserves to wither on the vine. It's happened before.
>
> I'd vote for that.
Well, I vote for that too. And I'm _for_ using KiB, MiB, GiB with all
my fingers. When you buy computer memory, it is always in ?iB units
(as nobody sane can upgrade computer equipped with 512000000 bytes
memory stick with some additional memory) but in all other cases (in-core
process size, hdd size, file size) it is very unclear what you mean.
Yes, error is only 2% - but if everyone around can give me 2% of
his HDD capacity, I think that I'm going to be very happy.
Yes, it is new prefix, but everything is sometime new. When computers
had 64KB of memory, there was capital K as 1024 bytes. But then computer
grew up, and already used letter 'M' was used as 2^20. It was serious
mistake, and as using same expression for different prefixes is unacceptable
(at least for me), and I do not think that we are going to use 1GdHz CPUs,
we are going to use computers with 4GiB of memory.
Thanks,
Petr Vandrovec
[email protected]
On Thu, 2001-12-20 at 15:07, Mark Hahn wrote:
> > 4 binary kilobyte pages
> > 1024 decimal kilobyte disk
> > 8.4 decimal gigabyte disks
> > 4 binary gigabytes of memory
> > 10 decimal gigabits of bandwith
> >
> > or if that offends the sensibilities:
> >
> > 4 kilobytes (binary)
> > 1024 kilobytes (decimal)
> > 8.4 gigabytes (decimal)
> >
> > I know that they are long on keystrokes, but in lieu of an accepted and
> > aesthetically pleasing standard, they are clear and unambiguous.
>
> though as your example showed, there's very little, if any,
> ambiguity: disk is always decimal, memory is always binary, etc.
>
My examples were by no means exhaustive. One also must consider things
like network traffic and in that case there seems to be a distinction
between computers and telecommunications. I've also seen pointed out
that the "MB" of 1.44MB floppy fame is actually 1,024,000 bytes.
More importantly, less educated users than yourself might not strike up
the distinction between disk and memory units. The common example being,
"why does my 9.1GB hard drive show up as 8.9GB?" Rather than explain
this again and again, or expect users to find the one FAQ entry amidst a
sea of configuration help, they could devine the answer from the clear
unit measures of decimal or binary that crop up everywhere.
For me, my reasons for full names are consistency and aesthetics --
allowing us to sidestep the abortion that the IEC has created of SI
units.
Regards,
Reid
On Thu, Dec 20, 2001 at 02:27:02PM -0600, Reid Hekman wrote:
> Perhaps if we could be so bold as to back Donald Knuth's KKB,MMB,GGB
> proposal (of which I learned here:
> http://www.linuxdoc.org/HOWTO/Large-Disk-HOWTO-3.html ). I understand
> that muddying the waters is not the way to see clearly into the depths
> of computer science for the unwashed masses, but the ambiguity that
> currently exists is very real. I try to explain these issues on what
> seems like a daily basis to many and the duplicitous terms are not
> helpful.
KKB looks a million times better than KiB. maybe it's the lowercase
letter, i don't know.
> > My personal esthetic distaste for the new terminology (gack! "kibi"
> > sounds like something I would feed my cat!) is less important
> > than following best practices. I'm hoping it will seem less ugly as it
> > becomes more familiar.
>
> It certainly rated high on my kibbles'n'bits meter as well :-)
>
> Whatever we do with the abbreviations, I would strongly recommend we
> spell out documention to help educate ( and ease the transition if we
> switch terms) wherever possible. For example:
>
> 4 binary kilobyte pages
> 1024 decimal kilobyte disk
> 8.4 decimal gigabyte disks
> 4 binary gigabytes of memory
> 10 decimal gigabits of bandwith
>
> or if that offends the sensibilities:
>
> 4 kilobytes (binary)
> 1024 kilobytes (decimal)
> 8.4 gigabytes (decimal)
>
> I know that they are long on keystrokes, but in lieu of an accepted and
> aesthetically pleasing standard, they are clear and unambiguous.
i will agree that the ambiguity sucks and something needs to be done
about it, but i really do find the SI units for binary plain ugly. i
doubt that anyone would be willing to type as much text for referencing
simple sizes as you explained above.
perhaps simply a base suffix:
4KB(2) == 4 * 2^10
4MB(2) == 4 * 2^20
4KB(10) == 4 * 10^3
4MB(10) == 4 * 10^4
it's definitely wierd to look at, but it seems to get the point across
easier. it defines the base, instead of referencing a name (kibi?
please, i don't think enough people will start using these
grossly-sounding prefixes enough to make it the de facto standard).
or perhaps a (d) or (b) qualifier to refer to decimal or binary.
perhaps everybody should just suck it up and go with what's standard?
-mike
--------------------------------------------------------------------------
/~\ The ASCII all that is gold does not glitter
\ / Ribbon Campaign not all those who wander are lost
X Against HTML -- jrr tolkien
/ \ Email!
radiusd+mysql: http://www.cafes.net/~diz/kiss-radiusd
--------------------------------------------------------------------------
On Thu, Dec 20, 2001 at 02:32:47PM -0500, Eric S. Raymond wrote:
> I guess it's a pretty quiet week in kernel-hacker land. Must be,
> otherwise people would have better things to do than argue over KB
> vs. KiB. The alternative would be to conclude that significant
> portions of the lkml population prefer flaming to coding, and that
> couldn't possibly be the case, could it?
The kb versus KB versus KiB versus whatever may come next was always a
very flammable cause.
Now my opinion on this would be: By sticking KiB everywhere nothing is
helped. To the knowledgeable, it's nothing new that memory is measured
in binary units, while ethernet speed in decimal ones. To the newbie,
KiB is about as cryptical as KB and he'll never know which is which,
because as a newbie (s)he didn't read the standards.
And of course, every search-and-replace cleanup will always upset many
people regardless which direction it goes.
On the other hand, making documentation less ambiguous is always a good
thing. I'd suggest a more careful approach, adding descriptive wording
in places where bits and bytes may be confused, and where binary or
decimal prefixes may be.
And speaking of the 1 Mbps connection - I fear that in many cases
that'll be 1024000 bytes per second. What M is that? Binary or decimal?
Who does care?
--
Vojtech Pavlik
SuSE Labs
Eric S. Raymond writes:
> If there is a clear consensus from lkml, I will be happy to back
> out this change. Perhaps this terminological standard does not
> meet a real need, perhaps it will be rejected by most engineers and
> deserves to wither on the vine. It's happened before.
Another option: maybe the choice of KB vs KiB vs KKB should be a
configuration choice.
--David Garfield
David Garfield <[email protected]>:
> Another option: maybe the choice of KB vs KiB vs KKB should be a
> configuration choice.
You *must* be joking.
Please tell me you're joking.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
According to the National Crime Survey administered by the Bureau of
the Census and the National Institute of Justice, it was found that
only 12 percent of those who use a gun to resist assault are injured,
as are 17 percent of those who use a gun to resist robbery. These
percentages are 27 and 25 percent, respectively, if they passively
comply with the felon's demands. Three times as many were injured if
they used other means of resistance.
-- G. Kleck, "Policy Lessons from Recent Gun Control Research,"
Law and Contemporary Problems 49, no. 1. (Winter 1986.): 35-62.
On Thu, Dec 20, 2001 at 06:52:26PM -0500, Eric S. Raymond wrote:
> David Garfield <[email protected]>:
> > Another option: maybe the choice of KB vs KiB vs KKB should be a
> > configuration choice.
>
> You *must* be joking.
>
Hopefully. Here's a serious one tho. Why don't we say at the bottom:
1 kB (or KB or KiB or ...) is 2^10 bytes. Like we do for code that can
be compiled as a module... As long as we're consistant in the suffix,
and we define it, it doesn't matter what it is.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
Eric S. Raymond wrote:
> I guess it's a pretty quiet week in kernel-hacker land. Must be,
> otherwise people would have better things to do than argue over KB
> vs. KiB. The alternative would be to conclude that significant
> portions of the lkml population prefer flaming to coding, and that
> couldn't possibly be the case, could it?
Surely not?
> However. In the *absence* of a clear consensus, I will follow best
> practices. Best practice in editing a technical or standards document
> is to (a) avoid ambiguous usages, seek clarity and precision; and (b)
> to use, follow and reference international standards.
"Best" practice? That's the *only* practice! Guesswork and assumption
has no place in technical documentation!
Mike
On Thursday 20 December 2001 17:52, Eric S. Raymond wrote:
> David Garfield <[email protected]>:
> > Another option: maybe the choice of KB vs KiB vs KKB should be a
> > configuration choice.
>
Um, you know, all due repect to Knuth, the God, I think that
someof his ideas are downright silly. Now, my suggestion
is different, namely, inserting a 2 in the unit such as "K2B"
meaning Kilo (base2) Byte. It's not like we don't have a
precendent from the chemistry and physics fields.
--
[email protected].
On Thu, 20 Dec 2001, Reid Hekman wrote:
> or if that offends the sensibilities:
>
> 4 kilobytes (binary)
> 1024 kilobytes (decimal)
> 8.4 gigabytes (decimal)
"decimal" is implied when using SI prefixes.
--
Matthias Andree
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." Benjamin Franklin
Eric S. Raymond writes:
> David Garfield <[email protected]>:
> > Another option: maybe the choice of KB vs KiB vs KKB should be a
> > configuration choice.
>
> You *must* be joking.
>
> Please tell me you're joking.
No, I'm serious. I will understand if CML2 does not support
meta-configuration. A configuration choice as I described above could
be viewed as a minor facet of a language configuration choice.
(Should kernel configuration be internationalized or at least
internationalizable?)
Choice of kB vs KB vs KiB vs KKB could also be used in some places in
the kernel. For instance, /proc/meminfo currently shows "kB".
--David
David Garfield <[email protected]>:
> Eric S. Raymond writes:
> > Please tell me you're joking.
>
> No, I'm serious. I will understand if CML2 does not support
> meta-configuration. A configuration choice as I described above could
> be viewed as a minor facet of a language configuration choice.
> (Should kernel configuration be internationalized or at least
> internationalizable?)
>
> Choice of kB vs KB vs KiB vs KKB could also be used in some places in
> the kernel. For instance, /proc/meminfo currently shows "kB".
What, and *encourage* non-uniform terminology? No, I won't do that.
Better to have a single standard set of abbreviations, no matter how
ugly, than this.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
The American Republic will endure, until politicians realize they can
bribe the people with their own money.
-- Alexis de Tocqueville
On Fri, Dec 21, 2001 at 01:43:29PM -0500, David Garfield wrote:
> Eric S. Raymond writes:
> > David Garfield <[email protected]>:
> > > Another option: maybe the choice of KB vs KiB vs KKB should be a
> > > configuration choice.
> >
> > You *must* be joking.
> >
> > Please tell me you're joking.
>
> No, I'm serious. I will understand if CML2 does not support
> meta-configuration. A configuration choice as I described above could
> be viewed as a minor facet of a language configuration choice.
> (Should kernel configuration be internationalized or at least
> internationalizable?)
>
> Choice of kB vs KB vs KiB vs KKB could also be used in some places in
> the kernel. For instance, /proc/meminfo currently shows "kB".
Whatever the choice ends up being, KB is always incorrect, unless you
intend to specify some strange formula where the number of bytes (B)
combined with the temperature in Kelvin (K) has anything to do with
things.
/David Weinehall
_ _
// David Weinehall <[email protected]> /> Northern lights wander \\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </
On Fri, Dec 21, 2001 at 01:40:34PM -0500, Eric S. Raymond wrote:
> What, and *encourage* non-uniform terminology? No, I won't do that.
> Better to have a single standard set of abbreviations, no matter how
> ugly, than this.
So, encouraging non-uniform terminology, breaking applicates *and*
confusing the hell out of everyone is better? Face it, the only
people trying to confuse things are the disk vendors. DRAM is sold
by the MB, everyone talks about MB == 1024*1024... I'm having a
hard time giving a sympathetic ear to anyone try to change the well
established, and consistent (barring the storage venduhs), standard.
-ben
--
Fish.
On Friday 21 December 2001 13:12, David Weinehall wrote:
[snip]
> Whatever the choice ends up being, KB is always incorrect, unless you
> intend to specify some strange formula where the number of bytes (B)
> combined with the temperature in Kelvin (K) has anything to do with
> things.
>
>
>
> /David Weinehall
The way the metric prefixes work is that multiplicative prefixes are
capitalized and divisional prefixes are in lower case.
mm = millimeter v. Mg= megameter
cm = centimeter v. Km = kilometer
Now, the only reason that 'k' has been allowed instead of "K"
is due to the Satem/Katem split in IndoEuropean languages.
If we were truly consistant, we would use
km = kentimeter for 1/100
or
Cm = cuilometer for 100
But this raises the problem that in most IE languages, "i" or "e"
after a "c" changes the sound from hard to soft. That's why
I stuck that "u" in cuilometer. But again, that's silly.
So unless we all change our language to "Katem" based ones,
legacy usage will prevail.
That's my way of saying that you "Kelvins" argument is silly
because there do not exist any cases where "KB" would be
mistaken for Kelvins Bytes.
Just my 2 kents.
--
[email protected].
On Friday 21 December 2001 07:01, Timothy Covell wrote:
> On Thursday 20 December 2001 17:52, Eric S. Raymond wrote:
> > David Garfield <[email protected]>:
> > > Another option: maybe the choice of KB vs KiB vs KKB should be a
> > > configuration choice.
>
> Um, you know, all due repect to Knuth, the God, I think that
> someof his ideas are downright silly. Now, my suggestion
> is different, namely, inserting a 2 in the unit such as "K2B"
> meaning Kilo (base2) Byte. It's not like we don't have a
> precendent from the chemistry and physics fields.
I've changed my mind. K2B would seem to imply
2**3 Bytes, which is 8 Bytes.
I think that way to solve the issue is to just byte
the bullet and stop equating 1024 with K. It's
just such an inconsistant and ad hoc hack.
The only truly logical way to do this would be
to base everything on bits and powers of
two. But, since we run out of common prefixes
at 2**6 (exa), we should just stick to decimal
and scientific format. 1024 = 2**10.
--
[email protected].
On Fri, Dec 21, 2001 at 02:18:47PM -0500, Benjamin LaHaise wrote:
So, encouraging non-uniform terminology, breaking applicates *and*
confusing the hell out of everyone is better? Face it, the only
people trying to confuse things are the disk vendors. DRAM is
sold by the MB, everyone talks about MB == 1024*1024... I'm
having a hard time giving a sympathetic ear to anyone try to
change the well established, and consistent (barring the storage
venduhs), standard.
And disks by the GB where GB == 1000^3 so I don't see any problem in
moving from KB to KiB and friends ESPECIALLY AS THEY ARE STANDARDIZED
BEYOND THE KERNEL and nothing will change this.
--CW
On Fri, 21 Dec 2001, Benjamin LaHaise wrote:
> On Fri, Dec 21, 2001 at 01:40:34PM -0500, Eric S. Raymond wrote:
> > What, and *encourage* non-uniform terminology? No, I won't do that.
> > Better to have a single standard set of abbreviations, no matter how
> > ugly, than this.
>
> So, encouraging non-uniform terminology, breaking applicates *and*
> confusing the hell out of everyone is better? Face it, the only
> people trying to confuse things are the disk vendors. DRAM is sold
> by the MB, everyone talks about MB == 1024*1024... I'm having a
> hard time giving a sympathetic ear to anyone try to change the well
> established, and consistent (barring the storage venduhs), standard.
Not true. Bandwidth is measured in metric. Pixels are measured in metric.
Basically anything but RAM is measured in metric. RAM is the exception
because of its intimate relation to bus width and that's an obvious
anachronism. There's no reason anyone but a systems programmer should give
a damn about powers of two.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
On Fri, 21 Dec 2001, Benjamin LaHaise wrote:
> So, encouraging non-uniform terminology, breaking applicates *and*
> confusing the hell out of everyone is better? Face it, the only people
> trying to confuse things are the disk vendors. DRAM is sold by the MB,
> everyone talks about MB == 1024*1024... I'm having a hard time giving a
> sympathetic ear to anyone try to change the well established, and
> consistent (barring the storage venduhs), standard.
And disk vendors aren't even consistant! At least my 30 GB and 40 GB drives
have 60036480 and 80418240 sectors, respectively (512 bytes each).
That computes to 30.7*10^9 and 41.2*10^9 or 28.6*2^30 and 38.3*2^30 bytes.
If you want numbers near 30 and 40 you need to calculate 30.0*10^6*2^10 and
40.2*10^6*2^10!
And as somebody else pointed out, 1 Mbit/s line is't 10^6 bit/s nor 2^20
bit/s line, either, a but 1024000 bit/s line.
=> Even if Configure.help would use kiB, MiB, GiB etc. it wouldn't remove
many of the ambiguities. Is it worth the pain?
> -ben
// /
....................................Timo Jantunen .......................
ZZZ (Used to represent :Kuuns?de 8 A 28: Email: jeti @iki.fi :
the sound of a person snoring.) :02210 Espoo : http://iki.fi/jeti :
Webster's Encyclopedic Unabridged :Finland : GSM +358-40-5763131 :
Dictionary of the English Language :...............:.....................:
On Fri, 21 Dec 2001, Timothy Covell wrote:
>
> On Friday 21 December 2001 13:12, David Weinehall wrote:
> [snip]
>
> > Whatever the choice ends up being, KB is always incorrect, unless you
> > intend to specify some strange formula where the number of bytes (B)
> > combined with the temperature in Kelvin (K) has anything to do with
> > things.
> >
> >
> >
> > /David Weinehall
>
> The way the metric prefixes work is that multiplicative prefixes are
> capitalized and divisional prefixes are in lower case.
Nonsense. Some of what you're calling multiplicative prefixes (as if they
weren't *all* multiplicative ;-) are capitalized, and others are not. kilo
(10^3) is k, hecto (10^2) is h, and deca (10^1) is da, for example. See
<http://www.bipm.fr/enus/6_Publications/si/si-brochure.html> for the
official guidelines (page 23 if you read English, and page 28 if you read
French).
More relevant to the whole Configure.help discussion, if you want to
pedantic, official SI guidelines also state on the same page that:
"These SI prefixes refer strictly to powers of 10. They should not be used
to indicate powers of 2 (for example, one kilobit represents 1000 bits and
not 1024 bits)."
later,
chris
Eric S. Raymond writes:
> What, and *encourage* non-uniform terminology? No, I won't do that.
> Better to have a single standard set of abbreviations, no matter how
> ugly, than this.
Valid argument. I will point out that the current version is
non-uniform. Quoting from Configure.help :
> # Choice: himem
> High Memory support
> CONFIG_NOHIGHMEM
> Linux can use up to 64 Gigabytes of physical memory on x86 systems.
> However, the address space of 32-bit x86 processors is only 4
> Gigabytes large. That means that, if you have a large amount of
> physical memory, not all of it can be "permanently mapped" by the
> kernel. The physical memory that's not permanently mapped is called
> "high memory".
>
> If you are compiling a kernel which will never run on a machine with
> more than 960 megabytes of total physical RAM, answer "off" here
> (default choice and suitable for most users). This will result in a
> "3GiB/1GiB" split: 3GiB are mapped so that each process sees a 3GiB
> virtual memory space and the remaining part of the 4GiB virtual memory
> space is used by the kernel to permanently map as much physical memory
> as possible.
>
> If the machine has between 1 and 4 Gigabytes physical RAM, then
> answer "4GB" here.
Note "3GiB/1GiB" and "4GB".
--David
On Sat, Dec 22, 2001 at 09:10:33AM +1300, Chris Wedgwood wrote:
> And disks by the GB where GB == 1000^3 so I don't see any problem in
> moving from KB to KiB and friends ESPECIALLY AS THEY ARE STANDARDIZED
> BEYOND THE KERNEL and nothing will change this.
If you think GB == 1000^3, then please go "correct" all the DRAM
manufacturers out in the world. They just sent me 1GB of ram and
it's coming up as 1073741824 bytes. Please help! They have no
option for GiB!!!
-ben
--
Fish.
On Fri, 21 Dec 2001, Benjamin LaHaise wrote:
> On Sat, Dec 22, 2001 at 09:10:33AM +1300, Chris Wedgwood wrote:
> > And disks by the GB where GB == 1000^3 so I don't see any problem in
> > moving from KB to KiB and friends ESPECIALLY AS THEY ARE STANDARDIZED
> > BEYOND THE KERNEL and nothing will change this.
>
> If you think GB == 1000^3, then please go "correct" all the DRAM
> manufacturers out in the world. They just sent me 1GB of ram and
> it's coming up as 1073741824 bytes. Please help! They have no
> option for GiB!!!
Also, a GB of disk space really is 2^10 * 10^6 ...
Better make sure we get it consistent ... *runs like hell*
Rik
--
DMCA, SSSCA, W3C? Who cares? http://thefreeworld.net/
http://www.surriel.com/ http://distro.conectiva.com/
On Fri, Dec 21, 2001 at 06:36:22PM -0200, Rik van Riel wrote:
> Also, a GB of disk space really is 2^10 * 10^6 ...
>
> Better make sure we get it consistent ... *runs like hell*
I always thought they'd like to count the size of disks in bits... man,
don't you really want on of those new 240Gbit disks? I hear they can
pull in a sustained 200Gbit/s on reads!
-ben
--
Fish.
On Fri, Dec 21, 2001 at 03:47:50PM -0500, Benjamin LaHaise wrote:
On Fri, Dec 21, 2001 at 06:36:22PM -0200, Rik van Riel wrote:
> Also, a GB of disk space really is 2^10 * 10^6 ...
>
> Better make sure we get it consistent ... *runs like hell*
I always thought they'd like to count the size of disks in bits...
man, don't you really want on of those new 240Gbit disks? I hear
they can pull in a sustained 200Gbit/s on reads!
But what Rik points out shows that right now there is ambiguity
BECAUSE OF LACK OF STANDARDIZATION --- because GB is vague at the very
best, disk manufactures get to claim nice marketing numbers.
As for bits/second sort of thing, this is common in networking of
course, especially when they talk about raw data rate and ignore
framing overhead and such like.
--cw
On Fri, Dec 21, 2001 at 03:31:36PM -0500, Benjamin LaHaise wrote:
If you think GB == 1000^3, then please go "correct" all the DRAM
manufacturers out in the world. They just sent me 1GB of ram and
it's coming up as 1073741824 bytes. Please help! They have no
option for GiB!!!
I don't want to get dragged into this silly debate; the point I was
making is that we already have considerable inconsistency and choosing
STANDARDS BASED tokens might not be a bad thing.
The nomenclature in use here is bigger than Linux (yes, believe it or
not such a thing is possible!), and like it or not people should just
get over it.
Standards exist to make peoples lives easier, the fact the hard drive
and memory vendors currently don't use these phrases right now doesn't
make the standard wrong --- this world is full of clue-less marketing
people and nothing will change this.
Accept that KB and GB are *wrong* (this isn't a statement of opinion
but rather of fact [1]) and then choose whether or not Linux
documentation should be wrong or right.
--cw
[1] IMO anyhow :)
On Sat, Dec 22, 2001 at 09:57:11AM +1300, Chris Wedgwood wrote:
> I don't want to get dragged into this silly debate; the point I was
> making is that we already have considerable inconsistency and choosing
> STANDARDS BASED tokens might not be a bad thing.
They're defacto standards that have been in use for well over a decade.
If the same could be said about GiB, maybe I could agree with you.
> The nomenclature in use here is bigger than Linux (yes, believe it or
> not such a thing is possible!), and like it or not people should just
> get over it.
Hmmm, all of the advertising, computer media and electrical engineering
related material I've read recently seems to be using GB. In fact, there
was one very article about the whole issue that found the computer
industry to be remarkably consistent in using terms like "10GB" with no
space between the number and the measuring unit. Oh wait, sorry, that's
not formally approved by any standards bodies.
> Standards exist to make peoples lives easier, the fact the hard drive
> and memory vendors currently don't use these phrases right now doesn't
> make the standard wrong --- this world is full of clue-less marketing
> people and nothing will change this.
Many standards bodies are examples of confusopolies. Take a look at the
POSIX threading standards. Do they make people's lives easier under
Linux? Should we accept every standard at face value and follow it
obediently wherever it takes us?
> Accept that KB and GB are *wrong* (this isn't a statement of opinion
> but rather of fact [1]) and then choose whether or not Linux
> documentation should be wrong or right.
Can you send me replacements for all the documentation I've got that
mentions GB or KB then? I wouldn't want to be non-compliant.
-ben
On Fri, 21 Dec 2001, Benjamin LaHaise wrote:
> On Sat, Dec 22, 2001 at 09:57:11AM +1300, Chris Wedgwood wrote:
> > Accept that KB and GB are *wrong* (this isn't a statement of opinion
> > but rather of fact [1]) and then choose whether or not Linux
> > documentation should be wrong or right.
>
> Can you send me replacements for all the documentation I've got that
> mentions GB or KB then? I wouldn't want to be non-compliant.
And how about my 17 M-KiByte disk ?
(yes, 17 million kibibytes, plus or minus whatever the amount of
disk space is the factory's low-level format found ... probably
as much as an error as getting the exact word in the manual)
cheers,
Rik
--
DMCA, SSSCA, W3C? Who cares? http://thefreeworld.net/
http://www.surriel.com/ http://distro.conectiva.com/
On Sat, 22 Dec 2001, Chris Wedgwood wrote:
> On Fri, Dec 21, 2001 at 03:47:50PM -0500, Benjamin LaHaise wrote:
> On Fri, Dec 21, 2001 at 06:36:22PM -0200, Rik van Riel wrote:
>
> > Also, a GB of disk space really is 2^10 * 10^6 ...
> But what Rik points out shows that right now there is ambiguity
> BECAUSE OF LACK OF STANDARDIZATION --- because GB is vague at the very
> best, disk manufactures get to claim nice marketing numbers.
Actually, I was more trying to ridicule the people who believe
we have any chance in hell of "getting it right".
Personally I believe we should stick to tradition. Better let
people be confused about the last 10% of capacity than confused
about the meaning of the text ...
cheers,
Rik
--
DMCA, SSSCA, W3C? Who cares? http://thefreeworld.net/
http://www.surriel.com/ http://distro.conectiva.com/
On Sat, Dec 22, 2001 at 10:00:17AM +1300, Chris Wedgwood wrote:
> But what Rik points out shows that right now there is ambiguity
> BECAUSE OF LACK OF STANDARDIZATION --- because GB is vague at the very
> best, disk manufactures get to claim nice marketing numbers.
GiB is not a useful standard because NOBODY USES IT. When it's in
common use, then consider applying it to the kernel, but please,
not before then.
-ben
--
Fish.
David Garfield <[email protected]>:
> Eric S. Raymond writes:
> > What, and *encourage* non-uniform terminology? No, I won't do that.
> > Better to have a single standard set of abbreviations, no matter how
> > ugly, than this.
>
> Valid argument. I will point out that the current version is
> non-uniform. Quoting from Configure.help :
>
>
> > # Choice: himem
> > High Memory support
> > CONFIG_NOHIGHMEM
> > Linux can use up to 64 Gigabytes of physical memory on x86 systems.
> > However, the address space of 32-bit x86 processors is only 4
> > Gigabytes large. That means that, if you have a large amount of
> > physical memory, not all of it can be "permanently mapped" by the
> > kernel. The physical memory that's not permanently mapped is called
> > "high memory".
> >
> > If you are compiling a kernel which will never run on a machine with
> > more than 960 megabytes of total physical RAM, answer "off" here
> > (default choice and suitable for most users). This will result in a
> > "3GiB/1GiB" split: 3GiB are mapped so that each process sees a 3GiB
> > virtual memory space and the remaining part of the 4GiB virtual memory
> > space is used by the kernel to permanently map as much physical memory
> > as possible.
> >
> > If the machine has between 1 and 4 Gigabytes physical RAM, then
> > answer "4GB" here.
>
>
> Note "3GiB/1GiB" and "4GB".
Yeah, that's because I can't touch the symbol namespace. Not yet, anyway.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
He that would make his own liberty secure must guard even his enemy from
oppression: for if he violates this duty, he establishes a precedent that
will reach unto himself. -- Thomas Paine
On Fri, 21 Dec 2001, Eric S. Raymond wrote:
> What, and *encourage* non-uniform terminology? No, I won't do that.
> Better to have a single standard set of abbreviations, no matter how
> ugly, than this.
Last I checked the purpose of language was _communication_.
Better use words people understand.
Also, the kB vs KiB mess is so ambiguous and complex that
it virtually guarantees that the _writers_ of documentation
will get it wrong occasionally and only confuse the readers
more.
As a last point, we shouldn't forget about the inconsistent
way in which the marketing departments of hardware vendors
apply these units to their products. In many cases binary
and decimal units are mixed, leading to something which is
impossible to "get right". Disk space would be one example
of this, but I'm sure there are more.
regards,
Rik
--
DMCA, SSSCA, W3C? Who cares? http://thefreeworld.net/
http://www.surriel.com/ http://distro.conectiva.com/
On Fri, 21 Dec 2001, Benjamin LaHaise wrote:
> On Sat, Dec 22, 2001 at 09:10:33AM +1300, Chris Wedgwood wrote:
> > And disks by the GB where GB == 1000^3 so I don't see any problem in
> > moving from KB to KiB and friends ESPECIALLY AS THEY ARE STANDARDIZED
> > BEYOND THE KERNEL and nothing will change this.
>
> If you think GB == 1000^3, then please go "correct" all the DRAM
> manufacturers out in the world. They just sent me 1GB of ram and
> it's coming up as 1073741824 bytes. Please help! They have no
> option for GiB!!!
If you think GB == 1024^3, then please go "correct" all the disk
manufacturers out in the world. They just sent me 1GB of disk and
it's coming up as 1000000000 bytes. Please help! They have no
option for GiB!!!
It's already clear that the terminology is internally inconsistent, now we
can either clarify it or live with the existing confusion.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
Benjamin LaHaise wrote:
> GiB is not a useful standard because NOBODY USES IT. When it's in
> common use, then consider applying it to the kernel, but please,
> not before then.
What better place to start "common use" then the kernel source.
Let's lead the way, not wait around to follow others.
Somebody has to be first, why not us?
Then once it get more common, we will have
been a leader forging into a brave new world :)
-Thomas
Just my 2.8 KiB worth :)
On Friday 21 December 2001 01:33 pm, Thomas Dodd wrote:
> Benjamin LaHaise wrote:
> > GiB is not a useful standard because NOBODY USES IT. When it's in
> > common use, then consider applying it to the kernel, but please,
> > not before then.
>
> What better place to start "common use" then the kernel source.
> Let's lead the way, not wait around to follow others.
>
> Somebody has to be first, why not us?
> Then once it get more common, we will have
> been a leader forging into a brave new world :)
Maybe because there's strong resistance to the change in the very place
you'd evidently like to START the change? That's generaly a clue that
it'd be best NOT to try and make the change.
>
> -Thomas
>
> Just my 2.8 KiB worth :)
At 07:17 PM 12/21/01 -0200, Rik van Riel wrote:
>As a last point, we shouldn't forget about the inconsistent
>way in which the marketing departments of hardware vendors
>apply these units to their products. In many cases binary
>and decimal units are mixed, leading to something which is
>impossible to "get right". Disk space would be one example
>of this, but I'm sure there are more.
>
>regards,
>
>Rik
OK, how about this silly suggestion: DON'T USE ABBREVIATIONS IN DOCUMENTATION.
For example, let me propose an "edit" to the text that has been appearing
in this thread to eliminate the ambiguity:
> # Choice: himem
> High Memory support
> CONFIG_NOHIGHMEM
> Linux can use up to 64 * 2^30 bytes (64 gigabytes) of physical memory
on x86 systems.
> However, the address space of 32-bit x86 processors is only 4 * 2^30
bytes (four gigabytes)
> large. That means that, if you have a large amount of
> physical memory, not all of it can be "permanently mapped" by the
> kernel. The physical memory that's not permanently mapped is called
> "high memory".
>
> If you are compiling a kernel which will never run on a machine with
> more than 960 * 2^20 bytes (960 megabytes) of total physical RAM,
answer "off" here
> (default choice and suitable for most users). This will result in a
> 3:1 split: each process sees a 3 * 2^30 byte (three gigabyte)
> virtual memory space, and the remaining 1 * 2^30 (one gigabyte)
of virtual memory
> space is used by the kernel to permanently map as much physical memory
> as possible.
>
> If the machine has between one 2^30 bytes and four 2^30 bytes of
physical RAM, then
> answer "4GB" here.
In this edit, the only place where the abbreviation "GB" appears is in the
symbol definition space. Configuration symbols are by custom all
upper-case, so the standard for capitalization as specified in SI is
violated in the interest of a symbol space that is consistent.
What kills me is that people forget the origin of KB as a standard
designation for "kilobyte" in the first place. Does anyone remember the
KSR-33 teletype, the early dot-matrix printers, and other output devices
that output only upper-case characters? Maybe you youngsters don't recall
that lower-case character devices were EXPENSIVE -- I still have a TI
Silent 700 terminal that did output lower-case when connected to systems
that understood the full ASCII alphabet, but those systems were few and far
between in business applications -- upper-case-only was "good enough." How
about tab machines that never did have lower-case, such as the 407 printing
accounting machine?
It got worse when you need to differentiate between "bytes" and "bits"
because you didn't have the luxury of using "B" for "byte" and "b" for
"bit" -- so that's why you see in legacy documentation a lone "K" for
"kilobit".
Have you noticed that some schematic packages *still* don't support lower
case for all output devices?
So now you know where the common usage of K, KB, MB, GB and the rest came
from -- limitations in the early tools for doing electronic documentation
of computer systems. Now, some of you may scream that we no longer have
those limitations -- but what are you going to do with the vast body of
written knowledge that is written using the accepted abbreviations of the
time? Unless someone is going to go back and re-edit 30 years of academic
papers, journal articles, and legacy documentation of equipment already in
use (can you say telephone systems?) then any argument about re-doing
abbreviations "for esthetic reasons" is either pointless or yet another
cause for confusion. Especially as this has every stigmata of becoming a
religious war.
So here we are, campers, arguing about abbreviations when in fact there is
no real NEED for abbreviations outside of the config symbol space. Why not
just take the few extra bytes (they are not a penny each anymore) to spell
out what you really mean? Why do we need MB or mB or MiB for
"megabyte"? Sometimes we get so wrapped up in our abbreviations that we
lose sight of the fact that the original job of a HELP FILE is to HELP, to
COMMUNICATE really useful information to the person trying to configure
their Linux kernel to a specific purpose. Don't forget that the audience
for configure.help goes far beyond the 30K of us (oops, I used an
abbreviation -- sorry) that work with this sort of stuff on a continuing
basis -- members of the priesthood, if you will. What would your mother or
grandmother say if confronted with this sort of stuff? Is it necessary to
obfuscate your meaning to the unwashed? (Even my edit caters to the expert
to some extent -- I admit it.)
Frankly, if the reason you use abbreviations is because you type slowly, I
can't feel any pain for you. There are lots of courses, sources, and even
gaming software around the world designed to teach you to type on a QWERTY
keyboard, far too many for me to feel any pain at all about your lack -- if
you are too lazy to learn a necessary skill for your craft or hobby, then
you might want to think about finding another career or passtime.
Oh, before someone quotes my Slashdot interview and says "Hey, it's easy
for you, you are a professional writer" I'll tell you that my high school
summer-school typing course increased my keypunching productivity by a
factor of 15 while I was still a hobbyist, and permitted me to make full
use of that KSR-33 and glass TTY and so forth as a professional...and that
I was a programmer for 12 years before I wrote my first article for
money. (I hope none of you EVER see that first article, which thank the
deity of your choice never saw publication.)
Look, I'm sorry if this comes across as harsh, but I can't believe you
people WANT to alienate users for the sake of an obscurity. Please
CONSIDER YOUR AUDIENCE -- ALL of them. Not just the top one-half of one
percent. The worst sin any writer -- professional or amateur, technical or
popular, fiction or non-fiction -- can do is lose the reader. And that,
people, is what you are doing with this debate.
Stephen Satchell
Stephen Satchell <[email protected]>:
> What kills me is that people forget the origin of KB as a standard
> designation for "kilobyte" in the first place. Does anyone remember the
> KSR-33 teletype, the early dot-matrix printers, and other output devices
> that output only upper-case characters? Maybe you youngsters don't recall
> that lower-case character devices were EXPENSIVE -- I still have a TI
> Silent 700 terminal that did output lower-case when connected to systems
> that understood the full ASCII alphabet, but those systems were few and far
> between in business applications -- upper-case-only was "good enough." How
> about tab machines that never did have lower-case, such as the 407 printing
> accounting machine?
That's right, kids. And furthermore, we had to walk to the computer
center uphill. Both ways. In the snow. Empty out the chad buckets
twice a day. And crimp backplane wires with our teeth, while the
machine was *on*!
> So here we are, campers, arguing about abbreviations when in fact there is
> no real NEED for abbreviations outside of the config symbol space. Why not
> just take the few extra bytes (they are not a penny each anymore) to spell
> out what you really mean?
Alas, this is not a solution -- because expanding all the abbrevs would
just get us into the argument over "kilobytes" vs. "kibibytes". And,
while I can just barely make myself choke down "KiB" for the sake of
clarity, "kibibytes" is beyond my tolerance. Aaarrggghhh....
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
All governments are more or less combinations against the
people. . .and as rulers have no more virtue than the ruled. . .
the power of government can only be kept within its constituted
bounds by the display of a power equal to itself, the collected
sentiment of the people.
-- Benjamin Franklin Bache, in a Phildelphia Aurora editorial 1794
Also sprach Oliver Xymoron
>Not true. Bandwidth is measured in metric.
If by this you mean that in networking, a megabit per second is equal to
1000^2, or a gigabit per second is 1000^3, then my response consists of:
Uhm, no.
If your response (I haven't followed this whole thread, so I'm not up on
all of the discussion here) is concerning the capitalization and such
used for it, then I really don't care which it is as the purpose is to
communicate, and strict adherence to capitalization just isn't that
important to communication. *shrug*
>Basically anything but RAM is measured in metric. RAM is the exception
>because of its intimate relation to bus width and that's an obvious
>anachronism. There's no reason anyone but a systems programmer should
>give a damn about powers of two.
This makes me think you're concerned about powers of 2 versus powers of
10. In which case, reference my response above.
--
Jeff McAdams Email: [email protected]
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
On Friday 21 December 2001 02:53 pm, Stephen Satchell wrote:
> At 07:17 PM 12/21/01 -0200, Rik van Riel wrote:
> >As a last point, we shouldn't forget about the inconsistent
> >way in which the marketing departments of hardware vendors
> >apply these units to their products. In many cases binary
> >and decimal units are mixed, leading to something which is
> >impossible to "get right". Disk space would be one example
> >of this, but I'm sure there are more.
> >
> >regards,
> >
> >Rik
>
> OK, how about this silly suggestion: DON'T USE ABBREVIATIONS IN
> DOCUMENTATION.
While pure reason suddenly made me realize that we really shouldn't use
abbreviations in docs, thus rendering MiB vs MB moot, this still leaves
us with another problem:
Gigs or Gibs? Kibbles or Kilos? You're still going to end up with
confusion, because outside of the (limited number of) people who heard
about this "international" standard, nobody knows what the heck a
kibibyte is.
On Fri, 21 Dec 2001, Benjamin LaHaise wrote:
> On Sat, Dec 22, 2001 at 10:00:17AM +1300, Chris Wedgwood wrote:
> > But what Rik points out shows that right now there is ambiguity
> > BECAUSE OF LACK OF STANDARDIZATION --- because GB is vague at the very
> > best, disk manufactures get to claim nice marketing numbers.
>
> GiB is not a useful standard because NOBODY USES IT. When it's in
> common use, then consider applying it to the kernel, but please,
> not before then.
To summarize: don't use it widely until it's widely used.
Let's apply that standard to aio, shall we? :P
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
> by the MB, everyone talks about MB == 1024*1024... I'm having a
> hard time giving a sympathetic ear to anyone try to change the well
> established, and consistent (barring the storage venduhs), standard.
If someone sells you 16MB of RAM and it turns out to be 16,000,000 bytes,
not only would it be appropriate use of units, it would be quite reasonable
as far as I can see to say it was in accordance with labelling of products.
The world did not begin in 1970, A-Za-z is not English collate order and
M is 1,000,000. When computing meets the rest of planet earth usages for
the odd hundred years its hard to see any reason to believe we are "right"
Eric using MiB seems the right thing. Its an ugly but appropriate unit, its
at least recommended as a solution by a standards body. We can either
redefine SI units ("You cannot change the laws of physics") or find a better
label. What better than a recommended one others use.
Alan
On Fri, Dec 21, 2001 at 06:07:20PM -0600, Oliver Xymoron wrote:
> To summarize: don't use it widely until it's widely used.
Actually, I just find it the most gratingly ugly thing I've ever seen,
and pointless as everyone already knows the meaning by context.
-ben
--
Fish.
On Friday 21 December 2001 14:24, Chris Ricker wrote:
> On Fri, 21 Dec 2001, Timothy Covell wrote:
> > On Friday 21 December 2001 13:12, David Weinehall wrote:
> > [snip]
> >
> > > Whatever the choice ends up being, KB is always incorrect, unless you
> > > intend to specify some strange formula where the number of bytes (B)
> > > combined with the temperature in Kelvin (K) has anything to do with
> > > things.
> > >
> > >
> > >
> > > /David Weinehall
> >
> > The way the metric prefixes work is that multiplicative prefixes are
> > capitalized and divisional prefixes are in lower case.
>
> Nonsense. Some of what you're calling multiplicative prefixes (as if they
> weren't *all* multiplicative ;-) are capitalized, and others are not. kilo
> (10^3) is k, hecto (10^2) is h, and deca (10^1) is da, for example. See
> <http://www.bipm.fr/enus/6_Publications/si/si-brochure.html> for the
> official guidelines (page 23 if you read English, and page 28 if you read
> French).
Dude, I don't know why you are being so pedantic on this.
You pointed to the stupid exceptions instead of the norm.
100% of the negative power prefixes ARE lower case, and all of the
positive power prefixes ARE UPPERCASE except those three stupid
exceptions which you cited. Here, SI is being stupid. Uppercase
is a GOOD IDEA (TM). And, NIST should fix this because the
point of standards is to create logical consistancy so that people
don't get into these stupid discussions.
Finally, I'm an American, so that means if someone tells me to do
something stupid, I tell them where they can shove it.
>
> More relevant to the whole Configure.help discussion, if you want to
> pedantic, official SI guidelines also state on the same page that:
>
> "These SI prefixes refer strictly to powers of 10. They should not be used
> to indicate powers of 2 (for example, one kilobit represents 1000 bits and
> not 1024 bits)."
And I already agreed to this, as have most of the others.
>
> later,
> chris
>
--
[email protected].
I favor switching to the use of KiB for 1024 bytes, etc.,
because I favor precision. Precise speech aids precise
thought.
One argument against was that 'KB' has been used ambiguously
in the past, so we should continue to use it ambiguously
in the future (for backward compatibility). However, I
don't think that our descendents brought up with "KiB"
will have trouble reading their grandparents' computer
manuals written with "KB". "KiB" was chosen because of its
similarity to "KB". They'll be able to say: "Hey, no wonder
computers used to crash back in the twentieth century. They
didn't know the difference between a kilobyte and a kibibyte!"
And they wouldn't be entirely wrong, either.
The other argument against the new terminology was that
when you speak the long forms, they sound funny. So
all you people think that "kilobyte" and "megabyte" don't
sound funny? A priori, "kibi" is no more ridiculous than
"kilo".
I think that the folks that thought of these prefixes were
rather clever, choosing names similar to the decimal prefixes,
yet easy to distinguish and still faily easy to pronounce.
The only thing wanting is a set of nouns for describing powers
of 2^10. I suggest:
one thousband = 1,024
one milbion = 1,048,576
one bilbion = 1,073,741,824
one trilbion = 1,099,511,627,776
etc.
Now what was the name of Fat Albert's friend who always said
"Haybee manbee, passbee mebee the ballbee!" ?
On Fri, 21 Dec 2001 20:12:59 +0100,
David Weinehall <[email protected]> wrote:
>Whatever the choice ends up being, KB is always incorrect, unless you
>intend to specify some strange formula where the number of bytes (B)
>combined with the temperature in Kelvin (K) has anything to do with
>things.
The KB unit has been reserved for the temperature of a linux-kernel
flamewar multiplied by the number of bytes of network traffic wasted on
that flame-war.
:)
On Thursday 20 December 2001 03:23 pm, Eric S. Raymond wrote:
> Reid Hekman <[email protected]>:
> > Perhaps if we could be so bold as to back Donald Knuth's KKB,MMB,GGB
> > proposal (of which I learned here:
> > http://www.linuxdoc.org/HOWTO/Large-Disk-HOWTO-3.html ).
>
> Hm. Attractive, but it doesn't have an ISO standard behind it.
Two words: "Posix threading."
Somebody had to say it.
How many successful real-world networks have been designed around the OSI 7
layer burrito networking model?
ISO standards do not define reality much on the internet. RFCs define
reality quite often on the internet. Most RFCs come well after the fact, and
an amazing number of RFCs are ignored or quickly replaced. Several of them
ADMIT to being jokes. Are you saying an ISO pronouncement has MORE weight
than an RFC?
ISO got into the computing world largely by rubber-stamping existing
standards from ANSI, CCITT, IEEE, and elsewhere. Not by making good
decisions. The ISO will happily standardize sugar cube sizes and pencil lead
density. They don't HAVE to know anything about the subject in question.
The best standards are the ones that either document practices that already
exist or define a draft interoperability procol hammered out by the parties
who are going to implement it (preferably with sample code which ends up
being worth more than the standards document).
Do you expect Microsoft to start using the term "mebibyte" any time soon? Or
hard drive manufacturers (who largely use decimal megabytes anyway for
marketing reasons)? Or ram manufacturers who obviously want end users to
learn a new term to buy their products? It would be a stupid marketing move.
(Sheesh, AMD's launching a major campaign to get away from "megahertz". And
failing at it, I might add.) How long did it take for end users to stop
referring to the "baud rate" of their modem, which hasn't been technically
true since the 300 baud days. (A "2400 baud" modem was actually 600 baud, 4
symbol if I remember correctly...)
In the short term, this change to the help files (which people look at when
they DON'T know stuff) is GUARANTEED to confuse WAY more people than it even
hopes to help over at least the next two years. Almost everybody who sees it
is going to have to ask "what's a mebibyte" and go look it up. Does this
really make the help file more helpful?
If the term goes into widespread use, THEN switch. If you want to make a
policy about it, we currently use binary measures when we measure memory or
storage in the linux kernel unless otherwise specified. Always have done.
Rob
On Friday 21 December 2001 01:40 pm, Eric S. Raymond wrote:
> David Garfield <[email protected]>:
> > Eric S. Raymond writes:
> > Choice of kB vs KB vs KiB vs KKB could also be used in some places in
> > the kernel. For instance, /proc/meminfo currently shows "kB".
>
> What, and *encourage* non-uniform terminology? No, I won't do that.
> Better to have a single standard set of abbreviations, no matter how
> ugly, than this.
find . -name "*.?" | xargs grep MiB | wc
46 lines, half of which seem to live in "jedec_probe.c".
find . -name "*.?" | xargs grep -w MB | wc
302 lines. And that's just upper case, whole word, not "MBs" or "Mb" or
any other fun little variation...
find . -name "*.?" | xargs grep -i MEGABYTE | wc
31 lines.
find . -name "*.?" | xargs grep -i MEBIBYTE | wc
1 line, and it's a comment saying it's NOT being used (along with one
of the MiB hits).
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
On Friday 21 December 2001 05:36 am, Mike Jagdis wrote:
> Eric S. Raymond wrote:
> > I guess it's a pretty quiet week in kernel-hacker land. Must be,
> > otherwise people would have better things to do than argue over KB
> > vs. KiB. The alternative would be to conclude that significant
> > portions of the lkml population prefer flaming to coding, and that
> > couldn't possibly be the case, could it?
>
> Surely not?
>
> > However. In the *absence* of a clear consensus, I will follow best
> > practices. Best practice in editing a technical or standards document
> > is to (a) avoid ambiguous usages, seek clarity and precision; and (b)
> > to use, follow and reference international standards.
>
> "Best" practice? That's the *only* practice! Guesswork and assumption
> has no place in technical documentation!
This may be why Andrea Arcangelli refuses to write any documentation at all,
Linus seems to have a prediliction for dropping documentation-only patches,
why the stuff in /linux/documentation has fallen up to two years out of date
at times, and why "Rusty's Unreliable Guides" (the best source of
documentation on the netfilter code, made available by the author himself at
"http://netfilter.samba.org/unreliable-guides/") says, and I quote:
-----
The Linux Documentation Project has the noble goal to `create the canonical
set of free Linux documentation'.
The Open Source Writer's Group wants `to put together a comprehensive "card
catalogue" of Open Source and Open Source-related documentation'.
On the other hand, my pet hamster dressed up in a penguin suit, and appeared
to me in a dream, telling me to write documentation for random stuff, and
include lots of obscenities.
The LDP guys no longer return my EMails (from me or my hamster).
-----
On the net, the way to get information isn't to ask questions, but to post
errors. Questions get ignored more often than errors go unflamed. Perfect
documentation, like perfect code, isn't something you wait until you have
before proceeding.
Rob
On Fri, Dec 21, 2001 at 07:23:13PM -0500, Rob Landley wrote:
>
> This may be why Andrea Arcangelli refuses to write any documentation at all,
> Linus seems to have a prediliction for dropping documentation-only patches,
> why the stuff in /linux/documentation has fallen up to two years out of date
> at times, and why "Rusty's Unreliable Guides" (the best source of
> documentation on the netfilter code, made available by the author himself at
> "http://netfilter.samba.org/unreliable-guides/") says, and I quote:
>
No doubt. The file drivers/block/loop.c has about 21 comments, although most of them are useless. The file is over 1700 lines long.
It would be a lot easier to grok this code if it didn't look like an entry for the IOCCC :) Comments would be nice.
--
Eric Windisch
http://bwbohh.net
> Linus seems to have a prediliction for dropping documentation-only patches,
Send them to the maintainers not to Linus generally helps. Or to Marcelo
because he seems to understand its important.
> The Open Source Writer's Group wants `to put together a comprehensive "card
> catalogue" of Open Source and Open Source-related documentation'.
[Thats out of date btw - OSWG is gone]
> errors. Questions get ignored more often than errors go unflamed. Perfect
> documentation, like perfect code, isn't something you wait until you have
> before proceeding.
Ah so aio would be perfect code - thats the problem 8)
Rob Landley <[email protected]>:
> 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?
If you had, you'd realized that I have not introduced "kibibyte",
or "mebibyte" or any of those terms anywhere. The Configure.help
changes involve only the IEC-standard abbreviations KiB, MiB, and GiB.
Try criticizing what I actually did, as opposed to what you merely *assume*
I did. You'll be more convincing that way.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
"The best we can hope for concerning the people at large is that they be
properly armed."
-- Alexander Hamilton, The Federalist Papers at 184-188
On Fri, 21 Dec 2001 15:33:52 -0600, Thomas Dodd wrote:
>
>Benjamin LaHaise wrote:
>
>> GiB is not a useful standard because NOBODY USES IT. When it's in
>> common use, then consider applying it to the kernel, but please,
>> not before then.
>
>
>What better place to start "common use" then the kernel source.
>Let's lead the way, not wait around to follow others.
>
And in fact, people are using it. Like I said earlier, I used to work
in StorageTek R&D, and we started using it. In fact the hardware people
started first, so the displays on our VSM arrays (Terabyte sized RAID
arrays) would use the kB = 1000byte whereas our reports would use
kB=1024byte. Big confusion.
AFAIR, the decision made to go with the IEC standard was primarily
because it was a standard.
regards,
Per Jessen, Zurich
regards,
Per Jessen, Zurich
http://www.enidan.com - home of the J1 serial console.
Windows 2001: "I'm sorry Dave ... I'm afraid I can't do that."
On Sat, Dec 22, 2001 at 12:32:54AM +0000, Alan Cox wrote:
> > by the MB, everyone talks about MB == 1024*1024... I'm having a
> > hard time giving a sympathetic ear to anyone try to change the well
> > established, and consistent (barring the storage venduhs), standard.
>
> If someone sells you 16MB of RAM and it turns out to be 16,000,000 bytes,
> not only would it be appropriate use of units, it would be quite reasonable
> as far as I can see to say it was in accordance with labelling of products.
>
> The world did not begin in 1970, A-Za-z is not English collate order and
> M is 1,000,000. When computing meets the rest of planet earth usages for
> the odd hundred years its hard to see any reason to believe we are "right"
>
> Eric using MiB seems the right thing. Its an ugly but appropriate unit, its
> at least recommended as a solution by a standards body. We can either
> redefine SI units ("You cannot change the laws of physics") or find a better
> label. What better than a recommended one others use.
The only problem is that M = 10^6 plus Mi = 2^20 don't cover the usages ...
4Mbit bandwidth is usually 4 * 10^3 * 2^10 bits per second.
20GB harddrive is usually 20 * 10^6 * 2^10 bytes.
The confusion is there. It can't be erradicated by adding Mi's and Gi's,
because they don't cover the whole spectrum.
Well, maybe we could have a 4 kKib/s connection and a 20 MKiB drive, but
that'd be even more confusing than what we have now.
--
Vojtech Pavlik
SuSE Labs
Vojtech Pavlich wrote:
>4Mbit bandwidth is usually 4 * 10^3 * 2^10 bits per second.
>20GB harddrive is usually 20 * 10^6 * 2^10 bytes.
A 20 GB hard drive is always 20 * 10^9 bytes. I'm not sure why so
many people on the linux-kernel list think otherwise, but the hard
drive industry is quite consistent in its use of power-of-10 units to
describe capacity. See:
http://www.seagate.com/support/kb/disc/bytes.html
("all major disc drive manufactures use decimal values when discussing
storage capacity")
Answer ID 336 in Maxtor's "Knowledge Base"
("Hard drives are marketed in terms of decimal (base 10) capacity.
In decimal notation, one megabyte (MB) is equal to 1,000,000 bytes,
and one Gigabyte (GB) is equal to 1,000,000,000 bytes.")
Answer ID 68 in Western Digital's "Knowledge Base"
("Drive manufacturers have always defined a megabyte as one million
bytes.")
http://www.storage.ibm.com/hdd/support/hddfaqs.htm#11
--
Tim Seufert
Benjamin LaHaise writes:
> If you think GB == 1000^3, then please go "correct" all the DRAM
> manufacturers out in the world. They just sent me 1GB of ram and
> it's coming up as 1073741824 bytes.
Oh, please - must we have this same discussion every year?
If someone uses an approximate value in some context then that
- is desirable if it is more convenient
- is admissable either (i) if greater precision is not of interest
(or unavailable), or (ii) when the approximate value suffices to
derive the exact value uniquely.
When things come in power-of-two sizes then no confusion is
possible if you use a decimal prefix: in reality the nearest
power of two is meant. Thus there is no urgent reason to be
precise when talking about the size of memory modules.
If you say 1GB, that is an American billion bytes, everybody
will assume that in fact the size was 1073741824 bytes.
Of course this will change when technology changes and memory
comes in arbitrarily sized units, like disks today.
These remarks taken together mean that it is not often necessary
to use these newfangled abbreviations like GiB or words like
gibibyte. Often precision is not required. Or precision is required
but the precise size is clear from the context.
But it is a serious mistake to doubt G = 1000^3.
k, M, G have one and only one meaning.
Just like "thousand" has only one meaning and still one can say
that this thing, that cost $1049, was bought for a thousand bucks.
Disks do not come in power-of-two sizes. So when talking about
disk sizes there is no "he says 1000000000 but it must be
a power of two so he must mean 1073741824". No, for disk sizes
it is just "he says 1000000000 so that is it".
In standard texts and other places where there must not be
any ambiguity one uses KiB, MiB, GiB. Also in a context where
binary and decimal units are both used it is clean to
separate them. When Linux boots, I see
hdf: 120064896 sectors (61473 MB) w/2048KiB Cache
and you see that the MB is decimal and the KiB binary. Good.
Concerning this Configure.help stuff, clearly it is not very
important what is written, but GiB is slightly better than GB,
and I doubt it would lead to any problems. People who have
never seen GiB will probably read it as gigabyte, and that is
approximately right.
Concerning the future of this standard for binary prefixes,
it looks like scientists and engineers like them and are
careful to distinguish G and Gi; in the open software world
programs are slowly adapted to correct usage; Microsoft has
not yet heard about the difference between GB and GiB.
Andries
Benjamin LaHaise writes:
> GiB is not a useful standard because NOBODY USES IT.
If everybody waits until all others use it, nothing will
ever happen. But in fact usage has been increasing over the
past two years. Also if one restricts attention to the Linux world.
But in fact the main purpose is to emphasize that 1000000 and
1048576 are different numbers and therefore need different
abbreviations. M always means 1000000. Mi always means 1048576.
There are not many contexts where an abbreviation for 1048576
is useful, so no great use is ever expected.
The goal is not to promote the abbreviation Gi.
The goal is to stop the people who believe that k means 1024.
Rik van Riel writes:
> the kB vs KiB mess is so ambiguous and complex
Mistake. k always means 1000. Ki always means 1024.
> In many cases binary and decimal units are mixed,
> leading to something which is impossible to "get right".
> Disk space would be one example of this.
No. All disk manufacturers only use decimal units.
Andries
[email protected] said:
> My personal esthetic distaste for the new terminology (gack! "kibi"
> sounds like something I would feed my cat!) is less important than
> following best practices. I'm hoping it will seem less ugly as it
> becomes more familiar.
It will. The resistance to the new terminology simply on the grounds that
it's new and not yet widely familiar _will_ pass.
The correctness and the lack of ambiguity will remain.
--
dwmw2
[email protected] said:
>
> If the machine has between 1 and 4 Gigabytes physical RAM, then
> answer "4GB" here.
> Note "3GiB/1GiB" and "4GB".
That's because the config option is named like that, and wasn't corrected
when the help text was. Maybe the following would be better:
If the machine has between 1 and 4 Gigabytes physical RAM, then
answer "4GB"(sic) here.
--
dwmw2
After reading this longish thread, or waste of bandwidth as you may look
at it, I wonder if people have realized how familiar this entire argument
is. Seams like we have another bunch of elitist snobs trying to tell the
common folk what is or isn't standard. Wasn't that long ago that teachers
were punishing students for using the word "ain't" because it wasn't
standard Engish despite it being used by virtually everyone else out in the
real world. Now last I heard a few years back, from an Engish teacher at
that, was that "ain't" was now fully allowed. Guess it became standard.
Perhaps some people should come off of their high horse and hang around with
the common people for a bit. For virtually everybody, including my grandma,
KB == kilobytes, MB == megabytes, and GB == Gigabytes. Memory-wise, at
least, kilos == 1024, Megas == 1024 * 1024. And as far as network speeds
I've always seen Kbits, Mbits, or Gbits (with lowercase or uppercase 'B').
For all practical purposes its always been like that. And while computers
haven't been around for ages yet its been around long enougth that the new
standards complient kernel source will be out of sync with the countless
amounts of documentation (of all kinds) out there as well as the standard
operating procedure in the real world.
Now aren't there better things to do in the world rather that going
around confusing and chastizing people with more talk of "Kibbles and Bits"
and "Men In Black". Not that pointless flamewars aren't always fun.
I already gotta put up with Python just to configure my kernel, now
this, and I read he's going after my symbols next.
Sorry if this seams a bit terse (I did tone it down a lot), however I
was hoping to get some help debugging my lockup problem on the VP6 instead
of corrections from language nannies informing me that the common folk and I
have been speaking and writing incorrectly all this time. Yes baby, there
is such a thing as a kiwibit.
On Saturday 22 December 2001 04:58 am, Eric S. Raymond wrote:
> Rob Landley <[email protected]>:
> > 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
Rob Landley <[email protected]>:
> Is the help file even currently accurate with this extra distinction made?
Not completely, but that's because in some cases I don't know whether decimal
or binary multiples are involved. Where that is the case I have left the
ambiguous terminology in place.
> 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?
I don't know yet. I can only clean up the bits for which I am maintainer.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
The spirit of resistance to government is so valuable on certain occasions,
that I wish it always to be kept alive. It will often be exercised when
wrong, but better so than not to be exercised at all. I like a little
rebellion now and then. -- Thomas Jefferson, letter to Abigail Adams, 1787
On Fri, Dec 21, 2001 at 07:17:45PM -0200, Rik van Riel <[email protected]> wrote:
| On Fri, 21 Dec 2001, Eric S. Raymond wrote:
| > What, and *encourage* non-uniform terminology? No, I won't do that.
| > Better to have a single standard set of abbreviations, no matter how
| > ugly, than this.
|
| Last I checked the purpose of language was _communication_.
| Better use words people understand.
Well, what we have is KB, which people _think_ they understand, but do not.
And KiB, which is ugly but well defined, albeit less known (at present).
| Also, the kB vs KiB mess is so ambiguous and complex that
| it virtually guarantees that the _writers_ of documentation
| will get it wrong occasionally and only confuse the readers
| more.
KiB is not ambiguous. KB demonstrably is.
And therefore KB is NOT useful for communication, _especially_ technical
communication.
| As a last point, we shouldn't forget about the inconsistent
| way in which the marketing departments of hardware vendors
| apply these units to their products. In many cases binary
| and decimal units are mixed, leading to something which is
| impossible to "get right". Disk space would be one example
| of this, but I'm sure there are more.
You're just making the case for KB weaker you know...
For all that KiB is ugly, at least it is not ambiguous.
I'll take "precise" over "vague" in technical documentation any time.
Using KB in places where precision matters puts us all into case #4 below,
because people think they know what KB means, but it means different
things to different people, and so people don't realise they are using
a vague term. Which is very bad.
--
Cameron Simpson, DoD#743 [email protected] http://www.zip.com.au/~cs/
Men are four:
He who knows and knows that he knows; he is wise, follow him.
He who knows and knows not that he knows; he is asleep, wake him.
He who knows not and knows that he knows not; he is ignorant, teach him.
He who knows not and knows not that he knows not; he is a fool, spurn him!
On Mon, 24 Dec 2001, Cameron Simpson wrote:
> Using KB in places where precision matters puts us all into case #4
> below, because people think they know what KB means, but it means
> different things to different people, and so people don't realise they
I take it this is your way of volunteering to always
keep all kernel documentation accurate as well as
answer questions from newbies who've never seen
'KiB' before ? ;)
Rik
--
Shortwave goes a long way: irc.starchat.net #swl
http://www.surriel.com/ http://distro.conectiva.com/
On Fri, Dec 21, 2001 at 04:10:30PM -0500, Benjamin LaHaise <[email protected]> wrote:
| On Sat, Dec 22, 2001 at 10:00:17AM +1300, Chris Wedgwood wrote:
| > But what Rik points out shows that right now there is ambiguity
| > BECAUSE OF LACK OF STANDARDIZATION --- because GB is vague at the very
| > best, disk manufactures get to claim nice marketing numbers.
|
| GiB is not a useful standard because NOBODY USES IT. When it's in
| common use, then consider applying it to the kernel, but please,
| not before then.
This is poor motivation.
s/GiB/linux/
We can all go to using Windows then... Thus is progress made.
--
Cameron Simpson, DoD#743 [email protected] http://www.zip.com.au/~cs/
Rik van Riel <[email protected]>:
> I take it this is your way of volunteering to always
> keep all kernel documentation accurate as well as
> answer questions from newbies who've never seen
> 'KiB' before ? ;)
One of the arguments for the KiB declaration, despite the ugliness of
"kibibytes", is that a newbie seeing "32KiB" is quite likely to deduce
what's meant from context. Let's not exaggerate the difficulties
here.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
Where rights secured by the Constitution are involved, there can be no
rule making or legislation which would abrogate them.
-- Miranda vs. Arizona, 384 US 436 p. 491
On Sun, Dec 23, 2001 at 08:53:41PM -0200, Rik van Riel <[email protected]> wrote:
| On Mon, 24 Dec 2001, Cameron Simpson wrote:
| > Using KB in places where precision matters puts us all into case #4
| > below, because people think they know what KB means, but it means
| > different things to different people, and so people don't realise they
|
| I take it this is your way of volunteering to always
| keep all kernel documentation accurate as well as
| answer questions from newbies who've never seen
| 'KiB' before ? ;)
Hmm. Not my plan at the time of typing, no.
But KB _is_ ambiguous. KiB is not (and it's ugliness is actually an advantage
here - it's less likely to be misused by people who've not seen the definition).
Just out of curiosity, is there anywhere in the kernel space where KB (et al)
is _not_ used to mean a power of 2 value?
--
Cameron Simpson, DoD#743 [email protected] http://www.zip.com.au/~cs/
When you're all dressed up and no place to go. - B.H. Burt (19th cent)
On Mon, 24 Dec 2001, Cameron Simpson wrote:
> | I take it this is your way of volunteering to always
> | keep all kernel documentation accurate as well as
> | answer questions from newbies who've never seen
> | 'KiB' before ? ;)
>
> Hmm. Not my plan at the time of typing, no.
> But KB _is_ ambiguous. KiB is not (and it's ugliness is actually an
> advantage here - it's less likely to be misused by people who've not
> seen the definition).
Now replace 'misused' by 'used'. I can guarantee you
that half the documentation will go on using KB while
the other half (if that) has KiB.
It doesn't help anything if there are more precise
terms when they're used inconsistently. Somebody will
have to check and fix this, continuously.
regards,
Rik
--
Shortwave goes a long way: irc.starchat.net #swl
http://www.surriel.com/ http://distro.conectiva.com/
Rik van Riel <[email protected]>:
> It doesn't help anything if there are more precise
> terms when they're used inconsistently. Somebody will
> have to check and fix this, continuously.
The situation is not as bad as you think, Rik. I grepped; the Documentation
subtree only has 17 instances of KB, of which about 6 clearly don't need
correcting as they really are referring to disk capacities. The patch to
fix these references would not be large.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
...Virtually never are murderers the ordinary, law-abiding people
against whom gun bans are aimed. Almost without exception, murderers
are extreme aberrants with lifelong histories of crime, substance
abuse, psychopathology, mental retardation and/or irrational violence
against those around them, as well as other hazardous behavior, e.g.,
automobile and gun accidents."
-- Don B. Kates, writing on statistical patterns in gun crime
[OT] man-pages-1.46 was released an hour ago or so.
Cameron Simpson asks:
> Just out of curiosity, is there anywhere in the kernel space
> where KB (et al) is _not_ used to mean a power of 2 value?
Disk sizes are given in decimal, so in the boot message
hda: 120064896 sectors (61473 MB) w/2048KiB Cache ...
the MB denotes (decimal) megabytes, while the KiB denotes
(binary) kibibytes.
Yes, the parenthetical parts are pleonastic both times.
Andries
On Mon, 24 Dec 2001, Cameron Simpson wrote:
> On Fri, Dec 21, 2001 at 07:17:45PM -0200, Rik van Riel <[email protected]> wrote:
> | On Fri, 21 Dec 2001, Eric S. Raymond wrote:
> | > What, and *encourage* non-uniform terminology? No, I won't do that.
> | > Better to have a single standard set of abbreviations, no matter how
> | > ugly, than this.
> |
> | Last I checked the purpose of language was _communication_.
> | Better use words people understand.
>
> Well, what we have is KB, which people _think_ they understand, but do not.
> And KiB, which is ugly but well defined, albeit less known (at present).
>
> | Also, the kB vs KiB mess is so ambiguous and complex that
> | it virtually guarantees that the _writers_ of documentation
> | will get it wrong occasionally and only confuse the readers
> | more.
>
> KiB is not ambiguous. KB demonstrably is.
> And therefore KB is NOT useful for communication, _especially_ technical
> communication.
Grep around in your RFC directory, and apply your argument. The KiB
definition will _create_ ambiguity in technical communication which
did not exist before.
-Mike
If someone is looking for an example of a kilobyte of RAM being defined as
1000 bytes, I can go dig out the carton for my Commodore 64. I am pretty sure
it was advertized on the box as having 65KB RAM. The could have even rounded
it to 66KB (65.536 KB).
Hi!
> > In many cases binary and decimal units are mixed,
> > leading to something which is impossible to "get right".
> > Disk space would be one example of this.
>
> No. All disk manufacturers only use decimal units.
Really? Even ATA flashcard manufacturers? So now I have to know if
CF-card has spinning parts to decide size?
Pavel
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
> > In many cases binary and decimal units are mixed,
> > leading to something which is impossible to "get right".
> > Disk space would be one example of this.
>
> No. All disk manufacturers only use decimal units.
Really? Even ATA flashcard manufacturers? So now I have to know if
CF-card has spinning parts to decide size?
What makes you think so?
Looking at a flash card here (sold as 8 MB), I see
SCSI device sdb: 15872 512-byte hdwr sectors (8 MB)
Now if the manufacturer claimed 8 MiB I could sue him,
but since he only claims 8 MB, this one is large enough
(it has 31 . 2^18 = 8126464 bytes).
It is 8.1 MB and 7.75 MiB.
Andries
Always remember:
(i) k=1000, M=1000k, G=1000M
(ii) specifications are rounded down, so that customers cannot complain
(iii) if something exists only in power-of-two sizes, that helps
guessing the actual size; however, this is not true for disks,
and as this example shows, it is not true for CF cards either.
Hi Eric, Rik.
>> I take it this is your way of volunteering to always keep all
>> kernel documentation accurate as well as answer questions from
>> newbies who've never seen 'KiB' before ? ;)
> One of the arguments for the KiB declaration, despite the ugliness
> of "kibibytes", is that a newbie seeing "32KiB" is quite likely to
> deduce what's meant from context. Let's not exaggerate the
> difficulties here.
Alternatively, deal with this problem the same way the "This may also be
built as a module..." comment is - either include it several thousand
times in Configure.help or (better still) have the configuration tools
spit it out automatically every time the need for it crops up. The
following ruleset could easily be implemented even in the `make config`
and `make menuconfig` parsers, and should be just as easy in CML2.
Applying rule (1) will result in a considerable reduction in the size of
the file Documentation/Configure.help as it currently stands.
Comments, anybody?
Best wishes from Riley.
===============8<=============== CUT ===============>8===============
RULE 1: If a particular symbol is defined using a command that
allows it to be selected as "Modular", then tack the
following to the end of the help description for that
symbol when a user requests help:
This driver is also available as a module( = code
which can be inserted in and removed from the
running kernel whenever you want). If you want to
compile it as a module, say M here and read
Documentation/modules.txt in the kernel source.
RULE 2: If the help text for a particular symbol includes a word
matching either of the egrep patterns '[KkMmGgTt][Bb]' or
'[KkMmGgTt]i[Bb]' then tack the following to the end of
the help description for that symbol when a user requests
help:
Differing standards are used for the numeric
designators in the computing and engineering
worlds. For the purposes of this document, the
following designators are used with the stated
values:
Symbol Designation Number of Bytes
~~~~~~ ~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~
KiB Decimal Kilobyte 1,000
KB Binary Kilobyte 1,024
MiB Decimal Megabyte 1,000,000
MB Binary Megabyte 1,048,576
GiB Decimal Gigabyte 1,000,000,000
GB Binary Gigabyte 1,073,741,824
TiB Decimal Terabyte 1,000,000,000,000
TB Binary Terabyte 1,099,511,627,776
This difference has arisen as a direct consequence of
the fact that computers naturally talk in a binary
(base 2) number system rather than the decimal (base
10) system preferred by mere mortals.
RULE 3: If more than one of the above rules apply, all configuration
systems shall agree on a common order in which to apply them.
On Wed, Dec 26, 2001 at 05:44:36PM +0000, Riley Williams <[email protected]> wrote:
| >> I take it this is your way of volunteering to always keep all
| >> kernel documentation accurate as well as answer questions from
| >> newbies who've never seen 'KiB' before ? ;)
|
| > One of the arguments for the KiB declaration, despite the ugliness
| > of "kibibytes", is that a newbie seeing "32KiB" is quite likely to
| > deduce what's meant from context. Let's not exaggerate the
| > difficulties here.
|
| Alternatively, deal with this problem the same way the "This may also be
| built as a module..." comment is - either include it several thousand
| times in Configure.help or (better still) have the configuration tools
| spit it out automatically every time the need for it crops up. The
| following ruleset could easily be implemented even in the `make config`
| and `make menuconfig` parsers, and should be just as easy in CML2.
| Applying rule (1) will result in a considerable reduction in the size of
| the file Documentation/Configure.help as it currently stands.
|
| Comments, anybody?
I like this!
--
Cameron Simpson, DoD#743 [email protected] http://www.zip.com.au/~cs/
It was a joke, OK? If we thought it would actually be used, we wouldn't have
written it! - Marc Andreessen on the creation of a <blink> tag
On Wednesday, 26 December 2001, Cameron Simpson wrote:
> On Wed, Dec 26, 2001 at 05:44:36PM +0000, Riley Williams <[email protected]> wrote:
> | >> I take it this is your way of volunteering to always keep all
> | >> kernel documentation accurate as well as answer questions from
> | >> newbies who've never seen 'KiB' before ? ;)
> |
> | > One of the arguments for the KiB declaration, despite the ugliness
> | > of "kibibytes", is that a newbie seeing "32KiB" is quite likely to
> | > deduce what's meant from context. Let's not exaggerate the
> | > difficulties here.
> |
> | Alternatively, deal with this problem the same way the "This may also be
> | built as a module..." comment is - either include it several thousand
> | times in Configure.help or (better still) have the configuration tools
> | spit it out automatically every time the need for it crops up. The
> | following ruleset could easily be implemented even in the `make config`
> | and `make menuconfig` parsers, and should be just as easy in CML2.
> | Applying rule (1) will result in a considerable reduction in the size of
> | the file Documentation/Configure.help as it currently stands.
> |
> | Comments, anybody?
>
> I like this!
I second this. Being a translator of the file in question, I have to deal
with ten slightly different versions of "You may also compile this as
a module...". So I have ten slighlty different translations of this text,
too, in the name of accuracy.
Although I thought there was an agreement that decimal kilobyte is kB,
and binary kilobyte is KiB, decimal megabyte is MB, binary megabyte is MB
and so on, wasn't there?
--
"The Universe doesn't give you any points for doing things that are easy."
-- Sheridan to Garibaldi in Babylon 5:"The Geometry of Shadows"
Dominik 'Rathann' Mierzejewski <rathann(at)we.are.one.pl>
Hi Dominik.
>>>>> I take it this is your way of volunteering to always keep all
>>>>> kernel documentation accurate as well as answer questions from
>>>>> newbies who've never seen 'KiB' before ? ;)
>>>> One of the arguments for the KiB declaration, despite the ugliness
>>>> of "kibibytes", is that a newbie seeing "32KiB" is quite likely to
>>>> deduce what's meant from context. Let's not exaggerate the
>>>> difficulties here.
>>> Alternatively, deal with this problem the same way the "This may
>>> also be built as a module..." comment is - either include it several
>>> thousand times in Configure.help or (better still) have the
>>> configuration tools spit it out automatically every time the need
>>> for it crops up. The following ruleset could easily be implemented
>>> even in the `make config` and `make menuconfig` parsers, and should
>>> be just as easy in CML2. Applying rule (1) will result in a
>>> considerable reduction in the size of the file
>>> Documentation/Configure.help as it currently stands.
>>>
>>> Comments, anybody?
>> I like this!
> I second this. Being a translator of the file in question, I have to
> deal with ten slightly different versions of "You may also compile
> this as a module...". So I have ten slighlty different translations
> of this text, too, in the name of accuracy.
I have to admit that I hadn't considered translators, but perhaps it
could be made even simpler for you. How about having the help file start
with a set of standard definitions, such as the following...
===8<=== CUT ===>8===
DEFINE_MODULAR
This driver is also available as a module ( = code which can be
inserted in and removed from the running kernel whenever you
want). If you want to compile it as a module, say M here and
read Documentation/modules.txt in the kernel source.
DEFINE_UNITS
Differing standards are used for the numeric designators in the
computing and engineering worlds. For the purposes of this document,
the following designators are used with the stated values:
Symbol Designation Number of Bytes
~~~~~~ ~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~
KiB Decimal Kilobyte 1,000
KB Binary Kilobyte 1,024
MiB Decimal Megabyte 1,000,000
MB Binary Megabyte 1,048,576
GiB Decimal Gigabyte 1,000,000,000
GB Binary Gigabyte 1,073,741,824
TiB Decimal Terabyte 1,000,000,000,000
TB Binary Terabyte 1,099,511,627,776
This difference has arisen as a direct consequence of the fact
that computers naturally talk in a binary (base 2) number system
rather than the decimal (base 10) system preferred by mere mortals.
===8<=== CUT ===>8===
The rules would then reduce to "If the relevant condition applies,
append the text associated with the relevant DEFINE_ symbol to the help
text to be issued" and this could be done with an additional call to the
routine to extract the appropriate help text from the file. In addition,
your translation efforts would be restricted to just the COnfigure.help
file, and you wouldn't have to tweak the various configuration scripts
at the same time - and this would also ensure that the various config
scripts all used exactly the same help text.
> Although I thought there was an agreement that decimal kilobyte is
> kB, and binary kilobyte is KiB, decimal megabyte is MB, binary
> megabyte is MiB and so on, wasn't there?
That's the standard that the IEC has defined, and what this thread is
all about. Whether it'll get anywhere remains to be seen - ask Ted T'so
about the dangers of early adoption of proposed standards, and he'll
probably explain where his surname came from...
Best wishes from Riley.
Riley Williams <[email protected]>:
> Alternatively, deal with this problem the same way the "This may also be
> built as a module..." comment is - either include it several thousand
> times in Configure.help or (better still) have the configuration tools
> spit it out automatically every time the need for it crops up. The
> following ruleset could easily be implemented even in the `make config`
> and `make menuconfig` parsers, and should be just as easy in CML2.
> Applying rule (1) will result in a considerable reduction in the size of
> the file Documentation/Configure.help as it currently stands.
I have said before; I am *not* going to make KB vs. KiB a
metaconfiguration option -- that would defeat the whole purpose of
having standard terminology. That decision is final, and this subject
is closed.
The other is not a bad idea in principle. I've thought before about
adding a feature that would add specified boilerplate to the help a
tristate symbol, for exactly the reasons you suggest. Three things make
it a bit messy in practice.
One is that it would have to be expressed in the rulebase, ruther than
wired into the code. I will not hardwire specific knowledge about
the Linux-specific properties of tristate symbols into the CML2 engine.
CML2 is already being used by at least two projects other than the kernel
and I know of a third that has it under consideration. Therefore I must
preserve its generality.
The second problem is that the module boilerplate is not all
boilerplate. Most instances contain the name of the generated module
object file. Thus, ypo do this right, I would have to declare module
names in the rulebase, one for each tristate entry. This implies a
significant extension to the CML2 language, which I'm reluctant to do
right now. The design is stable. I want it to stay that way until
(at least) well after CML2 achieves acceptance.
Third, I don't want to do major surgery on Configure.help until after
CML2 enters the tree. Were I to do so, I would then have to maintain
two different versions of Configure.help. That would be too big a pain.
Therefore, I'm going to defer consideration of this feature for now.
I certainly will not consider it until after CML2 goes into the 2.5 tree,
and may not consider it until there is some kind of final decision on
a 2.4 backport.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
When only cops have guns, it's called a "police state".
-- Claire Wolfe, "101 Things To Do Until The Revolution"
On Thursday, 27 December 2001, Eric S. Raymond wrote:
> Riley Williams <[email protected]>:
> > Alternatively, deal with this problem the same way the "This may also be
> > built as a module..." comment is - either include it several thousand
> > times in Configure.help or (better still) have the configuration tools
> > spit it out automatically every time the need for it crops up. The
> > following ruleset could easily be implemented even in the `make config`
> > and `make menuconfig` parsers, and should be just as easy in CML2.
> > Applying rule (1) will result in a considerable reduction in the size of
> > the file Documentation/Configure.help as it currently stands.
>
> I have said before; I am *not* going to make KB vs. KiB a
> metaconfiguration option -- that would defeat the whole purpose of
> having standard terminology. That decision is final, and this subject
> is closed.
With all due respect, Eric, I think you misunderstood. The way I understand
it, Riley is simply proposing to automatically _attach_ an explanation
of the KB/KiB confusion to help text of every option that uses these units.
> The other is not a bad idea in principle. I've thought before about
> adding a feature that would add specified boilerplate to the help a
> tristate symbol, for exactly the reasons you suggest. Three things make
> it a bit messy in practice.
>
> One is that it would have to be expressed in the rulebase, ruther than
> wired into the code. I will not hardwire specific knowledge about
> the Linux-specific properties of tristate symbols into the CML2 engine.
> CML2 is already being used by at least two projects other than the kernel
> and I know of a third that has it under consideration. Therefore I must
> preserve its generality.
Fair enough. I don't think anyone would want you to make it Linux-specific.
> The second problem is that the module boilerplate is not all
> boilerplate. Most instances contain the name of the generated module
> object file. Thus, ypo do this right, I would have to declare module
> names in the rulebase, one for each tristate entry. This implies a
> significant extension to the CML2 language, which I'm reluctant to do
> right now. The design is stable. I want it to stay that way until
> (at least) well after CML2 achieves acceptance.
>
> Third, I don't want to do major surgery on Configure.help until after
> CML2 enters the tree. Were I to do so, I would then have to maintain
> two different versions of Configure.help. That would be too big a pain.
>
> Therefore, I'm going to defer consideration of this feature for now.
> I certainly will not consider it until after CML2 goes into the 2.5 tree,
> and may not consider it until there is some kind of final decision on
> a 2.4 backport.
Again, these are all valid points. I guess you could just put this idea
far on the TODO list for now. :-)
Same thing applies to the first part of Riley's proposition, it would seem.
--
"The Universe doesn't give you any points for doing things that are easy."
-- Sheridan to Garibaldi in Babylon 5:"The Geometry of Shadows"
Dominik 'Rathann' Mierzejewski <rathann(at)we.are.one.pl>
On Thursday, 27 December 2001, Riley Williams wrote:
> Hi Dominik.
[snip]
> > I second this. Being a translator of the file in question, I have to
> > deal with ten slightly different versions of "You may also compile
> > this as a module...". So I have ten slighlty different translations
> > of this text, too, in the name of accuracy.
>
> I have to admit that I hadn't considered translators, but perhaps it
> could be made even simpler for you. How about having the help file start
> with a set of standard definitions, such as the following...
>
> ===8<=== CUT ===>8===
[cut indeed :-)]
> ===8<=== CUT ===>8===
>
> The rules would then reduce to "If the relevant condition applies,
> append the text associated with the relevant DEFINE_ symbol to the help
> text to be issued" and this could be done with an additional call to the
> routine to extract the appropriate help text from the file. In addition,
> your translation efforts would be restricted to just the COnfigure.help
> file, and you wouldn't have to tweak the various configuration scripts
> at the same time - and this would also ensure that the various config
> scripts all used exactly the same help text.
Nice, but - as Eric pointed out - there are many options where the
"available as module" text actually contains a module name, which
causes problems and makes your proposition insufficient for our needs.
A complete solution would require serious changes which Eric doesn't
want to introduce into a stable version.
> > Although I thought there was an agreement that decimal kilobyte is
> > kB, and binary kilobyte is KiB, decimal megabyte is MB, binary
> > megabyte is MiB and so on, wasn't there?
>
> That's the standard that the IEC has defined, and what this thread is
> all about. Whether it'll get anywhere remains to be seen - ask Ted T'so
> about the dangers of early adoption of proposed standards, and he'll
> probably explain where his surname came from...
Perhaps I will. But I still don't understand why you insist on choosing
an opposite notation - that is xiB for decimal and xB for binary.
If at all, I would change the traditional convention to something
exactly opposite, i.e. xiB for binary and xB for decimal, because
M(mega),G(giga), etc. are standard SI units.
PS. Don't Cc: me next time you reply, ok? I'm subscribed to lkml.
--
"The Universe doesn't give you any points for doing things that are easy."
-- Sheridan to Garibaldi in Babylon 5:"The Geometry of Shadows"
Dominik 'Rathann' Mierzejewski <rathann(at)we.are.one.pl>
On December 27, 2001 12:34 am, Dominik Mierzejewski wrote:
> Although I thought there was an agreement that decimal kilobyte is kB,
> and binary kilobyte is KiB, decimal megabyte is MB, binary megabyte is MB
> and so on, wasn't there?
Not in my book. As far as I'm concerned, somebody who tells me that one KB
of memory or disk is 1,000 bytes is a liar. When a disk manufacturer chooses
to interpret KB in such a way as to make their disk seem bigger, I just say
to myself "ok, they lied, that's what they do, they're in business and they
don't care". Now could we just ignore the self-serving doublespeak
promulgated by greedy manufacturers, and continue using KB please?
Kilo, as in memory -> 1024
Kilo, as in distance or weight -> 1,000
Difficult?
/me wonders when the kibblebytes thread is going to end
--
Daniel
On Thursday, 27 December 2001, Daniel Phillips wrote:
> On December 27, 2001 12:34 am, Dominik Mierzejewski wrote:
> > Although I thought there was an agreement that decimal kilobyte is kB,
> > and binary kilobyte is KiB, decimal megabyte is MB, binary megabyte is MB
> > and so on, wasn't there?
>
> Not in my book. As far as I'm concerned, somebody who tells me that one KB
> of memory or disk is 1,000 bytes is a liar. When a disk manufacturer chooses
> to interpret KB in such a way as to make their disk seem bigger, I just say
> to myself "ok, they lied, that's what they do, they're in business and they
> don't care". Now could we just ignore the self-serving doublespeak
> promulgated by greedy manufacturers, and continue using KB please?
>
> Kilo, as in memory -> 1024
> Kilo, as in distance or weight -> 1,000
>
> Difficult?
>
> /me wonders when the kibblebytes thread is going to end
/me wonders when people will learn to read more carefully
(no offense intended) :-)
If you look at my post more closely, you'll see I used `kB' (that's small
k and capital B) for decimal kilobyte. I would never suggest using `KB'
(that's capital K and capital B) for it. I do agree that `KB' is traditionally
used for binary kilobytes, but what about MB, GB and so on? These _are_
ambiguous. I am in favour of using Ki, Mi and Gi for binary quantities.
--
"The Universe doesn't give you any points for doing things that are easy."
-- Sheridan to Garibaldi in Babylon 5:"The Geometry of Shadows"
Dominik 'Rathann' Mierzejewski <rathann(at)we.are.one.pl>
[email protected] (Rik van Riel) wrote on 21.12.01 in <Pine.LNX.4.33L.0112211913360.28489-100000@duckman.distro.conectiva>:
> On Fri, 21 Dec 2001, Eric S. Raymond wrote:
>
> > What, and *encourage* non-uniform terminology? No, I won't do that.
> > Better to have a single standard set of abbreviations, no matter how
> > ugly, than this.
>
> Last I checked the purpose of language was _communication_.
>
> Better use words people understand.
People in general *don't* understand the current so-called "established
practice", because not only is it inconsistent with all of the rest of the
world, it's also inconsistent with itself.
A few specialists such as you or me understand those terms in those few
areas we are familiar with.
> Also, the kB vs KiB mess is so ambiguous and complex that
What is ambiguous or complex about it?
> As a last point, we shouldn't forget about the inconsistent
> way in which the marketing departments of hardware vendors
> apply these units to their products.
Do you know of *any* case where KiB and friends have been applied
inconsistently? You may not be arguing the side you seem to want to be
arguing here ...
> In many cases binary
> and decimal units are mixed, leading to something which is
> impossible to "get right". Disk space would be one example
> of this, but I'm sure there are more.
I have no idea why you think it is impossible to get right. It is fairly
easy to get right. Of course, that means using different numbers, but then
I've been saying for more than a decade that those numbers are a lie.
MfG Kai
[email protected] (Riley Williams) wrote on 26.12.01 in <[email protected]>:
> Symbol Designation Number of Bytes
> ~~~~~~ ~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~
> KiB Decimal Kilobyte 1,000
> KB Binary Kilobyte 1,024
>
> MiB Decimal Megabyte 1,000,000
> MB Binary Megabyte 1,048,576
>
> GiB Decimal Gigabyte 1,000,000,000
> GB Binary Gigabyte 1,073,741,824
>
> TiB Decimal Terabyte 1,000,000,000,000
> TB Binary Terabyte 1,099,511,627,776
Uh, that's all wrong. The "i" versions are *binary*, the non-"i" versions
are *decimal*. Completely backward.
MfG Kai
[email protected] (Chris Wedgwood) wrote on 22.12.01 in <[email protected]>:
> Standards exist to make peoples lives easier, the fact the hard drive
> and memory vendors currently don't use these phrases right now doesn't
> make the standard wrong --- this world is full of clue-less marketing
> people and nothing will change this.
Oh, it can be changed. Just the way car advertising has been changed to
use kW. (Well, it has over here.) And the way monitor size advertising is
in the process of being changed to use SI units, not US ones.
Fair advertising laws can be rather effective.
MfG Kai
[email protected] (Vojtech Pavlik) wrote on 20.12.01 in <[email protected]>:
> Now my opinion on this would be: By sticking KiB everywhere nothing is
> helped. To the knowledgeable, it's nothing new that memory is measured
> in binary units, while ethernet speed in decimal ones. To the newbie,
> KiB is about as cryptical as KB and he'll never know which is which,
> because as a newbie (s)he didn't read the standards.
Well, considering that I had to look at half a dozen web pages via Google
to make sure that ethernet did, indeed, use decimal, despite having been
in the industry for about a decade, I'd say that this *would* help.
And the newbie would at least recognize that there is something going on,
learning about which just might be a good idea. And the answer would
presumably come not out of a standard, but out of a FAQ.
> And speaking of the 1 Mbps connection - I fear that in many cases
> that'll be 1024000 bytes per second. What M is that? Binary or decimal?
A lied-about one. These abominations deserve to die, yesterday.
Preferrably messily.
> Who does care?
If you're selling it to me, I certainly do.
MfG Kai
[email protected] (Timothy A. Seufert) wrote on 22.12.01 in <p05101000b84a980dd9e1@[10.0.0.42]>:
> Vojtech Pavlich wrote:
>
> >4Mbit bandwidth is usually 4 * 10^3 * 2^10 bits per second.
> >20GB harddrive is usually 20 * 10^6 * 2^10 bytes.
>
> A 20 GB hard drive is always 20 * 10^9 bytes. I'm not sure why so
> many people on the linux-kernel list think otherwise, but the hard
> drive industry is quite consistent in its use of power-of-10 units to
> describe capacity. See:
>From dmesg:
"195371568 sectors (100030 MB)" (calls itself 100)
"8250001 512-byte hdwr sectors (4224 MB)" (calls itself 4330)
I take back whatever I said. It's not 1024^n. It's not 1024*1000^n. It's
not 1000^n. I don't know what it is, except it's all a lie.
MfG Kai
[email protected] (Vojtech Pavlik) wrote on 22.12.01 in <[email protected]>:
> The only problem is that M = 10^6 plus Mi = 2^20 don't cover the usages ...
>
> 4Mbit bandwidth is usually 4 * 10^3 * 2^10 bits per second.
> 20GB harddrive is usually 20 * 10^6 * 2^10 bytes.
There's a simple answer. "These people lie."
> The confusion is there. It can't be erradicated by adding Mi's and Gi's,
> because they don't cover the whole spectrum.
We don't *want* something that covers that part of the spectrum. We want
that part to be *avoided*.
MfG Kai
[email protected] (Jeff Mcadams) wrote on 21.12.01 in <[email protected]>:
> Also sprach Oliver Xymoron
> >Not true. Bandwidth is measured in metric.
>
> If by this you mean that in networking, a megabit per second is equal to
> 1000^2, or a gigabit per second is 1000^3, then my response consists of:
>
> Uhm, no.
Well, 64 kBit/s is certainly equal to 64000 bits per second. (That's
ISDN.)
And from a quick look through Google, Ethernet - in 10M, 100M, and G
variants at least - also uses decimal powers.
So I'd say that's "Uhm, yes".
MfG Kai
[email protected] (Benjamin LaHaise) wrote on 21.12.01 in <[email protected]>:
> On Sat, Dec 22, 2001 at 09:57:11AM +1300, Chris Wedgwood wrote:
> > I don't want to get dragged into this silly debate; the point I was
> > making is that we already have considerable inconsistency and choosing
> > STANDARDS BASED tokens might not be a bad thing.
>
> They're defacto standards that have been in use for well over a decade.
And it's been wrong for all of that decade, because the rest of the world
- *all* of it - has been using a different version for quite a bit longer
than that.
> Hmmm, all of the advertising, computer media and electrical engineering
> related material I've read recently seems to be using GB. In fact, there
> was one very article about the whole issue that found the computer
> industry to be remarkably consistent in using terms like "10GB" with no
> space between the number and the measuring unit. Oh wait, sorry, that's
> not formally approved by any standards bodies.
Unfortunately, while the typesetting may be consistent, the *meaning*
isn't. You cannot swap out 10GB RAM to a 10GB hard disk, it will overflow.
> Many standards bodies are examples of confusopolies.
Well, this particular "de facto standard" certainly is a confusopoly.
MfG Kai
[email protected] (Oliver Xymoron) wrote on 21.12.01 in <[email protected]>:
> On Fri, 21 Dec 2001, Benjamin LaHaise wrote:
>
> > On Sat, Dec 22, 2001 at 09:10:33AM +1300, Chris Wedgwood wrote:
> > > And disks by the GB where GB == 1000^3 so I don't see any problem in
> > > moving from KB to KiB and friends ESPECIALLY AS THEY ARE STANDARDIZED
> > > BEYOND THE KERNEL and nothing will change this.
> >
> > If you think GB == 1000^3, then please go "correct" all the DRAM
> > manufacturers out in the world. They just sent me 1GB of ram and
> > it's coming up as 1073741824 bytes. Please help! They have no
> > option for GiB!!!
>
> If you think GB == 1024^3, then please go "correct" all the disk
> manufacturers out in the world. They just sent me 1GB of disk and
> it's coming up as 1000000000 bytes. Please help! They have no
> option for GiB!!!
You've been defrauded. Typical disk GB come up as 1024,000,000 bytes.
Which is bloody awful.
MfG Kai
[email protected] (Reid Hekman) wrote on 20.12.01 in <[email protected]>:
> On Thu, 2001-12-20 at 15:07, Mark Hahn wrote:
> > > 1024 decimal kilobyte disk
> > > 8.4 decimal gigabyte disks
> > though as your example showed, there's very little, if any,
> > ambiguity: disk is always decimal, memory is always binary, etc.
Ah, but the problem with this is that it's *wrong*.
Disk is not always decimal. Nor is it always binary. Most disk sizes are
an unholy mixture of the two that deserves a stake through the heart,
where 1 GB = 1,024,000,000 bytes.
If even people here do not understand how this works, then can it possibly
be the right way of doing things?!
> More importantly, less educated users than yourself might not strike up
> the distinction between disk and memory units. The common example being,
> "why does my 9.1GB hard drive show up as 8.9GB?" Rather than explain
A current "9.1GB" hard disk would, if dc didn't lie to me, be either 9.3
GB (decimal) or 8.7 GiB (binary).
> For me, my reasons for full names are consistency and aesthetics --
> allowing us to sidestep the abortion that the IEC has created of SI
> units.
So you'll be saying "9.3 milliards of bytes" - or is it "billions" where
you live?
MfG Kai
[email protected] (Rob Landley) wrote on 23.12.01 in <20011223174227.NCJM25224.femail12.sdc1.sfba.home.com@there>:
> 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.
Would you want to live in a world where 1 litre milk was either more or
less than 1 litre water?
Why, then, do you think it was *ever* "good enough"?
I certainly never thought that 1 GB disk being a different number of
usable bits than 1 GB RAM was ever "good enough". *I* considered that to
be plain old fraud.
> 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...
"Established practice" is that these prefixes are decimal. It has been
established practice before the first electronic computer was even built.
> 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...
I see it as an unequivocal improvement, even though I don't like the
actual choice of prefix. But then, I never liked "Exa" or "Peta" either
...
MfG Kai
On Thu, Dec 27, 2001 at 12:45:00PM +0200, Kai Henningsen wrote:
> [email protected] (Vojtech Pavlik) wrote on 22.12.01 in <[email protected]>:
>
> > The only problem is that M = 10^6 plus Mi = 2^20 don't cover the usages ...
> >
> > 4Mbit bandwidth is usually 4 * 10^3 * 2^10 bits per second.
> > 20GB harddrive is usually 20 * 10^6 * 2^10 bytes.
>
> There's a simple answer. "These people lie."
Ok, then how *you* would call the abovementioned link that has 4096000
bits per second bandwidth? Yes, it's possible to say 4096 kbit, but then
you'll also have 32768 kbit links and 8388608 kbit links ...
> > The confusion is there. It can't be erradicated by adding Mi's and Gi's,
> > because they don't cover the whole spectrum.
>
> We don't *want* something that covers that part of the spectrum. We want
> that part to be *avoided*.
But how do you avoid something that *exists*? I mean - physically. The
devices that are described by these numbers are being produced and used.
--
Vojtech Pavlik
SuSE Labs
On Thu, Dec 27, 2001 at 01:57:00PM +0200, Kai Henningsen wrote:
> > And speaking of the 1 Mbps connection - I fear that in many cases
> > that'll be 1024000 bytes per second. What M is that? Binary or decimal?
>
> A lied-about one. These abominations deserve to die, yesterday.
> Preferrably messily.
You can't kill ISDN that easily. And not just ISDN, actually most phone
lines are based on 2048000 bit per second links ...
--
Vojtech Pavlik
SuSE Labs
On 27 Dec 2001, Kai Henningsen wrote:
> [email protected] (Timothy A. Seufert) wrote on 22.12.01 in <p05101000b84a980dd9e1@[10.0.0.42]>:
>
> > Vojtech Pavlich wrote:
> >
> > >4Mbit bandwidth is usually 4 * 10^3 * 2^10 bits per second.
> > >20GB harddrive is usually 20 * 10^6 * 2^10 bytes.
> >
> > A 20 GB hard drive is always 20 * 10^9 bytes. I'm not sure why so
> > many people on the linux-kernel list think otherwise, but the hard
> > drive industry is quite consistent in its use of power-of-10 units to
> > describe capacity. See:
>
> >From dmesg:
>
> "195371568 sectors (100030 MB)" (calls itself 100)
> "8250001 512-byte hdwr sectors (4224 MB)" (calls itself 4330)
>
> I take back whatever I said. It's not 1024^n. It's not 1024*1000^n. It's
> not 1000^n. I don't know what it is, except it's all a lie.
>
perhaps it is true.
in old days they were specified
for floppy disks and very old hd drives
so you had like floppy diskette 2MB diskette capacity unformated and
1.44 formated. (so we had 2m1 tools for dos and we can use /dev/fd0u1680)
the same was with hdd's there were disk with capacity 21MB unformated
but if they were with MFM controler they would have 19 with RLL 17MB
that was very old drives.
IN old days you had declared how much can hold unformated media
and how much in PC/CPM/MAC mode.
As I remember 5.25" history floppies in CP/M were unformatted about 450KB
on kaypro formated were 400KB / PC CP/M 86 360KB / and other 320KB
some cp/m like commodore c128D could read all those formats.
I think it is the same with HDD drives they full capcity may be
40GB where 40GB=40*1000M*1000K but real usefull is much less than declared
drive has it's own filesystem whathewer we use on top ot it,
you will realise that if you notice that there is no more low level format
option in bios, further more SMART in drives automatically change or
relocate bad sectors.
BUT I must admit I think it is stupid,
if 1KB is not 1024 bytes or 1Kb is not 1024 bites or 128 bytes.
regards,
Zoran
Hello!
> If you look at my post more closely, you'll see I used `kB' (that's small
> k and capital B) for decimal kilobyte. I would never suggest using `KB'
> (that's capital K and capital B) for it. I do agree that `KB' is traditionally
> used for binary kilobytes, but what about MB, GB and so on? These _are_
> ambiguous. I am in favour of using Ki, Mi and Gi for binary quantities.
Yes, the current MB/GB units are awfully ambiguous, but using Mi/Gi won't
cure the confusion as nobody will know whether MB/GB in that text means
the old-fashioned name of binary megabyte or the decimal megabyte according
to the new standard. Yes, the confusion might die out after a long period
of time of everybody switches to the new system, but I seriously doubt
it will happen in the near future.
It seems that the only way which is going to work is to create a new decimal
prefix for units of information as well. Not a particularly nice solution,
but probable the only working one.
Have a nice fortnight
--
Martin `MJ' Mares <[email protected]> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Every program in development at MIT expands until it can read mail.
On Mon, Dec 24, 2001 at 07:25:44AM +0100, Mike Galbraith wrote:
> > Well, what we have is KB, which people _think_ they understand, but do not.
> > And KiB, which is ugly but well defined, albeit less known (at present).
> >
> > | Also, the kB vs KiB mess is so ambiguous and complex that
> > | it virtually guarantees that the _writers_ of documentation
> > | will get it wrong occasionally and only confuse the readers
> > | more.
> >
> > KiB is not ambiguous. KB demonstrably is.
> > And therefore KB is NOT useful for communication, _especially_ technical
> > communication.
>
> Grep around in your RFC directory, and apply your argument. The KiB
> definition will _create_ ambiguity in technical communication which
> did not exist before.
Agreed. I think almost technical guys assumed that 'KB' (or kB, or kb, or
something ;-) IS 1024 bytes. Know even they starting to loose their
belief about old one, and that new and 'strange' 'KiB'. Imho '1000 bytes =
1 kbytes' was only used by some tricky hardware vendors to trick their
costumers (they could show bigger values ...). But even my sister knows
that when someone's speaking about computers, 'kilo' means 1024, not 1000.
It's like when we declared that direction of electrical current is from
positive to negative. Yes, we CAN change it now, because we know that it's
not the right direction of electrons in real.
So, if the 'technical world' already assumed (imho) that 'kilo' is 1024
in computer technology then we shouldn't change it now ...
- Gabor
> Most disk sizes are an unholy mixture of the two
> that deserves a stake through the heart,
> where 1 GB = 1,024,000,000 bytes.
"Are"??
I see several good people spout this particular type of nonsense
here. If I interpret "are" to mean that that is the unit
disk manufacturers use, then it is false - as far as I know
no manufacturer uses this.
Let us look at Maxtor. They are so friendly to give disk size
as part of the type.
Maxtor 91728D8 - 17280442368 bytes, 17280 MB, 17.2 GB
Maxtor 93652U8 - 36529274880 bytes, 36529 MB, 36.5 GB
Maxtor 96147H6 - 61473226752 bytes, 61473 MB, 61.4 GB
You see that the number of GB claimed by the manufacturer is
just (number of megabytes)/1000.
There is no 2.4% difference that could justify your strange claim.
All disk manufacturers always use decimal.
And this has been true for many years.
Andries
> You can't kill ISDN that easily. And not just ISDN, actually most phone
> lines are based on 2048000 bit per second links ...
Beg to differ. E1 is only 2048000 bits/second if you never send 5
consecutive 1 bits. The actual data rate on an E1 is in fact variable
On Thu, 27 Dec 2001 [email protected] wrote:
>> Most disk sizes are an unholy mixture of the two
>> that deserves a stake through the heart,
>> where 1 GB = 1,024,000,000 bytes.
> "Are"??
>
> I see several good people spout this particular type of nonsense
> here. If I interpret "are" to mean that that is the unit
> disk manufacturers use, then it is false - as far as I know
> no manufacturer uses this.
How about IBM. According to the datasheet at
http://www.storage.ibm.com/hdd/desk/ds120gxp.htm
Deskstar 120GXP with 120GB capacity has 24125472 sectors (123522416640
bytes).
That is 123.5GB if G=10^9 but 120.6GB if G=10^6*2^10 (and merely 115.0GB
if G=2^30).
Horrible? Yes.
(The same is true for 40GB and 80GB versions of 120GXP, and my (older model)
30GB and 40GB IBM drives.)
> Let us look at Maxtor. They are so friendly to give disk size
> as part of the type.
> Maxtor 91728D8 - 17280442368 bytes, 17280 MB, 17.2 GB
> Maxtor 93652U8 - 36529274880 bytes, 36529 MB, 36.5 GB
> Maxtor 96147H6 - 61473226752 bytes, 61473 MB, 61.4 GB
>
> You see that the number of GB claimed by the manufacturer is
> just (number of megabytes)/1000.
> There is no 2.4% difference that could justify your strange claim.
So Maxtor lies 7.37% while IBM lies only 4.86%?
BTW does anybody else remember when this insanity started? I seem to remember
that in the begining of the 90's some manufacturers re-defined (binary) MB as
1000kB and others had to follow (most likely because stupid buyers usually
bought the drive with 2.4% bigger figure without realizing it was the same
size as the other.)
> Andries
// /
Hi Dominik, Eric.
>>> Alternatively, deal with this problem the same way the "This may
>>> also be built as a module..." comment is - either include it several
>>> thousand times in Configure.help or (better still) have the
>>> configuration tools spit it out automatically every time the need
>>> for it crops up. The following ruleset could easily be implemented
>>> even in the `make config` and `make menuconfig` parsers, and should
>>> be just as easy in CML2. Applying rule (1) will result in a
>>> considerable reduction in the size of the file
>>> Documentation/Configure.help as it currently stands.
>> I have said before; I am *not* going to make KB vs. KiB a
>> metaconfiguration option -- that would defeat the whole purpose of
>> having standard terminology. That decision is final, and this
>> subject is closed.
No such suggestion has come from me.
> With all due respect, Eric, I think you misunderstood. The way I
> understand it, Riley is simply proposing to automatically _attach_
> an explanation of the KB/KiB confusion to help text of every option
> that uses these units.
That is exactly what I'm proposing Dominik - and the patches to do this
for `make config` are all ready for distribution, as are the basic
patches for Configure.help itself. I'm working on the patches for `make
menuconfig` at the moment, and will be doing those for `make xconfig`
once those are complete. Once that's done, CML2 will be the only config
tool not supporting it - and that's Eric's decision, not mine.
>> The other is not a bad idea in principle. I've thought before about
>> adding a feature that would add specified boilerplate to the help a
>> tristate symbol, for exactly the reasons you suggest. Three things
>> make it a bit messy in practice.
>>
>> One is that it would have to be expressed in the rulebase, ruther
>> than wired into the code. I will not hardwire specific knowledge
>> about the Linux-specific properties of tristate symbols into the
>> CML2 engine. CML2 is already being used by at least two projects
>> other than the kernel and I know of a third that has it under
>> consideration. Therefore I must preserve its generality.
> Fair enough. I don't think anyone would want you to make it
> Linux-specific.
I'm certainly not planning on doing so. The changes to `make config` are
on the basis that help requests from the "tristate" or "dep_tristate"
commands automatically adds whatever is attached to the help variable
DEFINE_MODULAR to the end of the help text for the option named. There's
absoultely nothing in that logic that has any more relevance to Linux
than to any other project using the same config toolsets.
>> The second problem is that the module boilerplate is not all
>> boilerplate. Most instances contain the name of the generated module
>> object file. Thus, to do this right, I would have to declare module
>> names in the rulebase, one for each tristate entry. This implies a
>> significant extension to the CML2 language, which I'm reluctant to
>> do right now. The design is stable. I want it to stay that way until
>> (at least) well after CML2 achieves acceptance.
This is already dealt with in the design I'm using. It requires that the
statement naming the module appears as the last line of the boilerplate
after the standard text, but that is already the case for several of the
uses of the "I can be a module" text, and the others can easily be
converted to use the same.
>> Third, I don't want to do major surgery on Configure.help until
>> after CML2 enters the tree. Were I to do so, I would then have to
>> maintain two different versions of Configure.help. That would be too
>> big a pain.
>> Therefore, I'm going to defer consideration of this feature for now.
>> I certainly will not consider it until after CML2 goes into the 2.5
>> tree, and may not consider it until there is some kind of final
>> decision on a 2.4 backport.
You may soon be in the position of having to maintain two different
versions of Configure.help if you don't implement this feature, rather
than if you do, as the code to implement it in the existing config tools
is well under way, and `make config` is ready for testing.
> Again, these are all valid points. I guess you could just put this
> idea far on the TODO list for now. :-) Same thing applies to the
> first part of Riley's proposition, it would seem.
Alternatively, you could have a look at what is actually required. Here
is a summary of the requirements that proved necessary for `make config`
to add boilerplate text to those options that can be selected as being
modular in the current tree:
1. The help function is split up into three...
extract_help help-var
This extracts the help text associated with the
help variable specified.
extract_all_help help-var...
This extracts the help text associated with all
of the help variables named, and appends it all
end to end in the order specified. It does so by
calling extract_help for each argument in turn.
help help-var...
This passes its arguments to extract_all_help and
then arranges for the resulting text to be shown
to the user.
2. The places in the tristate and dep_tristate functions where the help
function is called get an extra fixed parameter of DEFINE_MODULAR in
each case.
3. The relevant help text is added to the Configure.help file.
That's it - the sum total changes required. Essentially the same changes
are needed to get `make menuconfig` to do the same thing, but step (2)
is a little more tricky in this case. I haven't looked at `make xconfig`
yet, but that is unlikely to differ much from the above.
Once these changes are made, the additions to deal with adding other
boilerplate for technical acronyms appropriate to the project in
question are restricted to the Configure.help file itself and the
extract_all_help function included above, and nothing else will need
changing.
Incidentally, the changes to Configure.help in the current patches use
empty boilerplate text, so the addition of the relevant lines in
Configure.help to prevent it spewing out error messages results in a
Configure.help file compatible with both the old and revised system.
Best wishes from Riley.
On Saturday 22 December 2001 17:14, Vojtech Pavlik wrote:
>
> The only problem is that M = 10^6 plus Mi = 2^20 don't cover the usages ...
>
> 4Mbit bandwidth is usually 4 * 10^3 * 2^10 bits per second.
> 20GB harddrive is usually 20 * 10^6 * 2^10 bytes.
>
> The confusion is there. It can't be erradicated by adding Mi's and Gi's,
> because they don't cover the whole spectrum.
>
Please, please dont add more confusion.. Fortunatly people how sell harddisk
and bandwidth are both very consistent.
4Mbit bandwith IS always 4 x 10^9 bits per second
20GB harddrive IS always 20 x 10^20 bytes.
The confusion starts by saying a Mbit is only 1000 Kbit.. Well it is but the
Kbit here is 1000bit/s
And a GB is only 1000,000 kB, but these kB is only 1000 bytes.
Dont confuse the matter anymore, I am sure someone does, but they are wrong!
regards
Allan
On Thursday 27 December 2001 19:44, Allan Sandfeld wrote:
> Please, please dont add more confusion.. Fortunatly people how sell
> harddisk and bandwidth are both very consistent.
> 4Mbit bandwith IS always 4 x 10^9 bits per second
> 20GB harddrive IS always 20 x 10^20 bytes.
This is fantastic!
> The confusion starts by saying a Mbit is only 1000 Kbit..
Your confusion seems to start when you are many orders of magnitude out with
both your previous examples.
> Dont confuse the matter anymore, I am sure someone does, but they are
> wrong!
whoohooo
--
ABeet.
>> All disk manufacturers use decimal. Always.
> How about IBM.
Also IBM uses decimal.
Andries
Hi Dominik.
>>> I second this. Being a translator of the file in question, I have to
>>> deal with ten slightly different versions of "You may also compile
>>> this as a module...". So I have ten slighlty different translations
>>> of this text, too, in the name of accuracy.
>> I have to admit that I hadn't considered translators, but perhaps it
>> could be made even simpler for you. How about having the help file
>> start with a set of standard definitions, such as the following...
>>
>> ===8<=== CUT ===>8===
>[cut indeed :-)]
8-)
>> ===8<=== CUT ===>8===
>>
>> The rules would then reduce to "If the relevant condition applies,
>> append the text associated with the relevant DEFINE_ symbol to the help
>> text to be issued" and this could be done with an additional call to the
>> routine to extract the appropriate help text from the file. In addition,
>> your translation efforts would be restricted to just the COnfigure.help
>> file, and you wouldn't have to tweak the various configuration scripts
>> at the same time - and this would also ensure that the various config
>> scripts all used exactly the same help text.
> Nice, but - as Eric pointed out - there are many options where the
> "available as module" text actually contains a module name, which
> causes problems and makes your proposition insufficient for our needs.
> A complete solution would require serious changes which Eric doesn't
> want to introduce into a stable version.
Curiously enough, the changes I proposed are ones that I have already
implemented for `make config` and have nearly implemented for `make
menuconfig` at the moment, and I expect to have `make xconfig` ready
early in the new year. The module name part of it is trivially easy to
implement once the code to add the basic DEFINE_MODULAR text is there,
and the only change will be that the module name is always appended to
the end of the boilerplate rather than sometimes being in the middle and
sometimes at the end as it is now.
Because of this, I have no respect for this objection at all, and I have
to say that I would have expected a much better argument from Eric (for
or against this proposal) considering his progranmming skills.
>>> Although I thought there was an agreement that decimal kilobyte
>>> is kB, and binary kilobyte is KiB, decimal megabyte is MB, binary
>>> megabyte is MiB and so on, wasn't there?
>> That's the standard that the IEC has defined, and what this thread
>> is all about. Whether it'll get anywhere remains to be seen - ask
>> Ted T'so about the dangers of early adoption of proposed standards,
>> and he'll probably explain where his surname came from...
> Perhaps I will.
He explained that to me some time ago, and it's a similar story to this.
> But I still don't understand why you insist on choosing an opposite
> notation - that is xiB for decimal and xB for binary.
{Shrug} The exact text is an entry in Configure.help (under the symbol
DEFINE_UNITS as it happens) so in that sense, the fact that I made a
mistake as a result of misunderstanding the proposal is irrelevant.
> If at all, I would change the traditional convention to something
> exactly opposite, i.e. xiB for binary and xB for decimal, because
> M(mega),G(giga), etc. are standard SI units.
No problem - just edit the entries in Configure.help to say whatever
is consistent with the usage of the acronyms elsewhere in that file.
> PS. Don't Cc: me next time you reply, ok? I'm subscribed to lkml.
Blame the SysAdmin for that - if I choose (R)eply to a message, it
always addresses it to whoever posted it, and CC's anybody listed
elsewhere. I don't get the ability to change the "To" field, only the
"Cc" field, so you will always get a copy of any reply I send to an
email you've posted.
Best wishes from Riley.
Hi Kai.
> [email protected] (Riley Williams) wrote on 26.12.01...
>> Symbol Designation Number of Bytes
>> ~~~~~~ ~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~
>> KiB Decimal Kilobyte 1,000
>> KB Binary Kilobyte 1,024
>>
>> MiB Decimal Megabyte 1,000,000
>> MB Binary Megabyte 1,048,576
>>
>> GiB Decimal Gigabyte 1,000,000,000
>> GB Binary Gigabyte 1,073,741,824
>>
>> TiB Decimal Terabyte 1,000,000,000,000
>> TB Binary Terabyte 1,099,511,627,776
> Uh, that's all wrong. The "i" versions are *binary*, the non-"i"
> versions are *decimal*. Completely backward.
No problem. Just swap the relevant labels over in the first column.
As far as the tweak I proposed (and which I've finished creating for
`make config` and have nearly finished for `make menuconfig` as well),
the whole entry, along with that for any other "Technical Acronyms"
(TM) that one wishes to define in the same way, are simple entries at
the top of Configure.help and can easily be edited by anybody willing
to apply fingers to keycaps.
The only question I'm really interested in hearing answers to is this:
What other acronyms used in Configure.help could use
defining in this manner for kernel newbies?
Any takers willing to supply both the acronym and a definition thereof?
Best wishes from Riley.
On December 27, 2001 12:24 pm, Dominik Mierzejewski wrote:
> On Thursday, 27 December 2001, Daniel Phillips wrote:
> > Kilo, as in memory -> 1024
> > Kilo, as in distance or weight -> 1,000
> >
> > Difficult?
> >
> > /me wonders when the kibblebytes thread is going to end
>
> /me wonders when people will learn to read more carefully
> (no offense intended) :-)
>
> If you look at my post more closely, you'll see I used `kB' (that's small
> k and capital B) for decimal kilobyte. I would never suggest using `KB'
> (that's capital K and capital B) for it. I do agree that `KB' is
> traditionally used for binary kilobytes, but what about MB, GB and so on?
> These _are_ ambiguous. I am in favour of using Ki, Mi and Gi for binary
> quantities.
So would you be happy with kB -> 1,000 bytes, and KB -> 1024 bytes? Likewise
mB for 1,000,000 bytes and MB for 1048576 bytes?
Look, there's some precedent for it here:
http://www.unc.edu/~rowlett/units/dictK.html
"K - an informal abbreviation for one thousand used in expressions where
the unit is understood, such as "10K run" (10 kilometers) or "700K disk"
(700 kilobytes or kibibytes). Note that "K" is also the symbol for the
kelvin (see below). Also note that the symbol for the metric prefix kilo-
(1000) is actually k-, not K-."
If you believe that, then we don't have a problem, we never did:
kB -> 1,000 bytes
KB -> 1024 bytes
So, KiB is a silly fix for a problem that doesn't exist. Let's not have that
silliness creeping into our documentation, making it look silly too.
--
Daniel
On Fri, 28 Dec 2001, Daniel Phillips wrote:
> So would you be happy with kB -> 1,000 bytes, and KB -> 1024 bytes? Likewise
> mB for 1,000,000 bytes and MB for 1048576 bytes?
No way. m is the SI prefix for milli, one thousandth. (1/1000). K is the
SI unit Kelvin (absolute temperature). Add to the confusion...
--
Matthias Andree
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." Benjamin Franklin
[email protected] said:
> So you'll be saying "9.3 milliards of bytes" - or is it "billions"
> where you live?
Heh. Now we're getting even further off-topic. I think we've already just
about lost to the lobotomised masses on that one though - even the
historically clueful BBC have started using the US meaning of 'billion' in
spite of the fact that the word has always meant 10^12 throughout Europe,
not 10^9, and it would be trivial to just avoid the word altogether, to
avoid ambiguity.
Now I reckon it's just a matter of time before they start spelling colour
without the 'u' - 'because the general public don't know any better'. :)
--
dwmw2
'It says here I have the right to bear arms.
'Right. I want a nuclear warhead.
'Bring me one now.'
Alan Cox <[email protected]> remarked:
> Beg to differ. E1 is only 2048000 bits/second if you never send 5
> consecutive 1 bits. The actual data rate on an E1 is in fact variable
To the best of my recollection, the line bit (symbol) rate is fixed
at, ideally, 2048000 bps. At least with HDB3 line coding, a
sequence of 4 consecutive zeroes is replaced with three midscale
values one the line, and a mark that violates the normal mark
alternation scheme. I.e. 1,0,0,0,0 might be replaced with +,0,0,0,+
Thus, the "payload" data rate of 2048000 equals the line symbol
rate of 2048000 symbols/sec. (Of course, this isn't really the
"payload" data, since it includes the framing slots and all that,
but...)
Dan
Timo Jantunen <[email protected]> wrote:
>How about IBM. According to the datasheet at
>http://www.storage.ibm.com/hdd/desk/ds120gxp.htm
>
>Deskstar 120GXP with 120GB capacity has 24125472 sectors (123522416640
>bytes).
>
>That is 123.5GB if G=10^9 but 120.6GB if G=10^6*2^10 (and merely
>115.0GB if G=2^30).
>
>Horrible? Yes.
>
>(The same is true for 40GB and 80GB versions of 120GXP, and my (older
>model) 30GB and 40GB IBM drives.)
Please click on the "Models" link on the page you linked to and
reconsider your position. For abstract marketing purposes such as
model and family names, IBM currently prefers to round down to 5GB
increments, probably because 123.52GXP doesn't roll off the tongue
quite so well as 120GXP. That doesn't mean they use anything other
than 1GB = 10^9 bytes when they get around to telling you exactly how
much each model holds.
(It hasn't always been round-to-5GB. For example one older family
was the 22GXP. But that's easy to understand: when the maximum
shipping capacity was 22GB it presumably made more sense to round to
1GB figures.)
--
Tim Seufert
> Re: Configure.help editorial policy
>
>
> > Standards exist to make peoples lives easier, the fact the hard drive
> > and memory vendors currently don't use these phrases right now doesn't
> > make the standard wrong --- this world is full of clue-less marketing
> > people and nothing will change this.
>
> Oh, it can be changed. Just the way car advertising has been changed to
> use kW. (Well, it has over here.) And the way monitor size advertising is
> in the process of being changed to use SI units, not US ones.
>
> Fair advertising laws can be rather effective.
>
frankly speaking, the advertising on cars, monitors and other stuff
only changed, because it is illegal to do otherwise (you can use the old
units, but not alone and not prominently). IMHO in most peoples minds
the old units are still prevalent.
When looking at the new new notation for binary units, I just think the
standards organisations made a huge maistake :-( But standard is
standard. Better take it now.
Martin
--
+-----------------------------------------------------+
|Martin Knoblauch |
|-----------------------------------------------------|
|http://www.knobisoft.de/cats |
|-----------------------------------------------------|
|e-mail: [email protected] |
+-----------------------------------------------------+
Hi!
> Nice, but - as Eric pointed out - there are many options where the
> "available as module" text actually contains a module name, which
> causes problems and makes your proposition insufficient for our needs.
> A complete solution would require serious changes which Eric doesn't
> want to introduce into a stable version.
That "module" help text deserves to *die*. Explanation of modules
should be provided *once* in CONFIG_MODULES.
Pavel
--
(about SSSCA) "I don't say this lightly. However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa