Un an et sept mois après Python 3.1, voici une nouvelle version majeure de Python 3 : la version 3.2. Elle apporte notamment deux nouveaux modules (argparse et concurrent.futures), des améliorations sur les extensions écrites en C (API stable et marquage dans le nom de fichier des bibliothèques) et les modules compilés (fichiers .pyc) sont désormais rangés dans un dossier « __pycache__ ». Pour rappel, Python 3 corrige les erreurs de jeunesse de Python et harmonise la bibliothèque standard (relire la dépêche annonçant Python 3.0).

Pour faciliter le travail des développeurs des autres implémentations de Python (IronPython, Jython, Unladen Swallow, PyPy), la syntaxe, la sémantique et les fonctions builtins n'ont pas changé dans version 3.2, comme décidé par le moratoire (PEP 3003: Python Language Moratorium). Le moratoire prend fin avec la publication de Python 3.2.

La seconde partie de la dépêche présente en détail les nouveautés de Python 3.2, l'état du portage des modules vers Python 3, et évoque ce qui est prévu pour la suite.

En termes de nouveautés, Python 3.4 est la version de Python qui en apporte le plus ! Il n’y a pas moins de 7 nouveaux modules entre Python 3.4 et 3.3 (séparés de 18 mois), tandis qu’entre Python 3.3 et Python 2.7 (séparés de 27 mois) il y en a huit. En termes de propositions d’améliorations de Python, 14 PEP (Python Enhancement Proposals) ont été implémentées dans Python 3.4. Cette version donne un sérieux coup de vieux à Python 2.7. La 2^e partie de la dépêche détaille les principales nouveautés et la manière dont Python est développé.

Mon article Why should OpenStack move to Python 3 right now?, cité ci‐dessous, explique pourquoi Python 2 est désuet et pourquoi vous devez porter dès maintenant vos applications sur Python 3. L’article a été écrit pour le projet OpenStack mais reste général.

