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).

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.

Scenari est un ensemble de logiciels open source dédiés à la production collaborative, publication et diffusion de documents multi-support. Vous rédigez une seule fois votre contenu et vous pouvez les générer sous plusieurs formes : site web, PDF, OpenDocument, diaporama, paquet SCORM (Sharable Content Object Reference Model)… Vous ne vous concentrez que sur le contenu et l’outil se charge de créer un rendu professionnel accessible et responsive.

À chaque métier/contexte son modèle Scenari :
* Opale pour la formation
* Dokiel pour la documentation
* Optim pour les présentations génériques
* Topaze pour les études de cas
* …

🖥️ Prochain mini-webinaire : « Les outils Scenari pour traduire ses contenus » 15 octobre

La session aura lieu le mardi 15 octobre de 17h à 18h heure de Paris, à l’adresse https://scenari.org/visio/miniwebinaire.

Pour que la session colle au mieux aux besoins de la communauté, tu peux participer à ce fil de discussion sur le forum.

Les sessions précédentes sont sur la page dédiée de scenari.org et dans notre canal peertube.

📣 Tu utilises les « type de » dans Opale 24 ?

On va organiser un mini-webinaire sur l’usage de ces nouveaux et mystérieux objets dans Opale 24 : les « Type De ».

Tu les utilises et tu pourrais expliquer ton usage à la communauté ? Alors écris à direction@scenari.org.

📣 Sortie de la première version stable de Parcours

La première version stable de Parcours vient de sortir : Parcours 1.0.2.

Parcours est une chaîne éditoriale SCENARI qui assiste la création de parcours de formation en outillant la conception de conducteurs pédagogiques et l’exécution des sessions de formation. Elle est mise à disposition sous la forme d’une application utilisable en mode local (desktop), sur ton ordinateur.

Parcours est maintenant également disponible dans Platine-suite (solution serveur en version beta). Dans l’optique de finaliser Platine-suite, Kelis — qui développe la solution — propose un hébergement gratuit, pour ceux et celles qui veulent l’expérimenter en contexte réel.

📣 Parcours PHP : des fonctionnalités serveur, sans installer un serveur

Parcours PHP est une publication du modèle Parcours quipermet de générer un site web autonome, sans avoir à configurer une solution serveur SCENARI complète.

Parcours PHP propose une base de données qui permet d'inscrire des utilisateurs, stocker les scores et les avancées dans un exercice SCORM, et le téléversement des devoirs et des corrections.

📣 Nouvelles versions de modèles Scenari

OPALE : nouvelle version Opale 24.1.0 .

Cette version apporte :

• De nombreuses corrections dans les publications Exerciseur ;
• Des corrections dans l’habillage par défaut Daylight ;
• L’ajout de deux nouvelles options à la barre d’accessibilité de la publication Web : Titres numérotés & Titres à l’échelle ;
• L’ajout de la barre d’accessibilité au générateur Diaporama ;

Tous les détails sur le forum.

DOKIEL : nouvelle version (corrections dans la Documentation de référence) Dokiel 6.0.8. Elle est disponible dans quatre langues: Français, Anglais, Portugais, Italien.

LEXICO : nouvelle version Lexico 3.0.3. Cette version apporte surtout une correction dans le choix des termes à inclure dans un lexique : Seuls les termes explicitement inclus dans la requête sont inclus dans les « Liens vers d’autres termes ».

TECHNOPALE (modèle destiné à l’enseignement des sciences expérimentales dans le secondaire) : nouvelle version TechnOpale 5.0.7 dérivé d’Opale 5.0.7. Cette mise à jour est accompagnée des habillages graphiques Aurora Dys et Daylight Mint. Tous les détails sur le forum.

📣 Nouvelles versions des outils Scenari

SCENARI : nouvelles versions de maintenance (corrections fonctionnelles et sécuritaires) de :

• SCENARI 6.3 (6.3.6) (SCENARIbuilder 6.3, SCENARIchain-desktop 6 et SCENARIclient 6 doivent automatiquement proposer la mise à jour vers cette nouvelle version). Consulte le post sur le forum si tu as des question.
• SCENARI 6.0 (6.0.11), SCENARI 6.1 (6.1.13) et SCENARI 6.2 (6.1.5). Consulte le post sur le forum si tu as des questions.

MYSCENARI : mise à jour en version 6.3.11. Si tu utilises le client, pense à déclencher la mise à jour qui doit être proposée au prochain lancement.

LTI-SUITE : nouvelle version de maintenance LTI-suite 1.0.1. Pour rappel LTI-suite est un serveur qui permet de stocker des contenus accessibles par les plateformes d’apprentissage (LMS). LTI-suite enregistre les données d’apprentissage et propose des rapports détaillés de suivi des apprenants.

LTI-suite 1.0 est un projet en phase beta. Kelis est intéressé par tes retours éventuels afin de finaliser la version.

📣 Appel à volontaires pour traduire les outils Scenari

Tu maîtrises une autre langue que le français ?

Tu peux dédier un peu de temps à la communauté Scenari ?

Alors tu peux nous aider à traduire les outils Scenari !

C’est simple et chacun⋅e peut le faire à son rythme.

Envoie un message à direction@scenari.org, et on voit comme tu peux donner un coup de main aux traductions.

✨ Le savais-tu ?

Dans l’éditeur Scenari, lorsque l’on crée un bloc dans lequel un item doit être référencé, si on laisse la souris sur l’icone de la petite feuille, une popup indique quels sont les différents types d’items que l’on peut y mettre.

Très pratique pour mieux connaître un modèle et faciliter la réutilisation.

Tu peux retrouver cette astuce, et beaucoup d’autres, sur le forum.

Les deux parties précédentes ont présenté les principales évolutions dans le code de Haiku. Mais le code ne fait pas tout.

Cette troisième (et dernière) partie présente les nouveautés dans la documentation, ainsi qu’un court aperçu du rapport financier et aux dons qui permettent à Haiku d’employer un développeur à plein temps de façon durable.

Enfin, elle présente la participation au Google Summer of Code et les travaux réalisés par les cinq étudiants encadrés par Haiku cette année.

Sommaire

• Documentation
  • Documentation d’API
  • Documentation interne
• Un point sur le financement
• Google Summer of Code
  • Calisto Mathias — Re-design de la fenêtre de recherche de fichiers
  • Daniel Martin — Virtualisation matérielle accélérée avec NVMM
  • Diego Roux — Pilote pour les cartes sons virtuelles VirtIO
  • trungnt2910 — Portage de GDB
  • Zardshard — Migration du navigateur web WebPositive vers WebKit2

Documentation

La documentation de Haiku se découpe en 3 parties principales : un manuel de l’utilisateur, une documentation d’API, et une documentation interne pour les développeurs qui travaillent sur les composants du système.

Ces documents sont complétés par de nombreuses pages et articles sur le site Internet, et deux livres pour apprendre à programmer en C++ avec Haiku, ou encore un document de référence pour la conception d’interfaces graphiques et un autre pour le style graphique des icônes.

Documentation d’API

La documentation d’API de BeOS était assez complète et de bonne qualité. L’entreprise Access Co Ltd qui a hérité de la propriété intellectuelle de BeOS a autorisé le projet Haiku à la réutiliser et à la redistribuer. Malheureusement, cette autorisation est faite avec une licence Creative Commons n’autorisant pas les modifications. Cette documentation ne peut donc pas être mise à jour, ni pour corriger les erreurs, ni pour ajouter des informations sur toutes les nouvelles fonctions ajoutées par Haiku ou les différences entre les deux systèmes.

Il est donc nécessaire de réécrire une nouvelle documentation à partir de zéro. Ce travail est assez ingrat lorsqu’il s’agit de re-décrire ce qui est déjà très bien expliqué dans la documentation existante. La nouvelle documentation a donc tendance à se concentrer sur les nouvelles fonctions, et il faut souvent jongler entre les deux documentations, le contenu des fichiers .h, et des exemples de code d’applications existantes pour découvrir toutes les possibilités offertes.

Il ne semble pas utile de lister chaque fonction ou méthode qui a été documentée. On peut mentionner une page d’explications sur la bibliothèque C standard, comprenant des liens vers les spécifications POSIX qui documentent déjà la plupart des choses, et quelques détails sur les différences avec d’autres systèmes.

Une autre nouvelle page documente les primitives de synchronisation qui sont disponibles pour le code s’exécutant dans le noyau.

Documentation interne

La documentation interne était à l’origine simplement une accumulation de fichiers dans divers format dans un dossier « docs » du dépôt Git de Haiku. Depuis 2021, ces fichiers ont été rassemblés et organisés à l’aide de Sphinx, qui permet de mettre à disposition une version navigable en HTML et de donner une meilleure visibilité à ces documents.

D’autres pages sont petit à petit migrées depuis le site web principal de Haiku, qui n’est pas un très bon support pour de la documentation, et bénéficiera un jour d’une refonte pour être plus tourné vers les utilisateurs que vers les développeurs.

Quelques nouvelles pages ajoutées cette année:

• Une documentation sur l’utilisation de divers outils de complétion de code automatique avec le code source de Haiku
• Une page présentant l’organisation du code source et les principaux dossiers et sous-dossiers
• La documentation de l’outil rc utilisé pour compiler les « resources » attachées aux exécutables a été intégrée
• Le système de fichier FAT a reçu également une page de documentation à l’occasion de sa réécriture

Un point sur le financement

L’association Haiku inc qui gère le compte en banque de Haiku publie chaque année un rapport financier.

Le financement provient principalement de dons des utilisateurs et soutiens de Haiku. Le projet reçoit également une compensation financière de Google pour le temps passé à encadrer les participants du Google Summer of Code (voir le paragraphe suivant). La contribution de Google cette année est de 3 300$.

Les plateformes de don les plus utilisées sont Paypal et Github sponsor. Ce dernier est recommandé car, pour les dons reçus via Github, c’est Microsoft qui paie les frais bancaires de la transaction. 100% de l’argent donné arrive donc sur le compte de Haiku. Tous les autres opérateurs ont un coût, soit fixe lors des retraits, soit un pourcentage de chaque don, soit un mélange des deux.

En 2023, l’association a reçu 25 422$ de dons et a dépensé 24 750$. Elle dispose d’une réserve confortable de 100 000$ (accumulés avant 2021, alors qu’il n’y avait pas de développeur salarié) ainsi que d’environ 150 000$ en cryptomonnaies.

Les dons en cryptomonnaies sont pour l’instant bloqués sur un compte Coinbase suite à des problèmes administratifs (le compte n’est pas correctement déclaré comme appartenant à une association, il faudrait donc payer un impôt sur le revenu lors de la conversion en vraie monnaie). Il semble difficile de contacter Coinbase pour régler ce problème.

Du côté des dépenses, le poste le plus important est le paiement de 21 000$ à Waddlesplash, développeur employé par Haiku inc pour faire avancer le projet Haiku. Il travaille à temps partiel et avec un salaire très bas par rapport au marché, comme cela a été fait pour les précédents contrats entre Haiku inc et d’autres développeurs. Les finances de l’association ne permettent pas encore d’assurer un emploi à plein temps avec un salaire correct sur le long terme (c’est faisable sur le court ou moyen terme à condition de puiser dans les réserves de trésorerie).

Le reste des dépenses concerne principalement le paiement de l’infrastructure (serveurs pour le site Internet, l’intégration continue, hébergement cloud pour les dépôts de paquets) pour environ 3 000$.

Il faut enfin compter environ 500$ de frais Paypal, puis quelques dépenses administratives (déclaration de changement d’adresse de l’association, déclaration d’embauche) pour des montants négligeables (moins de 10$ au total).

En 2024, l’objectif fixé en janvier était de récolter 20 000$ de dons supplémentaires. Cet objectif a été atteint dès le mois de juillet, et a donc été révisé pour tenter d’atteindre les 30 000$. Cela permettra de rémunérer Waddlesplash pour un plus grand nombre d’heures cette année, ou bien d’envisager l’embauche d’une deuxième personne si un ou une candidate se présente parmi les personnes contribuant au projet (l’embauche d’une personne extérieure ne se fera pas tant que l’association ne peut pas se permettre de proposer une rémunération raisonnable).

Google Summer of Code

Haiku participe au Google Summer of Code depuis 2007. Il s’agit d’un programme où des étudiants (et d’autres participants pas forcément étudiants, ces dernières années) sont payés par Google pendant deux mois pour découvrir la contribution à des projets de logiciels libres.

Ce programme a été monté par « l’Open source program office » de Google. Leur intérêt est de défendre leur image d’entreprise sympathique (bien mise à mal ces dernières années, c’est devenu un géant de la publicité en ligne et de l’aspiration des données personnelles), et de contribuer à la richesse d’un écosystème de logiciels libres dont ils bénéficient beaucoup. Cela permet aussi d’encourager des personnes à s’essayer au développement logiciel, facilitant indirectement le recrutement chez Google en augmentant le nombre de candidats. Ces justifications peuvent sembler hypothétiques ou très indirectes, mais elles ont convaincu Google d’attribuer un budget de quelques millions de dollars à ce programme.

Une équipe de Google choisit les projets de logiciel libres participants parmi de nombreuses candidatures. Chaque projet participant propose une liste « d’idées » (un peu sous la forme d’un sujet de stage) et a ensuite la responsabilité de choisir parmi les candidats qui ont répondu à cette offre (en respectant les critères de non-discrimination imposées par Google ainsi que les embargos imposés par les USA), et d’assurer l’encadrement des personnes sélectionnées. Google rémunère les participants, et dédommage les projets participants pour le temps investi.

Cette année les développeurs de Haiku encadrent cinq participants :

Calisto Mathias — Re-design de la fenêtre de recherche de fichiers

Le système de fichier BFS utilisé par Haiku permet l’exécution de requêtes (comme une base de données) exploitant les attributs étendus des fichiers, qui peuvent être indexés.

Ce système permet de faire beaucoup de choses, et la fenêtre de recherche du navigateur de fichier essaie d’en tirer parti. Cependant, l’interface résultante est trop complexe, et peu de personnes prennent le temps de concevoir des requêtes améliorant leur façon de travailler, se cantonnant aux quelques exemples fournis.

L’objectif de ce projet est de refondre l’interface de cette fenêtre pour obtenir quelque chose de plus intuitif, et également d’afficher en temps réel les résultats de la requête dès qu’elle est modifiée, pour encourager les utilisateurs à expérimenter avec des requêtes plus complexes.

Daniel Martin — Virtualisation matérielle accélérée avec NVMM

Haiku n’est pas encore parfait, et certaines tâches nécessitent encore l’utilisation d’autres systèmes d’exploitation. Une partie des utilisateurs ont donc une configuration en double boot, ou bien lancent Haiku dans une machine virtuelle.

L’objectif de ce projet est de permettre d’utiliser Haiku comme système principal, et de lancer les autres systèmes dans des machines virtuelles. Cela sera réalisé à l’aide d’un portage de NVMM, qui a été développé à l’origine par NetBSD et Dragonfly BSD. Cette bibliothèque a l’avantage d’être bien documentée et conçue pour faciliter son adaptation vers d’autres systèmes.

NVMM sera complétée par l’utilisation de QEMU qui pourra fournir un « front-end » à cette mécanique.

Diego Roux — Pilote pour les cartes sons virtuelles VirtIO

Pour les personnes utilisant Haiku dans une machine virtuelle, il est intéressant d’utiliser autant que possible la famille de périphériques VirtIO.

Il s’agit de périphériques virtuels conçus sans s’inspirer de matériel existant, et plutôt pour avoir l’interface la plus simple possible entre la machine virtualisée et son hôte.

Haiku dispose déjà d’un jeu de pilote Virtio relativement complet (réseau, stockage de masse, affichage graphique). Le but de ce projet est de compléter cet ensemble avec un pilote pour les cartes son VirtIO.

trungnt2910 — Portage de GDB

Haiku dispose de son propre débugger (appelé Debugger, de façon assez peu originale). Ce dernier présente une interface graphique confortable, mais une interface en ligne de commande beaucoup plus limitée. Il souffre également de quelques problèmes de performances et d’un manque de prise en charge des fichiers exécutables et bibliothèques compilés avec autre chose que GCC. Il est également incapable de faire du debug à distance ou de s’intégrer dans une interface graphique existante (par exemple au sein d’un IDE).

L’objectif de ce projet est de ressusciter la version de GDB ciblant Haiku. Cette version très ancienne était utilisée avant l’apparition du Debugger natif. Le projet est en bonne voie, le code d’interfaçage a été entièrement réécrit pour s’adapter aux versions modernes de GDB, et plusieurs évolutions et corrections ont été intégrées dans le système de debugging de Haiku (par exemple, pour mettre en pause tous les threads nouvellement créés afin que le debugger puisse les intercepter).

Zardshard — Migration du navigateur web WebPositive vers WebKit2

Le navigateur WebPositive utilise le moteur de rendu webKit. Actuellement, il s’interface avec ce moteur via l’API WebKitLegacy. Cette API exécute tout le moteur de rendu web dans un seul processus, et ne fournit pas les garanties d’isolation nécessaires pour les navigateurs web modernes (que ce soit en termes de sécurité, ou en termes de fiabilité).

L’objectif de ce projet est de reprendre les travaux déjà entamés en 2019 pour migrer WebPositive vers la nouvelle API « WebKit2 », et bénéficier d’une séparation entre l’interface graphique, la communication réseau, et le rendu HTML/CSS/JavaScript dans des applications séparées. Ainsi, un crash d’un de ces composants peut être récupéré de façon transparente sans faire disparaître toute l’application (et les données non enregistrées de l’utilisateur avec).

Le projet est également en bonne voie, un navigateur de test permet déjà d’afficher quelques pages ce qui montre que les bases sont en place. Il reste à régler de nombreux problèmes de rendu de texte, ainsi qu’à implémenter la gestion des entrées (clavier et souris) pour avoir un navigateur web utilisable. Il faudra ensuite migrer WebPositive vers ces nouvelles APIs.

Haiku est un système d’exploitation libre destiné aux ordinateurs personnels ou de bureau (pas de serveurs, pas de systèmes embarqués, pas de tablettes ni de téléphones). Il s’agit au départ d’une réécriture libre de BeOS, préservant la compatibilité binaire avec ce dernier (les applications BeOS peuvent tourner sur certaines versions de Haiku).

Le projet Haiku (au départ nommé OpenBeOS) a démarré officiellement le 18 août 2001 avec le premier message sur la liste de diffusion : Ok, let's start (OK, allons-y). Cet anniversaire est l’occasion de faire un point sur les développements de l’année dans Haiku et ce qui est en préparation.

La dépêche a été un peu retardée cette année, pour être synchronisée avec la version R1 bêta 5 de Haiku, publiée le vendredi 13 septembre 2024.

Le projet emploie un développeur presque à plein temps depuis 2021 et le reste de l’équipe contribue bénévolement. La dernière version bêta a été publiée fin 2023 et la Bêta 5 est désormais disponible : l’occasion de revenir en trois parties sur ce que propose Haiku, d’abord des applications, un noyau et des améliorations de la documentation.

Sommaire

• Applications
  • AboutSystem
  • CharacterMap
  • CodyCam
  • Debugger
  • Deskbar
  • GLTeapot
  • HaikuDepot
  • Icon-O-Matic
  • Magnify
  • MediaPlayer
  • PowerStatus
  • SerialConnect
  • ShowImage
  • Terminal
  • Tracker
  • TV
  • WebPositive
  • Zip-O-Matic
  • Haikuports
    • Applications natives
    • Applications portées
• Panneaux de préférences
  • Appearance
  • Keymap (disposition clavier)
  • Screen (Affichage)
• Outils en ligne de commande
  • df
  • filteredquery
  • ping, traceroute, telnet, ftpd
  • pkgman
  • strace
  • whence
• Serveurs
  • app_server
  • input_server
  • registrar
• Kits
  • Interface
    •  BColumnListView
    • BTextView
    • BMenu
    •  BSpinner
    • rgb_color
  • Locale
  • Media
  • Support
    • BDataIO
• Bibliothèques C
  • Libroot
  • Libnetwork
  • LibBSD
  • LibGNU

Près de 350 tickets ont été clos dans le cadre du travail sur la version R1 bêta 5. Il y a bien sûr de très nombreuses corrections de bugs, qui ne seront pas listées dans cet article. On se concentrera plutôt sur les nouveautés, sauf dans les cas où la correction est vraiment importante ou permet d’ouvrir de nouvelles possibilités d’utilisation.

Applications

Haiku est un système d’exploitation complet, fourni avec un certain nombre d’applications permettant d’accomplir les tâches les plus courantes. En plus de ces applications de base, le gestionnaire de paquets HaikuDepot, alimenté principalement par le travail du projet HaikuPorts, apporte à la fois des applications portées depuis d’autres systèmes et des applications développées spécifiquement pour Haiku.

De façon générale, on trouve cette année dans les applications de Haiku des améliorations sur le rendu des nombres, l’utilisation d’un symbole de multiplication à la place d’une lettre x là où c’est pertinent, et de nombreuses petites corrections et améliorations sur la mise en page des fenêtres, des corrections de problèmes de traduction et ainsi de suite.

AboutSystem

AboutSystem est la fenêtre d’information sur le système Haiku. Elle fournit quelques informations sur la machine sur laquelle le système fonctionne (quantité de RAM, marque et modèle du CPU, uptime) ainsi que les noms des développeurs et autres logiciels libres ayant participé au développement de Haiku.

Cette application reçoit tout d’abord une mise à jour cosmétique : si le système est configuré en « mode sombre », le logo Haiku correspondant (avec un lettrage blanc et des dégradés de couleurs un peu différents) sera utilisé. Sinon, ce sera le logo avec lettrage noir.

Elle reçoit également quelques mises à jour de contenu : en plus de l’ajout de quelques nouveaux contributeurs qui ont rejoint le projet, on trouvera maintenant un lien vers la page web permettant de faire un don à Haiku. Plusieurs liens vers des bibliothèques tierces utilisées dans Haiku, qui ne fonctionnaient plus, ont été soit supprimés, soit remplacés par des liens mis à jour.

Enfin, il est désormais possible d’utiliser AboutSystem comme un « réplicant », c’est-à-dire de l’installer directement sur le bureau pour avoir en permanence sous les yeux les statistiques sur l’utilisation mémoire et l’uptime ainsi que le numéro de build de Haiku en cours d’exécution (ce qui peut être utile par exemple lorsqu’on lance beaucoup de machines virtuelles avec des versions différentes de Haiku pour comparer un comportement, ou si on veut stocker des captures d’écran de plusieurs versions et s’y retrouver facilement).

CharacterMap

L’application « table de caractères » permet d’étudier de près les différents glyphes et symboles présents dans une police de caractères. En principe, elle permet de choisir une police spécifique, mais le serveur graphique de Haiku substitue automatiquement une autre police si on lui demande d’afficher un caractère qui n’est pas disponible dans la police demandée.

Cela peut être gênant dans certains contextes, par exemple si on envisage d’embarquer une police dans un fichier PDF, il est difficile de savoir quelle police contient vraiment les caractères qu’on veut utiliser.

L’application a été améliorée pour traiter ce cas et affiche maintenant ces caractères en grisé.

CodyCam

CodyCam est une application permettant de tester une webcam et de l’utiliser pour envoyer périodiquement des images vers un serveur HTTP.

