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:

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

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.

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!

• 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!

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

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")

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.

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.