Munich’s big square computer

I noticed this post about Munich’s new LRZ supercomputer in Garching on Moritz Angermann’s blog. Looking at this photo (webcam apparently, so maybe you can only see it in the daylight), there’s something faintly absurd about it. Apparently this big cube building (at the right) is the computer, or can be perceived as the computer because it’s dealt with remotely. This might be a picture of the inside, but I’d still rather think of the building as the computer. It’s just a very big computer, you see.

I’ve never been to Garching, but I keep meeting clever people who work there.

German mini job

If there are any German GTK+/gtkmm/GNOME developers out there who’d like a few hours of part-time employment per week. maybe alongside their studies, please email me. I can’t offer much, and it might not last forever, but it’s probably better than the crap you’d have to do otherwise.

Debian soname/suffix/0c2a/thingy overview?

This is a slightly modified version of my email to the maemo-developers list, in case a Debian person can clear this up for me:

When creating maemo packages, we will tend to take the debian or Ubuntu package and modify it for maemo. However, for C++ libraries, and maybe C libraries, the latest Debian or Ubuntu soname might not be appropriate.

In this context, the soname is the package suffix, such as 0c2a seen in the http://packages.debian.org/unstable/libs/libsigc++-2.0-0c2a>libsigc++ package.

I believe that these suffixes are changed whenever either

  • A new version of g++, with a new C++ ABI, is used.
  • A new version of libstdc++, with a new ABI, is used.
  • A new version of glibc, with a new ABI, is used.

I don’t know what the 0, c, 2, or a parts of the suffix mean, or if suffix is just changed arbitrarily. I can’t find an overview of these in the debian documentation, so I don’t know what might be an appropriate soname for maemo’s own mix of ABI.

Women in Open Source #2

I am very proud of GNOME (and our new decisive GNOME Foundation board) for the initial progress we’ve made on the lack of involvement of women in our project. The discussion has opened a lot of peoples’ eyes to a problem that they didn’t recognise before, and we’ve already taken some steps to deal with it:

  • GNOME’s Women’s Summer Outreach Program (WSOP): 6 mentored projects (3 more than planned, thanks to Google’s support) bringing Women into our community. The quantity and quality of the applications surprised many of us, and is great ammunition against the “women are biologically incapable/predisposed” loonies. For the regular Google Summer of Code, I had 1 application for a Glom project. I had 5 for WSOP, some of which were very experienced already, though not in open source.
  • GNOME’s Code of Conduct (or “Ethics”, if you prefer) looks likely to become official, reinforcing our existing inclusive and tolerant community, and advertising it to the people looking for a chance. I just need to find a readable version of that inspirational first sentence. Suggestions are very welcome.
  • What’s next?

Now I’d like to start seeing more women on Planet GNOME and GNOME’s Planet SOC (Update: Planet WSOP 2006). I’m encouraging my WSOP applicants to get involved even though their applications weren’t approved, and they do seem more interested in that than the money, so I have high hopes. I’m suggesting that they start blogs, or that they mention their experiences on their existing blogs, and that they try to be involved in the existing mailing lists (such as gnome-love) while they are also getting direct help from me, setting up their development environments and learning about the project. While not wanting to scare them away, I’d like to get them involved with GNOME’s community as soon as possible, because that’s what makes people stay, and what keeps them learning.

There’s also been a lot of Pangolossianism from men during the discussion, along the lines of women not being generally biologically capable, or not being generally interested, and . This is the same 19th century nonsense that said that the poor were poor because they should be poor. Like most prejudice and conservatism it’s generally justified by selective anecdotal examples and resists contrary evidence. This always displays a fantastically selfish lack of empathy or imagination when confronted with the actual numbers.

Since seeing those discussions I am more convinced than before that there’s some real problems to solve, and I’m glad that we are solving them. And when women can help each other then they don’t have to waste time persuading men about this anyway.

