Ok so there were some reactions to the Call for help post. I had three direct offers for help in pkg-xfce, not sure if other teams had such propositions. Some people asked me to correct various number for the active contributors . Basically, the numbers are what the feeling I got from people working in those team. Julien Cristau wants me to correct the number of debian-x active contributors to 0. (yes, zero, that means nobody, nadie, personne). Basically he doesn't have time anymore, and Brice Goglin can't really keep up. So, for those who care about shiny X effects, and stuff like that, you help would be gladly appreciated (and no, you don't have to own each and every chipset in the world to give some time). Aurelien Jarno wants me to add that at the moment there are 2 (two) active libc contributors, plus one on GNU/Hurd and one on kfreebsd. Frans Pop wants me to add that there are ~85 people working on d-i and that the problems the team might face aren't only related to the lack of manpower (and I don't really want to enter politics) Finally, it seems that some people (well, only one at the moment, but it's enough for to feel the need to precise) though the numbers previously given would dismiss contributions for the active contributors. That wasn't my intention, so I apologize if you are an active contributor in one of that team and thought I dismissed your contribution. If it wasn't clear enough, my point is to show that quite some teams are lacking manpower (some team miss other things too, like leadership, coordination or whatever) and users shouldn't be scared to contribute to them. Those are core teams, without them Debian wouldn't work at all (not to mention derivatives), so it's a good idea to join them. Now, what if you do want to help, but don't know how. On the previous post I gave links to teams website, wiki page or QA page. You should be able to find a mailing list or contact mail you should be able to write to. Just write that you want to offer some help, that you don't know how and where to start. Add what you're interested in, what you find fun, and your technical knowledge. Don't be shy, and you don't need to be a Debian Developer (nor even a Debian Maintainer) to contribute. Thanks!

Bug-Squashing-Party in Munich We are organizing a BSP in Munich on the last weekend of November (28th/29th). It will take place in the (new, they are moving to the neighboring building this week) LiMux office on Sonnenstr. 25, between U-Bahn stations "Stachus" and "Sendlinger Tor". If you are from outside Munich and want to attend the BSP, please let me know (mbanck@debian.org) so we can maybe arrange something like limited travel sponsorship or lodging (some of us can offer crash space at least). We specially invite people from within 150 km, like Nuremberg/Erlangen, Salzburg, Ulm, Augsburg and Innsbruck. We probably start the BSP at some point on Friday evening already, but the main action will be on Saturday and Sunday. As usual, people should bring their notebooks and possibly an ethernet cable. Wireless will be present as well, but a certain bandwidth cannot be guaranteed.

Earlier in the year I bought some stuff from UK clothes retailer USC. USC kindly included some gift vouchers in my delivery. This is a good example of how to sweeten a deal and make your customers happy. The vouchers did not include any expiry date on them. I banked them until the autumn, so I could maximize their potential by using them in conjunction with a heavy winter coat. I recently spotted a coat I liked a lot. It's a bit pricey at nearly 200, so I decided to cash in my vouchers. Unfortunately, the vouchers didn't work Frustrating! I emailed the company to ask them why, and it turns out that -- despite not including a printed expiry notice -- the vouchers had expired. I asked the company if they would be willing to issue me with a replacement voucher, and they stopped replying to my emails. This is a good example of how to really sour a customer's impression of you and make them look elsewhere. I did so, and found another retailer selling the coat 20 cheaper.

So yesterday we had a really nice meeting with few french Debian folks. Luk and Ralf were visiting us, so we went at Prosper's for some meat and wine (and Aberlour). We were a bit too much to be able to speak to everybody (so mainly there were two 6-packs of people), but it was fine anyway. Though, the main point of the evening was that some (most?) teams in Debian are really (*really*) understaffed, and it might become problematic in the near future (like now). For example, from what I understood:

• debian-x has one active contributor
• pkg-xfce has one active contributor
• evolution has one de factor contributor
• pkg-gnome is better since Josselin had some help, but it's still not perfect
• d-i has only one active contributor
• libc has only one active contributor

I don't know the state of other teams, but it doesn't really look fine for the incoming freeze. So if you want to give some help, even if you're not yet technical enough, feel free to offer it to the teams above. Usually, starting with just using the package is enough. If you use it, you want it well-maintained, and there _are_ stuff to do to which don't require large technical knowledge, and the (few) active contributor will be happy to have some help and point you to what you can do. If you want to give some time to Debian, before filing some ITPs (even if you'd really like to have that package you use everyday), check if you can't do something for those above teams (and others which might need help too, like release team or kernel). Oh, and don't be scared, working on Debian is fun. It's time consuming, but it's rewarding. Don't let it become not fun.

• when people upload to Debian with an @ubuntu.com email address
• even better, if they do that when they are DDs (so with a @debian.org address)

Yeah! Actually, doing so shows several things: That the collaboration between Debian and Ubuntu actually works out. That people that feel more attached to Ubuntu also do care for Debian. And that those people started to realize that contributing things back to Debian actually does reduce their own workload with respect to not having to maintain seperate patches, with the benefit of all involved parties. So big kudos to you people being able to look over the corner of your little universe and see the bigger picture for the benefit of all!

I was referred to Creating a World Without Poverty during a discussion on advogato some months ago, but it took rather a long time to obtain the book for various reasons and then I forgot about this review until a recent discussion on new Cooperatives-UK Chief Ed Mayo s site. Better late than never, here s my review of it. Let me know what you think of this book. About the Book Author Muhammad Yunus is founder of the Grameen Bank, Bangladesh, one of the microcredit pioneers, but that story has been told in another book Banker to the Poor. The prologue of this book starts with the creation of Grameen Danone a joint venture between the bank and the France-based Groupe Danone then part one describes problems in capitalism and introduces the idea of Social Businesses as a complement to what the book calls Profit-Maximising Businesses (PMBs), or what most people know as usual shareholder companies. Part two then covers the Grameen Group from its start in banking, through an impressive list of short company case studies some Social, some PMBs, some joint-ventures up to the first year or so of Grameen Danone. The final part then talks about creating a marketplace which is open to Social Businesses, harnessing Information Technology to spread these ideas (more on this in a later article on this site) and using those innovations to banish poverty from the world. The epilogue is the Nobel Prize Lecture Poverty Is a Threat to Peace which seemed to read almost as a simplified summary of the book s main ideas. Annoyance I got quite annoyed with this book because I feel there is a lurking absurdity in its main big idea:- On the one hand, the argument seems to be that profit-maximising businesses are problematic because of their single-minded focus on profit-maximisation. This is an argument that I largely agree with, as you may remember from my short review of Joel Bakan: The Corporation. On the other hand, it proposes to remedy this by creating Social Businesses with equally single-minded focus on social problems this seems like a recipe for disaster! If profit-maximisers threaten to wreck the environment, human rights or whatever else isn t in their goals, why won t Social Businesses using similar single-purpose company formation rules just as easily threaten to wreck whatever mentioned isn t in their goals? If this book is correct and entrepreneurs are multi-faceted human beings who will act to promote social aims (which they must if they are to invest in Social Businesses), then the only robust way forward is to promote businesses that do not try to simplify that multi-faceted nature, whether for profit-maximisation or for a subset of social aims. The best form of businesses that I know for trying to represent all interests of their owners are cooperatives. Dismissed after less than a page Cooperatives are examined in part one of the book and dismissed after less than a page (p35) because they are not inherently oriented towards helping the poor or producing any other specific social benefit (which is a misleading claim because concern for community is a basic principle of cooperatives which all should uphold), they can be owned equally by the wealthy as well as the needy (why is this a problem?) and they can sometimes be demutualised into PMBs. Ultimately, if that s the will of the people, that can t be completely prevented, but recent developments have found ways to make that much less attractive (so-called anti-carpetbagging rules). Doing what people want is not usually a problem in other spheres it s democracy. What s really infuriating is that the author proceeds to describe Social Business which are aimed at specific social benefits (rather than all), can only be owned by the needy but can access the resources they need by donations from the wealthy or by forming joint ventures with them (even very unequal ones) and can be desocialised into profit-maximisers (p178). The same problems which were used to reject cooperatives exist just as badly, if not worse! Conclusion: a bit disappointing So, ultimately, I found this book a bit disappointing. There are lots of good ideas, but when presented with a ready-made round wheel for the basic problem of tempering profit maximisation, this book reinvents an oval one. I suppose I shouldn t be surprised. The misleading criticism of cooperatives is sadly typical of much of the current social enterprise movement, which I mentioned as a drawback in the recent case study of our co-op by Cooperatives-UK. I don t know if social enterprise enthusiasts are informed by the thinking of people like Muhammad Yunus, or if the high-profile authors simply reflect the movement. Have you read this book? Did you spot this contradiction? Do you feel it has other problems that I m ignoring? Or is it a work of genius and I shouldn t be disappointed with it?

Version 0.6.7 of the Rcpp package---a set of C++ classes making it easier to glue C/C++ code to R---is now on CRAN and Debian. This is a fairly incremental release that contains just a few small changes that arose since the previous release in August. One change is that a new type RcppList was added which allows us to build R 'list' types in C++. In particular, this makes it possible to have data structures of different types and dimensions. We had not previously accomodated this as our data structures where more regularised (i.e. think matrices or vectors of various types). The need for this came out of the work with the recently started RProtoBuf package which interfaces the Google ProtoBuf library. The incredible Romain Fran ois has joined the project and added a number of nice tricks; this will need another blogpost sooner rather than later. In the meantime, check out the RProtoBuf pages at R-Forge. Another small change was the addition of a self-contained example of a function callback from C++ into R which wasn't all that well documented before; this was in response to a user request. Finally, I started RcppList as a first step in reorganising the code a little better and split the class header and body off into separate files. This required changes to the infrastrucure files Makevars, cleanup, ... and I promptly forgot the Makevars.win Windoze variant which will require a 0.6.8 release real soon.

I have been reading a great many posts about Android lately, some consisting of criticism, some of praise and some simply addressing issues in the Android community . Let s have a look at those. Matt Porter s Android Mythbusters presentation and Harald Welte s reaction
I haven t seen the presentation live, but I had a look at the slides. Impressing work done by Matt putting all this information together. However, we all knew that Android only (ab-)uses Linux, without making use of the GNU userland for a long time, didn t we? In his presentation Matt has shown things such as Android s udev replacement that uses hardcoded values for device node creation and (on his blog) Harald has then come up with a statement I have found to be very strong:

The presentation shows how Google has simply thrown 5-10 years of Linux userspace evolution into the trashcan and re-implemented it partially for no reason. Things like hard-coded device lists/permissions in object code rather than config files, the lack of support for hot-plugging devices (udev), the lack of kernel headers. A libc that throws away System V IPC that every unix/Linux software developer takes for granted. The lack of complete POSIX threads. I could continue this list, but hey, you should read those slides. now!

Now both of these statements target technical details, but the root of the problem seems to be elsewhere. Where is my Android 2.0? Okay, that heading might not be making any sense in the context of this post at a first glance, but let me elaborate on that. Google and the Open Handset Alliance refer to Android as being an Open Source operating system, but the project is different from real Free Software projects: development takes place in a closed group and the results are shared with the community later on, when they are deemed to be ready. This means that innovation also takes place behind closed curtains and that the community is not involved in the actual development process at all. Lately we have seen the result of that, as Motorola is bragging about working close with Google on Android 2.0 ( Eclair ), but the AOSP source trees, open for everyone to have a look at, show no signs of version 2.0. In fact no changes that might even remotely suggest the release of a new major version have been made public in the past few weeks. So where is the openess there?
Actually, the Motorola Droid has already shipped with Eclair on 6th, but still, there is no indication that Eclair will be made available to the broader public. In short Android seems to be developed behind closed curtains, with hardly (read no) community input whatsoever and is sometimes released as Free Software, not what I would describe as an open development process. The Android Market problem As we have seen in the past Google is enforcing their copyright on proprietary applications that ship with pretty much every Android device, such as the Android Market. This has become really clear when Steve Kondik received a cease and desist letter when packing the Google-proprietary applications into his ROMs. Okay, it s Google s right to enforce their copyright and there is nothing wrong with actually doing so, the thing I really have a problem with is something else: the Market is proprietary. Now what this means should become rather clear. You can have an Android device without Google s proprietary bits, but with default settings you just do not have any way of installing additional software. In my opinion the Market should be freed by Google themselves, or the community has to react and come up with a free replacement to overcome the vendor lock-in. Oh, you might know a replacement called SlideMe (or Mobentoo) already. Well, that bugger is proprietary too, so not a solution at all. Nokia and Maemo to the rescue In most discussions about the openness of Android someone throws in Nokia and Maemo, as a solution to the dilemma. Reading all those positive comments I simply had to give it a try, but all my hopes were destroyed within a few minutes. Let s start with the good news and let alone the reason why my hopes were destroyed for another minute or two. Maemo is based on Debian GNU/Linux and various Free Software components, such as GTK+, gstreamer, esd and friends. Most of the system is Free Software which is a good thing(tm) and reading all of this really got me into Maemo. Okay, some applications seem to be proprietary, but I am sure that could be fixed rather easily, so I could once for all use a truly open phone. and then came the SDK installer shell script:

#!/bin/sh
# Copyright (C) 2006-2009 Nokia Corporation
#
# This is proprietary software owned by Nokia Corporation.
#
# Contact: Maemo Integration <integration@maemo.org>
# Version: $Revision: 1110 $

Now there is one question you should ask yourself: Why would someone trying to promote his platform as being open make the *installer* script for its SDK proprietary? Come on, it s an installer script, how much of your secret juice could be in there? What s the problem with people modifying it and working on this installer script in an open development environment? I had high hopes for Nokia actually doing a bit better than Google, but it seems they ve failed to do so. It may be me overreacting, but a proprietary SDK installer shell script scares me enough not to install the SDK and have a look at it for now nor to think about buying a Maemo-based device in the near future. Please Nokia, either get the facts straight or provide us with a free SDK to your free & open platform. So, in short, Google is bad at working with the community and creating a truly open development process, and Nokia simply fails in terms of not scaring off prospective developers for their open platform with the proprietary SDK installer. Do you have any solutions in terms of an open phone environment, apart from what OpenMoko has come up with?

For those who haven't seen it yet, LinuxDevices published an article recently looking at the roadmap of Marvell's ARM line. The new line is called Armada and for Debian the Armada 510 (known as Dove) is of particular interest. To me, it essentially looks like a Kirkwood (the current platform) but with ARMv6/v7 (instead of ARMv5), integrated VGA and some other features. According to the article, the Armada 510 is aimed at "high-end smartbooks and tablets". I'm happy to see the integration of VGA because I'd like to see more ARM based smartbooks, tablets and thin clients. At the same time, I'm worried that the VGA will be some proprietary chip without proper open source drivers and I'm surprised that the new chip only offers 1.2 GHz. After all, the current Kirkwood chip clocks 1.2 GHz already, so I'd have expected an increase to 2.0 GHz for the next generation.

gPDFText was only released yesterday and it's being downloaded three times faster than my next most popular upstream project: drivel. Even nicer, it only took under a month to get to this point - and that includes a string freeze to get four translations for the program output and three for the User Manual (which uses yelp, as usual).

gPDFText is a text editor for GTK+ that opens PDF documents for ebook readers, converts the text contents into plain ASCII text, restores the original paragraphs and removes unwanted line breaks to allow easier zooming on the reader.

Many downloaded PDF files for ebook readers still use the A4 paper type (or letter which is similar in size) and when the PDF is displayed on the ebook reader, the zoom required to display the entire page makes the text too small. Simply exporting the PDF into text causes problems with line wrapping and the various ways that ebook PDFs indicate page headers and footers make it hard to automate the conversion.

gPDFText loads the PDF, extracts the text, reformats the paragraphs into single long lines and then puts the text into a standard GTK+ editor where you can make other adjustments.

On the ebook reader, the plain text file then has no unwanted line breaks and can be zoomed to whatever text size you prefer.

Each reformatting option can be turned off using the gPDFText preferences window.

Spelling support also helps identify areas where the text has not been fully reconstructed.

Debian & Ubuntu - it's waiting in NEW but it should build fine on Squeeze and Jaunty or Karmic. Any feedback, use the wiki. Any bugs, use the Trac tickets. All links available via the SF pages.

Hopefully, the extra interest will produce some more people will join the work to improve it. It's a fairly simple codebase, lots of TODO and FIXME items for new contributors to work on and it's all up to date with GtkBuilder and ready for GTK+3.0. If you are looking for an upstream project, take a look at the SVN and give it a go.

Google has not yet released most of the Android 2.0 source code, but they did publish source for a very small number of components, including a WebKit snapshot. I was very excited to see that the snapshot includes Google's V8 virtual machine! (Previous Android releases used Safari's JavaScriptCore/"SquirrelFish Extreme" VM.) But without the rest of the source tree, there was no way to build and run this on a real Android phone. The SDK includes a binary image that runs only in the qemu-based emulator. Today I got to try out a Motorola Droid. Here is how its browser compares to Android 1.6 on my HTC Dream (Android Dev Phone / T-Mobile G1) in the V8 Benchmark Suite (version 5):

Test	Dream	Droid	Change
Richards	13.5	15.6	16%
DeltaBlue	5.23	12.9	147%
Crypto	13.2	10.9	-17%
RayTrace	10.9	80.1	635%
EarleyBoyer	23.5	74.7	218%
RegExp	did not complete	16.5
Splay	did not complete	did not complete

Some tests (Richards, Crypto) see little or no improvement, while others (DeltaBlue, RayTrace, EarleyBoyer) are dramatically faster. Just for comparison, let's run the same benchmark on Safari 4 (JavaScriptCore) and a Chromium 4 nightly build (V8) on a Mac Pro:

Test	Safari	Chromium	Change
Richards	4103	4640	13%
DeltaBlue	3171	4418	39%
Crypto	3331	3643	9%
RayTrace	3509	6662	90%
EarleyBoyer	4737	7643	61%
RegExp	1268	1187	-6%
Splay	1198	7290	509%

The precise ratios are different, but the same tests that showed the most improvement from Android 1.6 to 2.0 also show the most improvement from Safari to Chrome. Based on this plus the source code snapshot, I'm pretty sure that Android 2.0 is indeed using V8. This is exciting news. It makes Droid the first shipping product I know that uses V8 on an ARM processor, although V8 has included an ARM JIT compiler for some time now. For mobile web developers (like me), it means we're one step closer to having desktop-quality rich web applications on low-power handheld devices. Final thought: Although the Motorola Droid is still 100 times slower than Chromium on a Mac Pro, it's actually faster at some benchmarks than IE8 on a low-end Windows machine, or Firefox 2 on hardware from just a few years ago.

Earlier this year, my brother and I developed a documentation management server for a small software developing company. They were sick of creating their documentation by sending around Word documents, having to manually merge them, losing changes and not getting a clean, consistent layout.So we created zpub for them: It is based on DocBook and Subversion, and adds a fairly nice web interface to it. Now their work flow is

1. The editor checks out the DocBook source document via Subversion. With a client like TortoiseSVN, this is possible even for the less tech-savvy editor.
2. He works on the document using the editor of his choice. We recommended an editor with a proper DocBook mode such as the XMLMind XML Editor or Serna Free, which was recently published as Free Software, to our customer.
3. When satisfied, he commits his changes via Subversion, adding a comment describing his modifications.
4. On the server, zpub renders the document in the various output formats (.html, .pdf, .chm), and makes the result available via the web interface. The commit messages are put there, and all previous revisions of the document can still be accessed.
5. Optionally, an e-mail about the change is sent out to a per-document configurable list of recipients.
6. Optionally, the documents are rendered with a DRAFT -Watermark on the pages, to avoid leaking wrong revisions to the outside. Only users with extended rights are allowed to release a document, thus causing a version without that watermark to be rendered.

For more details on the feature and usage of zpub, check out the documentation that you can find on the demo instance.We are actually quite satisfied by zpub, and it would be a petty if that was just it. Of course, there are quite a view programs out that that can provide these features plus many more, much more than a company the size of our customer would want to have (or even to worry about). So there is a niche between sending Word documents by mail and buying a very expensive, complicated product where zpub fits in.Being a fan of Free Software myself, and since zpub is based on Free Software, we decided that we want to release zpub itself under a Free License. We chose the EUPL, which is a GPL compatible license created by the European Commission, since our customer comes from a municipal environment. The code is hosted on gitorious now, so if you have a need for zpub, just give it a try.Also, if you run a Free Software project, manage your documentation in DocBook (or want to start to do so) and think that zpub might be a neat idea to allow more documentation writers to contribute, talk to me. I might well offer free hosting in that case. If you are a commercial user, I m still offering hosting (and support or feature development), just not for free any more. Note that the zpub user interface and documentation is currently only available in German.

3.0 format source packages can now be uploaded to the Debian archive. (Note: despite the title of this post, this is not the "Wig and Pen" format which is 2.0. See dpkg-source(1) for a detailed description of all the source package formats.) I tried converting my libcgi-application-basic-plugin-bundle-perl package with mostly good results. l-a-b-p-b-p is an aggregation of perl modules (in .tar.gz format) from CPAN. There is no upstream, this is a Debian only package. Currently the source looks something like this:

   
build-area/
    libcgi-application-basic-plugin-bundle-perl-0.5/
        debian/
            [all the standard stuff: control, rules, etc.]
        tarballs/
            CGI-Application-Dispatch-2.16.tar.gz
            CGI-Application-Plugin-AutoRunmode-0.16.tar.gz
            CGI-Application-Plugin-ConfigAuto-1.31.tar.gz
            ...
            [rest of modules]

The files in the tarballs directory are unpacked at build time to create the binary package. This works but has all the disadvantages of "tarballs in tarballs." By adding a file called debian/source format with the single line:

   
3.0 (quilt)

...dpkg-source is directed to use that format. Now I can rename each upstream tarball to

   
<package name>_<package version>.orig-<upstream tarball name with .'s replaced by -'s>.tar.gz

...and organize the source like this:

   
build-area/
    libcgi-application-basic-plugin-bundle-perl-0.5/
        debian/
            [all the standard stuff: control, rules, etc.]
    libcgi-application-basic-plugin-bundle-perl_0.5.orig-CGI-Application-Dispatch-2-16.tar.gz
    libcgi-application-basic-plugin-bundle-perl_0.5.orig-CGI-Application-Plugin-AutoRunmode-0-16.tar.gz
    libcgi-application-basic-plugin-bundle-perl_0.5.orig-CGI-Application-Plugin-ConfigAuto-1-31.tar.gz
    ...
    [rest of modules]
    libcgi-application-basic-plugin-bundle-perl.orig.tar.gz

Each module is now a seperate file in the debianized source with MD5sum etc. The only problem I am having is with the last file. libcgi-application-basic-plugin-bundle-perl.orig.tar.gz makes no sense for me because there is no upstream yet dpkg-source insists on it. I can make a dummy easily enough but this is an unnecessary annoyance so I filed bug #554488. Raphael Hertzog responded quickly. He is considering adding a --create-empty-orig option to dpkg-source which would solve the problem nicely.

I love bugs that are just confusing and/or break your mental model of how you think the software works. Here is a good example: Given the following HTML in Gecko, what happens when a user clicks the button?

GET /anchor-target HTTP/1.1
GET /anchor-target HTTP/1.1

2 GET requests? Okay, perhaps some sort of event bubbling problem; it's relatively common in GUI internals. But what about:

POST /form-action HTTP/1.1
GET /anchor-target HTTP/1.1
GET /anchor-target HTTP/1.1

Wait, this time it POSTs the form and makes 2 GET requests? Answers in a Bugzilla report, thanks.

As 3.0 format packages are now allowed into the archive, I am thinking about what I would like the workflow to look like and hoping one of them fits me. For new upstream releases, I am imaginging something like:

1. New upstream version is released.
2. git fetch + merge into upstream branch.
3. Import tarballs, preferably in their original format (bz2/gzip), using pristine-tar.
4. Merge upstream to debian branch. Do necessary fixups and adjustments. At this point, the upstream..debian branch delta is what I want to apply to the upstream release. The reason I need to apply this delta is so I get all generated files into the package that's built and uploaded.
5. The source package has two functions at this point: Be a starting point for further hacking; and be the source that buildds use to build the binary Debian packages. For the former, I need the git repository itself. It is increasingly my preferred form of modification and so I consider it part of the source. For the latter, it might be easiest just to ship the orig.tar. gz,bz2 and the upstream..debian delta. This does require the upstream..debian delta not to change any generated files, which I think is a fair requirement.

I'm not actually sure which source format can give me this. I think maybe the 3.0 (git) format can, but I haven't played around with it enough to see. I also don't know if any tools actually support this workflow.

Previously i d talked about how we use GNOME technologies in the Moblin Myzone. Now i m going to talk about another component that i m responsible for, the People Panel. An important aspect of the Moblin user experience is about communicating with others and this panel provides quick access to do this. The core of the content is provided by an abstraction, simplification and aggregation library called Anerley. This provides a feed of items (an addressbook of people) that aggregates across the system addressbook, powered by EDS, and your IM roster, powered by Telepathy. You have small set of actions you can do on these people such as start an IM conversation / email / edit them with Contacts. The core of our IM experience is supplied by the awesome Empathy. We ve been working with the upstream maintainers to accomodate some of the needs of Moblin into the upstream source. This included the improvements to the accounts dialog and wizard that landed for GNOME 2.28. One of the biggest problems with the IM experience in Moblin 2.0 was that it was easy to miss when somebody was talking to you. If you were looking away when the notification popped up, whoops, it s gone. With our switch to Mission Control 5 I was able to integrate a Telepathy Observer into Anerley and the People Panel. An Observer will be informed of channels that are requested on the system. This allows us to show ongoing conversations in the panel and by exploiting channel requests and window presentation allow the user to switch between ongoing conversations. This wouldn t have been possible without the assistance of the nice folks in #telepathy and at Collabora: Sjoerd, Will, Jonny and countless others.

I am eager to get feedback on some of my pictures. Some people already liked them, so the ego is quite well right now... :-)