Code name for Ubuntu 18.04 LTS

Every Ubuntu release gets an alliterative code name from Mark Shuttleworth. It is a composition of an adjective and an animal. The upcoming Ubuntu 13.04 has the code name “Raring Ringtail”. Since nearly the beginning, the code names follow the alphabetical order. We will reach the letter Z with Ubuntu 17.04 if no letters are skipped. Will we wrap then and begin with A again?

At UDS-R in Copenhagen, Mark Shuttleworth jokingly said between Jono Bacon’s introduction and Mark’s keynote speech, that vegetables will be used once we run out of letters. He proposed the code name for Ubuntu 18.04 LTS: Brilliant Broccoli!

System cleanup

Tonight was system cleanup day. Baobob showed me where are the gigabytes hide. The home directory got rid of huge, old VCS checkouts of various projects. Then it was time to look at the system directories. I cleaned my apt cache

sudo apt-get clean

and the cache from pbuilder. Then I found something that lead to this blog post: /var/log consumed 3.8 GB. The biggest files were

1.8 GB /var/log/kern.log
1.8 GB /var/log/syslog
4.3 MB /var/log/dpkg.log
1.4 MB /var/log/kern.log.1

Hardware review I

This month I built two systems with identical hardware component (except for the case). Here’s the list of components:

Cases often don’t meet my high requirements. Many cases are sharp-edged, bad designed (inside and outside), use cheep plastic, and/or vibrate, because the hard drives confer their vibration to the case. The Sugo SG02-F case is not perfect, but I will recommend it. The Silentium T11 case has no shard edges, but I won’t recommend it. Too much plastic and optical not appealing.

You probably have to replace the boxed CPU heat sink and use a better power supply if you want a silent system.

How well do these components work with Ubuntu 10.10 (and probably other recent GNU/Linux distributions)? Perfectly. Everything that I tested worked:

  • The USB 2.0 and USB 3.0 ports work with everything plugged in (mouse, keyboard, flash drives).
  • Audio works (only stereo output tested; 5.1 sound was available in Pulseaudio)
  • 2D and 3D graphics work with the free (libre) radeon driver (Compiz runs)
  • LAN works

How to purge Wine completely

I had Wine installed and wanted to get rid of it completely. I removed the Wine Debian package and what belong to it, but the Windows applications still appeared in the GNOME main menu. I removed the .wine directory and all local wine-related desktop files:

rm -rf ~/.wine ~/.local/share/applications/wine
rm -f ~/.local/share/applications/wine-* ~/.local/share/applications/mimeinfo.cache

Now there is no sign left that Wine was installed.

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.