How to get units consistent across all applications?

We have a units policy in Ubuntu, which we have to implement in lucid+1 (Ubuntu 10.10). Correcting all applications to conform to this policy is not an easy task. The first attempt to patch glib, which provides the g_format_size_for_display() function, failed. We need a library that can handle input and output formatted sizes. Take transmission as example: I want to set the bandwidth limit in the same unit as it displays me the limit. We have to introduce a set of new functions.

Should I create a new library (named libbyteunits or similar) or add a bunch of new functions to glib (as replacement for g_format_size_for_display)? Is glib the right place for ten or more functions handling units?

Pros for a separate library:

  • the library can be used by non-glib application without depending on glib
  • it can be made user configurable (for example by an text file), because some user prefer base-10, others base-2.


  • one more dependency for glib applications

I like to hear as many opinions as possible. Please let me also know, if you are glib developer, a g_format_size_for_display() using developer, a developer, or a user.

A bug in my mobile phone

I own a Samsung SGH-X160. It’s just a mobile phone for telephoning and writing SMS messages. I was sitting in a train last weekend and wanted to add a note to my task list in T9, but the phone didn’t know Eclipse. I wanted to add Eclipse to the dictionary, but instead the phone crashed (rebooted). I tried it multiple times and it’s reproducible:

Grab your SGH-X160, add a new task (Aufgabenliste -> Optionen -> Neu), type 3254, T9 will suggest Eckh, press zero to toggle T9’s suggestion until it gives you the option to add the word to the dictionary, press adding (Zufügen), correct the word to Eclipse, press OK. Your phone will go blank and then present you the boot splash for a half minute.

I want to file a bug and grab the source code to fix this bug. Oh, that is not possible, because the OS on the mobile phone is not free (libre) software.

Comments to Ubuntu 10.04 Reads File Sizes Differently

I stumbled over Ubuntu 10.04 Reads File Sizes Differently and I have to correct some statements.

First I want to ask you, my blog reader, to read the units policy. Then think about it and read it again.

Now my criticism to the blog post:

  • We didn’t change the units policy. There were no such policy; we created one.
  • KB does not exist (in the SI or IEC standard). It’s either kB (meaning 1000 bytes) or KiB (meaning 1024 bytes). Did the author read the policy?

Now my clarifications to the commenter:

  • This policy was not Canonical’s decision. You have to blame me for creating the draft of the policy and the Technical Board for approving it.
  • This policy has nothing to do with Apple. I have never used a Mac and I don’t care what kind of byte prefixes Apple uses.
  • This policy is not connected to the decision to change the window buttons position of the default theme. This was done by different people. These two things are absolutely independent.

Correcting all applications to comply to the units policy is a goal for lucid+1 (Ubuntu 10.10). We are too late in the release cycle for the change in lucid (Ubuntu 10.04). My current plan is to create a library for inputing/outputting bytes to users. The user can then configure this library to display the units in base-2 (KiB), base-10 (kB), or the historical totally fucked-up format (KB).

Edit: My clarifications to the commenter apply to the commenter of Ubuntu implements units policy, will switch to base-10 units in future release too.

7.35 seconds for booting

Today I had to set up a new Lenovo IBM ThinkPad T400. I replaced the hard drive by a Super Talent Ultradrive GX2 128GB and extented the memory to four gibibytes. The installation of Ubuntu 10.04 (lucid) took four minutes (time after answering questions and before rebooting to installed system). The notebook is fast with the SSD. After pressing the power button, the system needs nearly 20 seconds to reach GRUB. 7.35 seconds later the GNOME desktop is ready for usage.

Does your system boots faster?

Plymouth is nice, but it’s gone before it appears. The system boots too fast for plymouth. But why do I have to stare at plymouth quite a few seconds on shutdown? Shutdown shouldn’t take longer than boot.

Eclipse 3.5.2-1 in Debian unstable

We, the Debian Orbital Alignment Team (DOA team), have released eclipse 3.5.2-1 to Debian unstable today after nearly seven month of work and 612 commit to our git repository. Many thanks to our hero Niels Thykier (222 commits). Without him we wouldn’t have eclipse in Debian now. Thanks to Pablo Duboue, Adnan Hodzic, and Adrian Perez for their work on the Debian package. Last but not least, I want to thank Alexander Kurtakov and Andrew Overholt for eclipse-build, which we use to build eclipse.

You should have modern hardware, if you want to build eclipse. It will need three gigabytes free disk space, two gigabytes memory, and at least 12 minutes to build, but it can need hours (on old hardware or if you have not enough memory).

Update: Four days later we released 3.5.2-2 to Debian unstable. Today eclipse 3.5.2-2 was synced to Ubuntu 10.04 (lucid).

Ubuntu units policy

We finally have an units policy in Ubuntu. I started to work on this issue over a year ago. The first step was to talk to other people (Ubuntu developers and upstream), but the opinions diverged. Neither a consensus was found, nor any result came out of it (except heated discussions). Upstream was not willing to change anything. It was time to contact the Technical Board to get a decision for Ubuntu.

Now we have the policy and we can start filing bug reports and fixing them without discussions about the reasonability of the patches. Let’s get Ubuntu 10.04 (lucid) in shape!

Translations of package descriptions

I saw the Translations of package descriptions video from FOSDEM 2010. Every distribution has two translatable string for each package: a synopsis (summary, short description) and a long description. These descriptions differ from distribution to distribution. The descriptions should be shared between the distributions. This will enable us to share the translations of the descriptions.

My idea: Why not letting upstream provide the package description and the translation for it? They should have the knowledge to provide a good description and to update it if required. To encourage upstream to provide the description, we should create a freedesktop specification for it. Quick draft: The tarball should contain a file named The file should contain three RFC-2822-like fields for each package: Package, Synopsis, and Description. Translation can be stored in<language> (for example


Package: audacity
Synopsis: A fast, cross-platform audio editor
Description: Audacity is a multi-track audio editor for Linux/Unix,
 MacOS and Windows. It is designed for easy recording, playing
 and editing of digital audio. Audacity features digital effects and
 spectrum analysis tools. Editing is very fast and provides unlimited
 Supported file formats include Ogg Vorbis, MP2, MP3, WAV, AIFF, and AU.

What do you think about this idea?

Edit: Alexandre Franke found an existing markup language designed for our use case: Description of a Project (DOAP). Package is name there, synopsis is shortdesc, and description is description. Here is my example in DOAP:

<Project xmlns=""
  <shortdesc xml:lang="en">
    A fast, cross-platform audio editor
  <description xml:lang="en">
    Audacity is a multi-track audio editor for Linux/Unix,
    MacOS and Windows. It is designed for easy recording, playing
    and editing of digital audio. Audacity features digital effects and
    spectrum analysis tools. Editing is very fast and provides unlimited
    Supported file formats include Ogg Vorbis, MP2, MP3, WAV, AIFF, and AU.