Deux-cent-vingt-deuxième émission « Libre à vous ! » de l’April. Podcast et programme :

• sujet principal : le logiciel libre do·doc : produire facilement des contenus

• la chronique F/H/X de Florence Chabanois, intitulée : « Qui a envie d’être sexiste ? »

• la chronique À la rencontre du libre de Julie Chaumard, sur la PyConFR 2024, la conférence francophone du langage Python, qui se déroulera du 31 octobre au 3 novembre à Strasbourg.

Rendez‐vous en direct chaque mardi de 15 h 30 à 17 h sur 93,1 FM en Île‐de‐France. L’émission est diffusée simultanément sur le site Web de la radio Cause Commune .

Télécharger ce contenu au format EPUB

Dans l’histoire de l’espace, les épisodes qui ont le plus marqué les esprits sont, probablement, ceux des marches sur la Lune qui ont été le fait des missions Apollo. Dans cette deuxième dépêche à l’occasion de la journée Ada Lovelace de 2024, on retrouvera donc un portrait de quatre femmes qui ont codé ou calculé les missions Apollo, Judith Love Cohen (1933 – 2016), Margaret Hamilton, JoAnn H. Morgan et Frances (Poppy) Northcutt mais aussi une histoire de celles, plus anonymes, qui ont tissé les mémoires des modules Apollo.

Ces biographies sont précédées d’un genre d’état des lieux de l’informatique en URSS et aux USA et suivies d’une sitographie pour prolonger un peu plus l’exploration.

Sommaire

• Préambule
• Les ordinateurs de la conquête de l’espace URSS et USA
  • Les ordinateurs soviétiques
  • Les ordinateurs des missions Apollo
• Judith Love Cohen (1933 – 2016) l’accouchement du programme de guidage Apollo
  • Margaret Hamilton (née en 1936) la jeune femme à côté de la pile de livre de sa hauteur
• JoAnn H. Morgan (née en 1940) la seule femme présente dans la salle de tir lors du lancement d’Apollo 11
• Frances Northcutt dite « Poppy » (née en 1943) l’autre seule femme présente dans les salles de tir des missions Apollo 8 et 13
• Les tisserandes
• Pour compléter
  • Les ordinateurs soviétiques
  • Missions Apollo
  • L’exploration spatiale et les astronautes
  • Sur la journée Ada Lovelace et la place des femmes dans les carrières scientifiques et techniques
• Excuse et paragraphes de la fin

Préambule

Pourquoi n’est-il essentiellement question que des informaticiennes de la NASA ou ayant travaillé pour la NASA ? Cela revient à poser la question de l’informatique côté Union soviétique. Plusieurs facteurs peuvent expliquer la méconnaissance que l’on a des personnes qui, côté soviétique, ont travaillé sur les programmes relatifs à la conquête de l’espace, à commencer par l’histoire qui est, disons compliquée surtout par rapport à celle des USA.

Ensuite, c’était un secteur stratégique : envoyer des satellites pose les mêmes questions balistiques que l’envoi d’un missile intercontinental. L’existence du fondateur du programme spatial soviétique, Sergueï Korolev , qui subissait des peines d’emprisonnement pour raisons politiques (dont quatre mois de goulag ) et qui avait été admis dans l’équipe de l’ingénieur aéronautique Andreï Tupolev lui-même prisonnier politique à l’époque, a été tenue secrète jusque bien après sa mort. On peut penser qu’il en va de même pour les autres personnes ayant participé aux programmes de conquête spatiale.

Concernant l’informatique proprement dite, trois noms apparaissent. Sergueï Lebedev (1902 - 1974) est considéré comme le père de l’informatique soviétique. Lebedev semble être un nom assez courant, ainsi, on trouve un cosmonaute russe du nom de Valentin Lebedev. L’Ukrainienne Ekaterina Yushchenko (en) (1919 - 2001) que le site ukrainien (en) sur l’histoire de l’informatique en Ukraine appelle « l’Ada Lovelace ukrainienne ». Yushenko a posé les bases de la programmation théorique en Ukraine (et en URSS avant) et écrit le langage de haut niveau Address . Andreï Erchov (en) (1931 – 1988), fondateur de l’École sibérienne de science informatique dont le livre, Programmation pour le BESM , a marqué un certain Donald Knuth .

Les ordinateurs de la conquête de l’espace URSS et USA

Les ordinateurs soviétiques

Le premier ordinateur soviétique date de 1950, construit sous la direction de Sergeï Lebedev, dans un contexte où le traitement électronique de l’information, considéré par Staline (1878 – 1953) et son entourage comme « fausse science au service de l’impérialisme » ¹ n’est pas encouragé par le pouvoir. Il s’agit du MESM (МЭСМ, Малая электронная счетно-решающая машина, petit calculateur électronique, qui était plutôt assez gros en volume), développé par une vingtaine de personnes. La plupart des ordinateurs soviétiques en découleront.

Le BESM sur lequel Andréï Erchov a écrit son livre de programmation a été produit à partir de 1953. Il se déclinera en deux séries les : BESM–1 (1950) à BESM–6 (1966) et les M -20 et ses descendants. Ces derniers, dont le premier, fabriqué à Moscou, est sorti en 1956 seront les ordinateurs des premiers âges de la conquête spatiale. Le dernier de la série, le M-220 était, quant à lui, fabriqué à Kazan. Ils ont, par la suite, probablement été remplacés par le MINSK dans les années 1960.

Quant aux langages de programmation, Yves Logé, en 1987, dans l’article Les ordinateurs soviétiques : Histoire obligée de trois décennies de la Revue d’études comparatives Est-Ouest relevait ceci :

• 1953 – librairie de sous-programmes pour STRELA et BESM,
• 1955 – langage de compilation (PP2 – PP – BESM),
• 1957 – assembleurs (PAPA, SSP),
• 1962 – compilateur Algol 60 (TA 1),
• 1962 – moniteur de traitement par lots (AUTOOPERATOR),
• 1966 – premier système d’exploitation (MINSK 22, BESM 6),
• 1967 – langage de programmation (EPSILON, ALMO).

Le FORTRAN et l’ALGOL, bien qu’ayant été introduits dans les ordinateurs soviétiques dans les années 1960, ne commenceront à être vraiment utilisés qu’à partir des années 1970, époque à laquelle l’URSS abandonnera la conception de ses propres ordinateurs.

Les ordinateurs des missions Apollo

L’informatisation de la NASA a commencé avec des machines IBM, la série IBM 700/7000 commercialisée dans les années 1950 à 1960 ; c’était la première version des ordinateurs à transistors. Les langages de programmation les plus courants à l’époque étaient le Cobol et le FORTRAN pour lequel des personnes comme Frances Allen avaient été recrutées afin de former des chercheurs, parfois réticents, au langage.

En 1964, IBM sort la série System/360 qui pouvait travailler en réseau et dont le système d’exploitation, multitâches, était OS/360. Il était doté d’une RAM, insuffisante, d’un mégaoctet qui a poussé les ingénieurs à adopter un code abrégé. Et, évidemment, il se programmait encore à l’époque avec du papier.

L’invention qui a permis d’équiper informatiquement les modules des missions Apollo est celle des circuits intégrés, inventés par Jack Kilby en 1958. Ils équiperont les ordinateurs à partir de 1963, la NASA étant dans les premiers utilisateurs pour les ordinateurs de guidage d’Apollo. Par la suite, les circuits intégrés permettront de fabriquer les « mini-ordinateurs » (qui restent toujours assez encombrants) et les micro-ordinateurs. Les premiers micro-ordinateurs, à l’allure de ceux que nous avons actuellement avec : l’ordinateur, un écran, un dispositif de saisie, puis, plus tard, un dispositif de pointage sortiront en 1973, après les missions Apollo.

Judith Love Cohen (1933 – 2016) l’accouchement du programme de guidage Apollo

Judith Love Cohen est ingénieure aérospatiale, après sa retraite, elle deviendra écrivaine et fondera une entreprise multimédia Cascade Pass.

En 1952, celle qui aidait ses camarades de classe à faire leurs devoirs de mathématiques, est embauchée par la North American Aviation. Elle obtient, en 1957 un Bachelor of Art (licence) en sciences, puis, en 1962, un master en sciences à l’Université de Californie. En 1957, après son BA, elle est embauchée par le « Space Technology Laboratories (laboratoire des technologies spatiales) qui deviendra TRW. Elle y travaillera jusqu’à sa retraite en 1990, souvent seule femme ingénieure de l’équipe dans laquelle elle se trouvait.

Son travail : les ordinateurs de guidage. Elle a fait partie de l’équipe qui a conçu le « Tracking and Data Relay Satellites (TDRS) », le système suivi et de relais des données des satellites de la NASA. Ce système qui permet notamment de rester en contact avec la Station spatiale internationale.

