Après une première partie consacrée à la notion d’uptime, voici la seconde partie traduite de l’excellent article htop explained : Explanation of everything you can see in htop/top on Linux (1er sur Hacker News, 1er sur /r/sysadmin, 2nd sur /r/linux), traduit avec l’accord de son auteur Pēteris Ņikiforovs, article présentant la commande htop et les notions de base d’un système GNU/Linux présentées par ce programme.

Aujourd’hui : le load average (charge moyenne du système).

Une capture d’écran de htop

Load average

En plus de l’uptime, il y avait aussi 3 nombres qui représentent le load average.

$ uptime
 12:59:09 up 32 min, 1 user, load average: 0.00, 0.01, 0.03

Ils sont pris depuis le fichier /proc/loadavg. Si vous jetez un oeil à la sortie de strace, vous verrez que ce fichier est aussi ouvert.

$ cat /proc/loadavg
 0.00 0.01 0.03 1/120 1500

Les trois premières colonnes représentent la charge moyenne du système durant les 1, 5 et 15 minutes précédentes. La quatrième colonne montre le nombre de processus s’exécutant en ce moment et le nombre total de processus. La dernière colonne affiche le dernier identifiant (ID) de processus utilisé.

Commençons avec le dernier nombre.

Quand vous lancez un nouveau processus, il lui est assigné un numéro identifiant (ID). Les IDs de processus en général sont croissants, à moins qu’eils soient épuisés et sont ré-utilisés. Le processus avec l’ID 1 appartient à /sbin/init, lequel est lancé au moment du démarrage du système.

Jetons de nouveau un oeil au contenu du /proc/loadavg et exécutons ensuite la commande sleep en arrière-plan. Quand il est lancé en arrière-plan, son ID de processus sera affiché.

$ cat /proc/loadavg
 0.00 0.01 0.03 1/123 1566
 $ sleep 10 &
 [1] 1567

Donc le 1/123 signifie qu’il y a un processus s’exécutant ou prêt à être exécuté à ce moment et qu’il y a 123 processus au total.

Quand vous exécutez htop et que vous ne voyez qu’un seul processus, cela signifie qu’il s’agit du processus htop lui-même.

Si vous exécutez sleep 30 et que vous exécutez htop de nouveau, vous constaterez qu’il n’y a qu’un seul processus en cours d’exécution. C’est parce que sleep ne s’exécute pas, il dort ou tourne au ralenti (idling) ou en d’autres mots attend que quelque chose se produise. Un processus en cours d’exécution est un processus qui s’exécute en ce moment sur le CPU physique ou attend son tour pour s’exécuter sur le CPU.

Si vous exécutez cat /dev/urandom > /dev/null qui génère de façon répétée des octets aléatoires et les écrit vers un fichier spécial depuis lequel on ne peut jamais lire, vous verrez qu’il y a maintenant deux processus en cours d’exécution.

$ cat /dev/urandom > /dev/null &
 [1] 1639
 $ cat /proc/loadavg
 1.00 0.69 0.35 2/124 1679

Donc nous avons maintenant deux nous processus (la génération de nombres aléatoires et le cat qui lit le contenu de /proc/loadavg) et vous remarquerez que les load averages ont augmenté.

Le load average représente la charge du système moyenne pendant une période de temps.

Le nombre du load est calculé en comptant le nombre de processus en cours d’exécution (s’exécutant en ce moment ou en attente d’exécution) et les processus non-interruptibles (attente d’accès au disque ou activité réseau). Donc c’est simplement un nombre de processus.

Les load averages sont donc le nombre moyen de ces processus durant les 1, 5 et 15 dernières minutes, n’est-ce pas ?

En fait ça n’est pas aussi simple que ça.

Le load average est la moyenne exponentiellement amortie/pondérée en mouvement du chiffre du load. Dixit Wikipedia (en) :

Mathématiquement parlant, toutes les trois valeurs créent une moyenne de la charge système depuis le démarrage du système. Elles se désagrègent exponentiellement mais elles se désagrègent à des vitesses différentes. Donc, la charge sur une minute va ajouter 63% de charge de la dernière minute, plus 37% de la charge depuis le démarrage en excluant la dernière minute. Donc, il n’est pas techniquement juste que la charge sur une minute inclut l’activité des 60 dernières secondes (puisqu’elle inclut 37% du passé), mais qui inclut majoritairement la dernière minute.

