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 a aussi des modes "bitmaps" qui rendent 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 a même le 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-DRAM" (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 Simphony of the Night comme Castlevanias.
• les ports de Doom ;
• bien sûr les classiques de Nintendo classics 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 accéssoires 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 lourd 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érallement créées par 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 d'appels 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'utlise 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.

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.

Ubix Linux est une distribution Linux libre et open-source dérivée de Debian.

Le nom « Ubix » est la forme contractée de « Ubics », acronyme issu de l'anglais Universal business intelligence computer system. De fait, le principal objectif d'Ubix Linux est d'offrir une plateforme universelle dédiée à l'informatique décisionnelle et à l'analyse des données.

Il s'agit d'une solution verticale, prête à l'emploi, dédiée à la manipulation des données et à la prise de décision. Allégée par conception, elle n'embarque qu'un jeu limité d'outils spécialisés dans ce domaine. Ceux-ci permettent néanmoins de couvrir tous les besoins dont l'acquisition, la transformation, l'analyse et la présentation des données.

Origines de la distribution

La volonté initiale du concepteur de la distribution était de pouvoir disposer, à tout moment et en toutes circonstances, des outils lui permettant de réaliser des analyses de données et d'en présenter le résultat ad hoc. Ce « couteau suisse » de manipulation des données, devait également lui permettre d'éviter de devoir justifier, rechercher, acquérir et installer l'écosystème logiciel nécessaire chaque fois que ce type de tâches se présentait à lui.

Son cahier des charges stipulait donc une empreinte disque la plus faible possible sans pour autant faire de concessions au niveau des fonctionnalités. La distribution se devait d'être portable et exécutable immédiatement dans des contextes variés, sans nécessité d'investissement, d'installation ou de droits d'accès particulier.

De ce fait, Ubix Linux ne se démarque pas par ses aspects « système », mais plutôt par sa destination et ses cas d'usage.

Au-delà du besoin initial

À l'heure où de nombreux concepts liés à la manipulation des données tels que le « Big Data », la « Data Science » ou le « Machine Learning » font la une de nombreux médias, ceux-ci restent encore des boîtes noires, affaire de spécialistes et d'organisation disposant des moyens de les mettre en application.

Si le grand public en intègre de mieux en mieux les grandes lignes, il ne dispose encore que de peu de recul sur la manière dont ses données peuvent être utilisées, ainsi que la richesse des débouchés associés.

D'un autre côté, de nombreux gisements de données à la portée du plus grand nombre demeurent inexploités, faute de compétences ou de moyens facilement accessibles.

Il se trouve qu'Ubix Linux peut permettre de surmonter cette difficulté, en offrant à tous les moyens de s'approprier (ou se réapproprier) et tirer parti des données disponibles.

Philosophie

Par nécessité, Ubix Linux a été conçue en intégrant uniquement des produits libres et open-source. Bien que cette distribution puisse s'avérer utile à toute personne devant manipuler des données, elle se doit de préserver et défendre une approche pédagogique et universaliste.

Elle a pour ambition de mettre les sciences de données à la portée de tous. La distribution en elle-même n'est qu'un support technique de base devant favoriser l'apprentissage par la pratique. Il est prévu de l'accompagner d'un tutoriels progressifs.

Les outils low-code/no-code intégrés dans la distribution permettent de commencer à manipuler des données sans devoir maîtriser au préalable la programmation. Néanmoins, des outils plus avancés permettent ensuite de s'initier aux principes des algorithmes d'apprentissage automatique.

Synthèse

Ubix Linux s'inscrit dans la philosophie du logiciel libre et plus particulièrement dans celle des projets GNU et Debian.

Elle se destine à :

• demeurer accessible à tous ;
• pouvoir s'exécuter sur des configurations matérielles relativement modestes, voire n'être installée que sur un périphérique portable USB ;
• proposer un outil pédagogique pour appréhender de façon pratique la science des données et l'apprentissage machine ;
• permettre la découverte, l'expérimentation et l'aguerrissement de tout un chacun aux principaux outils de manipulation des données ;
• offrir une boîte à outils légère et agile, néanmoins complète et utile pour un public professionnel averti.

Et après…

Nous sommes à l'écoute de toute suggestion. Toutefois, les moyens étant ce qu'ils sont (au fond du garage), la réactivité à les prendre en compte pourra s'avérer inversement proportionnelle.

Nous souhaiterions que cet outil pédagogique puisse bénéficier au plus grand nombre : si vous voulez contribuer à la traduction du contenu du site officiel en espagnol, en portugais ou en allemand, vous êtes les bienvenus.