Update: I forgot to mention, I was particularly persuaded when someone mentioned that, while female involvement and achievment in the sciences and mathematics is low in most schools, all-female schools have higher achievement rates in these subjects than the men in those regular schools. Obviously there are other factors in these schools, but it shows what is possible, and what should be possible without creating special environments. Anyone have a link to an actual study? – presumably the statisticians have tried to take account of details such as selection bias.

Real Optimization

GNOME’s performance-list mailing list is very high signal at the moment, though the archives seems to have lost emails for a few days.

These test results and suggested workaround/fixes are worth a gazillion viciously uninformed osnews or IRC discussions. Here’s a summary of what I’ve noticed recently though I can’t find the exact archive URLs for the stuff that I remember seeing, so this is full of errors that should be corrected in the comments so I can update it:

  • Workarounds in GTK+ to use the older GDK instead of Cairo, to test whether cairo is responsible, and as workarounds if there are cairo problems to be fixed. At least one of these changes seems to have a noticeable effect, at least on non-FPU hardware.
  • Text drawing optimizations: There might have been a slow down in text rendering (maybe in freettype?), and this might even be more of the cause of the GTK+ 2.6->2.8 slowdown than the use of Cairo.
  • Cairo optimizations: I’m pretty sure that I’ve seen some talk of patches optimizing small but significant parts of Cairo, but I can’t find them now.
  • GTK+ subsetting. Matthias has some patches for embedded environments that cut the GTK+ code size down by about 15%, by omitting unnecessary API, saving a couple of hundred K. (gtkmm has had this for a few weeks now, offering significant code size and runtime savings.)
  • Nokia’s 770 Internet Tablet versus floating point calculations: The 770 doesn’t have an FPU (floating point unit), so any use of floats leads to a big slowdown, even if it’s just passing a float through the API. This is unlikely to be responsible for a big slowdown seen on the desktop, but when they fix this on the 770 then they can start looking more at other optimisations that will help the desktop too. Note that the OLPC does have an FPU.

As far as I can tell, the jury is still out on whether Cairo is the change that made GTK+ 2.8 slower than 2.6, and it’s still not entirely clear whether 2.8 is indeed slower than 2.6 on regular desktops. Note also that Cairo hasn’t had much optimization work until now so there should be lots of easy optimizations. But performance-list is figuring all this out.

You can thank OpenedHand, Carl Worth, Matthias Clasen, and the others (not me) for getting this done.

As usual, these all seem like small parts of the code that have a large impact and that can be relatively easily fixed. I continue to believe that this is almost always the only meaningful form of optimization. Optimization by design is rarely possible other than by just trying to avoid well known problems and trying to generally allow room for optimizations in future. Amost all projects whose primary aim is to be fast or small end up being unusable, unmaintainable, or incomplete, though exceptions to this rule should be possible.

gtkmm 2.9/2.10 API almost done

Yesterday I released gtkmm 2.9.8, with GNOME 2.15/16 API freeze approaching on July 16th. Mostly everything is done, apart from a problem with the custom print preview, some of the TextBuffer serialization API, and an improvement to the recent files example. So, C++ people, do look at the new API, because now is the chance to fix it. Later it’ll be stable ABI and you’ll have to live with it.

There’s lots of new API in GTK+ 2.10, and users of gtkmm should be incredibly grateful to some new contributors who did most of the hard work:

  • Marko Anastasov, who has single-handedly wrapped all of the new printing API, written examples, and even written a printing chapter about it in the gtkmm book, all according to my pedantic standards. He has very quickly figured out how gtkmm works, and how it should look.
  • Armin Burgmeier also did most of the recent files API, with help from Marko.
  • Jonathan Jongsma (who should be on Panet GNOME) covered lots of the bits and pieces that were left over, while also steering cairomm to API stability, improving our documentation, restyling our website, and generally looking a lot like a future gtkmm maintainer.

gtkmm documentation: Wrapping C libraries

