You've probably heard that SL is measuring 1GB as 1000MB, instead of the proper 1024MB.
Is there any way to change this back?
Is there any way to change this back?
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Changing snow leopard file sizes from base 10
- Thread starter Jethryn Freyman
- Start date
- Sort by reaction score
You've probably heard that searching is a good practice on MR.
And no. There is no way, that works.
And no. There is no way, that works.
Actually, SL's way is the proper way, and has been for many years. It's caused no end of grief for Apple and other companies trying to explain to a customer why a their hard drive had so much less space than the drive manufacturer specified. Manufacturers who use the actual number of bytes, instead of multiples of 1024.
How Mac OS X reports drive capacity
How Mac OS X reports drive capacity
Very convincing position, especially when HD data is loaded into base-2 memory and crunched by a base-2 processor in a machine that uses base-2 electronic logic.
What's next -- we base-10ize the processor and memory reporting?
You can't change it back.
Apple built it into the system as such and so there's no way.
It seem more of a marketing move to show that you have more space then an accuracy move. The HD manufacturers did this yeas ago and it only created confusion. I expect similar results from this move, unless MS and Linux follows suit
Apple built it into the system as such and so there's no way.
It seem more of a marketing move to show that you have more space then an accuracy move. The HD manufacturers did this yeas ago and it only created confusion. I expect similar results from this move, unless MS and Linux follows suit
The problem lies in mixing terminology used to describe a base ten system(tera, giga, mega, kilo) to describe the calculations of a base two system.
The proper terminology for describing base two calculations was actually defined back in 1998. Tebi, Gibi, Mebi, and Kibi.
This chart on the Wikipedia terabyte page shows the prefixes.
http://en.wikipedia.org/wiki/Terabyte
If you see "MB" with no 'i' in the middle, that is the base ten measurement. If you see "MiB" with the 'i' in the midde, that is the base two measurement.
The proper terminology for describing base two calculations was actually defined back in 1998. Tebi, Gibi, Mebi, and Kibi.
This chart on the Wikipedia terabyte page shows the prefixes.
http://en.wikipedia.org/wiki/Terabyte
If you see "MB" with no 'i' in the middle, that is the base ten measurement. If you see "MiB" with the 'i' in the midde, that is the base two measurement.
Too bad we'd been using "kilo', "mega", etc. to describe base 2 calculations for several decades BEFORE 1998.
You guys might want to head over to this thread before you start repeating everything that happened there here.
That would be because hard drives have always used base-10 and because at first they didn't have a standard they could use for base-2 so they temporarily used the SI system which is base-10. Eventually they made a new standard for base-2 but unfortunately the wrong use of the SI system was already wide spread so changing to the proper system is hell. It also does not help that even software and hardware builders keep on using the wrong system. But than again, it's not as worse as medical terminology for the human body.Very convincing position, especially when HD data is loaded into base-2 memory and crunched by a base-2 processor in a machine that uses base-2 electronic logic.
What's next -- we base-10ize the processor and memory reporting?
Very convincing position, especially when HD data is loaded into base-2 memory and crunched by a base-2 processor in a machine that uses base-2 electronic logic.
What's next -- we base-10ize the processor and memory reporting?
Why would an end user care? The whole point of software is to abstract the hardware from the user (especially at the kernel level). Otherwise, we'd still be plugging wires into a programming board.
Try counting to ten in base-2. It really does work. Also note processors have been able to do base-10 math for quite a while now ("ages" ago, CPUs started to have the ability to do BCD conversions and math internally).
Sorry, there's not much reason to tell the user their hard drive contains x*y(to the nth power of 2) bytes, and leave it up to them to convert it into a number they can deal with the same way as all the other numbers in their life.
And TWO CENTURIES before that, the KILOmeter was defined as 1000 meters, not 1024.
mt
I just realized something today while looking at soemget info windows:
The Base10 value in GB is COMPLETELY redundant.
The size in bytes is easy to turn into base 10 GB/MB/KB by looking at the commas.
So they really should put GiB into the Get Info dialogs so the base10ers and the base2ers can both be happy.
The Base10 value in GB is COMPLETELY redundant.
The size in bytes is easy to turn into base 10 GB/MB/KB by looking at the commas.
So they really should put GiB into the Get Info dialogs so the base10ers and the base2ers can both be happy.
It's not redundant - it's just rounded off so you don't have to say 563,475,650,342 bytes as:
"five-hundred and sixty-three billion, four-hundred and seventy-five million, six-hundred and fifty thousand, three hundred and forty-two bytes.
Instead, it's:
"five-hundred and sixty-three point four eight gigabytes" (563.48GB)
What's the point of displaying the rounded off number as powers of 2? There's absolutely no reason to display GB as multiples of powers of 2 - unless you restrict your files to multiples of 2 to the nth and want to know how many will fit. I say powers of 2, because it's not base-2. Base-2 only has "1" and "0" for digits. Also, what's called the "base-2" method was a mix for "MB": 1000 (10^3) * 1024 (2^10)