L’évolution principale a été la mise à jour de l’icône de l’application. L’utilité de CodyCam est limitée par le manque de pilotes : il faudra soit trouver une webcam Sonix du début des années 90, seul modèle USB à disposer d’un pilote fonctionnel, soit utiliser un ordiphone Android équipé d’un logiciel permettant de le transformer en caméra IP (ou encore une vraie caméra IP).

Le pilote pour les WebCams UVC — standard utilisé pour les caméras USB modernes — n’est pas encore au point et n’est pas inclus dans les versions publiées de Haiku.

Debugger

Debugger est, comme son nom l’indique, le debugger de Haiku. Il est développé spécifiquement pour le projet sans s’appuyer sur les outils existants (gdb ou lldb). Il dispose à la fois d’une interface graphique et d’une interface en ligne de commande, plus limitée. Cette dernière est surtout utilisée pour investiguer des problèmes dans les composants de Haiku qui sont nécessaires pour l’utilisation d’une application graphique : app_server, input_server ou encore registrar.

La version en ligne de commande a reçu quelques petites améliorations, mais la principale nouveauté est la prise en charge des formats DWARF-4 et DWARF-5 pour les informations de debug. Cela permet de charger les informations générées par les versions modernes de GCC, sans avoir besoin de forcer la génération d’une version plus ancienne du format DWARF.

Le désassembleur udis86, qui n’est plus maintenu et ne reconnaît pas certaines instructions ajoutées récemment dans les processeurs x86, a été remplacé par Zydis.

Enfin, un bug assez gênant a été corrigé : si une instance de Debugger était déjà en train de débugger une application et qu’une deuxième application venait à planter, il n’était pas possible d’attacher une deuxième instance de Debugger à cette application. Les problèmes impliquant plusieurs processus pouvaient donc être un peu compliqués à investiguer. C’est maintenant résolu.

Deskbar

L’application DeskBar fournit la « barre des tâches » de Haiku. Elle permet de naviguer entre les fenêtres et applications ouvertes, de lancer de nouvelles applications via un menu (similaire au « menu démarrer » de Windows), ou encore d’afficher une horloge et des icônes fournis par d’autres applications (sous forme de réplicants).

Elle fait partie, avec le Tracker, des applications qui ont été publiées sous license libre lors de l’abandon de BeOS par Be Inc.

Quelques changements dans la DeskBar :

• Tous les menus utilisent maintenant la police « menu » choisie dans les préférences d’apparence du système. Auparavant, la police « menu » et la police « plain » étaient mélangées. Ces deux polices étant identiques dans la configuration par défaut, le problème n’avait pas été repéré.
• Si un nom de fenêtre est tronqué dans la liste des fenêtres, le nom complet peut être affiché dans une infobulle.
• L’icône pour les fenêtres dans la DeskBar a été remplacée. La nouvelle icône indique plus clairement si une fenêtre se trouve dans un autre bureau virtuel (dans ce cas, activer cette fenêtre provoquera un changement de bureau).

GLTeapot

GLTeapot est une application permettant de tester le rendu OpenGL, en affichant un modèle 3D de la théière de l’Utah.

En plus de la théière, cette application affiche un compteur du nombre d’images affichées par secondes. Bien que les chiffres affichés ne soient pas du tout représentatifs des performances d’un rendu 3D réaliste, certains utilisateurs insistent lourdement pour pouvoir faire le concours de gros chiffres de nombre d’images par seconde.

Il est donc à nouveau possible de désactiver la synchronisation sur le rafraîchissement de l’écran, et demander au processeur de réafficher la théière plusieurs centaines de fois par seconde, bien que l’écran soit incapable de suivre le rythme. Par défaut, la synchronisation est activée et le rafraîchissement ne dépassera jamais 60 FPS, si toutefois le pilote graphique implémente les fonctions de synchronisation nécessaires.

HaikuDepot

HaikuDepot est un hybride entre un gestionnaire de paquets et un magasin d’applications.

Il se compose d’un serveur (développé en Java) fournissant une API REST et permettant de collecter les informations sur les applications (icônes, captures d’écrans, catégories, votes et revues des utilisateurs, choix de la rédaction pour les applications mises en avant…), d’un frontend web minimaliste et d’une application native C++ permettant d’afficher ces données.

La principale nouveauté est l’intégration du système de single-sign-on (SSO) permettant d’utiliser un compte utilisateur commun avec d’autres services en ligne de Haiku. Actuellement, l’outil de revue de code Gerrit
utilise ce même compte, mais ce n’est pas encore le cas pour Trac (outil de suivi des bugs) ni pour le forum. Ce sera mis en place plus tard.

De façon peut-être moins visible, mais pas moins importante, le code C++ de l’application a reçu de nombreuses améliorations et optimisations « sous le capot », rendant l’application plus rapide et plus fiable, mais qui sont un peu difficiles à résumer dans le cadre de cette dépêche.

Enfin, l’apparence de l’application a été légèrement retravaillée pour mieux s’adapter aux écrans à haute définition (ce qui nécessite d’avoir des marges et espacements de taille dynamique en fonction de la taille de texte choisie par l’utilisateur).

Icon-O-Matic

Icon-O-Matic est un éditeur d’icônes. Il permet d’exporter les fichiers au format HVIF, un format vectoriel compact qui permet de stocker les icônes dans l’inode d’en-tête des fichiers pour un chargement et un affichage rapide.

Cette application a bénéficié du travail de Zardshard pendant le Google Summer of Code 2023, elle a donc reçu plusieurs évolutions et corrections importantes (dont certaines sont mentionnées dans la dépêche anniversaire de l’année dernière).

Citons en particulier l’ajout d’un nouveau type de transformation, « perspective », qui permet de facilement déformer un ensemble de chemins vectoriels selon une projection de perspective, ce qui est assez utile pour concevoir plus facilement une icône avec un aspect tridimensionnel (bien qu’en pratique l’apparence habituelle des icônes de Haiku soit un intermédiaire entre une projection perspective et une vue isométrique, ne se prêtant pas forcément à l’utilisation de cette opération de transformation purement mathématique).

Une autre petite amélioration est l’ajout d’une vérification pour empêcher la fenêtre de Icon-O-Matic de se positionner en dehors de l’écran, par exemple si on a déplacé la fenêtre vers le bas de l’écran, enregistré cette position, puis relancé l’application dans une résolution d’écran plus réduite. Dans ce cas, la fenêtre sera automatiquement ramenée dans la zone visible de l’affichage.

Magnify

L’application Magnify permet d’afficher une vue zoomée d’une partie de l’écran. Elle peut servir pour améliorer l’accessibilité (mais n’est pas idéale pour cet usage), mais aussi pour les développeurs d’interfaces graphiques qui ont parfois besoin de compter les pixels pour s’assurer que leurs fenêtres sont bien construites.

En plus de l’affichage zoomé, l’application permet d’afficher l’encodage RGB de la couleur d’un pixel, ou encore de placer des « règles » permettant de vérifier l’alignement des objets. Ces dernières ont reçu une petite mise à jour, avec une amélioration de l’affichage de leur largeur et hauteur pour les rendre plus lisibles.

MediaPlayer

L’affichage des sous-titres ne fonctionnait pas correctement, il manquait une partie du texte. C’est maintenant corrigé.

PowerStatus

L’application PowerStatus permet de surveiller l’état de la batterie pour les ordinateurs qui en disposent.

Elle a reçu plusieurs améliorations importantes :

Une notification a été ajoutée pour un niveau de décharge très faible (en plus du niveau faible déjà présent). Ces deux niveaux peuvent être paramétrés à un pourcentage choisi de décharge de la batterie, et associé à des sons d’alerte spécifiques. Avant ces changements, il était facile de ne pas voir le message d’alerte (affiché seulement pendant quelques secondes) ou de se dire qu’avec 15% de batterie on a encore le temps de faire plein de trucs, puis se retrouver un peu plus tard avec une batterie vide sans autre avertissement.

L’état « not charging » est maintenant détecté et correctement affiché, pour une batterie au repos : ni en train de se charger, ni en train d’alimenter la machine. C’est en particulier le cas d’une batterie déjà chargée à 100%, si la machine reste connectée au réseau électrique.

L’icône de statut de la batterie s’installe automatiquement dans la DeskBar au premier démarrage de Haiku sur les machines disposant d’une batterie.

Le réglage du mode « performance » ou « économie d’énergie" est enregistré et ré-appliqué lors des prochains démarrages (ces modes configurent l’ordonnanceur du noyau pour exécuter un maximum de tâches sur tous les cœurs du processeur, ou bien au contraire pour essayer de garder ces cœurs en veille autant que possible s’ils ne sont pas nécessaires).

SerialConnect

SerialConnect est une application de terminal série, utile principalement aux développeurs de systèmes embarqués et autres gadgets électroniques.

Elle est encore en cours de développement et propose pour l’instant les fonctions les plus basiques. Il est maintenant possible de coller du texte depuis le presse-papier pour l’envoyer sur un port série, ce qui est pratique si on veut envoyer plusieurs fois la même séquence de commandes.

ShowImage

ShowImage est la visionneuse d’images de Haiku. Elle utilise les traducteurs, des greffons avec une API standardisée qui permettent de convertir différents formats de fichiers entre eux.

L’interface graphique de ShowImage a été mise à jour pour utiliser le « layout system ». Historiquement, dans BeOS, tous les éléments des interfaces graphiques devaient être positionnés manuellement avec des coordonnées en pixels, ce qui est pénible à faire, surtout si on doit traiter tous les cas (polices de caractères de différentes tailles, remplacement des textes lors de traductions, utilisation de thème d’interfaces différents), et aussi lors d’évolution de l’application (si on veut insérer un élément en plein milieu, il faut souvent décaler tout ce qui se trouve autour).

Le « layout system » fournit un ensemble d’outils pour automatiser ce travail, soit à l’aide d’éléments prédéfinis (grilles, groupes, « cartes » superposées), soit à l’aide d’un système de définition de contraintes et de programmation linéaire.

D’autre part, ShowImage dispose maintenant d’un menu permettant d’ouvrir l’image affichée dans un éditeur d’images.

Terminal

Le Terminal de Haiku permet d’exécuter un shell (c’est bash par défaut) et toutes les applications conçues pour un affichage en console.

Les principaux changements cette année sont la correction d’un problème sur la configuration des couleurs utilisées par le Terminal (il y avait un mélange entre le nom anglais et le nom traduit des couleurs, empêchant d’enregistrer et de relire correctement le fichier de configuration), ainsi que des modifications sur les raccourcis clavier utilisés par le Terminal lui-même (en particulier pour naviguer entre plusieurs onglets) qui entraient en conflit avec ceux utilisés par les applications lancées dans le terminal.

Le terminal est également capable de traiter les « bracketed paste », c’est-à-dire que les applications en console sont informées que des caractères en entrée proviennent du presse-papier. Cela permet par exemple à bash de ne pas exécuter directement des commandes qui sont collées, mais de les mettre en surbrillance et d’attendre que l’utilisateur valide cette saisie.

D’un point de vue plus bas niveau, les pilotes TTY utilisés pour les ports série et pour le Terminal, qui étaient indépendants, ont été unifiés afin d’éviter de devoir corriger tous les bugs deux fois dans deux versions du code presque identiques.

Tracker

Tracker est le navigateur de fichiers de Haiku. Tout comme la DeskBar, il fait partie des quelques rares morceaux de BeOS qui ont été publiés sous licence libre par Be et ont donc pu être repris directement par Haiku. Contrairement à la DeskBar, la publication du code du Tracker avait conduit à l’apparition de nombreux forks, chacun améliorant à sa façon le logiciel. La version utilisée par Haiku provient principalement du projet OpenTracker, mais a réintégré ou réimplémenté au fil du temps les modifications faites dans d’autres variantes.

Le Tracker est un composant central de l’interface de Haiku et a donc reçu un nombre assez important d’évolutions :

La taille des fichiers est maintenant affichée à l’aide de la fonction string_for_size qui s’adapte aux conventions de la langue et du pays choisi par l’utilisateur.

Les brouillons de courrier électronique disposent maintenant de leur propre type MIME et de l’icône associée. Ils s’ouvriront dans un éditeur de mail plutôt que dans une fenêtre de lecture de message.

Pour les fichiers qui disposent d’un attribut « rating » (évaluation), ce dernier est affiché avec des étoiles pleines ou vides selon la note attribuée. La note va de 0 à 10 mais il n’y a que 5 étoiles. Le caractère demi-étoile permet d’afficher la note exacte avec les versions récentes d’Unicode (depuis 2018 en fait, mais il a fallu attendre la disponibilité dans une police de caractères).

La gestion des dossiers en lecture seule a été améliorée. Ils sont affichés sur fond gris (au lieu d’un fond blanc pour les dossiers modifiables) et tous les menus correspondant à des opérations non autorisées sont désactivés (au lieu d’être activés, mais d’aboutir sur une erreur car le dossier est en lecture seule).

Dans le même esprit, le bouton « ouvrir » des boîtes de dialogues d’ouverture de fichier est désactivé si le fichier sélectionné ne peut pas être ouvert (c’était déjà le cas, mais tous les cas possibles n’étaient pas bien pris en compte).

Un problème d’affichage sur le système de fichier packagefs a été corrigé : les dossiers n’ont pas de taille et affichent donc - au lieu d’une taille fixe de 4 Kio qui n’a aucune signification.

La fenêtre de recherche a reçu quelques évolutions, voir plus bas dans la section dédiée au Google Summer of Code, qui détaille le travail réalisé à ce sujet.

Le menu « templates », utilisé quand on fait un 'clic droit -> Nouveau…' et qui permet de créer différents types de fichiers et de dossiers à partir de fichiers de référence, peut maintenant contenir des sous-dossiers, pour les personnes qui utilisent beaucoup cette possibilité, avec par exemple des modèles de documents pré-remplis pour différents usages.

Enfin, un peu de nettoyage interne : les classes NavMenu et SlowContextPopup, qui permettent la navigation dans les sous-dossiers via des menus popup, ont été fusionnées en une seule classe car elles sont toujours utilisées ensemble. Cela simplifie le code pour l’affichage de ces menus, qui a quelques particularités pour permettre une navigation confortable même sur un disque dur un peu lent.

TV

L’application TV utilisée pour recevoir la TNT à l’aide d’un tuner approprié a été déplacée dans le paquet haiku_extras et n’est donc plus installée par défaut. La plupart des gens ne disposant pas d’un tuner compatible sur leur ordinateur, cette application était source de confusion et de nombreuses questions sur le forum.

WebPositive

WebPositive est le navigateur web de Haiku. Il utilise le moteur WebKit développé conjointement par Apple, Igalia et Sony principalement.

En dehors de la mise à jour du moteur vers une version plus récente, WebPositive reçoit actuellement peu d’évolutions, les développeurs étant malheureusement trop occupés par ailleurs. On peut toutefois mentionner une correction sur la barre de signets : celle-ci ne s’affichait jamais lorsque la langue du système était autre chose que l’anglais.

Zip-O-Matic

Zip-O-Matic est un outil permettant de créer une archive zip facilement depuis le Tracker. Il a reçu une amélioration qui est en fait une correction d’un problème qui existait depuis longtemps : l’archive créée est maintenant automatiquement sélectionnée dans le navigateur de fichier à la fin du processus, ce qui permet de facilement la retrouver pour la renommer, la déplacer ou l'envoyer à son destinataire.

Haikuports

Haikuports est un projet indépendant de Haiku, il se charge d’alimenter le dépôt de paquets. Au départ il s’agissait principalement d’un projet pour le portage de bibliothèque et de programmes venant d’autres systèmes (d’où son nom), mais il est également utilisé pour la plupart des applications natives développées pour Haiku.

Le dépôt de paquets contient actuellement 4193 paquets, il est mis à jour en continu par une petite équipe de bénévoles qui ne sont pas forcément tous développeurs, mais tout de même capables de faire les tâches de maintenance ainsi que le développement de quelques patchs simples.

Il est impossible de lister toutes les mises à jour et ajouts, le projet HaikuPorts étant très actif. Donc voici une sélection arbitraire de quelques nouveautés et mises à jour.

Applications natives

• Mises à jour de Renga (client XMPP), PonpokoDiff (outil de diff), 2pow (clone de 2048), StreamRadio (lecteur de podcasts), NetSurf (navigateur web léger)…
• Genio, un IDE pour Haiku avec gestion de la complétion de code via le protocole LSP (compatible avec les outils développés pour VS Code par exemple).
• Ajout de HaikuUtils, un ensemble d’outils de développement et de debug divers.
• WorkspaceNumber, un replicant pour afficher le numéro du bureau actif dans la DeskBar.
• KeyCursor, un outil pour contrôler le curseur de souris à l’aide du clavier.
• BatchRename, un outil pour renommer automatiquement des fichiers par lot.

Applications portées

• Un gros travail a été fait sur le portage de KDE Frameworks et des applications l’utilisant. De très nombreuses applications Qt et KDE sont donc disponibles.
• Du côté de GTK, il n’existait pas de version de GTK pour Haiku, le problème a été résolu à l’aide d’une couche de compatibilité avec Wayland qui n’implémente pas le protocole Wayland mais réimplémente l’API de la libwayland. Les applications GTK arrivent petit à petit, mais l’intégration est pour l’instant beaucoup moins bonne qu’avec Qt, qui dispose lui d’un vrai port utilisant les APIs natives directement. L’apparence des applications est très visiblement différente, certaines touches du clavier ne fonctionnent pas. C’est donc encore un peu expérimental.
• Enfin, pour compléter les possibilités d’outils graphiques, la bibliothèque Xlibe implémente les APIs de la libx11 (mais pas le protocole de communication de X) et permet de porter les applications FLTK par exemple, ainsi que celles utilisant directement la libx11. Il reste encore des problèmes avec les applications utilisant Tk (si vous connaissez Tk ou X, les développeurs de Xlibe aimeraient bien un petit coup de main). En attendant, les applications Tk sont utilisables à travers un portage de undroidwish, mais ça reste peu confortable.

Du côté des compilateurs et des langages de programmation : LLVM a été mis à jour en version 17. GCC est disponible en version 13 et peut maintenant être utilisé pour compiler du FORTRAN et de l’Objective-C. Les dernières versions de Python sont disponibles, et en plus avec des performances améliorées. Node.JS est également mis à jour, ou si vous préférez le langage R, vous le trouverez également, avec son IDE associé rkward.

Bien sûr, la plupart des bibliothèques et outils disponibles sur d’autres systèmes sont aussi disponibles : ffmpeg (en version 6), Git, libreoffice, Wireshark…

Mentionnons enfin un pilote FUSE pour monter des volumes réseau NFS, qui vient compléter les deux implémentations de NFS présentes dans le noyau (une obsolète qui implémente NFS2, et une plus récente implémentant NFS4, mais qui est instable et pas activement maintenue actuellement).

Panneaux de préférences

Appearance

Les préférences « Appearance » permettent de configurer l’apparence du système et des applications : principalement les polices de caractères et les choix de couleurs.

C’est ce dernier qui reçoit une mise à jour en profondeur, avec l’ajout d’un mode automatique. Auparavant, chaque couleur utilisée par le système devait être configurée manuellement, ce qui permet un contrôle très fin, mais demande de passer un certain temps à faire des ajustements. Le mode automatique permet de configurer seulement 3 couleurs : le fond des fenêtres, les barres de titres, et une couleur d’« accentuation ». Les autres couleurs et nuances sont calculées automatiquement à partir de cette palette de base.

En particulier, il devient beaucoup plus facile de choisir un fond sombre pour se retrouver avec un système en mode sombre, très à la mode chez certain·e·s utilisateurices de Haiku.

Il est toujours possible d’activer le mode avancé pour affiner les réglages si nécessaire (ou si vous aimez les interfaces graphiques bariolées et multicolores).

Keymap (disposition clavier)

L’application Keymap permet de configurer la disposition de touches du clavier. Le point qui a reçu un peu d’attention est la gestion de la configuration des touches modificatrices.

Haiku est un dérivé de BeOS qui lui-même a été au départ inspiré de Mac OS. On conserve de cet héritage l’utilisation des touches commande et option au lieu de meta et alt sur les claviers de PC. Mais BeOS et Haiku sont conçus pour être utilisés avec des claviers de PC. La touche commande qui prend la place de la touche ALT est donc celle utilisée pour la plupart des raccourcis claviers. Cela se complique si on essaie d’utiliser un clavier fabriqué par Apple (les codes de touches renvoyés par le clavier pour des touches situées au même endroit ne sont pas les mêmes), ou encore si on a besoin d’une touche AltGr (historiquement utilisée comme touche option par BeOS, mais aujourd’hui ce rôle est plutôt attribué à la touche windows apparue un peu plus tard). Une page sur le wiki de développement de Haiku tente de résumer l’historique et la situation actuelle.

La configuration des touches modificatrices est donc un sujet complexe, et il est probable que le comportement sera à nouveau modifié plus tard. Quoi qu’il en soit, en attendant, l’application Keymap permet toutes les permutations possibles de configuration de ces touches.

Screen (Affichage)

Les préférences d’affichage, en plus de permettre de changer la résolution d’écran, affichent quelques informations essentielles sur la carte graphique et l’écran en cours d’utilisation. Pour les écrans, ces informations sont généralement extraites des données EDID, mais il y a une exception : les dalles d’affichage des PC portables n’implémentent en général pas ce protocole. Les informations sont donc récupérées par d’autres moyens parfois moins bien normalisés. Par exemple, l’identifiant du fabricant est un code à 3 lettres. En principe, les fabricants doivent s’enregistrer auprès d’un organisme qui attribue ces codes, afin d’en garantir l’unicité.

Cependant, certains fabricants ne l’ont pas fait, et se sont choisi eux-mêmes un code qui semblait inutilisé. La base de données officielle réserve donc ces codes et en interdit l’utilisation, afin d’éviter des conflits. Il arrivait donc que le fabriquant d’un écran soit affiché comme étant « DO NOT USE », ce qui a inquiété quelques utilisateurs de Haiku se demandant s’ils risquaient d’endommager leur matériel.

Ces entrées de la liste sont maintenant filtrées et remplacées par les noms des fabricants de panneaux d’affichages concernés (lorsqu’on sait de qui il s’agit).

Outils en ligne de commande

Haiku est fourni avec un terminal et un shell bash (par défaut, d’autres shells peuvent également être utilisés). Les outils définis dans la spécification POSIX sont fournis, ainsi que des compléments permettant d’utiliser les fonctionnalités supplémentaires de Haiku.

df

La commande df affiche l’espace disque disponible sur chaque volume de stockage actuellement monté.

Les colonnes de l’affichage ont été réorganisées, pour être plus lisibles, et se rapprocher un peu du format spécifié par POSIX (mais pas complètement lorsqu’on lance la commande sans options particulières : des informations supplémentaires sont alors affichées).

filteredquery

L’outil filteredquery permet d’effectuer une requête sur les attributs étendus du système de fichiers (permettant de requêter le système de fichiers comme une base de données, plutôt que de naviguer de façon hiérarchique dans les dossiers), puis de filtrer le résultat pour ne conserver que les réponses contenues dans un sous-dossier spécifique. En effet, les requêtes étant indépendantes de l’organisation des dossiers, il est nécessaire de faire ce filtrage par post-traitement des résultats (ce qui reste tout de même généralement plus rapide que de faire l’inverse : parcourir tous les fichiers d’un dossier pour trouver ceux correspondant à un critère particulier).

