Le week-end dernier, je parcourais - dans un moment de nonchalance - une page web décrivant ce qu'est un vrai défenseur du logiciel libre. Parmi les "caractéristiques" de ce genre d'individu se trouve :

«Il a lu et relu La cathédrale et le bazar, d'Eric S. Raymond, de sorte qu'il sait précisément pourquoi il défend le logiciel libre.»

Eh bien moi je ne l'ai pas lu, mais comme j'ai un peu de temps, je me lance [1]. C'est une lecture très intéressante et instructive pour comprendre le succès de Linux et d'autres projets, basé sur les qualités de celui qui tient les rênes du développement : paresse (de sorte qu'il est prompt à accepter le code des autres), communication, etc.

Sur le même site se trouve un autre essai ayant pratiquement le même titre : La cathédrale, le bazar et le conseil municipal, d'Alan Cox [2]. Il décrit ce qui a failli miner le développement de Linux pour l'architecture 8086. Son idée principale est que la communauté qui se forme autour d'un projet comme celui-là est composée de quelques programmeurs talentueux et expérimentés, mais aussi d'une «masse» de programmeurs débutants qui produisent beaucoup plus d'opinions que de code et qui finalement ralentit considérablement le projet. Le vrai problème apparaît si le noyau de programmeurs chevronnés décide de s'enfermer pour ne plus être ralentis par la masse. À court terme le projet gagne en rapidité, mais à long terme il perd l'opportunité de recruter de nouveaux participants talentueux et motivés. Il perd aussi la possibilité de transformer une partie de la «masse» en bons programmeurs en expliquant avec tact quels sont les points qui comptent vraiment, dans une démarche d'éducation.

Pour en venir à Reiser4, il me semble qu'il a souffert d'un aspect du fonctionnement de la communauté tel qu'il est décrit par Alan Cox. Le système de fichiers, supposé ultra-performant comparé aux actuels ext3 et consorts [3], vit actuellement dans la branche -mm du noyau linux, alors que son créateur Hans Reiser aimerait le voir intégré dans la branche principale. Alors qu'il s'est trouvé rejeté assez brutalement l'année dernière [4], Hans Reiser et son entreprise, Namesys [5], ont poursuivi le développement, en s'attachant sans doute à corriger ce qu' Andrew Morton et les autres développeurs de Linux lui avaient reprochés [6].

Plus récemment, un groupe d'utilisateurs a tenté de résumer la situation concernant reiser4 [7], et LinuxFr s'en est même fait l'écho en première page [8]. En ce qui me concerne, je trouve que la page en question fait plus de mal que de bien, car elle n'aborde pas l'aspect technique, mais au contraire se concentre sur le côté politique du processus, dont on a déjà trop longtemps parlé, avec pour effet de dégoûter ceux qui auraient pu s'intéresser sérieusement à Reiser4 et commenter le code.

L'apparition de cette page a entraîné avec elle un nouveau fil sur la lkml, entamé par Hans Reiser [9]. Une fois de plus, au lieu de s'attarder sur le vrai problème (les choix techniques), le fil a dérivé vers une discussion sur la difficulté d'obtenir l'inclusion d'un patch dans la branche principale de Linux. En revanche, contrairement à ce qui a été dit auparavant sur monsieur Reiser, son ton m'a paru retenu et cordial [10]. Malheureusement, le fil s'est enfoui sous une montagne de réponses provenant de la «masse» de non-techniciens, ou plutôt de gens non expérimentés et qui n'ont jamais lu une seule ligne du code de Reiser4 (il s'agit bel et bien d'une masse : le site marc.theaimsgroup.com répertorie 470 messages concernant Reiser4 pour le seul mois de juillet !). Même notre cher Linus Torvalds est tombé un peu dans le piège de cette discussion, et s'est fortement opposé aux soit-disant "plugins" de Reiser4 [11].

Heureusement, les développeurs de Linux, comme ceux du projet Linux 8086 décrits par Alan Cox, ne succombent pas à l'étouffement par la «masse»:

- Andrew Morton, responsable de la branche expérimentale, a finalement donné un coup d'oeil au code[12] et entre dans la discussion. En voici ma traduction:

«Pendant ce temps, je me retrouve pauvre et vieux en train de chercher quelques quatre autres heures pour finir le compte-rendu de la chose [NdT : parlant du code de Reiser4].

«Le code d'écriture [NdT: "writeout"] est horrible, mais ceci vient largement du décalage entre ce que reiser4 veut faire et ce que VFS/MM s'attend à ce qu'il fasse. Si ça marche comme ça, on peut vivre avec, même si le VFS pourrait être rendu plus intelligent.

«Je dirais que le problème majeur de reiser4 est le manque des xattrs, acls et direct-io. Il est probable que cela limite de manière significative l'enthousiasme des distributeurs (de même que l'attribution de copyright, mais est-ce notre problème ?).

