Archive for the ‘Uncategorized’ Category

Jonathan Carter élu DPL pour 2020

dimanche, avril 19th, 2020

C’est Jonathan Carter qui vient d’être élu Debian Project Leader (DPL) pour l’année 2020, succédant ainsi à Sam Hartman qui avait été élu en 2019.

Arrivé l’an passé derrière Sam Hartman presque à égalité avec Martin Michlmayr et Joerg Jaspert, Jonathan l’emporte logiquement cette année dans une élection sans réelle concurrence.

En effet, Brian Gupta avait immédiatement indiqué que le seul objet de sa candidature était de constituer un référendum, qui s’est révélé peu concluant, sur la création des fondations Debian US et Debian Europe ; tandis que la jeune indienne Sruthi Chandran, dont on devrait réentendre parler dans les prochaines années, manquait de légitimité pour le poste n’étant développeuse Debian que depuis un an.

Bravo à toi Jonathan, et bonne chance dans la mise en œuvre de ton programme !

Quel DPL pour 2020 ?

dimanche, mars 15th, 2020

Le temps passe vite, et cela fait déjà presque un an que Sam Hartman a été élu Debian Project Leader (DPL). Chaque développeur Debian pouvait donc se porter candidat entre le 8 et le 14 mars à la suite du traditionnel appel à candidatures.

Dès le 4 mars, Sam exprimait le souhait de ne pas se représenter :

TL;DR: Overall, being DPL has been incredibly rewarding. I have enjoyed working with you all, and have enjoyed the opportunity to contribute to the Debian Project. I hope to be DPL again some year, but 2020 is the wrong year for me and for the project. So I will not nominate myself this year, but hope to do so some future year.

Il y aura donc trois candidats cette année :

Les presque mille développeurs Debian seront libres de voter du 5 au 18 avril lors d’un vote utilisant la méthode Condorcet.

Vous pouvez retrouver tous les débats de la campagne sur la mailing list debian-vote.

Sam Hartman élu DPL pour 2019

dimanche, avril 21st, 2019

C’est Sam Hartman qui vient d’être élu Debian Project Leader (DPL) pour l’année 2019, succédant ainsi au second mandat de Chris Lamb qui avait été réélu sans opposition en 2018.

Dans une élection plus incertaine que les années précédentes, Sam l’emporte largement devant Martin Michlmayr, Joerg Jaspert et Jonathan Carter arrivés tous les trois quasiment à égalité – expression approximative concernant un scrutin qui utilise la méthode Condorcet, mais qui en reflète assez bien la réalité -.

Vote DPL 2019

Sam a commencé à s’investir dans le projet Debian en packageant Kerberos et d’autres logiciels de sécurité, et il participe aussi activement à l’amélioration de l’accessibilité puisqu’il présente la particularité d’être aveugle. Vous pourrez en apprendre plus sur Sam dans cette interview de lui faite par Raphaël Hertzog en 2011.

Bravo à toi Sam, et bonne chance dans la mise en œuvre de ton programme !

Quel DPL pour 2019 ?

dimanche, mars 17th, 2019

Le temps passe vite, et cela fait déjà presque un an que Chris Lamb a été réélu Debian Project Leader (DPL). Chaque développeur Debian pouvait se porter candidat entre le 3 et le 9 mars à la suite du traditionnel appel à candidatures.

Cependant, aucun candidat ne s’est déclaré pendant cette période. Après la question de la légitimité d’un scrutin avec un seul candidat, posée en 2016 par Paul Wise lorsque Mehdi Dogguy fut seul à se présenter, et déjà d’actualité en 2011 puis à nouveau d’actualité en 2018 quand Stefano Zacchiroli et Chris Lamb furent seuls à concourir à leur réélection, se posait la question de l’existence même d’un scrutin sans candidats

Heureusement la Constitution du projet Debian avait prévu ce cas de figure dans sa section 5.2. Nomination :

4. […] S’il n’y a pas de candidats à la fin de la période de désignation alors cette période est étendue d’une semaine supplémentaire, autant de fois que nécessaire.

