Archive for the 'Computing' Category

New toy


I got a new toy. It’s a WASD keyboard with Cherry MX Clear switches. The picture doesn’t do it justice; maybe I should’ve gotten a new camera instead… I guess it’ll have to wait.

Mechanical-switch keyboards are pricey, but since I spend more than 2000 hours a year in front of a keyboard, it’s not a bad investment. Or so I’m telling myself. Anyway, it’s a big step up from the rubber dome one I’ve been using for the past couple of years. The key travel is longer, and it’s nice to have proper tactile feedback. Since the Clear switches have stiff springs, I can also rest my fingers on the keys when daydreamingthinking. It has anti-slip pads underneath, so it stays put, and it doesn’t bounce or rattle at all.

Until our last move, I clung to an older, clicky keyboard (I don’t remember which brand — I thought it was Key Tronic, but I’ve a hard time finding any clicky keyboards of theirs at the moment), worried that the future held rubber dome and chiclets only — but today, there are lots of options if you look around. I guess we have mostly gamers and aficionados to thank for that. So thank you, gamers and aficionados.

I did plenty of research beforehand, but WASD finally drew me in with this little detail: They have some very well thought-out editable layout templates for SodipodiInkscape. Good taste in software there.

Year of the Linux Desktop Debate

It’s been interesting following the recent discussion about the Linux Desktop and how it failed. It’s a notion that’s been around for some time - I’d say approximately since people tired of discussing whether next year was going to be the Year of the Linux Desktop or so. Painful as it is, it’s also a notion that needs to be discussed, so we can learn from it or at least try to put it to bed.

Sometimes I feel like we’re talking past each other, though. As with any discussion, it’s a good idea to define what we’re talking about:


Most of us use the term “Linux” very loosely (just ask RMS). For instance, it can refer to:

  • Linus’ kernel tree, or the tree of some other well-respected Linux maintainer.
  • GNU/Linux proper, including the much-loved userspace.
  • Anything based on a lightly modified Linux kernel - this is what GNU/Linux distributions tend to ship, but it also appears in routers and all kinds of embedded devices.
  • Anything based on a Linux-derived kernel, including heavily modified/forked Linux kernels - the Android kernel comes to mind.


As it happens, we also use the term “success” (and conversely, “failure”) very loosely. It reflects who we are and what we want to achieve with Linux, e.g:

  • Works-for-me. A solution that works well for ourselves and for some of our friends. Also known as “itch-driven development”.
  • Works-for-everyone. We tend to define “everyone” as people who have requirements different from our own - often typified as parents, grandparents, spouses, and so on. Whether these demographics will end up using it is seen as a separate problem. Maybe if you build it, they will come, but it’s not a requirement that they do so.
  • Engineering excellence. A product of inherent beauty, often the result of some design process/criteria, but not necessarily addressing a specific problem. Sometimes you will see this masquerading as works-for-everyone, but you’ll be able to tell it’s about excellence by its uncompromising nature.
  • Commercial ecosystem. A big, commercial ecosystem built around Linux, often expressed as market share or total revenue generated by sales.
  • Big user base. Similar to commercial success in that it emphasizes quantity and popularity, but usually with the aim of enabling freedom/free culture instead of business models.


This used to mean something like “a top-level graphical user interface with a file browser and application launcher”, but user interfaces have become more diverse, and it might make sense to include media libraries, smartphone interfaces and other environments where you can’t explicitly browse files. We’d have to draw the line somewhere, though - I doubt my router’s configuration UI would make the cut.

What do you want from (GNU/)Linux?

Depending on your perspective, Desktop Linux may be a failure - and if you were expecting to put GNOME in front of a majority of the population of planet Earth, it certainly is.

In many other ways, it’s a success. It’s been a test bed for a very capable free library stack, including GLib, GTK+, Cairo, Pango, D-Bus, GVFS, GStreamer, and more recently, Clutter and Cogl. This is not trivial. The surrounding community has also grown and diversified, and it has nurtured individuals and groups who’ve gone on to do some pretty sterling stuff.

Post scriptum

I think a desktop built on the GNOME platform could still be a moderate commercial success if integrated and marketed skilfully, perhaps tied to some kind of hardware. The window of opportunity hasn’t closed - the UI space is fragmented, Windows 8 is coming out, Valve have announced Steam for Linux (shiny games!) - and our building blocks are better than ever.

Hash Table Shootout!

It’s gratifying to see GHashTable faring not-too-badly against an assortment of other hash table implementations in Nick Welch’s excellent benchmarks. I did some work on this previously, but there’s at least one thing that can still be done to reduce its memory footprint on 64-bit architectures. The table is a big array of structs that look like this:

struct _GHashNode
  gpointer   key;
  gpointer   value;
  guint      key_hash;

The key_hash is useful, as it lets us skip over mismatches and resize the hash table quickly - and on a 32-bit arch, it adds only 4 bytes to every entry, for a total of 12 bytes. However, on a 64-bit arch, it causes entries to be padded so that each entry starts on a multiple of 8 bytes. That wastefulness can be remedied by packing key_hash values in a separate array - as a bonus, entry size becomes a power of two, which means offsets into the array can be calculated using a single shift. On the downside, we’ll incur the added overhead of maintaining two arrays and accessing an extra cache line for each lookup. I suspect it’s still worth it, though.

