Archive for the 'GNOME' Category

GNOME and Rust

I’ve been keeping an eye on Rust for a while now, so when I read Alberto’s statement of support for more Rust use in GNOME, I couldn’t resist piling on…

From the perspective of someone who’s quite used to C, it does indeed seem to tick all the boxes. High performance, suitability for low-level tasks and C ABI compatibility tend to be sticking points with new languages — and Rust kills it in those departments. Anyone who needs further convincing should read up on Raph Levien’s font renderer. The usual caveat about details vis-a-vis the Devil applies, but the general idea looks exactly right. Rust’s expressiveness and lack of baggage means it could even outperform C for non-trivial code, on top of all the other advantages.

There are risks too, of course. I’d worry about adoption, growth and the availability of bindings/libraries/other features, like a good optional GC for high-level apps (there is at least one in the works, but it doesn’t seem to be quite ready for prime-time yet). Rust is on an upwards trajectory, and there doesn’t seem to be many tasks where it’s eminently unsuitable, so in theory, it could have a wide reach: operating systems, platform libraries, both client- and server-side applications, games and so on. However, it doesn’t appear to be the de facto language in many contexts yet. Consider the statement “If I learn language X, I will then be able to work on Y.” Substitute for X: Java, Javascript, Python, ObjC, C, C++, C# or even Visual Basic — and Y becomes obvious. How does Rust fare?

That is, of course, a very conservative argument, while in my mind the GNOME project represents, for better or worse, and C use notwithstanding, a more radical F/OSS philosophy. Its founding was essentially formulated as a revolt against the Qt license (and a limited choice of programming languages!), it was an early adopter of Git for version control, and it’s a driver for Wayland and Flatpak now. For what it’s worth, speaking as mostly a downstream integrator, I wouldn’t mind it if GNOME embraced its DNA yet again and fully opened the door to Rust.

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.

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.

It’s not a picnic table, part 2

As a followup to my previous GHashTable post, Benjamin encouraged me to time the swfdec test suite - “make check” in the tests dir is consistently 4% faster with the patch.

Also, I have patched packages for our brave openSUSE Factory users: 1-click install