Quel DPL pour 2019 ?

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.

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

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 ?

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

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 ?

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é

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

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.

Ruby est mourant (Python, Node.js, Go et Elixir l’ont tué)

décembre 5th, 2016

En août 2015 GitHub publiait le classement des langage de programmation les plus populaires depuis son lancement en 2008. L’article mettait l’accent sur la progression de Java, lié à l’adoption des services de GitHub par les entreprises friandes de ce langage, mais c’est bien l’évolution de la popularité de Ruby qui m’avait le plus interpellé.

Leader aux premiers jours de 2008, avec en particulier la présence immédiate de Ruby on Rails sur GitHub (GitHub est une application Ruby en Rails), Ruby est passé 2ème en 2013, puis 3ème en 2014 et enfin 4ème en 2016.

github

Suivant de près la popularité des langages sur GitHub, j’ai eu la chance de capturer hier l’improbable moment où PHP – le grand-père du web en net regain de forme depuis la sortie de PHP 7 – a dépassé l’enfant prodige pour le reléguer à la 5ème place !

classment2

Mais si Ruby est mourant, quels sont donc ses meurtriers ?

Python pour la diversité d’utilisation

Python est un peu le concurrent historique de Ruby, tant ces deux langages semblaient occuper la même « niche » de langage de programmation moderne, dynamique et orienté objet. Ce que l’on peut faire avec Python on peut le faire avec Ruby, et réciproquement, le choix entre les deux est plus une question de feeling sur la syntaxe du langage ou l’ambiance de la communauté.

Oui mais justement, que fait-on avec ces langages ? En première page du site web du langage Python on peut trouver une section « Use Python for… » qui donne une réponse à cette question dans le but de conforter les débutants dans leur choix de Python : ils ne vont pas seulement apprendre un langage de programmation puissant et facile d’utilisation, mais aussi un outil pour faire plein de choses utiles et très diverses.

python

Car si Python est bien sûr utilisé pour la programmation web et qu’il a son alter ego de Rails avec Django, il est aussi énormément utilisé dans bien d’autres domaines. Python est installé par défaut sur toutes les distributions GNU/Linux et sur macOS, il est largement utilisé en administration système, s’est imposé pour des utilisations scientifiques et pédagogiques et représente le choix le plus simple et efficace pour développer des interface graphiques, avec de nombreux bindings vraiment fonctionnels et maintenus.

Ruby et sa communauté sont en comparaison par trop web-centric. Rails, Sinatra et Jekyll sont formidables, et ils étaient même très innovants, mais de nombreux projets s’en sont inspiré, des équivalents ont été développés dans d’autres langages et ils ne peuvent plus à eux seuls justifier d’apprendre le Ruby. Ruby a percé grâce à Rails et au web, mais il n’a jamais su s’en émanciper et c’est ce qui est en train de causer sa perte.

Node.js pour le buzz

D’une manière qui a parfois pu irriter les pythonistes, Ruby a longtemps eu l’image d’un langage cool, et tout ce qui s’y rapportait de près ou de loin faisait facilement le buzz. Oui mais voilà, Node.js est passé par là, amenant au JavaScript l’ubiquité, cette exceptionnelle singularité d’être le seul langage de programmation présent à la fois côté serveur et côté client.

trend

Node.js a bénéficié d’une large et dynamique communauté préexistante de développeurs JavaScript, ce qui a permis son adoption à une vitesse incomparable à celle d’un « nouvel entrant ». Node.js a donc attaqué frontalement Ruby sur sa niche web tenue par Ruby on Rails et l’a en quelque sorte dépossédé de son buzz.

Go et Elixir pour les performances

Deux langages de programmation récents ont aussi causé beaucoup de tort à Ruby en l’attaquant sur le terrain des performances, son point faible historique. On peut ainsi développer rapidement de beaux et fonctionnels sites web avec Ruby on Rails, mais quand le succès arrive, il est alors très difficile de scaler. Le remplacement de Ruby on Rails par du Java par Twitter en 2011 en est bien sûr l’exemple le plus cinglant.

Go est un langage de programmation compilé créé par Google en 2007 et rendu disponible en 2009. Alors que l’on pensait que ce langage allait attirer les développeurs C et C++ à la recherche de plus de confort, il a en fait attiré beaucoup de développeurs de langages dynamiques à la recherche de plus de performances. Ainsi de nombreuses personnes réécrivent leur application Rails en Go et constatent des gains de performances leur permettant par exemple de passer de 30 à 2 serveurs pour l’hébergement, ce qui implique des économies de travail, de temps et d’argent colossales.

Elixir est un langage de programmation fonctionnel datant de 2012 qui utilise BEAM, la formidable machine virtuelle massivement concurrente développée pour Erlang. La particularité d’Elixir est de reprendre la sémantique d’Erlang et de la proposer aux développeurs sous la forme d’une nouvelle syntaxe… inspirée du Ruby ! Cela n’est pas très surprenant quand on sait qu’Elixir a été créé par José Valim, un des principaux développeurs de Ruby on Rails. Et ce sont bien sûr les problèmes de performance de Ruby qui ont motivé sa démarche. Elixir se positionne donc clairement comme un nouveau Ruby, mais qui scale.

Il est très probable que Go et Elixir vont continuer à devenir de plus en plus populaires dans les années qui viennent, et que Ruby va avoir beaucoup de difficultés à s’en relever. Un dernier petit exemple en passant, sur les cinq logiciels libres dont je parlais dans mon article sur la base LEGI, deux sont en Python, un en PHP, un en Go, un en Julia… et aucun en Ruby.

