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

GValiente développe un SDK pour créer des jeux pour la console Game Boy Advance : Butano.

Cet entretien revient sur son parcours et les raisons qui l’ont amené à s’intéresser à cette console.

Sommaire

• • Partie 1: présentation
    • Qui êtes-vous, quel est votre parcours et est-il lié aux jeux vidéos ?
    • Pourquoi le retrogaming est-il important pour vous ?
  • Partie 2: Game Boy Advance
    • Comment en êtes-vous venu à vous intéresser à la Game Boy Advance ?
    • Qu’est-ce que cette console a de particulier ?
    • Est-elle proche de la Game Boy ou de la SNES ?
    • Comment fonctionne l'affichage (PPU, écran LCD) ?
    • La console peut-elle faire de la 3D ?
    • Comment fonctionne le son ?
    • Comment marche la rétrocompatibilité avec les précédentes Gameboy ?
    • La machine possède une ROM interne, à quoi sert-elle ?
    • La GB possède un dispositif anti piratage, comment fonctionne-t-il ?
    • Comment fonctionne le réseau (Game Boy Link) ?
    • Les cartouches peuvent-elles embarquer des coprocesseurs ?
    • Les émulateurs sont-ils bons ?
    • Quels sont vos jeux commerciaux préférés sur cette console ?
    • Quels sont vos jeux "homebrew" préférés sur cette console ?
  • Partie 2 : Butano
    • Pourquoi créer un SDK aujourd’hui pour si vieux système ?
    • Est-ce que vous participez vous même à la création de jeux ?
    • Quels ont été les difficultés pour créer Butano ?
    • Vous aimeriez vivre du développement de ce logiciel libre?
    • Est-ce que Butano gère les accessoires (e-Reader, WormCam, Play-Yan…) de la console ?
    • Quels conseils donneriez-vous à quelqu’un qui veut se lancer dans le développement de jeux Game Boy Advance ?
    • Quels sont les outils pour créer/préparer des graphismes utilisable par Butano ?
    • Quels sont les outils pour créer/préparer des musiques et des sons utilisable par Butano  ?
    • Est-il possible de créer ses propres cartouches ?
    • Pourquoi le choix de C++ pour ce SDK ?
    • Est-ce qu'il existe d'autres SDK libres pour ces consoles ?
  • Partie 3: pour finir
    • En dehors du travail, quels logiciels libres utilisez-vous, sur quel OS ?
    • Au travail, quels logiciels libres utilisez-vous, sur quel OS ?
    • Quelle est votre distribution GNU/Linux préférée et pourquoi, quels sont vos logiciels libres préférés ?
    • Quelle question auriez-vous adoré qu’on vous pose ?
    • Quelle question auriez-vous détesté qu’on vous pose ?

Partie 1: présentation

Qui êtes-vous, quel est votre parcours et est-il lié aux jeux vidéos ?

Après des études d'informatique, j'ai travaillé dans plusieurs domaines autour du logiciel comme les pages web ou les applications graphiques Java/Swing.

Aujourd'hui je travaille plutôt en C et C++ dans l'embarqué, ainsi même si mon parcours professionel n'est pas directement lié aux jeux vidéos, mon boulot actuel en est plutôt proche.

Comme loisir, j'ai joué un peu avec RPG Maker 2K avant de commencer à programmer pour la GBA.

Pourquoi le retrogaming est-il important pour vous ?

D'abord pour la nostalgie : être capable de jouer à nouveau aux jeux de votre enfance est très important pour tout le monde. Malheureusement, pouvoir rejouer à de vieux jeux est quelque chose que nous sommes en train de perdre à cause des restrictions des jeux modernes (mode en ligne obligatoire, DRM…).

Ensuite, grâce aux émulateurs il est très facile de lancer sans problème des jeux que j'ai créés pour la GBA il y a 20 ans. Si je les avais fait pour Mandrake 8.0 à la place, ce ne serait pas aussi facile de les tester aujourd'hui sans recompiler du vieux code et autre.

Partie 2: Game Boy Advance

Comment en êtes-vous venu à vous intéresser à la Game Boy Advance ?

La GBA SP était un grand progrès par rapport au modèle original grâce à l'écran rétro-éclairé et la batterie intégrée, alors j'en ai acheté une dès qu'elle est sortie.

Les jeux 2D me manquaient après la N64 et la GameCube, alors pouvoir jouer à des classiques de la 2D comme Final Fight sur une console portable était génial.