[Free](http://fr.wikipedia.org/wiki/Free_(soci%C3%A9t%C3%A9%29) vient de mettre en ligne les patchs de l'ensemble des logiciels libres utilisés dans ses différents produits dont notamment la Freebox. Il s'agit d'environ 155 patchs pour 45 logiciels libres différents. La mise à jour des conditions générales de vente, relevée par Numérama le 1er août 2011, avait annoncé cette libération.

Reste maintenant à voir ce que vont devenir ces patchs. Est-ce qu'il y aura des développeurs motivés pour les remonter dans les projets concernés ? Ces patchs sont sûrement écrits pour des versions désuettes des logiciels. Il faut les mettre à jour pour la dernière version des logiciels, vérifier si chaque patch est toujours pertinent (en dehors du cadre de la Freebox), etc.

La seconde partie de cette dépêche retrace la bataille juridique pour arriver à cette libération, liste les logiciels libres patchés, ainsi que les logiciels libres non patchés, utilisés dans les différents produits Free.

NdM: la FSF France vient de publier un communiqué de presse intitulé « Un accord met fin au procès intenté contre Free pour non respect de la licence GNU GPL »

Depuis l'arrivée de l'ordonnanceur de processus CFS dans le noyau Linux (2.6.23) et la généralisation des processeurs multi-coeurs, plusieurs projets cherchent à améliorer la réactivité du noyau Linux, notamment pour un environnement bureau. En septembre 2009, Con Kolivas a écrit un nouvel ordonnanceur appelé BFS (Brain Fuck Scheduler). En le comparant à CFS, des bugs ont été isolés puis corrigés dans CFS. Par exemple, un test avec le codec x264 a montré que BFS était 80% plus rapide : le bug a été isolé puis corrigé par Mike Galbraith (lire Open source collaboration done right). Depuis, Con Kolivas continue d'écrire des patchs pour améliorer la réactivité.

Plus récemment, ce même Mike Galbraith a proposé un patch sur la LKML le 19 octobre 2010 pour regrouper automatiquement les tâches par terminal (TTY). Suite aux critiques d'autres développeurs, il a écrit une deuxième, puis une troisième version de son patch. Linus en personne s'est réjoui qu'un si petit patch, non intrusif, soit capable d'améliorer autant l'interactivité. Le lendemain, un article paru sur Phoronix montre en vidéo le gain notable en utilisant un cas de test similaire à celui de Linus : lancer une compilation du noyau avec make -j64 (lance 64 tâches de compilation en parallèle) dans un terminal, tout en utilisant un bureau : navigateur web et lecture de vidéo en HD.

Le patch améliore l'interactivité en distribuant le temps de processeur plus équitablement du point de vue de l'utilisateur. Il utilise les cgroups (groupe de tâches) introduits dans le noyau 2.6.24 (janvier 2008) pour l'ordonnanceur CFS. CFS permet de définir le pourcentage de temps assigné à un cgroup. Cette fonctionnalité révolutionnaire a été un peu oubliée car la création des cgroup était manuelle. Le patch de Mike propose de créer automatiquement un cgroup par TTY, et permet donc de mettre en application simplement le travail sur CFS et les cgroups. Con Kolivas a néanmoins critiqué le patch sur son blog en expliquant qu'il introduit des régressions dans les cas d'utilisation « normaux ».

Proposé après la fenêtre de tir du noyau 2.6.37, l'avenir nous dira si ce patch va être intégré ou non dans le noyau 2.6.38. Plus généralement, ces différents projets devraient à terme améliorer la réactivité de nos environnements de bureaux sous Linux.

NdM : Merci à Poloh d'avoir proposé une dépêche sur le même sujet et insert_coincoin pour son journal en lien ci-dessous.

Une situation de compétition (race condition) a été trouvée le 14 octobre dans les fonctions pipe_read_open(), pipe_write_open() et pipe_rdwr_open() du noyau Linux par Earl Chew, bug vieux de plus de dix ans. Deux jours plus tard, Earl a écrit un patch corrigeant le bug (commité le 21 octobre, il fait partie de la version 2.6.32-rc6).

L'histoire pourrait s'arrêter là, mais Eugene Teo de Red Hat a découvert cinq jours plus tard que le bug est une faille de sécurité. La faille est facile à exploiter avec la boîte à outils de Brad Spengler. Comme les dernières failles du noyau Linux (vmsplice(), tun_chr_pool() et perf_counter), la faille est liée au déréférencement d'un pointeur NULL. Brad Spengler a écrit un exploit (pouvoir passer root à partir d'un compte utilisateur) fonctionnant sur, au moins, Debian Etch, Fedora (6, 10 et 11), et RedHat (5.3 et 5.4). L'exploit contourne les protections SELinux dans le cas de Fedora 10 et RedHat 5.4. Il devrait publier son exploit dans les prochains jours.

Pour se protéger (ou vérifier si votre système est vulnérable ou non), assurez-vous que la valeur de /proc/sys/vm/mmap_min_addr ne soit pas nulle. Debian Sid, Mandriva Linux 2010.0, Fedora 12, Ubuntu (Ibex et supérieurs) et les noyaux patchés avec grsecurity ne sont pas vulnérables. Alors que Debian Lenny et Squeeze ont une valeur nulle par exemple (il est prévu de changer ça à partir de Debian 5.0.4). Comme l'option mmap_min_addr a été introduite dans Linux 2.6.23, Debian Etch (qui utilise un noyau 2.6.18) est vulnérable : vous pouvez utiliser les paquets etchhalf pour installer un noyau 2.6.24. Des correctifs pour RedHat sont déjà disponibles.

Générer des nombres aléatoires avec un ordinateur (déterministe par définition) est un problème complexe. Il est facile d'introduire un biais par une maladresse. On a vu de nombreuses failles au fil des années, un exemple récent étant la faille introduite dans la version Debian d'OpenSSL (mai 2008).

Chaque système d'exploitation propose des périphériques et API différentes, et il existe diverses bibliothèques tierces, pour générer des nombres aléatoires. La bibliothèque Hasard propose une API simple, portable et haut niveau, pour limiter les erreurs d'un développeur, tout en réutilisant les briques existantes (ex: bibliothèques OpenSSL et gcrypt).

