Recently I mentioned Paul's rule of thumb:

A new developer within a given project will remain an active developer if they commit in each of their first three weeks.

So, firstly, this is wrong. What I meant to say was:

A new developer within a given project is more likely to remain an active developer if they commit in each of their first three weeks than if they do not.

At the time, this was based upon observation of a visualisation of KDE SVN commits. Is it possible to throw some stats at this and show how accurate a statement this is? Of course it is... (please don't run away)...

Question:
How likely is it that a developer who commits in each of their first three weeks will remain more active than a developer who doesn't commit in each of their first three weeks?

Method
I shall randomly select 40 KDE SVN accounts: 20 that did commit in each of their first three weeks and 20 that didn't. For each account I will find the percentage of weeks they have committed in since joining; this shall form the two sample sets. I shall then compare these two sample sets using the Wilcox test. I won't tire you with the details of this, other than to say (in this case) the test will return low values if the first sample indicates that it has come from a larger population than the second sample. In other words, a higher probability will indicate that people who commit in their first three weeks don't necessarily remain active for longer.

Results:

• Sample 1: SVN accounts committing in each of their first three weeks had continued activity rates of (%): 35,17,72,64,30,64,5,65,63,42,73,30,100,3,15,72,10,4,84,10
• Sample 2: SVN accounts not committing in each of their first three weeks had continued activity rates of (%):0,0,24,2,0,0,16,31,21,0,1,9,47,2,5,3,6,3,6,36

The Wilcox test applied to these two samples produced a probability value of: 0.0001031.

Answer:
A KDE developer who commits in each of their first three weeks is 99.98969% more likely to remain active for longer than a developer who doesn't (based upon these samples).

So it's not far off the probability of death and taxes.

Finally I’ve managed to finish the new cache for KDE card games

Until now the two card games that shipped with KDE Games in KDE4 both managed their own cache of rendered svg card decks. They’ve simply put the rendered images into png files in a special directory in $HOME/.kde4/share/apps. This has a few drawbacks:

• each card game needs to render the SVG at least once in the size needed
• wasted disk space if the same theme is used in both games
• a lot of similar code (almost duplicated)
• possibly some slowdowns because each frontside of the card deck was stored in a separate png file, so the game loaded 32-52 png files during startup

The new cache class is part of libkdegames, its called KCardCache and is rather easy to use. Simply store it as a member variable in your theme manager (or whereever your game currently renders the svg files) and then make sure to set the theme and proper size before asking it for cards. Some basic code may look like this:

mycache = new KCardCache();
KConfigGroup themeconfiggroup( KGlobal::config(), “Theme” );
mycache->setTheme( themeconfiggroup.readEntry( “Cardname”, “Oxygen (SVG)” ) );
mycache->setSize( themeconfiggroup.readEntry( “CardSize”, QSize( 60,80 ) );
QPixmap heart_ace = mycache->frontside( KCardInfo( KCardInfo::Heart, KCardInfo::Ace ) );

This would render the fronside for the ace of hearts into a pixmap which you can then use to draw on the board. Internally the cache uses the KPixmapCache class which was written specifically to cache pixmaps that need a lot of time for rendering. KCardCache uses different pixmap caches for each theme, but it allows to share the same cache among all kde card games that use it. So when you run KPatience and choose the Oxygen theme, the first time you run lskat and choose the same theme it already uses the cached images. Also KCardCache doesn’t need to read 52 PNG files because KPixmapCache stores all pixmaps in one data file instead of many.

As far as numbers go, I don’t have any. My feeling tells me that rendering during startup got a bit faster, but even if there’s no real noticeable speed improvement the other benefits weight quite heavily IMHO. Having the same caching code for all games, using a well tested cache implementation which is used all over KDE for icons and various other things and sharing the same theme-cache among all games is quite valuable in itself.

In 4.0 plasma had support for writing applets using Qt's built in javascript interpreter QtScript, but the facilities have been fairly limited. In KDE 3.x KJSEmbed gave us reasonably complete bindings to the Qt and KDE api's, allowing us to write applications such as a web browser in 10 lines of javascript. I'm glad to say that some plans that were discussed at the KDE conference in Glasgow are now a reality and Kent has released a qtscript binding generator based on the one used for QtJambi. The result is that we will very soon have good access to the Qt API from qtscript.

I've been playing with the output of the generator for a couple of weeks now and while it still has a lot of rough edges, it's definitely a solid foundation. Even better from my point of view as a KDE developer, the Jambi generator was designed from the start to allow you to use it to write bindings for Qt based code that is not part of the main Qt API. Using it to build bindings to the plasma APIs and in future the kdelibs API is definitely feasible.

After I had a beer with Klaas van Gend (the UMTSmon developer) and some members of the UUGN (that's from Seife: "umtsmon user group Nuremberg") two weeks ago, I hacked a little on UMTSmon.

Here what I did:

• added support to sort the content of QTable objects of the info dialog (bug #1616485) [1]
• fixed tabstop order for some widgets [2][3]
• reduce the really annoying flickering of the LCD widget in the main window, by use QWidget::setPaletteBackgroundPixmap() instead of QLabel::setPixmap() to draw the background image [4]

There are some ideas left to improve UMTSmon, some really nice features, we will see if and when I find the time to implement them ...

Tech Tags: Patches

I have not been blogging the last couple of weeks, so here is a condensed report of what I've been up to.

• Qtopia presentation at IT Universitetet, Gothenburg. Note to self, make sure to have water the first hour. Speaking for two hours, only sipping water the second half leaves you with a soar throat.
• Work, work, work - I've been working like a mad man the last weeks. One week in Lapland doing winter testing for an automotive customer (great fun, but still quite a few days away from home).
• Qt Quarterly dinner - a nice little event in Oslo. A rather loud restaurant, so it was hard to maintain a conversation, but still nice.
• Carpenting - the upper floor is beginning to look ready-ish. Will try to get the wallpapers up this weekend. Then it is just the floor, doors and details left.
• Driving - got my new car last week, a BMW 520d. It drives like a dream :-)

Well, now I need to work some more. Do not forget to watch the F1 next weekend. If BMW wins it must be due to my generous contribution. I hope that all the profit from my purchase is transferred directly to Dr. Thiessen's department.

I always check for changes in rpm files. Unfortunately, the command to do so needs some typing:

rpm -q --changelog PACKAGENAME|most

(Btw., most is a replacement for less). The best idea would be to have a bash/zsh/whatever alias with an argument. This is unfortunately difficult or even impossible, but it is quite easy to define a simple function:

rpmch () { rpm -q --changelog "$1"|most}

Copy that string to your .zshrc or .bashrc and you can easily query the changelog of rpm packages with the command

rpmch PACKAGENAME

This of course works for other commands as well.

Announcing a new project on Trolltech Labs: Qt Script Generator. It’s a tool that generates Qt bindings for Qt Script. Finally your scripts can go “new QPoint()” without you having to manually bind the world first! You not only get the Qt API, but also the possibility to “subclass” in script code, e.g.:

var w = new QWidget(); w.keyPressEvent = function(e) { print(e.key()); } w.paintEvent = function(e) { ... }

To use the bindings in your own app, you just compile the bindings plugins, put them in your library path and then go like this:

QScriptEngine eng; eng.importExtension("qt.core"); eng.importExtension("qt.gui"); // also available: qt.sql, qt.xml, qt.svg, qt.network, qt.opengl

Have a look at the examples to get an idea of what you can do. More examples to come.

The generator itself is essentially the Qt Jambi generator with a Qt Script backend. (Great job, Jambi guys!)

Although this project is still very young, we’re interested in hearing about any issues (functionality / performance / whatever) you have with the bindings. Have fun!

If you've been scanning KDE commits lately, you may have wondered about heavy activity on an experimental KJS branch, KJS/Frostbyte. Well, while it's still not 100% done (there are a couple bugs, and not all goals have been met yet), it's complete enough that I am comfortable to blog about it.

KJS/Frostbyte is a bytecode and performance improvement version of KJS, which aims to both provide an immediate speed up, and the infrastructure for further improvements. Right now, if I didn't screw up my notes, it's showing ~1.4x speedup over KDE4.0.2 version of KJS on the SunSpider benchmark suite.

Now, you might wonder why "bytecode" and "performance improvement" are two separate bullets. Doesn't bytecode usually mean "faster?". Well, in this case, only somewhat; much of speedup comes from other changes. KJS's traditional recursive nature matched very well with how ECMAScript is specified (ad hoc big-step operational semantics, basically), so it really didn't have much overhead.

The value of bytecode is more:

• It separates out the representation during parsing from the representation used during execution. This means they can both be kept as clean as possible. Previously, various optimizations would require things such as splicing of nodes (or the horrific, though clever, in-place replacement in JSC)
• It provides a much simpler, flattened program form to operate on and reason about, opening the possibility of doing fancier things in the future. A lot of the subtler trickiness in the language is made far more explicit, too.

To help with both, and to stay flexible, we do not hand-code the bytecode language. Instead, a description file with a list of IR types, instructions, etc., is fed to a special tool I wrote, Icemaker.
Icemaker converts that into:

1. The virtual machine main loop
2. Instruction description tables, which with some enhancement could
   perhaps be used to drive a dataflow engine
3. Instruction selection and conversion cost tables

Here, too, we have a layer of indirection, keeping things cleaner. For a subtraction operation, we can describe its bytecode merely as:

operation Sub { impl number(number v1, number v2) [[ $$ = v1 - v2; ]] }

Then, when compiling JavaScript into bytecode, we merely ask for an Op_Sub with given arguments. Sounds trivial? Well, it's not quite that simple, since the arguments don't have to be numbers. Using the tables Icemaker built, the instruction selection engine can automatically put in conversions, if needed. It can also do better than that, and pick a more efficient variant, if more than one is described:

operation BracketGet { impl value (value v1, value v2) costs 50 [[ // snip code ]] overload value (value base, int32 prop) [[ $$ = base->getByIndex(exec, prop); ]] }

With this, little tweaks to the IR can be tried easily, and specializations can often be done w/o even touching the compiler proper...

Coming up at some point later: some benchmark numbers... After I figure out what's wrong with this ScopeChainNode allocation optimization, anyway.

I've been quiet lately....

I'm moving out the Canary Islands, where I've lived my entire life (except for one year I lived in the US). A friend of mine, Ramón Ramón (yes doubled Ramón), has called me to help him in a migration project to free software of La Axarquía, a group of municipalities close to Málaga, where Akademy 2005 took place, in Andalucía, Spain.

I will keep working in some of the projects I'm in right now in the Canaries, like trying to bring Akademy to these islands in 2009. I'm also going to be directly related with Grupo CPD as much as I can.

This is the first time such a migration project takes place in Spain. It is financed by Andalucía's regional Gov. and the company ITD was the one chosen to do it (they have contracted me as freelance) and Emergya, a free software company from Andalucía, is also involved.

My role will be to make the previous evaluation of each municipality and make the design of the migration project. That should take a year.

In Andalucía, GNOME rules, so it will be tough to introduce KDE, but now we have another warrior to try it. I leave a place where KDE is the most popular free desktop (Canary Islands) by a region where GNOME is, by far, the most popular.

Anyway, since Windows is the target...everything will be fine :)

This is a new milestone in my professional career so I'm excited about this new challenge. I hope we can do something that have impact in this region of Spain. We have the willing, the knowledge and the people to do it. If the politicians and the public workers of these municipalities want, we can make the difference moving from propietary to software libre.

What a nice project...isn't it? I feel lucky these days.Agustín Benito Bethencourt (aka Toscalix) Blog in spanish: http://abenitobethencourt.blogspot.com Grupo CPD: http://www.grupocpd.com

It is one case to walk through 7000 pages of rather technical documentation and to try to extract something useful out of it for a concrete question. It is another thing to look at the actual XML produced by the Microsoft Office 2007 suite.

There we have the workbook as main entry-point for spreadsheets aka for what MS Excel flushes out. Such a workbook does contain normally general informations about the sheets, file-revision and so on. Now we know that something that may become ISO standard is at least vendor and application independent to be used by more then those who pushed for that standard, right? And hey, it's all XML (except things like the binary Printer-driver embedded in each OOX-document). So, it's open, right?

Within this main and initial entry-point I did run into a XML-tag that looks like this;

<workbookPr filterPrivacy="1" defaultThemeVersion="124226"/>

That's one of the very first tags someone has to deal with if he likes to do something with that format. So,
2 attributes that sound mysterious. But hey, that's why the 7000 pages specs are there, right?

So, on page 1919 of the "Office Open XML Part 4" PDF-document that is around 40MB big and does freez my
rather new AMD64 dual-core with 2GB of RAM for several minutes, is the description of both attributes.

The section about "filterPrivacy" says;

Specifies a boolean value that indicates whether the application has been inspected the
workbook for personally identifying information (PII). If this flag is set, the application
warns the user any time the user performs do an action that will insert PII into the
document. For example, inserting a comment might inserts the user's name.

Oha. So, it's another boolean flag and describes what the application should do during editing (hint: it's a file-format and not a guide how to implement the application itself). To be able to load+save that flag and those PII thing, I would need to know now more details what PII exactly is, where it's stored and how I am able to load it. But at none of the 7000 pages are any details about this Fine, only Microsoft knows...

Okeli, let's give up on this one. Well, to be able to load 50% (so 1 of 2 attributes) should be enough and it's still XML and open, right?

The section about "defaultThemeVersion" says;

Specifies the default version of themes to apply in the workbook.
The value for defaultThemeVersion depends on the application. SpreadsheetML
defaults to the form [version][build], where [version] refers to the version of the
application, and [build] refers to the build of the application when the themes in the user
interface changed.
The possible values for this attribute are defined by the XML Schema unsignedInt
datatype.

Oha again. Not only do I wonder about the unsignedInt datatype (in fact I didn't know before that XML is so much C/C++ like), but did I got it right, that those potential ISO-standard does contain details about "MSOffice Themes"? Wow, now that's really vendor-neutral and no ISO-standard should come without this! What a great idea to just just append all of /etc including there man-pages into something like e.g. the OpenDocument-specs. Man, we could blow up that documentation by a factor of 10 at least and everybody would waste there time by sorting those things out too!

I don't get why such application-dependend details are all over the place in the MSOOXML-specs. Would it be such difficult to at least extract them from the really useful things someone is able to implement? I mean, why should an ISO-standard contain such totally unimportant details only one vendor is able to implement?

Please ISO, don't push such trash on us. Everybody who's able to read those specs will see that they are just not ready yet. Do yourself and others a honor and abort the fasttrack-process. Let those specs go the regular way OpenDocument went through too. This really helps to improve the quality.

Updated: The Internet continues to be an impressing medium. Someone did point me to the Wikipedia article about PII. Now I am one step future, though not in the direction of a solution since I still need to figure out what it may mean in the context of this specification and most important: how to implement it the most compatible way?
Also interesting is, that unsignedInt as well as boolean are part of XML Schema. Any again something learned

In case the title has misled you, this post is completely free from satire, and is literally a step by step guide to trying out Decibel.

1) Decibel has some dependencies. You will need telepathy-qt and tapioca-qt compiled and installed to compile it. Some of the demos we are going to use also require a KDE4 development environment to be up and running.

2) You will need telepathy-qt and tapioca-qt from the tapioca-voip project (the versions in kdesupport are not yet supported by decibel). They can be got from the SVN repository by issuing the following commands:

• svn co https://tapioca-voip.svn.sourceforge.net/svnroot/tapioca-voip/trunk/telepathy-qt
• svn co https://tapioca-voip.svn.sourceforge.net/svnroot/tapioca-voip/trunk/tapioca-qt

Instructions to compile and build them are included in the file README files with each of them.

3) Get and compile decibel. Decibel is located in kdereview at the moment. It can be got by:

• svn co svn://anonsvn.kde.org/home/kde/trunk/kdereview/decibel

Again, compiling instructions are included. Make sure you compile it as you KDE 4 user.

4) Decibel itself cannot communicate with instant messaging networks. To do this, we need telepathy compatible connection managers. For this demo, we will use gabble. Install the gabble package that comes with your distro.

5) Now we need two jabber accounts to test with. Decibel can’t create the accounts on the server yet, so if you don’t already have two jabber accounts, you will need to use kopete (or your favourite instant messaging client) to create them. If you are looking for a jabber server, there is one located at kdetalk.net.