Mais ce qui m'intéressait vraiment à propos de la GBA était la possibilité de créer des jeux grâce au HAM SDK et aux flashcarts.

Qu’est-ce que cette console a de particulier ?

C'est la dernière console 2D. Le système graphique de la GBA fonctionne comme les consoles 16 bits classiques comme la SNES ou la Megadrive, avec des sprites, des arrières plans…

Toutefois elle utilise un processeur ARM 32 bits tourant à 16MHz, alors il n'est plus nécessaire ou aussi important de programmer en assembleur pour avoir de bonnes performances.

En plus, je trouve plus "magique" de voir votre jeu tourner sur un écran d'une vieille console portable que sur un écran de télévision.

Est-elle proche de la Game Boy ou de la SNES ?

Au niveau graphique, c'est comme une SNES avec plus de couleurs simultanées, plus d'arrière plans et beaucoup de sprites par scanline (proche d'une Neo Geo et en plus on peut leur appliquer une rotation !). Elle permets aussi d'utiliser un "framebuffer" qui rends le rendu "logiciel" plus facile. Les jeux 3D comme Doom sont beaucoup plus rapide sur la GBA grâce à ces modes. Malheureusement la résolution de l'écran est un peu trop basse (240x160 contre 256x224 pour la SNES par exemple).

Cependant, au niveau son, c'est pire que la SNES: la GBA partage le même canal PSG que la Game Boy originale avec deux nouveaux canaux directs pour jouer des samples PCM. Avoir seulement deux canaux PCM demande presque toujours de gâcher des tonnes de cycles CPU en mixage audio et même après cela sonne toujours pire que la SNES.

Comment fonctionne l'affichage (PPU, écran LCD) ?

Comme je l'ai dit, cela fonctionne comme une SNES : vous avez un nombre fixe d'arrière plans et de sprites, vous les configurez en écrivant des registres. La GBA a aussi des interruptions HDMA et H-Blank, donc vous pouvez faire beaucoup d'effets "raster" comme le fameux mode 7 de la SNES.

Néanmoins, quelques limitations pénibles du PPU de la SNES ont été retiré, ce qui rends le PPU de la GBA plus facile à programmer. Par exemple, la GBA permets d'écrire en VRAM pendant le "V-Draw" (quand le PPU rafraîchit l'écran). Cela permets d'utiliser toutes les tailles de sprites disponibles en même temps alors que la SNES ne permettait que deux tailles simultanément.

La console peut-elle faire de la 3D ?

La GBA n'a pas d'accélération 3D matérielle, mais son CPU est assez rapide pour faire du rendu logiciel (à un faible taux de rafraîchissement). Il y a quelques techniques pour dessiner des polygones 3D avec des sprites 2D, mais cela vient avec des tonnes de limitations. Dans Varooom 3D, j'ai utilisé des sprites 2D poour dessiner des lignes horizontales, ce qui m'a permis de dessiner quelques polygones non texturés à 60 images par seconde.

Comment fonctionne le son ?

Je ne sais pas très bien comment fonctionne l'audio de la GBA, car je n'en ai pas eu besoin : il y a de très bonnes bibliothèques disponibles et j'ai préféré les intégrer plutôt que d'implémenter ma propre solution.

Comment marche la rétrocompatibilité avec les précédentes Gameboy ?

Il y a 3 modèles de GBA disponible: GBA, GBA SP and GBA Micro. Seules les deux premières sont compatibles avec la Game Boy originale.
La rétrocompatibilité est transparente pour le développeur et la plupart des fonctionnalités de la Game Boy sont indisponibles en mode "natif" : un jeu GBA ne peut pas utiliser le CPU de la Game Boy par exemple.

La machine possède une ROM interne, à quoi sert-elle ?

La GBA démarre depuis le BIOS, une petite ROM qui montre l'écran d'accueil et exécute le jeu après cela. Il a aussi quelques fonctions liées à l'énergie, comme arrêter le CPU jusqu'au V-Blank ou mettre la console en veille. Enfin, il propose quelques routines comme des fonctions mathématiques, mais je ne les utilise pas pour des questions de performances. Cela aide aussi à éviter les bugs d'émulation du BIOS.

La GB possède un dispositif anti piratage, comment fonctionne-t-il ?

Je préfère vous renvoyer à l'article de copetti.org sur le sujet.