«Les plugins semblent avoir été grossièrement mal nommés. Ce sont juste les éléments d'une couche intermédiaire d'abstraction qui permet d'ajouter ultérieurement de nouvelles fonctions d'une manière propre et sûre.

«Puis-je suggérer que toutes les critiques techniques à venir sur reiser4 incluent la référence du fichier et de la ligne en question ? Ça devrait réduire le débit sur vger [NdT : la liste de diffusion].

«Thanks»

C'est magistral, d'un coup la discussion est recentrée. D'une main de maître, Andrew a attiré une poignée de vrais interlocuteurs. Christoph Hellwig [13] ajoute concernant les plugins :
«[NdT : Si les plugins ne méritent plus leur nom], c'est parce que les vrais plugins ont été retirés du code depuis longtemps. C'est juste que ni ceux qui critiquent ni les fans de reiser4 dans ce fil n'ont jamais lu le code, ou plus généralement ils ne se sont jamais fait d'idée par eux-mêmes.»
Andi Kleen [14] poursuit :
«J'ai jeté un coup d'oeil rapide, et je dois dire que la plupart de ce qui m'avait retourné quand j'ai regardé la première fois il y a longtemps a été corrigé.»

Finalement, la vraie discussion s'est tassé, sur sur un conclusion positive. Les messages étaient écrits sur un ton tout à fait cordial, et faisant un bilan des quelques aspects techniques à peaufiner. Des développeurs de Namesys, comme Vladimir V. Saveliev, ont participé, et n'ont fait que de confirmer les conclusions d'Andrew Morton.
Et pendant ce temps, la «masse» continuait à s'étriper, cette fois sur ZFS, ou encore sur la capacité d'un système de fichiers à compenser les problèmes matériels...

J'espère que comme moi vous serez ravis de voir que la communauté a finalement fonctionné et a abouti à une vraie conclusion, constructive et enthousiasmante. Après lecture de ces quelques extraits de la lkml, il semble tout à fait raisonnable que Reiser4 soit finalement inclus dans une des prochaines versions de Linux.



[1] http://www.linux-france.org/article/these/cathedrale-bazar/c(...)
[2] http://www.linux-france.org/article/these/conseil-municipal/(...)
[3] http://marc.theaimsgroup.com/?l=linux-kernel&m=115437951(...)
[4] Il y a sûrement d'autres fils pertinents dans la liste de discussion, et vous serez sans doute fatigués après les 10 premiers messages sur les centaines de messages postés, mais voici quand même un lien http://lkml.org/lkml/2005/6/21/326
[5] http://www.namesys.com/
[6] http://lkml.org/lkml/2005/6/21/450
[7] http://kernelnewbies.org/WhyReiser4IsNotIn
[8] http://linuxfr.org/2006/07/17/21105.html
[9] http://lkml.org/lkml/2006/7/21/109
[10] http://lkml.org/lkml/2006/7/24/3
[11] http://lkml.org/lkml/2006/7/28/180
[12] http://lkml.org/lkml/2006/8/1/70
[13] http://lkml.org/lkml/2006/8/1/157
[14] http://lkml.org/lkml/2006/8/1/334

> Lire le journal (56 commentaires, moyenne: 4,1).

Cher journal,

Il y a un an, je n'aurais pas imaginé en arriver là. Onze mois ont passé depuis que j'ai commencé à penser à ce projet. Onze mois de développement, d'apprentissage de C/C++, des techniques de rendu graphique, de la programmation multi-plateformes, soit au final plus de temps passé sur ce projet que je ne l'avais prévu. Mais ce projet a bel et bien abouti !

Quel projet ? Eh bien, je viens de placer sur le CVS de gnuplot [1] un nouveau terminal interactif, dont la partie "interface graphique" est implémentée grâce à wxWidgets [2] , et la partie "rendu" grâce à cairo [3] et pango [4].

