Last Comment Bug 106618 - Change "KB" to "KiB" across the application
: Change "KB" to "KiB" across the application
Status: VERIFIED WONTFIX
:
Product: SeaMonkey
Classification: Client Software
Component: General (show other bugs)
: Trunk
: All All
: -- enhancement with 19 votes (vote)
: Future
Assigned To: Alexey Chernyak
: Nobody; OK to take it and work on it
:
Mentors:
http://members.optus.net/alexey/prefB...
: 276656 333234 414304 421792 537386 695704 902206 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2001-10-24 23:11 PDT by Alexey Chernyak
Modified: 2015-06-29 05:09 PDT (History)
38 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
patch to fix about:cache (1.84 KB, patch)
2003-11-19 17:57 PST, Alexey Chernyak
bzbarsky: review+
darin.moz: superreview+
asa: approval1.6b-
Details | Diff | Splinter Review
patch to fix some locale stuff (2.58 KB, patch)
2004-02-26 19:10 PST, Shaun Hill
no flags Details | Diff | Splinter Review
patch to fix some locale stuff (3.55 KB, patch)
2004-02-27 15:29 PST, Shaun Hill
no flags Details | Diff | Splinter Review

Description Alexey Chernyak 2001-10-24 23:11:21 PDT
We are using SI prefixes for decimal multipliers (as well as some non-standard
prefixes) to denote binary multipliers. This long-developed practise is an
unacceptable use of SI prefixes and is just plain wrong. This is even explicilty
mentioned in SI publication.

We should follow the standards and use binary prefixes.

The correct binary prefixes and their abbreviations are:
Kibibyte (KiB) = 1 024 bytes.
Mebibyte (MiB) = 1 048 576 bytes.
Gibibyte (GiB) = 1 073 741 824 bytes.
Tebibyte (TiB) = 1 099 511 627 776 bytes.

Binary prefixes and their symbols, developed by Technical Committee (TC) 25
(Quantities and Units, and Their Letter Symbols) of the International
Electrotechnical Commission (IEC) with the strong support of the International
Committee for Weights and Measures (CIPM) and the Institute of Electrical and
Electronics Engineers (IEEE), were adopted in January of 1999 as Amendment 2 to
International Standard "IEC 60027-2: Letter symbols to be used in electrical
technology - Part 2: Telecommunications and electronics". Subsequently the
contents of this Amendment were incorportated in the second edition of IEC
60027-2, which has a publication date of 2000-11 (the first edition was
published in 1972). The complete citation for this revised standard is "IEC
60027-2, Second edition, 2000-11, Letter symbols to be used in
electrical technology - Part 2: Telecommunications and electronics".

Relevant URLs:
IEC 60027-2 SE -
http://www.iec.ch/cgi-bin/procgi.pl/www/iecwww.p?wwwlang=E&wwwprog=pro-det.p&HeIEC&Pu60027&Pa2&Se&Am&Fr&TR&Ed2
TC 25 -
http://www.iec.ch/cgi-bin/procgi.pl/www/iecwww.p?wwwlang=E&wwwprog=TCboard.p&committee=SC&TC=25
IEC - http://www.iec.ch/
SI - http://www.bipm.org/enus/3_SI/si.html
CIPM - http://www.bipm.org/enus/2_Committees/cipm.html
IEEE - http://www.ieee.org/

Some more explanations behind binary prefixes -
http://physics.nist.gov/cuu/Units/binary.html
Comment 1 Alexey Chernyak 2001-10-24 23:17:47 PDT
Oops
The & did not get converted in the URLs above.
These URLs should work:

IEC 60027-2 SE -
http://www.iec.ch/cgi-bin/procgi.pl/www/iecwww.p?wwwlang=E&wwwprog=pro-det.p&HeIEC&Pu60027&Pa2&Se&Am&Fr&TR&Ed2

TC 25 -
http://www.iec.ch/cgi-bin/procgi.pl/www/iecwww.p?wwwlang=E&wwwprog=TCboard.p&committee=SC&TC=25
Comment 2 Grey Hodge (jX) 2001-10-24 23:23:55 PDT
Yeah, this is an IEEE "standard", but frankly, NO ONE does this, it'll be
confusing to users, it sounds stupid as hell, and I vote for a WONTFIX
personally. Sometimes a standard can be wrong.
Comment 3 Alexey Chernyak 2001-10-24 23:45:32 PDT
Noone does this because this standard is just 1 year old and people don't know
that it came out. This is exactly why we should support it and help bring it to
wider audience.

Creating a prefix for binary multipliers instead of continuing confusion with
other prefixes can't be wrong.
There currently are at LEAST 3 different meanings to word "megabyte" all
denoting different numbers.
People currently try to see meaning in all these different abbreviations: "kb",
"Kb", "kB", "KB", see bug 94961 for example.
Talk about being "confusing"!

Currently there is a total chaos with the use of these prefixes and their
abbreviations, and you call people who finally bring order to it once and for
all "stupid"?
Comment 4 Matthias Versen [:Matti] 2001-10-24 23:49:16 PDT
marking wontfix

see the discussion in bug 64179 and bug 65710
and I never saw KiB, everyone is using KB and there is no reason to change this.
Comment 5 Alexey Chernyak 2001-10-25 01:01:52 PDT
One of Mozilla goals is to be standard compliant.
This is a standard.Like it or not it is official and it is international.
In bug 64179 and bug 65710 I see people waving around SI notation and saying
things like "it should be this way because SI says so", absolutely failing to
note that SI itself explicitly says that it's prefixes *should not* be used in
this way.
A lot of people are unaware of existance of official binary prefixes, simply
because they were standardised so recently.

The goal of this bug is to bring people's attention to it and educate them about
this issue.
On a larger scale this change will bring far more (important) benefits than
disadvantages. And Mozilla can be a leader here.

Reopening
Comment 6 timeless 2001-10-25 05:58:59 PDT
If you want to fix this feel free to provide your own Localization ens-US or
something.  Users have no interest in this.

The kilogram is a standard but I use pounds. The meter is standard but I use
miles. Just because a unit is standardized doesn't mean real users will use it.

Please explain why this isn't a dupe of the second bug
Comment 7 Alexey Chernyak 2001-10-25 06:44:37 PDT
The word "kilobyte" means 1000 bytes.
If that's what is meant everywhere across the application - no problem.
Except that "KB" would have to be changed to "kB" to really be SI compliant.
However I do believe everywhere the size of 1024 bytes is meant.

kilograms and metres are used in most of the English speaking countries.
But that isn't even the issue here.

There is no problem with using "pound" because you just can't misuse it.
We are using "kilobyte" which means 1000 to denote 1024. There *IS* a problem there.
Comment 8 Grey Hodge (jX) 2001-10-25 07:08:35 PDT
No, in THIS industry, "kilobit" means 1024 bits. It always has. Now, LATELY
marketroids have changed them back to their metric roots so that they can
advertise larger capacities than items actually have, just as they USED to
advertise monitors  by tube size, not viewable inches (now both, thanks to
California) when up to an inch per side was hidden by the bezel.