Cet outil n’a pas reçu de nouvelles fonctionnalités, mais de nombreuses corrections et nettoyages qui le rendent véritablement utilisable.

ping, traceroute, telnet, ftpd

Ces commandes liées à des opérations sur le réseau ont été remplacées par les dernières versions développées par FreeBSD, permettant de bénéficier d’une version moderne, avec plus de fonctionnalités et moins de bugs.

La commande ping6 est supprimée, car ping peut maintenant utiliser l’IPv6 aussi bien que l’IPv4.

pkgman

L’outil pkgman permet de télécharger et d’installer des logiciels et des mises à jour.

Il a peu évolué, mais on peut tout de même noter l’utilisation d’un algorithme de tri « naturel » pour l’affichage des résultats dans l’ordre alphabétique (par exemple, llvm12 sera affiché après llvm9).

Une fonction qui n’est toujours pas disponible dans pkgman est le nettoyage des dépendances non utilisées. Un script fourni dans le dépôt Git de Haiku permet de réaliser manuellement une analyse des paquets installés sur le système pour détecter ceux qui n’ont pas de dépendances, il faudra pour l’instant se contenter de cette solution.

strace

L’outil strace permet d’afficher les appels systèmes effectués par une application, pour comprendre son interfaçage avec le noyau et investiguer certains problèmes de performances ou de mauvais comportements.

L’interfaçage avec le noyau pour extraire ces informations étant assez spécifique, l’implémentation de strace est faite à partir de zéro, et ne partage pas de code avec la commande du même nom disponible par exemple sous Linux.

strace est mis à jour régulièrement et en fonction des besoins des développeurs de Haiku pour décoder et afficher de plus en plus d’informations. Par exemple, elle peut maintenant afficher le contenu des iovec (par exemple pour les fonctions readv ou writev), ainsi que les objets manipulés par wait_for_object et event_queue.

Un exemple de sortie de strace (traçant l’ouverture d’un fichier et le chargement d’une bibliothèque partagée) avant ces changements:

open(0x5, "plaintext", 0x2042, 0x0) = 0x8000000f () (49 us)
map_file("libicuuc.so.66 mmap area", 0x7f04c2675228, 0x6, 0x1ababd0, 0x1, 0x0, true, 0x3, 0x0) = 0x329a0 () (108 us)

et après :

open(0x5, "plaintext", O_RDWR|O_NOTRAVERSE|O_CLOEXEC, 0x0) = 0x8000000f Operation not allowed (57 us)
map_file("libicuuc.so.66 mmap area", [0x0], B_RANDOMIZED_ANY_ADDRESS, 0x1ababd0, B_READ_AREA, 0x0, true, 0x3, 0x0) = 0x73e8 ([0x6392223000]) (135 us)

whence

La commande whence permettait de trouver dans le PATH un exécutable à partir de son nom. Elle était implémentée sous forme d’une fonction bash dans le fichier profile par défaut. Cependant, cette implémentation posait problème pour charger le fichier profile avec d’autres shells, elle a donc été supprimée. La commande which peut être utilisée à la place, puisqu’elle remplit un rôle équivalent.

Serveurs

Les serveurs sont l’équivalent des daemons pour UNIX ou des services sous Windows : il s’agit d’applications lancées par le système pour rendre différents services et coordonner l’ensemble des applications.

app_server

app_server est le serveur graphique de Haiku, équivalent de X ou de Wayland. Il se distingue par un rendu graphique fait principalement côté serveur (pour les applications natives), ce qui permet de l’utiliser de façon fluide à travers une connexion réseau.

Bien que ce soit le serveur graphique, et qu’il ait reçu plusieurs améliorations importantes, les différences sont subtiles. Elles sont toutefois importantes pour proposer un système qui semble réactif et confortable à utiliser.

Un premier changement est une réarchitecture du code qui traite le rafraîchissement de l’écran. Ce rafraîchissement se fait en général en plusieurs étapes, par exemple, si on déplace une fenêtre :

• Le contenu de la fenêtre déplacée peut être directement recopié de l’ancienne position vers la nouvelle,
• La zone où se trouvait la fenêtre auparavant doit être re-remplie avec ce qui se trouvait en dessous de la fenêtre déplacée. Cela peut être plusieurs morceaux de fenêtres d’autres applications, qui vont devoir chacune ré-afficher une partie de cette zone.

Le problème étant que certaines applications peuvent mettre un peu de temps à répondre à cette demande de ré-affichage (par exemple parce qu’elles sont occupées ailleurs, ou alors parce que la zone à redessiner est relativement complexe).

Différentes stratégies peuvent être mises en place dans ce cas : laisser à l’écran le contenu obsolète, ou remplir la zone en blanc en attendant que les données deviennent disponibles, par exemple. Ou encore, tout simplement ne rien mettre à jour du tout tant que tout l’écran n’est pas prêt à être affiché. Il faut faire un compromis entre la réactivité (déplacer la fenêtre tout de suite), la fluidité (éviter les clignotements de zones blanches) et la précision (affichage d’information cohérente et à jour).

Plusieurs modifications ont permis d’obtenir un meilleur compromis.

Dans un autre domaine, la police de caractères par défaut « Noto Sans Display » a été remplacée par « Noto Sans », ce qui donne un affichage du texte légèrement différent. La police « display » avait été choisie suite à une mauvaise compréhension de la signification de ce mot en typographie : il signifie que c’est une police de caractères à utiliser pour des gros titres et autres textes courts. Il ne signifie pas que c’est une police à utiliser sur un écran d’ordinateur. De toutes façons la police Noto Display n’est plus maintenue par Google et a disparu des dernières versions du jeu de polices Noto.

Toujours dans le domaine des polices de caractères, app_server sait maintenant charger les fichiers « variable fonts ». Ces fichiers contiennent plusieurs polices de caractères définies à partir de glyphes de base, et d’algorithmes de transformation et de déformation (pour rendre une police plus ou moins grasse, plus ou moins italique…). Pour l’instant, app_server sait charger les valeurs de ces paramètres qui sont préconfigurées dans le fichier. Cela permet de réduire la place utilisée par les polices de caractères sur le media d’installation de Haiku (c’est l’un des plus gros consommateurs d’espace disque, qui nous empêche de faire tenir une version complète de Haiku sur un CD de démonstration par exemple).

Plus tard, il sera également possible de configurer plus finement ces paramètres pour générer des variantes intermédiaires des polices de caractères, ainsi que d’exploiter certaines polices qui offrent des paramètres configurables supplémentaires.

input_server

L’input_server se charge de lire les données venant des périphériques d’entrée (clavier et souris) et de les convertir en évènements distribués aux applications. Il est extensible par des add-ons qui peuvent générer ou filtrer des évènements, ce qui peut être utilisé pour de l’accessibilité (émuler une souris à partir de touches du clavier), de l’automatisation (envoi de commandes pré-enregistrées), du confort d’utilisation (bloquer le touchpad d’un ordinateur portable lorsque le clavier est en cours d’utilisation) et bien d’autres choses.

L’input_server a reçu des corrections de problèmes sur la gestion des réglages de souris, permettant en particulier d’utiliser des réglages différents pour plusieurs périphériques (souris, touchpad), et que ceux-ci soient bien enregistrés.

registrar

Le serveur registrar suit les applications en cours de fonctionnement, et leur permet de communiquer entre elles au travers de l’envoi de messages. Il assure également le suivi de la base de données des types MIME et des associations de types de fichiers avec les applications correspondantes.

L’implémentation de BMessageRunner, qui permet d’envoyer des messages périodiques (par exemple pour faire clignoter le curseur des zones de texte à la bonne vitesse), autorise maintenant des intervalles de répétition en dessous de 50 millisecondes. Cela permet d’utiliser ce système pour des animations fluides de l’interface graphique, par exemple.

D’autre part, la liste des applications et documents récemment lancés est maintenant limitée à 100 entrées. Cela évite un fichier qui grossit indéfiniment et finit par contenir surtout des vieilles informations sans intérêt.

Kits

Le système Haiku fournit les mêmes APIs que BeOS. Elles couvrent les usages basiques d’une application, et sont découpées (dans la documentation de BeOS et de Haiku, au moins) en « kits » qui prennent chacun en charge une partie spécifique (interface graphique, multimédia, jeux vidéos, accès au matériel, etc).

Interface

L’interface kit est la partie de la bibliothèque standard qui se charge des interfaces graphiques.

 BColumnListView

BColumnListView est un ajout de Haiku par rapport à BeOS. Il s’agit d’un élément d’interface permettant de présenter une liste avec plusieurs colonnes, de trier les lignes selon le contenu de ces colonnes, et aussi d’avoir des items hiérarchisés avec la possibilité de plier et déplier une partie de l’arborescence.

Cette classe remplace avantageusement BListView et surtout BColumnListView, les classes historiques de BeOS, qui sont beaucoup plus limitées.

Un certain nombre de type de colonnes prédéfinis sont également disponibles, ce qui facilite la construction d’interfaces présentant les données de différentes applications avec le même formatage.

La classe BColumnListView elle-même n’a pas changé. Par contre, les colonnes de type « taille » (pour afficher une taille en Kio, Mio, Gio…) et « date » utilisent la langue choisie dans les préférences système au lieu d’un format anglais par défaut.

BTextView

BTextView est une classe permettant d’afficher une zone de texte éditable. Elle implémente les fonctionnalités de base (curseur, sélection, retour à la ligne automatique) ainsi que quelques possibilités de mise en forme (couleurs, polices de caractères).

BTextView peut également être utilisée pour des zones de textes non éditables, souvent plus courtes. Cela permet de réutiliser une partie des algorithmes de mise en page et de formatage du texte dans différents contextes. Dans le cadre de l’utilisation du « layout system », une vue doit pouvoir indiquer sa taille minimale, maximale et optimale. Le « layout system » va ensuite calculer la meilleure disposition de fenêtre possible pour satisfaire ces contraintes.

Le cas des zones de texte est particulier, car la hauteur optimale dépend du nombre de lignes de texte, qui lui-même peut être plus ou moins grand si la largeur de la vue oblige à ajouter des retours à la ligne. Le « layout kit » prend en compte ce cas particulier, mais les algorithmes ne sont pas encore tout à fait au point et peuvent conduire à des résultats inattendus dans certains cas. Un de ces cas particuliers sur les zones de texte non éditables a été corrigé.

BMenu

La classe BMenu permet d’afficher un menu. Elle est utilisée de plusieurs façons, puisqu’on trouve des menus dans des barres de menu, dans des contrôles de type « popup », ou encore en faisant un clic droit sur certains éléments de l’interface.

Les menus sont également particuliers parce qu’ils peuvent d’étendre en dehors de la fenêtre dont ils sont originaires. Ils sont donc implémentés sous forme de fenêtres indépendantes. Mais cela pose un autre problème : dans Haiku, chaque fenêtre exécute son propre thread et sa propre boucle d’évènements. Si on navigue dans un grand nombre de menus et de sous-menus, cela peut causer quelques problèmes de synchronisation et de performances.

Le code contient également un grand nombre de cas particuliers pour, par exemple, aligner les raccourcis claviers et les flèches indiquant la présence de sous-menus ente les différents items d’un menu, ou encore détecter si un déplacement de souris a pour but de sélectionner un autre menu (en dessous ou au-dessus de celui actif), ou bien plutôt de naviguer vers un sous-menu.

Les nouveautés suivantes sont apparues cette année:

• Correction de problèmes de race condition lors de l’ajout d’items dans un menu pendant qu’il est affiché à l’écran. Ce problème se manifestait par exemple dans les menus affichant la liste des réseaux Wifi, qui sont mis à jour en temps réel.
• Finalisation de l’implémentation de la navigation au clavier (avec les flèches directionnelles) dans les menus.
• Affichage des symboles graphiques UNICODE pour « backspace » (⌫) et « delete » (⌦) si ces touches sont utilisées comme raccourcis clavier pour un item de menu.
• Utilisation d’un algorithme de tri stable pour la fonction SortItems. Ce type d’algorithme préserve l’ordre relatif des items qui sont égaux d’après la fonction de comparaison. Ce n’est pas le cas de certains algorithmes de tri classiques, notamment le quicksort. La conséquence était que trier un menu déjà trié pouvait changer l'ordre des items. C’était visible encore une fois sur le menu listant les réseaux Wifi, qui est trié par puissance du signal reçu.

 BSpinner

BSpinner est un contrôle permettant de choisir une valeur numérique, soit à l’aide de boutons +/- pour modifier la valeur par incréments, soit en entrant directement la valeur dans une zone de texte.

Il s’agit d’une extension de Haiku par rapport à BeOS qui ne proposait pas cette fonctionnalité.

Cette classe est encore en cours de développement. Elle a reçu des améliorations pour désactiver correctement les boutons +/- lorsque la valeur atteint le minimum ou le maximum autorisé, et aussi une correction sur le message de notification envoyé lors des changements de valeurs du spinner, qui ne contenaient pas la bonne valeur.

rgb_color

La structure rgb_color permet de représenter une couleur par la valeur de ses composantes rouge, vert, bleu (comme son nom l’indique) et alpha (comme son nom ne l’indique pas). Elle fournit également un certain nombre de fonctions pour mélanger des couleurs, les éclaircir ou les assombrir.