C’est ce que vous attendiez ?

Retournons à notre génération des nombres aléatoires.

$ cat /proc/loadavg
 1.00 0.69 0.35 2/124 1679

Bien que techniquement incorrecte, c’est la façon dont je simplifie les load averages pour en parler plus facilement.

Dans ce cas, la génération de nombres aléatoires est limitée par le CPU, donc le load average de la dernière minute est 1.00 ou en moyenne un processus en cours d’exécution.

Comme il n’y a qu’un CPU sur mon système, l’utilisation CPU est de 100% puisque mon CPU ne peut exécuter qu’un processus à la fois.

Si j’avais deux coeurs, mon utilisation CPU serait de 50% puisque mon ordinateur peut exécuter deux processus en même temps. Le load average d’un ordinateur avec deux coeurs qui a 100% d’utilisation CPU serait de 2.00.

Vous pouvez voir le nombre de coeurs ou de CPUs dans le coin en haut à gauche de htop ou en exécutant nproc.

Parce que le chiffre du load inclut également les processus dans des états non-interruptibles, lesquels n’ont pas beaucoup d’effet sur l’utilisation CPU, il n’est pas tout à fait correct de déduire l’utilisation CPU depuis les load averages comme je l’ai fait. Cela explique également pourquoi vous pourriez constater un load average élevé mais peut de charge sur le CPU.

Mais il y a des outils comme mpstat qui peuvent montrer l’utilisation CPU instantanée.

$ sudo apt install sysstat -y
 $ mpstat 1
 Linux 4.4.0-47-generic (hostname) 12/03/2016 _x86_64_ (1 CPU)

10:16:20 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
 10:16:21 PM all 0.00 0.00 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
 10:16:22 PM all 0.00 0.00 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
 10:16:23 PM all 0.00 0.00 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
 # ...
 # kill cat /dev/urandom
 # ...
 10:17:00 PM all 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
 10:17:01 PM all 1.00 0.00 0.00 2.00 0.00 0.00 0.00 0.00 0.00 97.00
 10:17:02 PM all 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00

Pourquoi utilisons-nous les load averages alors ?

$ curl -s https://raw.githubusercontent.com/torvalds/linux/v4.8/kernel/sched/loadavg.c | head -n 7
 /*
 * kernel/sched/loadavg.c
 *
 * This file contains the magic bits required to compute the global loadavg
 * figure. Its a silly number but people think its important. We go through
 * great pains to make it work on big machines and tickless kernels.
 */

Traduction du commentaire dans le fichier source : Ce fichier contient des bits magiques requis pour calculer le chiffre du loadavg global. C’est un idiot mais les gens pensent que c’est important. We éprouvons de grandes douleurs pour le faire marcher sur les grosses machines et les noyaux tickless.

Ce sera tout pour aujourd’hui J’espère que comme moi vous aurez appris des éléments sur le load average de votre système. Nous continuerons cette série dès lundi avec les processus dans htop.

Original post of Carl Chenet.Votez pour ce billet sur Planet Libre.

Bon, on peut souffler un peu. La mise en ligne de wallabag.it s'est plutôt bien passé : beaucoup de retours, quasiment que des retours positifs. Un article sur NextInpact (un peu critique, mais ces critiques sont justifiées donc bon).

Il a fallu surtout supporter l'effet Capital (à une moindre échelle, je le reconnais).

Rapidement, des utilisateurs sont arrivés, se sont créés un compte et ont décidé de récupérer leurs milliers d'articles de Pocket ou Instapaper : des gens ont plus de 15.000 articles chez Pocket. Mais vous êtes fous ? Passons.

Ça a surtout permis de tester à grande échelle l'import asynchrone de wallabag. Pour tester, on a testé.

Dans un premier temps, j'avais mis en place Redis pour stocker les articles et les traiter de manière asynchrone. wallabag supporte aussi RabbitMQ, mais Redis étant plus léger, plus simple à installer, ça me paraissait un bon compromis.