[1] http://www.gnuplot.info
[2] http://www.wxwidgets.org
[3] http://www.cairographics.org
[4] http://www.pango.org

gnuplot est un logiciel en ligne de commandes pour tracer des courbes de fonctions mathématiques ou de données expérimentales, en 2D ou en 3D, éventuellement sous forme d'histogrammes, etc. Il est doté de multiples "terminaux" qui correspondent chacun à un format de sortie : png, jpeg, postcript, svg, ou un rendu dans un fenêtre interactive capable de zoomer sur une courbe, de faire tourner une surface, etc.

Les terminaux interactifs de la version stable de gnuplot sont implémentés nativement : il y en a un basé sur X11, un autre sur Windows, un autre sur PM
(l'API d'OS/2), un autre sur Aquaterm (une API pour MacOS). Ils sont tous indépendants, et implémentent tous à peu près le même ensemble de fonctions. À part le terminal basé sur Aquaterm, aucun n'utilise d'antialiasing pour les courbes, donc le rendu paraît assez archaïque. Le terminal basé sur X11 n'utilise pas non plus d'antialiasing pour les polices...

Mais revenons à la situation il y a onze mois. Je vais essayer d'expliquer ce qui s'est passé pendant tout ce temps, des fois que ça inspire d'autres têtes brûlées !

Il y a onze mois, donc, je réflechissais à une éventuelle participation à un projet de logiciel libre.

Il y a onze mois, je ne connaissais que peu de choses concernant le C/C++ et encore moins à propos de la programmation d'interfaces graphiques. Mes connaissances se limitaient à la programmation web (html, php, mysql), "pour le fun", et à la programmation orientée mathématiques avec Maple.

Il y a onze mois, j'utilisais gnuplot pour quelques projets scientifiques (je suis en Master de physique fondamentale à l'École Normale Supérieure), et j'appréciais ses capacités, mais constatait son apparence relativement en retrait, comme mentionné plus haut.

Et puis voilà, je me suis lancé ! J'ai écrit aux développeurs de gnuplot, via leur liste de diffusion, pour annoncer mon intention de travailler sur un nouveau terminal. Ma première idée était de créer un terminal plus accessible, autrement dit où les propriétés interactives seraient plus évidentes pour un nouvel utilisateur. Il m'avait en effet fallu plusieurs mois avant de me rendre compte que le clic droit avec la souris activait le zoom !

Les réactions ont été relativement froides. "Je ne vois pas trop l'intérêt d'ajouter plus d'interactivité", m'a-t-on dit par exemple. Par contre, l'idée d'un code multi-plateformes a séduit. "Je serais très heureux d'avoir le même terminal sous Windows et sous Linux", m'a dit un autre développeur. Bon, pour avoir matière à discussion, je n'avais plus qu'à commencer à coder !

J'ai appris sur le tas. Je me suis d'abord entraîné sur les exemples fournis avec wxWidgets. Puis j'ai appris comment faire cohabiter le C et le C++ dans un projet, comment se servir des autotools, et j'ai abouti après deux mois environ à un premier résultat fonctionnel. Le résultat en lui-même n'était pas transcendant, mais j'avais déjà appris énormément ! Et les quelques questions que je posais aux développeurs de gnuplot ne restaient pas sans réponse.

Étape suivante : peaufiner ! C'est ce qui m'a occupé depuis septembre dernier jusqu'à ces dernières semaines. Au passage, pas mal de changements ont eu
lieu dans le fonctionnement global de ce que j'avais écrit. J'ai séparé la partie "interface graphique" et la partie "rendu" du graphe. En effet, le rendu méritait plus d'attention que ce que me permettait de faire wxWidgets. J'ai finalement choisi d'utiliser le couple cairo + pango, qui fournit une solide base pour faire du rendu 2D multi-plateformes et de qualité. Le premier objectif était de positionner le texte correctement sur le graphe. Pango renvoit très précisément la taille de la chaîne de la caractères telle qu'elle va apparaître à l'écran. Parfait ! Au passage, cairo trace lignes et polygones avec antialiasing et ça change tout !

