Kibibyte and mebibyte - WTF?

[david77]

Was just watching yesterday's QI and heard about the kibibyte.

http://en.wikipedia.org/wiki/Kibibyte

Subsequently also found the mebibyte

http://en.wikipedia.org/wiki/Mebibyte

and also the gibibyte http://en.wikipedia.org/wiki/Gibibyte

This really annoys the hell out of me. I guess I'll just ignore it.

 

[c4757p]

It was designed to replace the kilobyte, where used in some computer science contexts to mean 1024 bytes, which conflicts with the SI definition of the prefix kilo.

Well, since "byte" is not an SI unit, what the flipping hell does it matter?

[alm]

I agree, just stick to the decimal prefixes and ignore the confusing base-2 units.

[Monkeh]

It was designed to replace the kilobyte, where used in some computer science contexts to mean 1024 bytes, which conflicts with the SI definition of the prefix kilo.

Well, since "byte" is not an SI unit, what the flipping hell does it matter?

Kilo, I'm afraid, is an SI prefix. Redefining it to suit you is just stupid.

[nitro2k01]

The binary prefixes are perfectly reasonably because of how solid state computer memories (ROM, RAM) are physically constructed and addressed. Your other options are to abuse the SI prefixes to work in orders of 1024 instead of 1000, or to write memory sizes like "4.3 GB" (that is, 4*1024*1024*1024, or 4294967296 bytes) instead of "4 GiB".

These prefixes were invented to resolve an ambiguity in a specific context. It's not like people will start talking about "kibimeters" anytime soon.

[amyk]

I prefer the usual SI prefices with the understanding that memory is measured in powers of 2 instead of 10, the "binary prefices" just sound silly and almost no one uses them...

[Monkeh]

I prefer the usual SI prefices with the understanding that memory is measured in powers of 2 instead of 10, the "binary prefices" just sound silly and almost no one uses them...

So where else are we going to add the 'understanding' that the prefix no longer means what it is meant to mean?

[IanB]

Nothing is meant to mean anything. The English language is generally descriptive, not prescriptive. If common usage describes 1024 bytes as one kilobyte, then that is what it is. Since nobody in computer science (except disk drive manufacturers, bless them) thinks that one kilobyte is 1000 bytes, then no ambiguity arises. I know without ambiguity that 1 km is 1000 m and that 1 KB is 1024 bytes. Similarly I know that 1 MB is 1024 KB.

[alm]

Quiz: how long does it take to transfer a 1 TiB (8 Tibits) file over a gigabit ethernet connection assuming no overhead? Answer: about 1100 8800 seconds, not 8000, since network bandwidth is also measured in base 10. Memory size is about the only thing always measured in base 2, and for some reason early OS developers thought it was a good idea to extend this to file size since base 2 calculations are faster on binary computers. Disk size, network bandwidth, memory bus bandwidth, etc are all base 10. How long can a scope sample at 1 GS/s if it has 1 Mpts of memory?

So no, it's not obvious from context how large a 500 GB partition on a 1 TB drive is. Is that 50% or 55% of the total size of the drive?

[IanB]

So how can we get people to describe disk size, network bandwidth, memory bus bandwidth etc. properly, instead of using this silly base 10 nonsense?

[alm]

931Mbit/s ethernet doesn't sound as nice, for starters. It's not like they only started using base 10 recently, it's just that CS people have been sloppy in this regard by mixing base 2 and base 10. Historically they could get away with it since the difference between 1 kB and 1 kiB is only 2.4%, but differences get larger now we're talking about TBytes and up.

Your 1 GS/s scope doesn't sample at 1 GiS/s. And neither does that 3 GHz CPU run at 3 GiHz or your DDR3-1600 memory at 200 MiHz, which means any multiple of this frequency (eg. bandwidth, FLOPS) is also going to be base 10. So you'll always have an overlap area where base 2 and base 10 are both used. Wouldn't it make sense to distinguish these somehow? And no, you're not going to get the rest of the world to change their definition of the km, kg and kV just to make life easier for computer memory makers.

[IanB]

Powers of 2 only need to be used when measuring bits. So 1 Kb/s is 1024 bits per second, but 1 kHz is 1000 Hz. I have no reason to be confused about my scope sample rate or CPU frequency since neither is a measure of bits or bits per second.

I didn't know ethernet bit rates were not what they claimed to be, but thanks for letting me know. I have just lost a bit more respect for computer industry marketing people.

[Monkeh]

I didn't know ethernet bit rates were not what they claimed to be, but thanks for letting me know. I have just lost a bit more respect for computer industry marketing people.

 

[nitro2k01]

Quiz: how long does it take to transfer a 1 TiB file over a gigabit ethernet connection assuming no overhead? Answer: about 1100 seconds, since network bandwidth is also measured in base 10.

Incorrect. You confused bit and bytes.
A 1 TiB file is 1024^4=1,099,511,627,776 bytes.
A gigabit connection can transfer (again assuming no overhead) 1,000,000,000 bits, or 125,000,000 bytes per second.
So the answer is 1,099,511,627,776 / 125,000,000 =  ~8796 seconds

Powers of 2 only need to be used when measuring bits. So 1 Kb/s is 1024 bits per second, but 1 kHz is 1000 Hz. I have no reason to be confused about my scope sample rate or CPU frequency since neither is a measure of bits or bits per second.

Incorrect. (Data) bits have nothing to do with it per se. Ethernet is using bit rates based on base 10, so there nothing in that particular example that warrants use of base 2, per se.

Where base 2 comes from is the physical layout of memory chips. You have an array of memory locations with a number of rows and number of columns which will both be a power of 2. This follow naturally from the way the address lines are used. A number of address bits (n) will be fed into a demultiplexer which will output one of 2^n rows or columns. There is no such "intrinsic reason" to use binary prefixes in the example "1024 bits per second". 1024 is just an arbitrary data rate. The array size of solid state memories is not arbitrary, but by design.

Just to be clear, I wouldn't want to force anyone to use binary prefixes. What I would encourage people to do is use whatever prefixes they use correctly. k, M, G, T are base 10 prefixes, period. If you use them for RAM, you ought use them correctly and say for example "4.3 GB", as described in my previous post.

Historically they could get away with it since the difference between 1 kB and 1 kiB is only 2.4%, but differences get larger now we're talking about TBytes and up.

This is an important point. For those may not get it, the difference between the binary and decimal prefixes increase for the bigger prefixes, since it accumulates for every multiplication by 1024.
ki = 1024 -> 2.4% difference
Mi = 1048576 -> 4.9% difference
Gi = 1073741824 -> 7.4% difference
Ti = 1099511627776 -> 10% difference

And it grows - no joke - exponentially.

[alm]

Incorrect. You confused bit and bytes.

Doh! Editted.

Powers of 2 only need to be used when measuring bits. So 1 Kb/s is 1024 bits per second, but 1 kHz is 1000 Hz. I have no reason to be confused about my scope sample rate or CPU frequency since neither is a measure of bits or bits per second.

The problem is that bytes often get multiplied by clock rates. For example sampling at 1 GS/s in single (8-bit) channel mode for 1 second will produce 953 MiB of data. Filling up 6400 MiB of memory via the DDR2-800 memory bus, which is 64 bits wide and runs at 800 MT/s, giving it a bandwidth of 6400 MB/s, takes 1.05 seconds. All very clear and consistent; not at all a mess.

[Kjelt]

This really annoys the hell out of me. I guess I'll just ignore it.

That,s exactly the mentality why we got in this predicament in th efirst place.
Oh yeah lets ignore it nobody is going to notice.
Now hdd manufacturers  had lawsuits because their stated capacity on hdd,s was too low, while in reality they were the only ones doing it right. Oh well since a lot of people don,t even want the SI in this world go and make you,re own standard, or MEBI thats not such a good idea?

[apelly]

Are these formatted sizes?

[TMM]

Are these formatted sizes?

