Which distribution on Thinkpads: really the good question to ask?

After Dell, Lenovo decided to ask users which Linux distribution they should put on Thinkpads. Seriously, who cares? If I buy a laptop that comes with Linux pre-installed, my first step would be to reinstall it from scratch, exactly like with a laptop with Windows pre-installed. Because the choices that were made wouldn’t match mine (think of partitioning, etc). Or simply because I wouldn’t totally trust the hardware manufacturer.

So, what would make me happier about a laptop?

  • That installing any recent enough mainstream Linux distribution works without requiring tricks
  • That it’s possible to buy it without an operating system, with no additional charge (and no, I don’t buy the “we need the OS installed to do some quality tests before we ship” argument. USB keys and CDROMs have been bootable for years.)

I couldn’t care less about which distribution comes preinstalled. If Lenovo wants to make me happy, there are two ways:

  • Talk to free software developers: kernel developers, etc. Not distribution developers. And get the required changes merged in, so they will land in my favorite distribution after some time.
  • If they prefer to play on their own, they could create an open “Linux on Lenovo laptops” task force, where they would provide the needed drivers in a way that makes it dead easy to integrate them in Linux distros and to report problems.

It’s not _that_ hard: some manufacturers got it right, at least for some of their products. There are many manufacturers contributing code directly to the Linux kernel, for network drivers for example.

But maybe this is just about marketing and communication, not about results? Because after all, Dell and Lenovo will look nice to the random user. While playing-by-the-rules manufacturers are hidden deep in the Linux changelog.

Jabber clients and OS usage stats (3)

Using XMPP4R, I did some stats about Jabber clients usage on the Apinc Jabber server, which hosts im.apinc.org, jabber.fr, and many more using virtual hosting. I already did similar stats in March 2006 and September 2005.

The poll was done by sending jabber:iq:version to online users, around 1:00 PM (french local time, most of the users are french). 1343 clients were pinged, and 1315 answered, which is better than last year (1145 answers). Of the 1145 jids that answered last year, 368 were also part of the poll this year (I don’t know if this is good, or not enough).


  • GNU/Linux: 43% (2006: 38% ; 2005: 34%)
  • Windows: 35% (2006: 37% ; 2005: 34%)
  • Mac OS: 16% (2006: 18% ; 2005: 23%)
  • Unknown: 4 (2006: 5% ; 2005: 6%)
  • Others: 0% (12 clients ; 2006: 0% ; 2005: 1%)


  • Psi: 24% (2006: 28% ; 2005: 28%)
  • gaim: 22% (2006: 25% ; 2005: 25%)
  • Gajim: 12% (2006: 5% ; 2005: 3%)
  • Kopete: 11% (2006: 7% ; 2005: 7%)
  • iChatAgent: 9% (2006: 13% ; 2005: 18%)
  • libgaim (Adium): 5% (2006: 4% ; 2005: 3%)
  • Pandion: 4% (2006: 4% ; 2005: 2%)
  • Miranda: 2% (2006: 2% ; 2005: 1%)
  • BitlBee: 2%
  • neos: 1%
  • Unknown client: 0%
  • Exodus: 0%
  • Imendio Gossip: 0%
  • Jabbin: 0%
  • Spark IM Client: 0%
  • Trillian: 0%
  • JBother: 0%
  • jabber.el: 0%
  • JETI: 0%
  • JAJC: 0%
  • Class.Jabber.PHP: 0%
  • Jabberwocky: 0%
  • Tkabber: 0%
  • Gush: 0%

(all clients with at least one reply are listed here)

I also did some stats on the Linux distros. With 566 Linux users, one can consider that statistically signifiant.

  • Client answers with the kernel version, not including distribution information: 62%
  • Debian: 14%
  • Ubuntu: 12%
  • Gentoo: 2%
  • Unknown distros (not provided by the client): 2%
  • Fedora Core: 1%
  • Arch Linux: 1%
  • Mandriva: 1% (despite the fact that most users are french!)
  • Slackware: 0%

(Other distros are below 5 replies)

The Debian/Ubuntu situation is interesting. Debian is not dying, even on the desktop ! The server is hosting jabber.ubuntu-fr.org, so the results are biased towards Ubuntu.

Update: it seems that Psi reports “Debian GNU/Linux (testing/unstable)” even when running on Ubuntu. This is the case for ~5% of linux users.

To server admins: if you are running a large jabber server with jabberd 1.6, it’s easy to give me the right to get the list of online users, so contact me if your are interested in me doing your users stats. It would be interesting to see if users from different servers/countries have different behaviours. I’m not sure if it’s possible with ejabberd and other servers.

Efficient key signing

I just finished signing all the keys from the FOSDEM KSP.

Importing keys I received:
Mutt is nice. You can tag all messages with ‘t’, then use ‘;’ (tag-prefix) and ^K (Ctrl + K) to import all signatures. (Thanks Myon + sam for the tip)

Signing keys:
caff (featured on debaday last week) has some useful info in /usr/share/doc/signing-party/, especially the README.many-keys and README.gpg-agent files.

Discussion about moving Ubuntu IRC channels to Jabber

