Café au Miel

Récemment X11R7.5 a été publié. Je me propose à cette occasion de revenir sur le projet X.org au travers d'une traduction d'un article publié par l'un des ses hackers. La conclusion est néanmoins de mon cru et les réflexions associées n'engage que moi.

Cette article est donc une traduction intégrale, avec son aimable autorisation, d'un article de Petter Hutterer, un développeur impliqué dans le projet X.org et en particulier derrière X Input.

Début de la traduction.

X11R7.5 publié. Certes, mais encore ?

Grâce aux efforts d'Alan Coppersmith, X11R7.5 a été publié il y a quelques jours. Qu'est ce que cela peut bien vouloir dire.

Ce billet vise à mettre en lumière les composants de X11R7.5 ainsi qu'à expliquer d'où proviennent leurs numéros de version.

X Window

Si vous utilisez un système d'exploitation différent de Microsoft Windows ou de Mac OS X, il est fort possible que vous utilisiez également X Window System, également appelé "X11" ou simplement "X". X consiste en un assemblage de plusieurs pièces, dont certaines sont plus visibles que d'autres, qui toutes ensembles sont "X Window System"?

X Protocol

LE composant d'X est le protocole X. Il définit X et est principalement une API. Dans ce qu'on appelle le protocole X, on distingue le protocole "cœur", qui date des années 80 et plusieurs extensions, essentiellement des additions au protocole cœur. Quand vous entendez parler de XInput, XRandR, RENDER, etc., ce sont des extensions.

X Server et les pilotes

X Server est le processus qui "discute" avec les pilotes et qui "écoute" les applications qui requièrent de dessiner des "trucs". C'est également lui qui récupère les événements d'entrée et les transmet à la bonne application. En fonction de votre matériel, vous utiliserez un certain nombre de pilotes. Actuellement, les pilotes généralement utilisés sont evdev et synaptics pour les entrées, et intel, ATI ou Nvidia pour la partie graphique.

C'est encore X Server qui implémente le protocole cœur et la plupart de ses extensions, différents X Servers pouvant implémenter différentes versions. Globalement, le plus récent X Server implémente la version la plus récente du protocole.

Xlib et compagnie

Xlib (parfois libX11) est la bibliothèque logicielle qui permet aux applications de "discuter" en X Protocol avec le X Server. Elle enrobe le protocole dans une API d'un peu plus haut niveau. Quasiment toutes les applications graphiques actuelles utilisent Xlib à un moment ou à un autre, Xlib est d'ailleurs abstraite par les toolkits graphiques, comme GTK ou Qt.

Xlib a été longtemps la seule bibliothèque à utiliser le procotole X mais depuis quelques années, XCB gagne du terrain (en fait les dernières versions de Xlib utilisent XCB pour ce qui relève du bas niveau).

Les applications X

Il y a de nombreuses applications qui font traditionnellement partie du X Window System. Parmi elles, le fameux xeyes, mais aussi des outils cruciaux comme setxkbmap ou xkbcomp.

Le reste

Il y a aussi, au sein du X Window System, nombre d'autres paquets qui comptent les polices de caractères, des outils divers, des données... Je passe sur les détails, il suffit juste de savoir qu'ils sont là.

X11R7.quoi ?

Si l'on revient en arrière de quelques années, tous ces composants étaient regroupés dans un unique dépôt. Et pour construire un seul d'entre eux, il fallait construire tous les autres. Pour en publier un, il fallait publier tous les autres. Avec le temps, les numéros de versions de cet arbre monolithique ont atteint 6.9.

X11R6.9 (X11 édition 6.9) fut la dernière publication unifiée. Vers 2005, l'arbre monolithique a été éclaté en plusieurs dépôts, un par composant. À ce moment là, les numéros de version ont également été remis à 1.0 pour la majeure partie des composants (ceux qui en étaient à 6.9, voire à 7.0).

