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
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
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.
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"?
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.
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
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
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.
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.
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.
Ah but kilograms are masses and pounds are weights. We do misuse pounds.
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.
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.
email@example.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.
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.
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.
VERIFIED (for now, anyway).
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).
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.
it's funny that a google search for "kilobyte KiB" (quotes excluded) resulted in: Did you mean: kilobyte Kb ;-)
Comment on attachment 135963 [details] [diff] [review] patch to fix about:cache sr=darin this is the right thing to do.
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...
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
"we rejected KiB somewhere else once", I think it was this bug! see firstname.lastname@example.org's comments in http://bugzilla.mozilla.org/show_bug.cgi?id=124336#c4
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 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.
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 on attachment 135963 [details] [diff] [review] patch to fix about:cache This doesn't add any significant value to 1.6.
I wouldn't be against fixing this just for about:cache for now.
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)
> (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.
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.
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.
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.
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
"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.
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.
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.
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.
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.
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.
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.
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 on attachment 142394 [details] [diff] [review] patch to fix some locale stuff you forgot the Cache options.
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
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?
> 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.
> 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.
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.
(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.
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.
(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?
(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)
> 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.
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.
(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)?
(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.
> 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.
> > 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"
(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...)
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.
(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.
> 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").
(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.
(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.
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.
(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'.
> 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.
> 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.
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.
I think, as Hixie said, we went through this a couple years ago... V
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.
(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)".
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.
*** Bug 276656 has been marked as a duplicate of this bug. ***
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%.
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
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).
*** Bug 333234 has been marked as a duplicate of this bug. ***
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.
This is not about simplicity but about usefulness. And the change as such is not useful.
(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.
"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.
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.
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!
(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.
(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...
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).