A couple of open questions/comments on the benchmarks themselves:

  • Google’s dense_hash_map is suspiciously fast at integer deletion - is it shrinking the hash table at all, re-inserting the remaining items as it should? Or does it have some other trick up its sleeve?
  • How robust are the different strategies with respect to poorly distributed keys? E.g. N*2^M spaced integers: 1024, 2048, 3072, 4096, etc.
  • How about poor hash functions supplied by the API user? GHashTable attempts to tackle this by calculating the initial array index modulo a prime number, before applying a quadratic modulo on subsequent probes (faster, and required for quadratic probing).
  • What’s the per-table overhead? How much memory will, say, some 100.000 tables with <100 items each consume? This is not uncommon in practice - nested hashes are often used to store complex properties, and given suitably large working sets, this can become a significant factor for some programs.
  • Are the approaches affected by memory fragmentation? Do they cause it? This is hard to measure; maybe many tables could be grown simultaneously in the same address space.

openSUSE community week

Be sure to check out the openSUSE community week currently underway. The GNOME-centric part of the community has its own program for the week.

Shoveling snow

The snow-shoveling I’ve been taking part in over the last couple of weeks is best described with a set of graphs:

openSUSE boot time improvements on netbook

So far, we’ve been able to lop about 23 seconds - or 48% - off the time it takes to boot openSUSE 11.1 on this particular netbook, without sacrificing much in the way of functionality. It boots straight into GNOME and its usual trappings, including the panel, Nautilus, “slab” main menu, nm-applet, PackageKit updater, printing applet (written in Python…), CUPS, etc.

It’s important to note that this time is measured from the moment bootchart starts until everything settles and is ready to use, easily identified in the chart as the moment where CPU activity falls to the baseline of noise from bootchartd itself.

It’s also important to note that this is on a netbook with a slow CPU, slow-to-init X driver/graphics hardware and fast SSD I/O. I’m hearing a lot of numbers being bandied about these days, e.g. “distribution Foo boots in 10 seconds”, and these numbers are meaningless without hardware specifications and a list of features you get. GNOME delivers a different feature set from Xfce, and netbooks and workstations usually perform very differently. Then there are questions of flexibility; is the system open-ended? Can you get server features by just installing packages and configuring them?

IMO, openSUSE has had unacceptable boot times on workstations for a long time now. Hopefully these changes will make it into future releases, upstream where possible.

For more details, see the wiki page. Note that for various reasons I haven’t been able to keep the text up to date. The graphs are representative, though.

ENLi 2008

My talk, La comunidad GNOME para principiantes (The GNOME community for beginners), seems to have gone over well here at ENLi 2008 (the 2008 National Linux Meeting in Puebla, Mexico), with a big audience and interesting followup questions. The slides are available as a collection of plain PNG and JPEG images in a zip archive (use the link above).

I’m having an excellent time. Will post some pictures from the conference later.

Update: Pictures.


My wonderful audience

openSUSE discs

I clearly didn’t bring enough openSUSE discs

Evolution goodness (and some badness)

My laptop went south a couple of days ago, so I’m having to make do with a screen that is bigger but endowed with fewer pixels. This has been a source of frustration, especially in Evolution, where I depend on the efficiency afforded me by the tri-pane view. Crank down the resolution a bit, and it’s suddenly not so efficient - there isn’t enough space to display the subjects in the message list anymore. The problem is compounded by useless mailer “Re:” and mailing list prefixes.

So, since I don’t need to see the mailing list and reply status repeated for every single mail, I cooked up a little patch to trim the subjects in the message view. When applied, it makes available a new column in View -> Current View -> Define Views… -> Edit -> Fields Shown… -> Available Fields. This column implements the trimming, and can be used instead of the traditional Subject one:

Evolution, traditional subjects Evolution, trimmed subjects



The patch applies to both Evolution 2.22 and 2.24, although unfortunately, a couple of nasty, new bugs are preventing me from running the latter. If you happen to be running openSUSE Factory like me, and Evolution 2.24 is preventing you from getting work done, you can get my unofficial 2.22 build for Factory from the build service. It includes the above patch as an added bonus.

GDK indirect rendering backend online

I just finished touching up that GDK backend for rendering toplevel windows to Cairo image surfaces I briefly presented at GUADEC. It now compiles with the latest GTK+ trunk, and it even has a page with instructions for how to check it out and build it. There are some examples too.

With time, I can hopefully get this to production quality levels.

More GUADEC, Istanbul

A day and a half left of the conference. Some pictures from the awesome, Collabora-sponsored Bosporus cruise, sightseeing, etc. below. Everyone seems to be having a good time.

Bosporus cruise Istanbul bridge Castle Mosque Another mosque Cats everywhere Clemens and Federico

Fun at GUADEC 2008

Tram in istanbul

At GUADEC 2008. Istanbul is a fun and interesting place, and the talks aren’t all that bad either. Not much time to write or code, though.