Archive for September, 2008

1 KB = 1024 Bytes? No, 1 KB = 1000 Bytes!

Tuesday, September 30th, 2008

I read up on the history of the ancient convention that 1024 Bytes are called 1 Kilobyte. The problem with the convention is that it’s totally unintuitive unless you know it.

Unfortunately, Microsoft decided to use the following conventions and now the whole world uses it:

  • 1 KB = 1024 Bytes
  • 1 MB = 1024 * 1024 Bytes
  • 1 GB = 1024 * 1024 * 1024 Bytes.

Basically, that is a mish-mash of the ancient 70s convention of using kB for 1000 Bytes and KB for 1024 Bytes, and an abuse of the SI definitions of M and G prefixes. Actually, there is no mB or gB convention, although that would have been logic in the original convention. This is due to the fact that in the 70s – the age of large and expensive computers -, nobody believed that mass storage would actually be achievable at all.

Just assume you never used a computer, ancient UNIX tools or listened to a computer science lecture, or were taught anything about computers. Wouldn’t you expect that

  • 1 KB = 1000 Bytes
  • 1 MB = 1000 * 1000 Bytes
  • 1 GB = 1000 * 1000 * 1000 Bytes?

I filed a bug report against glib, with an historical analysis of the usage of all conventions and formalized nomenclatures in existence (slightly wrong) demanding that g_format_size_for_display() uses the latter conventions. This actually matches IEC recommendations.

One important side-effect of the conventions are:

  • K=1000: Memory sticks and main memory cells are made in powers-of-two – because the address line uses binary logic (i.e. powers-of-two). Historically, their size is advertized with K=1024 to get nice, non-fractional values. Below the 1 GB limit, they were probably advertized with kB rather than KB – but that shouldn’t be relevant anymore. With K=1000, on your computer screen memory (and memory sticks) shows up LARGER than advertized.
  • K=1024: Hard disks do not have such cell architectures, and they are advertized with K=1000. It was some kind of marketing trick in the very beginning, making the disk look larger than you expect, when you set K=1024 as old-fashioned “IT geek”. The effect is that with K=1024, on your computer screen hard disks look SMALLER than advertized.

Compare for yourself: Which of the two statements is positive, psychologically:

  • In contrast to Windows, under Linux my 70 GB hard disk has 70 GB as advertized, and my 1 GB memory sticks grow to 1,07 GB
  • Like under Windows, under Linux my 70 GB hard disk shrinks to 65,1 GB and my 1 GB memory sticks have 1 GB as advertized

Wouldn’t it also be nice to have a 100 MB file with 100 * 1000 Kilobytes? No more calculator I/O or right-clicking required for estimating the “actual” size in byte units!

I am mostly writing this blog entry to get some feedback from our users, rather than from programmers. Please also mention your background in your blog comments! Further concrete information regarding historic conventions and IEC and SI standards is available in the bug report mentioned above.

Also note that I do NOT demand to use the additional odd KiBi, MiBi, GiBi IEC convention that in fact make the current situation worse by using prefixes nobody knows, still defining Ki = 1024. My guess is that it was just introduced for offering an alternative for traditionalists who probably wanted “some convention with the beloved 1024”. But it is a non-traditional measurement prefix for a traditional concept, which makes it unattractive both for old(-fashioned) traditionalists and young pragmatists.


I removed the possibly intimidating roundhouse kicks against IT community, and somewhat out-of-context IRC log excerpts. Sorry if anybody felt insulted – some certainly did. You can find an interesting collection of opinions and personal backgrounds in the blog comments.

Nautilus multihead desaster

Friday, September 19th, 2008

Today I tried out Nautilus with dual-head, i.e. two monitors that share a large virtual screen using XRandr. It was a desaster! Not XRandr – I love it! But it turns out that Nautilus miserably fails to be useful in a dual-head layout.

I already fixed Nautilus 2.24 to never move any icons outside the (virtual) screen area some time ago, but for dual-head we have horrible issues:

* Dead space is not detected, icons are put happily there

* The icons are not laid out per physical monitor, but per virtual screen. You can easily have icons that are “shared” between two monitors. While the actual icon layout is a bit tricky in the case of overlapping monitor regions, in the non-overlapping case we should perfectly be able to do nice per-monitor icon layouts.

* When there is a loading error for a file launched from the desktop, it is displayed in the middle of the (virtual) screen, and not in the middle of the monitor you used to open the location.

* The first navigation window is always opened on the monitor where the last navigation window was closed, even when you open it through the panel on a different monitor (patch pending release team approval).

* We don’t begin the icon layout on the monitor that you right-click to select “clean up by name”

* No background image awareness, i.e. the background image is just centered across monitors, even if it fits on the first monitor. Ideally, we’d have per-monitor backgrounds, of course.

* … any more issues you report, assuming you actually use GNOME in a dual monitor setup …

Now, a serious question: Is our user base so small, that we just receive bug reports evry once in a while, and not constantly? Are our users masochistic or unprofessional enough to tolerate this in a desktop environment that is supposed to be used in business environments?

While I frequently use beamers in combination with my laptop, I miserably failed to use them with Linux and used Windows for my (university) beamer needs from day two on. An educated guess is that almost every GNOME user out there does the same and uses Linux for non-serious business only. This is somewhat frustrating, as we are still trying to deliver a robust and business grade desktop environment – aren’t we? Note that this is NOT a rant about XRandr, which is really, really neat. It’s just we who suck!


Some comments suggest that some of our users feel insulted, and rectify themselves that they actually filed bugs, gave up on us or something along those lines. It is interesting how some people describe their use-cases, griefs and work-arounds. I love how everybody cares about quality, files bug reports and kicks us in the arse when things are broken. I certainly did not write this to insult anybody. You have to understand that I somehow feel like an innkeeper who thinks that he has some good wine in his cellar, realizing that half his wine from a certain country is decomposed.