Bug 57240

No; they aren't commonly used. When they are, we'll probably switch to them, but I highly doubt that's gonna happen any time soon.

*** Bug 75304 has been marked as a duplicate of this bug. ***

KDE follow standards and KiBs are standard from the SI. So KDE should follow SI.

I agree with you. Moreover, because that bug report is a wish, I want to make the following suggestion: the user could have the possibility to choose between prefixes for binary multiples (KiB, MiB, GiB, etc...) and prefixes for decimal multiples (KB, MB, GB, etc...). Moreover, the software could make pretext of that choose for explaining the difference to the user.


Also, I must disagree with one point: KiBs are not standard from the SI. Actually, the standard from SI is:
1 KB = (10^3)^1 B = 10^3 B = 1 000 Bytes
1 MB = (10^3)^2 B = 10^6 B = 1 000 000 Bytes
1 GB = (10^3)^3 B = 10^9 B = 1 000 000 000 Bytes
etc... (ha, decimal multiples are so easy :))

That's why IEC (International Electrotechnical Commission) approved as an IEC International Standard names and symbols for prefixes for binary multiples:
1 KiB = (2^10)^1 B = 2^10 B = 1 024 Bytes
1 MiB = (2^10)^2 B = 2^20 B = 1 048 576 Bytes
1 GiB = (2^10)^3 B = 2^30 B = 1 073 741 824 Bytes
etc...

So, we don't use a SI standard when we use KiB ("only" an IEC standard), but when we say "1 KB=1024 Bytes", we totally disagree with SI, wich says 1 K = 1000, for all units (meter, bytes, etc...). It's a reason too to offer KiB and (real, in the SI mean) KB to the user, sothat the user can use an SI standard.


I want to point out that the introduction of the binary prefixes answers real difficulties:
http://www.iec.ch/zone/si/si_bytes.htm
http://physics.nist.gov/cuu/Units/binary.html

the current behavior is simply wrong, if you look at the standards. Eigher leave the current calculation and write "KiB", "MiB".. as units or calculate them with 1000B = 1 KB

A little remind :

You should write kilobyte as kB instead of KB. Prefix for kilo is k, kilometre is written as km.
But for kibibyte, kibibyte is written as KiB.

http://en.wikipedia.org/wiki/SI_prefix (english)
http://www-rocq.inria.fr/qui/Philippe.Deschamp/RETIF/gibi.html (french)

I would like to see Konqi (all of KDE, really) adhere to the IEC standard.  IMO, Konqi should default to using binary units, but it should be a configuration option.  Also, Konqi could display both base-2 and base-10 units in the status bar, tool tips, etc., to help people understand the differences.

While there are undoubtedly people on both sides of this argument, I think it should be the users who decide whether to adhere to the standard or not, rather than the developers.  If the developers allow both options, rather than only their personal choice, I think the freedom (libre) aspect of Free Software would be best served.

Thanks for your consideration.

Regards,
Mark

In general the most common standard should be followed with the correct notations. If several standards are common, let the user chose.

IMHO the only thing that's not okay is to write MB and mean MiB (or vice versa), but unfortunately that's exactly what konqueror does :-/
It's already bad enough that a "256 MB" USB stick has in fact 256000 KiB which is neither 256 MB nor 256 MiB. Konqueror just adds to the confusion by mixing both types of units.

If you know places where Konqueror do not follow defacto standard of k=2^10, M=2^20 and G=2^30 then please tell us so be can be consist about breaking the IEC "standard" (hardly a standard if noone uses it).

On Wednesday 05 January 2005 17:50, Allan Sandfeld wrote:
> If you know places where Konqueror do not follow defacto standard of
Well, I know of exactly two standards and konqueror doesn't follow either of 
them.
> k=2^10, M=2^20 and G=2^30 then please tell us so be can be consist about
> breaking the IEC "standard" (hardly a standard if noone uses it).
AFAIK, k was never 2^10, you probably meant K. The units(7) man page is quite 
interesting.
I don't know about yours, but my kernel (Linux) prints this when booting:
hda: 39876480 sectors (20416 MB) w/2048KiB Cache, CHS=39560/16/63, UDMA(66)
It couldn't be clearer.
I really don't want to start a flamewar about this, there's just huge 
potential for confusion when in fact everything's quite simple: it always 
comes down to the fact whether base 2 or base 10 is used. Unfortunately 
_both_ are used heavily in computing. So, the only way to avoid unnecessary 
confusion is to have two distinct names for two distinct concepts.
In my opinion the best way is to make it configurable whether KDE apps use 
base 2 or base 10, but they should never mix both types of units (as is 
currently done). I don't even care if base 2 or base 10 is default. Why would 
you object to have base 2 computations together with the symbols MiB, GiB, 
etc.?

Kind regards

Gilles

I object to MiB and GiB because they are not well known and can confuse users. (Most users only experience problems with the two standards when they realize their 120Gbyte disk cannot hold 120Gbyte, and that is a marketing scam)

I think KDE is pretty consistent as it is, and consistent with other operating systems as well. Using 10 based everywhere, except when measuring quantities of bytes where 2-based is the norm. 

However I would not object to an option of showing byte quantities in base 10, as long as it is off by default.