La période de candidature fut donc prolongée d’une semaine, jusqu’au 16 mars, dans l’attente de candidats. Le fait que Lamby ait clairement explicité le fait qu’il n’avait pas l’intention de se représenter :

Whilst it would have been clear to any serious potential candidate already, for the sake of clarity I will not be looking to extend my term in this year’s DPL elections.

a semble-t-il réveillé les ambitions endormies et ce sont finalement pas moins de cinq candidats qui se présenteront cette année :

Les presque mille développeurs Debian seront libres de voter du 7 au 20 avril lors d’un vote utilisant la méthode Condorcet.

Vous pouvez retrouver tous les débats de la campagne sur la mailing list debian-vote.

Mise à jour du 29 mars 2019 : Simon Richter s’est retiré de l’élection.

Lamby 2.0 : Chris Lamb réélu DPL pour 2018

mardi, avril 17th, 2018

Chris Lamb (Lamby) vient d’être réélu Debian Project Leader (DPL). Il va donc pouvoir continuer le travail commencé l’année dernière, et vous pouvez lire sa réaction sur son blog.

Ce n’est bien sûr pas une surprise puisque Chris était le seul candidat, et qu’il n’y avait aucune raison valable de lui préférer None Of The Above et ainsi de provoquer de nouvelles élections. Voici une représentation du résultat du scrutin qui utilise la méthode Condorcet :

DPL 2018
Bravo à toi Chris, et bonne chance dans la mise en œuvre de ton programme !

Quel DPL pour 2018 ?

jeudi, mars 15th, 2018

Le temps passe vite, et cela fait déjà presque un an que Chris Lamb a été élu Debian Project Leader (DPL). Chaque développeur Debian pouvait se porter candidat entre le 4 et le 10 mars à la suite du traditionnel appel à candidatures.

La question de la légitimité d’un scrutin avec un seul candidat, posée en 2016 par Paul Wise lorsque Mehdi Dogguy fut seul à se présenter, est malheureusement à nouveau d’actualité. En effet, seul le DPL sortant s’est porté candidat cette année :

Et force est de constater que les candidats ne se bousculent encore et toujours pas au portillon pour devenir DPL. Peu de développeurs semblent motivés par cette charge comme l’exprimait déjà Lars Wirzenius il y a deux ans :

After some serious thinking, I’ve decided not to nominate myself in the Debian project leader elections for 2016. […] Why not run? I don’t think I want to deal with the stress. I already have more than enough stress in my life, from work.

En plus de son rôle de développeur Debian et de DPL 2017, Chris Lamb est un important contributeur du projet Reproducible builds ainsi que du framework web Python Django et de son écosystème.

Les presque mille développeurs Debian seront libres de voter du 1er au 14 avril lors d’un vote utilisant la méthode Condorcet car, même en l’absence d’autres candidats, Chris Lamb reste en concurrence avec le choix None Of The Above.

Vous pouvez retrouver tous les débats de la campagne sur la mailing list debian-vote.

Chris Lamb élu DPL pour 2017

dimanche, avril 16th, 2017

C’est Chris Lamb qui vient d’être élu Debian Project Leader (DPL) pour l’année 2017, succédant ainsi au mandat de Mehdi Dogguy qui avait été élu sans opposition en 2016.

Si le mandat de Mehdi s’est bien déroulé, il donnait peut-être trop l’impression d’un Zack 4.0, et il semblerait donc que Chris puisse apporter une nouvelle dynamique au projet Debian. Voici une représentation du résultat du scrutin qui utilise la méthode Condorcet.

Vote DPL 2017

Bravo à toi Chris, et bonne chance dans la mise en œuvre de ton programme !

Quel DPL pour 2017 ?

dimanche, mars 12th, 2017

Le temps passe vite, et cela fait déjà presque un an que Mehdi Dogguy a été élu Debian Project Leader (DPL). Chaque développeur Debian pouvait se porter candidat entre le 5 et le 11 mars à la suite du traditionnel appel à candidatures.

La question de la légitimité d’un scrutin avec un seul candidat, posée l’année dernière par Paul Wise, n’est heureusement plus d’actualité, mais force est de constater que les candidats ne se bousculent toujours pas au portillon pour devenir DPL. Il y en aura donc deux cette année :

