Re: Using standardized SI prefixes
On Wed, 2007-06-13 at 12:51 +0200, Christof Krüger wrote:
> On Tue, 2007-06-12 at 15:52 +0100, Ian Jackson wrote:
> > shirish writes ("Using standardized SI prefixes"):
> > > Please look at http://en.wikipedia.org/wiki/Binary_prefix .
> > Urgh, these things are ugly and an abomination. We should avoid them.
> I'd really like to hear some real arguments against SI prefixes, besides
> being ugly or funny to pronounce or just because "it has always been
> like that". Advantages of using SI prefixes has been mentioned in this
> thread. Please tell me the disadvantages so there can actually be a
> constructive discussion.
Most users do not know what a "tebibyte" is, and they do not care. They
know that "a terabyte" is "about a million million bytes", and that is
Since you're rounding anyway, the loss of accuracy between "about a
million million bytes" and "just over a million million bytes" is not
significant. Certainly not at the expense at having to teach users
another new unit.
Hard drives are bought in gigabytes, memory is bought in gigabytes, etc.
Quoting the same figures with a different unit in the operating system
is pedantry for its own sake.
Users have already learnt that the term "gigabyte" is approximate.
Wrong most users think of "gigabyte" as absolute rather than
approximation. If that was not the case then
have happened. Most of the users when they burn a CD/DVD use the
approximation "GB" to say a burn a movie DVD. Most of the DVD media is
marketted as 4.78 GB while its 4.38 "GiB" & hence when they download a
movie (legally downloaded or otherwise) or do mixed mode stuff. Also I
don't know many users who go down to byte-size level & see how much
space is remaining. I do get support calls over this quite a bit.
Thinking that users know its an approximate IMHO is an
Introducing new units has only added confusion, rather than removed it.
The same could be said of relatively newer concepts like free
software, open source, copyright, creative licenses, .PNG, .SVG & all
the newer stuff that the web keeps pouring in. Micro formats anyone.
That doesn't mean we stop learning, it just means we adjust ourselves
to the new reality.
Before the new units, we all knew that 1GB was an approximate figure and
likely to be (for bytes) based on a power of 2. Now we have figures
quoted in GB and GiB, some of which are power of 10, some of which are
power of 2. Some figures quoted in GiB are wrong, and should be in GB;
likewise some in GB should be GiB. And we still have many figures in
both GB and GiB which are neither of the two!
Renaming the 1.44MB floppy helps in neither case; it is neither 1.44MB
or 1.44MiB. One could name it the 1.4MB or 1.47MiB floppy and confuse
everyone into thinking it's a different thing, of course. Or maybe it
should be the 1,440KB floppy, or the 1,475KiB floppy? Neither of these
help the situation.
Right, although it doesn't completely solve the situation it does
take things to a nearer perfect answer. I do see that it would take
time for us to make that change but its a better change IMO.
> Without the binary unit to consider, when we quote a drive as 1TB, we
know that it has *at least* 1,000,000,000,000 bytes available.
Depending on the drive, it may have anywhere between this and
1,099,511,627,776 bytes available. It's actually more likely to have
something strange like 1,024,000,000,000 available.
(And none of this takes into account partitioning and filesystem
I see no problem with this "1TB" quote being approximate. It's rounded
anyway. If you really want to know how many bytes are available, you
can use this great unit called the "byte" which is accurate and not
subject to change.
Do you think most common users are ever going to go down to byte size
level to see if things fit or not. It would actually be a good test
for Novell . I believe they do desktop tests for HIG & see how users
actually do stuff. Not techies but
day-to-day the Johns & Janes.
 Unless you're older than 25.
Scott James Remnant
Ubuntu Development Manager
This email is licensed under http://creativecommons.org/licenses/by-nc/3.0/
065C 6D79 A68C E7EA 52B3 8D70 950D 53FB 729A 8B17