J'avais lancé les workers (script qui consomme les articles stockés dans Redis pour les récupérer en ligne et les stocker dans la base de wallabag) en ligne de commande, classiquement. Quasiment une dizaine de workers pour Pocket, pareil pour Instapaper et tous les autres (environ 70 workers).

Ça marchait. Presque.

Il ne fallait pas trop charger la mule, sinon le CPU était vite sous l'eau. Problème constaté : certains workers mourraient, il fallait donc les relancer. Hop, un cron qui vérifie régulièrement le nombre de workers qui tournent et relance ce qu'il faut pour qu'on ait toujours nos 70 workers. Une ébauche de ce cron se trouve ici.

Pendant que les workers tentaient despérément de consommer les articles, les utilisateurs, eux, continuaient d'envoyer des articles. On est très rapidement arrivé à 100.000 articles à importer. CENT. MILLE. En moins de 24h.

@bourvill, qui développe l'appli wallabag pour iOS, me conseille de ne pas laisser tourner mes worker indéfininement, mais de les faire consommer quelques messages, puis de les tuer pour les relancer. Y'a eu un peu de mieux. Mais c'était pas la forme non plus.

Il me parle ensuite de supervisor. Hop, à la poubelle mon cron, supervisor c'est génial. On lui dit : "voici une commande à surveille : si elle meurt, tu la relances."

Extrait de configuration pour mes workers Pocket par exemple :

[group:pocket-workers]

[program:pocket-01]
command=php bin/console rabbitmq:consumer -e=prod import_pocket -w -vvv
directory=/var/www/app.wallabag.it/current/
autostart=true
autorestart=true
startretries=3
stderr_logfile=/var/log/import-workers/pocket.err.log
stdout_logfile=/var/log/import-workers/pocket.out.log
user=www-data

[program:pocket-02]
command=php bin/console rabbitmq:consumer -e=prod import_pocket -w -vvv
directory=/var/www/app.wallabag.it/current/
autostart=true
autorestart=true
startretries=3
stderr_logfile=/var/log/import-workers/pocket.err.log
stdout_logfile=/var/log/import-workers/pocket.out.log
user=www-data

supervisor est aussi plus pratique pour arrêter / démarrer / ajouter de nouveaux workers.

Bon, c'était mieux pour gérer les workers, mais les problèmes de performance étaient toujours là.

Au bout de 48h, je décide de couper les imports. Le temps de laisser Redis digérer les 50.000 articles avec seulement quelques workers : le fait d'en faire tourner trop faisait ramer l'appli en elle-même, certains utilisateurs avaient des timeout.

Après avoir discuté avec @j0k3r et @bourvill des optimisations possibles, je décide d'abandonner Redis pour installer RabbitMQ.

Et là, surprise : ça trace. Alors que RabbitMQ est plus lourd, il s'en sort mieux. Logique, il est fait pour ça (Redis n'étant à la base pas fait pour ça), si jamais un worker plante, on ne risque pas de perdre de messages. Et le bundle utilisé pour communiquer avec RabbitMQ est surement plus performant que la librairie PHP utilisée pour Redis.

Joie donc. Je décide de faire un test grandeur nature : import de 8.000 articles depuis Pocket avec 15 workers. Pour les 4.000 premiers articles, ça a plutôt bien tourné. Et puis après, c'est devenu plus compliqué, les CPU ont commencé à chauffer.

Grrr.

De la RAM ajoutée et c'était mieux : je décide donc de réouvrir les imports à tout le monde après des tests de plusieurs milliers d'articles (Merci elpep, gnppn et lpenou).

@bourvill, toujours lui, me dit d'activer aussi la quality of service dans RabbitMQ : en gros ça permet de n'affecter que quelques messages à un worker, pour éviter qu'il les prenne tous (le gourmand) et il en laisse ainsi aux autres et le parallélisme peut ainsi fonctionner. J'ai donc appris que sans ça, j'avais beau lancer 42 workers pour une même queue, ça n'aurait rien changé.

Pendant ce temps, et comme depuis le début de l'aventure de toute façon, Benoit, de web4all (mon hébergeur), a toujours été là pour me soutenir, pour changer les perfs des serveurs (ajouter de la RAM, ajouter des CPU, surveiller les serveurs), tester plein de trucs. Un grand merci à lui !