Comment fonctionne le réseau (Game Boy Link) ?

Comme pour l'audio, je ne sais pas trop comment cela fonctionne, car j'ai préféré intégrer une bibliothèque.
En général je préfère une bonne bibliothèque plutôt que passer du temps à implémenter une plus mauvaise solution.

Les cartouches peuvent-elles embarquer des coprocesseurs ?

Bien sûr, mais le CPU est tellement puissant par rapport à ceux des consoles 16 bits, qu'il n'y en a pas souvent besoin. Le meilleur exemple d'une cartouche officielle avec un coprocesseur dont je me rappelle est la Play-Yan : elle semble embarquer un VideoCore 1 pour jouer des musiques mp3 et des vidéos mp4 depuis une carte SD.

Les émulateurs sont-ils bons ?

Extraordinaires. Les émulateurs GBA sont si bons que vous n'avez presque jamais besoin de tester sur du vrai matériel. Si votre jeu fonctionne sur la plupart des émulateurs modernes, alors votre jeu a toutes les chances de fonctionner sur une console réelle sans souci. D'ailleurs la plupart des membres actifs de gbadev ne possèdent même pas de GBA.

Quels sont vos jeux commerciaux préférés sur cette console ?

Beacoup :

• des joyaux de Treasure comme Astro Boy Omega Factor et Gunstar Super Heroes ;
• d'autres jeux d'action comme Ninja Five-0, Dragon Ball Advanced Adventure et Final Fight ;
• tous les Castlevanias (qui sont proches du Simphony of the Night de la PS1) ;
• les ports de Doom ;
• bien sûr les classiques de Nintendo comme Wario Ware et Zelda the Minish Cap ;
• des RPGs bien connus comme Mother 3, Mario and Luigi et Final Fantasy I&II ;
• quelques RPGs moins connus comme Riviera et CIMA the Enemy.

Quels sont vos jeux "homebrew" préférés sur cette console ?

Il y en a beaucoup aussi, mais mon préféré est de loin GBA Microjam '23: c'est une collection de mini jeux très amusants à la Wario Ware.
Ce qui le rend très spécial, c'est que chaque mini-jeu a été fait par un membre différent de gbadev, c'est un jeu "communautaire".

D'autres très bons:

• Goodboy Galaxy ;
• Demons of Asteborg DX ;
• GBADoom, un portage opensource de Doom ;
• SNESAdvance ;
• OpenLara ;
• Super Wings ;
• Symbol Merged ;
• Anguna
• Vulkanon ;
• Inheritors of the Oubliette ;
• Demoscene entries like all Shitfaced Clowns prods ;
• et les jeux que j'ai fait bien sûr.

Partie 2 : Butano

Pourquoi créer un SDK aujourd’hui pour si vieux système ?

L'objectif de Butano était de pouvoir travailler avec le PPU de la GBA et le reste du système aussi facilement que possible sans perdre trop de cycles CPU. Et je pense que j'y suis arrivé : avec Butano, vous pouvez créer, afficher et détruire des sprites, des arrière plans, du texte, des effets raster et plus encore avec une seule ligne de C++.

Les prémisses de Butano étaient une bibliothèque interne à mes jeux. Je n'avais pas de plan pour rendre ça public à part faire quelques exemples et de la documentation.

Finalement je suis content d'avoir rendu ça public : le plus grand accomplissement de Butano est le grand nombre de jeux de qualité fait avec.

Est-ce que vous participez vous même à la création de jeux ?

Oui, Butano vient avec le code source de deux jeux que j'ai fait : Butano Fighter et Varooom 3D.

Quels ont été les difficultés pour créer Butano ?

Pour être honnête, je n'ai pas eu beaucoup de difficultés grâce au grand nombre de bibliothèques, tutoriaux, émulateurs et outils disponibles pour la GBA.

Vous aimeriez vivre du développement de ce logiciel libre?

Bien sûr, mais à moins de travailler à plein temps sur un jeu homebrew à grand succès, c'est difficile voire impossible de vivre de ça.

Est-ce que Butano gère les accessoires (e-Reader, WormCam, Play-Yan…) de la console ?

Il gère les accessoires les plus communs : SRAM, rumble et l'horloge temps réel / real time clock (RTC).

Pour les accessoires plus exotiques, je pense qu'il est préférable d'utiliser d'autres bibliothèques.

Quels conseils donneriez-vous à quelqu’un qui veut se lancer dans le développement de jeux Game Boy Advance ?

