p. 06 CTE et Window Functions avec MariaDB
p. 16 La configuration ssh d’un « DevOps »
p. 20 Vision 3D à partir d’une caméra sur Raspberry Pi
p. 32 Base 16,32,36,56,58,64,85,...
p. 36 Introduction : Serverless et Function as a Service (FaaS)
p. 40 Mais quelle est la meilleure méthode pour transférer un grand nombre de petits fichiers ?
p. 46 Isolez vos constructions logicielles à l’aide de Docker
p. 54 i.MX7 : « Communication interprocesseur, donnons vie au Cortex M4 »
p. 72 Appels systèmes sous Linux
p. 76 Développement applicatif avec GStreamer 1.0
p. 84 Dopez vos commandes shell
p. 92 Écrivez du code JavaScript robuste
Nous vivons dans un monde où nous sommes submergés de données qui nous parviennent de toutes parts. Un traitement manuel n'est plus envisageable et il faut donc analyser ces données de manière automatique en utilisant des techniques de plus en plus pointues (machine learning, deep learning, etc.). Néanmoins, la technologie ne peut nous mettre à l'abri de l'effet « Hans le malin » (https://fr.wikipedia.org/wiki/Hans_le_Malin). En effet, il est très facile de tirer de données de qualité (recueillies correctement, propres, etc.) absolument n'importe quelle conclusion qui, en général, ira dans la direction souhaitée. Pour mettre en garde contre ce phénomène, deux enseignants de l'University of Washington, Carl Bergstrom, professeur du département de Biologie et Jevin West, professeur assistant de l'Information School (https://ischool.uw.edu/), ont eu l'idée de lancer une initiative nommée « Calling Bullshit » (expression anglaise que je me garderai de traduire et qui permet de signifier son désaccord à une autre personne). Cette initiative prend la forme d'un site internet (http://callingbullshit.org) sur lequel on peut trouver :
J'ai récemment reçu un communiqué de presse. L'information était la suivante : une ville française (assez importante) a signé un contrat (assez conséquent) avec une société pour développer un outil permettant aux acteurs de la sécurité d'anticiper les risques et de préparer leur intervention via l'analyse de données massives (il faut dire Big Data si on veut faire plus vendeur). Cette information a raisonné en moi et je me suis souvenu de l'un des cas présentés sur le site qui fait allusion à la notion de pré-crime de Philip K. Dick (adapté au cinéma dans Minority Report par Steven Spielberg). On nous présente l'article de deux auteurs chinois qui indiquent pouvoir détecter des personnes criminelles en analysant des photos de leur visage sur la base de photographies de personnes reconnues coupables de crimes (et donc prises en photo lors de leur incarcération) et de personnes tout venant. L'hypothèse de départ de ce travail nous ramène à des heures assez sombres de notre Histoire. Toujours est-il que, tout naturellement, les criminels étaient ceux qui ne souriaient pas et donc la ligne prédictrice du crime était à lier en fonction du sourire des passants...
Ainsi, si l'on imagine que les auteurs de délits dissimulent leurs traits sous des bonnets ou cagoules pour ne pas être reconnus sur les vidéos, le futur fantastique logiciel dont je parlais précédemment pourra indiquer aux forces de l'ordre… la météo et plus précisément quand il fera froid. Comme vous le comprenez, je reste donc très sceptique sur les capacités d'anticipation d'un tel système, sans même un seul précog et me questionne fortement sur l'usage de l'argent public avec de tels objectifs.
Je profite d'ailleurs de ces lignes pour vous annoncer la sortie prochaine de notre Hors-Série sur le Machine Learning, pour que chacun puisse garder un œil critique sur ce qui est fait ou annoncé en grande pompe.
La technologie permet des avancées scientifiques précieuses... mais tout dépend entre les mains de qui. En attendant, n'oubliez pas de sourire en lisant votre magazine, on ne sait jamais… ;-)
Tristan Colombo
p. 06 La RAM non volatile
p. 18 Programmation dynamique et alignement de séquences
p. 28 Effectuez vos sauvegardes avec Bareos
p. 36 RADAR passif par intercorrélation de signaux acquis par deux récepteurs de télévision numérique terrestre
p. 56 Personnalisez et distribuez vos images Raspbian
p. 72 Ne cherchez plus sur le Web, laissez vos agents le faire à votre place !
p. 82 Développer une extension compatible Firefox, Chromium et autres navigateurs
p. 94 Durcissement Linux via Systemd
Aujourd'hui nous n'avons plus à défendre le logiciel libre avec autant d'ardeur qu'il y a quelques années. Le logiciel libre est rentré dans les mœurs (même Microsoft propose des produits open source). On pourrait donc se dire que la « guerre » est gagnée et que nous pouvons désormais nous reposer sur ces batailles durement gagnées. Mais ne serait-ce point une erreur ?
La vente liée d'ordinateurs et de systèmes d'exploitation n'est toujours pas interdite en France, car elle n'est pas assimilable à de la vente liée. En effet, suivant les constructeurs, il est légalement possible de se faire rembourser le système d'exploitation que l'on n'utilise pas (il est toujours dommage de payer un Windows pour tester une fois pendant dix secondes le démarrage d'une machine). Pourtant combien de demandes de remboursement sont menées à terme ? A-t-on du temps à dépenser en démarches administratives pour se faire rembourser un système que nous n'aurions pas acheté si nous avions eu le choix ? Donc la plupart du temps nous faisons une croix sur cet argent dépensé inutilement et venant grossir artificiellement les statistiques des utilisateurs de Windows.
Une solution alternative consiste à restreindre drastiquement son choix pour acheter l'un des trop rares ordinateurs proposés sans OS. Et là, on découvre qu'alors que Windows est vendu pour environ 150€, l'ordinateur sans système d'exploitation sera vendu 150€ de moins (jusque là tout est normal), mais qu'en plus vous aurez droit à un disque dur SSD, ou quelques Gio de RAM en plus, ou à une carte vidéo plus performante, etc. (ou à une combinaison de tout cela). Quelle est la raison de cet état de fait ? Je ne sais pas, mais cela est plutôt avantageux pour nous, linuxiens.
Nous avons pu voir qu'il y avait encore des problèmes de liberté vis-à-vis du système d'exploitation, mais que se passe-t-il lorsque votre ordinateur se met à dysfonctionner physiquement et qu'il faut le réparer ? Est-on libre de mener à bien une réparation. Oui, bien sûr… mais les fabricants chercheront à vous mettre des bâtons dans les roues : ils vont préférer vous vendre neuf plutôt que de réparer. En effet, les informations techniques (diagrammes d'implantation des composants, etc.) ne sont plus fournies et les pièces de rechange ne sont rapidement plus disponibles (il reste alors à partir en quête d'un appareil identique jeté pour pouvoir récupérer des composants). Je ne vais pas jusqu'à espérer que tout appareil électronique soit en hardware open source, mais qu'il soit seulement réparable paraîtrait logique ! En ce sens, le site ifixit.org propose de nombreux tutoriels expliquant comment réparer des smartphones, tablettes, etc. Ce qui ne vous mettra pas forcément à l'abri du comportement inadmissible de certains constructeurs comme Apple qui en 2015 a désactivé des iPhones dont les écrans n'avaient pas été changés dans des magasins affiliés à la marque mère (lire l'exemple du journaliste Antonio Olmos dans The Guardian : http://bit.ly/2CuL1pJ). Exemple accablant de logiciel propriétaire désactivant un périphérique pour changement de matériel propriétaire.
Il y a quelques semaines, bis repetita, Apple a fourni une mise à jour de son système iOS permettant d'économiser de la batterie… mais qui, étrangement, dégrade les performances des anciens iPhones (aux batteries forcément usées). Une aussi petite entreprise n'avait bien sûr réalisé aucun test avant de déployer la mise à jour… (voir https://www.apple.com/iphone-battery-and-performance/).
Vous voyez donc que malgré l'acceptation du logiciel libre / open source en tant qu'alternative crédible au logiciel propriétaire, nous ne devons pas nous endormir sur nos lauriers. Il y a encore des combats à mener et, en attendant, comme chaque mois, vous pourrez retrouver dans nos pages toute la richesse du monde open source.
Tristan Colombo
p. 06 Faut s’démener au FOSDEM !
p. 14 La logique du Jeu de la Vie : exercices amusants de pensée latérale
p. 28 Les subtilités de l’équilibrage de charge avec le DNS
p. 36 Gérez vos tickets GitHub en ligne de commandes
p. 40 Solutions temps réel avec Yocto et Buildroot
p. 50 Détectez les fuites mémoire dans vos programmes
p. 60 Réagir à un kernel panic quand on est développeur
p. 70 Effectuez automatiquement des captures d’un PDF
p. 76 Gérez les dates comme un pro avec SQL
p. 82 Modifiez l’ergonomie d’une page web avec Tampermonkey
p. 94 Sécurisez vos applications PHP avec Snuffleupagus
Nous sommes nombreux à développer différents outils dans notre coin. Ces outils pourraient intéresser la communauté et pourtant, bien que convaincus de leur utilité et de la philosophie du logiciel libre, nous ne le faisons pas… Pourquoi ?
Nous voulons tous que notre programme soit le plus abouti possible en termes de fonctionnalités, mais pas toujours nécessairement en termes de qualité et de couverture de la documentation ou des tests. Écrire rapidement une preuve de concept et la documenter c’est une chose, distribuer un outil finalisé dont le code aura été nettoyé, qui sera correctement commenté, qui aura une couverture de tests minimale et une documentation fournie, agrémentée de tutoriels est une tout autre chose. Je suis bien placé pour en parler : de nombreux articles pourraient aboutir à des outils concrets, mais le manque de temps et les articles qui suivent m’empêchent d’aller au-delà. Bien entendu mon code est disponible sur le GitHub du magazine, mais il ne « vit » plus et n’est utile qu’en lien avec l’article auquel il est rattaché.
Nous sommes donc face à trois cas possibles :
Dans le troisième cas, il sera possible d' « essaimer » de nombreux projets qui seront sans doute des projets « mort-nés » à vos yeux, mais n'en seront pas pour autant inutiles : vous aurez eu le mérite de partager votre méthode pour répondre à un problème. D'autres développeurs pourront s'en inspirer, voire les forker et ils pourront vous soumettre des remarques, soulever des problèmes ou proposer des corrections. Bien entendu, certains ne manqueront pas de critiquer sans aucune justification qu'une guerre d'église tel ou tel choix, de pointer l'absence de tests unitaires ou autre. Ces personnes-là sont généralement celles qui gardent leur code et ne font rien. Proposez-leur de soumettre un patch et vous n'en entendrez plus jamais parler...
Si l'un de vos projets prend le dessus sur les autres, car il suscite l'engouement de la communauté ou qu'il apparaît comme fondamental dans l'exercice de votre profession, vous pourrez alors lui consacrer le temps nécessaire pour le documenter de manière plus précise et améliorer la qualité du code.
Partagez donc votre code et votre expérience ! Si vous le souhaitez, vous pouvez même le faire au sein de votre magazine préféré : envoyez-moi vos idées ! En attendant, je vous souhaite une bonne lecture et je vous retrouverai le mois prochain...
Tristan Colombo
p. 06 Quand NE PAS automatiser les tests logiciels ?
p. 10 Stockage persistant dans Kubernetes avec Rook
p. 18 Primalité et cryptographie
p. 26 L’algèbre de Boole
p. 36 L’auto-hébergement léger de dépôts git avec Gitolite
p. 44 Répliquer sa base de données MariaDB en temps réel
p. 52 Créez et pilotez votre périphérique matériel sous Linux embarqué
p. 68 Correction d’erreurs par piégeage dans le système RDS
p. 74 Les dépendances entre paquets sous Slackware
p. 80 Un Python toujours à jour
p. 86 Faites vos jeux avec Pharo
p. 92 Utilisation de GStreamer 1.0 dans une application Android
Les services administratifs en ligne représentent une avancée majeure pour le citoyen qui n’a plus à se déplacer, à attendre pendant des heures à un guichet pour obtenir une carte d’identité (CNI), une carte grise, etc. De plus, la dématérialisation nous fait économiser les précieuses ressources de la planète : plus besoin de remplir une déclaration papier sur un formulaire Cerfa n°xxxx*xx, tout se fait en ligne !
Fort de toutes ces considérations et devant faire réaliser une carte d’identité pour mon fils, je me lance donc sur service-public.fr qui me renvoie sur le site de l’ANTS (Agence Nationale des Titres Sécurisés). On me demande de compléter un formulaire contenant les informations nécessaires à l’ouverture du dossier. Normal. Je valide le dossier et là, quelque chose d’étrange se produit : je reçois un mail contenant un QR-Code et m’indiquant que je peux enregistrer (ou si je le désire imprimer) la prédemande, et que je dois me rendre à la mairie en accompagnant mon dossier des pièces justificatives nécessaires. Décodons : je viens de remplir un dossier qui permettra à la personne chargée de réceptionner le dossier de ne pas faire de faute(s) lors de la saisie (c’est du vécu) et qui lui fera économiser du temps. En attendant, moi, du temps, je n’en ai pas économisé puisque je dois déposer le dossier à la mairie. Et puis pour l’économie de papier, effectivement l’État n’aura pas à assumer le coût d’impression du Cerfa puisque c’est moi qui l’ai imprimé, bien conscient que lors du dépôt il y aura 9 chances sur 10 pour que le scanner de QR-Code ne fonctionne pas. De toute façon, pour la planète le bilan sera le même, vu qu’il faut coller la photo d’identité et signer sur la feuille… donc il faut nécessairement du papier… Bref, ne râlons pas trop, la procédure est semi-automatisée, le véritable gain de temps apparaîtra sans doute avec les pièces justificatives dont la liste m'est communiquée via un lien dans le mail d'accusé de réception.
J’ouvre donc le lien m’indiquant quelles sont les pièces à fournir… mais bien sûr c’est un lien générique. Je viens de faire ma demande, le système sait que c’est un dossier pour une carte d’identité ! Mais non, il faut répondre à un formulaire pour avoir accès à l’information ! Je réponds donc et on m’indique qu’il va me falloir notamment :
La migration du papier au numérique a été visiblement pensée petit morceau par petit morceau, sans vision globale du service à fournir et il en résulte un « machin », un patchwork composé de plusieurs briques logicielles sans lien les unes avec les autres, mais formant extérieurement un tout. Lorsqu’un système est lourd et qu’on le retranscrit tel quel en système informatique, sans concertation, sans planification, il est bancal. Au lieu de profiter du passage au numérique pour dépoussiérer un système complexe, on propose un service inachevé qui, dans l'opinion publique, renverra encore la faute sur « l'informatique » et « les informaticiens » en oubliant que le code n'est pas tout, qu'avant lui il y a de la pensée, de la réflexion et que c'est souvent là que le bât blesse.
Allez, reprenons un peu espoir ! Respirez un bon coup et lisez votre GNU/Linux Magazine tout neuf !
Tristan Colombo
p. 06 Vers l'ARM et au-delà !
p. 10 À la découverte des arbres binaires à commande équilibrée
p. 22 L’auto-hébergement léger de dépôts git avec Gitolite
p. 44 Répliquer sa base de données MariaDB en temps réel
p. 34 À l'assaut du sous-système noyau « Industrial I/O » ! (et du QML …!)
p. 54 Créez votre animal de compagnie virtuel
p. 92 Stimulus, un framework JS léger, puissant et cool
p. 82 Construire son serveur d'audit de hash
Deux jours !
Deux jours, c’est le temps qu’il m’a fallu pour récupérer un smartphone opérationnel ! Pourquoi mon smartphone ne fonctionnait-il plus ? C'est toute une histoire qui se déroule donc sur deux jours...
Jour 1
Disposant d’un smartphone pouvant être qualifié par certains d'« assez ancien », en l’occurrence un Galaxy Note 3 de 4 ans, et désirant installer une application récente, je décidai de changer de système. En effet, le Galaxy Note 3 était sous Android 4.4.2, ayant déjà un effectué un changement de version il y a quelque temps, car Samsung n’assure plus la maintenance des Galaxy Note 3 depuis quelques années. L’application que je souhaitais installer nécessitait au minimum Android 5.0 et je décidai donc de passer sous Lineage OS et d’en profiter pour écrire un article pour Linux Pratique. L’intérêt était de montrer que l’on pouvait redonner une seconde jeunesse à son smartphone tout en restant sous Linux pour l’installation d’une ROM. Les smartphones Samsung nécessitent l’utilisation d’Odin sous Windows, mais sous Linux nous avons un équivalent open source : Heimdall. Ce dernier est présent dans les dépôts des grandes distributions et c’est seulement au bout d’une demi-journée que l’on se rend compte qu’il s’agit de la version 1.4.1, que celle-ci est boguée et qu’il faut la 1.4.2… qui doit être compilée manuellement. Bien entendu, la compilation ne fonctionne pas du premier coup et il faut compiler deux bibliothèques pour disposer des dernières versions et parvenir, enfin, à compiler Heimdall. Après avoir effectué toutes les sauvegardes d’usage, on peut donc installer le Custom Recovery open source TWRP pour Team Win Recovery Project (ajout d’une interface graphique au programme natif d'Android de récupération - recovery - le rendant plus simple à utiliser). Voilà qui s’annonce plutôt bien. Toutes ces opérations ayant pris une bonne journée, nous pouvons aller nous coucher sereinement.
Jour 2
Après avoir téléchargé la dernière version de Lineage OS adaptée à mon smartphone ainsi que les applications Google sur opengapps.org, je me lance : transfert via adb, installation puis reboot. Et là, ça marche ! Je commence donc la configuration jusqu’à ce que le système m’annonce que la carte SIM n’est pas détectée ?!?! J’ai donc au final un smartphone parfaitement fonctionnel : les mails, Internet, les applications, le GPS fonctionnent… par contre, je ne peux ni téléphoner ni envoyer de SMS. Plutôt gênant pour un téléphone ! Après diverses recherches et tests, ce qui devait arriver arriva : smartphone bloqué. Ne parvenant à rien avec Heimdall, la mort dans l’âme je passe sur Odin (oui, sous Windows) et j’arrive à débloquer le téléphone. Des heures de recherche et de tests de différentes ROM après, je récupère enfin mon smartphone sous Android 7.1 grâce à Resurrection Remix.
Bilan
Il est possible de prolonger la vie de son smartphone, mais le coût en temps est assez élevé et, en tout cas pour Samsung, les outils disponibles sous Linux ne sont malheureusement pas assez développés. Il est également dommage que les constructeurs ne suivent pas plus longtemps leurs smartphones, mais c’est peut-être à nous, clients, d’arrêter de changer de téléphone tous les ans pour qu’ils comprennent ce que nous attendons. Enfin, peut-être que le Project Treble de Google visant à séparer le système Android des couches bas niveau spécifiques à chaque modèle de smartphone permettra des mises à jour plus aisées…
En attendant de voir si ce petit miracle devient réalité, vous pouvez profiter de votre magazine qui, lui, n'a pas besoin de mise à jour (pour le moment…:-)).
Tristan Colombo
p. 06 Installez simplement la dernière version de Python avec Pyenv
p. 10 Enquête dans les méandres du système... ou l’aventure humaine de la chasse aux bugs
p. 14 L’apprentissage par renforcement pour créer des bots autonomes
p. 30 La peinture sur spectre radiofréquence, et l’effet capture de la modulation en fréquence
p. 44 Infrastructure As Code sous AWS avec Terraform
p. 56 KF5 en embarqué, couple improbable...
p. 64 Les mystères de l’ioctl()
p. 72 Les tribulations d’un programmeur Linux dans la Sierra Apple
p. 78 Une clé USB de secours toujours à portée de main
p. 82 Créer son propre ORM pour Node.js
p. 94 Cloisonner une application simplement avec NsJail
Voici de retour la controverse sur la révision du droit d’auteur dans l’Union Européenne. Il y a quelques jours, 147 associations européennes ont publié une lettre ouverte (https://savecodeshare.eu/) demandant la suppression ou la réécriture de l’article 13 de la proposition de réforme devant être votée à la fin du mois de juin. Actuellement voilà la teneur de l'article (le texte de la Proposition sur le droit d’auteur dans le marché numérique peut être consulté dans son intégralité en [1]) :
« Les prestataires de services de la société de l'information qui stockent un grand nombre d'œuvres ou d'autres objets protégés chargés par leurs utilisateurs et qui donnent accès à ces œuvres et autres objets prennent, en coopération avec les titulaires de droits, des mesures destinées à assurer le bon fonctionnement des accords conclus avec les titulaires de droits en ce qui concerne l'utilisation de leurs œuvres ou autres objets protégés ou destinées à empêcher la mise à disposition, par leurs services, d'œuvres ou d'autres objets protégés identifiés par les titulaires de droits en coopération avec les prestataires de services. Ces mesures, telles que le recours à des techniques efficaces de reconnaissance des contenus, doivent être appropriées et proportionnées. Les prestataires de services fournissent aux titulaires de droits des informations suffisantes sur le fonctionnement et la mise en place des mesures, ainsi que, s'il y a lieu, des comptes rendus réguliers sur la reconnaissance et l'utilisation des œuvres et autres objets protégés. »
Ainsi, en l'état, ce texte oblige toutes les plateformes à une certaine censure. Que l’on protège les auteurs, cela est plutôt une bonne chose. Par contre, en demandant aux « prestataires de service de la société de l’information », comme les plateformes de partage de code, de mettre en place des systèmes automatiques de filtrage, tout contenu pourra être censuré sans autre forme de procès.
Comme aucun programme de filtrage de code ne sera jamais fiable à 100% du fait des développeurs/licences multiples, de nombreux faux positifs risquent d’émerger et de ralentir l’évolution de différents projets. Ainsi, qu'adviendra-t-il d'un projet N contenant des fragments de code issus de projets N2, N3, etc., chacun possédant une licence différente ? Ne risquons-nous pas de nous retrouver avec un nouveau NPM-gate [3] ? Pour rappel, la société Npm Inc. qui gère npm supprima arbitrairement un module à la demande d’une société (pour une similarité de nom), ce qui provoqua l’ire de l’auteur dudit module qui supprima toutes ses contributions, ce qui entraîna l’échec de la construction de nombreux projets open source.
Étrangement, GitHub qui, d'après ses conditions d'utilisation (« We reserve the right at any time from time to time to modify or discontinue, temporarily or permanently, the Website (or any part of it) with or without notice ») s'autorise une forme de censure, s’est ému récemment à ce sujet [2]. Mais GitHub Inc. vaut-il mieux que Npm Inc. ?
Cet article 13 tant décrié et qu'il faut combattre nous permet donc également de nous rappeler qu'en partageant notre code sur une plateforme telle que GitHub, nous sommes tributaires d'une société qui peut à tout moment modifier, effacer un projet ou simplement cesser son activité. Le risque de censure n'est pas le fait d'un programme de filtrage automatique massif, mais est dès à présent réel.
Nous sommes nombreux à utiliser ces plateformes très pratiques, le tout est d'être conscient des dangers... GNU/Linux Magazine, en revanche, est un magazine et présente donc moins de risques :-) … je vous souhaite une bonne lecture !
[1] Proposition de directive du parlement européen et du conseil sur le droit d’auteur dans le marché numérique : https://eur-lex.europa.eu/legal-content/FR/TXT/?uri=CELEX:52016PC0593&qid=1525240660076
[2] The GitHub blog, « EU wants to require platforms to filter uploaded content (including code) » : https://blog.github.com/2018-03-14-eu-proposal-upload-filters-code/
[3] KOÇULU A., « I’ve just liberated my modules » : http://azer.bike/journal/i-ve-just-liberated-my-modules/
Tristan Colombo
p. 08 Retour sur KubeCon et CloudeNativeCon Europe 2018 Copenhague
p. 12 Le lien de trop : une enquête de J.S. Gramiet
p. 18 Partitionnement avec PostgreSQL 10
p. 22 Modélisation et génération de code automatique
p. 34 RPN : interpréteur de notation polonaise inversée en langage C
p. 48 Vous avez dit Event Driven ?
p. 56 Zsh et PowerLevel9K pour un Shell de malaaaaade !
p. 72 Du Python dans Minecraft ou comment automatiser les constructions
p. 88 Modes d'opérations et chiffrement des disques
En tant que magazine de développement informatique, nous ne pouvions pas ne pas nous poser la question : quid de l' « apprentissage du code », pour utiliser la formule consacrée ? Que ce soient les médias ou les politiques, on ne cesse de nous rappeler les enjeux majeurs du développement informatique et de l'intelligence artificielle. Mais pour être compétitifs, il faut que nos enfants, les futurs informaticiens et chercheurs de demain soient correctement formés. Qu'en est-il donc ?
C'est la question que je me pose pratiquement chaque jour depuis que mes enfants sont en âge d'aller à l'école. Ce qui suit n'est en rien une généralité, mais le fruit d'une observation ponctuelle qui n'est certainement pas isolée. En maternelle, l'école était équipée de vieux PC donnés par des parents et de quelques Mac : inutilisables de par la disparité du matériel et l'absence de connaissances techniques de l'équipe enseignante. Après mon passage, quelques ordinateurs étaient utilisés sous DouDouLinux en grande section. C'était il y a 5 ans… depuis les ordinateurs ne sont plus du tout utilisés et je m'aperçois en écrivant cet édito que le site de DouDouLinux n'est plus accessible : simple erreur du serveur web ou arrêt du projet ? On peut certes utiliser une Debian, rendre le bureau plus accessible et installer GCompris, mais DouDouLinux était déjà paramétré pour une utilisation par des enfants. Dans ce cadre, PrimTux est sans doute une alternative intéressante.
Dans l'école primaire de mon fils, il y a cette fois une véritable salle informatique… où les ordinateurs sont tous sous Windows et ne sont pas maintenus. Pour apprendre aux enfants à « programmer » (créer des animations avec Scratch), les enfants se déplacent donc et effectuent quelque trois heures de trajet aller/retour pour une heure de temps passée devant un ordinateur. Tout cela pour accéder à des ordinateurs fonctionnels, mais également à des formateurs ayant acquis quelques rudiments de programmation, les enseignants n'ayant pas eu la chance d'avoir accès à cette connaissance…
Nos voisins anglais ont été un peu plus rapides que nous à comprendre les enjeux de l'apprentissage de la programmation et l'utilisation de la BBC Micro:bit, petite carte permettant de s'initier aux joies du développement de manière plus large que Scratch (JavaScript avec un éditeur block ou normal et Python) en est l'exemple flagrant, même si cette dernière n'est employée qu'à partir de l'équivalent de notre 6ème.
Microsoft et Apple ont bien senti l'importance économique de ces futurs consommateurs. Le premier en s'impliquant dans le projet BBC Micro:bit en développant un éditeur, en rachetant Minecraft, en proposant le site https://makecode.com/ pour apprendre à programmer - à la sauce Windows bien sûr, tout en mode graphique-, et en diffusant des offres de réduction pour les étudiants et enseignants : une fois que les gens sont habitués à utiliser du Microsoft, faire machine arrière est beaucoup plus compliqué. Pour le second, en plus des promotions pour étudiants et enseignants qui ne visent qu'à ancrer les futurs utilisateurs sur du matériel de la marque, Apple proposait également des sorties de classe pour bien formater les futurs acheteurs (jusqu'à leur suspension par le ministre de l'Éducation nationale il y a peu). Édifiant !
Ainsi, alors que certaines administrations françaises ont réussi leur passage au logiciel libre, l’éducation nationale est la cible d'entreprises qui visent à enfermer les enfants dans leur vision propriétaire de l’informatique et du développement : on utilise Windows/Apple comme système d’exploitation, on développe de manière purement graphique… on devient de futurs clients !
Les grandes marques ne cherchent pas vraiment à former les élèves, ce n'est ni leur rôle ni leur intérêt. L'histogramme Current Age vs . Age started coding proposé sur https://research.hackerrank.com/developer-skills/2018/ et basé sur 39441 développeurs montre que parmi les développeurs, les 35 - 54 ans sont ceux qui ont appris à programmer le plus tôt et en plus grand nombre. La curiosité scientifique aurait-elle fuit les plus jeunes ?
Je vous souhaite une bonne lecture, et n'hésitez pas à laisser traîner vos GNU/Linux Magazine sur les lieux de passage d'enfants, on ne sait jamais, ils pourraient voir qu'une autre informatique est possible...
Tristan Colombo
p. 08 Première édition des French GNU Radio Days
p. 11 Moira et Alicia, le monde de la robotique a besoin de vous
p. 16 Quelques applications des Arbres Binaires à Commande Équilibrée
p. 28 Déboguer un conteneur « nu »
p. 36 Gestion de conteneurs en Bash
p. 40 Déboguer un conteneur « nu »
p. 53 Knockout, un framework JS qui a du répondant
p. 66 Au cœur des microprocesseurs
p. 82 J’ai hacké ma clarinette !
p. 92 Un VPN moderne, puissant, sûr et simple : à la découverte de WireGuard
Retour de vacances…
Le lundi matin, vous allumez votre ordinateur et les lignes défilent sous vos yeux : 117 mails non lus. Après deux semaines d’absence vous en avez reçu plus d’une centaine, des mails que vous traitez habituellement journalièrement et dont la lecture, le tri et éventuellement la réponse se diluent dans le temps consacré à vos autres tâches. Mais sur 117 mails, combien sont réellement intéressants ? Je me suis livré à une petite expérience et les chiffres suivants sont donc issus d’un cas concret. Je dispose de deux adresses professionnelles et une personnelle ; je ne me base ici que sur mon adresse tristan@gnulinuxmag.com pour laquelle j’ai de nombreux filtres actifs qui me permettent d’éliminer bon nombre d’indésirables, mais qui sont assez peu restrictifs de manière à limiter le risque de perte de messages importants.
Tout d’abord, sur ces 117 mails il y a ceux que j’ai identifiés immédiatement comme inutiles grâce à l’objet. Le temps de lire l'en-tête et de cocher le mail, il faut compter environ 4 secondes au départ puis rapidement on tourne autour de 6 à 8 secondes de peur d’effacer par inadvertance un mail important. Je compterai donc 6 secondes pour traiter un indésirable. Au final, il me reste 38 mails soit 79 indésirables et 474 secondes soit environ 8 minutes de « travail ». En temps normal, je parcours ces mails « au cas où ». Le temps de traitement est alors plutôt d’environ 14 secondes. Pour les 79 mails supprimés, j’aurais donc consacré en temps normal environ 18 minutes à les traiter… pour rien.
En projetant ce résultat sur mes deux autres adresses (qui contiennent à peu près autant de mails à mon retour), on arrive à 54 minutes soit 27 minutes par semaine. Sur 47 semaines de travail par an, cela représente un peu plus de 21h soit 2 jours et demi (pour les gens qui travaillent 35h par semaine). Beaucoup de temps perdu pour rien ! Quand on pense en plus que d’après Mike Berners-Lee dans « How bad are bananas ? The carbon footprint of everything » (2011), l’empreinte carbone d’un mail simple (sans pièce attachée) est de 4 g (l’ADEME a une évaluation plus importante), cela correspond à 7,5 kg de CO2… uniquement pour les mails indésirables que je reçois au cours d’une année !
Nous ne pouvons pas grand-chose pour réduire l’empreinte carbone de ces mails… par contre il faut faire un choix : risquer de perdre quelques mails et utiliser des filtres plus restrictifs ou perdre du temps… beaucoup de temps. Désormais, au vu de ces chiffres, mon choix est fait.
Et en parlant de temps, vous ne perdrez pas le vôtre en lisant ce numéro de GNU/Linux Magazine regorgeant comme à l'accoutumée d'informations diverses ! Bonne lecture !
Tristan Colombo
p. 08 Le cerveau de Peter
p. 11 Script Shell de comparaison de deux arborescences
p. 30 Testez votre infrastructure comme vous testez votre code avec Test Kitchen
p. 35 Générer vos conteneurs et machines virtuelles de manière automatisée avec Packer
p. 40 Mise à jour d’un système Linux embarqué « Over The Air » : comment intégrer et utiliser « Mender » pour vos déploiements
p. 62 Comment démarrer manuellement le noyau Linux
p. 72 Votre chatbot peut-il passer pour un humain ?
p. 82 Qt on the Web
p. 92 PaSSHport, bastion SSH
Avez-vous remarqué comme, étrangement, de plus en plus d'applications et de sites en ligne dysfonctionnent ? Je pense avoir enfin trouvé un élément de réponse à ce phénomène qui se généralise… mais avant de vous exposer mon hypothèse, je vous propose de revenir sur deux exemples concrets auxquels j'ai été confronté au cours de la même semaine.
Tout d'abord, je reçus un appel de détresse de ma mère qui ne parvenait pas à acheter des places d'opéra sur Internet. Rien que de très habituel : elle n'avait sans doute pas vu où cliquer ou avait dû se tromper de champ de formulaire… Je pris donc le temps de refaire la manipulation avec elle en utilisant chacun un navigateur différent à savoir Chromium (Google Chrome) et Firefox. Nous obtînmes le même résultat et nous retrouvâmes dans l'impossibilité de sélectionner une place sur le plan qui s'affichait (le clic ne produisait aucun évènement). Trouvant cela vraiment étrange, je décidai de tester sur un autre navigateur. Sur iPad avec Safari le résultat fut le même… mais sous Android avec Chrome (version Mobile 67), je pus achever la réservation.
Quelques jours après, je voulus effectuer une commande sur un site marchand. Il ne s'agissait pas d'un de ces monstres de la vente par correspondance, mais d'une enseigne de taille moyenne aux États-Unis. La commande se déroula sans accroc, le paiement également et mon colis fut expédié. Jusque-là pas de problème. C'est après que les complications apparurent : la commande partant de Los Angeles et n'étant pas un envoi prioritaire, au bout de quelques jours, comme nous en avons tous pris l'habitude, je cliquai sur un lien me permettant de suivre mon colis et j'aboutis sur une page... blanche ! Un petit problème de serveur, ça peut arriver et je décidai donc d'attendre le lendemain… pour un résultat identique. Me souvenant de mon expérience précédente, je tentai sans trop y croire une visualisation sur mon smartphone. Et là, ô miracle, les informations apparurent comme par enchantement !
On ne peut bien entendu pas tirer de généralités de ces deux expériences, mais elles soulignent un point important : bien souvent les applications et services ne sont pas purement et simplement buggées, elles ne sont pas testées ! Dans ces deux cas, on peut facilement imaginer qu'un seul navigateur a été employé et que la validation en mise en production a pu se produire de la manière suivante :
Tester un programme n'est pas une activité plaisante, mais elle est nécessaire. Elle paraît pourtant être souvent négligée. Même lorsque j'indique à mes étudiants en développement web que les tests feront partie des critères de notation d'un projet, environ 50% d'entre eux ne teste absolument rien (que ce soient les saisies utilisateur ou l'exécution sur différents navigateurs). Pourtant, même lors de calculs basiques on peut s'assurer de la validité d'un résultat. En simplifiant à l'extrême, avec x + 1 = 2, on peut dire que x = 10… On s'aperçoit vite que 10 + 1 ne vaut pas 2, mais pour cela il faut prendre le temps de tester le résultat obtenu et peut-être encore plus important avoir l'humilité de se dire que l'on a pu faire une erreur : « Errare humanum est ».
La prochaine fois qu'une application dysfonctionne, pensez donc à tester des choses basiques puisque les tests ne sont plus à la mode. En attendant, vous pouvez toujours lire GNU/Linux Magazine et vous astreindre à tester TOUS vos codes...
Tristan Colombo
p. 08 Performances et supervision avec PostgreSQL en version 10
p. 12 Introduction au NLP avec Spacy
p. 18 Big data avec awk
p. 22 Ansible Container : le meilleur des deux mondes ?
p. 34 Just enough Operating System et l’exemple de RancherOS
p. 42 Aller plus loin avec Bash...
p. 54 Utilisation avancée de l’interface USB-RS232 FT232
p. 72 Coreboot et me_cleaner : libérez votre BIOS
p. 82 Sélection des informations partagées dans un agenda Google
p. 88 Proxy Let’s Encrypt : comment généraliser SSL
p. 06 Android 8, le projet Treble
p. 14 Les langages de demain
p. 32 L’Intelligence Artificielle au service de la classification
p. 39 Quelques éléments de traitement de signaux échantillonnés en temps discret avec GNU Radio
p. 52 Highway to Helm !
p. 62 U-Boot : à la découverte du « démarrage vérifié »
p. 82 RPN : extension de la syntaxe grâce à lex
p. 92 Gérez vos listes avec le framework IPset et le pare-feu Netfilter
Mandrake, Debian, Red Hat, Suse, Debian, Ubuntu, Debian, … ce sont les différentes distributions par lesquelles je suis passé. On retrouve une constante, une distribution qui revient toujours : Debian. Alors oui, c’est la distribution que je préfère et malgré quelques infidélités, je finis toujours par revenir vers elle. Mais cela ne m’empêche pas de rester objectif. Actuellement, je suis sous Debian Stretch (stable) avec un noyau 4.9.0.7. La dernière mise à jour d’un système réputé stable entraîna pour moi, et pour la première fois, un grand questionnement. En effet, on a tendance à dire que l’on ne réinstalle pas une Debian, on la répare. J’étais assez d’accord avec cette « maxime » jusqu’à des évènements récents que je vais vous relater dans cet édito...
Dernière mise à jour du système, changement de noyau, tout va bien. Redémarrage de la machine, faites vos jeux, rien ne va plus :
Rien de bien grave à première vue, un classique problème de driver vidéo. Je redémarre en recovery mode et là, surprise : plus de réseau non plus ! Un rapide coup d’œil aux interfaces réseau :
Je passe en configuration « manuelle » dans /etc/network/interfaces :
Le réseau est revenu ! Pourquoi était-il parti ? Mystère… En tout cas voilà un problème de résolu. Voyons maintenant pourquoi le mode graphique ne se lance pas :
J’obtiens la confirmation qu’il s’agit bien d’un problème de driver de la carte graphique. Je réinstalle donc les drivers NVidia et tout fonctionne de nouveau : une Debian ça ne se réinstalle pas, ça se répare ! C’est donc regonflé à bloc que je peux me remettre au travail… et découvrir progressivement que le VPN ne veut plus se lancer, que les caractères accentués composés ne sont plus reconnus dans certaines applications (et non, pas dans toutes, on dirait qu’il y a de vrais morceaux de Windows dans ma Debian), etc.
Passée la déception (je n’étais même pas en testing !), voici le temps de la réflexion sur les alternatives (hors Debian nul salut :-)) : il faut trouver une solution. Pour moi, ce sera une réinstallation en configurant Ansible pour que la prochaine fois tout se fasse automatiquement. Et puis, tant qu’à faire, autant passer en testing et avoir des paquets plus récents puisque visiblement « stable » ne signifie plus grand-chose…
En attendant, aucune mise à jour hasardeuse n’a été effectuée sur le magazine que vous tenez entre vos mains et vous ne devriez rencontrer aucune difficulté pour le lire…
Tristan Colombo
Déployez votre solution de Single Sign On ! Intérêts et avantages de...
Lire plus ➤Arduino / RP2040 / STM32 / ESP Programmez vos microcontrôleurs en...
Lire plus ➤