Yes, but I am looking for a solution for OS X here, so obviously I am not going to elaborate on that... but I will get rid of OS X if there are no fix for it.
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.
Instructions to make Snow Leopard use Base 2
- Thread starter Rhapsody
- Start date
- Sort by reaction score
Yes, but I am looking for a solution for OS X here, so obviously I am not going to elaborate on that... but I will get rid of OS X if there are no fix for it.
So wait ....
I've been putting in 1,024 grams of flour into all my big group cooking when recipes called for a kilogram!
Oh Snap. I had my street pharmacist "taken care of" because I thought he was ripping me off, and stealing 24mg every time I bought a gram of... Erm... nevermind.
Oh Snap. I had my street pharmacist "taken care of" because I thought he was ripping me off, and stealing 24mg every time I bought a gram of... Erm... nevermind.
haha .. could you imagine?
"Hey, Tony! You promised me 2 kilos of the good stuff!"
"Thats what you got right there."
"Oh ya, smart guy? My scale only shows 2,000 grams. All those computer dudes told me there should be 2,048!"
<gun fire ensues>
Actually, since hexadecimal numbers are 4 binary digits when you convert them, it makes a damn lot of sense to use 8 bits per byte, and not 10 (seems you're not disputing this). When you get into RAM, you're dealing with pathways that basically require base 2. If you limited it to 1000s, then you'd be wasting potential storage. You COULD still use 1000, but then we'd have 4.67GB of RAM; 4GB is just plain simpler.
Anyways, if anyone's still upset over this, just give up and use Path Finder. It's better than Finder anyways, and will have a 64-bit build soon.
Regardless of the number of bits of a given byte, why should that change the counting of the bytes themselves?
Who said anything about using 10 bits in a byte? What the hell is anyone talking about anymore?
Regardless of the number of bits of a given byte, why should that change the counting of the bytes themselves?
Who said anything about using 10 bits in a byte? What the hell is anyone talking about anymore?
I realized I misread the post. Check mine again, I fixed it
Now this is the funniest thing I have read in a long time. Of all the reasons someone might get rid of Mac, getting rid of it because of how it reports storage capacity has to be the least valid one ever.
S-
I don't have to get rid of my Mac, only OS X. I really use mostly free software and Unix anyway, not a biggie for me.
I realized I misread the post. Check mine again, I fixed it
Ah, I see what you're saying. And you're right - RAM and CPU level stuff etc works in base 2. This is true. But, I mean, when we're dealing with user-facing stuff I think it's easier to stick to the basics.
I think the real issue here, for me at least, is the re-appropriation of the kilo, mega, giga, etc prefixes. kilo means 1000, not sure why the computer guys thought it would be a good idea to change the meaning instead if coming up with new binary based prefixes (although they have now, I suppose).
I agree the naming scheme is unfortunate, but it's *well* established that SI prefix kilo does not mean the same in computer-land. Hard Drive manufacturers (and now Finder) decided of their own accord to flip this. I completely understand the confusion, but it just needs to be looked at as two different systems -- a mile is a decent estimate for a kilometer, but you certainly wouldn't say they're equal to each other.
Anyway, I could honestly care less about Finder -- my entire work day is spent in Terminal. I just think it's hilarious that:
1) Apple decided to adopt the incorrect notation.
2) They _only_ did it in Finder.
3) Someone who doesn't know better is now going to wonder why any given file size is different than what anybody else not on Snow Leopard would report. That's Apple, though -- always buckin the trend!
This can ALL be simply fixed. Just give a system wide option to display in base 2 or base 10. Add that "i" before the "B" when people choose the base 2 option. Really it's not that hard.
Wait, what?
A kilometer is made up of 1,000 meters. A mile is ... uh, 5,280 feet? I certainly wouldn't sat they're equal to each other, consider a mile is more than 50% longer than a KM. An SI prefix is use to form decimal multiples. I.E 1000 x 1, 1000 x 10, 1000 x 100, and so on. That's why a kilometer is called a "kilometer"
"Computer land" were the ones that (arbitrarily) decided that 1,024 was close enough to 1,000 to co-opt the kilo prefix, even though it was an incorrect usage of the prefix in the purest sense. Much like a baker's "dozen" having 13 of something isn't quite an actual dozen.
I don't get what the big deal is though. Binary prefixes do exist for expressing these values like 1,024 and 2,048 or 1,048,576 and 2,097,152 and so on, for when you feel like going all base 2 on everyone.
Clearly you don't know the full story.
Hard drive manufacturers used the base-2 definition until one of them realized that if they switched to the base-10 then they would reach '1 gigabyte' easier.
It was not born out of any respect for the metric system-- it was born out of marketing.
Strictly speaking, Apple did the most correct thing here. KB, MB, GB, TB have been established (more recently, but established) to be using the proper SI prefixes, meaning 10^x.
The issue I'm currently taking is that they are not using the proper binary prefixes in places where the binary value is still used - such as in RAM amounts. Those should say KiB, MiB, GiB, or TiB - as they are universally calculated in 2^x.
They should be using KB, MB, GB, or TB where they mean it, but they should also be using KiB, MiB, GiB, and TiB where they mean it.
The issue I'm currently taking is that they are not using the proper binary prefixes in places where the binary value is still used - such as in RAM amounts. Those should say KiB, MiB, GiB, or TiB - as they are universally calculated in 2^x.
They should be using KB, MB, GB, or TB where they mean it, but they should also be using KiB, MiB, GiB, and TiB where they mean it.
convention should outweigh technicalities
i mean, we arent redefining current either to what it "should" be
i mean, we arent redefining current either to what it "should" be
I think the reasoning is also that most people are confused by the difference between binary and SI calculations. I still think it was the most correct move they could make, given 'ease of use' is a common goal for Apple.
That said, I did submit two bug reports, one regarding the incorrect capitalization of the thousand SI-prefix in the Finder (KB instead of kB), and the incorrect usage of SI-prefixes where base-2 calculations are used (2GB of RAM instead of 2GiB of RAM). I hope more people submit similar reports.
That said, I did submit two bug reports, one regarding the incorrect capitalization of the thousand SI-prefix in the Finder (KB instead of kB), and the incorrect usage of SI-prefixes where base-2 calculations are used (2GB of RAM instead of 2GiB of RAM). I hope more people submit similar reports.
Hah! I never claimed it was a clear explanation. The hex thing was part of my earlier answer for "why is a byte 8 bits, and not 10", which is what I thought was the question (it wasn't). My point was that representing a binary value is much easier with a number system that is base 2^x--such as octal and hexadecimal.
I know that you know this, but for some who don't...
Consider the binary number 01000001, aka the ASCII character 'A'. In decimal (base 10), it's 65. Unfortunately, there's no grouping of binary digits that will have 10 states between them. 3 digits have 8 states, and 4 digits have 16 states. Thus, it's very simple to convert 01000001 to hexadecimal:
0100 == 4
0001 == 1
Or 0x41. You can represent it in octal, but you must first pad the binary number to 001000001:
001 == 1
000 == 0
001 == 1
Or 0101. And since it's obviously cumbersome to print out full binary numbers, you're going to use shorthand. Hexadecimal numbers are shorter than octal numbers at the same value, while still remaining close enough to the familiar base 10 system that it stays useful (base 32 would be just plain obnoxious).
But, as said, this is all beside the point. I was answering something that wasn't asked, and admitted as much.
And while I don't care for Apple forcing base 10 on us and making the operating system internally and externally inconsistent, there are other options out there, and they work better than Finder in the first place.
I stretched the analogy for a reason. I wouldn't say they're equal either, no more than I would say 1000 bytes = 1024 bytes.
Again, we seem to agree. As stated before, it's unfortunate SI names were adopted into a completely different system, but it happened. 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.
Nobody's "going all base 2 on everyone." If anything, Apple's suddenly decided to go all base-10 on everyone. The powers that be decided to adopt a standard that (to my knowledge) is not used by any other OS. That's their prerogative, sure, but to me, it just seems like it would create more confusion than the usual "my disk is smaller than advertised
" confusion we have now.To wit, if you send a file from your machine to somebody else's (not running SL), there will be a discrepancy in the file sizes reported, and I don't think average users are going to start calculating or even checking file hashes. This assumes one is using Finder to determine the file size (the average user is not going to go into terminal and 'df -h' a file, for example), and not any other application in OSX. It strikes me as telling (and silly) that they didn't switch over all components to report base-10 sizes. Alternatively, if that wasn't a conscious decision, then it's pure negligence.
Ignoring all the other static for a second, my most basic issue is this: I'm guessing Apple is trying to make the OS X experience less confusing for the end-user. Reconfiguring the default file explorer to report different sizes than any other component in the system doesn't seem like the best way to accomplish that.
I stretched the analogy for a reason. I wouldn't say they're equal either, no more than I would say 1000 bytes = 1024 bytes.
Again, we seem to agree. As stated before, it's unfortunate SI names were adopted into a completely different system, but it happened. 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.
Nobody's "going all base 2 on everyone." If anything, Apple's suddenly decided to go all base-10 on everyone. The powers that be decided to adopt a standard that (to my knowledge) is not used by any other OS. That's their prerogative, sure, but to me, it just seems like it would create more confusion than the usual "my disk is smaller than advertised
To wit, if you send a file from your machine to somebody else's (not running SL), there will be a discrepancy in the file sizes reported, and I don't think average users are going to start calculating or even checking file hashes. This assumes one is using Finder to determine the file size (the average user is not going to go into terminal and 'df -h' a file, for example), and not any other application in OSX. It strikes me as telling (and silly) that they didn't switch over all components to report base-10 sizes. Alternatively, if that wasn't a conscious decision, then it's pure negligence.
Ignoring all the other static for a second, my most basic issue is this: I'm guessing Apple is trying to make the OS X experience less confusing for the end-user. Reconfiguring the default file explorer to report different sizes than any other component in the system doesn't seem like the best way to accomplish that.
Cool man - I appreciate the well thought-out answer. And you're right, we do basically agree.
The only difference, from my side anyway, is that I'm down with base-10 for storage. I think it's the right way to go and other OSes should adopt it.
For some stuff (CPU level things and the ilk) will need to stay base-2, but file storage-wise, I'm down with base-10 - a 1,242,500 byte file is 1,242,500 bytes to me, aka 1,242.5 kilobytes or aka 1.243 megabytes.