Enfin, pas tout de suite, parce qu'il m'a fallu maîtriser les subtilités de l'antialiasing :
Comment tracer 'y=x' comme une diagonale parfaite, qui ne "danse" pas ? En effet, gnuplot échantillonne la fonction y=f(x), et renvoit des coordonnées entières puisqu'on trace sur une grille de pixels. Oui, mais avec l'antialiasing, on a une précision effective inférieure au pixel ! La solution : faire croire à gnuplot que je trace sur une surface plus grande, en multipliant toutes les coordonnées par 10
environ.
Oui, mais je me retrouve avec des lignes horizontales et verticales qui bavent sur plusieurs pixels. Comment tracer des axes d'abscisse et d'ordonnée "nets" ? Eh bien, en détectant les lignes horizontales et verticales, et en les traçant de force alignées sur la grille de pixels.
Enfin, les algorithmes d'antialiasing font que des polygones censés être adjacents apparaissent finalement avec un "joint" sur leur arête commune. C'est dommage, alors j'écris à la liste de diffusion de cairo, on me propose plusieurs
solutions, aucune n'est triviale, mais au final l'une d'entre elles est relativement simple et efficace. Ouf !

Ah, j'allais oublier un autre problème qui m'a occupé pas mal de temps... l' UTF-8 ! En effet, pango ne trace que de l'utf-8. Ok, on dispose de librairies sachant transformer une chaîne de caractères depuis un encodage quelconque vers de l'utf-8. Mais il reste un gros problème : la police "Symbol". Elle peut être utilisée dans gnuplot pour écrire des légendes avec des symboles mathématiques ou des caractères grecs. Tout ça est superflu dans un système complètement unicode, mais pour assurer la compatibilité avec des anciens scripts, il me faut m'assurer que "Symbol" peut être utilisée. Or, si on choisit cette police avec mon nouveau terminal, pango ne trace rien du tout ! D'où vient le problème, me direz-vous ? Eh bien, par exemple, cette police suppose que le caractère 'a' correpond à la lette grecque 'alpha'. Or, pour pango en particulier et pour l'unicode en général, un 'a' est un 'a', et un 'alpha' est un 'alpha'. Point. Comment s'en sortir ? Après de nombreuses recherches bredouilles avec notre google préféré, et après avoir réfléchi quelques temps, j'ai finalement écrit une fonction qui fait "manuellement" la conversion depuis l'encodage "Symbol" vers l'unicode, et ... ça marche ! Pfiou, je ne suis pas passé loin de tout abandonner !

Et puis il m'a fallu apprendre la programmation avec les threads, les mutex et
compagnie. Et j'oublie encore les signaux, les sigjmp/longjmp, et tout ce que
gnuplot utilise et qui n'était pas compatible au départ avec mon nouveau
code... Et j'en oublie encore sans doute... Mais il faut persévérer !

Il y a quelques jours, j'ai été intégré dans la liste des développeurs de
gnuplot sur sourceforge.net. Après avoir appris les rudiments de CVS, j'ai
envoyé tout mon code avant-hier, soit un patch de 250 ko, qui touche le minimum
possible du code existant de gnuplot, qui contient quelques images PNG et XPM
pour la barre d'outils du nouveau terminal, et surtout plus de 5000 nouvelles
lignes de code !

Et pour couronner le tout, j'ai placé mon code sous double licence : sous la
licence de gnuplot, qui est assurément libre, mais non compatible avec la GPL au
sens de la Free Software Foundation, et sous la GPL, parce que, quitte
à être libre, j'aimerais bien voir gnuplot changer de licence pour la GPL,
alors pourquoi ne pas faire le premier pas moi-même !

Ça fait tout drôle... J'ai pleins de sentiments mitigés et de questions. Je suis heureux d'avoir appris autant, content d'avoir abouti et d'avoir contribué au logiciel libre mais, en même temps, est-ce que j'aurais pu utiliser tout ce temps pour autre chose de plus important ? Est-ce que ça va être un travail rentable dans la durée pour gnuplot ? Combien de temps vais-je devoir passer pour corriger les bugs, rajouter les fonctionnalités auxquelles je pense encore, etc. ?

En bref, c'est une page qui se tourne !

Combien sont prêts à passer de l'autre côté du miroir, et de se lancer dans un projet de ce genre, à plus ou moins long terme ? Je n'en sais rien. Probablement un nombre conséquent l'a déjà fait, étant donné l'état actuel du logiciel libre. J'aimerais voir plus de personnes faire ce pas, en tout cas je l'ai fait, et malgré les questions métaphysiques que je me pose, je ne regrette pas !

Merci à toi, cher journal, d'avoir accueilli ces pensées, et merci à toi, lecteur, de m'avoir lu.

> Lire le journal (27 commentaires, moyenne: 4,2).