Elle s’occupera aussi du télescope Hubble. Elle avait été chargée de concevoir le système terrestre des opérations scientifiques. Elle dira dans une vidéo (en) réalisée par Cascade Pass qu’elle avait travaillé avec les astronomes, car c’étaient eux qui allaient utiliser le télescope. Le système avait trois fonctions principales :

• planification des observations,
• contrôle en temps réel du réglage de la mise au point et du changement des filtres,
• récupération des données pour générer des photos, partie que Cohen considérait comme la plus intéressante et la plus difficile à réaliser.

Mais, le point culminant de sa carrière a été le programme Apollo, notamment le système de guidage de la mission Apollo 13 qui devait être la troisième à se poser sur la Lune, l’ordinateur AGS (Abort Guidance System, système de guidage d’abandon pour le module destiné à rester sur la Lune). Cette mission commence mal : les astronautes prévus à l’origine changent presque à la dernière minute, quand la fusée décolle le 11 avril 1970, le moteur central du deuxième étage s’éteint trop tôt. Ce sera compensé, sans incidence sur la trajectoire. Le 13 avril, l’un des astronautes, Jack Swigert , lance le fameux :

Houston, we’ve had a problem.

Le module de service d’Apollo 13 est hors d’usage, l’équipe change de module de service en urgence et embarque dans le module lunaire (LM) prévu pour deux personnes alors qu’ils sont trois. L’AGS servira en tant qu’ordinateur de bord et contrôlera tous les équipements vitaux, mais il n’aurait pas pu revenir sur l’orbite terrestre si Cohen n’avait pas bataillé avec la NASA pour que la fonction de retour y soit incluse.

Son fils, l’ingénieur en informatique Neil Siegel (en) racontera, ce qui a été vérifié, qu’elle avait conçu l’AGS pendant qu’elle était enceinte de son demi-frère, l’acteur Jack Black. Le 28 août 1969, au moment de partir pour l’hôpital pour accoucher, elle prend aussi le code d’un problème sur lequel elle travaillait. Elle appellera son patron plus tard pour lui signaler qu’elle l’avait résolu, et aussi, en passant, que le bébé était né. Le problème en question concernait l’AGS.

Margaret Hamilton (née en 1936) la jeune femme à côté de la pile de livre de sa hauteur

La photo probablement la plus connue de Margaret Hamilton est celle où on la voit poser à côté d’une pile de gros documents reliés : le code du logiciel de navigation de la mission Apollo 11.

Margaret Hamilton intègre le MIT (Massachusetts Institute of Technology) en 1960 pour développer des logiciels informatiques. En 1961, la NASA confie au MIT la mission de réaliser un ordinateur embarqué de navigation et de pilotage avec un cahier des charges assez léger et permettant au MIT une grande créativité. Ce sera l’AGC (Apollo Guidance Computer) qui sera le premier à utiliser des circuits intégrés. Lourd, 32 kilos, il préfigure néanmoins les ordinateurs portables puisque tous les éléments, ordinateur, mémoire, écran et dispositif de saisie étaient réunis dans un seul boitier.

Mais avant de travailler sur l’AGC, Hamilton intègre, en 1961, le laboratoire Lincoln pour travailler sur le projet militaire ultra-secret SAGE qui devait produire en temps réel une image de l’espace aérien états-unien. Elle racontera ensuite avoir fait l’objet d’un bizutage (une coutume apparemment) : on lui avait demandé de travailler sur un programme piégé commenté en grec et en latin. Elle était la première à avoir réussi à le faire fonctionner. Et c’est ainsi qu’en 1963 elle est invitée à rejoindre le laboratoire Draper du MIT qui était en charge du développement des logiciels embarqués d’Apollo.

Elle évoquera aussi la fois où, emmenant de temps en temps sa fille au laboratoire, un jour, cette dernière, jouant à l’astronaute, fait planter le système : elle avait sélectionné le programme d’atterrissage alors qu’elle était « en vol » (un appui sur une mauvaise touche). Ce que voyant Hamilton alerte la direction pour que l’on modifie le programme, réponse « ils sont expérimentés, ça n’arrivera pas ». Sauf qu’évidemment, c’est arrivé au pendant la mission Apollo 8. On peut imaginer qu’Hamilton et son équipe étaient préparées à cette éventualité : les données de navigation seront renvoyées et la trajectoire corrigée. Elle codera aussi un système de priorité des tâches afin d’éviter que l’AGC ne sature et qu’il fasse le travail correctement. L’AGC pouvait ainsi interrompre des tâches pour faire passer celles qui étaient les plus prioritaires et c’est ce qui a permis à Apollo 11 d’atterrir correctement sur la Lune.

Hamilton quittera le MIT en 1974 pour co-fonder une entreprise de développement de logiciels, Higher Order Software (HOS) qu’elle dirigera jusqu’en 1984. HOS se spécialisait notamment sur les logiciels de détection des erreurs. Ensuite, en 1986, elle créera Hamilton Technologies et concevra le langage de programmation USL (Universal Systems Language).

Elle reçoit en 2016 la médaille présidentielle de la liberté des mains de Barack Obama. Margaret Hamilton est considérée comme une pionnière de l’ingénierie logicielle et comme une des personnes qui ont contribué à la populariser.

JoAnn H. Morgan (née en 1940) la seule femme présente dans la salle de tir lors du lancement d’Apollo 11

Sur une photo de la salle de tir d’Apollo 11 , le 16 juillet 1969, elle apparaît comme la seule femme derrière une console. Les femmes que l’on voit sur le côté sont entrées après le lancement.