En plus de son rôle de développeur Debian, Chris Lamb est un important contributeur du projet Reproducible builds ainsi que du framework web Python Django et de son écosystème.

Les presque mille développeurs Debian seront libres de voter du 2 au 15 avril lors d’un vote utilisant la méthode Condorcet.

Vous pouvez retrouver tous les débats de la campagne sur la mailing list debian-vote.

Les fonctions anonymes lambda en Python : print, expressions conditionnelles et récursivité

samedi, décembre 24th, 2016

Si Python n’est pas un langage de programmation fonctionnelle, il possède cependant des fonctions anonymes lambda qui sont typiques de cette famille de langages. Ces fonctions sont réputées peu puissantes en Python car elle ont été volontairement limitées syntaxiquement à une expression, sans possibilité d’utiliser des instructions. Pourtant, nous allons voir qu’elles ont dans ce langage quelques particularités intéressantes.

Print

L’instruction print est devenue une fonction print() – et donc une expression – dans Python 3 suite à la PEP 3105. Ainsi, si vous utilisez print dans une fonction lambda, Python 2 lèvera une exception SyntaxError: invalid syntax alors que Python 3 l’acceptera :

>>> pr = lambda x : print(x)
>>> pr('OK en Python 3')
OK en Python 3

Expressions conditionnelles

Introduites (tardivement) dans Python 2.5 suite à la PEP 308, les expressions conditionnelles sont une manière simplifiée de réaliser grâce à l’opérateur ternaire true_value if condition else false_value la suite d’instructions suivante :

if condition:
    x = true_value
else:
    x = false_value

Comme leur nom l’indique, les expressions conditionnelles sont bien des expressions et elles permettent donc de mettre de la logique dans les fonctions lambda. Cela était déjà possible précédemment, en abusant un peu les opérateurs logiques classiques avec condition and true_value or false_value, mais c’est une méthode que je déconseille car elle n’est pas totalement fiable pour certaines valeurs de condition.

Dans l’exemple suivant, j’utilise une expression conditionnelle avec la fonction print() et donc Python 3, ce dernier me permettant d’utiliser un nom de variable avec le caractère non-ASCII é (PEP 3131) :

>>> majorité = lambda x : print("mineur") if x < 18 else print("majeur")
>>> majorité(15)
mineur
>>> majorité(25)
majeur

Récursivité

Le principe des fonctions anonymes étant de ne pas être nommées, il est donc logiquement difficile de les appeler. Ainsi, les fonctions anonymes de certains langages fonctionnels ne peuvent pas s’appeler, et donc ne peuvent pas être récursives. En Python, les lambda sont un sucre syntaxique limité des fonctions normales mais elles leur sont sémantiquement équivalentes, et elles peuvent donc parfaitement s’appeler récursivement.

En utilisant une expression conditionnelle et la récursivité on peut ainsi facilement implémenter l’algorithme récursif naïf de la très classique suite de Fibonacci :

>>> fib = lambda n : n if n < 2 else fib(n - 1) + fib(n - 2)
>>> fib(1)
1
>>> fib(10)
55
>>> fib(25)
75025

Vous n’arriverez pas à atteindre la limite de récursivité de l’interpréteur Python avec cet algorithme de complexité exponentielle, mais vous pourrez le faire aisément avec un algorithme à récursion terminale :

>>> fib2 = lambda n, a, b: fib2(n-1, b, a+b) if n > 0 else a
>>> fib2(200, 0, 1)
280571172992510140037611932413038677189525
>>> fib2(1000, 0, 1)
RuntimeError: maximum recursion depth exceeded

Compréhension de liste

On peut enfin ajouter que l’usage de compréhension de liste permet aisément de faire une boucle dans une fonction lambda :

>>> incr = lambda liste : [i + 1 for i in liste]
>>> incr([1, 45, 340])
[2, 46, 341]

Mise à jour du 18 mars 2019 : Ajout du Fibonacci à récursion terminale.

Base LEGI et système de fichiers : ext4 vs XFS