6) Once you have your two jabber accounts, you need to make sure they’re both friends with each other. Then, log in to one with kopete (or your favourite instant messaging client).

7) Now its time to start up Decibel. Open up a konsole and type ‘decibel’. If all has gone according to plan, the daemon will start and you will be presented with a KWallet dialog asking for your KWallet password. Once you have entered that, the decibel daemon should block the konsole (this makes debugging a lot easier than if it forks).

Now we need to register the second jabber account with decibel. At the moment, it is done by using one of the demos. Open another konsole and cd to $YOUR_KDE_INSTALL_DIR/lib/Decibel. This is the folder where th demos are stored. If you ‘ls’ in this folder, you should see a series of executable files whose names fit the pattern ‘decibel_*_demo’.

9) We are registering an account with decibel, so the demo we want to use now is ‘decibel_registeraccount_demo’. The command line you type should be the following, replacing [email protected] and yourjabberpass with the appropriate values. The ’s:’ before the values tells decibel to expect a string.

./decibel_registeraccount_demo account=s:[email protected] decibel_protocol=s:jabber password=s:yourjabberpass

10) Now that your account is registered with decibel, it is time to bring it online. To do this, we use the ‘decibel_setpresence_demo’. It should be called as follows replacing ‘handle’ with the numeric account handle returned by decibel_registeraccount_demo.