La méthode Brightness() dans la classe rgb_color implémentante maintenant l’algorithme perceptual brightness documenté par Darel Rex Finley, qui donne des meilleurs résultats que l’algorithme utilisé précédemment (qui était celui de la luminosité dans l’espace de couleurs Y'IQ. La fonction perceptual_brightness devenue redondante est supprimée.

Cette méthode permet en particulier de déterminer si une couleur est « sombre » ou « claire », et ainsi de décider si du texte affiché par-dessus doit être blanc ou noir (comme démontré ici par exemple).

Locale

Le locale kit se charge de tous les aspects liés à la localisation : traductions des applications, formatage des messages en utilisant les règles de pluralisation de chaque langue, formatage de dates, de nombres avec et sans unités, de pourcentages, nom des fuseaux horaires…

Il utilise ICU pour implémenter la plupart de ces fonctionnalités, mais fournit une surcouche avec une API s’intégrant mieux avec les autres kits.

La principale évolution cette année est l’implémentation de BNumberFormat, qui permet de formater des nombres. Elle permet de choisir une précision (nombre de décimales - pour les langues qui utilisent un système décimal), d’afficher ou non des séparateurs de groupes (de milliers en français, mais par exemple en Inde la séparation se fait traditionnellement par multiples de 10 000).

Media

Le media kit se charge de tous les aspects multimedia.

Il se compose de deux parties. D’une part, un système de gestion de flux média temps réel, permettant de transférer des données multimédia (son ou flux vidéo par exemple) entre différentes applications qui vont les manipuler, le tout avec un certain contrôle du temps de traitement ajouté par chaque opération, pour tenter de minimiser la latence tout en évitant les vidages de tampons qui produiraient une interruption dans le flux. D’autre part, des classes permettant d’encoder et de décoder des fichiers média et d’en extraire des flux de données (encodées ou décodées).

C’est surtout cette deuxième partie qui a reçu quelques évolutions. La version de ffmpeg utilisée pour le décodage de presque tous les formats audio et video est maintenant la dernière version ffmpeg 6. Quelques autres problèmes (erreurs d’arrondis, gestion des tampons partiels en fin de fichier) ont également été corrigés, ce qui permet de faire fonctionner à nouveau le jeu BePac Deluxe qui est extrêmement intolérant au moindre écart de comportement par rapport à l’implémentation du Media Kit dans BeOS.

Support

Le support kit contient un ensemble de classes basiques mais indispensables : gestion des chaînes de caractères, des tampons en mémoire, etc. Il fournit les briques de bases utilisées par les autres kits.

BDataIO

BDataIO est une classe abstraite avec des fonctions de lecture et d’écriture. Plusieurs autres classes sont des instances de BDataIO, par exemple BFile (représentant un fichier), mais aussi BMemoryIO (permettant d’accéder à une zone mémoire).

Plusieurs autres classes acceptent BDataIO (ou sa sous-classe BPositionIO, qui ajoute la possibilité de se déplacer à une position donnée dans le flux) comme entrée ou comme sortie. Il est donc facilement possible de réaliser les mêmes opérations sur un fichier, une zone de données en mémoire, un socket réseau, ou tout autre objet susceptible de fournir une interface similaire.

BDataIO elle-même n’a pas évolué, mais deux de ses implémentations, BBufferedDataIO et BAdapterIO, ont été améliorées. Ces deux classes permettent de construire un objet BDataIO à partir d’un autre, en ajoutant un cache en mémoire pour accélérer les opérations ou encore pour rendre compatible avec BPositionIO un objet qui ne l’est pas.

Ces classes sont en particulier utilisées par l’application StreamRadio, qui implémente la lecture de podcasts en connectant directement le résultat d’une requête HTTP (effectuée grace au network kit) dans un décodeur audio (via la classe BMediaFile du media kit). La mise en tampon permet de revenir en arrière dans la lecture d’un épisode, de télécharger en avance les données qui vont être lues, et d’éviter de conserver inutilement en mémoire les données qui sont déjà lues par l’application.

Bibliothèques C

Les « kits » mentionnés ci-dessus sont l’API en C++ utilisée par les applications Haiku.

Il existe aussi des APIs en C, en grande partie implémentant la bibliothèque C standard et les fonctions décrites dans la spécification POSIX.

Libroot

Libroot implémente la bibliothèque standard C. Elle regroupe entre autres la libc, la libm, et la libpthread, qui sont parfois implémentées comme 3 bibliothèques différentes pour d’autres systèmes. Les évolutions consistent à compléter l’implémentation de la spécification POSIX, et à suivre les évolutions de cette dernière ainsi que des nouvelles versions du langage C. On trouve également des corrections de bugs découverts en essayant de faire fonctionner de plus en plus d’applications sur Haiku, ce qui permet de mettre en évidence des différences de comportement avec d’autres systèmes.

• Ajout de getentropy pour initialiser les générateurs de nombres aléatoires
• Correction de problèmes de locks au niveau de l’allocateur mémoire lors d’un fork
• Plusieurs corrections sur l’implémentation de locale_t, remplacement de code écrit pour Haiku ou provenant de FreeBSD par une implémentation simplifiée mais suffisante, provenant de la bibliothèque C musl.
• Ajout de static_assert en C11
• Correction d’un crash lors de l’utilisation de certaines fonctions XSI
• Ajout de stpncpy
• La fonction open utilisée sur un lien symbolique pointant vers un fichier non existant peut maintenant créer le fichier cible.
• Il est possible d’utiliser mmap sur un fichier plus grand que la mémoire disponible sans avoir besoin de spécifier le flag MAP_NORESERVE
• Utiliser rename pour renommer un fichier vers lui-même ne retourne plus d’erreur (conformément à la spécification POSIX).
• Ajout de pthread_sigqueue

Libnetwork

La libnetwork implémente les APIs nécessaire pour se connecter au réseau (sockets, résolution DNS…). Elle est séparée de la bibliothèque C pour des raisons historiques : l’implémentation de TCP/IP pour BeOS avait été réalisée entièrement en espace utilisateur (le noyau n’offrant qu’une interface pour envoyer et recevoir des paquets ethernet sur la carte réseau). Cela a posé des problèmes de compatibilité avec d’autres systèmes, et des problèmes de performance. Haiku est donc compatible avec la version "BONE" de BeOS, qui implémente la pile réseau dans le noyau.

• Mise à jour du résolveur DNS à partir du code de NetBSD 9.3. Précédement le code utilisé était celui du projet netresolv de NetBSD, mais ce projet n’a pas connu de nouvelles publications et le code est à nouveau maintenu directement dans NetBSD sans publication séparée.
• Correction d’un crash lors de l’utilisation de multicast IPv4

LibBSD

La libbsd implémente plusieurs extensions fournies par la libc de certains systèmes BSD. Elle est séparée de la bibliothèque C principale pour limiter les problèmes de compatibilité: certaines applications préfèrent fournir leur propre version de ces fonctions, ou d’autres fonctions avec le même nom mais un comportement différent. Elles peuvent alors s’isoler en n’utilisant pas la libbsd pour éviter toute interférence.

• Ajout de arc4random pour générer des nombres aléatoires sans devoir passer par /dev/random (compatible avec OpenBSD, Theo de Raadt a réalisé une présentation expliquant le pourquoi et le comment en 2014).

LibGNU

De façon similaire à la libbsd, la libgnu fournit des fonctions qui sont disponibles dans la glibc (la bibliothèque C du projet GNU) mais ne font pas partie d’un standard (C ou POSIX).

• Ajout de sched_getcpu pour savoir sur quel cœur de CPU le thread appelant est en train de s’exécuter.
• Ajout de pthread_timedjoin_np, pour attendre la fin de l’exécution d’un thread (comme pthread_join mais avec un timeout.

Le 5 août 2024 est sortie la version 2.6 du logiciel de gestion de la relation client Crème CRM (sous licence AGPL-3.0), environ 11 mois après Creme 2.5 (11 septembre 2023).

Au programme notamment, un système de notification, des améliorations pour le calendrier ou des filtres réservés aux rapports. Les nouveautés sont détaillées dans la suite de la dépêche.

Sommaire

• Description du logiciel
• Principales nouveautés de la version 2.6
  • Le nouveau système de notification
  • Améliorations du calendrier
  • Filtres spécifiques aux Rapports
  • Quelques autres améliorations notables
• Le futur

Description du logiciel

Crème CRM est un logiciel de gestion de la relation client, généralement appelé CRM (pour Customer Relationship Management). Il dispose évidemment des fonctionnalités basiques d’un tel logiciel :

• un annuaire, dans lequel on enregistre contacts et sociétés : il peut s’agir de clients, bien sûr, mais aussi de partenaires, prospects, fournisseurs, adhérents, etc. ;
• un calendrier pour gérer ses rendez‐vous, appels téléphoniques, conférences, etc. ; chaque utilisateur peut avoir plusieurs calendriers, publics ou privés ;
• les opportunités d’affaires, gérant tout l’historique des ventes ;
• les actions commerciales, avec leurs objectifs à remplir ;
• les documents (fichiers) et les classeurs.

Crème CRM dispose en outre de nombreux modules optionnels le rendant très polyvalent :

• campagnes de courriels ;
• devis, bons de commande, factures et avoirs ;
• tickets, génération des rapports et graphiques…

L’objectif de Crème CRM est de fournir un logiciel libre de gestion de la relation client pouvant convenir à la plupart des besoins, simples ou complexes. À cet effet, il propose quelques concepts puissants qui se combinent entre eux (entités, relations, filtres, vues, propriétés, blocs), et il est très configurable (bien des problèmes pouvant se résoudre par l’interface de configuration) ; la contrepartie est qu’il faudra sûrement passer quelques minutes dans l’interface de configuration graphique pour avoir quelque chose qui vous convienne vraiment (la configuration par défaut ne pouvant être optimale pour tout le monde). De plus, afin de satisfaire les besoins les plus particuliers, son code est conçu pour être facilement étendu, tel un cadriciel (framework).

Du côté de la technique, Crème CRM est codé notamment avec Python/Django et fonctionne avec les bases de données MySQL, SQLite et PostgreSQL.

Principales nouveautés de la version 2.6

Voici les changements les plus notables de cette version :

Le nouveau système de notification

Depuis toujours Crème possède un système de Mémentos (Reminders), qui permet de recevoir des e-mails pour vous prévenir d’une échéance. Ce système est utilisé par les Alertes & les ToDos ; par exemple vous recevez un e-mail lorsqu’une Alerte qui vous est attribuée va expirer dans 30 minutes. Et comme vous pouvez créer des Alertes dont la date d’expiration est un champ date de la fiche associée, cela permet par exemple d’être prévenu qu’une activité importante à laquelle vous participez va bientôt avoir lieu.

Le nouveau système de notification qui a été introduit amène 2 avancées principales :

• les notifications envoyées ne sont pas limitées à des e-mails, vous pouvez aussi les voir dans votre navigateur (donc sans quitter Crème).
• si les mémentos ont été retravaillés pour utiliser ce nouveau système, d’autres parties de Crème en profitent aussi. Par exemple, une notification vous est envoyée si un administrateur a changé votre mot de passe ; ou bien quand un job d’import CSV vient de s’achever.

Chaque notification est associée à un canal, et vous pouvez configurer les canaux pour savoir si la notification est envoyée dans le navigateur, par e-mail ou bien les 2. Si le canal n’est pas obligatoire, vous pouvez aussi choisir de ne pas recevoir les notifications du tout. Chaque utilisateur peut utiliser sa propre configuration si la configuration générale du canal ne lui convient pas.

Améliorations du calendrier

• Le composant JavaScript FullCalendar est passé à la version 5. Même si ce n’est pas la toute dernière version (il faut dire qu’il y a pas mal de changements cassants entre chaque version), on profite de pas mal d’améliorations diverses.
• Il est maintenant possible de configurer graphiquement le calendrier (premier jour de la semaine, plage horaire, jour travaillés…). Il y a une configuration globale utilisée par tout le monde, mais comme presque toujours dans Creme, il est possible de créer des configurations par rôle.

Filtres spécifiques aux Rapports

Les Rapports utilisent généralement un filtre, afin d’affiner leurs résultats. Ces filtres sont les mêmes que ceux qu’utilisent les vues en liste ; par exemple si vous faites un Rapport sur les Devis, il peut utiliser les filtres disponibles sur la liste des Devis.

Un problème que cela entraîne est que beaucoup d’utilisateurs créent des filtres un peu spécifiques afin de les utiliser dans leurs Rapports, mais ces filtres viennent « polluer » la vue en liste correspondante (car la sélection de filtres proposent de nombreux filtres non pertinents). Afin de corriger ce souci, il est désormais possible de créer des filtres utilisables uniquement dans les Rapports. Les Rapports peuvent bien sûr continuer à utiliser les filtres classiques, mais les filtres spécifiques aux Rapports ne sont pas utilisables dans les vues en liste évidemment.

Quelques autres améliorations notables

• Python 3.12 est officiellement géré.
• Dans le module facturation, vous pouvez maintenant configurer les statuts sélectionnés par défaut (dans les formulaires), ainsi que les statuts utilisés par les Factures lorsque leur numéro est généré.
• Un nouveau bouton, qui peut être mis sur la vue détaillée des Contacts, est disponible: « Créer un appel non abouti » (détails).
• La configuration des blocs d’un rôle peut maintenant être créée en clonant la configuration d’un autre rôle (les rôles pouvant avoir des configurations assez proches, ça peut être un gain de temps appréciable).
• Les blocs basés sur OpenStreetMap sont maintenant utilisés dans l’installation par défaut (à place de ceux basés sur GoogleMaps).
• Un rôle «Utilisateur normal» est créé dans les nouvelles installations. Dans la mesure où c’est une bonne chose que tout le monde ne soit pas connecté en tant que super-utilisateur, ce rôle devrait permettre de gagner du temps et servir au moins de base de travail.
• Un bouton permettant de transformer un simple Contact en utilisateur a été ajouté. Auparavant il fallait fusionner ce Contact avec le Contact automatiquement créé à la création d’un utilisateur.
• Les Graphes ont reçu de nombreuses améliorations : plus de champs sont disponibles en abscisse, plus de champs sont disponibles pour le filtrage, les couleurs associées aux petits modèles auxiliaires (du genre « Statut ») sont utilisées…
• La validation des URLs est désormais moins stricte dans les champs informatifs. Cela posait pas mal de problèmes notamment lors des imports, les gens mettant rarement le « http:// » dans leur base de données.

Le futur

La prochaine version marquera notamment le passage à Django 5.2, la future LTS qui sortira en avril 2025. À l’année prochaine !

Curl est un outil en ligne de commande destiné à récupérer le contenu d’une ressource accessible par un réseau informatique et gérant de nombreux protocoles.

Curl est un outil essentiel pour de nombreux usages, pris en charge par une gamme très large de systèmes d’exploitation, d’architectures matérielles, de l’objet connecté à l’embarqué spatial en passant par l’informatique classique ou les consoles de jeux. Il évolue rapidement et fréquemment, voir par exemple l’arrivée prochaine de HTTP3 pour curl dans Debian unstable (avec le backend gnutls). Son domaine d’utilisation pourrait encore s’étendre avec l’apparition de wcurl dans Debian et bientôt dans le monde entier ?

Il y a 24 ans, une division du code entre une interface ligne de commande et une bibliothèque a été faite.

(Cette dépêche est principalement basée sur l’annonce anglophone par Daniel Stenberg, auteur principal de curl et libcurl ; dépêche rédigée sur un téléphone embarquant curl 7.80, pas vraiment la dernière version…).

La première version de libcurl, baptisée 7.1, date du 7 août 2000. La version de curl précédente, la 6.5.2, pas encore séparée entre une interface ligne de commande et une bibliothèque. Il s’agit de l’écart le plus long entre deux versions de curl. La création de la bibliothèque a été très largement réalisée par Daniel Stenberg seul.

Il décrit son choix de division ainsi : c'était juste une intuition et une conjecture. Je ne savais pas. Je n’avais pas fait de recherches sur cela ou autre chose. Je me suis juste lancé en me disant qu’on verrait plus tard si j’avais raison ou tort.

Le nom de la bibliothèque a été choisi faute d’une meilleure idée. L’API a été définie comme étant bas niveau (on peut toujours ajouter une API de plus haut niveau par-dessus), en observant ioctl(), fcntl() et les fonctions du genre. Le code est en C, langage de prédilection de l’auteur principal.

L’API a bien vieilli : 17 fonctions encore présentes proviennent de la 7.1 ; elle est passée de 17 000 lignes à 171 000 ; elle a survécu aux révolutions HTTP/2 (transferts multiples multiplexés) et HTTP/3 (passer de TCP à UDP).

L’usage a aussi bien progressé depuis l’entrée dans PHP 4.0.2 comme premier binding (ici rendre utilisable en langage PHP), moins d’un mois après la publication de la bibliothèque.

En 2002 a été ajoutée une API multi pour gérer des transferts parallèles concurrents de façon illimitée dans un même thread.

Puis en 2006 vient en surplus le multi_action avec des mécanismes orientés événements, avec une boucle événementielle (comme epoll).

Les premiers changements douloureux sur l’interface binaire (ABI) ont entraîné une volonté de stabilité, de ne jamais casser volontairement cette interface, et ce depuis 2006.

libcurl possède des bindings vers au moins 65 langages de programmation, fonctionne sur au moins 103 systèmes d’exploitation et 28 architectures de processeur, est présent dans les bibliothèques standard de langages de programmation (Python, Java, Rust ou .Net). Son ancien concurrent principal libwww n’est plus développé. Bref 18 ans de stabilité d’API et d’ABI.

L’utilisation de libcurl continue de croître (de plus en plus d’objets connectés notamment). Et curl de manière générale supporte rapidement les nouveaux protocoles et leurs évolutions. À noter que l’auteur principal ne mentionne pas dans ses projections ce qui me semble le plus gros risque pour Curl/libcurl, la difficulté d’avoir une personne prête à lui succéder si quand cela s’avérera nécessaire.

Ne redoutant pas la canicule, le sympathique outil de gestion de contenu de sites web (CMS) à l’écureuil, SPIP, vient de sortir en version 4.3. Au menu, entre autres : des améliorations de l’interface privée, de la conformité HTML5 et des performances des filtres pour les images.

Petite sélection des changements apportés par cette version.

Sortie, versions et php

SPIP 4.3 est sortie le 26 juillet 2024, suivie quelques jours après d’une version de maintenance, la 4.3.1 qui est celle que vous devez adopter pour votre site. Elle est compatible de PHP 7.4 à PHP 8.3.

Les versions antérieures suivantes bénéficient encore de correctifs de sécurité :

• SPIP 4.2.15, versions de PHP supportées 7.4 à 8.3,
• SPIP 4.1.17, versions de PHP supportées 7.4 à 8.1.

Si votre site est sous une version encore plus antérieure, il est très fortement recommandé de le passer en SPIP 4.3.1. Si vous ne savez pas trop comment procéder, n’hésitez pas à lancer un appel à l’aide sur le site discuter.spip.net. Vous trouverez sûrement des gens pour vous aider.

SPIP pense aux webmestres et aux personnes qui animent un site Internet

La version 4.3 voit l’apparition, dans la barre du haut de l’interface privée, d’un bouton Créer qui ouvre un menu déroulant pour créer un nouveau contenu, article, rubrique, site référencé, etc.

Cette barre est aussi réorganisée, la zone de recherche est à côté du nouveau bouton tandis que l’aide et le nom de la personne connectée passe à droite. Si vous rédigez vos articles avec LibreOffice et utilisez le superbe plugin ODT2SPIP, ce bouton ne vous servira à rien. Il est préférable de continuer logiquement à passer par Édition > Rubrique > Nom de la rubrique > Nouvel article.

Le formulaire de changement de statut d’un article a été revu. On ne risque plus d’oublier d’appuyer sur le bouton Changer par exemple, car il est intégré au formulaire.

À gauche la version 4.2, à droite le formulaire de la 4.3.

Il est possible d’indiquer le fuseau horaire du site au niveau de Configuration > Identité du site.

Et enfin, si on peut dire, la sortie des mises à jour fera l’objet d’un message aux webmestres dans l’interface privée avec un bouton pour y procéder via spip_loader, et même d’un courriel. Plus aucune excuse pour ne pas mettre un site à jour ! Si la notification par courriel vous ennuie, c’est désactivable. Pas très facilement, cela demande de modifier la constante _MAJ_NOTIF_EMAILS dans le fichier config/mes_options.php, mais c’est tout l’intérêt du système justement.

Corrections et améliorations

La conformité HTML5 est améliorée.

Les performances du plugin-dist (plugin de la distribution de SPIP) Filtre Images ont été optimisées : certains des filtres images sont dix fois plus rapides grâce à l’utilisation des fonctions natives de PHP GD. Il y a aussi des nouveaux filtres d’images, |image_oriente_selon_exif, |image_recadre qui permettent de réorienter une image selon son exif.

Sinon, tiré des notes de version :

• ecrire_fichier() a été revu,
• il est possible de combiner les critères {pagination} et {limit},
• (#PRODUIRE_FOND) permet de ne pas conserver un double des fichiers calculés inchangés,
• la bibliothèque mediaelement a été mise à jour.

Les notes de version sont plus disertes.

Mettre à jour, plugins, etc.

Avant de mettre à jour le site, il faut commencer par mettre à jour les plugins : Configuration > Gestion des plugins ce qui rendra la tâche plus facile. Vos plugins seront ainsi compatibles avec la nouvelle version de SPIP. La bibliothèque des plugins compatibles SPIP 4.3 recense environ sept-cent plugins.

Pour la mise à jour, le plus simple est de passer par spip_loader.php qui doit être installé à la racine du site. Il faut être connecté au site pour faire la mise à jour. Si vous n’avez pas spip_loader, c’est peut-être le moment de l’ajouter à votre site.

Sinon, la procédure lourde : télécharger SPIP 4.3.1, le décompresser et ensuite le téléverser sur le serveur non sans avoir fait les sauvegardes nécessaires.

Si la version de votre site est ancienne, il faudra sans doute procéder à une montée en version progressive, et vérifier que le squelette du site est compatible avec les versions plus récentes. Mais cela peut aussi être le moment de modifier l’interface publique de votre site. Ne pas oublier de sauvegarder, les dossiers img et squelette ainsi que la base avant !

Un grand merci à celles et à ceux qui font de SPIP un outil si agréable à utiliser.

S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology) est un système de surveillance intégré aux disques durs modernes et aux disques SSD. Il évalue en continu le bien-être du périphérique tout en anticipant les éventuels dysfonctionnements. Il utilise une réserve de secteurs de rechange pour réparer quand il détecte un secteur en anomalie.
Le programme Linux badblocks teste les blocs d’un média par écriture+relecture+comparaison. À l’origine il servait à mettre les blocs mauvais en liste noire dans le file-system.

Est-il utile de nos jours de vérifier ses médias ?
Comment se situe S.M.A.R.T. par rapport à l’outil badblocks ?
Comment vérifier un média en tenant compte de sa surveillance par S.M.A.R.T. ?

C'est ce que nous allons voir dans la suite de la dépêche.

Sommaire

• Préambule
• S.M.A.R.T.
• BADBLOCKS
• BADBLOCKS2
• En pratique
  • Si S.M.A.R.T. n’est pas sur le média
  • Si S.M.A.R.T. est sur le média

Préambule

Quelle précaution prendre vis-à-vis du risque de mauvaise qualité du stockage, quand je viens d’acheter un média (disque SSD, disque rotatif, clé USB, carte SD) ou un appareil sous Linux équipé d’un espace de stockage dont j’ignore la technologie ?
Sans être parano, je me dis qu’avant d’envoyer des données précieuses sur l’espace de stockage, c’est le moment de faire certaines vérifications. Mais quelles vérifications ? Qu’est-il possible de faire ?

Sur un média connectable, tout est possible.
Sur un appareil neuf sans système ni données, tout est possible en utilisant une distrib Live.
Sur les autres, ça dépend, il y en a où on n’a même pas un accès root pour lancer une vérification « dure » ou « molle » (Android, routeur…).

En écrivant cet article, je me suis rendu compte que je ne me suis jusqu’ici jamais posé de questions sur l’opportunité de vérifier les espaces de stockage de mes téléphones, PC portables, routeurs, box… bref tous les appareils vendus prêts à être utilisés. Pourtant, que sais-je de la vérification faite par celui qui a installé le système ? Rien, et j’utilise, sans penser que l’espace de stockage de l’appareil n’est ni plus ni moins robuste que celui du PC Linux que j’ai installé dernièrement, mais que j’ai vérifié consciencieusement.

S.M.A.R.T.

S.M.A.R.T. est un système de surveillance intégré aux disques durs modernes et aux disques SSD. Il évalue en continu le bien-être du périphérique tout en anticipant les éventuels dysfonctionnements. Il surveille un maximum de paramètres (température, temps de fonctionnement, vitesse de rotation pour les disques magnétiques, nombre de démarrages et d’arrêts…) et dépend de l’expérience du fabricant. La réparation de secteurs utilise une réserve de secteurs et le mapping entre secteurs logiques et secteurs physiques.

On pourrait se dire que, de nos jours, les supports sont fiables et testés par les intégrateurs. D’autres considèrent que la technologie S.M.A.R.T. suffit… et c’est bien commode de ne plus se soucier de la fiabilité des supports de stockage. Mais à la première galère due à un média défaillant, tu évolueras dans ta confiance.

Sais-tu seulement sur lesquels de tes médias S.M.A.R.T. est installé et actif ?
Si tu utilises un RaspberryPi, ton média système est… une carte SD. Elle n’a pas S.M.A.R.T.. Idem pour l’extension de mémoire que tu as ajoutée à ton téléphone.

Je t’invite à lire la page Wikipedia sur S.M.A.R.T. et son paragraphe « Standard, implémentation et limitations ». Que fait et que ne fait pas le S.M.A.R.T. qui fonctionne sur le disque du PC qui te permet de lire cet article ? Difficile de savoir. Comment est-il configuré ? Fais un sondage autour de toi à ce sujet et tu seras pris pour un parano.

Sur ton PC, sais-tu qu’il y a une option S.M.A.R.T. dans le BIOS (ou UEFI) ? Sais-tu qu’il y a un service smartd dans ton Linux ? As-tu compris aussi qu’avec du RAID il n’est pas toujours opportun d’activer S.M.A.R.T. ? Les communications entre S.M.A.R.T. RAID et l’O.S. peuvent se passer plus ou moins bien selon la qualité de ces éléments. Il te faut bien comprendre ce qu’il est possible de paramétrer et deviner comment ça marche derrière.

Si tu demandes une vérification à S.M.A.R.T. par smartctl, sais-tu ce qu’il fait ? Se contente-t-il de lire ou fait-il un test en écriture ?

Enfin, quand S.M.A.R.T. détecte qu’un secteur est devenu défectueux, il ne peut pas deviner quels bits sont défaillants, aussi il renseigne le secteur de secours avec ce qu’il peut, qui est l’état du secteur après défaillance. S.M.A.R.T. a ses limites, il répare comme il peut. S’il est configuré pour, il alerte quand il prévoit de la défaillance, mais sais-tu reconnaître ses alertes ? As-tu compris ce que tu dois faire en réponse aux alertes ?

Je t’invite à apercevoir la complexité de prise en main de S.M.A.R.T. en faisant quelques recherches sur ces listes de mots :

smartctl howto
smartctl configure self test
smartd howto

et tu verras que ce n’est pas simple à comprendre et à configurer.

Tu peux te dire naïvement que tout est bien configuré par défaut et que tes médias seront toujours impeccables. Sinon, il va falloir investir en temps et faire quelques essais. À toi de choisir.

S.M.A.R.T. est une belle avancée technologique, mais il est dangereux de lui attribuer des mérites indus.

BADBLOCKS

Le programme Linux badblocks a été créé en même temps que le paquetage e2fsprogs (mkfs.ext2, mkfs.ext3, mkfs.ext4, fsck.ext2…). À l’époque S.M.A.R.T. n’existait pas et il n’y avait pas de mapping entre les adresses logiques et physiques. C’est le file-system qui devait tout gérer quand il détectait un bloc défectueux, notamment la mise du bloc en liste noire. C’est pour cela que mke2fs et e2fsck lancent un badblocks « dur » quand on leur spécifie deux fois l’option -c. Cela dure trèèès longtemps car les paramètres par défaut ne sont plus bien optimisés.

Depuis l’arrivée de S.M.A.R.T., certains considèrent badblocks comme obsolète. Mais qui peut affirmer que TOUS les médias utilisés par TOUS les usages de Linux sont équipés de S.M.A.R.T. ?
Peut-être qu’au M.I.T. avec un réseau de classe A, on ne s’abaisse pas à utiliser une clé USB ou un RaspberryPi. Je me demande dans quel type de bulle vivent ceux qui pensent que S.M.A.R.T. est sur tous les médias de stockage.

Quand j’achète une clé USB, je lui passe badblocks dessus et s’il y a des mauvais blocs, je la rends et je me fais rembourser.
J’ai essayé d’interroger les fonctionnalités S.M.A.R.T. de diverses clés USB et je n’ai rien obtenu, comme si cette utilité n’y était pas installée :

# smartctl --scan-open
# smartctl -x /dev/sdc
# smartctl -i -d scsi -T verypermissive /dev/sdc

Mes recherches sur Internet n’ont abouti à rien qui me permette de voir une réponse de la part de clés USB. Peut-être que si j’achetais (cher) des clés USB de très haute qualité, j’y trouverais S.M.A.R.T. ?

Comme l’intervenant du message #25 de ce rapport de bug (en), je pense que badblocks est loin d’être obsolète.
J’ai envie d’imiter le message #20 juste au-dessus en disant : « Je dois demander --- ***pourquoi*** vous (et d’autres personnes) mettez de l’essence dans vos voitures en 2024 ? L’essence en tant que chose a commencé à devenir inutile pour les voitures vers 2011, lorsque la voiture électrique s’est répandue, et que les batteries sont devenues suffisamment énergétiques pour faire rouler des véhicules sur des centaines de km ».

Je t’invite aussi à une recherche sur la liste de mots « courbe en baignoire composants électroniques ». Le programme badblocks peut servir au déverminage. On sait en détail ce qu’il fait. Son résultat est clair, contrairement aux implémentations propriétaires de S.M.A.R.T..
Sans déverminage (rodage) on court le risque de subir trop tôt une réparation discrète incomplète : le secteur réparé sera physiquement bon mais son contenu sera corrompu. La conséquence peut être catastrophiquement discrète. Par exemple, un fichier LibreOffice est une archive zip (compressée), la corruption d’un seul bit y a des conséquences imprévisibles.

De mon côté, j’utilise badblocks pour tester les médias nouvellement acquis et pour effacer ceux bons à réformer. Ce programme permet aussi la chasse aux médias « fake-size », du genre carte SD de 1To qui accepte de recevoir 1To de fichiers, mais qui ne stocke en réalité que 8Go. On trouve de nos jours (juin 2024) des clés USB de 16To vendues au prix de 5 € ! L’application h2testw sous windows et son équivalent f3 sous linux sont spécialement conçus pour cette chasse. Le microprogramme de ces clés USB ou de ces disques a été détourné pour déclarer un espace de stockage falsifié. C’est de l’escroquerie.

BADBLOCKS2

Mon usage du badblocks du paquetage e2fsprogs-1.47.0 m’a amené à y caractériser un bug reproductible en novembre 2023. J’ai eu l’intention de remonter le bug aux équipes ad hoc de ma distribution (Mageia) mais je me suis d’abord mis à regarder le source.

J’y ai trouvé l’origine du bug, et j’ai trouvé d’autres bugs. En ajoutant des instructions de traçage et de simulation d’erreurs du média, j’ai mis en évidence encore d’autres bugs. De fil en aiguille, j’ai fini par retoucher profondément certains algorithmes, et j’ai appelé badblocks2 cette nouvelle version. J’y ai ajouté diverses options faciles à programmer et commodes à l’usage. J’ai copieusement testé.

Si tu veux essayer badblocks2 et/ou prendre connaissance de ma démarche, je livre tout sur mon site. Tu verras pourquoi je me suis rabattu sur la création d’une nouvelle version, plutôt que de faire remplacer l’ancienne (ce qui aurait profité à tous).
Tu peux te faire une idée des fonctionnalités ajoutées en consultant les *.8.txt .
Tu peux t’inspirer des tests décrits dans le fichier Alire.txt, tester diverses valeurs pour -c -t et voir l’effet sur la vitesse de traitement. Tu peux même jouer à arracher la clé en cours de test (Ctrl-C pour arrêter) !

J’espère que ce programme servira à d’autres que moi.

En pratique

Voici une suggestion d’actions à faire lors de l’acquisition d’un nouveau média (disque SSD, disque rotatif, clé USB, carte SD…). Les commandes doivent être lancées par l’opérateur root.
Avec cela, quand dans quelques années tu satureras le média, tu seras sûr que le dernier secteur utilisé aura été déverminé avant la mise en production.

ATTENTION : les usages de badblocks proposés sont destructifs pour les données présentes sur le média. Le mode non-destructif du badblocks actuel comporte des bugs (version e2fsprogs-1.47.0). Celui de badblocks2 a été corrigé.
ATTENTION : la liste des mauvais blocs renvoyée par le badblocks actuel est fausse (version e2fsprogs-1.47.0). Le nombre de mauvais blocs est correct. La liste renvoyée par badblocks2 est correcte.
ATTENTION : le paramètre device du média est supposé être /dev/sdc. Ne pas se tromper, au risque d’effacer un autre média en cours d’usage.

D’abord déterminer le block-size du noyau, c’est une bonne valeur à prendre comme block-size du file-system :

# blockdev --getbsz /dev/sdc

Dans ce qui suit, je suppose que la valeur 4096 a été renvoyée.

Ensuite déterminer si S.M.A.R.T. est sur le média :

# smartctl --scan-open
# smartctl -x /dev/sdc
# smartctl -i -d scsi -T verypermissive /dev/sdc

Si S.M.A.R.T. n’est pas sur le média

Passer badblocks2 pour voir s’il y a 0 ou peu de mauvais blocs :

# badblocks2 -b 4096 -c 32768 -wrrvvss -t r -t r -e 40 -o /tmp/sdc.bb /dev/sdc

L’option -e peut être supprimée ou modifiée selon la limite du nombre de mauvais blocs considérée acceptable ; les options -t peuvent être différentes selon la sévérité souhaitée (voir le man).

S’il y a trop de mauvais blocs, refuser d’utiliser le média (->garantie ?).

S’il y a 0 mauvais bloc on peut formater en toute tranquillité (partitionner éventuellement avant) :

# mkfs.ext? -b 4096 ... /dev/sdc

S’il y a quelques mauvais blocs, sans que la limite -e soit atteinte, on pourra formater en utilisant la liste sauvée de mauvais blocs :

# mkfs.ext? -b 4096 -l /tmp/sdc.bb ... /dev/sdc

Si l’on veut partitionner, il faudra recalculer la liste des mauvais blocs de chaque partition avant de formater (remplacer sdc par sdc1 dans les commandes badblocks2 et mkfs.ext? ci-dessus).

Si l’on veut formater en vfat exfat ou f2fs (clés USB en général), il n’est pas possible d’utiliser la liste des mauvais blocs détectés ; la seule solution est de refuser d’utiliser le média s’il y a des mauvais blocs (ou alors de restreindre l’usage à une zone saine… à localiser)

Si S.M.A.R.T. est sur le média

On peut vérifier son activation par smartctl :

# smartctl -i /dev/sdc

Ensuite, il faut interroger le média sur l’état et les capacités de son S.M.A.R.T. :

# smartctl -a /dev/sdc

Noter le nombre de réallocations faites et prévues :

# smartctl -a /dev/sdc | grep -i _sector

Puis faire une passe de déverminage, en écriture+lecture car on ne sait pas si l’écriture seule suffit ; ne pas utiliser l’option -p de badblocks ; les options -t peuvent être différentes selon la sévérité souhaitée (voir le man) :

# badblocks2 -b 4096 -c 32768 -wrvvss -t r -o /tmp/sdc.bb1 /dev/sdc

Faire une passe de vérification, il ne devrait plus y avoir de mauvais blocs :

# badblocks2 -b 4096 -c 32768 -wrvvss -t r -o /tmp/sdc.bb2 /dev/sdc

S’il y a encore des mauvais blocs, c’est soit que le déverminage n’est pas terminé, soit que le média et/ou son S.M.A.R.T. sont foireux (il ne détecte pas les mauvais secteurs vus par badblocks2 ou les secteurs de réserve sont mauvais ou… pire) ; relancer des passes une par une jusqu’à ce qu’il n’y ait plus de mauvais bloc détecté.

Re-interroger S.M.A.R.T. pour voir l’évolution des réallocations :

# smartctl -a /dev/sdc | grep -i _sector

Ensuite on peut formater (partitionner éventuellement avant) en considérant que le média a remappé tous ses mauvais secteurs et est donc impeccable pour l’utilisation :

# mkfs.ext? -b 4096 ... /dev/sdc

Par la suite, on pourra de temps en temps consulter l’état de santé du média en service :

# smartctl -H /dev/sda

Si on est courageux, on peut lancer de temps en temps un contrôle du média par son S.M.A.R.T.
Si on est encore plus courageux, on configurera smartd pour que ces vérifications soient automatiques et pour que les alertes soient envoyées par courriel.

Attention à la communication entre l’O.S., S.M.A.R.T. et RAID (niveau carte mère / niveau OS / contrôleurs bas de gamme), voir la page Wikipedia sur S.M.A.R.T..

Que l’esprit « aware » soit en toi, sur tes données et sur ton espace de stockage

La Commission européenne a publié un avis préliminaire selon lequel Microsoft aurait enfreint les règles antitrust de l’UE en liant Teams à ses suites bureautiques, Office 365 et Microsoft 365, avec pour effet de limiter la concurrence sur le marché des outils de communication et de collaboration.

La Commission a constaté que Microsoft est en position dominante sur le marché mondial des suites bureautiques SaaS pour un usage professionnel. Elle s’inquiète du fait que, depuis au moins avril 2019, Microsoft inclut Teams dans ses suites bureautiques en SaaS, restreignant ainsi la concurrence sur le marché des produits de communication et de collaboration. Cette stratégie empêche les concurrents de Teams de rivaliser efficacement, réduisant ainsi l’innovation au détriment des clients dans l’Espace économique européen.

La Commission juge insuffisants les changements apportés par Microsoft à la distribution de Teams après l’ouverture de l’enquête en juillet 2023. Si ces accusations sont confirmées, elles constitueraient une violation de l’article 102 du Traité sur le fonctionnement de l’Union européenne (TFUE), qui interdit l’abus de position dominante. La Commission pourrait alors interdire ces pratiques et imposer une amende pouvant atteindre 10 % du chiffre d’affaires annuel mondial de l’entreprise, ainsi que des remèdes pour rétablir la concurrence.

Le logiciel gratuit et illimité de généalogie Ancestris vient de sortie en version 12. Il est placé sous licence GPL.

La v12 en quelques chiffres : plus de 1700 commits, trois ans de développement, et elle fonctionne sur tous les systèmes d’exploitation qui permettent d’installer Java de la version 8 à la version 22.

Nouveautés, évolutions, corrections et traductions sont détaillées en seconde partie de dépêche.

Nouveautés

• Gestion du GEDCOM 7 (complet pour l’éditeur GEDCOM et l’éditeur Cygnus).
• Affiche toutes les entités (même les entités non conformes) dans l’explorateur de GEDCOM et dans l’éditeur GEDCOM.
• Nouvelle traduction en hongrois
• Enregistrer sous : copie exacte ou partielle
• Possibilité de choisir l’inhumation à la place de la date de décès pour les affichages.
• Ajout d’une option pour zoomer l’ensemble de l’application.
• Choix du répertoire de sauvegarde
• Imports spécifiques pour : Elie, Aldfaer, RootsMagic, Ancestry.com, Brother's Keeper
• Ajout d’un gestionnaire de média
• Ajout d'un convertisseur de GEDCOM
• Refonte du module de recherche de doublons
• Réécriture du rapport calendrier
• Réécriture du rapport narratif
• Réécriture du rapport circulaire 10 générations avec sortie SVG.
• Ajout d’un rapport de ligne de vie individuel.
• Ajout d’un tri des entités à la sauvegarde et la possibilité de trier les propriétés d’une entité par date.
• Possibilité de créer un nouveau GEDCOM directement à partir des entités affichées dans une vue (Arbre, Graphe, time-line, Carte, Recherche, Groupes de famille)
• Réécriture du module de groupes familiaux avec nouvelles fonctionnalités (marquage, regroupements…)
• Ajout d’une possibilité d’ignorer les vérifications automatiques.
• Nouveau calcul de consanguinité et détection de boucles.
• Ajout d’une liste de dépôts d’archives par défaut.
• Export pour Genealogieonline.nl

Évolutions et corrections

• Ajout d’un symbole pour les divorces dans l’arbre graphique
• Améliorations de Cygnus
• Améliorations d’Ariès
• Amélioration de l’éditeur GEDCOM
• Améliorations du module d’ancêtres communs
• Ouverture d’un nouveau fichier provenant d’Ancestris sur le SOSA 1
• Ajout par défaut du tag FILE des entités médias dans la table des entités
• Conserve l’ordre de tri dans les écrans de recherche d’Ariès
• Recherche sans accents
• Correction du tutoriel de présentation s’il y a plusieurs écrans.
• Ajout de la recherche par époux dans la recherche avancée
• Ajout du marquage par chromosome X
• Amélioration de l’exploitation des liens des médias dans les éditeurs.
• Amélioration de l’import Geneanet, geneatique et Heredis
• Améliorations de l’export Livre Web
• Améliorations de l’export Site Web
• Tri sur les dates dans la table des entités
• Ajout de séparateurs pour la gestion des marque-pages
• Améliorations et corrections de la carte géographique
• Ajout de filtres dans la vue graphe
• Permet de choisir une date de changement dans l’explorateur pour ne voir que les modifications postérieures.
• Améliorations du rapport d’arbre graphique multi-génération
• Améliore l’ouverture de fichier pour détecter et expliquer au mieux les problèmes rencontrés.
• Améliorations de l’export Geneanet
• Ajout d’un bouton de remise aux valeurs par défaut pour les réglages de la table des entités.
• Affichage de la première page des pdf à la place d’une image neutre.
• Conservation des options d’enregistrement d’un fichier d’une fois à l’autre.
• Ajout de l’impression de la vue en cours dans le menu « Outils ».
• Affiche les images de type JFIF
• Amélioration de la vue graphe sur les écrans à large résolution
• Possibilité de marquer les individus à partir de toutes les vues.
• Améliorations du module Relevé
• Ajout d’une préférence de durée maximale d’attente pour la vérification des liens internet
• Ajout d’icônes pour distinguer l’ajout d’une numérotation de l’affichage du Sosa 1.
• Correction de l’affichage en langue différente des rapports par rapport à l’interface.
• Utilisation des options des rapports avant de les lancer à partir du menu contextuel.
• Ajout d’un écran d’assistant pour la comparaison de généalogies.
• Possibilité de choisir le nombre de génération d’ascendants et de descendants séparément dans l’arbre dynamique.
• Ajout d’un nouveau template GedArt.
• Ajout d’un dégradé par date dans la carte géographique
• Ajout d’un paramètre pour limiter la longueur d’un champ dans un calque.
• Ajout d’un menu avec les derniers fichiers ouverts
• Ajout de la possibilité de souligner des champs dans les calques.
• Amélioration de la gestion des almanachs.

Mise à jour de traduction

• Allemand
• Anglais
• Castillan
• Catalan
• Danois
• Français
• Grec
• Hongrois
• Italien
• Néerlandais
• Polonais
• Portugais
• Tchèque
• Turc

Merci à tous les traducteurs pour leur travail constant, si important pour l’ensemble de la communauté.

Pour conclure, merci à toute la communauté par vos remarques, vos demandes, vos remontées d’anomalies, vous permettez de faire vivre et embellir ce logiciel.
On compte sur vous dans la suite pour nous créer du buzz, des tutoriels, des idées et de l’enthousiasme.

XL-Converter est un utilitaire graphique pour convertir vos images en formats utilisables sur Internet. Outre les classiques JPEG et PNG il y a donc AVIF, WEBP et JPEG-XL. L’outil se veut ergonomique avec un minimum d’options pratiques. Par exemple on peut indiquer une dimension ou un poids maximum pour les images. À mes yeux, l’intérêt d’XL-Converter c’est surtout le format Jpeg. Pourquoi ? parce que ce format est loin d’être mort : tout en travaillant sur Jpeg-XL, les chercheurs suisses de Google ont développé un nouvel algorithme d’encodage du Jpeg classique, et cet algo est très performant.

Jpegli, le nouvel algo, tire son nom du jargon suisse, tout comme guetzli, butteraugli, etc. par la même équipe. Il est inclus dans la version 0.10 de la libjxl, la bibliothèque de référence pour Jpeg-XL (c’est normal il en réutilise du code). Et par là, il se retrouve l’encodeur Jpeg de XL-Converter.

Jpeg est un format de compression qui date des années 80. C’est grâce à lui qu’on voit le web en couleur. On a souvent tenté de le remplacer, il résiste. C’est normal, non content d’offrir un bon rapport qualité/poids, il y a belle lurette que nos puces décodent les images Jpeg en un éclair. Jpeg est donc efficace et rapide, sa compression avec perte n’enlève que des détails invisibles à nos yeux. Enfin il a des défauts quand même : pour gagner encore plus de poids, il gomme encore plus de détails et nous laisse des artefacts bien visibles, qui ressemblent à des saletés dans l’œil, celles qu’on découvre en regardant un mur blanc. En principe je ne vous apprends rien, vous êtes habitués à optimiser le poids de vos images sur Internet et vous savez jouer du curseur pour obtenir le meilleur compromis pour la meilleure image Jpeg possible (© Voltaire).

Nos accès Internet deviennent sans cesse plus rapides, la puissance et la Ram sur nos ordis augmentent de même, les nuisances énergétiques itou. Ça m’importe. Et même si les nuisances vous indiffèrent, vous vous êtes peut-être déjà retrouvé pris au piège d’une zone blanche, ou bien sur une île surpeuplée de touristes en été, ou bien dans un pays lointain aux prises avec un vieil ordi malmené par les débits inconstants et la lourdeur de votre site web préféré, bref dans ma peau. La situation est tout de même assez commune pour qu'un des critères majeurs de bon référencement des pages web sur Google soit le temps de chargement et d’affichage¹.

Normalement vous savez qu’il y a plusieurs facteurs là-dedans, matériels, logiciel et humain. Humain, voilà ce qui nous intéresse. C’est l’humain qui fait l’effort de soigner son code, d’utiliser un format qui décompresse vite, de redimensionner ses images et de compresser suffisamment, en acceptant des pertes que l’autre internaute ne verra jamais sur un écran non calibré, salis par les doigts, sous un éclairage douteux et le plus souvent coloré (dans les villes).

Il y a quelques mois, je pensais vous décrire les merveilles de Mozjpeg : les premières versions de Webp n’avaient pas convaincu Mozilla qui avait proposé un nouvel algo et un nouvel outil, plutôt efficace. En remplaçant purement et simplement la libjpeg, les gains en compression était du même niveau que Webp (à l’époque), mais pour ceux qui aimaient jongler avec les paramètres², les gains étaient et sont toujours bien meilleurs. Tout le monde n’étant pas imageo-technophile, les feignants pouvaient se contenter d’utiliser ImageOptim pour un résultat équivalent.

Aujourd’hui, même les feignants n’ont pas d’excuses : Jpegli est super simple à utiliser³, plus rapide et meilleur que Webp ou Avif, produit beaucoup moins d’artefacts classiques du Jpeg et se décode à la vitesse de l’éclair puisque c’est du Jpeg normal. Et au sein d’XL-Converter c’est de la balle.

Je n’ai rien de plus à dire. En attendant Jpeg-XL dans tous nos navigateurs, Jpeg à la sauce Jpegli c’est trop bon, mangez-en.

En apéritif, goûtez donc cette petite note du divin Jon Sneyers :

More recently, the JPEG-XL team at Google has built yet another JPEG encoder, jpegli, which is both faster and better than even mozjpeg. It is based on lessons learned from guetzli and libjxl, and offers a very attractive trade-off: it is very fast, compresses better than WebP and even high-speed AVIF, while still producing good old JPEG files that are supported everywhere.

N. D. M. : nlgranger nous explique dans le journal qui est repris pour cette dépêche comment virtualiser un système pré-installé. Son expérience personnelle est relatée ici à la première personne (je). Rappelons aussi à tout hasard que si la licence de ce système d’exploitation propriétaire permet apparemment une utilisation dans le cadre d’une telle virtualisation, celle-ci doit être faite sur une seule instance et sans utilisation comme serveur (ce que rappelle aussi le tutoriel mentionné plus loin, mais sur une version précédente du système). Et qu’il n’est possible de faire qu’une « seule copie du logiciel à des fins de sauvegarde ».

Je viens d’acheter un PC et bien que j’aie fouillé et patienté longtemps, aucune offre sans OS n’arrivait ou ne convenait donc j’ai cédé à la vente forcée d’un PC avec Windows.
Dans ce petit tutoriel, je vous explique comment déplacer cette licence Windows OEM vers une machine virtuelle (VM) sur le même PC. Si vous avez déjà une licence achetée à part, il vous suffit de la spécifier à l’installation, on s’intéresse ici au cas des licences OEM préinstallées sur la carte mère.
L’intérêt de déplacer Windows dans une VM, c’est de ne pas bloquer une partie de l’espace disque avec une partition qui ne servira quasiment jamais. Là on peut déplacer l’image disque vers un stockage externe (disque ou clé USB) ou recréer la VM au besoin.
Dans ce tutoriel j’utilise libvirt via le GUI virt-manager, mais je me suis largement appuyé sur cet excellent tutoriel pour Proxmox d’Oliver Poncet que je vous invite à consulter.
Je précise immédiatement qu’il n’est pas nécessaire d’avoir gardé le Windows préinstallé sur la machine, ni même de l’avoir démarré une seule fois.

Dépendances

Pour parvenir à vos fins, il vous faudra les dépendances suivantes (en espérant ne rien oublier) :

• dmidecode pour lire les infos de la carte mère
• libvirt
• qemu/KVM
• swtpm pour émuler un TPM
• edk2-ovmf pour émuler un UEFI avec Secure Boot
• Le fichier.iso de Windows 11 disponible sur le site de microsoft.

Sous ArchLinux : pacman – S dmidecode libvirt dnsmasq qemu-desktop swtmp

J’ai utilisé virt-manager pour me faciliter la vie, j’imagine qu’on peut s’en sortir en ligne de commande directement avec qemu.

Installation

Récupérer les informations utiles

Pour valider automatiquement votre licence, Windows utilise des informations disponibles depuis la carte mère.

D’abord, le numéro de série, modèle, etc. :

$ sudo dmidecode
…
BIOS Information
    Vendor : LENOVO
    Version : NCCN16WW
    Release Date : 02/02/2024
…
    BIOS Revision : 1.16
    Firmware Revision : 1.16
…
System Information
    Manufacturer : LENOVO
    Product Name : 83E3
    Version : Yoga Pro 7 14AHP9
    Serial Number : 9F5OEMTZ
    UUID : a0a73af8-a886-4fbf-8f0d-5fd32c264a16
    SKU Number : LENOVO_MT_83E3_BU_idea_FM_Yoga Pro 7 14AHP9
    Family : Yoga Pro 7 14AHP9

(j’ai édité le serial et l’uuid)

Ensuite des informations enregistrées dans des tables ACPI :

sudo cat /sys/firmware/acpi/tables/MSDM > ~/VMs/MSDM.bin
sudo cat /sys/firmware/acpi/tables/SLIC > ~/VMs/SLIC.bin

Créer la VM

La procédure démarre comme d’habitude, on suit l’assistant de virt-manager jusqu’au moment où il faut bien demander à modifier la configuration avant de démarrer.

Dans les options du BIOS, choisissez la config avec Secure Boot activé, chez moi le fichier se nomme OVMF_CODE.secboot.4 m.fd.

Ensuite il faut éditer directement le code XML qui décrit la configuration de la machine. Si c’est la première fois dans virt-manager, il faut cocher une case dans les paramètres de l’appli pour le rendre éditable.

Pour commencer, modifiez le nœud racine XML pour spécifier le schéma, sinon certaines options seront rejetées :

<domain type=“kvm” xmlns: qemu='http://libvirt.org/schemas/domain/qemu/1.0'>

Mettez aussi à jour l’uuid pour qu’il corresponde à celui indiqué par dmidecode:

<uuid>a0a73af8-a886-4fbf-8f0d-5fd32c264a16</uuid>

Ensuite, il faut indiquer à qemu d’intégrer les tables ACPI :

<qemu: commandline>
<qemu: arg value='-acpitable'/>
<qemu: arg value='file=/home/ngranger/VMs/MSDM.bin'/>
<qemu: arg value='-acpitable'/>
<qemu: arg value='file=/home/ngranger/VMs/SLIC.bin'/>
</qemu: commandline>

Puis il faut ajouter les informations de la carte mère :

<sysinfo type=“smbios”>
<bios>
<entry name=“vendor”>LENOVO</entry>
<entry name=“version”>NCCN16WW</entry>
<entry name=“date”>02/02/2024</entry>
<entry name=“release”>1.16</entry>
</bios>
<system>
<entry name=“manufacturer”>LENOVO</entry>
<entry name=“product”>83E3</entry>
<entry name=“version”>Yoga Pro 7 14AHP9</entry>
<entry name=“uuid”>a0a73af8-a886-4fbf-8f0d-5fd32c264a16</entry>
<entry name=“serial”>9F5OEMTZ</entry>
<entry name=“family”>Yoga Pro 7 14AHP9</entry>
<entry name=“sku”>LENOVO_MT_83E3_BU_idea_FM_Yoga Pro 7 14AHP9</entry>
</system>
</sysinfo>

Installation de Windows

La procédure est désormais habituelle.

Pour éviter d’avoir à utiliser un compte Microsoft, vous pouvez couper Internet au moment où Windows redémarre pour la configuration du système. Lorsque l’assistant en arrive à la connexion au réseau, tapez Maj-F10 pour ouvrir le terminal et exécutez la commande oobe\BypassNRO. Le PC redémarrera sur un assistant qui rend la connexion facultative.

Au démarrage, vous pourrez remettre Internet et vérifier que la licence est bien activée.

Comme beaucoup de domaines scientifiques, la documentation de la diversité linguistique entretient une relation forte avec les mondes du Libre. Dans cette dépêche, je vous propose de découvrir ce domaine à travers la présentation de plusieurs logiciels et ressources libres ou en accès ouvert. La documentation des langues étant un thème peu courant sur LinuxFr.org, on commencera par une présentation de cette problématique. Nous continuerons par une description des deux ressources principales existantes pour cataloguer et se repérer au sein de cette diversité linguistique. Je parlerai ensuite d’ELAN et de FLEX, deux logiciels utilisés pour annoter des enregistrements audio-visuels, une étape clef dans l’analyse linguistique, et qui permet le partage et la réutilisation de ces enregistrements. Enfin, après un court passage sur la question de l’archivage, je présenterai deux compilations de corpus de documentation en accès libre, une pratique récente qui permet de nouveaux questionnements quantitatifs sur les langues orales peu documentées, et qui contribue également à la transparence et la traçabilité des analyses linguistiques.

Sommaire

• L’étude des langues à travers le monde
• Quelques concepts et termes liés à la documentation des langues
• Les catalogues et base de données pour l’identification des langues
  • • L’Ethnologue et l’ISO 639 : une norme gérée par le Summer Institute of Linguistics (SIL)
    • Glottocode : par le Max Planck Institute for Evolutionary Anthropology.
    • Les autres
• Documenter les langues
  • ELAN : des schémas d’annotation flexibles
  • FLEX : gérer un projet de documentation
  • Et il y en a bien d’autres encore
• L’archivage et la compilation de corpus
  • DoReCo
  • Multi-CAST
• Conclusion

L’étude des langues à travers le monde

Actuellement, environ 7000 langues ont été recensées à travers le monde. Ce chiffre ne peut être qu’une approximation car, il n’y a pas de consensus sur la définition de ce qu’est une langue. Une difficulté par exemple est de définir à quel moment une langue est distincte d’une autre. Lorsqu’il y a variation, mais intercompréhension, de nombreux linguistes s’accordent à dire qu’il s’agit alors de dialectes d’une même langue, et donc, lorsqu’il n’y a pas intercompréhension, alors il s’agit différentes langues. Cette perspective considère que tout le monde parle un dialecte (que ce soit celui de référence, ou un plus régional comme celui de Paris, de Marseille, du Québec), la langue n’étant qu’une abstraction permettant de regrouper les diverses pratiques langagières. En ce qui concerne l’intercompréhension, ce critère n’est malheureusement pas absolu car elle peut varier selon les personnes et leur parcours personnel. Et lorsqu’on considère l’évolution d’une langue à travers le temps, sa diachronie, définir ce qu’est une même langue à travers ses évolutions temporelles se complexifie d’autant plus.

Si certaines langues ont émergé récemment, on pense assez souvent aux langues dites créoles (le Bichelamar, les créoles malais, à Madagascar ou au Cap Vert), ou également lorsque certains dialectes se distinguent suffisamment pour ne plus être intercompréhensibles, la tendance actuelle est surtout à la disparition massive des langues. Cette disparition est souvent rapportée à travers la mort des derniers locuteurs et locutrices, on peut aussi considérer qu’une langue meurt lorsqu’elle n’est plus parlée d’une part, et qu’elle disparait si elle n’est pas documentée. Si certains aujourd’hui se questionnent sur la corrélation entre la diversité culturelle et la diversité écologique, il est évident que la disparition des langues correspond également à des inégalités et des tensions socio-politiques.

Bref, la documentation des langues, c’est un sujet actuel, et d’un point de vue scientifique, la perte de cette diversité aura de tristes conséquences sur la connaissance des langues et de l’univers des possibles languagiers, encore souvent sous-estimé :

• l’article The myth of language universals : Language diversity and its importance for cognitive science d’Evans donne un bel aperçu du débat qui existe entre les linguistes fonctionnalistes, notamment les approches générativistes telles que proposées par Noam Chomsky. Pourtant, régulièrement à travers la documentation des langues, des catégories cognitives jusque-là non-soupçonnés, voire rejetées car non-observées, sont identifiés. Nous nous sommes rendu compte récemment qu’un quart des langues grammaticalisaient l’emploi d’évidentiels, ces morphèmes qui indiquent la source d’une information. Au niveau de l’odorat, des neurologistes pensaient que si nous n’avions pas de termes abstraits pour catégoriser les odeurs, c’était lié au fait que notre cerveau ne le permettait pas. La description des termes liés à l’odorat en Jahai (par ici si vous souhaitez écouter du Jahai), qui possède donc des termes spécifiques pour catégoriser les odeurs, a montré le contraire.
• accéder à des facettes non-matérielles de la préhistoire, non-accessibles à travers l’archéologie. La documentation des langues nous permet d’accéder, dans une certaine mesure, aux termes et aux concepts utilisés durant les différentes préhistoires à travers la comparaison des langues et de leurs structures. Les travaux sont nombreux et anciens en ce qui concerne les langues européennes, mais les recherches en linguistique historique (ou comparée) portent également sur toutes les langues connues à travers le monde. Les chercheurs et chercheuses de ce domaine collaborent assez régulièrement avec les archéologues pour retracer les mouvements de population.
• mettre au point des systèmes d’écriture pour les langues orales, ou simplement des traitements de texte adapté aux écritures existantes. Parfois, certaines personnes savent écrire dans la ou les langues officielles du pays, mais ne connaissent pas d’écriture pour une de leurs langues régionales. C’est ainsi souvent le cas pour les personnes au Vanuatu. Le pays reconnait même le droit d’enseigner les langues locales à l’école, mais il n’existe que très rarement des ressources (que ce soit les personnes ou les manuels) pour cela. Parfois, les gens ne connaissent tout simplement pas de système d’écriture.

Quelques concepts et termes liés à la documentation des langues

Comme tout domaine de recherche, la terminologie et les concepts linguistiques évoluent au gré des discussions et peut se distinguer de l’usage attendu des termes. Une étape importante dans la documentation d’une langue est la production d’une grammaire décrivant les structures linguistiques de cette langue. De nombreux linguistes estiment alors qu’on peut dire que cette langue est décrite. Il ne faut pas se tromper cependant, aucun linguiste ne considère qu’une langue est alors complètement décrite. Une grammaire ne contient que quelques aspects estimés actuellement essentielles par les linguistes de terrain. Ces points sont, le plus souvent, une description du système phonologique d’une langue (c’est-à-dire comment les sons d’une langue sont organisés les uns vis-à-vis des autres), des morphèmes et des processus morphologiques associés (la conjugaison, l’expression de la possession, les déclinaisons, les genres, les classifications, etc.) d’une langue et souvent un début de description des processus syntaxiques. Il existe de nombreuses approches pour décrire les faits linguistiques, et la description d’une langue se fait souvent en dialogue avec les pratiques et terminologies qui ont été employées dans l'aire linguistique concernée.

Depuis l’article Documentary and descriptive linguistics de Nicholaus Himmelman, qui a promu la distinction entre la documentation linguistique et la description linguistique, on accorde beaucoup plus d’importance à la production d’un corpus d’enregistrements annotés. On dit alors d’une langue qu’elle est documentée si des enregistrements annotés, de préférences audio-visuels, de cette langue existe. Enfin, il existe la problématique de l’outillage d’une langue, c’est-à-dire si ses locuteurs et locutrices ont accès ou non aux outils informatisés, du traitement texte aux dictionnaires informatisés en passant par la reconnaissance vocale, la transcription automatique, voire aujourd’hui aux modèles de langues et autres ressources nécessitant des corpus beaucoup plus grands.

Les catalogues et base de données pour l’identification des langues

Une problématique récurrente dans le domaine des langues est de clairement identifier la langue sur laquelle on travaille. Cependant, identifier une langue, ce qui relève ou non de cette langue, où elle est parlée, est l’enjeu de nombreux débats, souvent politique, et n’est pas une tâche simple. Quoi qu’il en soit, il existe des ressources, bases de données, qui proposent d’associer à des noms de langues, endonymes ou exonymes, des codes pour rendre leur identification univoque.

L’Ethnologue et l’ISO 639 : une norme gérée par le Summer Institute of Linguistics (SIL)

Ethnologue, Languages of the World, ou plus simplement l’Ethnologue, est une base de données développée et maintenu par l’organisme évangélique SIL, Summer Institute of Linguistic depuis 1951. Elle vise à recenser toutes les langues du monde. L’ISO 639 est une norme issue de ce catalogue, également maintenue par le SIL. Cet organisme est très actif au niveau de la documentation des langues et de la création d’écritures, car un de ses objectifs est de traduire la Bible dans toutes les langues du monde. Historiquement, l’Ethnologue est un des premiers catalogues dont l’objet a été de recenser les langues. Si cette norme semble le plus souvent suffisamment exhaustive pour les besoins liés à l’informatique, après tout, les internautes consultent Internet en très peu de langue, d’un point de vue linguistique, il possède de nombreuses lacunes.

Un premier souci est la nécessité d’avoir une granularité plus importante que simplement la langue. Les linguistes travaillent sur des dialectes et des variétés, sur des familles de langues, et parfois ont travaillé sur des distinctions qui n’ont parfois plus cours. Afin de pouvoir associer ces ressources à des langues, ou des entités linguistiques particulières, l’approche du SIL ne suffit pas.

Enfin, la gestion du catalogue par un organisme religieux, donc avec parfois d’autres enjeux qu’uniquement scientifiques, le fait qu’il s’agisse d’une norme, donc la nécessité de collaborer avec l’ISO, et le fait que seule une partie du catalogue est accessible (il faut un abonnement pour accéder à la totalité de la ressource) rend la ressource moins pertinente pour de nombreux linguistes. Ces limites ont poussé des linguistes à proposer une ressource alternative.

Glottocode : par le Max Planck Institute for Evolutionary Anthropology.

Le projet Glottolog, initialement développé par Sebastian Nordhoff et Harald Hammarström, catalogue non seulement les langues du monde actuelles et passés, les familles de langues et leurs différentes branches, mais également « les restes » des hypothèses de langues ou de regroupements historiques. Cette granularité permet de retrouver les documents associés à chacun de ces objets. Si le catalogue est dédié aux langues moins connues, les langues les plus centrales sont elles aussi répertoriées. Il s’agit actuellement du catalogue mis en avant par les linguistes documentant les langues à travers le monde. L’application Glottolog est disponible via la licence MIT.

Si aux premiers abords, la liste des langues du Glottolog ne se distingue pas franchement de celle de l’ISO 639, c’est parce qu’il faut regarder plus en détail pour comprendre les différences essentielles entre les deux ressources. Notons tout de même la colonne « Child dialects » : « Dialectes enfants », et les champs vides au niveau des colonnes Top-level-family et pour la langue Abai Tubu-Abai Sembuak dans la colonne « ISO-639-3 ». La colonne « Child dialects » représente une information qui n’est pas documenté dans l’ISO 639, ce n’est pas son objet après tout, mais qui est intéressant pour les linguistes travaillant sur cette langue, indiquant qu’un minimum de données sociolinguistiques sont disponibles. Les champs vides dans la colonne « Top-level family » sont dus au fait que ces langues sont des isolats, c’est-à-dire que la linguistique comparée ne trouve pas de correspondances significatives entre cette langue et d’autres langues qui permettraient de les regrouper en une famille. Enfin, le vide dans la colonne ISO-963-3 révèle que la langue Abai Tubu-Abai Sembuak ne possède pas d’entrée dédiée dans la norme.

Ainsi, lorsque l’on consulte une langue en particulière, ici le Nisvai, on voit apparaitre tous les embranchements existants associés à cette langue :

Cette vue de l’arborescence associée à une langue particulière révèle tous les embranchements auxquels peut⁻être associée une langue. Et à chacun de ces embranchements, si des ressources linguistiques ont été identifiées par les mainteneurs du Glottolog, celles peuvent être proposées. Cette fonction permet aux linguistes de trouver des ressources sur les langues proches, non pas géographiquement (même si en pratique c’est le plus souvent le cas), mais d’un point de vue généalogique.

Les autres

Il existe d’autres initiatives pour cataloguer les langues du monde, que ce soit la liste proposée par Wikipedia, la liste de la CIA ou encore The Linguasphere Register, mais ces initiatives ne sont pas aussi pertinentes du point de vue de la documentation des langues.

Documenter les langues

ELAN : des schémas d’annotation flexibles

ELAN est un des logiciels libres (GPL3) les plus utilisés par les linguistes pour annoter des enregistrements audio et vidéo. Il permet d’élaborer des structures d’annotation complexes permettant ainsi de rendre compte des analyses que les linguistes souhaitent associer à un enregistrement. Ces couches d’annotation sont reliées les unes aux autres par des relations logiques, avec le plus souvent une couche de référence indexée temporellement à l’enregistrement. Les annotations les plus courantes sont une transcription, une traduction et une annotation morphologique. Mais des nombreuses autres analyses peuvent être incluses, que ce soit les parties du discours, les références et anaphores, l'animéité, mais aussi les gestes, la structuration du discours, les signes pour les sourds et malentendants.

Dans cette capture d’écran issu d’un texte de DoReCo retravaillé par l’auteur, on aperçoit un extrait de quelques secondes d’une narration nisvaie. Il s’agit d’un des modes de visualisation des annotations proposées par ELAN pour représenter les différentes couches d’annotation. Certaines de ces annotations ont été réalisées à la main par l’auteur, d’autres ont été retravaillées par les algorithmes mis en place par DoReCo, puis manuellement corrigés. Enfin, il y a également des couches d’annotation de la prosodie par le biais de SLAM+.

FLEX : gérer un projet de documentation

FLEX est un logiciel développé par le SIL et dont le code source est régie par la licence LGPL 2.1. Il est conçu davantage pour coordonner l’ensemble d’une documentation linguistique, de la gestion des textes à l’élaboration d’un dictionnaire, en passant par les analyses linguistiques. En revanche, il ne gère pas réellement l’annotation d’enregistrements. De nombreux linguistes l’utilisent en complément d’ELAN.

Si le logiciel est prometteur sur le papier, à chaque fois que je l’ai essayé, j’ai été rebuté par son côté usine à gaz, et surtout ses nombreux plantages notamment lorsqu’on essaie de gérer des fichiers multimédia avec. Et il en est de même pour les autres logiciels développé par le SIL, tel que SayMore pour gérer les métadonnées des enregistrements, WeSay pour faire des dictionnaires en collaboration avec les locuteurs et locutrices, à chaque fois que je les ai essayés, enthousiasmé par leurs fonctionnalités, j’ai été déçu par le fait qu’ils ne fonctionnaient pas correctement sur mon ordinateur.

Cette capture d’écran illustre un des modes de saisie de FLEX, ici la vue tabulaire du lexique, qui permet de rentrer et gérer les définitions des lexèmes (les entrées du dictionnaire) de manière assez rapide. On aperçoit dans la partie en haut à gauche les autres modes d’édition du lexique, et en dessous les autres catégories liées à la gestion d’un projet de documentation : Texts & Words, Grammar, Notebook et Lists. C’est à travers la catégorie Texts & Words que l’on peut par exemple importer des textes transcrits, voire des fichiers ELAN pour peupler la base de données lexicales. Grammar permet de décrire les paradigmes grammaticaux, FLEX propose d’ailleurs quelques algorithmes qui aident à la construction des paradigmes grammaticaux. Notebook et Lists servent à la gestion du projet, le premier pour prendre des notes diverses, et le second pour créer des listes, en particulier des tâches encore à réaliser.

Et il y en a bien d’autres encore

Il existe de nombreux autres logiciels similaires, tels qu’EXmaralda pour l’annotation des enregistrements (surtout utilisé en Allemagne à ma connaissance), Sonal (non libre, et dont le développement semble arrêté) qui est utilisé par les sociologues et les anthropologues pour une annotation thématique de leurs entretiens, Anvil, qui semble intéressant mais que je n’ai jamais réellement vu utilisé, ou enfin le vieux Transcriber qui lui était encore employé par certains projets il y a quelques années. Rentrer dans le détail de tous ces logiciels dépasserait le cadre d’une dépêche comme celle-ci, mais énumérer la diversité logicielle montre qu’il s’agit d’un secteur un minimum dynamique, d’ailleurs la question de la transcription et de l’annotation des enregistrements ne se limite pas du tout qu’au domaine de la documentation des langues du monde.

L’archivage et la compilation de corpus

Afin de conserver et partager les corpus et donnée enregistrées par les linguistes, chercheurs voire simplement les personnes ayant documenté une langue, il existe des archives, le plus souvent en ligne. Il y a en France par exemple Pangloss, géré par le LACITO, dédié aux langues orales, ou ORTOLANG, plus générique, pour les corpus de langue. En Océanie, il y a Paradisec. Il y a aussi ELAR, autrefois à Londres, et qui a déménagé récemment à Berlin récemment.

Ces archives proposent diverses interfaces pour déposer, gérer et parfois même consulter les enregistrements et les annotations réalisés par les linguistes et leurs collaborateurs·e·s. À noter que pour ces archives, Ortolang décrit son architecture logicielle qui repose sur des briques ouvertes, en revanche concernant Paradisec et Pangloss, bien que leur statuts soient sûrement similaires du fait de la démarche générale de ses ingénieurs, je n’ai pas trouvé de liens vers les logiciels employés. Quant à ELAR, le logiciel utilisé est Preservica, une solution propriétaire qui, quand on a le malheur de devoir l’utiliser, fonctionne bien lentement.

La compilation de corpus, si elle se rapproche de l’archivage en ce qu’il s’agit également de recueillir, conserver et publier les corpus des linguistes, correspond également à une édition particulière de ces corpus. La compilation de corpus est réalisé à travers la mise en place de processus de qualité, d’annotations et de conventions particulières. Les deux compilations de corpus présentées ici sont des compilations de corpus de documentation de langues orales. Les enregistrements ont été systématiquement annotés en utilisant une convention nommée les gloses interlinaires (le nom fait en fait référence à la pratique ancienne d’insérer des explications entre les lignes d’un texte. En pratique aujourd’hui, ce n’est plus vraiment ce que font les linguistes, puisque le travail est informatisé et les annotations ne sont plus entre les lignes, mais, le terme a cependant été conservé).

DoReCo

DoReCo est une compilation de 52 corpus en accès ouvert (NdR : auquelle l’auteur a contribué). La compilation a nécessité la mise en place de processus de qualité afin d’assurer la cohérence de l’ensemble et de fournir un certain nombre de garanties quant aux qualités du corpus.

Une première qualité, et l’une des originalités de DoReCo, est de proposer un alignement temporel est très fin. La durée de chaque phonème, de chaque morphèmes, de chaque mot (ici suivant la définition de la personne à l’origine du corpus, car la définition d’un mot n’a rien d’une évidence) et enfin de chaque groupe de souffle est fournie. Une deuxième qualité a été de s’assurer que pour l’ensemble des retranscriptions, chacun des termes et des morphèmes possède une glose, c’est-à-dire qu’ils possèdent une explication linguistique.

La compilation totalise une centaine d’heures d’enregistrements audio, en grande majorité des narrations monologiques. À noter que les corpus de la compilation sont accès ouvert, via une licence Creative Commons, mais que les droits d’utilisation varient d’un corpus à l’autre. Les données sont accessibles aux formats d’ELAN : .eaf, de Praat : . TextGrid, TEI.xml, et.csv.

Multi-CAST

Multi-CAST est également une compilation de 18 corpus de documentation de langues différentes. Les textes annotés via le logiciel ELAN. Contrairement à DoReCo, l’alignement temporel des annotations n’est pas réalisé de manière précise, mais manuellement, par les personnes à l’origine du corpus, à l’échelle de l’énoncé. Les textes sont également en grande majorité des narrations monologiques. L’originalité de cette compilation de corpus vient du fait que les textes contiennent trois couches d’annotation particulières : GRAID, Grammatical Relations and Animacy in Discourse, (voir), puis RefIND et ISNRef (Referent Indexing in Natural Language Discourse, voir Schiborr et al. 2018).

Cette compilation de corpus est aussi disponible dans plusieurs formats. XML évidemment, puisque c’est le format natif d’ELAN, mais aussi TSV et il existe également un paquet pour R. Tout cela est disponible via la licence CC-BY 4.0.

Conclusion

J’espère que vous avez apprécié cette introduction à la documentation des langues à travers les logiciels libres. L’idée est surtout d’attiser la curiosité, car il reste évidemment encore de nombreux aspects ou points à discuter et à approfondir. La prochaine fois que j’aborderai le thème de la documentation linguistique ici, j’espère que ça sera pour présenter mon application basée sur Django pour faire de la lexicographie.

Il y a également un autre sujet sur lequel j’aimerais bien échanger ici prochainement : la question des licences des données collectés et la négociation lorsque l’on travaille avec des personnes à tradition orale. Si ouvrir l’accès aux données de recherche et aux corpus peut sembler être une évidence pour certains, il ne faut pas oublier que souvent, les chercheurs et chercheuses de terrain collectent des informations personnelles, que la connaissance n’est pas forcément considérée comme un bien public et les enregistrements, notamment les narrations, qui ne sont pas forcément perçues comme des fictions, sont souvent couverts par des droits locaux. Enfin, ouvrir ses données de recherche, si c’est permettre à d’autres de réutiliser ses données, requiert beaucoup de travail de la part des linguistes, c’est une tâche longue, ingrate et surtout peu valorisée. Alors qu’il est de plus en plus précaire d’être chercheur en sciences humaines, il est aussi difficile de demander à ces chercheurs et chercheuses de consacrer une grande partie de leur temps à des tâches qui ne leur permettront pas de se constituer un CV, nécessaire si l’on souhaite avoir un poste stable (c’est-à-dire plus de deux ans).

Label sans IA : ce texte a été rédigé sans aucun aide de la part d’une LLM.

Présentation rapide de RootDB, une application auto-hébergeable open-source (AGPLv3), permettant de générer des rapports à base de requêtes SQL.

Sommaire

• Genèse du projet
• Open-source
• RootDB ?
• Fonctionnalités
  • Websocket
  • Bibliothèques graphiques au choix
  • Onglets & Menu
  • Cache
  • Paramètres en entrée
  • Liens entre rapports
• Hébergement
• Conclusion

Genèse du projet

Pour les besoins d'un client, il fallait que je génère rapidement des statistiques d'usage diverses et variées (à bases de tableaux et graphiques), à partir de plusieurs base de données relationnelles classiques et que j'intègre ces rapports dans un backoffice.

Le premier réflexe fut de me tourner vers une solution que j'ai utilisée pendant une dizaine d'années auparavant et qui se nomme MyDBR. Cela répondait parfaitement à son besoin tout en étant abordable. MyDBR, bien maitrisé, permet de faire énormément de choses, mais l'interface est vraiment datée et l'accès aux fonctionnalités des bibliothèques graphiques se fait par l’intermédiaire de wrappers en SQL.

J'ai cherché des alternatives, auto-hébergeables, simples à mettre en place, maintenues et avec la même logique pour la création de rapport mais je n'ai pas trouvé mon bonheur. Il y a, évidemment, pleins de solutions qui existent mais il y avait toujours quelque chose qui n'allait pas après essai, que ce soit dans la manière de générer des rapports ou bien les pré-requis, parfois compliqués, pour l'hébergement.

D'ou l'idée de créer, avec un collègue, notre propre solution de reporting - parce que pourquoi pas, finalement.

Open-source

Ce projet n'était pas open-source à la base et nous pensions simplement vendre des licences d'utilisation.

Sauf qu’aujourd’hui beaucoup de monde utilise le cloud, et ce dernier vient avec ses solutions intégrées de reporting, limitant de fait l'intérêt de ce genre de projet. Pour faire bref, je reste convaincu que tout le monde n'est pas sur le cloud et que ce genre de solution peut encore intéresser quelques personnes.
À cause des doutes sur la pertinence même du projet, je n'ai jamais sérieusement cherché du financement, ce qui ne m'a jamais permis d'être à temps plein dessus. Nous avons donc mis du temps avant de produire quelque chose d'exploitable dans un environnement de production : un an et demi environ.
À cela s'ajoute le fait que ce projet n'existerait pas sans toutes les briques open-source sur lesquelles il se base. Et comme c'est l'open-source qui me fait vivre depuis un certain nombre d'années, il me semblait finalement bien plus naturel de rendre ce projet open-source (licence AGPLv3) que d'essayer de le vendre en chiffrant le code source.

RootDB ?

Étant familier du SQL et du JavaScript, nous voulions avoir une solution qui ne mette pas de bâtons dans les roues du développeur, à savoir :

• utiliser principalement le SQL pour la récupération et le traitement des données ;
• avoir un accès intégral à la bibliothèque graphique choisie ;

Ce choix de préférer un environnement de développement de rapport orienté développeur est assumé, d'où le nom du projet.

Fonctionnalités

Je ne vais pas vous présenter toutes les fonctionnalités car le site web principal et l'instance de démonstration les présentent déjà correctement. Je vais donc plutôt mettre en avant les spécificités du projet.

Websocket

Les requêtes SQL peuvent prendre du temps à tourner, surtout si les tables ne sont pas correctement optimisées. Par conséquent l'interface repose lourdement sur les websockets afin d'éviter les problèmes de timeout. Quand un rapport est exécuté, l'exécution des différentes requêtes est dispatchée de manière asynchrone et les vues affichent des résultats uniquement quand les données arrivent sur le websocket du rapport.
D'une manière générale toute l'interface est rafraichie par websocket.

Bibliothèques graphiques au choix

Nous donnons accès à Chart.js ou D3.js, sans limitation, sans wrapper. Il est donc possible de se référer directement à la documentation officielle de ces deux bibliothèques.

Onglets & Menu

Nous aimons bien les menus. :)
C'est simple, élégant et permet d'accéder à beaucoup d'options de manière claire.
L'interface repose sur une barre de menu principale dynamique et une barre d'onglets dans lesquels s'affiche les différentes parties de l'application. Il est donc possible d'ouvrir plusieurs rapports (ou le même) dans le même onglet du navigateur web.

Cache

Il existe deux niveaux de cache :

• un cache utilisateur, pratique pour cacher des résultats de manière temporaire afin de partager des résultats avec un autre utilisateur.
• un cache système (jobs) ou il est possible de générer du cache de manière périodique. Nécessaire pour des rapports qui utilisent de très grosses tables qu'il n'est parfois pas possible d'optimiser.

Paramètres en entrée

Il est très facile de générer ses propres paramètres afin de filtrer les rapports, que ce soit sur une plage de date, une liste d'options sortie d'une base de données, des cases à cocher etc.

Liens entre rapports

Que ce soit avec Chart.js ou bien un tableau, vous pouvez créer des liens entre vos rapports ou bien sur le même rapport pour faire des rapports de type drill-down.

Hébergement

Côté API, RootDB est une application Laravel qui fonctionne sur du PHP en version 8.2.x (voir 8.3.x, mais pas encore bien testé) et utilise Memcached pour la gestion du cache.
Le serveur de websocket est propulsé par Laravel Reverb.
Côté Frontend, il s'agit d'une application React classique, en TypeScript, qui utilise PrimeReact pour la suite de composants prêt-à-l'emploi.

Conclusion

Concernant les fonctionnalités que nous aimerions mettre en place petit à petit :

• une interface de configuration pour Chart.js - afin de, quand même, rendre plus simple la configuration des charts, tout en laissant la liberté au développeur de coder en javascript les fonctionnalités avancés ;
• un nouveau type de connecteur pour supporter Microsoft SQL Server ;
• une fonctionnalité d'auto-rafraichissement des rapports ;
• l'import asynchrone de gros fichiers CSV ou Excel.

Nous pouvons aider à l'utilisation, par l’intermédiaire :

• d'un salon discord mais ce n'est pas forcément idéal pour ce genre de projet. Je suis donc entrain de regarder du côté de Matrix, éventuellement ;
• un forum classique.

Voilà, c'était une brève présentation de RootDB.
C'est un projet qui n'a pas encore été testé par beaucoup de monde, d’où cette présentation pour le faire connaitre un peu plus.

Face aux risques que fait peser GitHub sur le monde des logiciels libres suite à son rachat par Microsoft en 2018, une alternative semble avoir percé. Cette dépêche propose un tour d'horizon des problèmes posés par GitHub et expose comment Codeberg pourrait y répondre.

Sommaire

• • Les points forts de Codeberg
  • La problématique du tout GitHub
  • Des alternatives possibles
  • Pour vous faire venir sur Codeberg
    • Premières impressions
    • Fonctionnalités avancées
  • Projets ayant migré ou ayant un miroir sur Codeberg
  • Comment migrer vers Codeberg ?
  • Conclusion
  • Sources / Liens
    • Controverse GitHub
    • Forges diverses
    • Codeberg

Les points forts de Codeberg

L'association Codeberg e.V. ¹ et son projet Codeberg.org ont été fondés en janvier 2019, suite au rachat par Microsoft de GitHub. En plus d'un statut associatif à but non lucratif, ce qui limite les risques de disparition du jour au lendemain, Codeberg est basé en Europe (à Berlin), ce qui est un plus pour nos données personnelles.

Son logo représente un sommet enneigé sur fond de ciel bleu. En effet, en Allemand, der Berg veut dire la montagne et on pourrait donc traduire Codeberg par une « montagne de code ». Et effectivement, la communauté compte fin avril 2024 plus de 102 000 utilisateurs et plus de 129 000 projets y sont hébergés. L'association qui dirige le projet compte plus de 400 membres. Le financement s'effectue par les dons (déductible des impôts en Allemagne) et/ou contributions aux projets sous-jacents à la forge.

La forge est basée sur Forgejo, logiciel libre sous licence MIT, dont le nom vient de l'Esperanto forĝejo, ce qui est cohérent avec l'attention portée à la langue de l'utilisateur et aux problèmes de traduction (service Weblate). Comme avec GitLab, la licence libre implique qu'un projet peut posséder sa propre instance s'il le souhaite. On notera que Forgejo est un fork de Gitea, lui-même fork de Gogs, et est donc écrit en langage Go, langage sous licence BSD avec un brevet. Le projet Forgejo, évidemment hébergé sur Codeberg, est très actif avec plus de 900 Pull Requests acceptées depuis un an.

La problématique du tout GitHub

GitHub, lancé en 2008, est devenu la plus grosse plateforme d'hébergement de codes sources, utilisée par un grand nombre de projets majeurs du monde du libre (Firefox, Matrix, Yunohost…). Ce qui par effet d'attraction — et de réseau centralisant, contraire au choix de git décentralisé par nature — conduit souvent à faire de Github un choix par défaut, facilitant les interactions avec les autres projets et permettant d'accéder à une large base de contributeurs potentiels. Quand on cite une URL GitHub dans un réseau social, on peut d'ailleurs voir apparaître ce genre de message :

Contribute to Someone/my_project development by creating an account on GitHub.

Cependant, si ce service fourni par Microsoft est actuellement encore gratuit, il est soumis à son bon-vouloir, avec le risque de voir se répéter l'épisode SourceForge (publicités trompeuses, installateurs modifiés, usurpation d'identité de projets partis ailleurs, etc.).