The problem HERE is that the IEEE decided to change something in use for 50
years to conform to a DIFFERENT use. As Timeless said,if YOU want this fixed,
make a localization patch. There is already a standard in this Industry, in use
for much longer than the IEEE has been around.

As I said, sometimes standards are wrong.
Comment 9 Alexey Chernyak 2001-10-25 07:43:51 PDT
1. It is actually "marketoids" who have taken the term "kilobyte" from tech
slang and have brought it into the mainstream.
2. This "industry" hasn't existed for 50 years, and electronics of 50 years ago
haven't manipulated data of such sizes that would require any prefixes.
3. IEEE "has been around" since 1884. I'm sure word "byte" haven't even been
known for decades after that.
4. IEEE is basically what created this "Industry" and is what stands behind it.
5. Please stop displaying your incompetence.
6. If you talk of an already existing standard, please do point us to the
document that defines this standard and who defined it.
7. You singlehandedly label a standard that's been developed by some of the best
scientists from different countries over a number of years as wrong?
8. See 5.
Comment 10 timeless 2001-10-25 08:01:19 PDT
Ah but kilograms are masses and pounds are weights. We do misuse pounds.
Comment 11 Grey Hodge (jX) 2001-10-25 08:14:13 PDT
Ah yes, I was wrong about the IEEE. I misrea the date. But kilobit and kilobyte
HAS been used for 50 years. I have a vintage core memory board that's 4KB is
size dating to the 60's. Punchcards contained linear programs that were
thousands of bits long. The fact here is kilobit and byte, and theyr
larger/smaller counterparts have been inuse far longer than this standard, and
this standard does not redefine KB and the like, merely create a new KiB to mean
the same thing that we already use KB for, so make a localization package to
change KB and it's ilk to KiB if you like.
Comment 12 Matthew Paul Thomas 2001-10-25 09:18:30 PDT
Mozilla doesn't follow standards as an end in itself. Mozilla follows standards 
in order to ensure its long-term viability, by encouraging a Web in which 
multiple user agents can survive. For example, if Mozilla only supported the 
old Netscape DOM we could justifiably be criticized for not supporting the MSIE 
DOM. But if we support the W3C DOM then it's a lot easier to get away with not 
trying to keep up with MSIE, though this will break some pages for users.

The base-ten vs. binary prefix problem is not nearly so important -- confusion 
between the two has existed for the past twenty years or so, and the sky has 
not fallen. (Although I'm sure you could find some relevant anecdotes in the 
RISKS archive if you looked.) The overwhelming effect of using `KiB' and `MiB' 
in Mozilla would be to befuddle users, and nothing more.

Alexey, I promise you that when Mozilla-based browsers have at least 50 percent 
market share, *and* the binary prefix standard is still in effect, *and* you 
can find any published science or computing textbook which consistently uses 
the binary prefixes where appropriate, *then* I will try to get this bug fixed. 
But until then, we simply can't afford to be this confusing.
Comment 13 now michael@endbracket.net 2002-01-05 01:32:05 PST
timeless@mac.com wrote:
-----
"The kilogram is a standard but I use pounds. The meter is standard but I use
miles. Just because a unit is standardized doesn't mean real users will use it."
-----

And if you started abbreviating pounds "pnds", I would raise a bug stating that 
it should be "lb.".  It is not the unit that is in question, but the correct 
abbreviation.
Comment 14 Markus Gerstel 2002-01-05 02:23:53 PST
As you might know, 1 kb = 1024 b.
As you might not know, 1kbit/s = 1000 b/s

http://www.dante.net/ten-34/tf-ten/rumours/bits_p_kbit.html
http://www.alcpress.com/tutorials/units/units.htm
http://www.google.com/search?q=kbit+1000+bit&btnG=Google+Search

I don't like the transition to KiB either. I, too, find "Kibibit" ridiculous.
But in the last few months some projects adopted the new standards:

"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." - ESR, http://kerneltrap.com/article.php?sid=434

And you might consider a look at http://slashdot.org/article.pl?sid=01/12/23/1421225

I personally think that the community will soon (= not yet, esp. non-nerds) be
ready for the transition, and at this point we should not consider this bug
wontfix any longer.
Comment 15 Alexey Chernyak 2002-01-05 05:40:09 PST
Michael, actualy it's neither unit, nor abbreviation that is in question. It is
a case of using name (and abbreviation) of one unit while meaning another.

I call it "this" but what I really mean is "that".

And it appears that this does not bother the key UI developers of Mozilla. Which
I find surprising.
Comment 16 Hixie (not reading bugmail) 2002-02-17 15:22:52 PST
VERIFIED (for now, anyway).
Comment 17 Peter Lairo 2002-02-20 03:47:42 PST
I find the wontfix resolution of this bug highly disturbing. Using proper SI
notation is similar enough for anyone to quickly grasp what is meant (KiB vs kB)
(most users probably wouldn't even notice the extra "i", but those who did would
greatly benefit); and would clear up the confusion over actual data sizes in the
shortest of time. It's even mnemonically clear: "KiB" is longer (and therefore
larger) than "kB" (1024 vs 1000 bytes).
Comment 18 Alexey Chernyak 2003-11-19 09:08:41 PST
In (almost) 2 years since resolution of this bug the following happened:

IEEE (International Electrotechnical Commission) has accepted a standard for
binary multiples similar to the IEC (International Electrotechnical Commission) one.
ANSI (American National Standards Institute) has also accepted the IEEE standard.

The use of binary prefixes in applications has increased, especially on UNIX
platforms (Linux kernel for example).

Apple, Dell, Gateway, Hewlett-Packard, IBM, Sharp, Sony and Toshiba have been
sued this September in a class-action suit in US for "deceiving" the true
capacity of hard disk drives. This of course was due to misuse of "KB".

-----

Let's recoup the reasons for fixing this bug:

* Follow set international (and local) standards for the sake of correctness.
* Have datasizes displayed in an unambiguous way.
* Be on the forefront of technology and not lag behind.
* Avoid lawsuits (due to ambiguity)?

-----

To fix this, changes should be made to:

* Locales
* Documentation
* Hardcoded source (about:cache for example)

-----

Reopening bug.
Comment 19 Matthias Versen [:Matti] 2003-11-19 10:05:36 PST
-> Reporter
Comment 20 Alexey Chernyak 2003-11-19 17:57:56 PST
Created attachment 135963 [details] [diff] [review]
patch to fix about:cache
Comment 21 Darin Fisher 2003-11-21 00:03:43 PST
it's funny that a google search for "kilobyte KiB" (quotes excluded) resulted in:

Did you mean: kilobyte Kb

;-)
Comment 22 Darin Fisher 2003-11-21 00:31:52 PST
Comment on attachment 135963 [details] [diff] [review]
patch to fix about:cache

sr=darin

this is the right thing to do.
Comment 23 Boris Zbarsky [:bz] (still a bit busy) 2003-12-02 23:42:46 PST
Comment on attachment 135963 [details] [diff] [review]
patch to fix about:cache

