Register FAQ / Rules Forum Spy Search Today's Posts Mark Forums Read
Go Back   MacRumors Forums > Apple Systems and Services > OS X

Reply
 
Thread Tools Search this Thread Display Modes
Old Sep 3, 2009, 02:16 PM   #51
sidewinder
macrumors 68020
 
sidewinder's Avatar
 
Join Date: Dec 2008
Location: Northern California
Quote:
Originally Posted by studentism View Post
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-
__________________
Mac Pro: 8-core 2.8 GHz, 10GB RAM, OS X 10.8.4; iPhone 5 32GB iOS 6.1.2
sidewinder is offline   0 Reply With Quote
Old Sep 12, 2009, 09:43 AM   #52
dyn
macrumors 65816
 
Join Date: Aug 2009
Location: .nl
Quote:
Originally Posted by gibbz View Post
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).
dyn is offline   0 Reply With Quote
Old Sep 12, 2009, 10:07 AM   #53
paulsalter
macrumors 68000
 
paulsalter's Avatar
 
Join Date: Aug 2008
Location: UK
Send a message via ICQ to paulsalter Send a message via AIM to paulsalter Send a message via MSN to paulsalter Send a message via Yahoo to paulsalter
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
__________________
Macbook C2D 2.16 GHz, 16GB 3G iPhone, 64GB iPod Touch & MobileMe
paulsalter is offline   0 Reply With Quote
Old Sep 14, 2009, 08:05 PM   #54
brkirch
macrumors regular
 
Join Date: Oct 2001
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:
Quote:
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.

Last edited by brkirch; Sep 14, 2009 at 08:47 PM.
brkirch is offline   1 Reply With Quote
Old Sep 14, 2009, 10:13 PM   #55
Cinder6
macrumors 6502
 
Join Date: Jul 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.
Cinder6 is offline   0 Reply With Quote
Old Sep 15, 2009, 09:53 AM   #56
hippy dave
macrumors newbie
 
Join Date: Sep 2009
Quote:
Originally Posted by brkirch View Post
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!
hippy dave is offline   1 Reply With Quote
Old Sep 15, 2009, 10:57 AM   #57
clmason
macrumors regular
 
Join Date: Apr 2008
Quote:
Originally Posted by brkirch View Post
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!
clmason is offline   0 Reply With Quote
Old Sep 15, 2009, 01:44 PM   #58
hippy dave
macrumors newbie
 
Join Date: Sep 2009
yep, everybody please keep hammering apple with feedback until they do the right thing
http://www.apple.com/feedback/macosx.html
hippy dave is offline   0 Reply With Quote
Old Sep 16, 2009, 03:17 PM   #59
SpookyET
Guest
 
Join Date: Oct 2008
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!
SpookyET is offline   0 Reply With Quote
Old Sep 16, 2009, 03:30 PM   #60
clmason
macrumors regular
 
Join Date: Apr 2008
Quote:
Originally Posted by SpookyET View Post
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.
clmason is offline   0 Reply With Quote
Old Sep 16, 2009, 03:53 PM   #61
jchung
macrumors newbie
 
Join Date: Mar 2008
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.
jchung is offline   0 Reply With Quote
Old Sep 16, 2009, 04:05 PM   #62
clmason
macrumors regular
 
Join Date: Apr 2008
Quote:
Originally Posted by jchung View Post
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!

clmason is offline   0 Reply With Quote
Old Sep 16, 2009, 04:42 PM   #63
Mindinversion
macrumors member
 
Join Date: Oct 2008
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.
Mindinversion is offline   0 Reply With Quote
Old Sep 16, 2009, 04:54 PM   #64
clmason
macrumors regular
 
Join Date: Apr 2008
Quote:
Originally Posted by Mindinversion View Post
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.
clmason is offline   0 Reply With Quote
Old Sep 16, 2009, 11:16 PM   #65
brkirch
macrumors regular
 
Join Date: Oct 2001
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.
brkirch is offline   0 Reply With Quote
Old Sep 20, 2009, 03:46 PM   #66
Hurda
macrumors 6502
 
Join Date: Sep 2009
Quote:
Originally Posted by brkirch View Post
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.

Last edited by Hurda; Sep 21, 2009 at 02:47 PM.
Hurda is offline   0 Reply With Quote
Old Sep 20, 2009, 04:05 PM   #67
clmason
macrumors regular
 
Join Date: Apr 2008
Quote:
Originally Posted by Hurda View Post
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!
clmason is offline   0 Reply With Quote
Old Sep 23, 2009, 08:25 AM   #68
visik7
macrumors newbie
 
Join Date: May 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
visik7 is offline   0 Reply With Quote
Old Sep 23, 2009, 08:36 AM   #69
clmason
macrumors regular
 
Join Date: Apr 2008
Quote:
Originally Posted by visik7 View Post
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.
clmason is offline   0 Reply With Quote
Old Sep 25, 2009, 06:53 PM   #70
dwpoyner
macrumors newbie
 
Join Date: Sep 2009
Quote:
Originally Posted by brkirch View Post
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?
dwpoyner is offline   0 Reply With Quote
Old Sep 25, 2009, 08:06 PM   #71
clmason
macrumors regular
 
Join Date: Apr 2008
Quote:
Originally Posted by dwpoyner View Post
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.
clmason is offline   0 Reply With Quote
Old Sep 25, 2009, 09:57 PM   #72
techhelper1
macrumors newbie
 
Join Date: Sep 2009
Quote:
Originally Posted by brkirch View Post
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.
techhelper1 is offline   0 Reply With Quote
Old Sep 26, 2009, 07:06 AM   #73
cjmillsnun
macrumors 65816
 
Join Date: Aug 2009
Quote:
Originally Posted by clmason View Post
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.
__________________
I support the MacRumors Blood Drive!
cjmillsnun is offline   0 Reply With Quote
Old Sep 26, 2009, 07:48 AM   #74
SnowLeopard2008
macrumors 603
 
SnowLeopard2008's Avatar
 
Join Date: Jul 2008
Location: Silicon Valley
Send a message via AIM to SnowLeopard2008
Who cares? You still have the same physical amount of space. It's just another way to calculate it.
__________________
YouTube | @beautifulcode
Mac Pro | Thunderbolt Display | iPhone 5 | iPad mini | Apple TV | AirPort Extreme | iPad signed by Steve Wozniak
SnowLeopard2008 is offline   0 Reply With Quote
Old Sep 26, 2009, 01:03 PM   #75
cjmillsnun
macrumors 65816
 
Join Date: Aug 2009
Quote:
Originally Posted by SnowLeopard2008 View Post
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.
__________________
I support the MacRumors Blood Drive!
cjmillsnun is offline   0 Reply With Quote

Reply
MacRumors Forums > Apple Systems and Services > OS X

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Similar Threads
thread Thread Starter Forum Replies Last Post
How to make work an app/game for mountain lion (10.7 or more) on snow leopard (10.6)? Nikkei Mac Applications and Mac App Store 3 Jun 13, 2013 07:46 AM
How do I tweak Snow Leopard (Finder & Safari) to make it behave more like Tiger? Diamond Dave OS X 3 Jan 16, 2013 04:29 PM

Forum Jump

All times are GMT -5. The time now is 03:15 PM.

Mac Rumors | Mac | iPhone | iPhone Game Reviews | iPhone Apps

Mobile Version | Fixed | Fluid | Fluid HD
Copyright 2002-2013, MacRumors.com, LLC