[PATCH] Add option to use traditional binary units instead of kibibytes

[Michael Pyne]

On Monday 06 July 2009 20:13:09 Benoit Jacob wrote:
> 2009/7/7 Michael Pyne <mpyne at kde.org>:
> > On Monday 06 July 2009 17:02:16 Marcel Partap wrote:
> >> > >The patch is wrong.
> >> > >This is the standard.
> >> > >Not doing it would be wrong.
> >> >
> >> > Which then must mean that we shouldn't have those units
> >>
> >> Very confusing indeed. IMHO there should be an option to switch between
> >> base 1000 and base 1024 units, for which clear conventions exist.
> >
> > NO ONE NEEDS BASE 10 UNITS.
> >
> > Just use KiB and be done with it.  Your "160 GB" hard disk will not ever
> > hold 160000000000 bytes in practice no matter what unit system you select
> > in KControl so it's hardly going to make the users feel any better.
>
> I don't want to continue the bikeshedding but I just want to recall a
> point that, as far as I can see, got lost in the discussion.
>
> The point is that:
>
> 1 KiB is 2.4% more than 1 kB
> 1 MiB is 4.9% more than 1 MB
> 1 GiB is 7.4% more than 1 GB
> 1 TiB is 10.0% more than 1 TB
> 1 PiB is 12.6% more than 1 PB

> The whole "1024 is close enough to 1000" thing dates back when people
> were only dealing with kilobytes.

Well I was never trying to make that point, but I'll elucidate further below.

> If people had been dealing with
> terabytes at that time, they probably would never had adopted that
> terminology, because a 10% difference matters to many more people than
> a 2.4% difference does.

But you misunderstand I think, they certainly chose kilo as a well-known 
prefix which was "close enough" to the binary value in question (2^10), but 
that's where the similarity stops.

I deal with large quantities units all the time (I'm sure everyone is familiar 
with scientific notation) and even the error in 1 PiB vs. 2^50 bytes is not 
even close to one order of magnitude.

And at the end of the day that's all these units are (or should be): Orders of 
magnitude.  I don't think anyone on this list can tell me with a straight face 
that they can perceive some kind of difference between 23.2 MiB and 22.8 MiB.  
No, the MiB is important because it frames the order of magnitude.

Certainly some cases call for having an exact byte count.  Luckily good file 
managers (including Dolphin and Konq) provide that anyways.  And more 
importantly, most of us aren't going to be able to calculate it in our heads 
(esp. with only at most up to the hundreds of a unit precision available from 
the GUI, which will be wrong with decimal or binary units).

> I'm just saying that even though the current approach of KDE may seem
> overly strict at the expense of familiarity to the user, in the long
> term it is the only solution, and the rest of software will eventually
> have to do the same.

The "only solution" if you need exactness is the full number.  How many files 
have you ever seen that were exactly, say, 4200000 bytes (and thus would make 
4.2 dMB exact?)

I've already mentioned a week ago that I don't have a problem with the 
adoption of KiB if we want to go that route.  I don't know how many different 
times I can explain it, but we *cannot go back right now*.  1 KB will never 
equal 1000 bytes as long as hard disk manufactures are the only major ones in 
the computer industry using it.  All that being the only desktop environment 
to put KB == 1000 bytes does is confuse our users, and any users who would 
switch to us.

I have received feedback that getting the patch in would be appreciated by at 
least some nominal subset of users so it's not just me that would like this to 
go in.  But it would have to be backward compatible otherwise there's no 
point, and that means 1024-byte KBs.

I do appreciate your feedback though. :)

Regards,
 - Michael Pyne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090706/7b76e6d2/attachment.sig>