r=bzbarsky if darin is happy with this, I guess.  Luckily, about:cache is not
something users ever look at...
Comment 24 (not reading, please use seth@sspitzer.org instead) 2003-12-03 00:09:56 PST
data point, I think we rejected KiB somewhere else once...like in the thread
pane / folder pane for the size of messages / folders.

I'll be the download manager / progress dialog doesn't do KiB either.

so this fix doesn't really fix it across the app.

see also:

http://bugzilla.mozilla.org/show_bug.cgi?id=124336
http://bugzilla.mozilla.org/show_bug.cgi?id=140898

Comment 25 (not reading, please use seth@sspitzer.org instead) 2003-12-03 00:11:52 PST
"we rejected KiB somewhere else once", I think it was this bug!

see ian@hixie.ch's comments in http://bugzilla.mozilla.org/show_bug.cgi?id=124336#c4
Comment 26 Alexey Chernyak 2003-12-03 01:48:37 PST
Yes, it was rejected 2 years ago, when the standard was still rather new and
hasn't received much recognition.
Things changed.

More international and national standards bodies have accepted it: IEC, IEEE,
ANSI, NIST. Even W3C accepts their use in it's recent releases:
http://www.w3.org/TR/mathml-units/#IEC-prefixes

Linux over past few years has embraced it more than any other OS. Across the
kernel and many applications.

Mac users had to face it in light of the recent lawsuit on Apple and others. In
fact, the majority of recent hits on the URL for this bug have been coming from
various Mac forums.

This change is needed to eliminate ambiguity that exists with data sizes today.

Yes the patch above is the first small step on fixing it across the application,
and fixes just the hardcoded values in about:cache and I plan to follow through
with patches for locale and documentation. These are hard to track as different
notations are used everywhere in the app.
(about:cache uses "k", UI uses "KB", and documentation uses "K")

Also documentation is undergoing rewrite in XHTML at the moment, and I might
wait till that is finished before making patches for it.

For more detailed info on the binary prefixes and their use please see the URL
in this bug.
Comment 27 Hixie (not reading bugmail) 2003-12-03 02:45:22 PST
comment 12 still applies. This isn't a matter of us wanting to avoid doing the
right thing, it's just that the majority of our target market (IE users on
Windows who don't know much about anything) would get confused by this, and we
cannot afford to confuse our users in our current precarious position.

This should remain WONTFIX until Mozilla and Mozilla derivatives have enough
market share that we can fix it without risking turning even more users away.
Comment 28 Darin Fisher 2003-12-03 03:12:29 PST
about:cache is for advanced users, and it makes sense for it to state sizes in
an unambiguous and technically accurate manner.  as for UI that is presented to
most users (like the download manager), i'm not sure how i feel :-/  ... i
totally get the argument for keeping to user expectations.

the other day when i looked at size values reported by dmesg under linux and saw
a mixture of MB and MiB, i was thoroughly confused.  i think when it comes to
low-level stuff, it is good to be unambiguous.  technically minded folks will
"get it" and they are the audience for things like about:cache.
Comment 29 Asa Dotzler [:asa] 2003-12-03 13:11:05 PST
Comment on attachment 135963 [details] [diff] [review]
patch to fix about:cache

This doesn't add any significant value to 1.6.
Comment 30 Hixie (not reading bugmail) 2003-12-04 04:22:22 PST
I wouldn't be against fixing this just for about:cache for now.
Comment 31 Joe Llywelyn Griffith Blakesley 2003-12-09 12:11:15 PST
As someone who has used Mozilla for a long time, I find it crazy that Mozilla is
still not, apparently, following the SI/IEC/IEEE/NIST/W3C/Iso/&c standard on
this throughout the app.  I agree that it is a minor thing in Mozilla (which, in
a way, makes it even more silly), so ambiguity will most likely not be
life-threatening or result in data loss (as misuse of these prefixes does often
-- I've experience) or anything (but it is certainly confusing).

I strongly agree with the sentiments of #28 which makes a very good point.

Also to counter a few other points that have been made:

(1) For those who say standards are silly, this is *not* a
_standardisation_issue_ (at least not in the normal sense).  The issue is
intentional, pointless and ambiguity-increasing _standards_abuse_.  If you do
not want to use standard prefixes do not misuse SI prefixes for your own purposes.

(2) For those who say they have never seen KiB
   (a) I'm guessing you use MS Windows then
   (b) If you don't like KiB then you can use the abbreviation KB (but only when
K stands for kilo -- not when it stands for kibi)



Comment 32 Hixie (not reading bugmail) 2003-12-09 13:28:08 PST
> (2) For those who say they have never seen KiB
>   (a) I'm guessing you use MS Windows then

Most users use Windows. The overwhelming majority of our target audience uses
Windows. If our goal is to prevent Microsoft from playing the biggest vendor
lock-in game in te history of the industry when they release Longhorn in 2006,
we have to get those users over to our products. We can't do that if we feel
unfamiliar, using terms that while technically correct would just be confusing
to them, not matching any other part of their OS.

I could see an argument for making this change on all platforms but Windows,
although I imagine in practice that would be a maintenance nightmare.
Comment 33 Stephen Donner [:stephend] 2003-12-25 23:13:25 PST
Attachment 135963 [details] [diff] checked in.  Leaving this bug open for other issues.
Comment 34 Bill Gianopoulos [:WG9s] 2003-12-26 08:38:02 PST
The fact that Kilo stands for 1000 and never 1024 is exactly what is wrong with
this standard.  KiBi is actually shorthand for the full name which is
KiloBinary, so they are still using Kilo to mean 1024, and somehow claim that
appending the word binary, which means having 2 states, to the end of it makes
this OK. The binary term might make sense when talking about bits, which do have
2 states, but none at all when talking about bytes which have 256 states.  So,
to clear up a problem of misusing one term, we are now misusing 2 terms and by
putting them together make things more clear?  I think not!

But this is something that ought to be discussed with the IEC I guess.  BTW as
near as I can tell this is NOT a standard recognized or even supported by most
of the groups listed in the previous comments as strongly supporting it.  Some
of these groups just say you can't use kilo for 1024 but do not appear to have
embraced this lame KiloBinary thing.
Comment 35 Alexey Chernyak 2003-12-26 10:40:34 PST
SI prefixes like kilo don't stand for actual numbers like 1000
they stands for the power to which base of 10^3 is raised (thus they are called
"decimal prefixes" to represent the original base, and not "thousand prefixes")

kilo - 1 (10^3)^1 = 1000
mega - 2 (10^3)^2 = 1000000

names of some prefixes are indicative of this:

peta (derived from Greek "penta") - 5
exa (derived from Greek "hexa") - 6
zetta (derived from Latin "septo") - 7
yocto (derived from Latin "octo") - 8

IEC prefixes work in the same way, except they represent to which power base
2^10 is being raised. Similarly their name is "binary prefixes", and not "byte
prefixes" or what not.