Étant enfant, elle préférait lire Jules Verne à jouer à la poupée ² et jouer avec la boîte de chimie que son père lui avait offert. Son père, justement, travaillait pour le programme de développement des fusées américaines. JoAnn H. Morgan va passer son adolescence à Titusville en Floride, à quelques kilomètres de la base de lancement de Cap Canaveral. Elle y regardera les lancements des fusées. Ce qui la décidera dans son orientation professionnelle. Elle commence, à dix-sept ans, par un stage à l’ Army Ballistic Missile Agency (ABMA, Agence des missiles balistiques de l'armée de terre). Elle continuera à travailler à Cap Canaveral pendant l’été. En 1963, elle obtient un Bachelor of Arts (licence) en mathématiques. Elle commence à travailler pour la NASA au Centre spatial Kennedy (KSC) en tant qu’ingénieure. Elle sera la seule, ça n’a pas été facile : entre le fait que son supérieur hiérarchique trouve nécessaire de préciser qu’elle est ingénieure et pas là pour faire le café pour ses collègues (en) ou l’absence de toilettes pour femmes.

En 1969, elle est promue et devient « Chief Instrumentation Controller, KSC Technical Support » (Contrôleur en chef de l’instrumentation, support technique du centre), ce qui lui donne un poste dans la salle de contrôle de la mission Apollo 11. L’équipe de Morgan sera celle qui supervisera le lancement de la mission ce qui lui demandera de rester dans la salle de contrôle encore après le lancement pour pouvoir vérifier les équipements et faire un rapport sur les dommages consécutifs au lancement afin de préparer le suivant, sa tâche, dans le cadre de la mission, s’arrête au moment de l’atterrissage lunaire. Elle considère que c’est ce qui a lancé sa carrière.

Après Apollo 11, elle bénéficiera d’une bourse Sloan pour poursuivre des études et elle obtiendra une maîtrise en sciences de gestion en 1977 et retournera à la NASA en 1979 où elle est promue chef de la division des services informatique du KSC, première femme à occuper ce poste en particulier et un poste de direction à la NASA. Une tâche ardue dans une période de transition technologique : la NASA changeait son système informatique et commençait à remplacer les vieux ordinateurs géants par des PC. Elle deviendra ensuite directrice adjointe des véhicules de lancement (deputy of Expendable Launch Vehicles, director of Payload Projects Management) puis directrice de la sécurité de la mission ( director of Safety and Mission Assurance). Elle aura été l’une des deux dernières personnes à avoir vérifié le lancement de la navette spatiale.

Elle prend sa retraite en 2003 après avoir passé toute sa carrière à la NASA.

Morgan continue à militer pour que plus de femmes puissent suivre des carrières scientifiques et techniques.

Frances Northcutt dite « Poppy » (née en 1943) l’autre seule femme présente dans les salles de tir des missions Apollo 8 et 13

Frances « Poppy » Northcutt a planifié les trajectoires des vols des missions Apollo dans les années 1960 et 1970.

Elle commence sa carrière dans l’aérospatiale comme Judith Love Cohen en étant embauchée en 1965 par TRW. Elle sera d’abord une des calculatrices humaines. Problème : pour pouvoir bénéficier d’une promotion, elle devait faire des heures supplémentaires si nécessaire, ce qui était interdit aux femmes états-uniennes de l’époque. Elle tient le pari d’en faire mais non rémunérées. Cela fonctionne, elle obtient une promotion et intègre l’équipe technique (personnel effectuant des travaux ingénierie), mieux payée. Ce qui pose un autre problème, celui de l’écart de rémunération entre les hommes et les femmes.

Le travail de l’équipe technique consistait à écrire le programme. D’autres assuraient la tâche de le rentrer dans l’ordinateur, ce qui n’allait pas sans quelques bugs au passage, qui pouvaient avoir des conséquences fatales. L’équipe de Northcutt était chargée du calcul de la trajectoire de retour d’Apollo 8. C’était une mission mémorable pour Northcutt à plus d’un titre. D’abord, c’était la première fois qu’un véhicule spatial habité allait être mis en orbite autour de la Lune. C’était aussi ce qui aura permis de déterminer l’équipement et le matériel nécessaire pour les missions suivantes, notamment la quantité de carburant nécessaire. Enfin, c’était la première fois que les calculs de Northcutt et de son équipe étaient utilisés, et cela allait servir aussi aux missions suivantes. Ainsi, après Apollo 8, il n’y aura pas eu de modifications des programmes, sauf en cas de problème. Pour Apollo 13, avec d’autres ingénieurs, elle aura pour mission de calculer le retour de la capsule Apollo après l’explosion du réservoir d’oxygène qui oblige l’équipage à rentrer sur Terre dans le module lunaire.

Elle suivra ensuite des études de droit à l’Université de Houston pour devenir avocate. Elle en sortira diplômée en 1981 et travaillera pour le procureur du comté de Harris à Houston, sera stagiaire auprès d’un juge fédéral en Alabama avant de se tourner vers le privé et défendre des causes sur les droits de femmes, elle qui a longtemps travaillé avec un salaire inférieur à celui de ses collègues pour le même travail.

Elle expliquera au site astronomy (en) :

J’ai eu beaucoup de chance. La plupart des femmes n’avaient pas quelqu’un qui se battait aussi durement pour elles.

Elle ajoutera :

C’est le problème auquel sont confrontées les femmes en particulier, lorsqu’elles sont embauchées pour un salaire inférieur à ce qu’elles valent. Si vous ne partez pas sur un pied d’égalité, vous ne pourrez jamais vous rattraper.

Northcutt continue à militer pour les droits des femmes, mis à mal aux États-Unis lors de la présidence de Trump.

Les tisserandes

Les tisserandes, dont beaucoup étaient navajos ou noires, les « Little Old Ladies » ont tressé les mémoires à tores de ferrite des missions Apollo. Elles avaient littéralement la vie des astronautes entre leurs mains.

Les RAM des ordinateurs des années 1950 à 1975 étaient le plus souvent des mémoires à tores de ferrite. D’après la notice de celles présentées au musée du Conservatoire National des Arts et Métiers (CNAM) à Paris dans la photo ci-dessous :

elles sont encore utilisées lors de certaines missions spatiales car elles ne sont pas endommagées par les rayons cosmiques.

Mémoires à tores de ferrite du Gamma 60 d’une capacité de 512 octets, début des années 1960, musée du CNAM, Paris.

La fabrication de ces mémoires ne pouvait pas être mécanisée, elles étaient donc tissées à la main. Et, à l’époque des missions Apollo les seules personnes qui avaient l’habilité et la précision digitale nécessaires pour le faire étaient des femmes, surnommées les LOL et supervisées par les « rope mothers » (mères des cordes), généralement des hommes, et dont la cheffe était Margaret Hamilton. Ce travail extrêmement critique, était contrôlé par trois ou quatre personnes avant d’être validé. Il réclamait non seulement des ressources manuelles mais aussi des capacités intellectuelles certaines pour être accompli correctement.

Quand, en 1975, un rapport de la NASA sur les missions Apollo s’extasiait, à juste titre, sur les systèmes informatiques développés en mis en œuvre, il négligeait complètement cet aspect essentiel. Les journalistes de cette époque, présentaient la fabrication des mémoires comme un travail ne nécessitant aucune réflexion ni aucune compétence…

Pour compléter

Les ordinateurs soviétiques

• Sergeï A ; Lebedev, père de l’ordinateur soviétique , Pierre Vandeginste, La Recherche, mensuel N°375, mai 2004, pour accéder à l’article, il faut « l’acheter » en visionnant une publicité, le bouton qui permet cela ne se voit pas dans un Firefox avec un bloqueur de publicité, mais ça fonctionne bien avec Konqueror
• Les ordinateurs soviétiques : histoire obligée de trois décennies , Yves Logé, Revue d’études comparatives Est-Ouest Année 1987 18-4 pp. 53-75
• Il y a 50 ans : back in the USSR , Pierre Mounier-Kuhn, blog binaire, 24 janvier 2020
• Première génération d’ordinateurs (1936-1956) , tout le site est en fait une histoire des calculatrices et des ordinateurs, Fabrice Auclert, 18 juillet 2019.

Missions Apollo

• Apollo 11 : un bond de géant technologique avec les ordinateurs de la mission ,
• Il y a 50 ans, Apollo 13 : revivez en images la catastrophe transformée en succès
• Il y a 50 ans : l’ordinateur qui emmena l’Homme sur la lune , 26 juillet 2019
• Dépôt du code source d’Apollo 11 (en)
• Si vous voulez vous amuser à refaire l’ordinateur embarqué d’Apollo 11, vous pouvez vous procurer le matériel pour un euro (oui ça a coûté beaucoup plus cher au départ)
• Photos des missions (en) .

L’exploration spatiale et les astronautes

• La conquête spatiale pas pour les femmes russes , Victoria Loguinova-Yakovleva, lapresse.ca, 14 juin 2013
• Les femmes dans l’espace : une conquête inégale , Maxime Tellier, Radiofrance, 18 octobre 2009
• Liste de femmes astronautes
• Svetlana Savitskaïa , première femme à avoir effectué une sortie extra-véhiculaire
• Corps européen des astronautes .

Sur la journée Ada Lovelace et la place des femmes dans les carrières scientifiques et techniques

• ‘I wrote my first piece of code at seven’: women share highs and lows in computer science for Ada Lovelace Day (en) , 10 octobre 2023, témoignages de six femmes informaticiennes, Nature, 10 octobre 2023
• De l’école à l’entreprise, les femmes toujours découragées de faire carrière dans les métiers scientifiques et techniques , Charlotte Bozonnet, Le Monde, 2 octobre 2024.

Excuse et paragraphes de la fin

Cette dépêche paraît assez tardivement après la précédente pour des raisons assez indépendantes de ma volonté et incluant un piratage d’un de mes sites.

Ceci étant, un grand merci une fois de plus à vmagnin pour ses suggestions, notamment pour cette citation tirée d’une de ses lectures, Forces de la nature de François Lacombe, Anna Reser et Leila McNeil chez Belin :

Dans l’histoire des sciences et des vols spatiaux, on constate que cette distinction nette établie entre les tâches techniques et non techniques a été l’une des façons de marginaliser systématiquement les femmes.

Ce qui se vérifie amplement notamment avec les tisserandes des mémoires.

Comme de bien entendu, entre les recherches, l’écriture et les commentaires de la dépêche précédente, il appert qu’il y a un sujet connexe, celui de l’astronomie et de l’évolution du métier d’astronome et d’astrophysicienne qui mériterait d’être traité. Ce qui sera fait, d’ici la fin de l’année. Et, si vous cherchez un sujet de mémoire ou thèse, à mon avis le thème des langages informatiques : naissance, diversité, histoire, pourquoi un langage très populaire finit par être abandonné, etc. pourrait être passionnant (si ça n’a pas déjà été fait). Peut-être qu’un jour je vous infligerai un texte sur l’histoire de l’informatique soviétique (ou peut-être pas).

Télécharger ce contenu au format EPUB

Pour ce troisième épisode du podcast Projets Libres depuis la rentrée, nous recevons Gaël Blondelle pour parler de la fondation Eclipse .

Avec Gaël, qui est un des dirigeants exécutifs de la fondation et membre du board de l' Open Source Initiative (OSI) , nous parlons des sujets suivants :

• l'histoire et la création de la fondation
• les raisons de son déménagement en Europe et sa forme juridique
• à quoi sert une fondation ?
• Eclipse et la souveraineté digitale européenne
• les principaux projets hébergés par la fondation Eclipse
• la collaboration avec les autres fondations dans le cadre du Cyber Resilience Act (CRA)
• constituer un lobby européen de l'Open Source
• le futur de la fondation

Bonne écoute !

Télécharger ce contenu au format EPUB

Cette semaine encore, un numéro du Lama Déchaîné, sortait ce mercredi 23 octobre. Toujours avec quatorze rubriques à découvrir. Toujours pour soutenir financièrement l'April, mieux connaitre ses actions, mais pas que.

La semaine dernière, l'édito de la présidente était un coup de gueule sur la domination et les stratégies désastreuses et liberticides de Microsoft. Elle dénonçait l'Open Bar et les dérogations de certains ministères. Cette semaine, elle explique plus calmement, le travail invisible de l'April avec les parlementaires, les échanges d'arguments pour limiter certains projets de lois nuisibles aux logiciels libres, les questions écrites qui sont posées au gouvernement et les demandes CADA qui en résultent.

La plume extérieure du numéro 0 était accordée à Claudine Chassagne, une élue depuis deux ans à Saint Martin d’Uriage qui lutte pour amener des logiciels libres dans sa commune et ailleurs. C'est l'incontournable Tristan Nitot qui reprend la plume, enfin le clavier, pour expliquer en quoi le Libre a changé sa vie et continue de le faire.

Chaque semaine, les journalistes bénévoles ont décidé de mettre en avant un extrait d'un ancien compte rendu d'activité… Pour le numéro 1, du 23 octobre, c'est le groupe Patrimoine mondial crée en 2002 que Laurent Costy, un des vice-présidents de l'April a choisi… Dans le numéro 0, le choix avait été fait de parler de la situation financière de l'association.

Bien sûr, il n'existe pas de journal sans dessin satirique, et c'est Simon "Gee" Giraudot l'auteur de nombreux livres et jeux vidéo (dont Sales Gosses qui vient de sortir) qui s'y colle avec l'intelligence et l'humour qu'on lui connait.

Pour vous faire connaitre les services libres et proposés à tout le monde du Chapril, chaque semaine, un logiciel sera mis en avant. Mumble (conférence audio) et Nextcloud (stockage et partage) pour ces deux premiers numéros, car il faut faire des choix et seuls neuf des quatorze services pourront vous être présentés

Des citations, des anecdotes rigolotes, des informations à savoir et des idées à déconstruire, des paroles de bénévoles ou de personnes salariées sont également proposées. Et des chiffres!

Vous avez plusieurs manières de participer à cette campagne:

• en remplissant la grille de mots croisés
• en gazouillant sur les réseaux sociaux (surtout Mastodon) avec les hashtags #lelamadechaine ou #campagneapril2024. Votre texte apparaîtra dans un des numéros suivants.
• en testant le nouveau service https://bd.chapril.org , en réalisant un dessin (dé)généré et en l'envoyant sur sensibilisation@april.org . Il n'est pas impossible que cette œuvre soit également publiée.

Pour la tranquillité des yeux, un dark mode du site a été mis en place et testé en direct par plusieurs bénévoles.

Tout ce travail pour vous motiver à adhérer à l'April ou à faire un don à l'association.

Télécharger ce contenu au format EPUB

Le site LinuxFr.org utilise divers logiciels libres pour son fonctionnement et ses services : une large majorité provient de projets tiers ( Debian , MariaDB , Redis - version d’avant le changement de licence, nginx , Postfix , conteneurs LXC et Docker , Ruby On Rails , Sympa , etc.) et d’autres composants sont développés pour nos propres besoins. Cette dernière catégorie comprend le code principal du site web en Ruby On Rails, et principalement 5 services autour : le cache d’images img , la tribune board , le convertisseur EPUB 3 epub , le partageur sur les réseaux sociaux share et le convertisseur LaTeX vers SVG svg . Cette dépêche va s’intéresser à img , un code sous AGPLv3.

Elle est née d’une envie personnelle d’expliquer, documenter et montrer ce qui a été fait sur le cache d’images de LinuxFr.org, complétée d’une demande d’un « article technique sur le fonctionnement de ce cache, les choix techniques qui ont été faits, les erreurs commises donc à éviter… ».

Sommaire

• Des images sur le site
• Buts du cache d’images
• À l’utilisation
• Côté code Ruby on Rails
• Côté img
• Historique
• Évolutions récentes
  • Dockerfile
  • La suite de tests
  • L’audit interne
• Le grand nettoyage
• Les problématiques restantes
• Conclusion ?

Des images sur le site

LinuxFr.org vous permet d’utiliser des images externes dans les contenus et commentaires du site. Ces images sont incluses en syntaxe markdown avec ![description textuelle](adresse "titre optionnel") (soit en saisissant directement du Markdown, soit en cliquant sur l’icône d’ajout d’image dans l’éditeur). Profitons-en pour rappeler que pour utiliser une image sur LinuxFr.org, vous devez vous assurer de respecter sa licence .

Nous vous encourageons donc à utiliser des images sous licence libre et à citer les auteurs (c’est même obligatoire pour les licences CC-by et CC-by-sa) . Cette citation est tirée de la dépêche d’annonce Un nouveau reverse-proxy cache pour les images externes sur LinuxFr.org de 2012.

Il est aussi recommandé de mettre une vraie description textuelle, qui finira dans l’ attribut alt de la balise img utilisée pour l’accessibilité ou si l’image ne peut être chargée. Il peut être utile de lui donner un titre qui apparaîtra l’autre du survol de l’image à la souris par exemple.

Exemple :

![Logo LinuxFr.org](https://linuxfr.org/images/logos/linuxfr2_classic_back.png "L’actualité du logiciel libre et des sujets voisins (DIY, Open Hardware, Open Data, les Communs, etc.), sur un site francophone contributif géré par une équipe bénévole par et pour des libristes enthousiastes.")

Buts du cache d’images

Les raisons évoquées à la mise en place de img (sans ordre particulier) :

• la sécurité : si une image externe n’est servie qu’en HTTP (en clair donc) et est appelée au milieu d’une page LinuxFr.org elle-même servie en HTTPS, alors le navigateur va râler sur le mélange des genres. img permet de servir toutes les images identiquement (par exemple en HTTPS, et avec le certificat de LinuxFr.org, via le serveur frontal devant img ). À noter que ces images ne sont pas servies directement depuis le domaine principal linuxfr.org mais depuis un sous-domaine img.linuxfr.org pour éviter que le JavaScript embarqué dans les images en SVG puisse servir de vecteur d’attaque contre le site.
• la protection de la vie privée des personnes visitant LinuxFr.org : seul LinuxFr.org voit les informations en provenance de leur navigateur (dont l’adresse IP). Les équipes d’administration des différents sites ne les voient plus (elles voient l’adresse IP du serveur LinuxFr.org).
• une meilleure gestion du trafic : au lieu d’envoyer tout notre public chercher individuellement chaque image, LinuxFr.org la récupère une fois et la rend disponible. Si le site externe fournissant l’image est un serveur à faibles ressources (liaison ADSL avec faible débit montant par exemple), la mise en cache permet de garantir qu’il ne recevra qu’un faible volume de requêtes (la récupération se faisant initialement toutes les 10 min tant que des demandes arrivent, le cache expirant après 10 min).
• la conservation des images : les images incluses depuis des sites externes peuvent ne plus être disponibles (l’entité a disparu, le serveur a été arrêté, le domaine a été perdu, l’adresse a changé, etc.). Nous avons donc un mécanisme de cache pour que nous puissions continuer à servir une image même si elle devient indisponible.

Parmi les conséquences de cette implémentation initiale, on peut citer :

• si le fichier est changé sur le serveur distant (modifié, converti dans un autre format), l’ancien fichier est servi jusqu’à la prochaine récupération et le nouveau fichier ne sera servi qu’à la prochaine récupération ;
• si le fichier est supprimé sur le serveur distant, l’image ne sera plus servie après la prochaine récupération (car le serveur a répondu que l’image n’existe plus) ;
• il est possible de modifier l’image au passage : les images d’avatar sont retaillées pour une hauteur de 64 pixels par exemple ;
• il est possible de bloquer des images : les images problématiques (pub/spam, contenus pour adultes, images injurieuses, etc.) peuvent être bloquées et ne plus être servies ;
• par ailleurs img n’accepte de servir que les images connues de LinuxFr.org dont le poids fait moins de 5 MiB.

À l’utilisation

Lors de l’écriture d’un commentaire ou d’un contenu sur LinuxFr.org, une personne va ajouter une image externe via la syntaxe Markdown, par exemple ![Logo LinuxFr.org](https://linuxfr.org/images/logos/linuxfr2_classic_back.png)

Ce qui donne à l’affichage :

Et côté code HTML :

<img src="https://linuxfr.org/images/logos/linuxfr2_classic_back.png" alt="Logo LinuxFr.org">

OK, mauvais exemple ce n’est pas une image externe, puisqu’elle est hébergée sur LinuxFr.org justement. Prenons un autre exemple ![April - Campagne d’adhésion](https://april.org/campagne-2024/relais/banniereCampagneApril.svg) .

Ce qui donne à l’affichage :

Et côté code :

<img src="//img.linuxfr.org/img/68747470733a2f2f617072696c2e6f72672f63616d7061676e652d323032342f72656c6169732f62616e6e6965726543616d7061676e65417072696c2e737667/banniereCampagneApril.svg" alt="April - Campagne d’adhésion" title="Source : https://april.org/campagne-2024/relais/banniereCampagneApril.svg">

Donc on sert l’image via le sous-domaine img.linuxfr.org . On peut aussi noter le titre rempli automatiquement avec la source. Expliquons la nouvelle adresse :

• // on sert en https si la page est en https et en http si la page est en http (c’est plutôt un oubli qu’autre chose, vu que le site est uniquement en https)
• img.linuxfr.org on sert depuis un sous-domaine du site
• 68747470733a2f2f617072696c2e6f72672f63616d7061676e652d323032342f72656c6169732f62616e6e6965726543616d7061676e65417072696c2e737667 est la version en texte-vers-hexadécimal de l’adresse d’origine (68 pour h, 74 pour t (deux fois), 70 pour p, etc.). Il existe des sites et des outils en local pour faire cette conversion, mais cela ne concerne pas la simple utilisation du site.
• banniereCampagneApril.svg on met à la fin le nom du fichier pour être sympa si vous voulez sauver l’image en local avec un nom plus explicite

Ceci était le cas où tout se passe bien, comme prévu, comme le voulait la personne qui voulait utiliser une image externe.

Voyons maintenant ce qui se passe dans le cas pas si rare où la personne a donné une adresse d’image invalide, une adresse ne pointant pas vers une image vers autre chose (cas extrêmement fréquent), une image trop grosse (plus de 5 MiB), etc. Il se passe la même chose côté code, mais côté affichage, pas d’image, et on voit seulement le texte alternatif dans son navigateur. Dans les coulisses, img a répondu 404 , cette adresse n’est pas disponible.

On note donc qu’une même image servie en http:// ou en https:// aura une adresse convertie en hexadécimal différente, donc sera vue comme une autre image par img . Même chose si le serveur externe accepte des adresses sans tenir compte de la casse, ou si on rajoute des paramètres dans l’adresse comme « ?mot_magique=merci ».

Côté code Ruby on Rails

Un contenu ou commentaire est en cours de création et une image externe a été mentionnée. Le code de gestion des images va vérifier que l’image est déclarée dans redis (créer l’entrée img/<adresse> avec adresse l’adresse de l’image en clair, ajouter un champ created_at avec l’horodatage, ajouter l’adresse dans la liste des dernières images img/latest ) et renvoyer l’adresse via img .

Le code peut aussi modifier le champ status d’une image dans redis pour mettre ou enlever un blocage (valeur Blocked ) par l’équipe du site, et l’ajouter/enlever de la liste des images bloquées img/blocked .

Côté img

Les schémas dans la documentation du service img explicitent les possibilités et les comportements.

Il est possible de faire un GET /status et on obtient une réponse HTTP 200 avec un contenu OK . C’est utile pour tester que le service est lancé (depuis l’intérieur de la plateforme).

Sinon, on peut envoyer des requêtes GET /img/<adresse_en_hexa> or GET /img/<adresse_en_hexa>/<nom_de_fichier> pour les images, et GET /avatars/<adresse_en_hexa> ou GET /avatars/<adresse_en_hexa>/<nom_de_fichier> pour les avatars.

En se limitant aux requêtes légitimes, le comportement de img est le suivant :

• l’adresse demandée a été précédemment déclarée (dans redis par la partie code Ruby On Rails) sinon il répond 404 ;
• l’adresse demandée n’est pas bloquée par l’équipe du site sinon il répond 404 ;
• l’adresse est déjà dans le cache disque, alors il renvoie l’image ;
• l’adresse n’est pas dans le cache disque et la récupération échoue, il renvoie 404 (et va noter temporairement l’échec dans img/err/<uri> ) ;
• l’adresse n’est pas dans le cache disque et la récupération a lieu (noté temporairement dans img/update/<uri> ): si le serveur répond positivement à la demande, avec une image comme attendue, pas trop volumineuse, alors on la met en cache disque. Si c’est un avatar, on peut retailler l’image. On aura des champs supplémentaires stockés type avec la nature de l’image (en-tête Content-Type ), checksum avec un hachage SHA1 et etag avec la valeur ETag (entête ETag ).

Le cache est rafraîchi régulièrement.

img est un binaire statique en Go. Il offre des options pour définir le couple adresse:port d’écoute, pour définir où envoyer les logs, pour se connecter à une base redis, pour définir le répertoire du cache disque, pour choisir le User-Agent qui sera utilisé pour les requêtes externes, pour définir l’avatar qui sera renvoyé par défaut, et la possibilité de le lancer uniquement en mode audit interne pour vérifier la cohérence et l’état des données et des fichiers.

Dans les logs on va trouver des infos comme :

2024/10/20 20:39:24 Status code of http://example.invalid/exemple1.png is: 404
2024/10/20 20:39:24 Fail to fetch http://example.invalid/exemple1.png (serve from disk cache anyway)
2024/10/20 20:44:12 Fetch http://example.invalid/exemple2.png (image/png) (ETag: "be5e-4dba836030980")
2024/10/20 20:44:12 http://example.invalid/exemple3.png has an invalid content-type: text/html;charset=UTF-8
2024/10/20 20:44:12 Fail to fetch http://example.invalid/exemple3.png (serve from disk cache anyway)

Ici l’exemple 1 est déjà en cache et peut être servi même si on échoue à le récupérer à ce moment-là. L’exemple 2 vient d’être récupéré. L’exemple 3 a désormais une adresse invalide (qui renvoie une page HTML au lieu d’une image) mais il existe en cache une image précédemment récupérée.

Historique

img a été créé par Bruno Michel en 2012. Adrien Kunysz amène 5 commits en novembre 2013, mais globalement Bruno est le seul à travailler dessus (43 commits) jusqu’en 2018. img fait le job et il n’est pas besoin d’y retoucher trop souvent.

En 2022, Bruno quitte l’équipe du site, et par ailleurs il y a des montées de versions et des migrations à faire sur les serveurs de LinuxFr.org, et img fait partie des services à reprendre en main. Ce qui veut dire le comprendre, le documenter et au besoin l’améliorer.

Bref je décide de me plonger dans img (2022-2024), car a priori ce n’est pas le composant le plus compliqué du site (il vit dans son coin, il offre une interface, c’est du Go, donc on a un binaire seulement à gérer).

Étape 1 : je vais commencer par ajouter un Dockerfile permettant de recompiler img dans un conteneur, en contrôlant la version de Go utilisée, en effectuant une détection d’éventuelles vulnérabilités au passage avec govulncheck . Cela me permet de valider que l’on sait produire le binaire d’une part, et que l’on offre à tout le monde la possibilité de contribuer facilement sur ce composant.

Étape 2 : je vais tester le composant pour vérifier qu’il fonctionne comme je le pense et qu’il fait ce qu’on attend de lui. Je vais ajouter une suite des tests qui couvrent les différentes fonctionnalités et les vérifient en IPv4 et en IPv6, en HTTP 1.1 et en HTTP 2.0. Les tests utilisent Hurl et docker-compose (avec des images redis et nginx ), et encore une fois l’idée de donner la possibilité de contribuer facilement. Ils comprennent des tests de types de contenus non pris en charge, le test de la limite à 5 MiB, différents types d’images, le test de vie, des appels erronés (mauvais chemin, mauvaise méthode, etc). Le choix des cas de tests est basé sur le trafic réellement constaté sur le serveur de production, sur les différents cas dans le code et un peu sur l’expérience du testeur.

Étape 2,5 : l’avatar par défaut renvoie sur le site de production, y compris sur les tests en développement en local et sur le serveur de test du site. J’en profite pour ajouter un paramètre pour cela (et cela permettra de passer du PNG au SVG par défaut).

Étape 3 : encore une fois essayons de simplifier la vie d’hypothétiques personnes contributrices. Une petite modification pour que hurl et redis soient fournis via docker-compose et ne soient plus nécessaires sur le poste de développement.

Étape 4 : il est temps de documenter plus le fonctionnement. J’avais déjà décrit les infos stockées dans redis , mais pour comprendre le système de cache, autant fournir des diagrammes pour illustrer ce qui se passe lors d’une requête et comment on passe d’un état à un autre. C’est aussi l’occasion de compléter la suite de tests en ajoutant des tests avant et après expiration du cache, histoire de pouvoir documenter ces cas précis.

Étape 5 : en cas d’échec de récupération, une image était indisponible jusqu’à la prochaine récupération (donc potentiellement pendant 10 min). Autant servir l’ancienne version en cache lorsque cela se produit : je modifie le code et les tests en conséquence.

Étape 6 : je sais que certaines images ont été perdues, que des adresses d’images ont toujours été erronées, que des contenus et commentaires ont été supprimés et qu’il n’y a donc plus lieu de garder les images associées. Je décide d’implémenter dans img un audit interne qui indiquera si des anomalies sont présentes dans redis, si des images sont indisponibles ou si des entrées dans le cache disque ne correspondent plus à aucune image. Et j’ajoute cet audit dans la suite de tests.

Étape 7 : j’écris une dépêche pour parler de tout cela.

Évolutions récentes

Dockerfile

Le fichier Dockerfile du projet permet :

• de partir d’une image officielle Go d’une version donnée, basée sur une distribution minimale Alpine
• de l’utiliser pendant la construction en prenant la liste des dépendances, en les téléchargeant, en prenant l’unique fichier source img.go et en le compilant statiquement avec l’option pour retirer les chemins de compilation
• de rechercher les éventuelles vulnérabilités avec govulncheck
• d’ajouter le paquet tzdata pour avoir les définitions fuseaux horaires (nécessaire pour les conversions de/vers GMT pour les entêtes type Last-Modified ).
• de repartir d’une base Alpine en y mettant les définitions de fuseaux horaires et le binaire issus de la partie construction, de déclarer le port d’écoute et de lancer le binaire avec des variables disposant de valeurs par défaut.

La suite de tests

Pour l’utiliser, c’est assez simple, il faut aller dans le répertoire tests et lancer un docker-compose up --build , qui va produire le conteneur contenant img , et démarrer le redis et le nginx préconfigurés pour les tests. Si tout va bien, on attend, et au bout d’un moment il s’affiche :

linuxfr.org-img-test_1  | All tests look good!
tests_linuxfr.org-img-test_1 exited with code 0

Rentrons un peu dans les détails.

D’abord un fichier docker-compose.yaml qui décrit le réseau IPv4/IPv6 utilisé pour les tests, l’image redis qui sera utilisée (stockage géré par docker), l’image nginx qui sera utilisée avec sa configuration et ses fichiers à servir pour les tests, l’image img et son paramétrage (dont l’accès au redis et au nginx ) ainsi que le répertoire du cache et enfin l’image de la suite de tests qui est construit avec son Dockerfile , prévue pour faire du Docker-in-Docker et avoir accès au cache img et aux fichiers nginx .

Le Dockerfile de tests est basé sur une image Hurl (un outil pour faire des tests HTTP). On ajoute les fichiers de tests en .hurl , le script shell qui pilote le tout, on prévoit d’avoir les paquets dont on aura besoin : bash (pas par défaut dans les Alpine), coreutils , docker et xxd (pour les conversions texte vers hexadécimal). Et on lance les tests par défaut.

La configuration nginx de test écoute en HTTP sur le port 80 en IPV4 et IPv6 et permet de définir des chemins avec des réponses en HTTP 301, 302, 308, 400, 401, 403, etc. jusqu’à 530 et même 666 pour les codes invalides, ainsi qu’une redirection infinie.

Dans les données de tests servies par nginx , on trouve des contenus du mauvais type, une image destinée à être bloquée, des images dans divers formats, une image très grande en pixels mais pas trop en octets, une image trop grande en octets, et un avatar à servir par défaut.

Sont aussi présents cinq fichiers de tests avec une extension en .hurl :

• le test de vie et les chemins hors img/ et avatars/
• les tests sur les avatars : adresse valide ou invalide, image inexistante, bon et mauvais types, comportements sur les différents codes HTTP et sur une boucle de redirection infinie
• les tests sur les images (découpés en trois parties, la partie initiale, la partie entre la récupération initiale et l’expiration du cache et enfin la partie après la récupération et l’expiration du cache.

Vient enfin le script shell qui pilote le tout :

• on définit les variables pour les cibles IPv4/IPv6 et les binaires redis et img que l’on veut utiliser dans les autres conteneurs Docker
• on liste les images dans différentes catégories :
  • celles qui vont échouer et ne comporteront donc qu’une entrée dans redis sans rien dans le cache disque (avec sous-catégories possibles bloquées/non-bloquées)
  • les images devant être en erreur
  • les images qui iront normalement dans le cache
• on prépare des images qui seront altérées plus tard
• on purge le cache sur disque, on nettoie redis et on déclare toutes nos images comme le faire le code Ruby on Rails . Certaines sont déclarées bloquées pour les tests.
• on lance les premiers tests (en IPv4 et IPv6, en HTTP 1.1 et en HTTP 2.0)
• on modifie certaines images pour simuler un changement sur le serveur externe, une suppression sur le serveur externe ou un blocage par l’équipe de site
• on lance les tests post-récupération initiale mais avant l’expiration du cache (toujours avec toutes les variantes)
• on force l’expiration du cache
• on lance les tests post-expiration du cache (toujours avec toutes les variantes)
• si on est arrivé jusqu’ici, c’est qu’on a passé tous les tests Hurl , alors maintenant on recompte ce que l’on a dans redis et sur disque et on vérifie si ça correspond à nos attentes
• on nettoie les images mises volontairement en échec
• on lance le test d’audit interne qui doit nous dire que tout va bien
• si on est arrivé jusque-là on écrit que tout va bien et on déclenche un sourire de satisfaction.

L’audit interne

L’objectif est de vérifier la cohérence des données dans redis , si des images sont indisponibles ou si des entrées dans le cache disque ne correspondent plus à aucune image.

Le binaire d’ img peut donc être appelé en mode audit et lancer des contrôles internes.

D’abord il collecte la liste des fichiers dans le cache disque.

Ensuite il vérifie que toutes les images listées dans les dernières images ( img/latest ) existent comme entrées individuelles.

Puis il vérifie s’il existe des images bloquées (il râlera s’il y en a) et si chacune existe comme entrée individuelle le cas échéant.

Ensuite on parcourt tous les entrées individuelles d’images :

• on râle si on tombe sur une entrée img/updated/ ou img/err/ sans date d’expiration
• on râle si on tombe sur une entrée img/ sans champ created_at , sans type ou d’un type inconnu, sans checksum , avec un statut inconnu, une image bloquée non présente dans les images bloquées, un champ inconnu, une présence inattendue dans le cache disque, etc. Et on marque les images que l’on a vu passer comme attendu dans le cache.
• on râle sur tous les fichiers du cache restants (ne correspondant à aucune image)
• si on a râlé, on renvoie 1, sinon 0

Le grand nettoyage

img a fonctionné pendant 12 ans en production : il a rencontré des bugs, des comportements inattendus, des contenus et commentaires ont été supprimés ou réédités, etc. Il est donc probable qu’il y ait besoin d’aller dépoussiérer un peu tout cela et de retirer ce qui est inutile.

Les traces du grand nettoyage sont d’abord visibles dans la rétrospective de la première quinzaine de septembre 2024 :

• une « image » sur sept présente un souci (n’est pas une image, adresse invalide, trop grosse, etc.) et n’est donc pas dans le cache sur disque (ce qui a conduit à pas mal de taf sur la partie gestion des images)
• les types de contenu ( Content-Type ) en provenance de sites variés et divers, c’est quelque chose… entre les « image/JPEG » ou « image/PNG » en majuscules parce que, les charset=utf-8 ou UTF-8 ou… sur du binaire, les name= qui ne sont pas dans la norme… Wikimedia renvoie aussi du profile=" https://www.mediawiki.org/wiki/Specs/SVG/1.0.0 " (pareil ça semble en dehors de tout standard).

D’abord j’attaque le sujet la fleur au fusil en me disant que ça va passer crème, je fais un joli tableau qui résume l’état initial :

                              img/<uri>   img/updated/<uri>   img/err/<uri>   blocked
total                           25565 -21       634               160            5

no created_at                      23 -23         0                 0            0
created_at                       2857 -3          0                 5            1
created_at+type                   222             0                 0            0
total not in cache               3104 -26         0                 0            0

created_at+type+checksum(+etag) 22463 +5        634               155            4

files in cache                  22778 +5

Donc on a officiellement 25 565 images, mais 23 sont mal créées (état théoriquement impossible hors race condition ), 222 sont incomplètes (état théoriquement impossible race condition ), 22 463 sont attendues en cache et on a 22 778 fichiers dans le cache. Ça part mal. Je nettoie en premier le plus facile (on voit le delta +/- de mes corrections). Et on arrive à une situation où une image sur sept présente alors un souci et il faut gérer un grand volume de corrections à faire.

Parmi les soucis on trouve des types de contenus inattendus ( image/PNG ou image/JPEG avec majuscules, image , des images binaires annoncées avec un charset , des types invalides comme image/jpg au lieu de image/jpeg , etc), des erreurs de notre lectorat (mauvais lien, mauvais copier-coller, lien vers une page web au lieu d’une image), mais aussi des espaces insécables et autres blancs inopportuns, des guillemets convertis, des doubles scheme ( http://https:// ou http://file:// ).

Après cela se cache une autre catégorie encore plus pénible : les images que l’on a en cache, mais qui ne sont plus utiles au site : par exemple celles qui étaient dans des contenus ou commentaires supprimés (notamment le spam), celles qui étaient dans des commentaires ou contenus réédités depuis, etc.

Un problème connu est devenu vite pénible : on n’a pas d’association entre les images externes et les contenus/commentaires concernés. Donc il faut d’abord extraire la liste de toutes les déclarations d’images externes des 12 tables SQL où l’on peut trouver des images et des avatars, sous forme HTML ou Markdown.

Ensuite il faut sortir toutes les entrées dans redis et regarder si on les retrouve en clair ou converties en hexadécimal dans l’extraction SQL.

Et par sécurité on fera une double vérification pour celles détectées en erreur, en relançant une recherche en base (attention à la casse dans la recherche texte).

Au final, on peut supprimer des milliers d’entrées redis et de fichiers dans le cache.

Et un jour l’audit dit :

Connection 127.0.0.1:6379 0
2024/10/19 12:11:21 Sanity check mode only
2024/10/19 12:11:37 Files in cache: 17926
2024/10/19 12:11:39 Total img keys in redis: 18374
OK

Ça aura pris un mois et demi (l’audit a été fusionné le 8 septembre 2024), certes pas en continu, mais ça a été long et guère palpitant de faire ce grand ménage. Et j’ai refait une seconde passe du traitement complet la semaine d’après pour vérifier que tout se passait correctement et que les soucis résiduels après tout ça étaient minimes ou nuls.

Parmi les anecdotes, Web Archive / archive.org a eu sa fuite de comptes utilisateurs et a été indisponible sur la fin (ce qui rendait compliqué la récupération d’images perdues ou leur remplacement par un lien valide par exemple). Et, mentionné dans la rétrospective de la seconde quinzaine de septembre 2024 , un compte de spammeur de 2015 supprimé… mieux vaut tard que jamais : détecté parce que comme beaucoup de visiteurs, le spammeur ne fait pas la différence entre un lien vers un document et l’ajout d’une image.

Les problématiques restantes

Il y a la question habituelle de la montée de versions des dépendances (pour nous actuellement contraintes celles du code Ruby on Rails ) et du remplacement des composants devenus non-libres (migrer vers valkey plutôt que redis ? Questions à se poser sur l’avenir de nginx ?).

On pourrait aussi ajouter la prise en charge du TLS et d’un certificat X.509 directement dans img plutôt que dans un frontal. Mais ce n’est utile que si on les sépare sur deux serveurs distants, ce qui n’est pas le cas actuellement. Donc même si ça ne paraît pas compliqué à faire, ce n’est pas urgent.

Ensuite une entrée de suivi existe pour séparer le cache des avatars du cache des autres images : les contraintes pour le cache des avatars étant différentes de celui des autres images, le stockage en cache devrait être différent. Cela reste un problème mineur. Le changement doit d’abord être fait côté Ruby on Rails pour définir les avatars avec des clés redis différentes (genre avatars/ au lieu de img/). Ensuite on peut modifier img pour séparer le traitement des requêtes HTTP /img/<adresse_hexa> vers les clés redis img/<adresse> et le cache disque des images par rapport aux requêtes /avatars/<adresse_hexa> vers les clés avatars/<adresse> et le cache des avatars. Il faudra aussi déplacer les avatars stockés dans l’actuel cache des images dans leur propre cache. Et là on devrait pouvoir avoir la même adresse dans les deux caches mais avec un rendu éventuellement différent.

Un autre problème concerne la non-association des contenus ou commentaires avec les images externes qu’ils contiennent, ce qui rend l’administration des anciennes images un peu pénible. Le fait que les contenus et commentaires peuvent être réédités ou simplement prévisualisés (donc que des images peuvent être supprimées et d’autres ajoutées) vient compliquer un peu la tâche. Actuellement un ensemble de scripts permettent d’obtenir ces infos et fournissent un contournement, mais ça reste un peu laborieux.

Un cache rafraîchi périodiquement conserve les images pour éviter de surcharger le site d’origine, pas si le site a changé, déplacé ou perdu l’image. La modification pour servir depuis le cache disque en cas d’échec de récupération couvre le cas de la disparition d’une image avec une erreur sur l’adresse, pas celui où le serveur répond une mauvaise image. Il y a donc une autre entrée de suivi images et disparition du web évoquant l’augmentation des soucis sur les images externes avec un cache rafraîchi, en raison des domaines récupérés par des spammeurs et autres pénibles, ou perdus ou utilisés pour du phishing (imageshack.us, après framapic, pix.toilelibre, etc.). Diverses problématiques sont mentionnées comme la perte d’information et donc la diminution de l’intérêt des contenus anciens, la prime aux pénibles du référencement SEO qui pourrissent le net en récupérant les vieux domaines, la modification possible des images publiées. Pour résoudre cela techniquement, ça nécessite de suivre les images et les domaines perdus, et d’intervenir de façon régulière. Ou bien de ne plus rafraîchir le cache (que cela soit jamais, après la publication ou au bout d’un certain temps après la publication). Pour juste éviter la perte d’info, il est possible de remplacer par une image locale récupérée d’une archive du net type archive.org, avec le côté « pénible à faire » et sans garantie que ça soit toujours possible (merci waybackpy ).

Enfin une troisième entrée de suivi suggère l' hébergement des images des dépêches (et éventuellement des journaux) , idéalement en permettant d’avoir une version modifiée d’une image en changeant sa taille. On peut citer en vrac comme problématiques la responsabilité légale, l’éventuelle volumétrie, l’impossibilité de corriger une image publiée facilement par la personne qui l’a soumise, la centralisation et la perte de référencement pour des tiers, l’éventuelle rétroactivité et le traitement de l’historique, le fait qu’il faut traiter tous les autres contenus/commentaires pouvant accueillir des images, etc. Autre question, faut-il différencier les images passées en modération a priori de celles en modération a posteriori ?

Conclusion ?

Bref sans surprise, il reste des problématiques et du code à faire pour les gérer (c’est rare un composant sans demandes d’évolution ou de correction). Yapuka (mais probablement plus tard, il faut aussi partager le temps avec les autres composants, ou avoir plus de contributions).

img apporte les fonctionnalités que l’on attendait de lui même si on pourrait faire mieux. Plonger dans ce composant s’est avéré assez intéressant et formateur (et nécessaire) : techniquement cela a été l’occasion de faire du Go , du docker et du docker-compose , du redis et du nginx , du hurl et de l’HTTP. Et de comprendre ce que faisait un code écrit par une autre personne, de se poser des questions pour choisir les tests et le contenu de la documentation, de se demander pour quelles raisons tel ou tel choix a été fait, de rendre ce composant plus « contribuable », et de compléter le tout de façon détaillée avec une dépêche. Reste à savoir si j’ai répondu à l’attente d’ un article technique sur le fonctionnement de ce cache, les choix techniques qui ont été faits, les erreurs commises donc à éviter… et la réponse est à trouver dans les commentaires.

Télécharger ce contenu au format EPUB

Cette revue de presse sur Internet fait partie du travail de veille mené par l’April dans le cadre de son action de défense et de promotion du logiciel libre. Les positions exposées dans les articles sont celles de leurs auteurs et ne rejoignent pas forcément celles de l’April.

• [Le Monde.fr] Lina Khan, la femme qui fait trembler les Gafam (€)
• [La République] Vie privée, logiciels libres: ce journaliste veut sensibiliser à un usage plus éthique de l'informatique
• [Next] L'Open Source Initiative accuse Meta de polluer la définition de l'IA open source
• [ZDNET] Wordpress: l'écosystème open source s'enfonce dans le conflit

[Le Monde.fr] Lina Khan, la femme qui fait trembler les Gafam (€)

✍ Corine Lesnes, le dimanche 20 octobre 2024.

«L’économie, enjeu d’une Amérique fracturée» (5/5). La présidente de la Federal Trade Commission, l’agence antitrust américaine, combat les grands monopoles. Elle irrite les républicains et participe aux efforts déployés par l’administration Biden pour défendre son action contre l’inflation.

[La République] Vie privée, logiciels libres: ce journaliste veut sensibiliser à un usage plus éthique de l'informatique

Le samedi 19 octobre 2024.

Thierry Pigot, habitant de Samois-sur-Seine et journaliste spécialisé en technologies numériques vient de publier un livre pour simplifier l’informatique du quotidien. Rencontre."> Le directeur général de l’Open Source Initiative (OSI), Stefano Maffulli, critique vertement l’utilisation par Meta du terme «open source» pour qualifier ses modèles d’IA générative Llama. L’OSI attaque Meta alors qu’elle finalise justement sa définition de ce terme employé pour qualifier les modèles d’intelligence artificielle.

Et aussi:

• [Silicon] Définir l'IA open source: avec l'AI Act, ça presse?

[ZDNET] Wordpress: l'écosystème open source s'enfonce dans le conflit

Le mercredi 16 octobre 2024.

Une guerre fait rage depuis plusieurs semaines entre le fondateur du projet Matthew Mullenweg et l’un des principaux fournisseurs de site web Wordpress, WP Engine.

Et aussi:

• [Le Monde.fr] Guerre de contrôle autour de Wordpress, l'un des principaux outils de création de sites Web

Télécharger ce contenu au format EPUB

La dernière dépêche sur le jeu Unvanquished a été publiée ici en 2023, pour son dixième anniversaire . La dernière version annoncée ici était la version 0.53 , en 2022. Alors que nous sommes à deux mois de 2025 et à quelques jours de la prochaine version 0.55, c’est l’occasion de faire un point sur ce qui s’est passé ces dernières années et d’ajouter un épisode à la série « des nouvelles de [votre jeu préféré] » et de faire suite à celui sur Xonotic .

Laisse-moi sortir de là ! — réclame la version 0.55…

Unvanquished est un jeu de stratégie en temps réel ( RTS ) à la première personne ( FPS ) où des extraterrestres évolutifs et des humains lourdement armés s’affrontent pour leur survie. Son développement, basé sur Tremulous , a commencé en 2011.

Sommaire

• Quelques nouvelles en vrac
  • Un nouveau lanceur
  • Des améliorations graphiques
  • Un explorateur de serveur minimaliste
  • Des vidéos et un compte Mastodon
• Unvanquished, ARMé et dangereux
  • De nouvelles architectures
  • Interface, jouabilité et bots
  • La danse des submodules
  • Contributions
  • Des traductions !
• La 0.55 arrive !

Quelques nouvelles en vrac

Un nouveau lanceur

En prévision de la prochaine version 0.55 qui arrive (deux « release candidates » ont déjà été publiées ), le « lanceur » (aussi appelé « updater ») a été mis à jour en juillet dernier.

Le lanceur est le moyen recommandé d’installer Unvanquished : il permet une intégration optimale avec le système (possibilité de cliquer sur des liens pour lancer une partie) et propose la mise à jour du jeu quand une nouvelle version est disponible. Le lanceur sait aussi se mettre à jour et c’est ce qui a été fait en juillet.

Des améliorations graphiques

L’année dernière le projet Unvanquished avait annoncé être en recherche d’un développeur spécialisé dans les moteurs de rendus. Reaper a rejoint l’équipe et a réalisé un gros travail : débugage et finalisation des miroirs récursifs et d’autres choses. Il fait aussi progresser le moteur pour tirer partie d’OpenGL 4.6 et autre techniques avancées (« bindless textures », etc.).

Un explorateur de serveur minimaliste

Viech a publié un explorateur de serveur de jeu minimaliste qui tient dans la barre de notification ( tray browser ). C’est à la fois simple et pratique.

Des vidéos et un compte Mastodon

Diverses vidéo montrant les avancées du développement ont été publiées sur la chaîne Youtube d’Unvanquished, c’est l’occasion de rappeler l’existence de cette chaîne : https://www.youtube.com/@UNVofficial

Pour ceux qui préfèrent Peertube, qui permet aussi de s’abonner aux chaînes à travers Mastodon et plus globalement le Fédiverse, avec la publication de certaines parties : https://vdo.unvanquished.greboca.com/

Un compte Mastodon a été créé sur l’instance idtech.space dédiée aux technologies id Tech et projets associés (le moteur d’Unvanquished dérive d’id Tech 3) : https://idtech.space/users/UNVofficial

Ce compte Mastodon s’ajoute aux comptes X et Facebook . Le public libriste sera peut-être plus intéressé par ce compte Mastodon.

Unvanquished, ARMé et dangereux

De nouvelles architectures

La version 0.54 de Unvanquished sortie en janvier 2023 avait été la première à être jouable autrement que sur PC (x86 et x86-64), en proposant des binaires pour les processeurs ARM (sous Linux seulement pour l’instant).

Côté moteur la version 0.54 avait reçu de nombreuses optimisations pour mieux tourner sur des machines moins performances, par exemple, Certaines ressources logiciels optionnelles comme les deluxemaps ne sont plus chargées si désactivées, ceci économise non seulement le calcul, mais aussi la mémoire de la carte graphique. Les lightstyles peuvent être désactivés, ce qui peut accélérer le rendu graphique, etc. La compatibilité matérielle sera encore étendue avec la version 0.55.

À partir de la version 0.54 tous les binaires pour toutes les architectures matérielles et systèmes d’exploitation sont compilés dans des containers Docker, y compris les binaires macOS compilés dans un container Linux en utilisant Darling , Darling étant à macOS ce que Wine est à Windows. La version 0.55 sera produite de la même manière.

La version 0.55 apportera la compatibilité pour un nouveau système d’exploitation ! 🤫️

Interface, jouabilité et bots

Le nouvel écran de chargement des cartes.

L’interface avait été revue à l’occasion de la version 0.54 :

• Nouvelles icônes d’inventaire contribuées par Nanaa, Gireen et Bob Vador
  Ces icônes donnent un coup de fraîcheur, on distingue mieux les deux types de grenades et les armures ainsi que le mode de déplacement.
• L’écran de chargement des cartes affiche le nom de la carte et des auteurs (si renseigné) depuis les métadonnées. Historiquement, les artistes inscrivaient ces informations sur l’image d’illustration de la carte avec un logiciel de dessin… (!!!)
• La version 0.55 apportera des modifications d’interface réalisées par Grise.

Côté jouabilité, la version 0.54 avait corrigé le momentum négatif qui était particulièrement pénalisant. Le momentum , est généré par les Leech (Alien) ou les Drills (Humain). Il faut qu’il y ait assez de momentum pour pouvoir construire d’autres éléments.

La version 0.54 a apporté toute une série de nouveautés au niveau des bots (entités qui remplacent les joueurs afin de compléter les équipes) :

• Amélioration de l’évitement d’obstacles pour les bots.
• Les bots peuvent viser des cibles situées sur des navmesh différents.
• Certains bots n’hésiteront pas à sauter pour atteindre une cible en hauteur, d’autres se retiennent d’exécuter une attaque qui pourraient les blesser si la cible est trop proche…

Depuis quelque temps, le développement des bots suscite un regain d’intérêt. La version 0.55 ne sera pas la plus riche à ce sujet car elle apportera surtout des améliorations du moteur. Le développement de gameplay ne s’est pas ralenti mais s’est surtout focalisé sur des mods dont il faudra fusionner les avancées dans le tronc commun après la sortie de la version 0.55. Ces améliorations de gameplay sont déjà jouables sur des serveurs en ligne.

L’amélioration du comportement des bots à permis un nouveau type de jeu : Le PVE. C’est à dire que les joueurs peuvent jouer ensemble contre l’ennemi piloté par le serveur. Certaines cartes ont été créées spécifiquement pour ce type de jeu, et d’autres ont été adaptées à l’aide de layout qui étaient déjà utilisés pour créer des variantes de parties.

La version 0.54.1 n’avait pas vraiment proposé de modifications des données, il s’agissait surtout de publier des correctifs de bugs gênant du moteur. La version 0.55 viendra avec une mise à jour des données et donc avec les corrections attendues. Par exemple un bug dans la chaîne logicielle de conversion d’images avait produit des artefacts dans certaines textures, ce sera corrigé dans la version 0.55.

La danse des submodules

            _________________
           /                 \
          |         ✝         |  
          |                   |
          |      beloved      |
          |     submodule     |
          |                   |
          |    2017-12-30     |
          |     2023-04-11    |
          |                   |
          |       R.I.P.      |
          |                   |  🄵
  (,,)é   |                   |   ɘ̀(⹁⹁)  ɘ̀(⹁⹁)
////////////////////////////////////////////////

Press F to Pay Respects!

Tous ceux qui doivent traiter avec Git savent que les submodules sont très pratiques mais parfois bien ennuyeux. Un travail de fond réalisé sur les outils de production des données a permis la réintégration du dossier source unvanquished_src.dpkdir . Le générateur de code CBSE qui produit la plomberie pour la logique de jeu a été réintégré aussi. Cela rend plus facile de travailler sur des mods en évitant de devoir gérer plusieurs dépôts différents.

Contributions

Voulez-vous en savoir plus ?

Comme vous le voyez, ce cycle de développement a aussi vu de nouveaux contributeurs apporter leur concours au projet. Certaines de leurs améliorations ont déjà été publiées dans la version mineure 0.54.1, d’autres arriveront avec la version 0.55.

Récement, le développeur Slipher qui est un des développeurs Unvanquished les plus prolifiques et les plus fidèles a étendu ses activités au moteur de rendu et a rejoint la petite élite de ceux qui savent comment le moteur fonctionne. Il a corrigé entre autre le rendu de vidéo sur des surfaces et une fonctionnalité de sprites.

La liste de régressions depuis le désormais lointain ancêtre d’Unvanquished, Tremulous, est maintenant réduite à peau de chagrin.

Des traductions !

La grosse nouveauté de la version 0.54.1 publiée en décembre 2023 a été de proposer à nouveau des traductions intégrées au jeu. L’outil de traduction est gracieuseuement hébergé par Weblate .

L’interface de traduction Weblate.

Il y a longtemps, le jeu était traduit, mais suite à de très profonds changements (par exemple le remplacement total de la technologie utilisée pour faire des menus, désormais sous RmlUi ), l’effort de traduction avait été interrompu.

La traduction francophone est bien avancée, mais la traduction en breton a besoin de plus de contributions. Si vous souhaitez contribuer votre langue régionale, vous êtes les bienvenus, c’est ici que cela se passe !

La 0.55 arrive !

Préparez votre souris et votre clavier, la version 0.55 arrive très bientôt.

Télécharger ce contenu au format EPUB