./decibel_setpresence_demo handle 2

If that worked correctly, your first jabber account running in your favourite instant messaging client should see your secondary account appear online.

12) The final step is to start a chat with your decibel jabber account from your favourite instant messaging client. If all the above steps have worked correctly, you should see a ugly little GUI pop up, allowing you to continue the conversation.

13) If no GUI appears and decibel spits out errors about .service files, try opening a third konsole and running ‘textchannelgui’ in it. This will register the gui with dbus in case the .service files are installed in the wrong locations.

14) Be warned, decibel is still using a rather old implementation of the telepathy-spec, so don’t expect your chat to work for more than a few messages. We are making rapid progress with getting decibel up to the latest spec, and I will blog again as soon as it is using that.

More information on using the decibel demos can be found on techbase.

If you are having problems, or even better, would like to help out, drop by #decibel and shout. There will often be someone there who can help you out.

From Jacqueline: List your five favourite artists, your five favourite songs by those artists and tag five other people to do it.

This took me all weekend to think about. I can’t commit that these are my favourite 5 artists and favourite 5 songs ever, but they are certainly in any top list I compile.

Nine Inch Nails

• Closer
• Hurt
• The entire The Fragile album
• My Violent Heart
• Meet Your Master

Tool

• H.
• Jimmy
• Lateralas
• The Grudge
• 10,000 Days