kibi - (2^10)^1
mebi - (2^10)^2

and so on

The exponents are the same as for SI prefixes - thus the use of same names for
their creation. But the base is different - thus the use of word "binary".

Note kibi and mebi are the actual standard prefixes, and words kilobinary and
megabinary are given only to show the origins of prefixes and are not standard
words themselve.

All of the above listed standards bodies have officially accepted this standard,
and for more info on that, relevant history and references, please read the URL
provided in this bug.
Comment 36 Ben Goodger (use ben at mozilla dot org for email) 2003-12-26 13:53:06 PST
Firebird does not want to do this for the front end that uses are LIKELY to see,
so any other patches in core components that propagate up to the FE must take
this into account. We have no argument with about:cache, for the reason bz cites. 
Comment 37 Bill Gianopoulos [:WG9s] 2003-12-26 16:38:39 PST
Well, about:cache gives the size of individual cached items in bytes.  This fix
only changes the data about total cache size amount used, etc.  Why not just put
this out in straight bytes too and avoid all confusion.

Change this:

Memory cache device

Number of entries: 	101
Maximum storage size: 	21504 k
Storage in use: 	1630 k
Inactive Storage: 	1175 k

List Cache Entries
Disk cache device

Number of entries: 	1840
Maximum storage size: 	50000 k
Storage in use: 	39582 k

To this:

Memory cache device

Number of entries: 	101
Maximum storage size: 	22020096 bytes
Storage in use: 	1669120 bytes
Inactive Storage: 	1203200 bytes

List Cache Entries
Disk cache device

Number of entries: 	1840
Maximum storage size: 	51200000 bytes
Storage in use: 	40531968 bytes
Comment 38 Peter Lairo 2003-12-27 01:56:52 PST
"put this out in straight bytes too and avoid all confusion." (e.g. 22020096 b)

Please NO! Long strings of contiguous numbers are *extremely* hard to read. At a
minimum, use thousands separators (e.g., 22,020,096 bytes). BTW: "kibi" is still
the better solution (e.g., 22,020 kibi), because it is the easiest to read.
Comment 39 Alexey Chernyak 2003-12-27 02:21:22 PST
Using commas to divide numbers in groups of three to facilitate reading is
against international standards and practises, since in most languages comma is
the symbol for the decimal marker. The correct way to divide numbers in groups
of three is by placing space between them.
Comment 40 Bill Gianopoulos [:WG9s] 2003-12-27 05:19:59 PST
re comment #39, the correct way to divide numbers into groups of 3 to facilitate
reading is to use the seperator character defined in the localization file which
should be either ',' '.' or ' ' depending.  I am kind of assuming here that the
mozilla localization files support this.  Every other application I know of that
has localization features does.  The reasons I just strung all the digits
together were:

1.  That is the way they are currently displayed.

2.  I thought it would avoid this discussion of what the proper seperator
character should be.
Comment 41 Bill Gianopoulos [:WG9s] 2003-12-27 05:32:18 PST
re comment #38.

Putting out 22 020 kibi is wrong for the same reason that putting out 22030 k
was wrong.  It is just a number but with no units. At least KiB tells you
un-ambiguously that it is in units of 1024 bytes.  BTW the 22 030 k was even
more incorrect because in the non-standard convention use in computing, k meant
1000, K meant 1024.  So the old 22202 k was wrong for 2 reasons always should
have read 22020 KB, so that we knew the multiplier was 1024 and that we were
talking about bytes.

 
Comment 42 Bill Gianopoulos [:WG9s] 2003-12-27 05:45:59 PST
Sorry for spamming the list with so many comments, but am trying to keep each
comment to one topic.

It is usually uinwise to try to speak for others, but I don't think it was the
intention of the IEC in creating these new prefixes trht the computer industry
abondon decimalization and just continue to plod on dividing by 1024 instead of
1000 and use these new prefixes as vindication for this bad practice.  I believe
the actual intent is that we begin to correctly utilize the kilo- mega- prefixes
by dividing things by 1000 instead of by 1024.  I think the new prefixes were
created for cases where doing so just plain does not make sense.  All of a
sudden changing what everyone knows as a 1 GB memory card to be called a
1.073741824 GB memory card is just plain dumb.  So the new prefixes to cover
things like this were required and this becomes a 1 Gib memory card.

However, I feel that continuing to divide by 1024 in places where we could just
as easily divide by 1000, and worse yet, taking places where we currenlty divide
by 1000 and changing to divide by 1024 to universally use these new prefixes is
most likely NOT what the IEC intended.
Comment 43 Christian :Biesinger (don't email me, ping me on IRC) 2003-12-27 08:14:56 PST
this bug is already useless anyway, so I'll add my comment...

dividing by 1024 is much easier than dividing by 1000 - div. by 1024 (2^10) is
just a bitshift. This is especially true in javascript, where you can't easily
do integer division, but can easily do bitshifts.
Comment 44 Jonas Sicking (:sicking) No longer reading bugmail consistently 2003-12-29 09:31:09 PST
I'm compleatly on the side of IEEE standards here, we should not devide by 1024
and use the KB (or kB) unit. However I also agree with comments saying that the
new Ki, Mi, Gi prefixes will be confusing to most users.

The solution is however quite simple, devide by 1000 instead. In fact, i would
think that this is what most users expect. If I ask my mom what kilo-byte is she
will most likly guess it's 1000 bytes. So when she downloads and sees a speed of
5KB/s she'll think that she's downloading in 5000 bytes per second.

comment 42 puts it rather nicly. he IEC probably didn't intend for engineers to
switch to using 1024 and use the new prefixes. But rather to switch to using
1000. If you want I could ask one of IEC members that worked on this, he's a
professor of mine :).

So to sum it up: To give the most userfriendly experience, especially for
non-savvy users, we should devide by 1000 across the mozilla applications.
Comment 45 Grey Hodge (jX) 2003-12-29 19:47:36 PST
I disagree totally. There are dozens of industries where specific words have
meanings different from common useage. Heck, even a nautical mile is different
from a statute mile. There are different pounds, gallons, ounces, etc.

I move we consider a kilobyte/bit, megabyte/bit, et al., discreet units BASED
upon their greek/latin roots, but with a specific meaning. Obviously this is
above the level of Bugzilla...

I still hold that in this industry, 9 out of 10 answers will be that a
kilobyte/kilobit is 1024. It's established. As for the prefixes themselves, I'll
grant you that kilo is immutable, it is 1000. Mega, giga, etc., however are
different. Mega means "great"; Giga means "giant"; Tera means monster. Yotta is
the second to last letter of the Latin alphabet. Zetta is the last. Peta and Exa
are created terms by the General Conference of Weights and Measures (Conference
Generale des Poids et Mesures).

I still argue the common use predates the standard, it's what is in use industry
wide, it is already well established, and to change Mozilla in this sense would
substantially alter user preceptions as we would suddenly differ from the near
unanimous current use, and cause confusion. This is bad.
Comment 46 Shaun Hill 2004-02-26 19:10:00 PST
Created attachment 142394 [details] [diff] [review]
patch to fix some locale stuff

