Alban’s blog

This is a post in French about why you should become a member of April, the French association for promotion and defense of Free Software.

Si vous vous intéressez au mouvement du Logiciel Libre et que vous souhaitez qu’il soit défendu contre les MTP/DRM, les brevets logiciels, la vente liée et l’informatique déloyale, je vous encourage à adhérer dès maintenant! Les positions de l’April sur ces sujets sont affichées sur son site et des cahiers explicatifs ont été réalisés lors des dernières élections présidentielles et législatives.

Je suis membre depuis début 2006 et je peux témoigner, tout comme le fait Thomas sur son blog, du travail de promotion du Logiciel Libre auprès des élus et des cabinets ministériels. Depuis 2007, l’April a trois permanents financés par les cotisations des membres. Toutes les actions de l’association listées au rapport moral de 2007 n’auraient pas été possibles sans embaucher des personnes à plein temps.

Pour renforcer son action, l’April lance une campagne d’adhésion et se donne pour objectifs 5000 membres. Aujourd’hui, le compteur affiche 3068 adhérents dont:

• 2853 particuliers
• 121 entreprises ou réseaux d’entreprises
• 91 associations
• 2 collectivités locales

Que vous soyez un militant actif ou que vous vouliez seulement soutenir l’association, vous pouvez adhérer à l’April aujourd’hui:

Two weeks ago, Michael Albinus sent me a collaborative plugin for Emacs. It can work with the gedit and gvim plugins I hosted on my collaborative editing page. It needs D-Bus support in Emacs, so the version 23.0.60 at least is required.

I tried it and recorded a screencast with Emacs, gedit and gvim together:

Just a quick screencast with gedit and gvim sharing a buffer:

It is not really useful because the text editors are running on the same computer, and they communicate via D-Bus. It would be better on Internet with the Obby protocol and with Telepathy tubes!

The code used to make the screencast is on my collaborative editing page.

I would like to have a real-time collaborative editor for code source. The real-time collaborative edition feature already exists in Gobby or AbiWord. But I still want to use vim for source code, and some colleague will not accept to leave its alternative editor.

It would be better to have a common protocol in order to have collaboration features between vim, emacs, gedit and more. The existing collaboration features in vim cannot interoperate with GNU Emacs, and the existing collaboration features in GNU Emacs cannot interoperate with vim. The AbiWord’s plugin Collab protocol has good ideas to avoid and resolve conflicts as explained in a GNOME Journal article (and more good ideas will come with the abicollab.net service). But the Collab’s protocol is tied to Abiword internal structures. Aseigo discussed the issue and want a generic library for collaborative features.

A common protocol would be useful for editing source code with my contacts (I want to use Telepathy tubes!) but also when one user want to use both vim and emacs on the same buffer. D-Bus is now the way to go for applications to communicate with one another, and D-Bus tubes are available in Telepathy.

The editors landscape use very different languages: Emacs Lisp for GNU Emacs, the Vim script language for vim (although Python can be used, see this presentation from PyCon), C and Python for gedit. Whatever the way we choose to resolve conflicts that happens in real-time editing, it seems complex: it took some years to the Abiword team to build the Collab plugin. I would prefer to avoid writing complex things in all theses differents editors and languages.

So I am thinking of an architecture with an intermediary component that make the difficult job of handling conflicts. Let’s call it text-remote-control now but I am looking for a better name.

Then, editors would have to implement a basic D-Bus specification. I don’t know yet if it is possible to isolate the complexity from the editor, but I would like to explore this possibility.

So I started to hack on gedit:

• gedit’s remote control plugin: file (on git)
• text-remote-control: script (on git)

And I have built this screencast:

I have also a plugin for vim (on git) that fires a D-Bus signal each time the buffer is changed. The problem here is that vim use its own mainloop and I don’t know how to integrate the GLib mainloop used by the python-dbus. So my vim plugin cannot receives method calls yet.

I don’t know how to use GNU Emacs but I hope someone will take the opportunity to show that writing plugins in emacs is easier!

There was two Google Summer of Code about music integration in GNOME in 2005:

• Gshrooms : Music rooms in Gaim (now Pidgin) with Rhythmbox,
• Playlists sharing with DAAP in Rhythmbox.

Vincent has also written a Rhythmbox plugin (proposed for inclusion) to update the status in IM clients (Empathy or Gossip).

What can Telepathy do for music sharing? There is a limitation in the DAAP Rhythmbox’ plugin: you can share your music with people on your local network or if you know the IP address of your contact. However, users don’t know what is an IP address and it may not be reacheable if the contact is behind a NAT.

A better interface should just be to select the contact in the contact list and the DAAP protocol is routed to the remote contact through a Telepathy stream tube. This feature request has now a proof-of-concept implementation and you can enjoy the screencasts:

• Export the music to your contact
• The music got imported

However, the current implementation is not usable: it uses In-Band Bytestreams (IBB, XEP-0047). This means that all your Ogg Vorbis files go through the Jabber server in XML, encoded in base64. Even if it was not too slow, it would abuse the public Jabber servers.

Let’s hope Telepathy will support real P2P stream tubes soon!

I started a page for my DBusMessagesBox.py tool. So now you can generate beautiful D-Bus diagrams like this one:

The Telepathy framework has a lot of components. It may be hard to understand the dependencies. I discovered Debtree and used it to generate dependency graphs:

More graphs

The command line was:

debtree -r --condense --no-conflicts --no-recommends --no-alternatives --no-provides empathy > empathy.dot
dot -Tpng -o empathy.png empathy.dot

