Instantané du 29 octobre 2026. Ce dossier décrit les quatre dépôts tels qu'ils étaient ce jour-là ; les projets ont continué d'avancer depuis, et les dépôts font foi. Les liens soulignés mènent aux sources, figées à leur état de ce jour. La suite vit sur gnu6dotlive.github.io.
Comprendre
Trois mots à désarmer
« Open source », « dépôt », « preuve ». Trois expressions qui reviennent partout et qui veulent souvent dire moins — ou plus — que ce qu'on croit.
Open source : la recette, pas le plat #
Un restaurant peut publier sa recette complète. Cela ne veut pas dire que le plat est bon, que la cuisine est ouverte, ni que quelqu'un vous servira à table. Cela veut dire que vous pouvez la refaire vous-même, la corriger, et vérifier ce qu'il y a dedans.
C'est exactement ce que fait une licence libre : elle vous donne le droit de lire, modifier et redistribuer. Elle ne promet ni qualité, ni support, ni mode d'emploi.
Un dépôt, c'est un dossier avec une mémoire #
Un « dépôt » (en anglais repository) est un dossier de fichiers dont l'historique est conservé. Chaque modification enregistrée s'appelle un commit : elle garde la date, l'auteur et une explication. On peut donc savoir qui a changé quoi, quand, et pourquoi.
Le fichier README.md est la porte d'entrée : ce que l'auteur veut que vous sachiez d'abord. Les dossiers docs/ contiennent la documentation, evidence/ les preuves, crates/ le code découpé en paquets.
Commit
Une modification enregistrée, avec son message et sa date. L'unité de l'histoire du projet.
Issue
Un problème ou une demande, discuté publiquement. Une todo-list visible.
Pull request
Une proposition de modification, que l'auteur peut relire avant de l'accepter.
Licence
Le contrat qui dit ce que vous pouvez faire du code. MIT est permissive ; GPL impose de partager vos modifications.
CI
« Intégration continue » : des contrôles automatiques lancés à chaque changement.
Fork
Une copie indépendante d'un projet, que l'on fait évoluer de son côté.
« Ça marche » ne veut rien dire tout seul #
C'est la leçon centrale des quatre projets. Une fonctionnalité peut être décrite, écrite, testée, observée chez son auteur, ou utilisée par un tiers. Ce sont cinq choses différentes, et les confondre est la source de presque toutes les déceptions.
Le vocabulaire, traduit #
Le bureau
| Terme | Traduction |
|---|---|
| Compositeur | Le programme qui assemble les fenêtres et l'affichage. Sous Linux, Hyprland en est un. |
| Wayland | Le protocole moderne par lequel un programme parle à l'affichage. |
| GPUI | La bibliothèque de rendu utilisée par gnosix, issue de l'éditeur Zed. |
| Surface | Une zone dessinée à l'écran : la barre, le deck, une fenêtre, un panneau. |
| Crate | Un paquet de code Rust. gnosix en compte une quarantaine, séparés par domaine. |
| Rust | Un langage de programmation réputé pour sa sûreté mémoire et sa performance. |
| Zig | Un autre langage, utilisé par le moteur de Calix. |
L'intelligence artificielle locale
| Terme | Traduction |
|---|---|
| Modèle | Un très gros ensemble de nombres ajustés pour produire du texte. « 30 milliards de paramètres » donne une idée de sa taille. |
| Paramètre | Un nombre interne du modèle. Plus il y en a, plus le modèle est volumineux et coûteux à faire tourner. |
| Quantisation | Compresser les nombres sur moins de bits (Q2_K, Q3_K…). Moins de mémoire, un peu moins de précision. |
| MoE | « Mixture of experts » : le modèle n'active qu'une partie de ses réseaux pour chaque mot. |
| Jeton | Un fragment de mot. Les débits se mesurent en jetons par seconde (tok/s). |
| Inférence | Le fait d'utiliser un modèle déjà entraîné, par opposition à son entraînement. |
| GPU / VRAM | La carte graphique et sa mémoire dédiée. Rapide, mais petite sur une machine personnelle. |
| Résidence | L'endroit où un morceau de modèle est réellement chargé : carte graphique ou mémoire centrale. |
| Benchmark | Une mesure comparative, avec un protocole. Sans protocole, un chiffre n'est qu'une anecdote. |
| mistral.rs | Un moteur d'inférence écrit en Rust. À ne pas confondre avec Mistral AI, l'entreprise qui produit des modèles. |
| llama.cpp | Un moteur d'inférence très répandu, souvent utilisé comme référence de performance. |
| A/B apparié | Comparer deux versions en alternant les exécutions, sur la même machine et les mêmes entrées. C'est ce qui rend un « ×2 » crédible. |
Les logiciels et la scène
| Terme | Traduction |
|---|---|
| Paquet | Un logiciel prêt à installer, avec ses dépendances. Sur Arch Linux, il s'installe avec pacman. |
| ALPM | La bibliothèque qui fait le vrai travail derrière pacman : résoudre les dépendances, écrire les fichiers. |
| AUR | Les dépôts communautaires d'Arch : des recettes de compilation, maintenues par des bénévoles. |
| Flatpak / AppImage | Deux façons d'emporter une application avec ses dépendances, hors du système. Isolée pour l'une, autonome en un seul fichier pour l'autre. |
| polkit | Le mécanisme qui demande l'autorisation au moment de l'action, pour une opération précise — au lieu de donner tous les droits d'avance. |
| Provenance | L'origine d'un logiciel : quel dépôt, quel mainteneur, donc à qui vous aurez affaire. Ce n'est pas une décoration. |
| Scène | L'ensemble des objets, relations, positions et contraintes qu'un moteur considère comme vrais. |
| Projection / renderer | La traduction d'une scène en pixels, faite par un programme de rendu. Le renderer observe ; il ne décide pas de ce qui existe. |
| Topologie | La carte des places et des liens — y compris quand elle change. Le fil rouge des quatre dépôts. |
Quatre questions à poser à n'importe quel dépôt #
1. Quelle est la dernière version stable ?
Si la réponse est « aucune », ce n'est pas un défaut : c'est une information. Un projet expérimental assumé vaut mieux qu'un projet instable qui se présente comme fini.
2. Que dit le document de statut ?
Les bons projets ont un fichier qui liste ce qui marche, ce qui ne marche pas, et ce qui reste à faire. Cherchez-le avant de croire le README.
3. Les échecs sont-ils documentés ?
Un projet qui ne publie que ses réussites cache quelque chose. Les quatre dépôts présentés ici gardent leurs essais ratés, avec leur cause.
4. Puis-je vérifier moi-même ?
Commandes de test, empreintes de fichiers, reçus de mesure : la preuve doit être rejouable, pas seulement racontée.
Pourquoi cette insistance sur la preuve #
Dans un domaine où les annonces vont plus vite que les résultats, la chose la plus utile qu'un projet puisse offrir n'est pas une promesse : c'est une frontière claire entre ce qui est démontré et ce qui ne l'est pas.
Cette frontière permet de lire un dépôt sans être dupe, de l'essayer sans se tromper d'attente, et de le financer sans acheter une illusion.