C’est Lucas Nussbaum qui vient d’être élu Debian Project Leader (DPL) pour l’année 2013, succédant ainsi au triple mandat de Stefano Zacchiroli.
Lucas Nussbaum devance Allan Moray et Gergely Nagy (déjà candidat malheureux en 2004 et 2012). Voici une représentation du résultat du scrutin qui utilise la méthode Condorcet.
Bravo à toi Lucas, et bonne chance dans la mise en œuvre de ton programme à partir du 17 avril !
Pour comprendre la génèse de la syntaxe des sets, il faut étudier celle des types conteneurs historiques de Python qui sont :
[ et ]( et ){ et }Ces types conteneurs sont donc dotés d’une syntaxe légère et facilement utilisable :
>>> l = [1, 2, 3]
>>> l
[1, 2, 3]
>>> t = (1, 2, 3)
>>> t
(1, 2, 3)
>>> d = {1: '1', 2: '2', 3: '3'}
>>> d
{1: '1', 2: '2', 3: '3'}
Les tuples, qui sont en fait des listes immutables et que l’on ne peut donc pas modifier, sont souvent oubliés car assez peu utilisés, en tout cas de manière consciente. En effet, une simple énumération sans syntaxe spécifique est en fait un tuple :
>>> e = 1, 2, 3
>>> e
(1, 2, 3)
Si l’on peut donc dire que globalement, les listes et les dictionnaires répondent à la grande majorité des besoins des programmeurs, un quatrième type conteneur s’est lentement mais sûrement fait une place au soleil des pythonistes : les sets.
Un set est un ensemble, c’est-à-dire une collection non ordonnée d’éléments uniques, ce qui se révèle très pratique dans beaucoup d’usages courants. Ce nouveau type conteneur étant fourni en deux saveurs, l’une mutable (comme les listes), et l’autre immutable (comme les tuples).
D’abord introduits dans Python 2.3 sous la forme d’un nouveau module sets ajouté à la bibliothèque standard. Il est ensuite devenu un type built-in dans Python 2.4, ce qui représentait une amélioration syntaxique non négligeable. Plus besoin d’écrire :
>>> import sets
>>> s_mutable = sets.Set([1, 2, 3])
>>> s_immutable = sets.ImmutableSet([1, 2, 3])
On pouvait dorénavant se contenter de :
>>> s_mutable = set([1,2,3])
>>> s_immutable = frozenset([1,2,3])
Et de bénéficier en plus d’une implémentation du type set en C et non plus en Python, avec la belle augmentation de performance qui va avec.
L’intégration des sets mutables (les plus utiles) dans le core du langage Python, au même niveau que les tuples, les listes et les dictionnaires, se heurtait encore à une limitation syntaxique : il fallait écrire set([1, 2, 3]). En effet, il n’y a que trois signes de ponctuation ASCII 7 bits fonctionnant par paire et facilement accessibles sur un clavier, les parenthèse, les crochets et les accolades, qui comme on l’a vu sont déjà utilisés respectivement par les tuples, les listes et les dictionnaires.
Mais que pouvait-on alors faire pour mieux intégrer syntaxiquement les sets à Python ? C’est dans Python 3.0 que la solution a été trouvée : si les tuples et les listes sont des énumérations que l’on ne pourrait distinguer des sets, les dictionnaires sont eux bien différents, et l’on peut donc utiliser les accolades { et } pour une énumération sans risque de confusion :
>>> s = {1, 2, 3}
>>> s
{1, 2, 3}
Il reste cependant une petite exception qui rend cette solution syntaxique imparfaite, et potentiellement génératrice d’erreurs ou d’incompréhensions, c’est le cas de l’ensemble vide. En effet, {} ne peut pas représenter à la fois le dictionnaire vide et le set vide :
>>> s = {}
>>> s
{}
>>> isinstance(s, set)
False
>>> isinstance(s, dict)
True
De manière logique et rétrocompatible, {} représente donc toujours le dictionnaire vide, et c’est set() qui permet de créer un set vide :
>>> s = set()
>>> s
set()
>>> s.add(1)
>>> s
{1}
Enfin, ce sucre syntaxique de Python 3 a été backporté dans Python 2.7.
Le temps passe vite, et cela fait déjà presque un an que Stefano Zacchiroli, dit Zack, a vu son mandat de Debian Project Leader (DPL) re-renouvelé.
Le plus important est bien sûr de lire les programmes de chacun des candidats :
Les presque mille développeurs Debian seront libres de faire leur choix du 31 mars au 13 avril lors d’un vote utilisant la méthode Condorcet.
Il y a trois candidats, le même nombre que l’année dernière, ce qui est un peu moins en moyenne que les années précédentes, mais l’absence du triple sortant laisse présager d’un scrutin très ouvert. Les candidats doivent vraiment se sentir libres de proposer des idées et des orientations originales et innovantes.
La campagne qui commence et qui durera jusqu’au 30 mars devrait donc être très dynamique et permettre d’ouvrir publiquement certains débats, ce que chacun pourra suivre sur la mailing list debian-vote.
Le 26 octobre 2012 a été publiée la cinquième version des exceptions à l’interdiction de contournement des systèmes de protection du Copyright (droit d’auteur) aux États-Unis. Ces exceptions sont débattues dans le cadre d’une longue procédure de consultations participatives prévue par la section 1201 du Digital Millennium Copyright Act (DMCA), et menée par le bureau du Copyright de la bibliothèque du Congrès.
Cette révision triennale de la réglementation a pour but de permettre une adaptation rapide du cadre juridique aux évolutions technologiques. C’est une manière de procéder très différente de la nôtre, puisque nous bénéficions en France d’un cadre légal définissant à l’article L. 122-6-1 IV du Code de la propriété intellectuelle une exception globale à des fins d’interopérabilité :
La reproduction du code du logiciel ou la traduction de la forme de ce code n’est pas soumise à l’autorisation de l’auteur lorsque la reproduction ou la traduction au sens du 1° ou du 2° de l’article L. 122-6 est indispensable pour obtenir les informations nécessaires à l’interopérabilité d’un logiciel créé de façon indépendante avec d’autres logiciels [...]
Le défaut de cette méthode est que c’est le juge qui trace la limite par la jurisprudence, et qu’en l’absence de contentieux et donc de jugements, nous sommes confrontés à une forme “d’insécurité juridique”. Les américains savent eux de manière beaucoup plus claire ce qu’il est possible de faire ou non. Ainsi, concernant les smartphones et les tablettes, c’est la classe B qui nous intéresse :
B. Wireless Telephone Handsets—Software Interoperability
Computer programs that enable wireless telephone handsets to execute lawfully obtained software applications, where circumvention is accomplished for the sole purpose of enabling interoperability of such applications with computer programs on the telephone handset.
This exemption is a modification of the proponents’ proposal. It permits the circumvention of computer programs on mobile phones to enable interoperability of non-vendor-approved software applications (often referred to as ‘‘jailbreaking’’), but does not apply to tablets—as had been requested by proponents—because the record did not support it.
Mais qui étaient donc les “proponents” , c’est à dire ceux qui ont proposé et soutenu cette classe de périphériques, qui voulaient pouvoir jailbreaker non seulement leurs smartphones, mais aussi leurs tablettes ?
Proponent Electronic Frontier Foundation (‘‘EFF’’), joined by New America Foundation’s Open Technology Initiative, New Media Rights, Mozilla Corporation (‘‘Mozilla’’), and the Free Software Foundation (‘‘FSF’’), as well as several hundred individual supporters
Il n’est pas surprenant d’y retrouver l’EFF, déjà à l’origine de la proposition en 2010, soutenue par les groupements du logiciel libre les plus influents politiquement, la FSF et Mozilla, ainsi que par des centaines de particuliers. Mais pourquoi le bureau du Copyright a-t-il refusé de considérer cette nouvelle catégorie de périphériques ? Le FUD habituel d’un lien entre jailbreak et “piratage”, c’est-à-dire “contrefaçon” en droit français, est balayé d’un revers de main :
While Joint Creators raised concerns about pirated applications that are able to run on jailbroken devices, the record did not demonstrate any significant relationship between jailbreaking and piracy.
C’est en fait le caractère mal défini ou trop large de l’appellation “tablette”, recouvrant potentiellement trop de types de périphériques différents, qui est la justification du refus :
The Register found significant merit to the opposition’s concerns that this aspect of the proposed class was broad and illdefined, as a wide range of devices might be considered ‘‘tablets,’’ notwithstanding the significant distinctions among them in terms of the way they operate, their intended purposes, and the nature of the applications they can accommodate. For example, an ebook reading device might be considered a ‘‘tablet,’’ as might a handheld video game device or a laptop computer.
Même si l’agence gouvernementale américaine des télécoms (NTIA) était d’un tout autre avis, puisqu’elle considérait la définition proposée par l’EFF comme totalement pertinente :
NTIA was persuaded that the proposed class should apply to tablets as well as mobile phones, believing that category to have been sufficiently defined by EFF.
Cependant, le bureau du Copyright n’insulte pas l’avenir et laisse la porte ouverte pour les prochaines révisions des exceptions :
In future rulemakings, as mobile computing technology evolves, such a definition might be more attainable
Dont acte, rendez-vous en 2015 !
Canonical a décidé de tuer Unity 2D, la version d’Unity fonctionnant même sans carte graphique 3D puisqu’utilisant Qt et Metacity en lieu et place de Nux et Compiz.
Personnellement je l’ai appris par un message d’Ogra, sur la mailing list Ubuntu/AC100 à laquelle je suis inscrit car le port d’Ubuntu pour le Toshiba AC100 est de loin la meilleure distribution Linux disponible pour cette machine (que j’ai offerte à ma sœur et dont j’assure la maintenance). Mais si cela a autant d’importance pour moi c’est que j’utilise Unity 2D, que je trouve plus légère et plus rapide qu’Unity, sur toutes mes machines Desktop.
En fait, la décision a d’abord été annoncée lors du Ubuntu Developer Summit Q, au détour d’une conférence sur l’avenir de GNOME dans Ubuntu. Sa réalisation a commencé avec un bug à portée générale et vient d’être confirmée par Jason Warner, le Ubuntu Desktop Manager.
Mais alors que se passera-t-il lorsqu’un ordinateur n’aura pas les capacités 3D nécessaires à Unity, si l’on ne peut plus avoir recours à Unity 2D ? La solution choisie par Canonical est la même que celle que Red Hat a mise en œuvre pour GNOME Shell et qui fonctionne depuis Fedora 17 : utiliser LLVMpipe, qui est basé sur Gallium3D, pour émuler en software les fonctionnalités 3D manquantes du hardware.
Ceci implique très logiquement de gros problèmes de performance et, le plus grave selon moi, une compatibilité limitée aux seuls processeurs x86. Or, en plus du Toshiba AC100 et de son processeur ARM, j’utilise aussi de vieux Macs équipés de processeurs PowerPC comme desktop…
L’intérêt bien compréhensible de Canonical est de concentrer toutes ses forces dans un seul projet. Cette démarche est rationnelle, mais le choix du projet est plus que contestable, car c’est celui qui fonctionne le mieux, alors même qu’il est plus jeune et qu’il bénéficie de moins de développeurs, qui se retrouve sacrifié.
Comme je l’avais envisagé à l’annonce d’Unity 2D, Canonical simplifie son offre logicielle pour le desktop, mais contrairement à ce que j’espérais ce n’est pas Unity qui disparaît. Pourtant, le choix d’Unity 2D pour le projet Ubuntu TV et les besoins du projet Ubuntu for Android m’avaient clairement conforté dans mon analyse, et rendent d’autant plus surprenante la décision d’abandonner Unity 2D maintenant.
Est-il encore temps de réagir et d’obtenir que Canonical revienne sur sa décision ? Un fork d’Unity 2D, avec port immédiat vers GSettings, sans le soutien de Canonical est-il viable ? J’ai vraiment l’impression de ne pas être le seul à préférer Unity 2D à Unity pour des machines ayant un support 3D, et je me demande si Canonical avait vraiment conscience de cela au moment où la mise à mort de Unity 2D a été décidée…
Prince of Persia est un jeu vidéo culte qui a réellement marqué l’histoire des jeux vidéo, en particulier pour son innovante technique d’animation rotoscopique. Or sa version originelle, sortie sur Apple II en 1989, vient d’être libérée par Jordan Mechner.
C’est son père qui, il y a trois semaines, en faisant du rangement, a retrouvé dans un carton trois vieilles disquettes 3.5″, âgées de plus de 20 ans, dans lesquelles se trouvait encore le précieux code source du jeu.
Le code source, qui est maintenant disponible sur GitHub, est de l’assembleur pour 6502, un processeur utilisé sur une très grande variété de machines différentes, ce qui laisse pas mal d’espoir de voir apparaître de nouveaux portages. La riche documentation technique, fournie à l’époque par Jordan pour aider les développeurs effectuant les portages commerciaux, devrait alors être encore une fois d’un grand secours.
La disponibilité du code source rend les choses beaucoup plus simples, bien que la programmation en assembleur puisse paraître effrayante pour beaucoup de programmeurs “modernes”, et évite d’avoir recours au reverse engineering comme lors du superbe travail de portage de Prince of Persia sur Commodore 64, économisant ainsi beaucoup d’énergie et de talent.
Le choix de la licence utilisée n’est pas encore très clair, Jordan indiquant juste dans le README:
We did this for fun, not profit. As the author and copyright holder of this source code, I personally have no problem with anyone studying it, modifying it, attempting to run it, etc. Please understand that this does NOT constitute a grant of rights of any kind in Prince of Persia, which is an ongoing Ubisoft game franchise. Ubisoft alone has the right to make and distribute Prince of Persia games.
Je lui ai demandé des précisions sur son Twitter, moyen de communication qu’il semble privilégier, et j’espère qu’il répondra rapidement. En attendant, vous pouvez toujours jouer au clone Flash de POP :
Et ainsi réfléchir aux Ghz de CPU et aux Go de RAM que vous utilisez, alors que la version dont on a aujourd’hui le code source faisait que le Mhz du 6502 et ses quelques Ko de RAM suffisaient à obtenir le même résultat.
À l’époque où un jeu vidéo était une œuvre indissociable de son développeur, inventeur aussi bien de l’idée originale que du scénario, créateur aussi bien du code source que des graphismes ; et où chaque instruction assembleur utilisée était un trésor d’optimisation de code (when men were men and wrote their own device drivers)…
Stefano Zacchiroli (Zack) vient d’être re-réélu Debian Project Leader.
Il devance très largement Wouter Verhelst (déjà candidat malheureux en 2007 et 2010) et Gergely Nagy (déjà malheureux lui en 2004) :
Zack a annoncé pendant la campagne que ce troisième mandat consécutif de DPL serait son dernier. Souhaitons qu’il se déroule aussi bien, et même encore mieux !, que les deux premiers, et que Zack puisse mettre en œuvre au mieux son programme.
En passant place de la Bastille à Paris (j’ai cours tout près, à l’EFB, rue de Charenton), j’ai croisé un Abribus d’un nouveau genre, aux allures de soucoupe volante, doté d’un design futuriste et de nombreux écrans :
Cet Abribus est un prototype de JCDecaux, faisant partie des 40 projets de mobilier urbain intelligent retenus par la ville de Paris. Le grand écran de 42 pouces en pleine action :
Les deux écrans de l’arrière :
Les écrans sont tous tactiles multitouch et proposent de nombreux services que je ne détaillerai pas car là n’est pas mon propos. En effet, c’est le système d’exploitation utilisé par cet Abribus qui m’intéresse, et l’utilisateur de smartphone un peu perspicace que je suis a tout de suite reconnu Android, un système d’exploitation libre basé sur le noyau Linux !
Ceci est une réelle bonne nouvelle, car jusqu’à présent JCDecaux utilise pour ses différentes bornes des solutions basées sur Microsoft Windows, ce qui présente pas mal d’inconvénients. Ainsi, tous les utilisateurs réguliers de Vélib’ ont été au moins une fois confrontés à une station totalement plantée, ce que JCDecaux résout tant bien que mal en redémarrant ses bornes toutes les nuits…
Si, à l’avenir, Android devait remplacer Windows, les utilisateurs y gagneraient donc des stations plus stables et plus fonctionnelles, et JCDecaux ferait des économies de licence (ce qui devrait impliquer des économies pour la Ville de Paris et donc pour les contribuables parisiens…).
Le temps passe vite, et cela fait déjà presque un an que Stefano Zacchiroli, dit Zack, a vu son mandat de Debian Project Leader (DPL) renouvelé. Sans concurrent en 2011, Zack est cette année en compétition avec Wouter Verhelst (candidat malheureux en 2007 et 2010) et Gergely Nagy (malheureux lui en 2004). Il a justifié sa nouvelle candidature par le proverbe italien “Non c’è due senza tre“, qui semble bien être l’équivalent de notre “Jamais deux sans trois”.
Le plus important est bien sûr de lire les programmes de chacun des candidats :
Les presque mille développeurs Debian sont maintenant libres de faire leur choix lors d’un vote utilisant la méthode Condorcet. Le nombre de trois candidats est un peu inférieur à la moyenne des années précédentes, qui est de quatre environ, mais il permet tout de même un belle campagne qui ouvre publiquement certains débats, que chacun peut suivre sur la mailing list debian-vote.
Carl vient de publier, dans le dernier Linux Pratique Hors-Série sur Python, un article sur le module sqlite3, disponible dans la bibliothèque standard depuis Python 2.5, et qui permet d’utiliser facilement SQLite.
C’est un article très didactique, qui tombait à point nommé pour moi puisque j’ai récemment eu plusieurs idées d’intégration de SQLite dans txt2tags. Je suis parti totalement de zéro, puisque j’ai toujours fui aussi bien le langage SQL que la configuration des systèmes de gestion de bases de données, et j’ai quelques remarques complémentaires à faire qui pourront aider les personnes dans le même situation que moi.
Sur le shell sqlite3
Le shell sqlite3 est très pratique pour interagir avec les bases de données SQLite, et en particulier vérifier celles générées par nos programmes Python. Cependant, l’affichage standard est un peu spartiate :
sqlite> select * from tab; 1|gpl|3|premier test 2|linux|5|deuze
Pour une meilleur visualisation, on peut ajouter les noms des champs :
sqlite> .header on sqlite> select * from tab; id|title|length|comment 1|gpl|3|premier test 2|linux|5|deuze
Afficher en colonnes :
sqlite> .mode column sqlite> select * from tab; 1 gpl 3 premier test 2 linux 5 deuze
Et même les deux à la fois :
sqlite> select * from tab; id title length comment ---------- ---------- ---------- ------------ 1 gpl 3 premier test 2 linux 5 deuze
Sur la table sqlite_master
Dans l’article il est précisé comment obtenir la liste des tables d’une base de données grâce à une commande du shell sqlite3 :
sqlite> .tables tab
Mais pas comment obtenir le même résultat d’une requête SQL que vous pouvez effectuer en Python, et qui utilise la table sqlite_master automatiquement créée par SQLite :
sqlite> select name from sqlite_master; tab
Sur la méthode iterdump()
Deux remarques :
sqlite3, la seule méthode pour dupliquer une base en mémoire vers une base sur disque (oui, c’est vraiment très moche qu’il n’y ai pas de manière plus élégante de le faire, mais c’est comme ça !)Sur les ? et les chaînes de caractères
Pour construire dynamiquement le contenu des requêtes SQL, Carl utilise sans le justifier des ? et un tuple de valeurs comme second argument de la méthode execute(). Il est en fait très important de suivre cette manière de faire, car si vous utilisez les opérations classiques de concaténation des chaîne de caractères, vous vous exposez à des risques d’attaque par injection SQL !
L’autre article de Carl sur l’utilisation du module smtplib est aussi très intéressant, les autres articles du Hors-Série formant en fait un gros tutoriel d’initiation au langage Python.