Radiohead

• Lucky
• Morning Bell
• I Might Be Wrong
• Where I End and You Begin
• There There

BT
Nothing of his is better than the 5 song sequence in the UK release of Movement in Still Life.

• Mercury and Solace
• Dreaming
• Giving up the Ghost
• Godspeed
• Namistai

(Unknown)
I have too many other artists who would tie for this position. Also, they haven’t made as much of an impression as the previously selected artists, or, do not have enough material to select five songs from.

Also, since not everyone blogs off-topic, so I’ll just ask my five other people to post a comment response (and whoever else who wants to!): Bokunenjin, Chani, JRiddell, Lowmagnet, and Nixternal.

After I got back from the UK in January my wife came to join me. She brought with her my old Acer Ferrari nearly working shy of a new hard drive. I got one from NewEgg at a fairly reasonable price and installed it. The drive arrived with a few bent pins, packaging isn't their strong point obviously, and took twice as long as they said but hey at least I had it. I had been stranded in America without Linux for more than three months and so another few days wasn't going to kill me.

Once I got the drive in it seemed the slot loading CD drive and got itself in a twist and would not load any CDs. An hour later and lots of pieces on the table I had reset it, put it back together (a few times) and got a Gentoo LiveCD in there. So I was in business. I had considered installing kubuntu but I wasn't getting on with it in the VM I had at work and I wanted to get back to Gentoo development too.