La version 0.9.6 supporte Linux, FreeBSD, Mac OS X et Windows, et devrait fonctionner sur n'importe quel système d'exploitation disposant des périphériques /dev/urandom et /dev/random. La bibliothèque Hasard est écrite en C, propose un binding Python, et est distribué sous licence BSD.

Les mainteneurs Debian de la bibliothèque standard C ont décidé de passer de la GNU libc (glibc) à eglibc. La migration est déjà effective dans Debian Sid. La « libc » est un élément essentiel dans une distribution étant donné que l'intégralité des applications l'utilise. La décision de migrer a été mûrement réfléchie et découle de plusieurs raisons : relations difficiles avec les développeurs de la glibc, prise en charge incomplète de l'ARM dans la glibc, branche stable non maintenue, etc.

Le projet eglibc a été lancé en août 2006 par Codesourcery et est aujourd'hui soutenu par un consortium (Freescale, MIPS technologies, MontaVista, Wind River). Ce n'est pas à proprement parler un « fork » de la glibc, c'est une collection de patchs visant l'embarqué. Il permet notamment de désactiver certains composants, les locales par exemple, pour diminuer l'empreinte mémoire. La compilation croisée est également améliorée, point important pour l'embarqué. La bibliothèque eglibc est aussi compatible avec d'autres shells que le très classique Bash.

Le projet vise une compatibilité binaire avec la glibc, et pour cela l'arborescence des sources est régulièrement synchronisée. La distribution Linux OpenWrt supporte déjà eglibc (en plus d'uClibc).

Le langage de programmation Python arrive dans une version 3.1 qui marque la maturation de la branche 3.x. Le passage à Unicode par défaut pour les chaînes de caractères dans Python 3.0 était source de nombreuses régressions au niveaux des performances. Celles-ci ont été gommées par la réécriture en C de la bibliothèques d'entrées/sorties (io) et l'optimisation des décodeurs des principaux jeux de caractères (ISO-8859-1, UTF-8 et UTF-16).

Les nouvelles fonctionnalités ne sont pas en reste. Le type « dictionnaire ordonné », qui conserve l'ordre d'insertion des éléments, souvent demandé par les utilisateurs, fait enfin son entrée dans le langage sous le nom « odict » (PEP 372: Adding an ordered dictionary to collections). L'instruction « with » accepte désormais d'écrire plusieurs contextes sur la même ligne, rendant contextlib.nested() désuet.

La seconde partie de la dépêche détaille les nouveautés de la version 3.1.

Un peu moins de deux ans après la version 2.6, la fondation Python est heureuse de vous annoncer la publication de la version 2.7. Cette version marque la fin d'une ère, car ça sera la dernière version majeure de la branche Python 2. Justement, Python 2.7 apporte beaucoup de nouveautés qui viennent de Python 3.1 (listées en seconde partie de la dépêche) dans le but de simplifier la migration de Python 2 vers Python 3. La branche 2.7 sera maintenue plus longtemps que les précédentes versions 2.x.

Python est un langage de programmation interprété multi-paradigme. L'interprète standard (CPython) est distribué sous licence PSF (semblable à la licence BSD). CPython est multiplateforme : Windows, Linux, Mac OS X, *BSD, AIX, MS-DOS, OS/2, QNX, etc.
CPython sert de référence pour le langage Python et les autres implémentations : PyPy (écrit en Python), IronPython (plateforme .NET) et Jython (JVM). Ces implémentations ne sont pas aussi à jour que CPython puisque IronPython est compatible avec Python 2.6 tandis que PyPy et Jython sont compatibles 2.5.

La version 2.11 de la bibliothèque C GNU (glibc) est sortie le 30 octobre. Cette version apporte de nombreuses optimisations, de nouvelles fonctions, le support de DNSSEC, parle de nouvelles langues (Birman et Pachtou), etc. La seconde partie de cette dépêche détaille les nouveautés.

Cette version 2.11 est disponible pour ArchLinux, Linux From Scratch, Gentoo et Fedora 12. Alors qu'avant la glibc était gérée par CVS, cette version est la première à être publiée à partir du nouveau dépôt GIT. Par contre, le projet eglibc, variante de la glibc visant l'embarqué et utilisé dans Debian, continue à utiliser Subversion.