Résultat : ce soir, ça semble se stabiliser, y'a des moments où les CPU chauffent encore, je tue les workers si vraiment les 4 CPU sont à plus de 80% chacun et ça repart. Donc encore un peu de boulot à faire niveau performance, mais c'est beaucoup plus supportable : ça importe et le site est utilisable.

Depuis 3 jours, mon ordi, c'est ça quasi en permanence : surveiller les CPU, voir le nombre d'articles en base, regarder ce qu'il reste à importer.

Aujourd'hui, tout s'est un peu calmé (et c'est pas plus mal), mais ça m'a permis de corriger des bugs dans wallabag (découverts via les imports), d'apprendre plein de choses et de voir que finalement, le service tournait pas trop mal :)

Quelques chiffres :

• 2500 visiteurs uniques en moins de 48h
• 160.000 articles importés en moins de 72h
• une base de données de 2,5 Go
• beaucoup de retours extrêmement positifs : merci !

C'était éprouvant, mais intéressant ! On continue !

Original post of Nicolas Lœuillet.Votez pour ce billet sur Planet Libre.

La bidouille ça ne s’arrête jamais, et c’est parfois un exutoire, un moyen de pouvoir décompresser après une journée chargée. Mais c’est avant tout la possibilité de se construire un OS taillé sur mesure, où du moins un OS adapté pour l’usage qu’on souhaite en faire.

Notons également que la bidouille c’est bien mais qu’il fut un temps linuxien fort lointains où la bidouille faisait fréquemment tout planter bien comme il faut, sans moyen de récupérer ses données. Au hasard : une rapide installation d’une Lubuntu en 2006 faisait, si bien naturellement on était un jeune homme pressé, un formatage complet de votre disque dur, y compris les partitions non-vides…

Ce qui m’intéresse aujourd’hui c’est de parler ligne de commande, de parler interprétateur et d’éditeur de texte. De parler barbe quoi, enfin barbe naissante vu mon piètre niveau.

Depuis que j’utilise Linux, j’ai à ma disposition un invité de commande BASH, on retrouve cet interprétateur sur la plupart des distributions actuelles et je ne m’étais jamais posé la question des alternatives. Alors j’ai ouvert le grand livre Internet et m’en suis allé découvrir les possibilités existantes et, finalement, je me suis arrêté sur Zsh.

Kesako

Bash est interprétateur le plus connu et installé d’office sur la plupart des distributions linux actuelles. Là où zsh se démarque c’est qu’il propose des fonctionnalités que bash n’apporte pas comme un système d’auto-complétion assez poussé qui fonctionne même avec les différents logiciels utilisables en ligne de commandes. Bash le fait également mais en plus sommaire, il ne propose pas par exemple une description des commandes disponibles, des arguments possibles pour la commande.

Slimzsh

Oh My Zsh est une communauté d’utilisateurs proposant thèmes, plugins en un outil global pour simplifier la personnalisation et l’utilisation de zsh. Et pourtant il me paraît bien trop complet, je souhaite quelque-chose de simple pour l’utilisation basique que je fais du terminal alors j’ai regardé les autres frameworks zsh et mon dévolu s’est arrêté sur slimzsh.

Slimzsh est un framework minimaliste pour Zsh, il n’apporte pas une myriade de plugins mais juste ce qu’il faut pour mon utilisation :

• Un thème minimaliste nommé Pure
• L’auto-complétion activée pour les commandes et les arguments
• La coloration syntaxique quand une commande est erronée ou correct
• Indication en fonction du statut du dépot git

Pour moi c’est amplement suffisant.

Complétion, git et features

Zsh regorge de petits utilitaires qui facilite grandement la fluidité dans l’usage de la ligne de commande, l’auto-complétion en fait partie et c’est vraiment agréable de pouvoir l’utiliser. Un vrai gain de temps.
La colorisation syntaxique peut paraître peu intéressante mais au contraire j’y trouve une forme d’apport pédagogique. Cela m’incite à utiliser la ligne de commande et lorsque je me plante je prends le temps d’aller regarder mon erreur et ainsi en apprendre toujours un peu plus sur les commandes disponibles ainsi que leurs arguments respectifs.

micro

Niveau éditeur de texte en ligne de commande j’ai toujours utilisé nano. Il est simple et fait le maigre job que je lui demande. Et puis je suis tombé sur micro, un nano enrichi en quelque sorte. Snippets, colorisation syntaxique dans un terminal c’est top. Et puis c’est construit avec du langage Go, je n’y connais pas grand-chose mais j’aime le fait que tout soit contenu dans un seul binaire, pas de dépendance et ça tourne nickel.
Attention tout n’est pas parfait et pour l’écriture d’un billet par exemple je trouve cela un poil restrictif, car je n’arrive pas, pour le moment, à obtenir un retour à la ligne propre et fonctionnel, le logiciel est encore jeune et est en cours de polissage.

Voilà pour le moment, je découvre et j’apprends, mais je commence à être de plus en plus utilisateur de la ligne de commande pour les petites opérations et c’est un réel plaisir dans apprendre encore un peu plus sur l’utilisation possible de Linux.

Original post of Bridouz.Votez pour ce billet sur Planet Libre.

La bidouille ça ne s’arrête jamais, et c’est parfois un exutoire, un moyen de pouvoir décompresser après une journée chargée. Mais c’est avant tout la possibilité de se construire un OS taillé sur mesure, où du moins un OS adapté pour l’usage qu’on souhaite en faire.

Notons également que la bidouille c’est bien mais qu’il fut un temps linuxien fort lointains où la bidouille faisait fréquemment tout planter bien comme il faut, sans moyen de récupérer ses données. Au hasard : une rapide installation d’une Lubuntu en 2006 faisait, si bien naturellement on était un jeune homme pressé, un formatage complet de votre disque dur, y compris les partitions non-vides…

Ce qui m’intéresse aujourd’hui c’est de parler ligne de commande, de parler interprétateur et d’éditeur de texte. De parler barbe quoi, enfin barbe naissante vu mon piètre niveau.

Depuis que j’utilise Linux, j’ai à ma disposition un invité de commande BASH, on retrouve cet interprétateur sur la plupart des distributions actuelles et je ne m’étais jamais posé la question des alternatives. Alors j’ai ouvert le grand livre Internet et m’en suis allé découvrir les possibilités existantes et, finalement, je me suis arrêté sur Zsh.

Kesako

Bash est interprétateur le plus connu et installé d’office sur la plupart des distributions linux actuelles. Là où zsh se démarque c’est qu’il propose des fonctionnalités que bash n’apporte pas comme un système d’auto-complétion assez poussé qui fonctionne même avec les différents logiciels utilisables en ligne de commandes. Bash le fait également mais en plus sommaire, il ne propose pas par exemple une description des commandes disponibles, des arguments possibles pour la commande.

Slimzsh

Oh My Zsh est une communauté d’utilisateurs proposant thèmes, plugins en un outil global pour simplifier la personnalisation et l’utilisation de zsh. Et pourtant il me paraît bien trop complet, je souhaite quelque-chose de simple pour l’utilisation basique que je fais du terminal alors j’ai regardé les autres frameworks zsh et mon dévolu s’est arrêté sur slimzsh.

Slimzsh est un framework minimaliste pour Zsh, il n’apporte pas une myriade de plugins mais juste ce qu’il faut pour mon utilisation :

• Un thème minimaliste nommé Pure
• L’auto-complétion activée pour les commandes et les arguments
• La coloration syntaxique quand une commande est erronée ou correct
• Indication en fonction du statut du dépot git

Pour moi c’est amplement suffisant.

Complétion, git et features

Zsh regorge de petits utilitaires qui facilite grandement la fluidité dans l’usage de la ligne de commande, l’auto-complétion en fait partie et c’est vraiment agréable de pouvoir l’utiliser. Un vrai gain de temps.
La colorisation syntaxique peut paraître peu intéressante mais au contraire j’y trouve une forme d’apport pédagogique. Cela m’incite à utiliser la ligne de commande et lorsque je me plante je prends le temps d’aller regarder mon erreur et ainsi en apprendre toujours un peu plus sur les commandes disponibles ainsi que leurs arguments respectifs.

micro

Niveau éditeur de texte en ligne de commande j’ai toujours utilisé nano. Il est simple et fait le maigre job que je lui demande. Et puis je suis tombé sur micro, un nano enrichi en quelque sorte. Snippets, colorisation syntaxique dans un terminal c’est top. Et puis c’est construit avec du langage Go, je n’y connais pas grand-chose mais j’aime le fait que tout soit contenu dans un seul binaire, pas de dépendance et ça tourne nickel.
Attention tout n’est pas parfait et pour l’écriture d’un billet par exemple je trouve cela un poil restrictif, car je n’arrive pas, pour le moment, à obtenir un retour à la ligne propre et fonctionnel, le logiciel est encore jeune et est en cours de polissage.

Voilà pour le moment, je découvre et j’apprends, mais je commence à être de plus en plus utilisateur de la ligne de commande pour les petites opérations et c’est un réel plaisir dans apprendre encore un peu plus sur l’utilisation possible de Linux.

Original post of Bridouz.Votez pour ce billet sur Planet Libre.

Avec l’accord de Pēteris Ņikiforovs, auteur original de l’excellent article htop explained : Explanation of everything you can see in htop/top on Linux (1er sur Hacker News, 1er sur /r/sysadmin, 2nd sur /r/linux), j’entreprends une série d’articles visant à traduire en français son excellente explication de htop et des notions de base d’un système GNU/Linux présentées par ce programme.

L’approche didactique m’est apparue excellente et me semble pouvoir être d’une grande aide à toutes les personnes intéressées par ce qui se passe sur leur système GNU/Linux. Une traduction en français s’imposait donc

Aujourd’hui : l’uptime.

htop expliqué

Explication de tout ce que vous pouvez voir dans htop/top sur Linux

Bien longtemps je n’ai pas su ce que toutes les valeurs dans htop signifiaient.

Je pensais qu’un load average de 1.0 sur ma machine à deux coeurs signifiait que l’utilisation CPU était de 50%. Ce n’est pas tout à fait vrai. Et entre autre, pourquoi 1.0 ?

J’ai alors décidé de tout chercher et de le documenter ici.

Il est aussi dit que le meilleur moyen d’apprendre quelque chose est de tenter de l’enseigner.

htop sur Ubuntu Server 16.04 x64

Voici une copie d’écran de htop que je vais décrire.

Uptime

L’uptime montre depuis combien de temps un système s’exécute.

Vous pouvez voir les mêmes informations en exécutant la commande uptime :

$ uptime 12:17:58 up 111 days, 31 min, 1 user, load average: 0.00, 0.01, 0.05

Comment le programme uptime sait-il cela ?

Il lit ces informations depuis le fichier /proc/uptime.

9592411.58 9566042.33

Le premier nombre est le nombre total de secondes pendant lequel le système s’exécute. Le second nombre est combien de secondes la machine a tourné au ralenti (idle). La seconde valeur peut être plus grande que l’uptime du système sur les systèmes avec de multiples coeurs puisqu’il s’agit d’une somme.

Comment l’ai-je su ? j’ai observé quels fichiers le programme uptime ouvrait lorsqu’on l’exécute. Nous pouvons utiliser l’outil strace pour cela.

$ strace uptime

Il va s’afficher beaucoup de choses. Nous pouvons utiliser grep pour l’appel système open. Mais cela ne marchera pas vraiment puisque strace redirige tout sur le flux de l’erreur standard (stderr). Nous pouvons rediriger stderr vers le flux de la sortie standard (stdout) avec 2<&1.

$ strace uptime 2>&1 | grep open
...
open("/proc/uptime", O_RDONLY) = 3
open("/var/run/utmp", O_RDONLY|O_CLOEXEC) = 4
open("/proc/loadavg", O_RDONLY) = 4

qui contient le fichier /proc/uptime que j’ai déjà mentionné.

Il se trouve que vous pouvez aussi utiliser strace -e open uptime et ne pas vous embêter avec grep.

Mais pourquoi avons-nous besoin du programme uptime si nous pouvons juste lire le contenu du fichier ? La sortie de la commande uptime est joliment formatée pour les humains tandis que le nombre de secondes est plus utile à réutiliser dans nos programmes ou scripts.

Premier partie en forme de mise en bouche, nous continuerons dans le second article de cette série par la notion de load average.

Original post of Carl Chenet.Votez pour ce billet sur Planet Libre.