Instructions to make Snow Leopard use Base 2

sidewinder · Sep 3, 2009

studentism said:
A baker's dozen is 13. A kilobyte is 1024. There's no way one would reach those conclusions without some background; you just learn the notation and move on with your life -- you don't argue with a baker about how s/he's not using the word "dozen" correctly.

A "Baker's dozen" or a "long dozen" is 13 and is always 13. It's a tradition that dates back to the 13th century. If you went to a baker today and asked for a dozen donuts, he is going to give you 12 donuts. A dozen means a dozen. A kilo should mean 1000 of whatever units it is placed in front of...

S-

dyn · Sep 12, 2009

gibbz said:
Frankly who cares?

It is only Finder showing base-10. Open up terminal if you must know what the base-2 size is. iTunes and QTX also report in base-2.

Finder is using the correct standard as well as the terminal. Some applications still use the wrong standard such as iTunes 9 and Activity Monitor. Finder uses base-10 and reports it as such (so it uses kB, MB, GB, etc.), Terminal uses base-2 and reports it as such (that would be Mi, Gi, etc.) but iTunes and Activity Monitor both use base-2 but report it as base-10 since they use MB and GB instead of MiB and GiB.

The problem is not using base-10 or base-2, the problem is using base-2 and reporting it as base-10. That incorrect way of doing things has been going on for years and years and is what is creating a lot of confusion among both users and even technicians no matter what hardware or software is being used. I'd rather have Apple fix OS X that it displays the correct system. I don't care if Finder uses base-10 and Activity Monitor uses base-2 as long as I can tell the difference (which I can't right now).

paulsalter · Sep 12, 2009

I have now started ignoring the file size column in finder

its handy to see if your disk is nearly full, but as file sizes dont match anything except other SL systems they are completely pointless

I keep checking for an alternative to finder, path finder looked great and i was about to purchase this, they changed to base 10 also so i deleted it

brkirch · Sep 14, 2009

Rather than replace Finder, why not correct the problem at its source? The size strings are assembled using the Foundation framework, so if you change the base number it uses to calculate sizes from 1000 to 1024 then it will not only change the size displays in Finder to base 2, but also in Disk Utility and probably a few other Apple programs as well. Here's a simple command line utility that does exactly that:
http://files.me.com/brkirch/72zto4

Keep in mind that the usual software disclaimer applies, that is more specifically:

THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY
OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

So make sure you have a backup available before running this program (I included a couple safeties in the program so I doubt there will be any problems, but it can't hurt to be on the safe side). It would also probably be a good idea to rerun this program to change the Foundation framework back before installing any software updates.

Cinder6 · Sep 14, 2009

That's pretty intriguing. I'll have to look over the source later

Not really out of distrust, but to see how you did it.

hippy dave · Sep 15, 2009

brkirch said:
Rather than replace Finder, why not correct the problem at its source? The size strings are assembled using the Foundation framework, so if you change the base number it uses to calculate sizes from 1000 to 1024 then it will not only change the size displays in Finder to base 2, but also in Disk Utility and probably a few other Apple programs as well. Here's a simple command line utility that does exactly that:
http://files.me.com/brkirch/72zto4

i just registered purely to say thank you. you've made my day - thanks!

clmason · Sep 15, 2009

brkirch said:
Rather than replace Finder, why not correct the problem at its source? The size strings are assembled using the Foundation framework, so if you change the base number it uses to calculate sizes from 1000 to 1024 then it will not only change the size displays in Finder to base 2, but also in Disk Utility and probably a few other Apple programs as well. Here's a simple command line utility that does exactly that:
http://files.me.com/brkirch/72zto4

Keep in mind that the usual software disclaimer applies, that is more specifically:

So make sure you have a backup available before running this program (I included a couple safeties in the program so I doubt there will be any problems, but it can't hurt to be on the safe side). It would also probably be a good idea to rerun this program to change the Foundation framework back before installing any software updates.

Thank you, thank you, thank you, thank you!

This awesome news. Now we just need to get Apple to put this in system preferences!

hippy dave · Sep 15, 2009

yep, everybody please keep hammering apple with feedback until they do the right thing

http://www.apple.com/feedback/macosx.html

SpookyET · Sep 16, 2009

This is stupid. The problem is that they didn't change "Snow Leopard". Otherwise, all apps would be affected. They only changed a library used by Finder and Disk Utility. READ THIS!

clmason · Sep 16, 2009

SpookyET said:
This is stupid. The problem is that they didn't change "Snow Leopard". Otherwise, all apps would be affected. They only changed a library used by Finder and Disk Utility. READ THIS!

Um, I don't think you understand. All other apps still use base-2. If they are modified in the future to use base-10, it will be by modifying them to use this new library setting. This is standard programming practice! You don't hardcode a number (i.e. 1024 or 1000) into dozens of different apps. You set it in one central place so that it's easy to change them all.

This is good, since it means it's very easy for Apple to have a setting to use base-2 (1024) or base 10 (1000) in system preferences, or for a think party (i.e. tinkertool) to change this setting globally. Of course, third party apps should use this same library so that way they aren't forcing their users to use one size display versus another.

jchung · Sep 16, 2009

Hmmm... just because a group of people have decided to go against HISTORICAL definitions of KB, MB, GB, etc... does not make it "right".

Storage on computers are always base 2 and there are clear logical reasons for it. And from the beginning KB, MB, GB have been defined in terms of base 2. As far as I'm concerned, KB being 1024 bytes IS THE RIGHT definition. And I do not care what international committees decide.

clmason · Sep 16, 2009

jchung said:
Hmmm... just because a group of people have decided to go against HISTORICAL definitions of KB, MB, GB, etc... does not make it "right".

Storage on computers are always base 2 and there are clear logical reasons for it. And from the beginning KB, MB, GB have been defined in terms of base 2. As far as I'm concerned, KB being 1024 bytes IS THE RIGHT definition. And I do not care what international committees decide.

Exactly. I've decided a dozen should mean 10, not 12, because that's base ten. And a gross should be 100, not 144! See, with the larger units, the discrepancy gets even worse! So, we *have* to change it to be base 10!

Mindinversion · Sep 16, 2009

Simple question time. When a software vendor records on their product label the HDD space requirements for their program. . .is that measurement in base2 or base10? I ask this because I honestly don't know. If it's Base10, then at least when it comes to storage I can compare apples to apples and I can just be pissed about having been sold a product that does not have the capacity advertised. [You can sell me all the B/S in the world about why you think Base10 is superior/smarter/better, and my brain will *STILL* compute space in Base2. After over 2 decades, you're not going to get that to change]

*IF*, however, programs and files are still reported in Base2, then not only are you losing space off the top [@ the HDD end] but you're losing space off the other side as well [according to computer, program is bigger than advertised on the label due to Base10 calculation].

And if THAT'S the case, why haven't they standardized it all around???

[Sure, maybe they have. . but I've never heard or seen anything on this argument outside of the HDD sector.

Either way, corporations = money and money = their way, no matter who likes/dislikes their practices. I'd say if you don't like it find another company to do business with, but that's kinda hard when they're all in bed with each other to begin with.

clmason · Sep 16, 2009

Mindinversion said:
Simple question time. When a software vendor records on their product label the HDD space requirements for their program. . .is that measurement in base2 or base10? I ask this because I honestly don't know. If it's Base10, then at least when it comes to storage I can compare apples to apples and I can just be pissed about having been sold a product that does not have the capacity advertised. [You can sell me all the B/S in the world about why you think Base10 is superior/smarter/better, and my brain will *STILL* compute space in Base2. After over 2 decades, you're not going to get that to change]

*IF*, however, programs and files are still reported in Base2, then not only are you losing space off the top [@ the HDD end] but you're losing space off the other side as well [according to computer, program is bigger than advertised on the label due to Base10 calculation].

And if THAT'S the case, why haven't they standardized it all around???

[Sure, maybe they have. . but I've never heard or seen anything on this argument outside of the HDD sector.

Either way, corporations = money and money = their way, no matter who likes/dislikes their practices. I'd say if you don't like it find another company to do business with, but that's kinda hard when they're all in bed with each other to begin with.

Yes, software requirements are generally listed in base-2 for the simple reason that every OS uses base-2 except for Snow Leopard. Download files are listed in base-2 as well. Also, there are standard sizes for media files such as 700 MB or 350 MB (in order to fit on CDs usually, which are also listed in base-2.) Other files are split into 100 MB or 200 MB parts. Under Snow Leopard all these file sizes looked strange and were hard to judge if the download had completed correctly. (I say looked, past tense, because we now have a fix thanks to the awesome guy above.)

The major exception is the bloody HD manufacturers who use base-10 for marketing reasons. I wish all the lawsuits about that had succeeded years ago and we wouldn't have the problem today.

brkirch · Sep 16, 2009

I made a minor bug fix to the command line utility that switches how Foundation framework calculates sizes, just redownload from:
http://files.me.com/brkirch/72zto4

The bug fix is just to ensure HFS+ compression is reapplied after patching the Foundation framework to base 2; it should save 7546941 bytes, or about 7.2 MiB. If you have already used the earlier version of the command line utility then just run the newer version twice.

Hurda · Sep 20, 2009

brkirch said:
I made a minor bug fix to the command line utility that switches how Foundation framework calculates sizes, just redownload from:
http://files.me.com/brkirch/72zto4

The bug fix is just to ensure HFS+ compression is reapplied after patching the Foundation framework to base 2; it should save 7546941 bytes, or about 7.2 MiB. If you have already used the earlier version of the command line utility then just run the newer version twice.

Just registered to say thank you. It's a pity, that it takes the efforts of a user to fix a horrible bug.

And to duykur, sidewinder, gibbz, jedijoe: May I ask you to change your signatures to either use binary prefixes for the RAM-size or properly convert them to MB/GB.

PS: Using a SI-prefix for a not-SI-unit is stupid to begin with, and yes, next to all OS do it wrong, even today.
But do you see people using kilomiles or centiinch or hectogallons? No? Guess why: no SI-units. Bit/Byte ain't SI-units either, so use IEC-standardized symbols (b for bit, B for byte) and binary prefixes.
So Apple is using a wrong prefix and does proper conversions in a wrong place.

PPS: In other forums I even saw people suggesting Apple to change the definition of a byte to 10 bit, for consistency-reasons. Sheesh...

EDIT2:
Oh, and for all SI-lovers: the SI-symbol for kilo is "k", "K" is for Kelvin.

clmason · Sep 20, 2009

Hurda said:
PPS: In other forums I even saw people suggesting Apple to change the definition of a byte to 10 bit, for consistency-reasons. Sheesh...

Yes, we should also redo all the silicon so that it uses 10 voltage levels instead of 2. Then we'll *really* be following the standard! Plus, think of all the jobs we'll create rewriting all the programs and operating systems!

Btw, DNS only has 4 different values, this is clearly wrong too. Thankfully we now have genetic engineering, so we should be able to re-engineer all life in the world to use a system based on 10! Even more jobs!

visik7 · Sep 23, 2009

this patch doesn't work correctly:
here from bash

plain bytes:
ls -al DVD_DUMP.dmg
-rw-r--r--+ 2 visi staff 7687476522 Sep 17 17:02 DVD_DUMP.dmg

human readable:
ls -alh DVD_DUMP.dmg
-rw-r--r--+ 2 visi staff 7.2G Sep 17 17:02 DVD_DUMP.dmg

and here the finder:

Click for full size - Uploaded with plasq's Skitch

clmason · Sep 23, 2009

visik7 said:
this patch doesn't work correctly:
here from bash

plain bytes:
ls -al DVD_DUMP.dmg
-rw-r--r--+ 2 visi staff 7687476522 Sep 17 17:02 DVD_DUMP.dmg

human readable:
ls -alh DVD_DUMP.dmg
-rw-r--r--+ 2 visi staff 7.2G Sep 17 17:02 DVD_DUMP.dmg

and here the finder:

Click for full size - Uploaded with plasq's Skitch

It's working fine, "ls" just rounds off to one decimal place. As you can see 7.16 rounds to 7.2.

dwpoyner · Sep 25, 2009

brkirch said:
I made a minor bug fix to the command line utility that switches how Foundation framework calculates sizes, just redownload from:
http://files.me.com/brkirch/72zto4

The bug fix is just to ensure HFS+ compression is reapplied after patching the Foundation framework to base 2; it should save 7546941 bytes, or about 7.2 MiB. If you have already used the earlier version of the command line utility then just run the newer version twice.

Thanks for a very useful utility. My only question is, is this a reversible process?

clmason · Sep 25, 2009

dwpoyner said:
Thanks for a very useful utility. My only question is, is this a reversible process?

Yes, if you run it a second time it reverses the process. And he suggested in a previous post this might be something you want to do before any updates to OS X.

techhelper1 · Sep 25, 2009

brkirch said:
Rather than replace Finder, why not correct the problem at its source? The size strings are assembled using the Foundation framework, so if you change the base number it uses to calculate sizes from 1000 to 1024 then it will not only change the size displays in Finder to base 2, but also in Disk Utility and probably a few other Apple programs as well. Here's a simple command line utility that does exactly that:
http://files.me.com/brkirch/72zto4

Keep in mind that the usual software disclaimer applies, that is more specifically:

So make sure you have a backup available before running this program (I included a couple safeties in the program so I doubt there will be any problems, but it can't hurt to be on the safe side). It would also probably be a good idea to rerun this program to change the Foundation framework back before installing any software updates.

Even though it says for you to restart your computer what i did was open terminal if it was not already open, and type "killall Finder" and it took the base 2 without rebooting.

cjmillsnun · Sep 26, 2009

clmason said:
Exactly. I've decided a dozen should mean 10, not 12, because that's base ten. And a gross should be 100, not 144! See, with the larger units, the discrepancy gets even worse! So, we *have* to change it to be base 10!

Very funny, what you are talking about are not units with SI prefixes.

SI has always been base 10 and the kilo, mega, micro, deci, centi, giga prefixes have been around since the metric units (gramme, metre, etc) were first invented. http://physics.nist.gov/cuu/Units/prefixes.html http://physics.nist.gov/cuu/Units/meter.html

Which is a long time before than the 1940s when the first electronic computer (Collosus NOT ENIAC) was produced.

So in fact the HISTORICAL unit is base 10.

I don't support the way it has been implemented in Snow, and think altering the units to read as GiB, KiB, MiB would have been much better because then the sizes would have remained the same and avoided the confusion whilst introducing the correct notation for the units.

SnowLeopard2008 · Sep 26, 2009

Who cares? You still have the same physical amount of space. It's just another way to calculate it.

cjmillsnun · Sep 26, 2009

SnowLeopard2008 said:
Who cares? You still have the same physical amount of space. It's just another way to calculate it.

The problem is the confusion it can cause, particularly when native Apple applications (Safari and Finder for example) contradict each other, which do you believe?

Therefore a lot of people care.

Instructions to make Snow Leopard use Base 2

macrumors 68020

macrumors 68030

macrumors 68000

macrumors regular

macrumors 6502a

macrumors newbie

macrumors regular

macrumors newbie

Guest

macrumors regular

macrumors newbie

macrumors regular

macrumors 6502

macrumors regular

macrumors regular

macrumors 6502

macrumors regular

macrumors newbie

macrumors regular

macrumors newbie

macrumors regular

macrumors newbie

macrumors 68020

macrumors 604

macrumors 68020

Our Staff