Everything looked good. Got an X server up and running. The ATI binary blob was as unstable as ever. Thanks to nerdboy (I think) I got the open source r300 driver working. This is much more stable although missing several OpenGL features we use in Avogadro such as smooth triangle shading, changing vertex colours in drawing operations etc. Other than that it works much better than the binary blob and is far more stable. I like stability in a system.

I have KDE 4 trunk running and am using it as my main desktop right now. Still got some rough edges I haven't had time to figure out just yet such as kmail refusing to save my IMAP accounts, kopete refusing to connect to GTalk and general saving issues most of the core seems pretty solid. I am compiling Thunderbird right now so that I have something. I will hopefully be getting back to Kalzium development pretty soon. If I find the time I would love to help out with KDE in a more general sense as well as helping out with the Gentoo packages.

My desktop is apparently in a customs area somewhere in New York. Delay after delay after delay with the shipping of my household possessions from the UK. So I am still without desktop hoping that an "intensive exam" is not too expensive and does not involve breaking any of my stuff :/ We shall see. Fingers crossed I will actually have furniture and my desktop computer back within a few weeks. That would allow me to be so much more productive having my dual core Gentoo desktop back, creature comforts and all that good stuff.

So keep your fingers crossed for me. Hopefully you will be seeing a lot more commits coming from me in the KDE and Gentoo repositories as well as the Avogadro work I have managed to continue to do on the MacBook Geoff so kindly loaned me whilst I was laptopless (is that a word? It should be!) Not sure that was a sentence now either...