Premièrement, vous devez apprendre les bases du C/C++ : la plupart des nouveaux connaissent uniquement des langages de haut niveau comme Javascript ou Python, malheureusement ils sont un peu trop lourds pour la pauvre GBA.

Après, vous pouvez suivre cet excellent guide plutôt que suivre mes modestes conseils.

Quels sont les outils pour créer/préparer des graphismes utilisable par Butano ?

J'utilise Gimp et Usenti (un logiciel proche de MS Paint pour la GBA et notamment une gestion des couleurs 15 bits et des palettes). Toutefois, la plupart des outils permettant de produire des images indexées peuvent faire l'affaire.

Pour le travail des cartes, j'aimais utiliser Tiled par le passé.

Quels sont les outils pour créer/préparer des musiques et des sons utilisable par Butano  ?

OpenMPT est l'outil audio le plus populaire pour la GBA, les musiques étant généralement créées avec un tracker. Il a aussi de bons outils pour travailler avec les samples. D'autres utilisent hUGETracker et Furnace.

Est-il possible de créer ses propres cartouches ?

Je ne suis pas juriste, mais comme Butano est sous licence zlib, tant que vous respectez cette licence et celles des autres dépendances, vous pouvez faire vos propres cartouches et même les vendre.

Je pense que ce que font la plupart des gens aujourd'hui, c'est acheter des cartouches pirates Pokémon pas chères, et les flasher pour y mettre leurs propres jeux.

Pourquoi le choix de C++ pour ce SDK ?

Comme je l'ai dit, un langage de haut niveau avec ramasse miettes est généralement trop pour la GBA.

Entre C et C++, j'ai choisi ce dernier, car il permet de réduire grandement la quantité de code sans gâcher trop de CPU.

Par exemple:

• les destructeurs de C++ permettent de ne pas avoir à écrire trop de code pour nettoyer les ressources, ce qui est une source de bugs importante sur les grands projets GBA ;
• la GBA ne gère pas les nombres flottants en hardware, donc utiliser des nombres en virgule fixe est essentiel. Grâce à la surcharge d'opérateurs, C++ permets d'écrire des classes qui se comportent comme des nombres flottants.
• L'opérateur constexpr permet de générer et stocker des tables de correspondance (lookup tables) ou autres constantes en ROM sans avoir à utiliser d'outils externes.

Est-ce qu'il existe d'autres SDK libres pour ces consoles ?

Il y a beaucoup de SDK pour GBA, mais malheureusement (à mon avis) la plupart sont de plus bas niveau que Butano.

Voici une liste de ressources (compilers, toolkits, libraries, etc.) pour la GBA: resources GBA.

Partie 3: pour finir

En dehors du travail, quels logiciels libres utilisez-vous, sur quel OS ?

J'utilise généralement Windows à cause du boulot et de certains jeux PC, mais la plupart des programmes que j'utilise sont libres.

L'éditeur de code que j'utilise presque toujours est Qt Creator, il est génial pour C++.

À part les logiciels libres pour le développement GBA, j'utilise Firefox, Notepad++, VLC, 7-Zip, LibreOffice, TortoiseGit, VirtualBox et bien sûr les émulateurs pour les vieilles consoles et bornes d'arcade.

Au travail, quels logiciels libres utilisez-vous, sur quel OS ?

Pour le développement embarqué, j'utilise GCC et les outils GNU. Pour les applications de bureau, j'utilise Qt avec MinGW.

GCC est aussi le compilateur le plus populaire pour le développement GBA, alors je n'aurais pas pu l'éviter même si j'avais voulu.

D'autres logiciels que j'utilise au travail : Thunderbird, Putty and WinSCP.

Quelle est votre distribution GNU/Linux préférée et pourquoi, quels sont vos logiciels libres préférés ?

Ubuntu est bien pour le peu d'usage de Linux que je fais.

Mes logiciels libres favoris sont ceux avec lesquels je passe le plus de temps : Firefox, Qt Creator, GCC, les émulateurs.

Quelle question auriez-vous adoré qu’on vous pose ?

Mmh… rien qui me vienne à l'esprit.

Quelle question auriez-vous détesté qu’on vous pose ?

Pourquoi perdez-vous votre temps avec des consoles vieilles de 20 ans ?

Maintenant que j'y pense… J'aurais adoré qu'on me demande ça.

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 ?