On Wednesday 05 January 2005 18:21, Allan Sandfeld wrote:
> I object to MiB and GiB because they are not well known and can confuse
> users.
What do "typical end users" know anyways?
Ask them what the meaning of MB is in the case of
- a hard disk
- a floppy
- a CD-R
- a USB flash drive.
- RAM
They're already confused, so where's the difference?
(Except perhaps that now they know they're confused ;-))

If you find MiB and GiB objectionable, why not change the computation to base 
10. This is less silly as it may seem at first:
- Who cares about the exact size of a file? It's the order of magnitude that's 
important. (After all that's the reason the size is displayed in MBs or MiBs 
and not in bytes.)
- When one has to see whether a file fits onto a storage medium it all depends 
of the device class anyway (see above). So it's always necessary to plug the 
device and compare the available space to the file size, using the same unit, 
being it base 2 or 10.
- With base 10 as default, it's completely okay to call it "megabytes" and the 
"confusing" name "MiB" isn't used.

Not that I would be particularly in favour of switching to base 10. As I 
already stated, I don't care, as long as the correct names are used.

I agree strongly with Gilles Schintgen.

Konqueror should either show KiB and MiB and label them KiB and MiB, or it should show KB and MB and label them KB and MB.

I don't care which option is the default, I just want KDE to give correct output.

Currently it shows KiB and MiB but labels them KB and MB, which is just wrong.

*** Bug 102196 has been marked as a duplicate of this bug. ***

Created attachment 12915 [details]
Implement SI and IEC standard byte prefixes

It's been almost two years since this was originally requested, and it still
isn't implemented.  My _perception_ is that the developers refuse to provide
users with the option of having Konqueror, and the rest of KDE, give accurate
and standards-compliant information.  This makes no sense to me.

We do everything else to a standard (where possible), regardless of how screwed
up other systems may do it. I understand that the developers wouldn't want to
_force_ such a change on the users, but IMO it is reasonable to expect that
they allow us at least the _option_ of complying with standards.

With KDE 3.5 getting closer to being out-the-door, KDE 4 should be getting more
and more attention from developers.  With all the other library changes being
made, now seems like a perfect time to fix this issue for KDE 4.

I have attached a patch that fixes KIO by implementing functions for both
SI-standard prefixes and the IEC Binary Prefixes.  A mechanism should still be
developed to allow users the option of which function to default to, even if
that option doesn't have a GUI anywhere.

Since this is my first patch ever to KDE, I am sure there will have to be
implemented differently, but I do hope this will inspire a proper solution to
this issue.

Thanks,

Mark Taff

Created attachment 12919 [details]
Updated IEC Prefix Patch

This is an updated patch.  It fixes a tab problem.  It also defaults to using
the IEC binary prefixes with binary math, as that is the closest to existing
behavior.  It still has functions for both binary and base 10, so developers
could specify one way or the other when needed.

Thanks for the patch; however I'm not sure if we should let applications decide which unit to use; shouldn't we use only one, and consistently?
I think there should be only one "convert" method, and it should either always use kB/MB/GB, or always kiB/MiB/GiB, or use a hidden config entry to decide (I don't think most people care, so no GUI checkbox).

For now I'd simply keep the existing conversions and change the labels to be correct.
But it's too late in the 3.5 branch already (message freeze since September 5th!).

SVN commit 468927 by dfaure:

Use the correct units for the calculation that we make: 1024 B is 1 KiB, not "1 KB".
IMHO this resolves 57240, but let's see if anyone really wants kB support too...
CCBUG: 57240

Can I backport it to the 3.5 branch even though breaks the message freeze?
CCMAIL: kde-i18n-doc@kde.org


 M  +20 -8     global.cpp  


--- trunk/KDE/kdelibs/kio/kio/global.cpp #468926:468927
@@ -45,30 +45,42 @@
 #include <volmgt.h>
 #endif
 
+// If someone wants the SI-standard prefixes kB/MB/GB/TB, I would recommend
+// a hidden kconfig option and getting the code from #57240 into the same
+// method, so that all KDE apps use the same unit, instead of letting each app decide.
+
 KIO_EXPORT QString KIO::convertSize( KIO::filesize_t size )
 {
+    // Per IEC 60027-2
+
+    // Binary prefixes
+    //Tebi-byte             TiB             2^40    1,099,511,627,776 bytes
+    //Gibi-byte             GiB             2^30    1,073,741,824 bytes
+    //Mebi-byte             MiB             2^20    1,048,576 bytes
+    //Kibi-byte             KiB             2^10    1,024 bytes
+
     double fsize = size;
     QString s;
-    // Giga-byte
+    // Gibi-byte
     if ( size >= 1073741824 )
     {
         fsize /= 1073741824.0;
-        if ( fsize > 1024 ) // Tera-byte
-            s = i18n( "%1 TB" ).arg( KGlobal::locale()->formatNumber(fsize / 1024.0, 1));
+        if ( fsize > 1024 ) // Tebi-byte
+            s = i18n( "%1 TiB" ).arg( KGlobal::locale()->formatNumber(fsize / 1024.0, 1));
         else
-            s = i18n( "%1 GB" ).arg( KGlobal::locale()->formatNumber(fsize, 1));
+            s = i18n( "%1 GiB" ).arg( KGlobal::locale()->formatNumber(fsize, 1));
     }
-    // Mega-byte
+    // Mebi-byte
     else if ( size >= 1048576 )
     {
         fsize /= 1048576.0;
-        s = i18n( "%1 MB" ).arg( KGlobal::locale()->formatNumber(fsize, 1));
+        s = i18n( "%1 MiB" ).arg( KGlobal::locale()->formatNumber(fsize, 1));
     }
-    // Kilo-byte
+    // Kibi-byte
     else if ( size >= 1024 )
     {
         fsize /= 1024.0;
-        s = i18n( "%1 KB" ).arg( KGlobal::locale()->formatNumber(fsize, 1));
+        s = i18n( "%1 KiB" ).arg( KGlobal::locale()->formatNumber(fsize, 1));
     }
     // Just byte
     else if ( size > 0 )

On Sunday 09 October 2005 20:10, David Faure wrote:
> SVN commit 468927 by dfaure:
>
> Use the correct units for the calculation that we make: 1024 B is 1 KiB,
> not "1 KB". IMHO this resolves 57240, but let's see if anyone really wants
> kB support too... CCBUG: 57240


Sorry but I find it curious that on one side we try to increase usability for 
new users and on on the other, we introduce now units that are supposed to be 
for experts only, as far as I know.

>
> Can I backport it to the 3.5 branch even though breaks the message freeze?


No backport, please.

KDE 3 has always used the legacy/historical abbreviations and should keep so, 
especially as we are in message freeze for KDE 3.5.

If it was supposed to be in any KDE 3.x, it could have been done at the time 
of the discussion on kde-core-devel in 2002:
http://lists.kde.org/?t=103245396300004&r=1&w=2

Have a nice day!

> CCMAIL: kde-i18n-doc@kde.org
>
>
>  M  +20 -8     global.cpp
>
>
> --- trunk/KDE/kdelibs/kio/kio/global.cpp #468926:468927
> @@ -45,30 +45,42 @@
>  #include <volmgt.h>
>  #endif
>
> +// If someone wants the SI-standard prefixes kB/MB/GB/TB, I would
> recommend +// a hidden kconfig option and getting the code from #57240 into
> the same +// method, so that all KDE apps use the same unit, instead of
> letting each app decide. +
>  KIO_EXPORT QString KIO::convertSize( KIO::filesize_t size )
>  {
> +    // Per IEC 60027-2
> +
> +    // Binary prefixes
> +    //Tebi-byte             TiB             2^40    1,099,511,627,776
> bytes +    //Gibi-byte             GiB             2^30    1,073,741,824
> bytes +    //Mebi-byte             MiB             2^20    1,048,576 bytes
> +    //Kibi-byte             KiB             2^10    1,024 bytes
> +
>      double fsize = size;
>      QString s;
> -    // Giga-byte
> +    // Gibi-byte
>      if ( size >= 1073741824 )
>      {
>          fsize /= 1073741824.0;
> -        if ( fsize > 1024 ) // Tera-byte
> -            s = i18n( "%1 TB" ).arg( KGlobal::locale()->formatNumber(fsize
> / 1024.0, 1)); +        if ( fsize > 1024 ) // Tebi-byte
> +            s = i18n( "%1 TiB" ).arg(
> KGlobal::locale()->formatNumber(fsize / 1024.0, 1)); else
> -            s = i18n( "%1 GB" ).arg(
> KGlobal::locale()->formatNumber(fsize, 1)); +            s = i18n( "%1 GiB"
> ).arg( KGlobal::locale()->formatNumber(fsize, 1)); }
> -    // Mega-byte
> +    // Mebi-byte
>      else if ( size >= 1048576 )
>      {
>          fsize /= 1048576.0;
> -        s = i18n( "%1 MB" ).arg( KGlobal::locale()->formatNumber(fsize,
> 1)); +        s = i18n( "%1 MiB" ).arg(
> KGlobal::locale()->formatNumber(fsize, 1)); }
> -    // Kilo-byte
> +    // Kibi-byte
>      else if ( size >= 1024 )
>      {
>          fsize /= 1024.0;
> -        s = i18n( "%1 KB" ).arg( KGlobal::locale()->formatNumber(fsize,
> 1)); +        s = i18n( "%1 KiB" ).arg(
> KGlobal::locale()->formatNumber(fsize, 1)); }
>      // Just byte
>      else if ( size > 0 )

On Sunday 09 October 2005 21:19, Nicolas Goutte wrote:
> Sorry but I find it curious that on one side we try to increase usability for 
> new users and on on the other, we introduce now units that are supposed to be 
> for experts only, as far as I know.


It will become known to more than experts if we start using the correct units
in GUIs, not just in the linux kernel boot message. Chicken and egg problem,
let's make the first egg to solve the problem.

> If it was supposed to be in any KDE 3.x, it could have been done at the time 
> of the discussion on kde-core-devel in 2002.


No time machine, sorry. Also, time had started to make the units more used 
already, so switching makes more sense now than at the time.

With this change being made, I would be happy to write some documentation text explaining the differences between SI and binary prefixes, a short history, and how this new standard clears up the confusion.

I presume we need a page for Konqi's handbook, and some generic what's this text/code that could be added to all apps who use these units without using KIO.  Any other places where there might need to be some documentation?

As for the SI-standard prefixes, I believe they are used for some aspects of computing, such as transmission line speed.  We may not need them in KIO, but perhaps in some other part of KDE Libs?

On Sunday 09 October 2005 22:43, Mark A.Taff wrote:
> With this change being made, I would be happy to write some documentation 
> text explaining the differences between SI and binary prefixes, a short history,
> and how this new standard clears up the confusion.  


Thanks, that would be a good idea.

> I presume we need a page for Konqi's handbook


Yes. Please send the text (preferrable docbook formatted) to the kde-doc-english mailing-list
or to Lauri Watts <lauri@kde.org>. Thanks!

On Monday 10 October 2005 09:44, you wrote:
> Am Montag, 10. Oktober 2005 00:48 schrieb Federico Zenith:
> > I do not agree if you mean that we should continue using "kilo" for 1024
> > and similar ones for "mega" and "giga", this is simply wrong. I agree if
> > you mean we should keep these prefixes and correct their actual values to
> > 10^3, 10^6, and 10^9.


I've been thinking about that after my commit - this might be a better solution
indeed. Only a fraction of computer users know that 1 KiB = 1024 B,
whereas everyone knows that 1 kB = 1000B just like 1 kg = 1000g.

> I don't really think this issue should be discussed on the translators list,
> rather on some usability list. Generally I agree though - I'm pretty tired
> of my hard drive having 40GB, but only having place for 37 files that 
> konqueror displays as 1GB.


Does 40G for the harddrive mean 40*1000000 bytes? Then using GB (decimal)
for the files would be a good idea indeed.

> Does 40G for the harddrive mean 40*1000000 bytes? Then using GB (decimal)
> for the files would be a good idea indeed.

Yes, but unfortunately hard disks are not the only available storage media. 
And the size of one "MB" depends on the category (floppy, USB stick, CD, DVD, 
HDD). That's why it's so important to get some consistency in the use of MB 
and MiB.

> Only a fraction of computer users know that 1 KiB = 1024 B, 
> whereas everyone knows that 1 kB = 1000B just like 1 kg = 1000g. 
 
I fully agree with that view... please, let's just use base 10 and keep iB units in the lab...

No, let's not do that, please. No one uses decimal units except harddrive manufacturers. If Konqueror suddenly starts displaying ISO images as 734 MB, people will be confused.

The fact that end users don't know 1 kilobyte (I refuse to name it kebibyte) = 1024 bytes doesn't change anything.

However we name them, we should use powers of 2. I would prefer nothing be changed, though.

Gilles is right on target.  It is very important to set/keep kB = 1000 and kiB = 1024 to avoid confusion.  As it is now, when you see kB, MB, etc, you have no way of knowing whether they mean base 2 or base 10 besides looking at the actual byte count.

Germain is right that it seems natural for non-geeks that kilo, mega, etc keep their SI meanings.

Some people will be strongly resistant to any change, like Thiago refusing to call 1024 bytes a kebibyte, despite the IEC and IEEE standards. Thiago argues for the status quo, which is _completely_ incorrect.

Either switching completely to SI or completely to Binary are equally correct solutions.  I prefer the binary IEC solution for most things, as it maintains the computer heritage of using base 2 math, and porting existing apps is trivial.

However, we still need to use the SI prefixes for other computer uses, such as transmission speeds, bus speeds, clock speeds, etc.

I submit most users aren't going to care whether kB=1000 or if kB=1024.  Those that do care about it, should be given the correct info, i.e. kilo=1000 (like with line speed) and kebi=1024 (like in file sizes).

I like David's commit as is, though I could support a config-file-only option to choose between SI and IEC.

Regards.

Mark

You are making it unnecessarily confusing bytes are always measured in base 2 kilos/megas except by lying harddisk manufacturers. Bits are measured in base 10 kilo (like in bandwidths).

Besides refering to SI means nothing as long as bytes is not a SI unit. kbytes is not a SI unit no matter if k means 1000 or 1024.

On Monday 10 October 2005 23:00, Allan Sandfeld wrote:
> bytes are always measured in base
> 2 kilos/megas except by lying harddisk manufacturers.

* What about those DVD-5 discs which hold 4.7 "GB"? Guess what, that's 4.7 
(decimal) GB or 4.38 gibibytes. (See wikipedia.)
* Hmmm, DVDs and CDs are almost the same, aren't they? Surprise, surprise.
1CD = 700 "MB" where "MB" is actually MiB (contrary to DVDs).
* What's left? Flash media. Binary? Decimal? Neither!
$ df
/dev/sdb1               255728      1188    254540   1% /media/sdb1
That's right, in the case of my Cruzer Micro, 1 "MB" equals 1000*1024 bytes 
(approximately). In other words, its capacity of "256 MB" is actually 250 MiB 
or 262 MB.

Do you still think that everything is just perfectly fine?

Kind regards,

Gilles

When we refer to `SI`, we are not alleging that byte is an official SI base, derived, or other unit, but rather we are referring the the SI standard meanings of the base unit multiple prefixes like kilo-, mega-, giga-, etc.

According to wikipedia, the hard drive manufacturers aren't lying, though they do seem to be, in some cases, taking advantage of the confusion over the definition of the SI-standard prefixes.

Regards,

Mark

That means there is no definite standard by hardware and component manufacturers. The only standard so far is what programmers use: base 2. So I prefer we stick to it. Whether the unit is "KiB" or "kB" it doesn't really matter for me. How many people did know the "k" should be lowercase anyways?

All I ask is that you never write "kebibyte" in full :-)
(which would have to be i18n'ed, because "byte" doesn't exist in French, for instance)
(but, then again, KiB must be i18n'ed as well, so that's not an argument)

What is also the correct way to express "bit"? As "b" or "bit"? I've seen Mb/s and Mbit/s and I would much rather see the latter.

From my readings, the SI people prefer "bit" instead of "b" as that way it can't be confused with the Bel (B).  They do note that for most practical measurements, the deci-bel is used, so it seems they begrudgingly accept "b" as being OK for bit.

What about nibble?

Unfortunately, I think we shall have to write out "kebibyte" in the same places we would have to write out "kilobyte", such as documentation.  Sorry.  :-(

I don't think, that it's easy to understand, that B and b means something totally different, so we should write "Mbit".

This 1000*1024 is somewhere else too: Floppies. They are neigher 1,44MB nor 1,44MiB. They are 1440 KiB. Afaik even hard disks are 1000*1000*1024 Byte = "1 GB"

Let's add my point of view:

For years and years and before computing science, "k" is meaning "thousand". One day a not very rigorous data processing specialist decided to call "kB" a unit of 1024 bytes because 1024 it is almost 1000. It's time to repair this error for multiple reasons.

First for the newbies: To increase the comprehension and accessibility of computing.

Second to raise ambiguities: The primary error on "k" has produce many ambiguities bitween units in bandwith, floppy, hard disc, RAM...

Third again ambiguities: What about "m"? is mB is 1000x1024 or 1024x1024? There is multiple logics.

So please repair errors made in the past. No matter of a few computer scientists: "The irreducible Asterix and Obelix". Bring to the world the clarification which it needs.

Actually kb was invented to mean 1024 bytes. B was original used for bits. But for some logical concerns KB was later used to mean 1024 bytes. 

m means milli (1/1000) by the way, you are thinking of M which is 1^6.

But life is full of mistakes. If we where rational we would use 12-based "decimal" system, the US would use metrics and we would all use Kelvin.

Don't wage a holy war on reality, just deal with the ambiguity.

Isn't this bug ready to be closed? My Konqueror shows Kibytes and Mibytes and I'm so happy! Someone had to take the first step and you did! (I hope it's not just in Debian.)

Now go metricate the U[SK]. :-)
(OK, first fix Gnome.)

Not solved in Ubuntu's version. Version 3.5.0.

Sorry to add more noise to this bug, but I think the issue is worth it.

Here is my tentative to summarize the situation, and to clarify it for some people who seem very confused. As pointed several times here, more information can be found on Wikipedia[1].

First, which device is using what ?

The "power of two" prefix are used in:
- RAM
- CD

The "power of ten" prefix are used in:
- hard drives built since at least 2001
- DVD
- next generation DVD (HD-DVD and blu-ray)
- USB flash memories/drives (my 128 MB usb stick contains 129.366.016 bytes, which in binary units would correspond to 124 megabytes)
- memory cards (e.g. a 16 MB memory stick contains 16.138.240 bytes)

As of operating systems and desktop environments:
The "power of two" prefix are used in:
- MS Windows
- Gnome
- KDE (well, it seems it has changed in recent version)

The "power of ten" prefix are used in:
- Linux kernel (check dmseg)
- Rox, a quite user-friendly desktop using GTK toolkit.

I do not know the situation for MacOSX or BSDs. GNU is defaulting to power of two, but at least some of its tools can also use power of ten(*).

Historically, there was no convention used on computers in the past. Indeed, the famous 1.44 floppy disk contained 1.44 * 1000 * 1024 bytes, which is quite characteristic of the past confusion. Pretending that there was a clear convention for kilo=1024 is just plain inaccurate.

What are the reasons to stay with power of two when displaying files in KDE ?
- binary arithmetics is faster than power of ten one. TRUE, but what is the gain... a few micro(milli?)-seconds ?
- present code uses power of two.
- developers like power of two.

What are the reasons to switch to power of tens when displaying files in KDE ?
- to be consistent with what is written on the DVD pack, or on the USB key, etc. of the user.
- for Aunt Tillie, using powers of ten is much easier than powers of two.
- to be consistent with the other units used in the computer, such as the MHz or GHz of the processor which stand for million and billion respectively. Same argument is valid with the MBit/s of network devices/modems or the MFlops/GFlops of the CPU/GPU. Or the refresh rates of the screen in Hz and kHz (line scan frequency).
- to remove any source of confusion: when binary system is more useful, the standard proposed by the IEC, (KiB, MiB, GiB etc.) can be used.
- to follow the worldwide centuries old standard[2] than nearly everyone has agreed on. A kilogram is 1000 grams. A kilometer is 1000 meters. A GigaHertz is 1 billion Hertz. Why would a GigaByte be  1073741824 Bytes ?
- To follow an international standard. After all, Free Software / Open Source has shown its superiority to commercial software when it comes to follows standards, such as CSS, XHTML or PNG. Think about how good KHTML and Gecko are compared to commercial counterparts. Yes it is a political choice, similar to the use of the new open document format in openoffice.org and Koffice. This standard is at least set in the SI[3-6], ISO 31[7] and IEC 60027-2[8] standards.
- to be consitent with the most used kernel for KDE users: Linux, which has been following the standards for years.

So there are 3 possible alternatives:
1- use kilo/meg/giga/tera prefix and power of 2. This solution creates a confusing state, since there exist two competing definitions for the terms. One widely used, the power of ten, and one marginally used ,the power of 2.
2- use kibi/mebi/gibi prefix and power of two. This solution seems confusing too since they are not widely known prefix.
3- use "power of ten", i.e. plain SI units. This is the most user-friendly solution. It also follows the de-facto industry standard, so the file manager and other programs returned information consistent with the devices.

The only reason I see against the power of ten is that the convertion requires more CPU cycles. However, I cannot think of any application where this could result is a visible slowdown of the computer.

Notes and references

(*) example: "df --si" or "df -H", "ls --si". Additionally, df and ls use MB for 1,000,000 and M alone for 1,048,576

[1] http://en.wikipedia.org/wiki/Binary_prefix
[2] According to the following link, kilo was introduced in 1793 and mega in 1874.
    http://web8.ehost-services.com/cdkaese/metre/prefixes.htm#encyclopaedia
[3] http://en.wikipedia.org/wiki/SI
[4] http://en.wikipedia.org/wiki/SI_prefix
[5] http://physics.nist.gov/cuu/Units/binary.html
[6] http://www.bipm.fr/en/si/prefixes.html
[7] http://en.wikipedia.org/wiki/ISO_31
[8] http://en.wikipedia.org/wiki/IEC_60027-2

In reply to oliv I would point out that there is one other option:

To allow for both #2 or #3 via a global config option.  In that case, I would certainly prefer option #2 set as KDE's default, though I am certain each distro will have their way with that one.

Regards,

Mark

*** Bug 143142 has been marked as a duplicate of this bug. ***

*** Bug 131022 has been marked as a duplicate of this bug. ***

*** Bug 138893 has been marked as a duplicate of this bug. ***

*** Bug 164299 has been marked as a duplicate of this bug. ***

*** Bug 165603 has been marked as a duplicate of this bug. ***

In reply In reply to oliv for comment #39.

Agreed with comment #40.
Option 2 by default. A config option with option 3.
A small description in the help.

I feel like dying species or something :-( I was always taught kilo stand for 1000, Kilo stands for 1024, and it was far from ZX81 times.

Even if KiB is more trendy nowadays please provide option to choose suffix (KB/KiB) and meaning of it. I think nowadays beasts that can handle fancy plasmoids can handle one extra call to kdelibs 
capacity_str(free_space_on_usb())
instead of hardcoding this calculation,

The reason for this is:
* on one hand do whatever is necessary to do to please weekend users
* on the other hand please respect old-timers (I don't felt like 5 minutes ago) so I could still live happily in world of KB/GB and good 2^X scale

196 votes, 47 comments, and two tiny options which could "solve" this once for good I think it is not too much to ask.
[ ] use KiB suffix instead of KB
[ ] use 10^N instead of 2^X

PS. The product should be kdelibs, not konqueror, because it would be crazy if each app would use its own settings.

Comment #47, please also read all duplicates before adding comments. The bugzilla janitors here are a quite a zealous bunch and also merge topics that are just related, not exactly identical.

These preferences are no good. See bug 131022 for a mock-up that attempts to cover all use cases.

Why not? It covers all possibilities (sane ones).

KiB meaning 1000
KiB meaning 1024
KB meaning 1000
KB meaning 1024

(and of cours the same for GB, MB, TB, PB, and so on)

Is there any "system" of calculation missed?

The bug mentioned above is wrong, there was not such "system" as G for Giga and k for Kilo at the same base. It was always lowercase (k,m,g...) or uppercase (K,M,G..) not mixed.

And for octet, ok, one option more if it is really valid, I didn't hear about Go for capacity, but well, I learn all life :-)

PS. One more note, I think it is not to debate how many variants are needed, but to cover the most "hot" issues right now. The fact is for sure there one function in kdelibs would can convert number of bytes to proper string, and if those two options will not be enough there could be a further discussion what else is needed. But note -- there will be no more changes in libraries, because you still need to call this capacity_str function.

"The bug mentioned above is wrong, there was not such "system" as G for Giga and k for Kilo at the same base. It was always lowercase (k,m,g...) or uppercase (K,M,G..) not mixed."

What are you talking about? The case of the letters is defined within the SI unit system.  Giga (G) is always upper case, kilo (k) is always lower case.  The informal use of a capital K for base-2 is where this confusion started.

Since everything anyone is likely to want to do with a file size will be base-10 (calculating space left on disk, which is always given in base 10 by manufacturers; calculating upload or download time, since network speeds are always base 10) it makes no sense to provide file sizes in base 2. The only time you'd care about that was if you wanted to calculate whether a file would fit in RAM, and when does anyone ever do that?

So the useful option, for average users, is base 10 units, standard SI prefixes. For computer scientists, a checkbox for base-2 and Ki/Mi/Gi should suffice, as they aren't going to panic if they see an unfamiliar prefix, and they ought to have seen the base-2 prefixes by now.

Also, since I haven't linked to my article on the subject yet: 
http://lpar.ath0.com/2008/07/15/si-unit-prefixes-a-plea-for-sanity/

Mathew, about mix -- you are right, since I am developer I live in bits world mostly, sorry for that.

But about the rest -- not everyone wants base 10. I used KB/MB/GB terms for last 22 years (in 2^X scale) and I don't want to change my thinking just because KDE becomes more "trendy" and uses KiB/GiB and so on.

Respect users habits.

And I don't get your argumentation -- will those two options hurt you in some way? No? Then let users decide for their own. I don't see any point in narrowing choice if I know right now that it will not suffice.

It's nothing to do with "trendy", it's to do with accurately and unambiguously reporting file sizes. No matter how much you may wish it wasn't true, the vast majority of things, even in the computer world, are measured in base 10 units--including disk capacity and network speed. Therefore it's simply more useful to provide base 10 by default. (Read my article linked above.)

Nobody's suggesting that there shouldn't be an option for base 2, if for some bizarre reason you find that more useful. But base 2 should be indicated correctly, of course.

> Therefore it's simply more useful to provide base 10 by default.

Of course. I totally agree.

> Nobody's suggesting that there shouldn't be an option for base 2, 
> if for some bizarre reason you find that more useful. 

It is not "bizarre", it is different. Respect other people, please.

My only objection was limiting options to either KB for 1000 or KiB for 1024. The scale should be configurable _and_ unit (independently).

> The scale should be configurable _and_ unit (independently).

What rational reason could there be to display kB but indicate KiB?  Or to display KiB, but indicate kB?

Seriously, things are standardized (IEC, IEEE etc.). If you use base 10, its kB, if you use base 2, its KiB. KB is unofficial and not standardized. see
http://en.wikipedia.org/wiki/Binary_prefix and
http://www.annodex.net/cgi-bin/man/man2html?units+7

why do we have institutions for standardization when we don't respect the standards they define. just my 5 cents... ;-)

You (Mathew) opt for having _mutual exclusive_ two options. Does it really hurt your feeling or something, that you cannot allow people to have non-mutual exclusive two options. Is a crime that I would set it for KB/1024? I don't simply get it. Let me use use my computer the way I used it for 22 years.

Mathew, John, standards, your likes and dislikes, I don't really mind if you call 10 bits a byte. It is your free choice. And in return I expect you allow me to use KB/1024 system, ok? Those options will be implemented and I don't see any point in insisting they have to be mutual exclusive.

You, your computer, your programs will be no affected by my non-standard information display, I promise :-)

Well there is such a thing as over-configurability, so no we are not going to add an option for "calling 10 bits a byte",
to take your far-fetched example. Similarly, there shouldn't be an option for KB should be there at all, it doesn't make sense.
This isn't just about choice (you can use your computer the way you want, just patch kde),
it's also about making the world a slightly more sensible place by not propagating ambiguities onto more people.
I'm opposed to adding code for "KB", but I'm not opposed to a kB/KiB config option for KLocale::formatByteSize.
I'm just not sure how many users other than those reading this bug report (which is turning into a discussion forum btw)
are going to care enough to change that option...

Of course I am not for overconfigurability, but to have configurable KiB/1024 KB/1000 such options are required

( ) KiB/1024
( ) KB/1000

and just almost by granted, by changing this to

[ ] KiB instead of KB
[ ] 1024 instead of 1000

you get four not two possibilities.

>  I'm not opposed to a kB/KiB config option for KLocale::formatByteSize. 

Does it mean there will be one global function which get this as an input and calculate string, or each app on its own should calculate it using KLocale::formatByteSize? If the former -- I vote for it.

Anyway, even with two choices I'll be happy. So maybe instead of further discussion "what is the point of KB/1024" let's focus on even minimal fix.

> Is a crime that I would set it for KB/1024? I don't simply get it. 
> Let me use use my computer the way I used it for 22 years. 

So because your computer displayed wrong values for 22 years, you want it to continue to display wrong values. Don't you see how silly that seems to the rest of us?

Are you like this with other bugs? Should we have checkboxes every time someone fixes a bug, in case people prefer to continue having incorrect data displayed?

> it's also about making the world a slightly more sensible place by not 
> propagating ambiguities onto more people. 

Bravo!

> So because your computer displayed wrong values for 22 years, you want it to
> continue to display wrong values. Don't you see how silly that seems to the
> rest of us? 

Values were correct, and I would like to continue to use them as before, and I am happy to be in a good company here. I would appreciate if you stop forcing your opinion how _my_ computer should work as well overusing words like silly, bizarre, etc. Thank you.

I think everything was said already so there is no point for further discussion on this subject.

Values were not correct. k = 1024 and M = 1024*1024 was never correct; there are standards for this stuff, and it is not a matter of opinion, no matter how many people think otherwise.

I don't care how your computer works. Patch it to call bytes "octets" if you like. I just care about KDE displaying *correct* information and abiding by open international standards.

I never used k for 1024, it was K. And the meaning of words is not of divine origin, people use it, people understand it, thus it makes correct usage and meaning. ZX81 had 1KB memory (1024), ZXSpectrum 48KB (48*1024) and so on. It made the meaning of K once for good.

Oh boy, we should "correct" all the info sources, starting from wiki, because, shame-o-shame, it quotes ZX81 had... 1KB memory.

>  no matter how many people think otherwise. 

It matters. It is a language after all. Get some people, add some time and you will get "standard", voila.

We're not talking about the meanings of words, we're talking about SI units. The SI units aren't defined by popular usage or by what random pages on Wikipedia say.

And this isn't about K = 1024. That was never a problem. Back in the days of the ZX81, k was 1000 and K was 1024 and everyone was happy. The problem started in the late 80s when disk and memory sizes started to hit MB and GB ranges, and people glossed over the K/k distinction and decided to casually redefine giga- and mega- prefixes.

I would actually support an option to keep K = 1024, as that's distinguishable from the SI kilo prefix k = 1000. But that doesn't help with GB and MB, so I doubt it'd make you happy.

Mathew, look at things that can agree, rather we disagree, ok?

Again:

 [x] _iB instead of _B 
 [ ] pow of 2 scale instead of pow of 10

(default values). This makes weekend user happy (KB/1000), this makes you happy (? KiB/1024), this makes me happy (KB/1024), this makes everybody happy.

Why not make KDE the way everybody is happy?

The problem is that there are four possible combinations of your proposed checkboxes, and two of them result in KDE displaying incorrect information. In fact, one is an option literally nobody has said they want.

I don't think KDE should provide users with the option of displaying incorrect information, no matter how much any individual may want it. That way lies madness. I mean, some users don't like file permissions, so should there be an option to pretend all files are owned by the logged in user even when they aren't? 

I think formatting preferences are fine, but if you want incorrect information displayed, it's reasonable to tell you you should have to patch the source yourself.

> The problem is that there are four possible combinations of your proposed
> checkboxes, and two of them result in KDE displaying incorrect information.
> In fact, one is an option literally nobody has said they want. 

Ok, let's make it three options :-) 

> I mean, some users don't like file permissions, so should there be an option
> to pretend all files are owned by the logged in user even when they aren't? 

Some users don't like to use access time info, and guess what, there is an option for it.

> I think formatting preferences are fine, but if you want incorrect
> information displayed, it's reasonable to tell you you should have to patch
> the source yourself. 

Fair enough (the non-SI does not make it incorrect though).

OK unfortunaly konqueror in kde 3.5.10 still misslabels them, led to confusion when a website required a 10MB file and konqueror reported 9.7, but was over 10,000,000 bytes, it should at least be renamed in the old version.

I personally can't stand the use of KiB, MiB, GiB, etc. and KDE is the only desktop environment I know that uses this prefix system. I think it should be an optional feature, if anything, and that KB, MB, GB, etc. should be used by default so as not to confuse people.

The 'mainstream' computer users in this world have, IMO, has grown used to KB, MB, GB, etc. and I would expect that many people do/would not like this change.

Created attachment 35014 [details]
Provides KB = 2^10 bytes behaviour

This patch will not be applied to KDE, but if you need this behavior you can apply this patch to get it. Originally submitted by Michael Pyne to kde-devel list.

Created attachment 35015 [details]
Provides kB = 10^3 bytes behaviour

This patch is not expected to be applied to KDE. However if you need this behavior you may apply the patch yourself.

Attachments have been added that can provide all of these requested varying behaviors to Konqueror (4.4) if people need them. However, since Konqueror does display file size as wished for in the bug description this bug should be marked as resolved/implemented.

(In reply to comment #70)
> I think it should be
> an optional feature, if anything, and that KB, MB, GB, etc. should be used by
> default so as not to confuse people.

Interestingly, there has not been any report about a user confused by KiB, MiB, GiB, etc. since Dolphinpart uses these units since KDE 4.0.

Remember that SI is not optional (professionals are even forced to use it in every country of the world except for Liberia, Sri Lanka, and the USA *sigh*).

Revision 996857 adds support for JEDEC units and metric units in addition to the IEC units already supported.  (JEDEC is the standard for the "traditional" units used in KDE 3.5.  I was as surprised to find out they actually were standardized as anyone else...).

Add the BinaryUnitDialect=0 option to the [Locale] group of your $KDEHOME/share/config/kdeglobals file.

setting to 0 (or leaving unset, of course) gives you the current default of IEC units since they are unambiguous and in accordance with the current revision of the relevant standards documents.  Setting to 1 gives you JEDEC units.  Setting to 2 gives you metric (yes, real powers-of-10, lowercase k instead of K, metric units).

There was more added in that commit for developers but nothing that pertains to this bug.

Everyone has what they want, unless what you want is to keep someone else from having what they want.  There will be no GUI.  I consider this feature request fixed.  If you see uses of binary units in KDE not in accordance with what you've selected then the application involved probably manually handles the conversion instead of using formatByteUnits, in which case a bug should be opened against that application.

*** Bug 364321 has been marked as a duplicate of this bug. ***