The Ubuntu GNU/Linux distribution is using IRC channels as a central place for its development. This week-end, Samir van de Sand proposed to move from IRC to Jabber on the ubuntu-devel@ mailing list. A discussion started, with lots of good arguments on both sides, and Samir started a specification summarizing its proposal.

Even if I’m not sure if I would like to use MUC rooms instead of IRC for Ubuntu-related discussions (mainly because I don’t think there are Jabber clients allowing to join 10 rooms with the same user experience I get with XChat), this might be a good opportunity to work on our argumentation regarding the IRC vs MUC debate.

Now, something totally different for my readers from planet.jabberfr.org: I usually blog my Jabber entries in english, because I’m syndicated on planet.jabber.org as well. Somebody argued that I should not post stuff written in english to planet.jabberfr.org. So, should I:

  1. Continue to post entries in english to planet.jabberfr.org
  2. Stop posting entries in english to planet.jabberfr.org (I’m not going to translate my entries, so my posts to planet.jabberfr.org will be limited to stuff which is not relevant to planet.jabber.org)

Version française: mes billets sur Jabber sont généralement écrits en anglais, car je suis également syndiqué sur planet.jabber.org. Quelqu’un m’a fait remarquer que je ne devrais pas publier de billets en anglais sur planet.jabberfr.org. Que dois-je faire :

  1. Continuer à poster des billets en anglais sur planet.jabberfr.org
  2. Arrêter de poster des billets en anglais sur planet.jabberfr.org (Je ne vais pas traduire mes billets, donc mes billets sur planet.jabberfr.org se limiteraient aux sujets qui ne concernent pas planet.jabber.org)

Unintrusive Instant Messaging

Most IM clients have a big problem: they seem to think they are the most important application on the desktop, or that their users always consider IM as top priority. Problem is, some users don’t! It would be great if IM clients where dealing better with two use cases :

  • Joe is working intensively on something, and doesn’t really want to be disturbed, except, of course, if the chat he would have is of extremely high importance (knowing who just sent him a message would probably help in determining how important the chat is going to be). He can’t rely on setting himself “Busy” on jabber, because people then write to him saying “ok, you are busy, answer me later, but here is my question: ….”.
  • Joe is working with Jack (a colleague) in front of his workstation. Since he has a mix of both professional and personal contacts, he needs to check if the message he just received is from his boss or from his girlfriend. (Opening a message from his girlfriend while Jack is watching might not be a good idea).

Typical stuff clients do:

  • Display incoming messages using notification-daemon (see picture below), but do not provide a way to disable this behaviour (I don’t think many clients fail this test).
  • The tooltip of the notification area icon (“system tray”) provides a fast way to be informed of important information. However, some clients (e.g Gajim) only give the number of unread messages, but don’t say who they are from (see picture below). The tooltip would be a perfect place to say “3 unread messages, 1 is from Boss, 2 are from ” in a Jack-safe way. When working intensively, it also allows you to make a quick decision about whether you want to read the messages and maybe start a chat now, or reply to them later.
  • Some clients (e.g Gajim) do not provide a way to easily read a specific unread message (and not all of them) (see picture below). Adding something event-specific in addition to “Show All Pending Events” would allow to read the message from Boss without reading the message from Girlfriend in front of Jack.

So, how does your client behave in regard to this ? I don’t really like the way Gajim behaves because it doesn’t provide much info in the tooltip, and doesn’t allow you to read a specific event (you have to open the roster and select the contact). Is your client doing better ?

Random chat using XMPP/Jabber, anyone ?

A Random Chat applet hit digg recently. It allows you to chat with a random stranger visiting the website at the same time as you.

It’s a good idea, but it would really be much better to have something similar based on Jabber (and maybe it could become a Jabber killer app’ ?)

Some thoughts:

  • It should be easy to get in the system, but slightly more difficult to get out of it : the main problem with the current website-based system is that it doesn’t work very well outside of flash-crowd periods. For example, you could be considered available for Random Chat as soon as you are “Available” or “Free for chat” on Jabber.
  • The system should provide strong anonymity (no direct messages between participating users to hide their JID) and allow for blacklisting to avoid the usual harassment problems.
  • The system should work with a classic Jabber client: no specific software or support for unimplemented JEPs should be required.
  • The system could include a tag-based system to be able to chat with people with similar interests or speaking the same language(s)

So, is somebody interested in working on this ? It would be quite easy to do with XMPP4R or another Ruby library. (This was from my list of things that I would really like to see implemented, but I won’t have time to work on it myself)

Related links:

Of bounties, donations and summers of code influence on volunteer participation

Stuff like the Google Summer of Code, the GNOME Women’s Summer Outreach Program 2006, the Sourceforge donations system, or Dunc-Tank (an experiment to see how targeted fund raising can improve Debian) are generally considered a good ideas. However, experiments have shown that sometimes, paying volunteers decreases the overall participation. Luis Villa wrote about this a few months ago, and summarized like this:

When people do things for their own intrinsic goodness (i.e., for reasons other than payment), introducing payment can reduce the amount of invovement.

