Poll: libkibi VS libbyteprefix (or: How to call the library? 2)

Dear lazy web,

thanks for voting the best name for the library that helps implementing the Units Policy of Ubuntu. The winner with the most votes has been libkibi. There was one suggestion that got my attention: libbyteprefix. The suggestion came too late to have a chance. Therefore I ask you again to vote for the library name, but this time only these two names are open for voting: libkibi and libbyteprefix. libkibi is short and sounds good. On the other hand, libbyteprefix describes exactly what the library is supposed to do.

I was asked to use a free (as in freedom) poll-service. So please go to the Selectricity unitspolity vote and select your favorite. Thanks.

Poll: How to call the library?

Dear lazy web,

I am writing a library that implements the Units Policy of Ubuntu. This library can be used to format sizes (of files, disks, memory, etc.) for displaying them and the other way around. For example, the size 12345 bytes can be formatted to 12.3 kB, 12.1 KiB, or 12.1 KB depending on the configuration. An other function will give you the possibility to convert 12.3 kB, 12.1 KiB, or 12.1 KB back to 12345 bytes. The preferred binary unit can be configured by an text file (per system and per user) and by an environment variable. The library is written in C and doesn’t have any dependency. Therefore it can be used by any program on any desktop environment. Binding to other languages like C++, Python, Java are planned.

Before creating a project for this library, I need a name for the library. The current prototype is called libdisplayunits, but this name reflect only the half of the project. It does not indicate that the library can be used for inputting sizes. What do you think? What is the best name for the library? Please poll and/or comment below.

Daily builds rock, but bzr imports suck

Ubuntu‘s development platform Launchpad recently gained the ability to create daily builds. BzrBuilder is used for creating source tarballs and PPAs are used for building the source tarballs. BzrBuilder uses a recipe that declares how to build a source from different bzr branches. In most cases you have a bzr import from the upstream version control system. Then you nest a bzr branch that contains the packaging information. This works great for

but the bzr import for these projects fail:

  • Audacious: Import fails with infinite recursion (LP: #519709)
  • Eclipse: Launchpad disallows valid CVS module of ‘.’ from being imported (LP: #594294)
  • VLC: Code Imports does not support submodules (LP: #402814)
  • XMMS2: Code Imports does not support submodules (LP: #402814)

How many packages have you sponsored?

How many packages have you sponsored in the maverick release cycle? Check your mailbox for mails that have a header starting with [ubuntu/maverick]. Then subtract the number of own uploads (you can find them on the Uploaded packages site on your Launchpad account).

In my case, I have uploaded 45 own packages and sponsored 191 packages. That’s approximately four times more sponsored packages than own ones.

Is your ratio smaller than mine? Then go to the sponsoring overview and grab one bug and work on it. The code review process is described on the Ubuntu wiki.

Ubuntu 10.04 (Lucid Lynx) boots fast

A few  days ago, I installed Ubuntu 10.04 (Lucid Lynx) on my Super Talent Ultradrive GX 64GB (firmware version 1916 with TRIM support) and rebooted it thirty times to get some data from bootchart. Here are the results: The fastest boot took only 3.65 seconds. Impressed?

Click on the image for the full bootchart.

The default installation averages out at 4.5 seconds. The highest disk throughput was 204 MiB/s (thanks to ureadahead).

Click on the image for the full bootchart.

After everything was installed, the boot takes six seconds (probably due to liferea).

Click on the image for the full bootchart.

A SSD leads to a fast booting system, but then the processor has an impact on boot times too. Compare these boot charts with the one of the IBM ThinkPad T400. The SSDs are similar, but the processors differ: Core 2 Duo E8500 @3.16GHz versus Core 2 Duo T9400 @2.53GHz.

Do your system boots faster?

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.

Cons:

  • 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.

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).