This changes KB to KiB in metaData.properties and pageInfo.properties (I'm
pretty sure everything that uses these works in powers of 2).
Comment 47 Alexey Chernyak 2004-02-26 21:24:10 PST
Comment on attachment 142394 [details] [diff] [review]
patch to fix some locale stuff

you forgot the Cache options.
Comment 48 Bernard Alleysson 2004-02-27 02:16:44 PST
I think that "KB", "MB" should be changed to "KiB", "MiB" on the mozilla web
site, not only across the application, see for instance
http://www.mozilla.org/releases/, it would be more correct
Comment 49 Shaun Hill 2004-02-27 15:29:50 PST
Created attachment 142480 [details] [diff] [review]
patch to fix some locale stuff

(In reply to comment #47)
> (From update of attachment 142394 [details] [diff] [review])
> you forgot the Cache options.
> 

Is this what you mean?
Comment 50 Stefan Huszics 2004-03-02 02:37:58 PST
> I disagree totally. There are dozens of industries where specific words have
> meanings different from common useage. Heck, even a nautical mile is different
> from a statute mile. There are different pounds, gallons, ounces, etc.

Um, the very exsistance of the SI organization has only 1 single purpose, to
remove such different meanings and establising a standard with the resoult of
lowering confusion.

Also I don't understand much of the arguments about KiB being confusing.
I'm pretty sure that anybody who knows what 
45 KB means can easily figure out what
45 KiB means.

Non technical people that don't know what KB is probably won't even notice that
it's written KiB instead.

On webpages, for those that belive KiB to be confusing, one can always write eg
45KiB (KB) which will be both correct as well as educate people.

In any case, starting to change the values in "hidden" areas as well as
documentation is a good first step even if people prefer to keep the main
UI-parts as KB for a few more years.
Comment 51 Bill Gianopoulos [:WG9s] 2004-03-02 04:09:34 PST
> On webpages, for those that belive KiB to be confusing, one can always write eg
> 45KiB (KB) which will be both correct as well as educate people.

This is entirely INCORRECT.  The sole purpose of creating the KiB abbreviation
was so that KB could un-ambiguously mean 1000 Bytes.  So, putting KiB with KB
following it is incorrect by any standard.
Comment 52 Hixie (not reading bugmail) 2004-03-07 02:25:08 PST
Why don't we just divide by 1000 instead of 1024 when we use the suffix KB? That
way we satisfy everyone on this bug: we'd be technically accurate, and we
wouldn't be confusing to new users.
Comment 53 Alexey Chernyak 2004-03-07 06:01:27 PST
(In reply to comment #52)
> Why don't we just divide by 1000 instead of 1024 when we use the suffix KB? That
> way we satisfy everyone on this bug: we'd be technically accurate, and we
> wouldn't be confusing to new users.

That won't be technically accurate, and would still be ambiguous. In this case
technically accurate would be kB, not KB.

I don't understand this fear of KiB. This is nothing compared to the confusion
correctness of Mozilla's layout engine causes. And unlike Mozilla laying sites
out horribly when something is wrong, and users not understanding what the hell
is going on, in this case user can always look up what "KiB" means, and would
most likely be grateful to learn something new.
Comment 54 Hixie (not reading bugmail) 2004-03-07 06:08:30 PST
Ok, kB then. Whatever.

Users are rarely grateful to learn something new, actually. They just want their
computer to Work and be friendly. KiB is not something they are used to, and it
is thus not friendly.
Comment 55 Christian :Biesinger (don't email me, ping me on IRC) 2004-03-07 06:58:37 PST
(In reply to comment #53)
> is going on, in this case user can always look up what "KiB" means, and would
> most likely be grateful to learn something new.

You mean they wouldn't think that KiB is a totally stupid invention to solve a
nonexisting problem?
Comment 56 Alexey Chernyak 2004-03-07 07:06:29 PST
(In reply to comment #54)
> KiB is not something they are used to, and it is thus not friendly.

In that case, Mozilla in itself is totally not friendly since 95% of web users
are not used to it, and we should stop all efforts and instead release rebranded
version of IE to keep them happy.

> You mean they wouldn't think that KiB is a totally stupid invention to solve a
> nonexisting problem?

I think they won't care and won't pay attention to it, as it does not affect the
browser functionality. Or do you think your nana will care? :o)
Comment 57 Hixie (not reading bugmail) 2004-03-07 07:10:46 PST
> In that case, Mozilla in itself is totally not friendly since 95% of web users
> are not used to it, and we should stop all efforts and instead release 
> rebranded version of IE to keep them happy.

This is, of course, one of the main reasons Firefox tries to fit in so well with
the OS on Windows -- with the result that Firefox is quite similar to IE in many
respects. Anyway, this is off-topic.
Comment 58 Alexey Chernyak 2004-03-07 07:33:24 PST
The way I see it, this doesn't affect the functionality of the browser or "user
experience".

Those anal users that will notice it, will be grateful to learn something new.
Those users that are rarely grateful to learn something new, won't care to
notice something like this in the first place, since it doesn't affect them one
way or the other.

This is a pretty minor change compared to issues like File->Exit functionality,
or CSS with wrong MIME type not being applied to pages. They do affect browser
functionality and user experience. This doen't.

I think the fear of it is unreasonable, and is blocking progression, recognition
and adaptation of international technical standards set 7 years ago by IEC,
IEEE, ANSI, and recognised and endorsed by BIPM, NIST and ISO.

And you, Ian, should be the last person I should be explaining this to.

This is a matter of evangelizing Mozilla, and very mildly at that.
Comment 59 Anne (:annevk) 2004-03-07 07:37:34 PST
(In reply to comment #52)
> Why don't we just divide by 1000 instead of 1024 when we use the suffix KB?

Alexey, what is wrong with this proposal (except the kapital K)?
Comment 60 Alexey Chernyak 2004-03-07 07:47:24 PST
(In reply to comment #59)
> Alexey, what is wrong with this proposal (except the kapital K)?

That it would indeed change the functionality.
And that ambiguity would still not fully disappear due to current abuse of SI
prefixes.
Comment 61 Grey Hodge (jX) 2004-03-07 14:48:59 PST
> You mean they wouldn't think that KiB is a totally stupid invention to solve a
> nonexisting problem?

Not only is it a non-solution to a non-problem, it goes against 50 years of
industry convention.
Comment 62 Jonas Sicking (:sicking) No longer reading bugmail consistently 2004-03-08 09:23:34 PST
> > Alexey, what is wrong with this proposal (except the kapital K)?
> 
> That it would indeed change the functionality.

What's wrong with changing functionality?

> And that ambiguity would still not fully disappear due to current abuse of SI
> prefixes.

We should fix that, not work around it.

Personally I think this bug should be WONTFIXed and a new bug should be filed:
"Divide by 1000 and 1000000 when prefixes kB and MB is used"
Comment 63 Christian :Biesinger (don't email me, ping me on IRC) 2004-03-08 12:22:59 PST
(In reply to comment #62)
> Personally I think this bug should be WONTFIXed and a new bug should be filed:
> "Divide by 1000 and 1000000 when prefixes kB and MB is used"

That's fortunately worksforme as we only use KB not kB.
(well, if you ignore MB, but I doubt we use that much...)
Comment 64 Jonas Sicking (:sicking) No longer reading bugmail consistently 2004-03-08 13:12:23 PST
Well, KB is IMHO equivalent to kB (though kB is more correct and thus should be
used). So the new bug should be:

"Divide by 1000 and 1000000 when prefixes kB and MB is used, for all cases or kb
and mb. We should also change to use the kB and MB cases everywhere".

My point is this:
* We shouldn't use kB (or KB) when we devide with 1024. It's technicall and
  mathematically wrong. Same thing with MB (including Mb, mb, and mB).
* We shouldn't use the KiB or MiB since most people won't know what they mean,
  and they're not going to go through the effort of finding out.

It doesn't matter what reason they were invented for, we are still free to
choose whichever devisor we chooses, as long as we use the correct prefix when
using them. And our clients won't understand the new prefixes, thus we shouldn't
use them, thus we shouldn't use the binary devisors.
Comment 65 Ali Ebrahim 2004-03-08 13:28:45 PST
(In reply to comment #64)
> It doesn't matter what reason they were invented for, we are still free to
> choose whichever devisor we chooses, as long as we use the correct prefix when
> using them. And our clients won't understand the new prefixes, thus we shouldn't
> use them, thus we shouldn't use the binary devisors.

While we are free to choose whatever we want, I think it makes sent to stay with
the binary-based 1024 system. This is still what operating systems use to report
filesize (in KB/MB), and I don't use why we should be doing anything different.

As to what we call it, I don't really think that KB/MB or KiB/MiB really matter
a great deal. If someone knows what KB means, and sees an incrementing number
with KiB next to it (instead of KB), I don't think there is going to be a whole
lot of confusion.
Comment 66 Jonas Sicking (:sicking) No longer reading bugmail consistently 2004-03-08 13:55:28 PST
> While we are free to choose whatever we want, I think it makes sent to stay 
> with the binary-based 1024 system. This is still what operating systems use to 
> report filesize (in KB/MB), and I don't use why we should be doing anything 
> different.

So just because the OS does the wrong thing so should we? (This reminds me of
something my dad said about jumping and the brookly bridge.)

> As to what we call it, I don't really think that KB/MB or KiB/MiB really 
> matter a great deal. If someone knows what KB means, and sees an incrementing 
> number with KiB next to it (instead of KB), I don't think there is going to be 
> a whole lot of confusion.

Most people will probably think it's a typo, which makes us look sloppy ("how
could they miss an obvious typo like that").
Comment 67 Christian :Biesinger (don't email me, ping me on IRC) 2004-03-08 13:58:24 PST
(In reply to comment #66)
> So just because the OS does the wrong thing so should we? (This reminds me of
> something my dad said about jumping and the brookly bridge.)

(I hate that argument)

But your suggestion does make the filesize shown in the download progress dialog
and the filesize that file managers shows for the same file not match.
Comment 68 Ali Ebrahim 2004-03-08 14:10:43 PST
(In reply to comment #66)
> So just because the OS does the wrong thing so should we? (This reminds me of
> something my dad said about jumping and the brookly bridge.)

Note that I said we should match the OS behaviour in terms of using the
binary-based power of two system. I never said that we should call it the wrong
thing, just that I'm open to any of the following: kb/KB/KiB. Having said this,
the mean reason I said we should match the behaviour is that this is what users
expect in terms of numbers matching. As biesi pointed out, the numbers will not
match if we switch to the 1000-based system.

If I'm downloading an ISO (I've purposely chosen a large type of file for
demonstrative effect) from somewhere, I don't want the website's ftp server to
tell me its 600MB, my operating system to tell me its 600MB, but have Mozilla
disagree and tell me that its actually 629.1MB.
Comment 69 Grey Hodge (jX) 2004-03-08 15:26:05 PST
If we're going to change something, the multiplier is the WRONG thing to change.
I'm against changing to KiB a lot less than changing from 1024 to 1000. If it
wasn't for a new "standard definition" that wasn't needed, this conversation
wouldn't be taking place. The potential to see the new math for filesizes as an
error is MUCH worse than then noticing KiB.

Frankly, the idea of changing the multiplier comes across as more of a cure
that's worse than the disease, maybe offered in hopes of seing KiB as a
middleground to agree on. Both are bad, but changing from 1024 to 1000 is worse.
Why don't we just honor industry convention and stick with kB/1024 until there's
an actual movement towards KiB. This is not a "Jump off a bridge" argument, this
is an issue of USER expectations. We should be consistent not just with an OS,
but with an industry that has an extensive consumer face.
Comment 70 Jonas Sicking (:sicking) No longer reading bugmail consistently 2004-03-08 15:45:52 PST
(In reply to comment #69)
> If we're going to change something, the multiplier is the WRONG thing to 
> change. I'm against changing to KiB a lot less than changing from 1024 to 
> 1000. If it wasn't for a new "standard definition" that wasn't needed, this 
> conversation wouldn't be taking place. The potential to see the new math for 
> filesizes as an error is MUCH worse than then noticing KiB.

You're thinking of it the wrong way around. kB = 1000 bytes isn't new math for
the majority of the planet. kB = 1024 is new and strange for every non-geek out
there. It is simply wrong, and has always been, even though it has been widly
accepted among geeks for quite some time.

> This is not a "Jump off a bridge" argument, this is an issue of USER
> expectations. We should be consistent not just with an OS, but with an
> industry that has an extensive consumer face.

Ask 10 non-geek users how many bytes 1 kB is. I bet that in a country using
non-metric units you'll get a few 'I dunno' and a few '1000 bytes'. Ask in a
metric-using country and you'll get mostly '1000 bytes'.
Comment 71 Grey Hodge (jX) 2004-03-08 16:05:51 PST
> kB = 1000 bytes isn't new math for the majority of the planet.

As stated above, however, 600MB now equalling 629,145,600 bytes _is_. 

> kB = 1024 is new and strange for every non-geek out there.

And standard for everyone involved in the IT industry.

> It is simply wrong, and has always been, even though it has been widely
> accepted among geeks for quite some time.

Not just geeks, anyone in IT. It's not wrong, it's merely at worst a
"non-standard" use of the kilo prefix. As I stated, KiB is bad, KB = 1000 B is
worse. So fine, if that's truly the situation, KiB or KB = 1000 B, then KiB is
my vote. I'm normally against useless changes, but at this point, I don't care.
So let's change kB to KiB, just make sure _every_ developer knows that this is
the new standard nomencalture to be used, or we'll wind up being inconsisted,
yet again.
Comment 72 Jonas Sicking (:sicking) No longer reading bugmail consistently 2004-03-08 16:19:54 PST
> So let's change kB to KiB, just make sure _every_ developer knows that this is
> the new standard nomencalture to be used

..and every non-geek not know what we're talking about. I don't even think that
non-geek IT people knows that 1024B = 1kB in most apps.

Actually, this entire issue isn't very important to me at all, but I think that
we should think about who we are targetting with whatever change (or non-change)
that we do.

If we absolutly want to keep using 1024 as devisor i actually think that we
should use KB as unit. There are very few people that knows about KiB, everyone
else will think it looks weird. Geeks and non-geeks alike. So we better look
sane and no-worse-then-everyone-else, then look sane and mathematically correct.
Comment 73 Hixie (not reading bugmail) 2004-03-08 16:56:04 PST
Man, never has the painting-the-bike-shed analogy been more appropriate than in 
this bug.

We're not using the KiB suffix. It is too geeky at this point in time, and we 
can't afford that. mpt's comment 12 made two and a half years ago _still_ 
applies. Nothing that has been said since then has in any way changed that.

We _might_ want to change to power-of-ten divisors if the people championing 
this bug really feel that accuracy is that important. Either way, _that_ would 
be a new bug, not this one.

WONTFIX. Please do not reopen this bug unless the conditions mpt gave in comment 
12 have come to pass.
Comment 74 Grey Hodge (jX) 2004-03-08 17:02:50 PST
I think, as Hixie said, we went through this a couple years ago... V
Comment 75 John Christopher Jones 2004-03-10 16:42:52 PST
What has changed is that we've established:
 1) Most non-technical users think a kilobit is 1000 bits
    a) I say my local telco/cable broadband providers agree
 2) Technical users know there are a medley of technica situations where a
number is either 2^10 or 10^3.
    b) When you go to CompUSA, BestBuy, Microcenter, Amazon, I-don't-care, and
you look at a hard drive, do you stop and think "gee, is that 80 GB hard drive
really 80 GB or 76 GB?"  And have you ever had to wonder for a second when
looking at RAM?  And, really, does it make any sense to refer to a contiguous
linear address storage system in /8 or /1024 units, as opposed to /1000 units?  No.

So, non-tech users don't know, and tech users have to actually think about this
****.  They shouldn't.  There are better things to waste brain cells on.

And if you're really concerned that non-tech users will think it's a typo, make
KiB/MiB a hyperlink to a mozilla.org page.  It can explain the *RECENT*
standardization process that Mozilla and the rest of the IT industry is
following/adopting, and which Linux and FreeBSD have already adopted.  It can do
so in less than 200 words, and follow up with a clear explanation of 2^(k10) and
10^(k3)for the curious.  It makes Microsoft look slow and behind the curve and
let's face it: if you're using Mozilla you know that.  Now you know Mozilla.org
isn't slow and lumbering and behind the curve.
Comment 76 Shaun Hill 2004-04-06 16:07:46 PDT
(In reply to comment #50)
> On webpages, for those that belive KiB to be confusing, one can always write eg
> 45KiB (KB) which will be both correct as well as educate people.

That wouldn't be correct. KiB and kB refer to two distinct values, so if the
file was eg 45 012 B, then we should write (Mozilla pages usually fix values at
1 decimal place): "45.0 kB (44.0 KiB)".
Comment 77 Daniel Cater 2005-03-31 08:04:12 PST
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2)
Gecko/20050329 Firefox/1.0+
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2)
Gecko/20050329 Firefox/1.0+

I was just about to file a similar bug. Just a few of my thoughts to add here.

If Mozilla is not going to use KiB, then it should at least change all the KB to
kB. At least it would then be "correctly wrong" (small k meaning 10^3) and not
just "wrongly wrong" (big K not meaning anything in the number world.)

However, KiB should be used really. It's correct and avoids any possible
confusion when considering whether it means 10^3 or 2^10. However, many comments
have suggested it would be confusing to those who don't know anything about
binary and just use Mozilla products. That would be fair enough if KiB was much
different to kB (or even the ghastly KB.) But it's not. I honestly do not
believe anyone will be confused when confronted with a file size in KiB. They
probably knew that kB stood for kilobytes, so this abbreviation to them is no
different; it could still stand for kilobytes as the first 2 letters are the
same. Ki(bi)B(ytes) as opposed to k(ilo)B(ytes).

I hope that this will soon become the norm in data size representation.
Comment 78 Alexey Chernyak 2005-06-06 15:30:40 PDT
*** Bug 276656 has been marked as a duplicate of this bug. ***
Comment 79 Alexey Chernyak 2005-06-06 16:06:22 PDT
Just keeping track:

By now all standards organisations have finished their trial periods and have
accepted IEC prefixes for full-use.

* IEC
  o Standard: IEC 60027‐2, Second edition, 2000‐11, Letter symbols to be used in
electrical technology — Part 2: Telecommunications and electronics

* IEEE
  o Standard: IEEE 1541-2002, IEEE Standard for Prefixes for Binary Multiples

* ISO
  o ISO/IEC 18025 EDCS units (draft)

* ANSI
  o Standard: BSR/IEEE 1541-200x, Prefixes for Binary Multiples

* W3C
  o Units in MathML

* NIST
* SI/BIPM

The users now should be a bit more in touch with this since the prefixes have
also been implemented in most popular P2P applications and some disk utilities
for Windows, as well as GNU utilities and Linux kernel. (see the bug URL for a list)

This is not a question of if, but a question of when.
The only thing that creates the inertia holding this back is Windows OS, and
with such broad adaptation by standard organisations this may change soon.

With IE7 on the horizon, I find the 50% share target to be too optimistic, even
though we're already around 10%.
Comment 80 Jon B 2005-11-03 19:53:37 PST
I don't understand why we adhere to standards that confuse and frustrate typical end-users (Bug 25537 and all 120+ duplicates, Bug 45375, etc.), but refuse to implement ones like this that actually matter and make things consistent.

"We won't change it because Microsoft won't change it."  

Geez, c'mon. The open-source community needs to stop playing catch-up with proprietary software.  It's only a matter of time before everyone adopts these. Why wait for Internet Explorer to do it first?  "We are an advocate for standards" - http://www.mozilla.org/about/

"This will confuse the end user."  

The typical end-user thinks kilo- means 1000, just like it does everywhere else in the universe except a few types of computer measurements (where it was originally an approximation anyway).  The ones who are already used to thinking of KB = 1024 are smart enough to figure this out in a few seconds.  This is *less* confusing.  Especially if you make "KiB" a link to an explanation (or just a tooltip: "KiB = 1024 bytes").  

Worst case: they'll blink twice, read a paragraph of explanation, and move on.  Any confusion would be a one-time event.

"If Mozilla is not going to use KiB, then it should at least change all the KB to kB."
"We _might_ want to change to power-of-ten divisors"

NO.  That would be incorrect, since we aren't reporting in multiples of 1000.  We *should* report sizes exactly the way we currently do, in multiples of 1024; like everyone else reports file sizes. The numbers would not change.  But we should do so with an unambiguous unit symbol.

This is more accurate, it's simple to learn, it's endorsed and recommended by pretty much every important standards organization, and it makes sense.

W3C notes on units in MathML: http://www.w3.org/TR/mathml-units/#prefixes

"A plea for sanity": http://www.xciv.org/~meta/2005/02/25/#2005-02-23-units
Comment 81 Hixie (not reading bugmail) 2005-11-04 10:49:13 PST
Jon: We don't support all standards. Some standards are good, some standards are good for certain audiences but inappropriate for most end users, some standards are just plain bad. (Some standards contradict other standards.) In this particular case we have opted to follow this standard where it makes sense (e.g. in about:cache), and not where it doesn't (e.g. the download manager).
Comment 82 Matthias Versen [:Matti] 2006-04-08 11:07:34 PDT
*** Bug 333234 has been marked as a duplicate of this bug. ***
Comment 83 Matthias Versen [:Matti] 2008-01-27 22:27:05 PST
*** Bug 414304 has been marked as a duplicate of this bug. ***
Comment 84 Damian Shaw [Quan] 2008-01-27 22:32:51 PST
Something should change now we have the opportunity with plurals just introduced( http://ed.agadak.net/2008/01/plurals-downloads-statuses-for-yous )

I can't believe what a simple change this would be, it would confuse no one who didn't care and enlighten people who did.
Comment 85 Karsten Düsterloh 2008-01-28 00:20:20 PST
This is not about simplicity but about usefulness.
And the change as such is not useful.
Comment 86 Peter Lairo 2008-01-28 01:25:20 PST
(In reply to comment #85)
> This is not about simplicity but about usefulness.

This is not about usefulness, it is about correctness. 

And the change would make Mozilla correct. Also, the change wouldn't be unuseful either.
Comment 87 u554791 2008-01-28 02:20:38 PST
"And seven years later, the chicken was still alive."

After re-reading the comments, the only reason I see standing out from the others against using KiB is "the users will get confused".

Well it's just not true. John Doe will assume KB, kb, kB, Kb, kib, KiB and whichever variant coming with it is correct and they are all the same if anything. All he wants is to download this big file, take a coffee and come back to see it completed. He frankly doesn't care the least about however the size is named, as long as there IS a size.

In the worst case, he'll think it's a typo until the day he looks it up on wikipedia or whatever else.

I think this at least is pretty clear. As for the idea of keeping KB because it's used by Windows... who had it? Today, Windows Vista (and older versions) gives bytes counterparts and take up that excuse to avoid having to change the KB to KiB. It's pretty obvious Microsoft cares even less than John Doe about how the file size is determined.
Both people and applications will slowly adapt to that standard anyway - a lot have started. Having Mozilla adapt to it would be a step already.
Comment 88 Karsten Düsterloh 2008-01-28 02:31:45 PST
If ISO had wanted to help solving a real-world problem of confusing usage ('kilo' used for 1024), they shouldn't have added to that by redefining traditional measures. Imagine the uproar and confusion if ANSI would define 1 yard := 1 meter!
(Mind that "byte" as such has had different lengths in the past, from about 4-10 Bits!)

ISO could have defined "kilo Octett" to represent 1000 8-Bit-Units, and everything would have been fine. People might have used it (or not - who knows).

As things stand, kiB & Co. are just confusing and thus not helpful.
This bug is WONTFIX for a reason, see Hixie's summary ;-) in comment #81.
Comment 89 Damian Shaw [Quan] 2008-01-28 03:11:43 PST
How on earth is is confusing and unhelpful?!

Have you done any research in to that at all or are you just randomly assuming it? I got my Gran using Ubuntu which at several times uses KiB, that wasn't wan issue at all, not an eyelid bated, the world didn't suddenly get turned upside down. Since then I've had several different non-technical users use Ubuntu and a few other applications use it, I've yet to see any to them have a problem with it.

I'm sure Microsoft could argue having more than one browser is confusing and unhelpful! But we all know that'd just be FUD.

So I at least ask for a constructive reason!
Comment 90 Jon B 2008-01-28 06:41:37 PST
(In reply to comment #87)
> After re-reading the comments, the only reason I see standing out from the
> others against using KiB is "the users will get confused".

"Regular" people in metric countries are more likely to be confused by the way things are now.  Technical people already know about the discrepancies.

Instead of using "KiB = 1024 B", you could also just use the SI prefixes correctly: "kB = 1000 B".  What's the benefit of dividing into powers of two when the file lengths are arbitrary?

(In reply to comment #88)
> they shouldn't have added to that by redefining
> traditional measures.

Whatever are you talking about?  "kilo-" has meant "1000" for hundreds of years, and still does in almost every discipline.  Even in computing, "kilo-" means "1000" in many situations, as it has since the first computers were developed.  It's just the idiosyncratic "K = 1024" Microsoft definition that we're trying to clean up.
Comment 91 Damian Shaw [Quan] 2008-01-28 08:16:06 PST
(sorry for all my typos earlier, I'd only had a couple of hours sleep)

Another point to consider is even if people don't understand KiB meaning KibiByte, a lot will probably think KiB is short for KiloByte causing no more confusion than there is now. 

I've never seen the IEC standard prefix cause confusion in the sense people couldn't work out what was going on. I have seen the Microsoft notation cause such confusion, particularly in the sense of HardDrive space. Manufacturers often use the SI standard prefix GB , but Windows does not use the the SI standard prexfix GB but still uses the acronym, often giving people a feeling they've lost about 7% hard drive space.

What confuses me most is Firefox's moto is usually 'push for good standards'. Here's a good standard, there's no evidence supporting that it'll confuse people, it reduces ambiguity and it'll hopefully push for a wider adoption. But seemingly complying with Microsoft arbitrary notation is more important...
Comment 92 Damian Shaw [Quan] 2008-03-09 08:38:43 PDT
*** Bug 421792 has been marked as a duplicate of this bug. ***
Comment 93 Shawn Wilsher :sdwilsh 2009-12-31 09:45:13 PST
*** Bug 537386 has been marked as a duplicate of this bug. ***
Comment 94 Matthias Versen [:Matti] 2011-03-01 18:33:32 PST
*** Bug 637914 has been marked as a duplicate of this bug. ***
Comment 95 Stefan [:stefanh] 2011-10-19 11:42:55 PDT
*** Bug 695704 has been marked as a duplicate of this bug. ***
Comment 96 Théo Chevalier [:tchevalier] 2013-08-09 18:49:20 PDT
*** Bug 902206 has been marked as a duplicate of this bug. ***
Comment 97 Pat Mächler 2015-06-29 05:09:43 PDT
It appears to me that the system that use the outdated calculation are browsers and Windows.
OS X and most Linux variants (above all Ubuntu) have fixed this by using powers of 10 instead of using powers of 2.

So why not switch to calculating actual kilobytes? 
They're certainly way more intuitive and less confusing (except for Windows users probably).

Note You need to log in before you can comment on or make changes to this bug.