Using standardized SI prefixes
kfries at cctus.com
Wed Jun 13 14:46:36 UTC 2007
On Wed, 2007-06-13 at 14:29 +0100, Scott James Remnant wrote:
> On Wed, 2007-06-13 at 12:51 +0200, Christof Krüger wrote:
> > On Tue, 2007-06-12 at 15:52 +0100, Ian Jackson wrote:
> > > shirish writes ("Using standardized SI prefixes"):
> > > > Please look at http://en.wikipedia.org/wiki/Binary_prefix .
> > >
> > > Urgh, these things are ugly and an abomination. We should avoid them.
> > I'd really like to hear some real arguments against SI prefixes, besides
> > being ugly or funny to pronounce or just because "it has always been
> > like that". Advantages of using SI prefixes has been mentioned in this
> > thread. Please tell me the disadvantages so there can actually be a
> > constructive discussion.
> User Confusion.
> Most users do not know what a "tebibyte" is, and they do not care. They
> know that "a terabyte" is "about a million million bytes", and that is
No it is not!!!
As larger and larger sizes are used, what was once an minor difference,
is starting to become significant. It almost reminds me of that old
scam of taking the rounded portions of a penny in financial calculations
and putting into an account. It adds up fast.
As we move from kilobytes to megabytes to etc the percentage of error
becomes greater and greater. It is no longer approximate, it is out and
I will be the first to admit that even though I am a computer scientist,
I did not understand the difference between Ki and K. I just always
thought of them as 1024. It actually annoys me to explain to the
uneducated the difference all the time due to what I always thought was
laziness of marketing people. I know realize it is a metric vs binary
Personally, when Joe Sixpack sees that a drive is 300 GiB or 300 GB he
will likely think it is the same. We all know that is not true.
Knowing it is not true, and purposely ignoring the the fact that the guy
buying the 300GiB drive is getting 7.4% more drive than the guy buying a
300GB drive is being complacent in the fraud.
As the size of drives grow, so does the error. Here is a chart:
kilobyte -> kibibyte -> +2.4%
megabyte -> mebibyte -> +4.9%
gigabyte -> gibibyte -> +7.4%
terabyte -> tebibyte -> +10%
petabyte -> pebibyte -> +12.6%
exabyte -> exbibyte -> +15.3%
zettabyte -> zebibyte -> +18.1%
yottabyte -> yobibyte -> +20.9%
With drives coming out in terabyte sizes soon, this is a 10% difference!
With raids approaching and in some cases exceeding exabyte sizes, this
is more than a 15% difference.
This goes way beyond "approximate". Imagine if you went to the gas
station to by a gallon (litre for our Europeans) of gas for your car,
but only received 85% of the gas you thought you paid for. Now how do
you feel about how close enough the differences are?
As unethical and immoral as it is to sell gas without accurately
reflecting the units/price, it is just as bad for us in the computer
industry to perpetrate this fraud by misreporting the size of memory,
If Joe Sixpack sees that 300GiB drive on the shelf next to a 300GB
drive, and both are marked accurately, and he assumes they are both the
same size, that is not our problem. He should become a more educated
consumer. If the salesman does not explain the difference (ever been to
Best Buy, lol) that is his fraud. But to purposely report that the
300GB and 300GiB drive are the same, because I am too lazy for field
questions is just immoral, and wrong. And to do so because I am too
lazy to field a few questions while people get used to the difference...
Unethical does not even begin to describe it.
The standard is in place. Use it. Be honest and reflect sizes
correctly. Kb is not the same as KiB. We all know that. If the public
gets confused, there is always Wikipedia. If you are too lazy to
explain it yourself, send them to:
I for one will begin using the SI units, now that I understand the
difference. "Approximate" is just an excuse to be lazy, and is
purposely giving wrong information to people. People look to me to
build data reporting tools... That information should always reflect
accurately unless I place a disclaimer on the data. Laziness should
never be an excuse.
Senior Linux Engineer
Computer and Communications Technologies, Inc.
a division of Japan Communications, Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part
More information about the Ubuntu-devel-discuss