I urge you to read Luis Villa’s blog entry about this, and specifically the Motivation Crowding Theory: A Survey of Empirical Evidence paper.

Update (22/09) :

The point of this blog entry was “You should read this, it could help you make your own opinion about this stuff.”, not “Dunc-Tank bashing.”.

About Dunc-Tank specifically, I don’t think that it desserves all the criticisms it has gone through recently, because :

  • It is an experiment. Its results will be discussed (I hope), and will help to better understand the consequences of such projects. Also, I like the fact that this experiment is taking place with Debian, because Debian hasn’t been the most innovative project lately.
  • It has limited scope: it’s only about paying two Release Managers for one month each, so it is unlikely to break totally the social dynamics of Debian. it’s not as if it was paying 400 people from 40 organizations without thinking too much about the social issues involved.
  • The team running Dunc-Tank is probably one of the best possible teams for this. Breaking Debian is probably very low on their priority list ;)

However, I would be more comfortable with Dunc-Tank if it’s goal was “Experiment the effects of fund raising on Debian”, and not “Pay developers to release etch in time” (dunc-tank.org doesn’t say this, but some articles in the press do .)

One remaining issue is: is paying the RMs the best way to experiment fund raising ? I have no opinion about that, mostly because I don’t know how the Release Team works internally.

Disclaimer: I am not a DD, so I haven’t read the debian-private@ thread about that.

XMPP4R 0.3 Released !

Stephan Maka announced that XMPP4R 0.3, the new version of the XMPP/Jabber library for Ruby, was released very early this morning. From the announcement :

XMPP4R is a Ruby library for the Jabber/XMPP instant messaging protocol.

Version 0.3 brings a lot of new features and fixes. The release has been
delayed by a redesign process, thus the class and module names of
additional features have changed. Updaters are advised to read the
included UPDATING document.

From the ChangeLog:

* SRV lookup capability in Client#connect
* Stringprep support for JIDs
* TLS & SASL support
* Basic Dataforms support
* Multi-User Chat Helpers
* Helpers for File-Transfer, SOCKS5 Bytestreams, In-Band Bytestreams
* Roster helper has modified subscription-request semantics (see
* A lot of features have renamed namespaces (see UPDATING file)

Pointers for further information:

* XMPP4R Homepage: http://home.gna.org/xmpp4r/
* Downloads: http://download.gna.org/xmpp4r/
* API reference: http://home.gna.org/xmpp4r/rdoc/

While I worked on version 0.2, I didn’t do anything for this version, and I’m very proud of that, because it’s actually the first time that I was able to hand over all the maintainership of a project I created ;) Stephan Maka really did a Great Job. Congratulations, Stephan !

Non-google Summer of Code proposal: Distributed monitoring of the Jabber network

(This was initially a Google SoC project proposal. Someone got a grant to work on this, but then, he got another grant to work on another project, and he chose to work on the other one…)

The Jabber network isn’t really known for its reliability: servers are often down, or are unable to contact other servers. And most server admins don’t have tools to detect such problems. There’s some data on http://public.jabbernet.dk/mrtg/, but it’s far from being enough.

The goal of this project is to build a testing framework to be able to monitor the public servers and answer those questions :

  • Do client connections using SASL, TLS or SSL currently work on server foo.com ? (not only checking if the TCP port is open, but do full login)
  • Do server-to-server communications works between server foo.com and bar.com ? What about latency ? (To determine that, you need to connect to both servers and exchange ping messages)

Of course one would need a nice way to vizualize such data (matrix + rrdtool graphs ?)

Additional ideas :

  • Allow server admins to set a contact email, so they can be informed of problems (and/or provide an RSS feed)
  • Integrate this into the XMPP Federation

I would like to work on this, but I won’t have time. If you are interested, please contact me !

Jabber clients and OS usage stats (2)

I already did this last september. This time, 1145 online clients from the Apinc Jabber server replied to the poll. It was done around 4:30 PM, french local time. Here are the results.

Systems :

  • GNU/Linux : 38% (in september 2005: 34%)
  • Windows : 37% (34%)
  • Mac OS : 18% (23%)
  • Others (AmigaOS, FreeBSD, NetBSD, OpenBSD, SunOS) : 0% (1%)
  • Unknown (Gaim doesn’t always report the OS) : 5% (6%)

Clients :

  • Psi: 28% (28%)
  • Gaim: 25% (25%)
  • iChatAgent: 13% (18%)
  • Kopete: 7% (7%)
  • Gajim: 5% (3%)
  • Pandion: 4% (2%)
  • libgaim: 4% (3%)
  • Miranda: 2% (1%)
  • neos: 2% (1%)
  • BitlBee: 1% (0%)
  • Exodus: 1% (1%)
  • Trillian: 1% (2%)
  • Unknown: 0% (none)
  • JBother: 0% (none)
  • JAJC: 0% (0%)

All clients with at least one reply are listed here.

I’ll let you do the analysis :-) I’m just quite happy with the fact that we know have much less Mac users (most of them were parasites only interested in the MSN gateway).

The scripts are available on request if you want to run them against your own server.