Apple Kicks HDD Marketing Debate Into High Gear

quacking duck writes "With the release of Mac OS X 10.6 Snow Leopard, Apple has updated a support document describing how their new operating system reports capacities of hard drives and other media. It has sided with hard drive makers, who for years have advertised capacities as '1 GB = 1,000,000,000 bytes' instead of the traditional computer science definition, and in so doing has kicked the debate between marketing and computer science into high gear. Binary prefixes for binary units (e.g. GiB for 'gibibyte') have been promoted by the International Electrotechnical Commission and endorsed by IEEE and other standards organizations, but to date there's been limited acceptance (though manufacturers have wholeheartedly accepted the 'new' definitions for GB and TB). Is Apple's move the first major step in forcing computer science to adopt the more awkward binary prefixes, breaking decades of accepted (if technically inaccurate) usage of SI prefixes?"

Comments

Its been done for years already

[sopssa]

Is Apple's move the first major step in forcing computer science to adopt the more awkward binary prefixes, breaking decades of accepted (if technically inaccurate) usage of SI prefixes?

No, its not any first major step. HDD makers already went there years ago, its established and people know better what it means. And even if I'm quite a nerd myself, I never think that 1 terabytes = 1 048 576 megabytes. Yeah it would be great if I remembered that or as many decimals in PI as possible, but no one really cares. It's a lot easier to remember and think that 1 terabyte is 1 000 000 megabytes, even if its not technically so because of binary system and even if I know that - I still think so just for the easy of it.

And its a mac. What did you think? It's as far from a nerdy computer as possible. Obviously they are going to use terms and units that non-geeky people understand.

Re:Its been done for years already

[sopssa]

Your example is bad because its the default one. 1 terabyte to 1024 gigabytes is easy. How quickly you calculate that to 4TB? 15TB? 492TB? Or for more better example, 405GB to MB's? Its just a lot easier to think 405GB = 405 000MB than start calculating it, while its kinda close anyway.

Re:Its been done for years already

[mwvdlee]

The problem isn't the definition, it's that OS's and hardware manufacturers have been using different definitions. If both of them would stick to factors of 1000, there would be no problem. If they all stick to 1024, there would be no problem. The problem is that both definitions are used.

Personally I'd vote for 1000, since it's just easier for most people. That way they could easily know that 1001 1MB files do not fit on a 1GB USB stick and all the world would be consistent.

Re:Its been done for years already

[Timothy Brownawell]

So we've had a defined standard that was, arguably, not the easiest to understand. THEN harddrive manufacturers started their fraud. And THEN people started complaining. So what, and please think about this, would be the right decision here?

The "right" solution is that things dependent on the number of address lines (cache size, RAM size) are in units measured in 2^10, and things not dependent on the number address lines (network bandwidth, HDD/SSD size) are in units measured in 10^3. Files are interesting in that the base unit is a 512 byte sector but they don't depend on address lines, so they should be measured like floppy disks where 1kB is 1024 bytes, 1MB is 1000kB ,and 1GB is 1000MB etc -- but this is confusing, so they'll probably just consistently use steps of 1000.

Re:Its been done for years already

[Amiga Lover]

> So we've had a defined standard that was, arguably, not the easiest to understand.

> THEN harddrive manufacturers started their fraud. And THEN people started complaining.

> So what, and please think about this, would be the right decision here?

As far back as I know, and this goes back before the 1970s, C.Sci boffins picked up a defined pseudostandard (that 1024 was close though to 1000 to use K, etc) for concepts that required *only* direct binary addressibility like RAM and CPU registers/caches, and all else used a base 10 definition of K right from the start - that includes tape drive storage, hard drive storage, bandwidth rates, CPU frequencies, display frequencies, screen resolution, sampling rates and so on.

The idea that 1K = 1024 for "everything in a computer" is relatively new. The old guard knew exactly when it was appropriate to use, and did not use it for concepts outside that domain. It's only since the mid 1990s that geek kids fresh out of school want to use it everywhere. Hell, go into a geek IRC channel (usually a bastion of relatively conservative C.Sci geeks) and ask how many Hertz in a 1GHz processor, and a fair number will insist it's 1073741824Hz, or that 10Mbps ethernet is 10485760bps. They'd be wrong, too.

Re:Its been done for years already

[Bill_the_Engineer]

Because computers work in powers of 2.

Well...

Since we are talking about number values meant for human consumption, the selection of SI versus IEC units is arbitrary. Since most human beings tend to think in powers of 10, the SI units could be thought of as the more appropriate for the task.

Now technically, when it comes to media, the actual number of storage available doesn't necessarily need to be a power of 2. Yes the maximum capacity for a given random access media is limited by the largest value that can be addressed which is a power of two. However, the actual number of data words or address locations don't necessarily need to be. This is why we are able to have data structures of any length (eg char a[10];).

Re:Its been done for years already

[Kalriath]

Gigabyte does mean 1,000,000,000 bytes. Giga means billion. It doesn't not mean 1024 * 1024 * 1024 bytes. Mega means million, kilo means thousand.