Par ailleurs, derrière une communication favorable à l'open source, le code de la forge GitHub est volontairement fermé. Vous ne pouvez donc pas avoir votre propre instance de GitHub. En outre, cela laisse un flou sur l'exploitation de nos données (au sens large, le code lui-même et nos données personnelles, l'hébergement étant délégué). Avec l'arrivée du projet Copilot, il est cependant certain que nos codes servent à alimenter un outil d'IA, permettant à Microsoft de monétiser des suggestions de code en faisant fi des questions de licence. Une partie d'un code sous licence libre pourrait potentiellement se retrouver injectée dans un projet avec une licence incompatible et de surcroît sans citation de l'auteur.

Des alternatives possibles

On pense tout d'abord à GitLab, logiciel lancé en 2011, qui permet d'avoir sa propre instance serveur pour maîtriser l'ensemble (client et serveur sont libres). Parmi les grands projets libres, on trouve en particulier GNOME et Debian qui utilisent leur propre instance GitLab CE (Community Edition), logiciel sous licence MIT. Mais il faut nuancer : la forge GitLab.com utilise GitLab EE (Enterprise Edition) qui est propriétaire et propose des fonctionnalités supplémentaires. GitLab suit donc un modèle dit open core. GitLab compterait plus de 30 millions d'utilisateurs inscrits et l'entreprise GitLab Inc., lancée en 2014, génère plusieurs centaines de millions de dollars de revenus. On notera enfin qu'en 2018, le site migre de Microsoft Azure à Google Cloud Platform (USA), ce qui a posé des problèmes d'accès dans certains pays.

Autres projets de forges libres plus modestes :

• Codingteam.net (une initiative française, service clôturé en 2019).
• SourceHut http://sr.ht (et https://sourcehut.org/), initié par Drew DeVault.
• Disroot basé sur Forgejo comme Codeberg, mais il ne semble pas avoir attiré de projets d'envergure (le portail, sorte de Framasoft néerlandais, est néanmoins à recommander).
• Chez un Chaton (GitLab ou Gitea pour la plupart).
• L'auto-hébergement : chez-vous, dans un fablab, en datacenter sur serveur dédié…

Pour vous faire venir sur Codeberg

Premières impressions

La page principale est accueillante et annonce que Codeberg.org ne vous piste pas et n'utilise pas de cookies tiers. Les statistiques actuelles sont affichées : nombre de projets, d'utilisateurs et de membres de l'association. Chose agréable, vous avez la possibilité de choisir le français parmi les nombreuses langues proposées pour l'interface. Petite icône qui attire l'attention : l'activité de chaque dépôt peut être suivie grâce à un flux RSS. Sinon, l'organisation générale est très semblable à celle de GitHub ou GitLab et la prise en main de Codeberg se fait donc sans effort.

Fonctionnalités avancées

• Codeberg pages : permet de disposer d'un site web statique pour le projet
• Forgejo actions : pour dérouler automatiquement les actions nécessaires à l'intégration continue (CI/CD)
• Weblate : pour gérer les traductions de votre projet. On peut d'ailleurs y constater que parmi les traductions de Forgejo, le Français est dans le peloton de tête.

Projets ayant migré ou ayant un miroir sur Codeberg

Un certain nombre de projets importants utilisent désormais Codeberg, ce qui est à la fois un gage de confiance et assure une base de contributeurs a minima :

• libreboot : remplacement libre de BIOS/UEFI.
• Conversations : le client majeur XMPP sur Android.
• WideLands : jeu libre basé sur le concept de Settlers II.
• LibreWolf : fork de Firefox axé sur la vie privée.
• F-Droid : magasin d'applications libres pour Android.
• FreeBSD : miroir de https://cgit.freebsd.org/
• FreeCAD : miroir officiel.
• Forgejo : fork communautaire de Gitea suite à la privatisation de celui-ci en 2022.
• Fedilab : client Android pour le Fediverse.
• irssi : client IRC.
• Peppermint OS : une distribution Linux avec bureau minimaliste.
• DivestOS : un fork de LineageOS orienté sur la protection de la vie privée.
• VeggieKarte : un service pour trouver des restaurants végétariens/végétaliens.
• …

Comment migrer vers Codeberg ?

Migrer le code source et l'éventuel Wiki associé ne devrait pas poser de problème particulier. Il suffit de configurer git pour pusher vers la nouvelle forge. Cette page décrit comment migrer l'ensemble de votre projet (incluant les issues, le wiki, les Pull Request, etc.) vers Codeberg : https://docs.codeberg.org/advanced/migrating-repos/

Concernant les Workflows (CI), bien qu'il n'y ait pas de garantie de compatibilité avec les Actions Github, la syntaxe se veut similaire pour faciliter la transition : https://forgejo.org/2023-02-27-forgejo-actions/

Au-delà de l'aspect technique, il reste aussi à faire migrer la communauté d'utilisateurs (la présence fortement suivie sur Mastodon peut être un avantage).

Conclusion

Codeberg est un outil prometteur. Il reste pour la communauté du logiciel libre à le faire grandir. Rappelons les statistiques : 100 millions de développeurs sur GitHub, 30 millions utilisant GitLab et 100 000 pour Codeberg. Le potentiel est grand, l'un des enjeux est de financer l'association pour accompagner la croissance de la communauté, tout en faisant monter en puissance l'infrastructure informatique.

Sources / Liens

Controverse GitHub

• Sonnette d'alarme activée dès 2016 (fr).
• Pourquoi abandonner Github (en) : la campagne Give Up GitHub! a été lancée en juin 2022 suite à la controverse sur GitHub Copilot.
• Please don’t upload my code to GitHub (en) : résumé des problèmes posés en particulier par Copilot (IA GitHub).
• https://en.wikipedia.org/wiki/GitHub_Copilot#Licensing_controversy

Forges diverses

• https://en.wikipedia.org/wiki/GitLab
• Synthèse LinuxFR sur l'autohébergement (2018) (fr).

Codeberg

• Parcourir les projets hébergés sur Codeberg (en)
• Suivre Codeberg sur Mastodon (en) : 12000 abonnés.
• Le blog de Codeberg (en)
• Instances, projets et ressources autour de Forgejo (en)
• https://en.wikipedia.org/wiki/Codeberg

Cloonix est un outil d’aide à la construction de réseau virtuel. Il est basé sur Open vSwitch pour l’émulation du réseau constitué de switchs et LANs virtuels, sur crun et les namespaces pour la gestion de conteneurs et sur KVM pour ce qui concerne l’émulation des machines complètes.
Cloonix peut être considéré comme un hyperviseur qui permet de lancer des scénarios de démonstration impliquant des réseaux connectant de nombreuses machines virtuelles ou conteneurs. Ce logiciel open source permet d’automatiser et de rejouer des scénarios complets.

FRR est le logiciel open source qui permet de transformer une machine Linux en l’équivalent d’un routeur professionnel, ce logiciel implémente tous les protocoles de routage classique.

Podman est exactement comme Docker, un gestionnaire de conteneur.

Le but de cette dépêche est de présenter une démonstration qui tourne dans un podman et qui met en œuvre un réseau d’une soixantaine de conteneurs et qui peut être lancé en tant qu’utilisateur simple sans les droits root.

Il y a le lien « demo » qui montre une vidéo un peu accélérée de cette démonstration qui démarre les machines, les configure et les met en réseau. On peut ensuite y voir la convergence du protocole OSPF.

Il y a quelques années, je vous avais présenté TuxMake, un utilitaire pour faciliter la (cross-)compilation du noyau Linux supportant une grande variété de toolchains différentes : TuxMake et le noyau Linux.

TuxMake facilitant la compilation du noyau Linux, nous nous sommes alors attaqués à rendre l’exécution de ces noyaux plus aisée : ainsi est né TuxRun.

Exemples

TuxRun propose une interface en ligne de commande simple pour exécuter un noyau dans QEMU. TuxRun se charge de fournir un environnement suffisant pour démarrer le noyau avec QEMU.

tuxrun --device qemu-arm64 \
       --kernel https://example.com/arm64/Image

TuxRun va alors télécharger le noyau et un système de fichier compatible avec ARM64 puis lancer qemu-system-arm64 avec les bons arguments et afficher les logs du boot.

La ligne de commande de qemu générée par TuxRun est la suivante :

/usr/bin/qemu-system-aarch64 \
    -cpu max,pauth-impdef=on \
    -machine virt,virtualization=on,gic-version=3,mte=on \
    -nographic -nic none -m 4G -monitor none -no-reboot -smp 2 \
    -kernel /.../Image \
    -append "console=ttyAMA0,115200 rootwait root=/dev/vda debug verbose console_msg_format=syslog systemd.log_level=warning earlycon" \
    -drive file=/.../rootfs.ext4,if=none,format=raw,id=hd0 \
    -device virtio-blk-device,drive=hd0

Il est également possible de lancer une suite de tests directement depuis la ligne de commande :

tuxrun --device qemu-arm64 \
       --kernel https://example.com/arm64/Image \
       --tests ltp-smoke

Les résultats de la suite de test seront analysés par TuxRun et la valeur de retour de TuxRun sera 0 uniquement si la suite de tests passe intégralement. Ceci permet d’utiliser TuxRun pour valider qu’une suite de tests donnée fonctionne toujours correctement sur un nouveau noyau.

Architectures

QEMU

Grâce à QEMU, TuxRun supporte de nombreuses architectures:
- ARM: v5/v7/v7be/64/64be
- Intel/AMD: i386/x86_64
- MIPS: 32/32el/64/64el
- PPC: 32/64/64le
- RISCV: 32/64
- sh4, sparc64, …

La liste complète est disponible dans la documentation.

FVP

Il est également possible d’utiliser FVP, le simulateur de ARM pour simuler un processeur ARMv9. FVP est un simulateur bien plus précis que QEMU au prix d’un temps d’exécution bien supérieur.

FVP permettant de configurer et simuler de nombreux composants du processeur, TuxRun propose une configuration permettant de démarrer et tester Linux dans un temps raisonnable.

tuxrun --device fvp-aemva \
       --kernel https://example.com/arm64/Image \
       --tests ltp-smoke \
       --image tuxrun:fvp

ARM ne permettant pas (pour le moment) de redistribuer les binaires FVP, il faut construire localement le container tuxrun:fvp.

Système de fichiers

Par défaut, TuxRun télécharge et utilise un système de fichier compatible avec l’architecture cible. TuxRun fournit donc 20 systèmes de fichiers différents, un pour chaque architecture disponible.

Ces systèmes de fichiers sont basés sur buildroot et comportent les outils nécessaires pour faire tourner la majorité des suites de tests supportés par TuxRun. La liste complète est disponible dans la documentation.

Il est également possible d’utiliser un autre système de fichiers :

tuxrun --device qemu-arm64 \
       --kernel https://example.com/Image \
       --rootfs https://example.com/rootfs.ext4.zst

Runtimes

TuxRun télécharge et utilise un container que nous maintenons. Ce container inclut l’ensemble des binaires nécessaires ainsi que QEMU. Par défaut, TuxRun utilise toujours la dernière version du container disponible.

Il est cependant possible de spécifier une version particulière afin de reproduire plus facilement une erreur. Les nouvelles versions de QEMU introduisent quelques fois des régressions dans les suites de tests. Il est alors nécessaire d’utiliser exactement la même image pour reproduire le problème.

Reproduire un test

TuxRun est utilisé, via tuxsuite notre service de compilation et de test dans le cloud, par le projet LKFT (Linux Kernel Functional Testing) de Linaro. Lorsqu’une régression est détectée, il suffit de fournir la ligne de commande TuxRun pointant sur les artefacts utilisés pour pouvoir reproduire le problème.

Les développeurs du noyau sont alors à même de reproduire et de corriger les régressions détectées par LKFT. TuxRun simplifie ainsi énormément la reproduction du test.

Un exemple parmi tant d’autres : selftests: sigaltstack: sas…

Installation

TuxRun étant un programme Python, il est possible de l’installer depuis pypi :

python3 -m pip install tuxrun

Nous fournissons également un paquet Debian, et un rpm.

TuxMake et Tuxrun

Dans un prochain article, je vous montrerai comment combiner TuxMake et TuxRun pour automatiquement trouver le commit responsable de la régression dans le noyau.

Suite à la dépêche Comparatif : GrapheneOS vs LineageOS, je souhaitais faire part d’un retour d’expérience sur l’utilisation de GrapheneOS sur un téléphone Android Pixel 7a. Ce commentaire est repris ici sous forme de dépêche.

Sommaire

• PixelOS
  • Installation
  • Interface
  • Fonctionnalités spécifiques/avancées de PixelOS
• GrapheneOS
  • Installation
  • Interface
  • Applications et « stores »
  • Gestion des autorisations
  • Séparation des usages
  • Détail des approches suivies
    • 1ʳᵉ approche
    • 2ᵉ approche (test en cours)
    • 3ᵉ approche (d’ici une semaine)
  • Détails : utilisation sans les services Google
    • Synchronisation des contacts & agendas
    • Quid des applications non libres hébergées sur le play store
  • Détails : Utilisation avec les services Google
    • Dans un profil séparé
    • Via la fonction « work profile » d’Android
• Conclusion, cas d’usages et « threat model » (modèle de menace)
  • Sécurité
  • Vie privée
  • Facilité d’utilisation
  • Note : l’impact du matériel (« hardware ») sur la vie privée

Le point de départ est celui d’un utilisateur sensible aux logiciels libres mais qui utilise un téléphone Android Samsung « comme tout le monde », avec :

• Utilisation du Google Play Store, avec un compte Google personnel
• Utilisation d’un compte Google professionnel
• Utilisation du Samsung store, avec un compte Samsung
• Utilisation d’une montre connectée Samsung avec appli Samsung health

L’utilisateur a déjà expérimenté par le passé les solutions suivantes :

• UbuntuOS (abandonné rapidement par manque d’applications)
• LineageOS, avec Micro-G + « signature spoofing » pour permettre l’installation des applications bancaires

PixelOS

Installation

La mise en œuvre du système « stock » installé sur le smartphone est très facile et simple d’utilisation. Les téléphones Pixel proposent des fonctionnalités « avancées » spécifiques qui sont proposées au démarrage, avec à chaque fois le jeu de « voulez-vous activer cette fonctionnalité ? Si oui, acceptez le contrôle des données suivantes… »
On est dans un environnement full google, donc avec quelques habitudes à changer me concernant venant d’un environnement Samsung (la surcouche de l’OS est différente).

Interface

Launcher Pixel avec une barre de recherche Google qui ne peut pas être enlevée (The search bar cannot be removed from the bottom of the home screen, it's part of the Pixel Launcher https://support.google.com/pixelphone/thread/133065648/is-there-any-way-to-remove-the-google-search-bar-from-the-home-screen?hl=en), sinon tout est fluide / "beau"

Fonctionnalités spécifiques/avancées de PixelOS

• Déblocage du téléphone par reconnaissance faciale (probablement un cauchemar en termes de privacy, mais je pourrais comprendre pourquoi une personne lambda souhaiterait activer ce service)
• « Double tap » au dos du téléphone pour lancer une action (dans mon cas : la lampe torche)
  • On peut utiliser Torchie pour une fonctionnalité proche (https://f-droid.org/fr/packages/in.blogspot.anselmbros.torchie/)
  • Les fonctions d’urgence « avancées » fournies par l’application « sécurité personnelle » (https://play.google.com/store/apps/details?id=com.google.android.apps.safetyhub&hl=fr&gl=US)
  • L’application est disponible sur le playstore mais ne fonctionne pas sur GrapheneOS
  • Il existe une fonction d’urgence « de base » dans GrapheneOS (AOSP ?) (appuyer 5x sur power pour lancer un appel d’urgence vers le 112)
  • Dans PixelOS, il y a un conflit de raccourcis entre « appuyer 5x sur power pour lancer un appel d’urgence » et l’option « appuyer 2x pour lancer l’appareil photo » (quand les deux sont activées : l’appareil photo prend le dessus)
• Paiements NFC (non accessibles sur GrapheneOS)
  • Certaines applications de paiement autres que Google Wallet peuvent fonctionner (par ex. Paylib)
• Fonctionnalité « bien être numérique », notamment le fait de passer l’écran en noir & blanc à partir d’une certaine heure pour tenter de limiter le temps devant les écrans. L’application existe dans le Play Store (https://play.google.com/store/apps/details?id=com.google.android.apps.wellbeing&hl=fr&gl=US) mais impossible à retrouver depuis le client Play Store sur le téléphone.
  • Il existe probablement des alternatives

GrapheneOS

Installation

Procédure d’installation web très simple et rassurante. C’est la première fois que je me verrai recommander ce type d’install à un utilisateur non technique (alors que la procédure d’install de LineageOS - à l’époque ou j’ai essayé - est complexe et obscure, avec le risque de se planter à plusieurs étapes).

Interface

• Le bureau par défaut est très minimaliste et pas très accueillant (je sais que cela peut paraître peu important, mais le fond noir + icônes en noir & blanc peut rebuter / n’est pas aussi accueillant que le système de base).
  • Possibilité d’utiliser un launcher alternatif : j’ai fini sur Lawnchair après en avoir testé plusieurs
  • Possibilité de changer le fond d’écran : Muzei (https://f-droid.org/fr/packages/net.nurik.roman.muzei/) / Walman (https://apt.izzysoft.de/fdroid/index/apk/com.colorata.wallman)
• Le clavier par défaut m’a dérangé (après des années à utiliser le clavier Gboard), surtout pour l’écriture « swipe » (que je pratique souvent quand j’écris un message à une main).
  • Possibilité d’utiliser un clavier alternatif : Home:FlorisBoard (https://f-droid.org/fr/packages/dev.patrickgold.florisboard/) est pas mal, il inclut une fonction « swipe » mais qui n’est pas aussi précise

Applications et « stores »

• Le « store » par défaut « Apps » contient le minimum vital.
  • Pour le compléter, je suis passé par l’application Droid-Ify (https://droidify.eu.org/ ou https://github.com/Droid-ify/client) dans lequel j’ai activé les dépôts F-droid et Home:IzzyOnDroid

Pour le Store Google, il est possible d’installer plusieurs « briques » de l’éco-système :

• Google Services Framework (GSF), dont dépendent :
  • Google Play services + Google Play Store (interdépendants) On peut donc choisir : rien du tout, GSF pour les applis qui en dépendent, ou les trois.

Gestion des autorisations

• Les possibilités sont très fournies = positif (permet de limiter les accès réseau, les accès stockage)
• Les possibilités sont très fournies = complexe à gérer : il faut se poser des questions / passer du temps à configurer les choses.
  • Exemple : la synchronisation des contacts Google ne se fait pas sans la permission « Contacts » dans l’appli « Google Services Framework ».

Séparation des usages

Il existe deux approches possibles de séparation des usages :

• Utilisation d’un « user profile » : il s’agit d’un profil complètement distinct. On peut passer de l’un à l’autre assez facilement. Les deux profils ne peuvent pas se parler, sauf via les notifications croisées (https://www.youtube.com/watch?v=WjrANjvrSzw)
• Utilisation d’un « work profile » : ici on utilise un seul profil, mais à l’intérieur duquel on vient activer la fonctionnalité « work profile » d’Android pour séparer les usages (via une application tierce telle que Shelter, https://www.youtube.com/watch?v=20C0FD7mGDY pour une explication détaillée)

Détail des approches suivies

1ʳᵉ approche

• Profil « owner » avec Shelter
  • Profil « Personnel » = pas de services Google
  • Profil « Professionnel » = Services Google avec compte personnel
• 2ᵉ Profil « Travail » = Services Google avec compte professionnel

Ce qui bloque : je voulais utiliser la fonctionnalité « work profile » d’Android avec Shelter pour isoler mon compte Google personnel. Hors c’est ce compte qui jusqu’ici synchronise les contacts. Les applications par défaut de GrapheneOS ne gèrent pas cette synchro (autrement que via import/export manuel, ou alors je n’ai pas trouvé comment). Si on veut quelque chose qui s’intègre tout seul il faut passer par les applications Google de Téléphone/Contacts/Calendrier. Hors ces applications ne peuvent pas devenir « applications par défaut » (pour remplacer celles existantes de GrapheneOS) dans le « work profile », c’est le profil personnel qui gère cette configuration.

2ᵉ approche (test en cours)

• Profil « owner » (unique, sans Shelter) = Services Google avec compte personnel
• 2ᵉ Profil « Travail » (unique, sans Shelter) = Services Google avec compte professionnel

Ce qui bloque : j’utilise le téléphone à la fois pour le pro & perso, sauf que le fait d’avoir deux profils implique de jongler systématiquement entre les deux profils. Trop compliqué au quotidien.

3ᵉ approche (d’ici une semaine)

• Profil « owner » avec Shelter
  • Profil « standard » = Services Google avec compte personnel
  • Profil « work » = Services Google avec compte personnel

Détails : utilisation sans les services Google

Synchronisation des contacts & agendas

La première problématique c’est la synchro des contacts et des agendas. Pour se passer de Google sur ce point, il faut mettre en place au préalable un service de partage de contact / agenda :

• Nextcloud + DAVx⁵
• https://www.etesync.com/
• https://www.chatons.org/
• NAS Synology + leurs applications (mais uniquement accessibles sur Google Play Store…)

Bref c’est un projet en tant que tel, pas forcément à la portée de tous

Quid des applications non libres hébergées sur le play store

À ce stade, pour accéder à d’éventuelles applications uniquement présentes sur le Play Store, il est possible de :

• passer par l’application Aurora
• passer par apkmirror pour les télécharger une à une

Cependant, de nombreuses applications du Play Store requièrent l’installation du Google Services Framework (« GSF ») pour fonctionner.

Me concernant, j’ai la liste suivante d’applications que j’ai pu récupérer par ce biais (et qui fonctionnent sans GSF) :

• Appli Banque (SG)
• Paiement NFC via Paylib (pas encore testé « en vrai » mais l’appli s’installe sans broncher)
• Deezer (musique)
• Somfy (alarme)
• NetAtmo (thermostat connecté)
• Doctolib (Santé)
• Appli mutuelle (Alan)
• Freebox connect (utilitaire freebox)
• Wifiman (utilitaire réseau)

Certaines applications nécessitent le GSF, c’est le cas notamment de :

• Whatsapp (pour les notifications « push » et pour transfèrer l’historique des messages)
  • Il semble que des transferts « locaux » soient possibles
    • https://faq.whatsapp.com/6181521285295518/?helpref=hc_fnav&cms_platform=android
    • https://faq.whatsapp.com/209942271778103/?helpref=hc_fnav&cms_platform=android
• Bose connect (gestion casque bluetooth Bose qui indique l’erreur « Services Google Play manquants »)
  • Le casque peut fonctionner en bluetooth sans l’application

Détails : Utilisation avec les services Google

Dans un profil séparé

J’ai mis du temps à comprendre / trouver comment activer la fonctionnalité de profils multiples (alors que c’est simple) : Paramètres > Système > Utilisateurs multiples > Autoriser plusieurs utilisateurs (https://www.youtube.com/watch?v=SZ0PKtiXTSs)

Le profil séparé à l’avantage d’être comme un « deuxième téléphone ». C’est aussi un inconvénient pour les personnes qui ne sont pas prêtes à faire cet « effort » (passer de l’un à l’autre), même si les notifications « cross profile » aident sur ce point.
Il faut reproduire sur chacun des profils toutes les « custo » faites (changement de launcher, de clavier, configurations diverses, etc).

Via la fonction « work profile » d’Android

La fonction work profile fournit une séparation moins forte, mais c’est aussi plus « pratique » au quotidien car toutes les applications (et les comptes) sont dans un seul profil. J’ai testé via l’application Shelter.

Avantages :

• Tout est accessible dans le même profil
• Dans le tiroir d’application, on retrouve deux « onglets » séparant les applications « perso » et « pro ».

Inconvénients :

• Comme pour le profil séparé, il y a une « double maintenance »
  • Ex: en cas d’utilisation de deux profils Google Play (profil perso + pro), il faut faire les mises à jour « des deux côtés »
• Il faut bien choisir dans quel contexte on souhaite installer chaque application
• Je n’ai pas trouvé comment faire pour 1. Synchroniser mon compte Google perso dans le « work profile » de Shelter et 2. faire remonter ces informations dans les applications « contacts » et « téléphone » par défaut de GrapheneOS. C’est le profil « Personnel » qui va dicter quelles applications par défaut sont utilisées.

Conclusion, cas d’usages et « threat model » (modèle de menace)

J’ai passé beaucoup plus de temps que prévu à comprendre GrapheneOS, tester différentes solutions et configurer les options / trouver des alternatives. Je suis bien conscient que plusieurs « problèmes » remontés pourraient tout simplement être résolus si j’acceptais de faire les choses différemment. Cela me pousse à m’interroger sur le compromis à choisir entre sécurité / respect de la vie privée / facilité d’utilisation ? Cette question dépend bien sur du modèle de menace (« threat model ») de chacun.

Sécurité

GrapheneOS répondrait parfaitement à des contraintes de sécurité « forte » pour des personnes étant journaliste / activiste / lanceur d’alerte / député. Dans ce cas d’usage, le coût de la sécurité est accepté.

Vie privée

GrapheneOS apporte un choix indéniable permettant à chacun de trouver le meilleur usage possible.

Facilité d’utilisation

Dans mon cas d’usage, je trouve que la fonction de profil séparé apporte trop de friction au quotidien, et je suis prêt à tout rassembler au sein du même profil. L’utilisation de deux téléphones différents (un perso / un pro) pourrait être une alternative. De la même manière, je n’ai pas encore passé le pas de me séparer de mon compte Google (pour la synchro des contacts / agendas), donc pour le moment je continue d’utiliser le Play Store. À terme, j’essaierai de ne plus en dépendre.

Note : l’impact du matériel (« hardware ») sur la vie privée

• Un casque Bluetooth Bose nécessite l’app « Bose Connect » qui dépend de GSF/Play Store
• Un casque Bluetooth Samsung Buds2 Pro nécessite l’app Samsung qui demande la création d’un compte cloud chez eux
• L’application Google Wallet me permet de régler mes courses via paiement NFC, mais donne accès par ce biais à un pan entier de données personnelles

À chaque fois la question est : est-ce utile ou pas ? Puis-je facilement m’en passer ?

Récit de mon aventure en tant que contributeur pour le projet Open Food Facts, la base de donnée alimentaire ouverte et collaborative, où je suis arrivé un peu par hasard en 2015.

Depuis son lancement par Stéphane Gigandet en 2012, le projet a beaucoup évolué et les contributions ont augmenté de façon exponentielle. D’abord centré sur des données de produits vendus en France, la base compte désormais 3 100 000 produits et 18 pays ayant dépassé les 10 000 produits référencés.

L’impact de ces données a pu se voir à travers le Nutriscore qui a pu être testé sur un grand nombre de produits grâce à Open Food Facts. Désormais, plusieurs projets avancent de front et en partenariat avec d’autres acteurs, notamment autour de l’empreinte carbone (EcoScore), des emballages (avec l’ADEME) ou de la surveillance de la réduflation (avec l’ONG Food Watch).

Sommaire

• • Découverte & premiers pas
  • Contribution(s)
  • Changements notables
  • Limites
  • Perspectives
  • Conclusion
  • Liens & ressources

Découverte & premiers pas

Je raconte souvent que j’ai découvert Open Food Facts (OFF) grâce à José Bové. Pas directement, certes, mais il a joué un grand rôle dans mon intérêt pour OFF.

José Bové n’est pas content contre le dioxyde de titane (E171)

Mars 2015 : je regarde d’un œil torve BFM TV et je vois un José Bové énervé contre un additif : le E171 (aussi connu sous le nom « dioxyde de titane »). Face à Jean-Jacques Bourdin, il sort des paquets de M&M’s et de chewing-gum, cite les marques et incite les téléspectateurs à boycotter ces produits qui contiennent ce colorant controversé.

Pas forcément renseigné sur les enjeux autour de ce colorant, j’ouvre la page Wikipédia de celui-ci. Je lis en diagonale ce qui est marqué et, en bas, je vois un lien où il est indiqué « Liste des produits contenant du E171 sur Open Food Facts ».

Je découvre l’interface moche (signe de reconnaissance des projets portés par des bénévoles et où l’aspect visuel est souvent en bas de la liste des priorités) de OFF et comprend très vite les grandes lignes du projet : un Wikipédia des aliments qui se base sur les informations présentes sur les emballages. Ni plus, ni moins.

En découvrant OFF, je suis étonné que le projet n’a été lancé qu’en 2012. Naïvement, je pensais que les données alimentaires étaient obligatoirement partagées par les producteurs et centralisées quelque part, à des fins de contrôle de conformité par exemple. Mais finalement non : les rares bases de données qui existent ne sont pas ouvertes.

Quand j’arrive sur le site, le projet vient de dépasser les 30 000 produits dont 90% sont français. À l’époque, je ne suis pas libriste (je crois que je ne connaissais pas la différence entre logiciel libre et logiciel propriétaire), je ne contribue à aucun commun numérique et, ironiquement, je ne suis pas très intéressé par les questions autour de l’alimentation.

Contribution(s)

Rapidement, je ne sais plus où donner de la tête : il y a tant de choses à faire pour aider !

Au début, j’aide à compléter les fiches. On parle d’une époque où il n’y a aucun outil de reconnaissance de caractères intégré au projet donc, la liste d’ingrédients, il faut forcément la remplir à la main. Plutôt simple pour un jus de fruit, beaucoup moins pour un gâteau industriel.

Comparaison de deux listes d’ingrédients : l’une avec beaucoup d’ingrédients et l’autre avec peu

L’ajout de nouveaux produits est rapidement un réflexe que de nombreux contributeurs et contributrices de OFF ont connu : en revenant des courses, je me retrouve à genoux sur le sol de ma cuisine pour prendre les meilleures photos possibles d’une conserve de haricots ou d’une galette complète surgelée. Je suis moins fan de prendre des photos directement en rayon : on parle d’une époque pré-Yuka où scanner un produit n’est pas du tout dans les habitudes du consommateur moyen (et encore moins le prendre en photo). Autre réflexe : ramasser parfois des déchets dans la rue pour voir si — au cas où — ils ne sont pas dans Open Food Facts (et les mettre dans la poubelle jaune en passant, tout de même :D ).

La question des catégories — et surtout de la taxonomie de celles-ci — devient rapidement un point central de mes contributions : pour comparer des produits d’une même catégorie, encore faut-il que ceux-ci en aient une. La complétion des autres champs, bien qu’importante, me paraît secondaire sur la mission de classer les produits le plus finement possible.

Un autre sujet qui m’intéresse : les estampilles sanitaires. Ces codes qui sont obligatoires sur certains produits (notamment ceux issus d’animaux) permettent de connaître le lieu de préparation de ceux-ci. Multipliez les fiches avec ces codes, couplez-les avec la liste, publique, des sites de productions correspondant et vous obtenez la carte « C’est fabriqué près de chez-moi ». Avec cette carte, on a rapidement « repéré » certains sites majeurs, comme l’usine d’Aucy, à Theix (près de Vannes), qui a rapidement dépassé les 300 références.

Carte des sites de production centrée sur le Golfe du Morbihan

Changements notables

Le grand changement qui a révolutionné la contribution à OFF, ce sont les modifications semi-automatisées permises par Hunger Games. Rajouter, en quelques minutes, la marque de centaines de produits accélère considérablement la contribution et permet d’avoir une base de donnée toujours plus complète. À terme, ce projet a sûrement vocation à devenir la Street Complete de Open Food Facts (en tout cas, je l’espère :D ).

Depuis fin 2022, nous avons enfin réussi à infléchir la courbe des produits sans catégorie (qui ne faisait que monter depuis 2017)

Pour ce qui est de l’ajout de nouveaux produits, il y a clairement eu un avant et un après Yuka. Cette application se basait, à ses débuts en 2017, sur OFF. Elle a depuis créé sa propre base mais rebascule les photos et certaines données sur OFF. Bien que l’ajout de nouveaux produits ait tendance à se diversifier avec le temps (via l’arrivée d’applications similaire dans d’autres pays notamment), Yuka a clairement donné un coup d’accélérateur incroyable à OFF : à l’heure où j’écris ces lignes, près de 60% des produits ont été ajoutés via cette application. Même si de nombreuses données sont ajoutées sur OFF par la suite sur ces produits, cet apport est essentiel pour la croissance de la base.

Liste des principaux contributeurs qui sont des applications pour les 15 plus importants (« kiliweb » est l’identifiant de l’application Yuka dans OFF)

Des projets annexes ont vu le jour : Open Beauty Facts, Open Pet Food Facts et Open Products Facts. Ces trois projets, à chaque fois lancés sous forme de blague le 1ᵉʳ avril, sont devenus des projets sérieux qui avancent à leur rythme dans le sillage de OFF. Le projet de fusionner tous ces projets est en gestation depuis plusieurs années, mais devrait se concrétiser bientôt.

La refonte graphique du projet actée pour les 10 ans de OFF a été très bien mise en place. La nouvelle page d’accueil est plus agréable, le logo est super et, surtout, les fiches produits sont très bien organisées. Il y a également une cohérence graphique entre le site web et l’application smartphone.

Ancien logo vs. nouveau logo

Dernière chose qui démontre la maturité du projet : la mise en place d’un groupe de travail dédié à la qualité des données. Depuis sa mise en place, de nombreuses erreurs de valeurs nutritionnelles ont été corrigées en priorisant les produits les plus scannés via près de 200 contrôles (ex : il y a un problème si un produit est noté avec « 120 g de sucre pour 100 g »). Ce travail va désormais porter sur la qualité des ingrédients renseignés et, là, on passe à un autre niveau de complexité…

Un mème que j’avais bricolé il y a quelques mois et qui illustre le chantier qui nous attend pour améliorer la qualité des ingrédients.

Limites

Selon moi, le gros point noir de OFF est son application smartphone. Celle-ci rend la contribution laborieuse. À tel point que j’ai tendance à rester sur PC, même pour l’envoi de photos. Aussi, le décalage entre les versions disponibles sur Google Play/App Store d’un côté et F-Droid de l’autre est dommage.

Une autre limite est, selon moi, le lien que l’on a, en tant que contributeur, aux données que l’on ajoute.

Je m’explique : j’ai un peu contribué à OpenStreetMap (projet que j’ai découvert via mon implication à OFF, en passant). J’ai fait des modifications assez modestes, mais j’ai un lien assez fort aux données que j’ai ajoutées. Mais j’ai souvent en tête ces contributions et le fait qu’elles sont utiles à de nombreuses ré-utilisations via des applications tierces. Constater ces ré-utilisations crée une sorte de fierté d’avoir contribué à ce projet. Et une incitation à continuer. Christian Quest en a d’ailleurs parlé lors des derniers « OFF Days », en décembre 2023.

Cette incitation est assez faible dans le cas de OFF. Personnellement, ce qui me pousse et m’a toujours poussé à contribuer est de voir passer des articles scientifiques qui utilisent OFF comme source de données principale, notamment autour du Nutriscore.

D’ailleurs, lors des dix ans d’OFF, le docteur Chantal Julia a évoqué le travail l’équipe du Pr Serge Hercberg (l’inventeur du Nutriscore) et est venue parler de l’impact d’OFF dans l’élaboration de cet indicateur. Elle a prononcé la phrase : « Le Nutriscore n’en serait pas là aujourd’hui si Open Food Facts n’existait pas ». Cette phrase résume la raison de mon implication dans ce projet.

Intervention du Dr Chantal Julia pour les Open Food Facts Days 2022

Autre étonnement : la dépendance du projet à des outils non libres. Le fait que tout s’organise sur Slack, par exemple, est dommage et l’utilisation de services Google l’est également. Loin de moi l’idée de passer pour un puriste (on a tous nos contradictions à ce sujet) mais lorsque des alternatives existent, cela devrait être un réflexe pour tout projet de les utiliser en priorité. Je pense notamment aux outils portés par l’association Framasoft.

Le contrôle des produits ajoutés serait à renforcer : OFF déborde de produits dont le code-barre est erroné. Cela peut être intentionnel (vandalisme de données) ou non (erreur du lecteur de code-barre ou faute de frappe). La conséquence : un travail de fourmi pour transférer les photos au bon produit puis supprimer la mauvaise fiche. Heureusement, pour les produits qui n’ont ni photo ni données, la procédure est souvent automatisée et, passé un certain délai, la fiche est supprimée. La conséquence : une partie non négligeable des produits ajoutés sur OFF sont destinés à être supprimés à long terme. De ce que j’ai pu en constater, j’estime que cela représente entre 10 et 15% des produits ajoutés sur une année (chiffre à prendre avec des pincettes).

Comparaison des produits ajoutés par année entre le 2 janvier 2023 et le 10 février 2024. Entre ces deux dates, plus de 77 000 produits ont été supprimés car erronés.

Dernier regret qui, j’imagine, est partagé par le reste des bénévoles : n’avoir jamais pu développer de communautés locales de contributeurs. Je pense que c’est dû à la nature des données : il est plus facile de créer un groupe local lorsque celles-ci sont liées à l’endroit où l’on réside (comme pour OpenStreetMap par exemple). Quelques « scan party » ont été organisées ici ou là, mais je n’ai pas le sentiment que ça ait initié quelque chose de concret.

Enfin, je veux terminer cette partie en clarifiant un point : j’adore OFF et j’ai prévu de continuer à y apporter ma pierre à l’avenir. Cette section a uniquement pour but de souligner quelques-unes des pistes d’amélioration.

Perspectives

Les projets lancés récemment autour des emballages, en partenariat avec l’ADEME, me paraît très intéressant. Même si je suis terrifié par la montagne de travail que représentent ces contributions, qui demandent de peser chaque élément de l’emballage avec une balance de précision, prendre la photo de celle-ci, l’envoyer sur la fiche et renseigner toutes les informations.

Opération Plein pot sur les emballages en partenariat avec l’ADEME

Un autre projet plus récent : OpenPrices. L’ambition est de suivre les prix des produits. Sacré boulot en perspective vu la volatibilité de cette donnée. Reste que les premiers résultats valent le détour et des processus ont déjà été élaborés pour automatiser certaines contributions.

Interface du projet Open Prices

La taxonomie des ingrédients est également prometteuse. Un peu de la même manière que les catégories (quoique plus complexe), référencer les ingrédients dans une arborescence (potentiellement liée aux données de Wikidata) va permettre de nouvelles réutilisations. Il y a également le projet de réaliser une taxonomie des marques.

Conclusion

À travers Open Food Facts, j’ai mis un pied plus globalement dans le monde du libre. Parfois, la motivation baisse devant l’aspect "sisyphéen" du projet : pour une fiche correctement complétée, 100 produits sont ajoutés. Mais, voir l’impact concret de son travail, par exemple via le Nutriscore, est très gratifiant.

Entre mon arrivée et aujourd’hui, la taille de la base mondiale a été multipliée par 100 et le taux de produits français a largement diminué, preuve de l’internationalisation du projet. Même si beaucoup reste à faire, OFF a d’ores et déjà apporté sa pierre à la transparence alimentaire.

Si j’ai incité ne serait-ce que deux ou trois personnes à modifier une fiche ou à ajouter un produit, j’aurai atteint mon objectif. Mais plus que Open Food Facts, cet article a pour but de vous inciter à contribuer à un commun numérique. Je tire surtout de cette expérience des rencontres et des discussions enrichissantes avec l’équipe au cœur du projet.

Photo de groupe aux OFF Days 2023

P.S. : Le E171 (ou dioxyde de titane), ce colorant controversé par lequel je me suis intéressé à OFF, est désormais interdit en Europe depuis 2022 après que la France l’ait bannie des aliments l’année précédente.

José Bové doit être content. :)

Liens & ressources

À lire
Mange et tais-toi (Serge HERCBERG, Editions humenSciences, février 2022)

À voir
Présentation d’Open Food Facts à l’édition 2015 de la convention Pas Sage en Seine
Une vidéo de la chaîne Projet Utopia qui parle surtout de Yuka mais aussi (un peu) de OFF

À écouter
Manon Corneille de Open Food Facts sur le podcast Projet Libres
Un épisode de l'émission "Le Meilleur des Mondes", sur France Culture, qui aborde les applications comme Yuka et Open Food Facts