I am pleased to announce that I tagged and released Avogadro 0.6.1 yesterday evening. This is a bug fix release which fixes one pretty large bug that slipped through - the OpenGL context was lost if switching between virtual desktops, multiple views etc rendering the OpenGL window useless unless the application was restarted. As such I would encourage anyone running Avogadro 0.6.0 to upgrade to this new version. It also features several smaller bug fixes and feature enhancements.

The screen shot above shows Avogadro 0.6.1 running in a KDE 4 session. One of the small visual tweaks I made was to add a second light source to our default OpenGL scene which really helps to illuminate the other side of the scene. Thanks go out to Albert for his suggestion of adding another light source. Hopefully there are no really big bugs remaining but Avogadro is still in the beta stages of its development. It is rapidly approaching a stable release though and I am very happy with our progress so far.

We would love to hear what you think of Avogadro. I had one person question why we always have to use the latest and greatest version of OpenBabel and felt I should offer some explanation. Many of the features exposed in Avogadro use functions and structures in OpenBabel. I myself was quite heavily involved in improving OpenBabel's support for Gaussian cube files and the cube format so that we could load and display orbitals for example. As such we often add new features or fix bugs in OpenBabel trunk and so a new release of OpenBabel must be used in order for everything to work.

There are already ebuilds for this latest version in the Gentoo tree. Ubuntu/Debian builds are in the process of being built. We should hopefully have Mac and Windows binaries very soon too.

I am headed to a meeting in the UK where Donald and I will be talking with other scientists about visualisation in chemistry and related areas. We will of course be showing off Avogadro as well as talking with many other people working in this area. I am very much looking forward to it and hope that this will lead to further innovation in the Avogadro project as well as the open source chemistry movement in general. It will of course be great to have a full English breakfast and some real ale too!

Recently I stumpled on the project fsdaily.com. It is a digg.com-clone but is focused on Free and Open Source Software. While the community seems to be rather small yet it might be an interesting news source in the future.

When I came across fsdaily.com I noticed an interesting piece of news about future EU plans to buy more Open Source software. It caught my eye because I hadn’t read that anywhere else at that time. Therefore I had a deeper look at fsdaily.com, and must say that it looks rather nice.

The more important question however is if it will suffer the same problems as digg.com. While I loved digg.com when I first discovered it I dropped it some months later due to quite some disappointments: digg is, after all, just a place for the masses. So the relevance is also defined by the masses. And well, the masses love sport, glittering things and naked skin. The equivalent in the software world might be iPods, themes and desktop screenshots. That’s ok for the masses, but as a result digg.com is just not the place if you want to get decent information or want to follow technological development.

That however might be the case with fsdaily.com - although I must admit that even the FLOSS world might have it’s equivalent for sport, glittering and naked skin in the form of a dozen hot flame wars. But at the moment the situation looks rather calm, and due to the specialized focus I think the topics will stay more technique related and really interesting than just glittering.

Also since it is still a quite small project, you can still influence it quite a lot with just a couple of people. So where is the next Commit Digest? In the end it’s the community which decides which news are interesting.

Somewhen after midnight last night GGZ 0.99.2 snapshot was uploaded. Just a few hours after, the next cool patch was created. Development runs at high speed at the moment, even though I’m still busy drawing presentation slides like a dull ODP monkey for my 2nd job (lecturer).