Depuis, les publications X11.R7.x (appelée également katamari) sont très similaires aux distributions. Elles embarquent un des modules, chacun d'une certaine version et dont on sait qu'ils fonctionnent ensemble, et les regroupe en un seul jeu. Les modules en eux-même sont indépendants des katamaris et leurs numéros de version peuvent sauter entre les katamaris. Par exemple, X11R7.4 inclut X Server 1.5 mais pour X11R7.5 c'est X Server 1.7.

C'est une source de beaucoup de confusion. La plupart des utilisateurs ne savent pas s’ils utilisent 1.7, 7.5, 1.0 ou 6.8. Un katamari vise juste à fournir un jeu de composants suffisant pour faire tourner un GUI basique. C'est pourquoi avec le temps des modules ont disparu ou au contraire ont été introduits au sein des katamaris. Un module inclus dans X11R7.5 pourrait ne pas l'être dans X11R7.6 et réciproquement (la liste complète des modules et de leur version se trouve au début du journal des changements de X11R7.5).

Quelle version est importante ?

Les katamaris sont important principalement pour les distributeurs. Ils représentent un jeu de module d'une certaine version dont on sait qu'ils fonctionneront ensembles et en cela ils facilitent le packaging. Une distribution est libre de démarrer avec un katamari et d'inclure les nouvelles versions des modules au fur et à mesure de leur publication. Un katamari est un point de départ, rien de plus.

Pour ces raisons, il importe rarement aux utilisateurs finaux de savoir si un module qu'ils utilisent est inclus dans un katamari ou non. Pour les rapports de bug, les développeurs ont besoins des numéros de version des tous les modules impliqués afin de réduire leur champ d'investigation.

Pour connaître le numéro de version du X Server et des pilotes, il suffit de regarder au début du fichier /var/log/Xorg.0.log. La première ligne concerne le X Server. Comme les pilotes sont chargés dynamiquement, il faudra chercher dans le journal. Par exemple, le mien me dit :

X.Org X Server 1.7.0

...

(II) Module intel: vendor="X.Org Foundation"

      compiled for 1.6.99.903, module version = 2.9.0
      Module class: X.Org Video Driver
      ABI class: X.Org Video Driver, version 6.0

...

(II) Module evdev: vendor="X.Org Foundation"

      compiled for 1.7.0, module version = 2.3.0
      Module class: X.Org XInput Driver
      ABI class: X.Org XInput driver, version 7.0

...

(II) Loading /usr/lib/xorg/modules/input/synaptics_drv.so (II) Module synaptics: vendor="X.Org Foundation"

      compiled for 1.6.99.900, module version = 1.1.99
      Module class: X.Org XInput Driver
      ABI class: X.Org XInput driver, version 7.0

J'utilise donc actuellement X server 1.7.0 avec evdev 2.3.0, intel 2.9.0 et synaptics 1.1.99. Que ces versions fassent ou non partie d'un katamari importe peu.

Les applications X ont habituellement un paramètre -version. Pour les bibliothèques, le mieux est d'utiliser le système de gestion des paquets de la distribution (par exemple rpm -q libX11) pour accéder au numéro de version.

Fin de la traduction.

Conclusion

X.org est sans doute l'élément le plus critique après le noyau pour l'utilisation au quotidien d'un bureau Linux. Le projet souffre pourtant d'un manque de visibilité (ce que je trouve ironiquement paradoxal pour un projet qui nous permet de voir nos applications...) et d'un manque de main d'œuvre important.

Je n'ai pas les compétences requises pour participer au développement de X, j'ai tout juste celle pour traduire les articles de ceux qui le font, c'est donc ma maigre contribution au projet que de les aider à communiquer sur le travail.

Pour en savoir plus :

• http://www.x.org/wiki/ : Le site de la X.org fundation qui supervise le développement de X.org
• http://who-t.blogspot.com/: Le blog de Peter Hutterer, l'auteur de l'article originel
• http://fr.wikipedia.org/wiki/Xorg : L'article Wikipedia sur X.org

Note au lecteur : Cette article a été également publier sur le site linuxfr.