Open Data juridique : l’utilisation de la base LEGI

novembre 12th, 2016

Suite au rapport sur l’ouverture des données publiques que le magistrat à la Cour des comptes et développeur Debian Mohammed Adnène Trojette a remis au Premier ministre le 5 novembre 2013, la majorité des bases de données juridiques de l’administration française ont été rendues disponibles en Open Data.

Ainsi, depuis juin 2014, la base LEGI, composée de l’ensemble des codes, lois et règlements français, est mise à disposition par la DILA, la Direction de l’information légale et administrative. La base complète est fournie environ deux fois par an sous la forme d’un ficher archive compressé, auquel viennent s’ajouter des mises à jour quotidiennes.

La base LEGI est très imposante. La dernière archive complète (Freemium_legi_global_20160406-082840.tar.gz) pèse 745 Mo, et elle se décompresse dans un répertoire legi d’une taille variant entre 9 et 15 Go selon votre système de fichiers.

Une fois que les données sont en Open Data, toutes les initiatives deviennent possibles. Voici les six projets que j’ai pu référencer :

NomArchéo Lexlegi.pyLegi DisplayLegit.jllegifrance-goCodes Droit.org
AuteurSeb35ChangacoSedLexeraviart (Etalab)SteeveHabett
Origine des donnéesLEGILEGILEGILEGILégifrance puis LEGILégifrance puis LEGI
ProductionDépôts GitTest des donnéesPlugin WordPressDépôts GitDépôt GitPDF et ePub
LangagePythonPythonPHPJuliaGoPerl
SGBDSQLite (Peewee)SQLiteMySQL---
LicenceWTFPLCC0GPLMITGPLPropriétaire

Le projet le plus ancien est les Codes pour Droit.org, qui a précédé l’ouverture de la base LEGI. Ce projet avait donc commencé en récupérant directement les données du site web Légifrance.

Le seul projet a avoir bénéficié d’une importante couverture médiatique -d’un gros buzz-, avec articles sur Le Monde et Le Figaro, tweets de Maître Éolas et de la secrétaire d’État chargée du numérique Axelle Lemaire, et en conséquence plus de 2 500 étoiles sur GitHub, est le Code civil que Steeve fournit sous la forme d’un dépôt Git.

Paradoxalement c’est un projet techniquement très limité :

  • seulement deux codes fournis (d’abord le Code civil, puis le Code pénal)
  • récupération des données du site web Légifrance alors que la base LEGI était disponible depuis presque un an
  • logiciel de génération des codes jamais distribué, donc propriétaire

Cependant, il a eu le grand mérite de faire connaître au grand public ce qui est sûrement l’innovation la plus importante que l’informatique peut apporter à l’étude des textes juridiques : une bonne visualisation des changements entre les versions grâce aux diff générés par un logiciel de gestion de versions comme Git.

Diff Article 34 du Code civil

Archéo Lex, un projet complet qui fournit tous les codes de la base LEGI sous la forme de dépôts Git ainsi que le logiciel utilisé pour les générer, était pourtant apparu plusieurs mois avant le Code civil de Steeve…

Enfin, la mission Etalab s’est emparée de la démarche et a fourni tous les codes et toutes les lois non codifiées sous la forme de dépôts Git ainsi que Legit.jl, le logiciel utilisé pour les générer. C’est très bien, mais je trouve que le choix du langage de programmation Julia est contestable, non pas d’un point de vue technique, mais d’un point de vue communautaire. En choisissant un langage aussi confidentiel, on se prive de toute chance de voir des contributeurs extérieurs s’y intéresser…

Concernant la qualité des données de la base LEGI, Seb35 remercie la DILA pour la très bonne qualité des métadonnées tandis que Changaco indique avoir été un peu découragé par la structure médiocre des données.

Personnellement, je pense que le manque de dynamique autour de la base LEGI, qui est pourtant l’une des plus intéressantes de l’Open Data en France, s’explique par la complexité de l’organisation des données qui la rend difficilement exploitable. 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. Je suis convaincu qu’il reste encore plein de choses à faire pour rendre ces riches données plus accessibles et plus exploitables.

Mise à jour du 16 novembre 2016 : Tous les codes sont présents dans la branche everything du Code civil de Steeve, et ils ont été générés à partir de la base LEGI avec le logiciel libre legifrance-go.

Arduino, la réunification

octobre 2nd, 2016

Banzi et Musto au Maker Faire de New York

Massimo Banzi (à gauche sur la photo) et Federico Musto (à droite) viennent d’annoncer sur l’estrade du Maker Faire de New York la « réunification » du projet Arduino. Arduino LLC et Arduino srl ont de plus publié conjointement un communiqué sur leur site web respectif Arduino.cc et Arduino.org.

Il y a un an et demi, en mars 2015, la scission du projet Arduino avait été rendue publique. Une bataille juridique s’était engagée concernant la propriété et l’exploitation de la marque Arduino dans le monde, amenant à la création de la marque Genuino. La disponibilité des produits Arduino était devenue très problématique et la vision du futur plus qu’incertaine.

La situation était très préjudiciable au plus important des projets de hardware libre et je suis vraiment très heureux de relayer l’annonce d’une transaction entre les parties plutôt que de faire un cas pratique de droit des marques sur le sujet !