jeudi, décembre 8th, 2016

Comme je l’indiquais dans mon article sur la base LEGI, cette dernière est assez volumineuse et structurée d’une manière très complexe. Ainsi, la dernière version de la base est composée de 1 624 783 fichiers XML, répartis dans une arborescence absconse de 1 537 949 sous-répertoires pour une taille d’une dizaine de Go.

Cette structure est suffisamment extrême pour nous amener à nous interroger sur le choix et sur les performance de notre système de fichiers, alors que la plupart des gens utilisent un système de fichiers sans même en avoir vraiment conscience et a fortiori sans le choisir.

Le première chose si vous souhaitez travailler sur la base LEGI, qui est composée d’un très grand nombre de petits fichiers, c’est de privilégier l’utilisation d’un SSD à celle d’un disque dur classique. En effet, les performances seront 10 à 20 fois meilleures avec un SSD.

Les systèmes de fichiers sont un sujet très technique et de très bas niveau, sur lequel peu de personnes sont compétentes et où les convictions affichées relèvent parfois plus de la croyance que de l’analyse scientifique. Voici donc trois éléments de comparaison objectifs et compréhensibles des systèmes de fichiers ext4 – le choix par défaut sous Linux – et XFS.

1) Taille de la base LEGI

Dans mon article je mentionnais que la base LEGI pouvait varier de taille selon le système de fichier, sans citer explicitement ext4 et XFS.

ext4 : 15 Go
XFS : 9 Go

Pourquoi une telle différence ? C’est Jean-Baptiste Denis qui m’a aidé à percer ce mystère. En fait XFS possède des Shortform Directories qui permettent de stocker les petits répertoires directement dans leur inode. Les 6 Go supplémentaires correspondent donc aux 1 537 949 blocs de 4 Ko créés par ext4 pour chacun des sous-répertoires.

Vainqueur : XFS

2) Nombre d’inodes

Un inode est utilisé par fichier et par répertoire lors de la décompression de la base LEGI. Il faut donc que la partition dans laquelle est stockée la base possède au minimum 1 624 783 + 1 537 949 = 3 162 732 inodes. Or le nombre d’inodes varie selon les systèmes de fichiers et les options de formatage. Pour visualiser le nombre d’inodes de vos partitions il suffit d’utiliser la commande df -ih.

ext4 : 65 000 inodes/Go
XFS : 1 000 000 inodes/Go

Ceci n’est pas du tout anecdotique, car beaucoup d’hébergeurs ne permettent pas de choisir votre système de fichier : ce sera ext4 avec ses options de formatage par défaut et rien d’autre. Avec seulement 65 000 inodes par Go, il faudra une partition d’une taille minimale de 50 Go pour pouvoir stocker la base entière. Cela implique que certaines offres de VPS peu chères, avec une capacité de stockage SSD de petite taille, ne vous permettront pas d’exploiter la base LEGI.

Vainqueur : XFS

3) Performances

J’ai évalué les performances des deux systèmes de fichiers avec plusieurs commandes parcourant la base LEGI sur un serveur Xeon 8 cœurs 3,7 GHz doté de 16 Go de RAM et d’un SSD. Les résultats permettent de comparer Ext4 et XFS, mais les performances sur votre ordinateur risquent d’être nettement inférieures.

J’ai utilisé la commande echo 3 | sudo tee /proc/sys/vm/drop_caches pour vider les caches avant chaque essai (merci Jean-Baptiste bis).

Commandeext4XFSext4/XFS
du -hsc legi3'08"0'53"3,5
find legi -type d | wc -l3'06"0'56"3,3
find . -name "*.xml" | wc -l2'54"0'51"3,4
tar xzf Freemium_legi_global.tar.gz2'26"1'18"1,9

On peut ici conclure que XFS se révèle globalement 3 fois plus rapide qu’ext4.

Vainqueur : XFS

XFS sort donc grand vainqueur de cette comparaison avec ext4, et je ne peux que vous encourager à l’utiliser si vous voulez exploiter la base LEGI. À titre personnel, j’ai décidé de ne plus utiliser que XFS.