After my two FOSDEM presentations and some chatting after each I think that while the software required to achieve high-quality free multiplayer gaming isn’t there yet, the individual puzzle pieces already let us forebode a scenario of some sort, as a guide of what shall (or will) be possible. We have GSoC 2008 proposals coming up for those who want to help out.

The scenario goes like this: Bob wants to play Chess with Eve. (He used to play with Alice but they broke up, just to introduce some dramatic content here.) He might be logged into his GGZ core client already, possibly lurking at the Chess or Freeciv room, or he might hang around on Jabber. As soon as he finds Eve, he’ll launch a game of Chess and selects his favourite client, e.g. GGZBoard. Eve then joins this game using Tagua since she’s on KDE 4. Hurray for protocol compatibility!

Alice joins as a spectator and is totally jealous of the two players. She decides to found a player club called Toxic Pawns and invites tons of people. She’s a good club leader and also a helpful, above-average player and thus gets granted host status, which gives her privileges such as kicking players and sending private table messages, and of course hosting tournaments. In order to accomodate those players who came up with a new set of rules called Rookymotion Chess, who are believed to prefer playing audio files over playing games but like Chess nevertheless, she requests a new room from the community administrator who easily sets one up based on existing room templates through the community web frontend.

Meanwhile, Bob and Eve continue playing individual games, although Eve’s DSL connection often breaks for no reason. Of course, she can regain her abandoned game seat after a reconnection. One day, the server goes down, yet after a reboot all games are being restored. No data is lost, and no data is being leaked due to encrypted connections. The player’s personal page also features a privacy section which Eve prefers a lot to the ad-driven, privacy-invading other social networking sites she knows. Trust is important in online gaming, since technical efforts to prevent cheating can and will always be defeated at some point. But with karma points, veteran status and other community relationship indicators, Eve can rest assured that Bob’s friends are trustworthy people.

So much for the community-oriented view on all the technology which is currently on the work bench. Except for a few shameless plugs, the presentation should have shown that the software is making great progress and it’s about time to think about community and player-oriented concepts. Gaming is still one of the areas where free software isn’t #1, and changing that requires some vision beside the daily coding. Send comments to any game list I’m subscribed to.

Yesterday I made an excursion to CeBIT. Despite some major names missing and three halls staying closed it's the world's largest IT fair - and my legs remind me today of my marathon. Many halls were rather boring, the ones where the World Cyber Games took place were in opposite rather crowded. Dunno why watching others playing computer games is popular. Or the spectators were all their girl-friends who had free entrance on World Women Day. AMD wins the biggest bag contest. And many exhibitors seem to want to win in the 'Germany's Next Top-Hostess' contest.

openSUSE and KDE were present at the Novell booth and in the rather disappointing sized Linux Park:

Martin blocked the hall corridor with his openSUSE talks at the Novell theater. The last picture shows Michl giving a talk (in German) about the openSUSE project in the Linux Park forum. It will be repeated today at 15:15 CET and streamed by Linux-Magazin (records will be available later).

I am a big fan of the International Conference on Open Source. Once upon a time I was on the Programme Committee; that was back in 2005. I like this conference for a few reasons:

• It's small, but not too small. Normally, if you make an effort, you can speak with everyone at the conference. Even if only briefly.
• It is very good at producing work which should be of interest (and importance!) to Free Software developers. Often the results presented here will filter through to the community via smaller events, like the research room at FOSDEM.

So it was with great joy that I find that I have had a paper accepted to this year's gathering. It was coauthored by [ade] and Andrea Capiluppi of the Centre for Research on Open Source Software at the University of Lincoln.

So why is it that final submissions have to be made in Word format? My preference is for LaTeX, but surely even ODF would make an infinitely saner choice? Of course it would.

Springer is the final publisher. Hopefully they will see the light before next year's conference.

An angry historian have published an "opinion piece" in my newspaper telling the world that heroes should be forgotten.

English Auschwitz survivor dies

The idea being, it's not the heroes, but the ordinary people who make history. Yeah, well... but who will inspire the ordinary people to do the right thing when they make history, if we don't have genuine heroes?

Behind the fold, because this is roleplaying stuff, background assembled for the fantasy roleplaying game campaign Irina and Eduard are playing in. I'll need to expand it: we've been playing this campaign for about a decade now.

Read more ...