With this configuration: ~/.debtree/skiplist ~/.debtree/endlist

“The dbus-monitor command is used to monitor messages going through a D-Bus message bus” (manpage). But when there is several connections on the bus and lots of method calls and signals, the output is not easily readable. Sometimes I draw a diagram on a piece of paper: it helps me to understand what happens. But it would be better to have diagrams drawn automatically.

This can be achieved with Mscgen (patched to draw D-Bus signals) and some scripts. Mscgen is a simple tool to generate diagrams from a simple text file with a simple syntax. Text files can be put in a SCM.

I wrote a python script that listens on the bus and writes the .msc file.

Example with Quod Libet:

Example with Telepathy:

The python script has a DBusMessagesBox object. I can filter D-Bus connection I don’t want to draw. In this example, I don’t print messages from or to the script itself. I can filter message from or to the dbus-daemon.

The script choose the right name (”salut” instead of “:1.15″). Some programs requests several connection names on the session bus. In this case, you can choose the prefered name with the ‘prefered_names’ option.

   #skip_entities = set(“DBusMessagesBox”, “DBus”)    skip_entities = set(“DBusMessagesBox”)    options = { ’skip_entities’ : skip_entities, \                ‘prefered_names’ : ‘gabble’, ’salut’, ‘ChatFilter’ }

   box = DBusMessagesBox(options)    box.start_recording()    try:        gtk.main()    except:        print

   box.stop_recording()

   box.parse("/tmp/file.msc")    os.system("mscgen -T png -i /tmp/file.msc -o /tmp/file.png")

Tetris est un «jeu vidéo de puzzle alliant simplicité, intelligence et adresse» d’après Wikipédia. GTetrinet permet d’y jouer à plusieurs. On peut gagner des bonus et des malus en faisant des lignes, puis envoyer les malus aux adversaires.

Mais GTetrinet est aussi un jeu de hasard. Le jeu choisit aléatoirement les pièces et les bonus-malus. Et le hasard se manipule, surtout sur un jeu avec une architecture client-serveur où les lancés de dés se font sur le client. Certains n’hésitent pas à écrire un patch pour pouvoir choisir eux-mêmes leurs bonus-malus au lieu de faire confiance au destin (j’ai hésité à mettre le lien vers le patch en question, mais finalement je ne le mets pas!).

Pour se protéger contre cela, on pourrait choisir aléatoirement les pièces et les bonus-malus sur le serveur. Car à priori, on fait plus confiance au serveur qu’aux clients, non? Dans le cas de Gtetrinet, cela impose de changer le protocole client-serveur, et donc de briser la compatibilité avec les autres clients existants sous Windows.

Et si on n’a pas confiance au serveur non plus, on fait quoi? Y a-t-il une solution si les deux clients communiquent directement entre eux sans passer par un tiers de confiance? C’est le même problème que jouer à pile ou face par téléphone. Il existe des solutions en utilisant un peu de cryptographie. Bruce Schneier reprend dans Cryptographie Appliquée (ISBN-10: 2841800369) une petite histoire de Uses of Randomness in Algorithms and Protocols de Joe Killian (ISBN-10: 0262111535):

Alice: Premièrement, tu penses à un bit aléatoire, ensuite je pense à un bit aléatoire. Ensuite, on prend le ou exclusif des deux bits.

Bernard: Mais que se passe-t-il si l’un de nous ne choisit pas aléatoirement?

Alice: Peu importe. Aussi longtemps que l’un des deux bits est vraiment aléatoire, le ou exclusif des deux bits doit être aléatoire.

Bernard: Ok, je parie sur 1. Mon bit aléatoire est 1. Et le tien?

Alice: Mon bit aléatoire est aussi 1. Le ou exclusif fait donc 0. Tu as perdu.

Ce protocole ne marche pas car Alice peut changer son bit si le choix de Bernard ne lui convient pas. Il faut modifier légèrement ce protocole pour mettre en gage un bit aléatoire en utilisant une fonction de hachage.

Il y a 9 bonus-malus différents dans GTetrinet. Pour choisir son prochain bonus-malus, Alice va effectuer les opérations suivantes:

1. Alice choisit deux nombres aléatoires quelconques R1 et R2.
2. Alice choisit son bloc B1 entre 0 et 8 aléatoirement.
3. Alice envoie HASH(R1, R2, B1) et R1 à Bernard
4. Bernard envoie un numéro de bloc B2 entre 0 et 8 aléatoirement.
5. Alice envoie en clair R1, R2, B1 à Bernard
6. Les deux joueurs calculent le bloc B obtenu par Alice: B = B1 + B2 modulo 9.

J’ai implémenté ce protocole en Ruby avec D-Bus: random_client.rb (pour Alice) et random_server.rb (pour Bernard). Les deux programmes doivent s’exécuter sur le même ordinateur sur la même session D-Bus pour communiquer, mais avec les tubes D-Bus de Telepathy, ça devrait pouvoir s’arranger.

Last week, Guillaume and I played for the first time GTetrinet with Telepathy’s stream tube support. You can see the two screencasts on Guillaume’s post ”GTetrinet through tubes”.

This user interface lets you choose the contact to play with and the game settings in the same window. Once chosen, you cannot add additional players. I propose an alternative user interface: you first choose the game settings in the connection window, and then you add your contacts in the party from the main window. You can see the screencast!

And maybe I will have some time to clean up the GTetrinet patch I used to create the screencast.