I just uploaded a new appendix to the gtkmm book, on wrapping C libraries, including all the tedious search/replace details of setting up a directory structure, creating the various .defs files, and some of the common problems. I did this while wrapping a simple C library for a customer who also wanted to have the documentation.

In other news, Dodji (his real name, I discovered at GUADEC), figured this all out for himself and created excellent C++ bindings for gtksourceview – gtksourceviewmm. He probably wishes that he’d waited. I’ll use gtksourceviewmm in Glom when I get around to branching for new features.

9 to 5 GNOME

There’s a lot of employment opportunities out there for GNOME developers at the moment to do embedded stuff. That’s a nice reward for all your contributions, and a chance to spend your time on something you love. I personally know of the following:

And I am tempted to try to hire someone cheap in Germany. I have a little more work than I can handle by myself, but I’m not sure that I have enough to cover two incomes. And German taxes make employment quite expensive for small businesses, not leaving much left over for the employee.

Back from GUADEC & Barcelona

On Monday evening I returned from Barcelona where I spent the weekend after the GNOME conference. I’ve just about caught up with the stuff that stacked up during the week away, and I hope to have a full night’s sleep some time soon.

I noticed that I was getting very little email while at GUADEC, and for a while I believed my theory that nobody was sending me email because everyone was already at GUADEC. But when I examined my Junk folder at home I realised that switching from SpamAssassin to Bogofilter on the first day had not been completely painless.

But along with my complete lack of responsibility this year (no board, no release-team, no guadec organisation), I think that helped me to enjoy the event. I actually went to talks and learned from them, and just hanging around meant that I met far more people than ever before at GUADEC. I’m not going to mention you all because the list would be huge, but I love you all and enjoyed meeting and talking with you. I like the GNOME people so much that I often really wish that I lived in a town like Boston, Barcelona, or Portland (and Helsinki now too), where there are large clusters of them that can see each other regularly.

Reading Planet GNOME while at GUADEC was a wonderfully positive experience, and it’s clear from the mass of photos that we are not your average hackers. GNOME is people. Without meaning to, we just did some great advertising of our core purpose. This is something that people want to be part of.

Lots of people gave me encouragement for my work on Glom, and showed me a few more bugs that I need to fix in version 1.0. I may have recruited a few people to help with some of the simpler tasks. My talk was a disaster because I couldn’t get my (cheap) laptop working with the projector, and had to wait for the disk check before I could even copy the slides to Christian Kirbach’s laptop. Daniel Holbach had Glom running on his laptop so I could show that to a small group of enthusiasts at the end. People seem to appreciate the concept and are reassured by the ability to extend Glom systems by using Python and PyGtk or by using Postgres directly. Now I just need the time/money to fix the bugs and add the features.

However, because I put all my ever-decreasing free time into maintaining gtkmm (fairly repetitive work that’s more responsibility than excitement because all the hard problems are long solved.) and Glom (exciting work that’s not yet widely known), I always have a guilty sense at GUADEC of not contributing enough.

Over the weekend I had a chance to play with my new (ridiculously expensive toy) wide-angle lens. I’ll need lots more practice.

Sigi, Fiona, Matthew Garrett, Robert McQueen

IMG_1052

GNOME API/ABI Stability document 90% done – help needed

Last year at GUADEC I promised to help the SUN people make their (lengthily vague) API/ABI stability documentation requirements meet up with GNOME’s API/ABI stability practices, so everyone can learn about the good stuff that we do, and so we can recommend some minor improvements. We almost got there.

But the draft document is still not quite ready. The main issue is the library versioning section. I’ve listed some of my confusion there. As far as I know, GTK+ just doesn’t use it because it’s more trouble than it’s worth. When I’ve tried to follow the instructions for using it in the past, I’ve caused ABI problems when I just wanted to say “here’s some new ABI that doesn’t break the old ABI.”. So I’d like either a knowledgeable explanation of why it should be ignored, or clear examples of how to use it. Feel free to fill up the comments with clues.

The next GUADEC is upon us, and a year seems too long to get this done.