I can't understand why people are actually arguing that doing it wrong is right.

There are even proper units for the 1024 units. Kibi-, mebi-, gibi-, and so on.

People keep harping on about these "proper" units, but the reality is that there's no way in hell you'll ever get anyone but obsessive geeks (the kind that develop OSS software) to adopt prefixes that sound like something you feed your cat. Seriously, those "proper prefixes" suck.

Benchmarks

[TheCount22]

This mean the downloads will seem faster on a Mac. What about benchmarks? Does this mean we are going to see tons of amateur reviews with inaccurate results? I hope Apple gives us a way to switch back to GiB mode in any case.

Wait 8 weeks

[nickovs]

The difference between 2^30 and 10^9 is about 7.4%. Disc drive capacity has been growing at least as fast as CPU power, doubling every 18 month, for as long as I can remember. This means that it takes about 8 weeks for drive capacity to grow by 7.4%. This should mean that by the time the marketing literature has made it through the bureaucratic process of being reviewed for release it will probably be correct!

Re:computers user base 2

[evilbessie]

You want to accept inconsistancies within your own field (MHz, GHz, MB etc.) rather than havng to change things. Because it's not as if anything ever changes with computers. Some parts of computers use base 2, others do not, there has been a definitive set of standards since 1999, getting MS on board would pretty much solve the problem as that is what people would then see their computer tell them.

Re:Okay, so technically,

[Sxerks]

The prefixes are different already, there is no centibyte for millibyte, it's not really a scientific measurement to begin with.

So there is no problem with using them in the original context (2^10....)

And no logical reason whatsoever for the terms (KiB,MiB,GiB) to have been created in the first place

Silly names

[AdamHaun]

Binary prefixes for binary units (e.g. GiB for 'gibibyte') have been promoted by the International Electrotechnical Commission and endorsed by IEEE and other standards organizations, but to date there's been limited acceptance

Nobody's going to use an annoyingly cutesy word like "gibibyte", which seems just as silly now as it did ten years ago. Using the abbreviated prefixes might be a good idea, though.

Just for reference (since some people are freaking out about how much space they're "losing") here's the percentage difference between the SI and binary sizes:

Kilobyte: 2.3%
Megabyte: 4.6%
Gigabyte: 6.9%
Terabyte: 9.1%
Petabyte: 11.2%
Exabyte: 13.3%

So for the foreseeable future your hard drive will be about 10% smaller than advertised. Not a big deal, IMHO (it's not like you're paying for the missing bits), but still worth pointing out.

Naw, not even those who know the difference care

[coryking]

It is kind of like the rated speed of a network card. Sure I've got a gigibit ethernet card. But unlike I assume most non-nerds, I *know* it doesn't move a giga*byte* per second--it moves a giga*bit* per second. So how many seconds does it take to move a giga*byte*? Well, I amost always convert GB to Gb by just multiplying by ten. Yeah there are 8 bits in a byte and I should be using 8, but there is all kinds of error correction and stuff that get shoved down the pipe too that I should be accounting for. Thus I figure 10 is good enough and plus the math is easy. With WiFi, I'd probably use 11 or 12 bits per byte. Basically, I dont care about the *exact* number, I just want an estimate.

Same with how big a file is. Unless I'm writing code and need to verify I'm writing out the *exact* number of bytes, I figure the numbers I see either are rounded to the hard drives block size, or they account for other stuff. Heck, even Explorer gives you like two file sizes on its property panel. Unless you add that cute little -h to df, most implementations will show you a number based on block size and *that* number depends on an environment variable.

In short, there are multiple standards and more most use cases we are looking for estimates to filesize or transfer speed. There are always hidden assumptions in most cases.

That all said, if I've got a file that contains the hex dump below, I better get back 6 bytes from my OS. ls -l shows the right number.
coryking@localhost ~ $ hexdump -C testing
74 65 73 74 2e 0a |test..|

PS: Those weren't "junk" characters slashcode! When are you going to get a better editor--steal the one used by stackoverflow. You use a `` around something and it interprets it as code.

PPS: Just learned learned there was a hexdump utility. Cool!

Re:Let's see them be consistant.

[n6mod]

But only under the pie chart. Free+Total still adds up to 4GB (3.81GB + 199MB at the moment)

So yeah, someone probably added the new math in the wrong place.

You merely agree with me (but it's not so obvious)

[Mathinker]

I already stated that it "would be a pain to convert to and from base-2" but you, while seeming to agree with me, make me understand where you are perhaps overlooking some things:

> every load and store operation

PCM wouldn't be used for the level-1 or probably even for the level-2 caches, so we are actually talking about loads and stores of cache lines which are many bytes long, said loads/stores already requiring something like 100-200 clock cycles on the last system for which I did low-level optimization (but I admit, that was quite a while ago). So it's not totally clear that its impossible to build some kind of pipelined asynchronous base converter which could convert fast enough (at small enough geometries) to make it worthwhile.