Matthias Hopf

In my talk (or rather: structured discussion) "Methods of Attraction: How to bring in new contributors" on this year's X.org Developer's Conference I brought up reasons why open source projects often fail to attract new contributors, and some changes to help this.

During the discussion it turns out that for X.org the changes are either very non-trivial, or (better) somewhat implemented already (like the list of low hanging fruits, which basically boils down to our ToDo list and the Janitor subproject).

I didn't really expect any direct outcome from this discussion (as it's more like a meta discussion because we need to understand the real issues first), but I think it was fruitful especially in keeping everybody aware of the situation.

One interesting aspect regarding our (very) low female contributor ratio was brought up by Brian Cameron: The Gnome project has an apparently successful program to promote contributions of women in their project. Something to be checked out in the future, maybe X.org can join forces or set up something similar.

Yesterday was my last working day at SuSE Linux Products. After exactly 7 years of working for this awesome Linux distribution there was an opportunity I couldn't refuse. I made innumerable friends in this company (and it's the people that define a company!), and there were many great moments that will stick in my memory forever  .

Now I'm moving (back) to academia, and will start teaching and researching at the Georg-Simon-Ohm University of Applied Science, as "Professor for Applied Computer Science" (which is the official job title).

Currently, it's the free period of the summer semester, and the University is almost deserted. I'm currently only starting to get used to the new environment, prepare courses, meet with other professors, etc.

I'm pretty excited about the new opportunities in this position, and will keep you posted how everything turns out!

Now back to Fantasy Film Fest again ;-)

During our work in our preload department at SuSE we have to install our current image on several machines for each image version for smoke testing, which meant burning several DVDs per iteration (and there is typically one iteration per week!).
In order to ease this work flow I created a kiwi image for a CD or an USB stick for installing the latest image via network - the Network Image Installer. It's also capable of installing arbitrary openSUSE / Fedora / Ubuntu versions, so you never have to burn another DVD if you have a reasonably fast internet connection. Network detection is automatic, wireless requires the SSID etc. changed in a config file beforehand.

Find the sources on gitorious, I will eventually try to understand the functionality in the openSUSE build service to create images automatically, but for now you'll have to build the image yourself. I'll post when there is a downloadable image available.

Now I'm off to Fantasy Film Fest again .

We at SUSE needed to know whether we had some severe regressions regarding graphics performance during enablement of intel SandyBridge graphics - and it turned out that it was not commonly understood what graphics performance is actually composed of. Some were only interested in core X commands (xterm users :-) , some only in render performance (office users :-) , some in low-core 3D graphics (compiz users :-) , some in hardcore 3D graphics (gamers :-) .

So finally I put together a standardized graphical benchmark with aspects for all users. And no, it won't output a single number, because that would be meaningless for everybody. But it makes it easy to compare different aspects between different graphics cards and drivers, and there are some surprising results. But more about the results later.

The sources for the benchmark are now on gitorious, and the Wiki entry describes its usage. It's currently somewhat tailored to SLE11SP1, so you might run into minor issues when running it on a different OS version. And of course, it's not very polished yet .

Due to the amount of spam I'm receiving as comments I had to disable most of the comment functions of the blog. If you want to add a reasonable comment and have difficulties doing so, please just mail it to me, I will publish it.

Sorry for the annoyance, but it's better this way. Given that I'm not blogging too often, this shouldn't be much of an issue anyways.

While starting to implement error resilience (not erasure resilience, which is already working nicely) in my RAID-lookalike multi-disk block device RAnsrID, I finally had to notice that I didn't understand one aspect of Galois Field mathematics - the Reed-Solomon representation type has heavy influence on how to deal with errors (read: corrupted data).

So far, I only understood the canonical matrix style representation (basically a linear combination over the data disks for each redundancy disk). Turns out that with polynomial representation you can create way better (read: faster) algorithms for error correction - according to my analysis, erasure and error recovery is O(N²), compared to O(N³) for erasure correction in the linear combination case, and unknown (presumably O(N³⋅M²)) in the error case (N: total number of disks, M: number of redundancy disks).

Thus I will rewrite the redundancy routines based on Phil Karn's Reed-Solomon implementation - the best implementation with an open license I could find. Most implementations (like in par2) don't bother with error correction, and use block-level checksums to detect errors. That done, erasure recovery can be used. Needless to say, this is no option for my block device (where and why should I store the checksums).

No need to say that this delays delivery timeframe of RAnsrID further; especially as I'd like to incorporate the change in an at least data preserving backwards compatible way.

Also Hackweek 6 wasn't as productive as I hoped; I only managed to get the test suite up and running. Oh well.

Our group is now in HackWeek 6, quite a few weeks delayed after all other groups at SuSE. I will use the time to (finally!) continue work on RAnsrID - see also my initial blog entry. The project source is hosted on gitorious.

The basic redundancy routines are all working already, next is a usable test suite, then run-time configuration management (live adding and removing disks, live reconstruction w/o repair in the read error case).

I doubt I will reach a final version 1.0 I can recommend to use, but it will hopefully be close.

	I have a spleen for rather - say - exotic weekend activities (remember the R8 tour?). This time, two friends of mine and I went close to the middle of nowhere to the local blacksmith in Hallerstein (his web page is German only), for a two days forging course .
	The event was fantastic, apart from some major problems with the local power supply (the whole village went dark three times), so we had to setup a mobile power generator in order to power the fan for the smith's hearth. It went well, apart from the starter breaking on the first attempt to start up the generator (it was brand new ), but we were able to improvise.
	After a lot of hammering (also involving a pneumatic hammer we used for pattern welding for our Damascus steel knifes), and hours of grinding and polishing, every one of us was the proud owner of two self-forged knives, one of monosteel and one of Damascus steel.

It was an amazing experience, but you definitely need the help of an experienced blacksmith like our Axel, in order to get good results even on the first forging attempt. I guess I'll do it again, in the future. Maybe I will come home with a fully sized Katana next time .

As all members of X.org should have noted in the meantime, it's election time again! After some efforts we actually do have more candidates than seats for the board of directors .

Some community members have asked a (rather large) number of questions, I have consolidated the answers I received in this wiki page. So far only three candidates replied, so for me at least the top three candidates are clear - it's better to vote for persons that do have an opinion and voice it, than for persons who prefer to stay quiet .

So go to members.x.org and vote!

git is great for bisecting regressions (or finding a fix in a series of commits) - but compiling the kernel can take ages, especially if you have to do it on an Atom, and with the configuration of your favorite distribution...

Now finally I created a perl script for reducing the default config to the set of modules that are currently actually loaded. Reduces kernel compilation times on a quad core machine from 56 minutes to 6 for a standard SLED kernel Guess it's even more difference on this !@#$% Atom...

Usage:

# cd /var/tmp/linux-2.6	or wherever your git tree is located
# gunzip </proc/config.gz >.config	to get the current configuration
# make oldconfig	to add new options for current kernel
# ~/linux-adaptconfig.pl >.config.new	to remove all not required options
# mv .config.new .config
# make oldconfig	to be on the save side...
# make -j5	build, mother*beep*, build :-)

Yes, it's a hack. No, it's certainly not perfect. But it might be exactly what you had been waiting for. I waited long enough to actually write it myself...