No, they are exactly the same size, just different units. Like Kilograms and Pounds... e.g. A 1TB harddrive is 931GiB whether it is formatted or not.

Now hdd manufacturers  had lawsuits because their stated capacity on hdd,s was too low, while in reality they were the only ones doing it right. Oh well since a lot of people don,t even want the SI in this world go and make you,re own standard, or MEBI thats not such a good idea?

Everyone should sue Microsoft for having Windows count everything in powers of two and display SI prefixes. Linux displays the correct prefixes.

[c4757p]

Are these formatted sizes?

There is no such thing as a "formatted size". Your 500 GB hard drive holds 500 GB exactly (once you define what a GB is). The fact that the operating system puts tables of contents into it is no fault of the hard drive (and will vary from system to system depending on configuration, anyway, so it's futile to list). Trying to list a "formatted size" of a hard drive is like trying to list a "printed size" of a piece of paper, accounting for margins.

[AndrejaKo]

Interesting that nobody mentioned the dreaded 1.44 MB floppy yet! The size was derived by mixing binary and decimal prefixes, so we have formatted capacity of 1440 KiB, which we divided with 1000 to get 1.44 kKiB.

[rr100]

Yea, the floppy was interesting!
With the CDs they went to full binary (MiB) and then with the DVDs to full decimal I think. Nowadays also the USB sticks (especially the bigger capacities) are decimal (of course, why should they give you extra capacity for free).

I never understood the tenacity of non-technical people towards the binary prefixes. More scientifically oriented people usually can't conceive that 1 GX/GY can mean anything than 1 X/Y, instead of 0.931322574615478515625 X/Y or 1073741824 X/Y. But for laymen I think they feel there's something special and surprising knowing what they learned once that sometimes K mean 1024 instead of 1000 and they don't want to let it go. However it is extremely detrimental for any practical purpose to have those non-decimal units because is just hard to convert between them without a calculator. If you have 40GB (decimal GB) left on a disc and you need to write on it 41 234 567 890 bytes (which is how the info is presented sometimes) then you know, you just can't write them. However if you have 40 GiB space then you'll be able to fit those 41 234 567 890 bytes and have some extra space. But you certainly can't tell immediately unless you're pretty good at this already.

[nitro2k01]

There is no such thing as a "formatted size". Your 500 GB hard drive holds 500 GB exactly (once you define what a GB is). The fact that the operating system puts tables of contents into it is no fault of the hard drive (and will vary from system to system depending on configuration, anyway, so it's futile to list). Trying to list a "formatted size" of a hard drive is like trying to list a "printed size" of a piece of paper, accounting for margins.

The overhead is actually quite predictable given a certain disk size and file system. And in particular, what formatted size usually refers to in this context is the advertised size on the packaging. Many manufacturers print both the total and formatted size on the packaging, because this is required by consumer protection laws in some places. Hopefully they have enough quality control to predict the formatted size of the particular drives that they are shipping.

[Kjelt]

However it is extremely detrimental for any practical purpose to have those non-decimal units because is just hard to convert between them without a calculator. If you have 40GB (decimal GB) left on a disc and you need to write on it 41 234 567 890 bytes (which is how the info is presented sometimes) then you know, you just can't write them. However if you have 40 GiB space then you'll be able to fit those 41 234 567 890 bytes and have some extra space. But you certainly can't tell immediately unless you're pretty good at this already.

What's wrong with just letting the computer take care of this, it will tell you within a us if it fits or not. Because what you are suggesting means in fact that we should abandon the binary system al together and switch computerscience into a decimal system since humans are not great in binary arithmetic.  Oh but wait is this not why we invented the computer to take care of some hard mathematical problems in the first place 

[rr100]

I am not suggesting anything, this is in your imagination.
I just said that it is not good to have to reach for a calculator for the most simple things, if you like to do it anyway feel free.

[sync]

What's wrong with just letting the computer take care of this, it will tell you within a us if it fits or not. Because what you are suggesting means in fact that we should abandon the binary system al together and switch computerscience into a decimal system since humans are not great in binary arithmetic.  Oh but wait is this not why we invented the computer to take care of some hard mathematical problems in the first place 

Yes, CS should switch to decimal SI prefixes. They are used for representation to humans and humans can easily multiply or divide by 1000 but not with 1024. I really hate it to use a calculator to convert file sizes from GiBs to bytes.

Bit and byte should become SI units. Then this bullshit ends.

[IanB]

Bit and byte should become SI units. Then this bullshit ends.

But bits and bytes are not decimal. A long time ago industry settled on a convention of 8 bits to a byte rather than, say, 10 bits to a byte, and so there will never be a base 10 scaling between megabits and megabytes.

The problem of remaining disk space mentioned above would not require a calculator if all capacities were quoted in 2-based arithmetic. For instance if you had 40 GB free on your disk the system could say "41,943,040 KB free, 41,956,352 KB to be written". You can immediately see that the data won't fit.

Are we really suggesting that disks should have 500 byte logical sectors, rather than the 512 byte sectors they have now? (Or 4096 byte--4 KB--sectors on newer disks.) It's most efficient of course to transfer data to and from disks (or across the wire) in units aligning with the size of memory pages. There is no reason other than marketing that disks have 1024 byte kilobytes, but 1,000,000 byte megabytes.

Microsoft apparently agrees with this.

[rr100]

a. you are wrong, a byte isn't always 8 bits
b. even if it would be there is no reason why this should translate to the representation of some units to humans. Science doesn't work particularly better if we use some prefixes instead of others, we could as well use the full numbers or some exponential notation but when we chose some notation we'd better make it easier on ourselves and have it straightforward (as in not having to take out the calculator to find out how much is 17GB in KB) and consistent (as in meaning the same without having to guess the context, with the bonus that mathematics still works as expected, as in you can simplify k/k without any complications)
c. with all the ECC and spare sectors we are very far from any "natural" powers of 2. I don't think there's any hard drive on the market that has a capacity an integer number of GiB, never mind TiB. In any case I don't understand why all the arguments that we will give up computer science or that we would be making things extremely inefficient by displaying (because this is what we're talking about) some value divided by 1000 instead of 1024.

[Kjelt]

I just said that it is not good to have to reach for a calculator for the most simple things, if you like to do it anyway feel free.

Then I have misread your post.
Still your example is flawed IMO, if you want to write 41 234 567 890 bytes then you still miss a lot of information. How many files, which filesystem, how was it formatted (which allocation unit size / how many bytes overhead per file) etc.
No computer user is ever going calculate this (perhaps as a theoretical example in class but not on a daily basis as a user) , he/she is just simply going to start the copy process and let the computer find out if it fits or not. And if it is a smart computer with a smart OS it is going to tell you that right away.

[rr100]

@IanB:
And now that I think even more I really don't get how the fact that because there are (usually) "8 bits to a byte rather than, say, 10 bits to a byte, and so there will never be a base 10 scaling between megabits and megabytes"

10^3 is 1000 yes, but 8^3=512 ! So what is in your mind the algorithm that makes 8 to 1024 what 10 is to 1000 ?

[rr100]

Still your example is flawed IMO, if you want to write 41 234 567 890 bytes then you still miss a lot of information. How many files, which filesystem, how was it formatted (which allocation unit size / how many bytes overhead per file) etc.

It doesn't matter, it can be even one file. The point is that it's ridiculos to not be able to make immediate calculations between prefixes. Ultra-simple example, if you would have the same non-sense in EE. You measure a resistor, it's supposed to have 14.7 KOhm (and let's say it's the binary K, called nowadays Ki). It shows on the multimeter 15000.0 ohm. Now, QUICK, is this more or less than 14.7K(i) ?

[marshallh]

Why stop there? You know, a "byte" actually can mean anything! even 9 bits! So let's take things to their logical conclusions

I propose the following:
1. New unit: "butts" for explicit denotation of 8 bits, assuming a bit can be on or off, and meaning the same as an octal;
2. New postfix: "poop" to denote power of 2 numbers instead of decimal.

Example:
megapoopbutts - 1048576 sets of 8 bits
gigapoopbutts - 1073741824 sets of 8 bits

Yes, that is how stupid this "mibibyte" crap sounds like. And now it's infecting the rest of wikipedia.

[rr100]

We already have a unit for 8 bits, it's called octet.

These discussions with kilo=1024 and byte=always 8 bits are fine, just like using "Xerox" for anything. Everybody understands what you mean and it doesn't matter, until it does.

[IanB]

a. you are wrong, a byte isn't always 8 bits

If I said a byte is always 8 bits I would indeed be wrong. But I didn't say that, so I'm not.

[rr100]

Can you elaborate on the more interesting point and tell us how is 1024 to 8 as 1000 is to 10 ?

[sync]

The problem of remaining disk space mentioned above would not require a calculator if all capacities were quoted in 2-based arithmetic. For instance if you had 40 GB free on your disk the system could say "41,943,040 KB free, 41,956,352 KB to be written". You can immediately see that the data won't fit.

That is a good example why the binary prefixes are bad for presentation to humans.
The OS show 40.0GB free not 41943040KB. So I have to use a calculator.

With decimal prefixes this is easy. 40GB are 40000000KB. No need to calculate.

And the sole purpose of the prefixes are to present a big (or small) value in a convenient format to humans. Computers don't know and work with Kilo, Mega, etc internally.

Are we really suggesting that disks should have 500 byte logical sectors, rather than the 512 byte sectors they have now? (Or 4096 byte--4 KB--sectors on newer disks.) It's most efficient of course to transfer data to and from disks (or across the wire) in units aligning with the size of memory pages. There is no reason other than marketing that disks have 1024 byte kilobytes, but 1,000,000 byte megabytes.

That's not the point. It's about the usage of prefixes. And they should be decimal based. Except for the few cases when there is a physically defined power of two value, e.g. page sizes, raw solid state memory, ... For this use KiB, etc.
But disk and file sizes are not defined by power of twos. So it makes no sense to use binary prefixes. And disks sizes traditionally uses decimal prefixes. I saw a disk specification from 1960ies with uses 1 kiloword = 1000 words. Bandwidth also uses decimal prefixes. In the today computer world a MB is not equal a MB!

Microsoft apparently agrees with this.

Microsoft is the authority of truth?
I found a few totally wrong claims on support.microsoft.com.

[IanB]

That is a good example why the binary prefixes are bad for presentation to humans.
The OS show 40.0GB free not 41943040KB. So I have to use a calculator.

With decimal prefixes this is easy. 40GB are 40000000KB. No need to calculate.

And the sole purpose of the prefixes are to present a big (or small) value in a convenient format to humans. Computers don't know and work with Kilo, Mega, etc internally.

There I think the answer is simple. Measure in bits rather than bytes and use the decimal prefixes for bits as has always been done in communications contexts (modems and network links).

1 kb = 1000 bits. 1 kb/s = 1000 bits per second.

Similarly 1 Mb = 10^6 bits; 1 Gb = 10^9 bits, and so on.

Now your 40 GB becomes ~340 Gb (343.597 Gb). All nice and decimal.

[Kjelt]

That is a good example why the binary prefixes are bad for presentation to humans.
The OS show 40.0GB free not 41943040KB. So I have to use a calculator.

I think you need another OS see picture.

[sync]

Now your 40 GB becomes ~340 Gb (343.597 Gb). All nice and decimal.

Great! Now a byte is 8.58993 bits.

[Kjelt]

It doesn't matter, it can be even one file. The point is that it's ridiculos to not be able to make immediate calculations between prefixes. Ultra-simple example, if you would have the same non-sense in EE. You measure a resistor, it's supposed to have 14.7 KOhm (and let's say it's the binary K, called nowadays Ki). It shows on the multimeter 15000.0 ohm. Now, QUICK, is this more or less than 14.7K(i) ?

Your example is besides the point since it is a decimal system example. It is not logical to use binary prefixes in a decimal system.
And that is exactly the truth the other way around, it makes no logical sense to use decimal prefixes in a binary based value system 

[sync]

And that is exactly the truth the other way around, it makes no logical sense to use decimal prefixes in a binary based value system 

Right! But i never saw a prefix on a binary value. I saw 35KB but never 0b100011KB. And the 35 is decimal.

[Kjelt]

Right! But i never saw a prefix on a binary value. I saw 35KB but never 0b100011KB. And the 35 is decimal.

I am getting confused now, your point is that in a binary based value system one shall not use decimal or hexadecimal notation for values? Hmmm 

Well the kilo is actually a decimal based power factor of 3 (10³) and if you look at it in that way I agree and it should be limited to decimal systems.
A KiB is then very confusing since it has a totally different power factor of 10 (2¹⁰).
If you look at it in that (mathematical) way 1kB should be 8 bytes (2³)   

[rr100]

That is a good example why the binary prefixes are bad for presentation to humans.
The OS show 40.0GB free not 41943040KB. So I have to use a calculator.

I think you need another OS see picture.

Now you think you have the hole picture? Think again. It shows 67 935 817 728 and 63.3 GB. Is this more or less than 100 x 650 MB CDs?
It is MUCH trickier than it seems. First you need to decide "which G" and "which M". For G it's clearly not the decimal one but you can't be sure without a calculator what "G" it is. Maybe it is 1000x1024x1024? Or 1000x1000x1024? It can happen, if it did to floppies why not to explorer? Anyway it is pretty pointless already to need the full value because you can't decide from the GB what it's supposed to mean. But let's move to the MB. Start researching wikipedia, etc. What is the M prefix used for CDs? Ok, we decide it's in fact Mi (1024x1024) and NOW we can start to compare. Oh, it's not that simple even with all data. 1024x1024x6500 versus 67 935 817 728 (which is the same as 63.3 Gi). Who wins?

Anyway whole discussion is kind of pointless. Usually there isn't any reason to use binary prefixes (especially in all things people usually use, like disk size, free space, file size, etc) but sometimes there is (for example when you want to be both precise and concise, like "this tool will align the partition at 1MiB"); anyway when there is such reason you can just use the complete an unambiguous notation, with that "i", it can't be that hard.

[Kjelt]

Now you think you have the hole picture? Think again.

I agree the decimal based prefixes should be banned from binary systems 

[IanB]

Now you think you have the hole picture? Think again. It shows 67 935 817 728 and 63.3 GB. Is this more or less than 100 x 650 MB CDs?

If you ever consider writing 63 GB of data to ~100 CDs you have bigger problems than arithmetic... 

[sync]

Right! But i never saw a prefix on a binary value. I saw 35KB but never 0b100011KB. And the 35 is decimal.

I am getting confused now, your point is that in a binary based value system one shall not use decimal or hexadecimal notation for values? Hmmm 

What do you mean with a binary based system?
Do you mean stored as binary values or based on power of two values?
Disk and files sizes are the former but not the latter.

[rr100]

Now you think you have the hole picture? Think again.

I agree the decimal based prefixes should be banned from binary systems 

I think in my somehow meandering post you missed this part: it's not that simple even with all data. 1024x1024x6500 versus 67 935 817 728 (which is the same as 63.3 Gi). Who wins?
You still have this problem even if everything is "binary".

[dfmischler]

Where base 2 comes from is the physical layout of memory chips.

No.  The use of powers of 2 in sizes predates the existence of integrated circuits of any type.  It comes from addressing memory (of any type) using binary address values, and making all addresses usable.

Decimal computers were tried in the dark ages of computing, but it was quickly determined that this is not a very efficient use of hardware resources.

Software allocates disk space by the sector (or clusters of sectors), each of which is generally 512 or 4096 bytes (although I recall a brain-dead TI system that made them 288).  So the disk manufacturers are starting with binary sizes, but want to market in decimal sizes (because they sound bigger).  Do not even think about changing disk drives to use decimal sector sizes or the software guys will go on strike (e.g. 4 KiB pages can be easily mapped to disk sectors for virtual memory purposes).

We're not going to stop addressing memory with binary values, and telecomm bit rates have always been decimal.  And who wants to confuse all the poor folks who have to actually weigh and measure things?  So learn and use the "new" binary prefixes and kwitcherbitchin.

[sync]

Software allocates disk space by the sector (or clusters of sectors), each of which is generally 512 or 4096 bytes (although I recall a brain-dead TI system that made them 288).  So the disk manufacturers are starting with binary sizes, but want to market in decimal sizes (because they sound bigger).  Do not even think about changing disk drives to use decimal sector sizes or the software guys will go on strike (e.g. 4 KiB pages can be easily mapped to disk sectors for virtual memory purposes).

Even today there are disks which can be formatted to a non power of two sector size, eg. 524 bytes (http://www.seagate.com/files/www-content/product-content/savvio-fam/enterprise-performance-15k-hdd/savvio-15k-4/en-us/docs/100721324b.pdf). Of course only 512 bytes are used for the real data and the rest for meta data.

[dfmischler]

Even today there are disks which can be formatted to a non power of two sector size, eg. 524 bytes (http://www.seagate.com/files/www-content/product-content/savvio-fam/enterprise-performance-15k-hdd/savvio-15k-4/en-us/docs/100721324b.pdf). Of course only 512 bytes are used for the real data and the rest for meta data.

Yes, but as I said there is not a virtual memory operating system on the planet that would be happy with non-binary sector sizes.  This includes Linux, BSD, MacOS X, and even Windows.  To say nothing of whatever legacy operating systems might still be in use hiding under a rock (or a mainframe).

Disk sectors are memory, and memory needs to be addressed with binary addresses and so should have binary sizes.  Don't fight it, you'll just hurt yourself.

[sync]

The non power of two sector size are used in high end storage systems. These uses the extra bytes for internal purposes. The computer operating system sees only 512 or 4096 byte blocks.

But there is no good reason to use binary prefixes for disk sizes.

[Stonent]

Too many people complained that their 500GB drives were only 488GB so now they tend to specify in both on the boxes.

[dfmischler]

But there is no good reason to use binary prefixes for disk sizes.

Agreed.

These units make the speaker sound like a gibbering idiot. 

So don't say them.  If you say, "1 gig ethernet" nobody is confused (decimal).  If you say, "That computer has 16 gigs of RAM" everybody should assume that is 16GiB: 16*1024*1024*1024.  Disk drive sizes are now generally assumed to be decimal.  The most ambiguous case is for a file, but as far as I know all operating systems report binary sizes.  So for, "This file is 15 meg" everybody should realize that is 15MiB: 15*1024*1024.  And they can ask you if they are in doubt.

[c4757p]

There is no such thing as a "formatted size". Your 500 GB hard drive holds 500 GB exactly (once you define what a GB is). The fact that the operating system puts tables of contents into it is no fault of the hard drive (and will vary from system to system depending on configuration, anyway, so it's futile to list). Trying to list a "formatted size" of a hard drive is like trying to list a "printed size" of a piece of paper, accounting for margins.

The overhead is actually quite predictable given a certain disk size and file system. And in particular, what formatted size usually refers to in this context is the advertised size on the packaging. Many manufacturers print both the total and formatted size on the packaging, because this is required by consumer protection laws in some places. Hopefully they have enough quality control to predict the formatted size of the particular drives that they are shipping.

The available space on a piece of paper is quite predictable as well, considering most word processing software uses the same default margin sizes, but we've decided as a society that people aren't so brain-dead as to not understand that the margins will use a bit of the paper. Nobody is enough of a dumbass to come into a store furious that he could only print  6.5x9 inches on his 8.5x11-inch paper. How about we stop treating computer users like kindergartners?

[baljemmett]

Too many people complained that their 500GB drives were only 488MB so now they tend to specify in both on the boxes.

To be fair, I'd be pretty pissed off in that case too.  A thousand-fold discrepancy is pretty harsh, regardless of whether that's a decimal or a binary thousand

[sync]

The most ambiguous case is for a file, but as far as I know all operating systems report binary sizes.  So for, "This file is 15 meg" everybody should realize that is 15MiB: 15*1024*1024.  And they can ask you if they are in doubt.

And that for a value which has a granularity of 1 byte. It's just idiotic to use binary prefixes for file sizes. IFIAK Apple has changed to decimal prefixes.

[alm]

Clearly both base 2 and base 10 prefixes are commonly used for bytes, so it makes sense to distinguish them if we want to specify numbers with less than 10% uncertainty. Since base 10 prefixes pre-date the binary prefixes by about a century and are common both in CS and in other engineering disciplines, I think it would make sense to change the base 2 prefixes. If you think 'kibibytes' sounds stupid, feel free to convince the IEC to change the standard, pronounce it as 'kay eye bytes' or just avoid using base 2 prefixes all together. In the mean time, using TB and TiB will allow us to specify file and disk sizes without guesswork.

[Stonent]

Too many people complained that their 500GB drives were only 488MB so now they tend to specify in both on the boxes.

To be fair, I'd be pretty pissed off in that case too.  A thousand-fold discrepancy is pretty harsh, regardless of whether that's a decimal or a binary thousand

DERP! I was writing from my phone.

[johnwa]

I used to be quite against the new prefixes, seeing them accommodating the 'evil' HDD manufacturers in their attempts to short-change their customers. However, when you look into it, decimal prefixes are already used in some applications - a 28.8kbps modem = 28000 bits/second (forgetting about compression for now). And I realised that attempting to bend the metric prefixes into something that they are not would only result in confusion.

While the prefixes may sound a bit funny initially, their real value is that they allow unambiguous communication. If your meaning is 1048576 bytes, then the only way to communicate this unambiguously, other than writing it out in full, is to say 1MiB. It didn't really take long for me to go from hearing "mebibyte" and thinking "the speaker is a fool", to hearing it and thinking "the speaker values precision and clarity". A lot of programs are starting to use the new prefixes, so it seems that support for them is growing.

[rr100]

Speaking about greedy hard drive manufacturers: I think this part of the issue is exaggerated. Capacities were increasing all the time and still are, we just go the first 2TB "normal size" laptop drive (as in no thicker). Each time they go up one prefix they go up 1000 times (that's 100 000%) and we bicker about losing 2.4% ?! The difference is absolutely staggering, even across multiple prefixes and starting with 2 handicap (K and M) if you take from 10 MB to 3TB for example, that's 300 000 times increase (or if you want 30 000 000%). And we bicker about 10% for Ti vesus T.

The only part where it matters is consistency. If some manufacturer sold a 0.90TB drive and one a 1.0TB drive and have in fact the same capacity, now that would obviously suck for the manufacturer advertising 0.9.

[IanB]

While the prefixes may sound a bit funny initially, their real value is that they allow unambiguous communication.

Unfortunately, they don't succeed even in this. If you write 1 MB I still don't know whether you mean 1,048,576 bytes or 1,000,000 bytes. You still have to disambiguate by providing extra commentary ("1 MB, where M means one million decimal"). Without commentary, I would follow the normal practice of computer science and assume 1024 KB.

[Kjelt]

I would follow the normal practice of computer science and assume 1024 KB.

and what is a KB? Oh you mean kB. You are messing up the prefixes and expect other people to know what you mean? That is exactly why I think it is important to have the new binary prefixes. k means 1000, M means a million PERIOD. not 1024 or 1024*1024.

[westfw]

If you write 1 MB I still don't know whether you mean 1,048,576 bytes or 1,000,000 bytes.

Or maybe bits rather than bytes.

But it's hopeless; the binary "prefixes" are born out of laziness rather than any serious attempt at a meaningful prefix definition.  The roots are back in "Microsoft 4k basic", and "16k S100 memory boards"; there wasn't even a UNIT!

[rr100]

And this is precisely the thinking that created this mess ot of nothing.

[Kjelt]

Indeed, we have a perfect SI prefix system where k (not K  ) is a 1000 but when at a sudden we step into the CS dimension it needs to be something different because some dumbo's in the 70's made that mistake? Naaah mistakes are there to be corrected, people should adapt and move on.
Another generation and no-one will know about this fluke anymore.

[Fsck]

the more amusing thing is that *nix have *iB units
so apparently not all CS are weird

[dfmischler]

the more amusing thing is that *nix have *iB units

Well, some unix/linux systems are using *iB, in some places.  It has not fully penetrated yet.

... into the CS dimension it needs to be something different because some dumbo's in the 70's made that mistake?

"The use of K in the binary sense as in a "32K core" meaning 32×1024, or 32768, can be found as early as 1959."  I don't think it was a mistake to use "K" to mean 1024 in that context at that time.  Thank Dog they didn't use Latin prefixes (e.g. M for 1000, still on my natural gas bill as in "Mcf" for 1000 cubic feet).  That would have been a nightmare 

[amyk]

The only part where it matters is consistency. If some manufacturer sold a 0.90TB drive and one a 1.0TB drive and have in fact the same capacity, now that would obviously suck for the manufacturer advertising 0.9.

Another inconsistency that has always annoyed me about hard drive sizes is that they still need to be an integral multiple of 512 (2^9 aka 0.5K), the sector size. HDD manufacturers should start making "real-sized" drives; if they can make a "2TB" one that shows up as a little less than 1.86TB to the OS, they clearly have the technology to make a "1TB" one that contains exactly 2^40 = 1,099,511,627,776 bytes and shows up as 1.0TB. Then market it as a "REAL ONE TERABYTE" drive!

I still have a 16MB(!) USB drive that really does have a capacity of 16,777,216 bytes, or 8192 sectors.

Regarding communication speeds: again, I've only seen the binary sizes used in things like download progress bars and the like, so it's consistent with the rest of the presentation of sizes in the OS.

[rr100]

I very much prefer a 1.86 TiB drive to a hypothetical 1.0000000000000 TiB drive, thank you.

[sync]

The only part where it matters is consistency. If some manufacturer sold a 0.90TB drive and one a 1.0TB drive and have in fact the same capacity, now that would obviously suck for the manufacturer advertising 0.9.

Another inconsistency that has always annoyed me about hard drive sizes is that they still need to be an integral multiple of 512 (2^9 aka 0.5K), the sector size. HDD manufacturers should start making "real-sized" drives; if they can make a "2TB" one that shows up as a little less than 1.86TB to the OS, they clearly have the technology to make a "1TB" one that contains exactly 2^40 = 1,099,511,627,776 bytes and shows up as 1.0TB. Then market it as a "REAL ONE TERABYTE" drive!

It's not the hard drive manufactures fault. They are real 1 terabytes disks. It's the OS fault displaying the wrong value/ units.

[ovnr]

I've always used the traditional k/M/G prefixes (that is, 1024^n) for CS-related things. I'm not going to start using Mebibytes because it's fucking stupid, and the morons who decided it's a good idea are nuts.

If you cannot deal with the fact that some symbols and prefixes change meaning when changing technical fields, please find something else to do, like knitting. Because god help you if you ever start doing serious math or physics.

No, when I see people use kiBs and GiBs, I laugh at it, because you're a sheep going "baaa" at whatever you're told. Fucking stupid if you ask me.

[c4757p]

No, when I see people use kiBs and GiBs, I laugh at it, because you're a sheep going "baaa" at whatever you're told. Fucking stupid if you ask me.

Oh god. Another dude who thinks it's cool to call people sheep.

Sure, you might be a sheep doing whatever your told. Or, you think it's a good idea for the same reasons as the people who came up with it.

[Monkeh]

No, when I see people use kiBs and GiBs, I laugh at it, because you're a sheep going "baaa" at whatever you're told. Fucking stupid if you ask me.

Why thank you, would you care to insult us some more for being precise and sane?

[sync]

I've always used the traditional k/M/G prefixes (that is, 1024^n) for CS-related things. I'm not going to start using Mebibytes because it's fucking stupid, and the morons who decided it's a good idea are nuts.

Do you use 1024 based prefixes for bandwidths too?

[Kjelt]

I'm not going to start using Mebibytes because it's fucking stupid, and the morons who decided it's a good idea are nuts.
If you cannot deal with the fact that some symbols and prefixes change meaning when changing technical fields, please find something else to do, like knitting. Because god help you if you ever start doing serious math or physics.

It were the scientists and serious ones too who decided to introduce the binary prefixes because there was confusion in the world. And if you are a serious scientist and practitioner there is one thing you do not want and that is that something that has the same name has a different meaning depending on the context.
So give us a good example of serious mathematics or physics where the same prefix has a totally different value?

[IanB]

and what is a KB? Oh you mean kB

No, I mean KB. With an upper case K. As in 1024 bytes. As is the normal typographic convention for that quantity of bytes   

[Monkeh]

and what is a KB? Oh you mean kB

No, I mean KB. With an upper case K. As in 1024 bytes. As is the normal typographic convention for that quantity of bytes   

Only amongst those who don't know what K is.

[IanB]

So give us a good example of serious mathematics or physics where the same prefix has a totally different value?

In US engineering the unit MMBtu/hr means one million Btu's per hour. A single M in front of a unit is a thousands multiplier, so MM is thousand thousand, or million, as in MMbbl/d. (M comes from the Latin mille, meaning thousand.)

[Kjelt]

and what is a KB? Oh you mean kB

No, I mean KB. With an upper case K. As in 1024 bytes. As is the normal typographic convention for that quantity of bytes   

Ah you mean the JEDEC standard, yeah gotcha, but not the normal convention anymore since the JEDEC spec is not fully SI compliant anymore, K is still OK but the M and G are obsolete:
The International Bureau of Weights and Measures (BIPM), which maintains the International System of Units (SI), expressly prohibits the use of SI prefixes to denote binary multiples, and recommends the use of the IEC prefixes as an alternative since units of information are not included in SI.

[Kjelt]

In US engineering the unit MMBtu/hr means one million Btu's per hour. A single M in front of a unit is a thousands multiplier, so MM is thousand thousand, or million, as in MMbbl/d. (M comes from the Latin mille, meaning thousand.)

Sorry but that is outside the SI standard, other topic about metric vs imperial. Same with the US AWG, how strange is that calling the biggest diameter the lowest number and when you ran out of numbers at 0 just add more 0's.
Do you call that serious science? 

[IanB]

Ah you mean the JEDEC standard, yeah gotcha, but not the normal convention anymore since the JEDEC spec is not fully SI compliant anymore, K is still OK but the M and G are obsolete

No, I don't mean the JEDEC standard. Neither do I mean SI, since, as your following link points out SI prefixes are not used for data in computer science.

What I mean is that in computer science a kilobyte is written as KB and not as kB.

[Kjelt]

What I mean is that in computer science a kilobyte is written as KB and not as kB.

On what planet? 

[Kjelt]

Darn Ok i give in, I just saw that one of my bibles (Computer Architecture a quantitive approach from Hennesy & Patterson) do use the term KB in one of their tables 
I am sad now 

[IanB]

Darn Ok i give in, I just saw that one of my bibles (Computer Architecture a quantitive approach from Hennesy & Patterson) do use the term KB in one of their tables 
I am sad now 

I do try to be very precise in what I write. If I make a mistake it will be a genuine error and not simple carelessness.

[Kjelt]

I do try to be very precise in what I write.

So would you consider switching to the unambiguous KiB and use that in the future?

[Monkeh]

I do try to be very precise in what I write.

So would you consider switching to the unambiguous KiB and use that in the future?

But KB, GB, and TB aren't ambiguous because he knows what they mean!

[Monkeh]

To complicate it even further, the Brits have used "billion" to mean a million million, or a trillion. 

And the French, Spanish, Germans, Finns, Danes, Poles, Swiss, Swedes, and many, many others still do use long scale.

[johnwa]

Oh dear, this is worse than a PIC vs AVR debate!

And, although I am a confirmed metric nazi, sometimes I think things would be a whole lot easier if we had all been born with 16 fingers...

[Kjelt]

The real problem is that everyone has been using kilobyte and KB to mean 1024 bytes for decades. If they had defined the new 1000 byte unit as a kibibyte there would have been no problem.

That is the same as saying we created a bug in the software code some years ago, let's adapt the requirements instead of fixing the bug 

[rr100]

The real problem is that everyone has been using kilobyte and KB to mean 1024 bytes for decades. If they had defined the new 1000 byte unit as a kibibyte there would have been no problem. All the existing literature and nomenclature would have stayed the same, and whenever anyone wrote "KiB" it would be very clear what they meant. Instead we now have some people using KB to mean kilobyte and some using KB to mean 1000 bytes.

There was no such thing as "if they have defined 1000 as kibi", we had in the metric system since year 1799 kilo as 1000. Of course many strange things happened but I think it would be quite implauzible and pointless to have both kilo and kibi define 1000.
kilo was chosen specifically because everybody knew it meant 1000. Otherwise they could've used something else and there is A LOT of "something else" out there that was in fact used, just some examples: sniff, crumb, quad, tayste, tydbit, nickel, decle, playte, chomp, dinner, goblle, octlet (not the same as octet), hexlet, tryte.
Now to complain that you used 1000 to mean about 1000 and usually 1024 and now you want 1000 to mean 1024 all the time it sounds pretty lame.
Even if we go now bananas and reverse the tables and use the "i" for the metric prefixes and replace all 1000 kilo with kibi and for example your car speedometer to read in kibimeters and your scope to be specified in mebiHerz STILL we won't solve the basic problem most people face. Namely they buy a 1TB or 1TiB drive or however you call the drive with 1000... bytes and then windows will show them it has 0.90 TB.

[dfmischler]

You guys don't get it.

Yeah.  I get it.  Change now rather than putting it off any longer.

What I'm saying is that we have been using kilobyte = 1024 for decades. Since the early days of computers memory was specified that way, early home machines came with a few kilobytes and then megabytes, and early hard disks used the power of 2 system as well.

So what?  There is essentially no confusion with main memory sizes.  And the divergence on a few megabytes is pretty insignificant.

Thanks to this stupid decision we will have confusion for all eternity as large numbers of people ignore the standard and vast quantities of old material are not re-written.

If the community adopts the (now 15 year old) "new" convention then peer pressure will make it work.  Don Knuth will probably fix his stuff if the community begs him adoringly (enough).  Hakmem and the like don't seem to have a problem.  Most young hackers don't seem to know about anything from before they were born, anyway.

[sync]

and early hard disks used the power of 2 system as well.

Which?
An ST-506 doesn't.

32 * 256 * 612 = 5013504
5 * (2^20) = 5242880

And hard disks from the 1960ies uses also 1M = 10^6.

[rr100]

What I'm saying is that we have been using kilobyte = 1024 for decades.

YEP, in SOME places SOME people were using kilo to mean 1024 for decades and YES, BECAUSE of that we have this confusion for decades (even the humble completely messed-up in terms of units "1.44" floppy is more than 25 years old).

If we take the "old" approach then kilo = 1000 is coming from late 1700's so much older than "decades". And no, having just a new unit doesn't justify having a new meaning for a prefix. We didn't have Ohm and Hertz when the prefix was invented but still we don't have 1 kOhm = 1234 Ohm or 1 kHz = 1012 kHz just because some calculation is easier. And again, just to see how stupid and pointless is the whole discussion: tell us again quickly how much would be a 14.7 kOhm rezistor in Ohms if the "k" would be 1024?

[westfw]

There is essentially no confusion with main memory sizes.

Sure there is.  The average computer user probably has no idea that their "GB" of memory is actually 2^30 bytes.
Nor do they care.  Nor do they need to care.

And the divergence on a few megabytes is pretty insignificant.

This too.   Even on a few TB.

No matter how it were done, most people would not be able to tell you how many 14Mpixel images will fit on a 4GB flash card...

[Monkeh]

so why not just make the base 10 units "kibibytes" and there would have been no confusion.

Because there would still be confusion, and quite simply, it is wrong.

[Tuomas]

so why not just make the base 10 units "kibibytes" and there would have been no confusion.

Because there would still be confusion, and quite simply, it is wrong.

Even if we would do that, it would just shift the problem. Then the networking guys would start complaining about how ridiculous Gibibit ethernet sounds along with a bunch of other protocols.

There are going to be pissed off people either way.

[rr100]

I also don't understand the fixation with the particular names. Oh, they're so funny, kibi-gibi, ha, ha. But we don't say them too often and most of the times we say it the difference doesn't matter, you can say anything. "I have only 10 gigs left, it won't fit"; there might be giga or gibi or whatever, it won't matter much anyway. If you give a presentation or a course an it really matters and you really can't say kibi you can put it in writing in the correct for with "i" and explain "that's the binary k" and then refer to it as "key" (spoken) and write "Ki".

But in writing and in programs there's no reason not to add that "i". Well, maybe in some very limited displays or interfaces you don't have the space but in general nothing except some misguided pride prevents you from just adding that "i" and squash all the ambiguity and be correct by any standard.

[rr100]

... to be replaced by?

[hammy]

Firstly when most technical people, especially digital electronics designers and programmers, say "meg" or "k" they mean megabytes and kilobytes, i.e. multiples of 1024 bytes.

I work in IT. The only people who use kibibytem, mebibyte (...) are nitpicker who have generally a problem with their communication skills because of their asperger syndrome.

If a programmer is not able to implement the correct code (k=1024 or k=1000) because someone had not said "kibibyte" than there is something more in disorder. How has he worked all the years before kibi and mibi was invented? 

Sorry for my rude german profanity.

[Kjelt]

I've got Atmel's latest XMEGA E5 datasheet in front of me and it talks about "32K flash"

32K flash?  That is not many times you can flash it then, because I now assume you are talking about the amount of times the flash memory can be flashed, other wise it would have been "32KB of flash memory" and according to the JEDEC spec it would be indeed 32*1024 bytes of memory.

[amyk]

I've got Atmel's latest XMEGA E5 datasheet in front of me and it talks about "32K flash"

32K flash?  That is not many times you can flash it then, because I now assume you are talking about the amount of times the flash memory can be flashed, other wise it would have been "32KB of flash memory" and according to the JEDEC spec it would be indeed 32*1024 bytes of memory.

...It seems you've never worked much in the industry? Those conventions have been around for decades.

[Monkeh]

Exactly. If you want 1000 bytes just say 1000 bytes. Kilobytes is already taken, sorry.

Kilo was already taken. A few centuries ago.

[hammy]

Kilo was already taken. A few centuries ago.

Yes, but in context with bytes ist is absolutely clear what kilobytes mean. If you work in this field it is clear what a byte is and what this means.
If you are a butcher you are maybe confused that a kilobyte on you harddisk is not the same like a kilogram meat. But when I buy meat I can also distinguish between 1000 gram meat and 1024 gram meat.

Sorry for my rude german profanity.

[Monkeh]

Kilo was already taken. A few centuries ago.

Yes, but in context with bytes ist is absolutely clear what kilobytes mean. If you work in this field it is clear what a byte is and what this means.

Really? Okay. 1kB. Do I mean 1000 bytes or 1024?

[alm]

Recent versions of MacOS X report decimal gigabytes. Most Linux desktops report in GiB or decimal GB. End users won't care and will report whatever the OS tells them, so if their OS switches, so will they. So it will mostly depends on whether MS is going to switch. I imagine some people are already getting support calls why their file that was 2 G(i)B on a Windows system is suddenly smaller on Macs.

[Monkeh]

Recent versions of MacOS X report decimal gigabytes. Most Linux desktops report in GiB or decimal GB. End users won't care and will report whatever the OS tells them, so if their OS switches, so will they. So it will mostly depends on whether MS is going to switch. I imagine some people are already getting support calls why their file that was 2 G(i)B on a Windows system is suddenly smaller on Macs.

It'd be really easy to switch, too. If Windows just used the appropriate prefix and added a little explanatory note, we'd be clear of the stupidity and confusion in what, 10 years?

Except for the obscenely stubborn ones, anyway.

[hammy]

Yes, but in context with bytes ist is absolutely clear what kilobytes mean. If you work in this field it is clear what a byte is and what this means.

Really? Okay. 1kB. Do I mean 1000 bytes or 1024?

In data transfer context you mean 1000 bit = 1 kilobit = 1 kB.
I had a apprenticeship as technician for information and communication technologies before my academic study. I also know this context. 

It's all about the context! I don't mix memory with data transfer or meat. 

Sorry for my rude german profanity.

[Monkeh]

Yes, but in context with bytes ist is absolutely clear what kilobytes mean. If you work in this field it is clear what a byte is and what this means.

Really? Okay. 1kB. Do I mean 1000 bytes or 1024?

In data transfer context you mean 1000 bit = 1 kilobit = 1 kB.
I had a apprenticeship as communication electronic technician before my academic study. I also know this context. 

I didn't say kb. I said kB. I actually meant kilobyte in the data transfer context, or 1000 bytes. So you figured out half the trap.

It's all about the context! I don't mix memory with data transfer or meat. 

But you do mix your bits and bytes and your kilo and kibi.

Stop being ridiculously stubborn, and learn to use prefixes appropriately. Before I start selling 850-gram kilos of sugar.

E: Wait, no, I can't do that, there are laws against that, it's usually referred to as fraud. Totally fine to misrepresent data, though, or you're just being nitpicky and have problems with your communication skills.

And now, back to actually working.

[Kjelt]

It seems you've never worked much in the industry? Those conventions have been around for decades.

Only about 16 years 
What conventions? To say something in the datasheet that is ambiguous and can mean a lot of other things then the writer intended, as I gave a clear example of?
At our company we have reviews of documentation and these sort of issues are addressed each time as soon as it can be read by different people in a different way so it could have a different meaning. If you specify an interface (like a protocol) better be 100% sure the specification is unambiguous or problems can will start.

[Kjelt]

In data transfer context you mean 1000 bit = 1 kilobit = 1 kB.

WHAT? Only in serial datatransfer you talk about bits and then you keep on talking about bits per second. As soon as you want to talk bytes you need to specify the transfer protocol , for simple serial: how many start, stop, parity bits, perhaps crc?

[hammy]

Stop being ridiculously stubborn, and learn to use prefixes appropriately. Before I start selling 850-gram kilos of sugar.
E: Wait, no, I can't do that, there are laws against that, it's usually referred to as fraud. Totally fine to misrepresent data, though, or you're just being nitpicky and have problems with your communication skills.
And now, back to actually working.

 

Right. Keep calm and solder on! 

[Monkeh]

It'd be really easy to switch, too. If Windows just used the appropriate prefix and added a little explanatory note, we'd be clear of the stupidity and confusion in what, 10 years?

It would cause all sorts of problems. For example software that parses printed output would suddenly fail. It's a stupid way of doing things but surprisingly common too. Even on Linux there is a configuration setting to fix the ls command's output back to "KB" instead of "KiB" so it doesn't break stuff.

Uh, no, ls does not print KB or KiB (or MB, MiB, GB, GiB, etc), and that's not how the options to ls work, either. It does differentiate between kilo and kibi by case, but the format does not allow for an extra character. Don't try these things with a sysadmin.

If you don't believe me take a look at this: http://www.zen134237.zen.co.uk/ Now realize there are millions of sites running similar software, and that's just web servers.

"Someone else does it wrong, so I should too!"

KiB = 1000 bytes, problem solved.

 

Really? Okay. 1kB. Do I mean 1000 bytes or 1024?

1024. If you meant anything else you made a mistake.

Here, enjoy your 1KG of sugar, where KG = 851.56 grams.

[sync]

[Even if we would do that, it would just shift the problem. Then the networking guys would start complaining about how ridiculous Gibibit ethernet sounds along with a bunch of other protocols.

The networking people already get it right. 1 gigabit ethernet is 10^9 not 2^30. No need to change it to 0.93 gibibit ethernet.

[sync]

I work in IT. The only people who use kibibytem, mebibyte (...) are nitpicker who have generally a problem with their communication skills because of their asperger syndrome.

If a programmer is not able to implement the correct code (k=1024 or k=1000) because someone had not said "kibibyte" than there is something more in disorder. How has he worked all the years before kibi and mibi was invented? 

Sorry for my rude german profanity.

I also work in IT. There are many confusions. For example I once meet an storage expert. He said that a that particular storage system reserves 7% of the disk space for them self. After seeing his calculation I saw that the 7% was the difference between the disks sizes in TB (10^9) and the reported capacity in TB (2^30) of the storage system.

Now the situation is that 1TB != 1TB on the same system! It's worse that hundred years ago when every town has it's own meaning of foot. At least they were coincident within a town.

[westfw]

Don't forget that 100Mbps comm lines need that 125Mbps bandwidth; cause 8b/10b encoding.  But your 10Mbps ethernet needs 20Mbps bandwidth, and your 115200bps modem is only like 8000 baud.

Basically, your CS types are really lazy when it come to actual numbers, or units, or silly concrete concepts like that.

[rr100]

It would cause all sorts of problems. For example software that parses printed output would suddenly fail. It's a stupid way of doing things but surprisingly common too. Even on Linux there is a configuration setting to fix the ls command's output back to "KB" instead of "KiB" so it doesn't break stuff.

Now that's a new one, software will crash and burn if we add that "i". OMFG, run in circles, scream and shout. Would you care to show us such software? I'm sure it's a kludgy POS that would be better off to be shot in the head.
Everything can and will be changed. You just need to chose the right direction.
python changed from one version to next one in such a fashion that "Hello World" wasn't working anymore. And still people use python and the world did not transform into a Mad Max world. And realize how many pieces of software use python compared cu how many might be using k input and not accept Ki (I don't know about any, again maybe you care to share some).

If you don't believe me take a look at this: http://www.zen134237.zen.co.uk/ Now realize there are millions of sites running similar software, and that's just web servers.

That I do not understand, is something crashed because of the extra "i" ?

KiB = 1000 bytes, problem solved.

No, that would really make the problem outlive us. Now at least Ki is clear what it is, there's no doubt; some people swear they'll rather die than use it but that's it. If you make it NOW 1000 it will be like "oh, Ki, hm, is that early 2013 Ki or late 2013 Ki?". And the doubt about k would still stand, some people would use it for 1000 as it was used since late 1700's and some people would insist to use it as 1024. And you'll get double the mess.

[sync]

It would cause all sorts of problems. For example software that parses printed output would suddenly fail. It's a stupid way of doing things but surprisingly common too. Even on Linux there is a configuration setting to fix the ls command's output back to "KB" instead of "KiB" so it doesn't break stuff.

Now that's a new one, software will crash and burn if we add that "i".

And the best is that the linux ls doesn't output "KiB" and AFAIK never done.

[Monkeh]

It would cause all sorts of problems. For example software that parses printed output would suddenly fail. It's a stupid way of doing things but surprisingly common too. Even on Linux there is a configuration setting to fix the ls command's output back to "KB" instead of "KiB" so it doesn't break stuff.

Now that's a new one, software will crash and burn if we add that "i".

And the best is that the linux ls doesn't output "KiB" and AFAIK never done.

I already said that

[Monkeh]

KiB = 1000 bytes, problem solved.

No, that would really make the problem outlive us. Now at least Ki is clear what it is, there's no doubt; some people swear they'll rather die than use it but that's it. If you make it NOW 1000 it will be like "oh, Ki, hm, is that early 2013 Ki or late 2013 Ki?". And the doubt about k would still stand, some people would use it for 1000 as it was used since late 1700's and some people would insist to use it as 1024. And you'll get double the mess.

So it's okay for you to try and redefine kilobyte as 1000 bytes, but I can't use kibibytes for 1000 bytes. Well, too bad, I'm sticking with the original definition and setting up KiB as the new 1000 byte version. My hard drives a 2TiB or 500GiB, but I have 8GB of RAM.

It's already a case of "oh, K, is that the new K or the original K?". Hopefully the new K will just die, and using KiB=1000 should speed up its death.

You're the one complicit with the redefinition of a prefix which existed long before you were born.

[rr100]

I'm still waiting for examples of the situation mentioned previously by mojo-chan: "software that parses printed output would suddenly fail."
Is this something that exists for real or (plausible and possible but still) imagination?

[Monkeh]

I'm still waiting for examples of the situation mentioned previously by mojo-chan: "software that parses printed output would suddenly fail."
Is this something that exists for real or (plausible and possible but still) imagination?

If he tries it on with ls again I'll print out POSIX and brain him with it..

[amyk]

python changed from one version to next one in such a fashion that "Hello World" wasn't working anymore. And still people use python and the world did not transform into a Mad Max world. And realize how many pieces of software use python compared cu how many might be using k input and not accept Ki (I don't know about any, again maybe you care to share some).

It seems with all the Python hype these days people are thinking it's bigger than it really is, when in fact Python 3 is still in the minority and the whole base of Python software is just a drop in the ocean compared to all the other systems that are out there.

Whatever the confusion between units has cost (financially), I am almost going to bet that it's tiny in comparison to what it would cost to rewrite/update everything. And when rewriting software, there's a very large chance that bugs are going to be introduced, making things even worse than they were. It's a net loss. (But then again, I know of a few large companies who love making breaking changes because they seem to have developers who wouldn't have/want anything else to do... )

[alm]

Whatever the confusion between units has cost (financially), I am almost going to bet that it's tiny in comparison to what it would cost to rewrite/update everything.

Rewrite/update everything? The far majority of APIs (like fstat(2)) use bytes, not kBs or kiBs. And even the ones that do would just need a change to the documentation that said parameter is in kiB, not kB. Most application software would at most require superficial changes (eg. displaying the size of the currently open file somewhere). Only some UIs would need changing, for example Windows Explorer / Finder, web browser download dialogs and the file open dialog. All of these go through much larger changes every major Windows release than this change require. Apple did it for OS X 10.6, and I don't remember shareholders complaining about development costs or users complaining about major bugs caused by this change.

[rr100]

Python 3 is still in the minority and the whole base of Python software is just a drop in the ocean compared to all the other systems that are out there.

The point is that Python3 (2008) programs are still a lot and used a lot. Certainly their usage dwarfs completely any and all programs like mojo-chan mentioned.

The simple fact that we need to go to such extreme examples like super-duper programs known only to mojo-chan that anyway break from many other reasons means the problem, if any, is fantastically limited. Otherwise we would have already the example code to discuss and evaluate what's the impact, what, why and how it breaks and so on. It's such a big and costly problem to fix but somehow it impacts just one program nobody else heard about but one of our colleagues here!

[amyk]

Apple did it for OS X 10.6, and I don't remember shareholders complaining about development costs or users complaining about major bugs caused by this change.

That's because OS X is a minority...

The simple fact that we need to go to such extreme examples like super-duper programs known only to mojo-chan that anyway break from many other reasons means the problem, if any, is fantastically limited. Otherwise we would have already the example code to discuss and evaluate what's the impact, what, why and how it breaks and so on. It's such a big and costly problem to fix but somehow it impacts just one program nobody else heard about but one of our colleagues here!

You'd be surprised how many "legacy" systems are still around. It's usually things like banks that use them, and the codebase there is huge.

The Y2K problem is probably of comparable magnitude, although the difference there is that there was a deadline to it, while this issue isn't really a problem except to the SI purists and "standards lawyers"...

[rr100]

You'd be surprised how many "legacy" systems are still around.

There are so many that we can't get even one good example to analyze!

In any case I don't understand the argument with "too many systems to change". There are a lot of places where certainly nothing would happen if you would just use "i" or better yet the proper values for the metric prefixes. Post number #36 is a good example and no, don't come saying there's some OCR recognizing the digits and letters from the picture and it won't like the different units. For those cases there's no reason to insist to do it wrong, except maybe to puzzle customers with things like "I bought a 1TB drive why it shows only 0.90TB".

Then we MAYBE have some programs (not THAT many as we couldn't find yet any good example) that might be parsing the output and barf on Ki. FINE, then don't use the "i" and put k but use the right value, 1000. Don't tell me you use the binary k for any precision! Do you know how much is 1 byte in Ki? It is 0.0009765625 Ki ! 11111 bytes = 10.8505859375 Ki. You get the picture.
Even better, 1B = 0.0000000000009094947017729282379150390625 TiB ! It is much more efficient to just use the value directly in octets without any prefix!!!

As I don't think anybody can claim that some software outputs and some software parses such nonsense it means even if there are some calculations done they aren't precise but just a rough estimate. If you don't compute to the last bit (and I'm sure you don't, not even close, see what kind of output we're talking about) you anyway have to build in large tolerances for anything to work. You can have two 1kb files put together and get either 2kb or 3kb. And if you have tolerances and anyway use just estimates why not use 1000 for k as it should be?

[sync]

"software that parses printed output would suddenly fail."

smtp, nntp, www, pop3, imap .... 

Lucky these protocols doesn't use any unit prefixes.

[sync]

At work we have a product that uploads data to an FTP server over the GSM network. Our client has software that gets new files from the site. It's some kind of script and has broken a few times when we updated the FTP server software, mainly due to formatting.

Typical bad implementation. I have seen that a lot of times done by people which don't know what they doing. There are FTP libraries which are robust against different FTP servers and updates.

[sync]

smtp, nntp, www, pop3, imap .... 

Lucky these protocols doesn't use any unit prefixes.

They use "K" and "M", but some people are trying to re-define those to mean powers of 10 which is where the breakage comes from.

Wrong! These protocols doesn't use unit prefixes. The designer of them aren't that stupid. They uses plain numbers of octets or lines. No prefixes allowed.

[Kjelt]

The problem with KiB is that it breaks easy hex numbering that people are used to. Do you know what 1KiB is in hex? It's 0x3E8. 

In your universe 1KiB = 1000 in the universe of all other human beings 1KiB = 1024 and this is 0x400 in hex. Perfect 

[sync]

The problem with KiB is that it breaks easy hex numbering that people are used to.

What? Almost all people doesn't know what hex numbers are. They only see that a 1TB disk is only 0.9TB in Windows. Please leave your ivory tower.

[AlfBaz]

[troll]
I haven't read this whole thread, so it may have been mentioned already, but doesn't it take a special breed of arrogance (aka software programmers) to take a long standing international standard and assume it is polymorphic? [/troll]

[Tepe]

[troll]
I haven't read this whole thread, so it may have been mentioned already, but doesn't it take a special breed of arrogance (aka software programmers) to take a long standing international standard and assume it is polymorphic? [/troll]

Polymorphism is used in computing so no problems there.

[rr100]

What? Almost all people doesn't know what a terabyte is. They don't even know that the box under their desk isn't a "hard drive". Please leave your ivory tower.

They don't (many programmers don't) but can easily see the 1TB on the box and 0.90TB in the pie chart.
Anyway the point was that "it breaks easy hex numbering that people are used to" is false BECAUSE "Almost all people doesn't know".
Don't tell us now that most people don't know what 1TB is but would prefer to use the TiB because it looks better in hex!