C'est en effet la quatrième version de maintenance de la branche 2.6 de Python qui a été publiée ce week-end (1) après un cycle de développement particulièrement court (23 jours écoulés depuis la publication de la version 2.6.3 le 2 octobre 2009).
Celle-ci n'apporte pas de nouvelle fonctionnalité mais adresse plusieurs bugs jugés critique par l'équipe de développeurs (2). Pour l'essentiel il s'agit de corrections apportées à la bibliothèque standard de python. On remarquera en particulier la réparation de la régression introduite à la version 2.6.3 dans le module distutils qui empêchait l'installation de modules à l'aide de l'outil setuptools.
On retrouve aussi une correction au module intégré (Builtin) marshal. Pour mémoire ce module assure la sérialisation (et la dé-sérialisation) de valeur python au format binaire (3), son usage est réservé à des situations très particulières, les modules pickle et shelves étant bien plus efficaces et adaptés pour la persistance de données.
C'est donc à une nouvelle version utile bien que sans surprise à laquelle nous avons affaire. La mise à jour est évidement recommandée, ne serait-ce que pour pouvoir à nouveau exploiter pleinement le Python Packages Index (4).

(1) : http://python.org/download/releases/2.6.4/
(2) : http://python.org/download/releases/2.6.4/NEWS.txt
(3) : http://docs.python.org/library/marshal.html
(4) : http://pypi.python.org/pypi

Le 13 Août dernier sortait la première version de maintenance de Python 3.1 ! Cette version n'apporte pas de fonctionnalité mais corrige de nombreux bugs. Bien qu'aucun ne soit particulièrement méchant, cette version stabilise Python 3.1 en corrigeant des crashs de l'interpréteur lorsque certaines fonctions (en particulier la fonction dir()) étaient appelées et quelques segfaults.

Par ailleurs il ne vous a sans doute pas échappé qu'il y a 2 semaines de ça http://www.python.org est resté hors ligne pendant 2 longs jours. C'est un problème de disques durs sur la machine hébergeant le serveur http de plusieurs sites python.org (dont www, docs, planet..) mais aussi de jython.org et le dépôt svn de python qui a engendré la coupure. Bien que cette panne ait été (heureusement) réparée depuis, la documentation de python a entre autre été inaccessible pendant quels temps. Chose "amusante" comme il est nécessaire à l'installateur de la documentation (make html) de récupérer l'utilitaire sphinx depuis svn.python.org pour compiler la documentation html à partir des sources ReStructured Text, il ne m'était pas possible de la construire et de la consulter en locale, alors que je les avais sur mon disque dur...

C'est pour ces raisons que j'ai décidé d'héberger la documentation, et les sources, de Python 3.1.1 au cas où Tout cela est donc accessible sur cette page.

Liens :

• L'annonce de la sortie de Python 3.1.1 et les __liens de téléchargement__
• Le changelog de la version 3.1.1
• Le message de A.M. Kuchling annonçant la fin de la panne
• La documentation de Python 3.1.1 sur python.org
• La page de téléchargement sur Café au Miel

J'ai été pas mal occupé ces derniers temps et traduire un PyMOTW prend plus de temps que prévu. Néanmoins, celui traitant de pickle est en ligne comme promis. Le suivant sera le PyMOTW sur le module shelve.

Comme d'habitude il est accessible à partir du menu à votre droite.

PyMOTW : pickle and cPickle

Months ago I published a plugin for the well know php web framework symfony. Today I've stopped to use php but, as people asked me to put online again the plugin, I repost here the original page and reupload the archive. If someone is willing to take over the plugin, I'll give it to him with pleasure.
Note that the plugin was developed for symfony 1.1 but should work in 1.2. Furthermore, I don't support this plugin any more.

Python 3 est une refonte majeure du langage. Pourtant, il y avait jusqu'à récemment assez peu de documentation centrée sur cette version. Deux ouvrages viennent palier ce manque : A Byte of Python et Dive Into Python3