EXP C12 — Git / GitHub : conserver ce que nous avons appris

EXP C12 — Git / GitHub : conserver ce que nous avons appris

Il y a un moment particulier dans une expérience technique.

Le matériel fonctionne.

Le logiciel fonctionne.

La restauration fonctionne.

Et l’on pourrait simplement remettre la carte micro-SD dans le Raspberry Pi, refermer le boîtier et passer à autre chose.

Mais après tout ce que nous avons fait avec cette vieille Canon LBP-810, quelque chose manquerait.

Nous aurions conservé la machine.

Mais pas nécessairement tout ce que nous avons appris en la reconstruisant.

Une image disque ne raconte pas toute l’histoire.

Dans l’expérience précédente, nous avons démontré qu’une image complète pouvait être restaurée et reconstruire le serveur :

working
     ↓
stable
     ↓
backed up
     ↓
restored
     ↓
working again

C’était une étape importante.

Mais le Gold Master reste avant tout une photographie complète d’un état matériel et logiciel.

Il contient le système, les fichiers, les configurations, les paquets installés, le pilote CAPT, CUPS, Avahi et tout ce qui permet au serveur de fonctionner à cet instant précis.

Il ne contient pas facilement l’histoire du projet.

Il ne raconte pas pourquoi telle commande a été nécessaire.

Il ne conserve pas naturellement les différentes hypothèses que nous avons testées.

Il ne distingue pas toujours ce qui relève de l’installation historique, de la réparation ou de notre propre travail.

Et surtout, il ne permet pas de comprendre rapidement comment nous sommes arrivés à cet état.

Pour cela, il fallait autre chose.

Le changement de perspective.

Jusqu’ici, notre objectif était essentiellement de faire fonctionner la Canon.

Nous avions dû comprendre son interface CAPT, son pilote historique, CUPS, le périphérique USB, le réseau, le Wi-Fi, Avahi, les problèmes de noyau et finalement la sauvegarde complète du système.

À partir de maintenant, le problème est différent.

Nous ne cherchons plus seulement à faire fonctionner.

Nous cherchons à préserver.

working server
      ↓
configuration
      ↓
documentation
      ↓
historical source
      ↓
rebuild procedure
      ↓
version control

Et c’est précisément le rôle de Git.

Pourquoi Git ?

Git n’est pas nécessaire pour imprimer une page sur une LBP-810.

Il n’est même pas nécessaire pour reconstruire le serveur à partir du Gold Master.

En revanche, il devient extrêmement utile dès que nous voulons conserver les éléments qui ont permis de comprendre et de reconstruire le projet.

Nous pouvons alors versionner :

README
documentation
source archive
PPD
rebuild procedure
configuration notes
project history
      ↓
Git

Chaque modification possède son historique.

Chaque étape importante peut être identifiée.

Et surtout, le projet ne dépend plus uniquement de notre mémoire.

Le dépôt Canon LBP-810 Revival.

Nous avons donc créé un dépôt GitHub consacré au projet :

Canon LBP-810 Revival

Le dépôt est volontairement séparé du serveur lui-même.

Il ne cherche pas à devenir une nouvelle copie du système.

Il constitue plutôt l’archive technique du projet.

Nous y conservons notamment :

Canon LBP-810 Revival
        │
        ├── README.md
        │
        ├── docs/
        │     ├── revival.md
        │     └── rebuild.md
        │
        └── historical/
              └── capt-0.1.tar.gz

Chaque élément répond à une fonction différente.

Le README.

Le README explique ce qu’est le projet.

Il rappelle notamment que cette résurrection repose sur un pilote CAPT historique et que nous ne sommes pas les auteurs du pilote original.

Cette distinction est importante.

Le pilote historique CAPT 0.1 a été publié en 2004 par Nicolas Boichat, avec les attributions et la licence conservées dans les sources originales.

Nous avons donc conservé l’archive originale sans la réécrire :

Historical driver
        ↓
Nicolas Boichat
        ↓
CAPT 0.1
        ↓
original source and license
        ↓
2026 revival

Notre travail commence ensuite.

Il consiste à reprendre cet héritage, à le faire fonctionner dans un environnement Linux moderne et à documenter tout ce qui a été nécessaire pour y parvenir.

Autrement dit :

nous ne prétendons pas avoir écrit le pilote.
Nous documentons sa résurrection.

La documentation technique.

Le fichier docs/revival.md conserve l’histoire technique du projet.

On y retrouve l’environnement final, le matériel, la chaîne d’impression, le pilote CAPT, CUPS, Avahi, les tests et les résultats obtenus.

Il permet de comprendre ce qui fonctionne réellement, indépendamment du récit des articles.

Le second document, docs/rebuild.md, va plus loin.

Il rassemble les étapes nécessaires pour reconstruire l’environnement :

base system
    ↓
packages
    ↓
CUPS
    ↓
Avahi
    ↓
CAPT
    ↓
USB printer
    ↓
PPD
    ↓
CUPS queue
    ↓
test print

Ce document n’est donc pas simplement une description.

Il constitue une procédure de reconstruction.

Nous avons ainsi deux niveaux de conservation :

revival.md
    = what we learned

rebuild.md
    = how to rebuild it

Et le pilote original ?

Nous avons également conservé dans le dépôt l’archive originale :

capt-0.1.tar.gz

L’archive a été conservée telle quelle, avec son historique, son copyright et sa licence.

Son empreinte SHA-256 permet également de l’identifier sans ambiguïté.

0a8ec900feea36ad025e0bd7e7c0593e58aec5368e2adc05609d80c0f9914cdf

Ce détail peut sembler anodin.

Il ne l’est pas.

Lorsque l’on travaille avec du logiciel ancien, la provenance devient rapidement aussi importante que le code lui-même.

Le Gold Master reste à part.

Il aurait été tentant de vouloir tout mettre dans GitHub.

Mais ce serait une mauvaise idée.

Notre image complète de référence est une image disque du serveur, avec tout son état système.

Elle constitue un Gold Master de laboratoire.

Elle n’a donc pas sa place dans le dépôt Git.

GitHub
  ↓
source
documentation
procedures
history

Gold Master
  ↓
complete machine state

Cette séparation est volontaire.

Git conserve le savoir et les matériaux nécessaires à la reconstruction.

Le Gold Master conserve l’état complet d’une machine qui fonctionne.

Les deux sont complémentaires.

Pourquoi ne pas publier simplement l’image ?

Une image disque complète peut contenir beaucoup plus d’informations qu’on ne le pense.

Elle peut notamment conserver des clés SSH, des paramètres réseau, des historiques, des identifiants de machine ou d’autres éléments spécifiques à l’installation d’origine.

Une image parfaitement adaptée à notre laboratoire n’est donc pas automatiquement une image prête à être distribuée au public.

C’est une distinction importante que l’expérience C11 nous a permis de voir très concrètement.

Une sauvegarde complète et une distribution publique ne sont pas nécessairement la même chose.

Ce que Git apporte réellement.

Après douze expériences, le projet n’est plus seulement constitué d’une vieille imprimante et d’un Raspberry Pi.

Nous avons maintenant :

hardware
    +
historical software
    +
modern Linux environment
    +
configuration
    +
tested procedures
    +
restoration method
    +
documentation
    +
version history

Et c’est probablement ce dernier élément qui change le plus la nature du projet.

Nous ne possédons plus seulement un système qui fonctionne.

Nous possédons désormais une expérience technique documentée.

De C01 à C12.

Lorsque nous regardons la série dans son ensemble, le chemin parcouru est assez révélateur.

C01 → C09
make it work
and understand it

C10
make it reproducible

C11
prove that it can be restored

C12
preserve what we learned

Ce n’est donc pas vraiment douze articles séparés.

C’est une seule expérience découpée en plusieurs problèmes.

Nous sommes partis d’une imprimante pratiquement oubliée.

Nous avons traversé plusieurs systèmes, plusieurs approches, plusieurs problèmes matériels et logiciels, plusieurs générations de pilotes et plusieurs méthodes de sauvegarde.

Et nous avons finalement obtenu quelque chose de beaucoup plus intéressant qu’une simple impression de test.

Nous avons une méthode.

Le rôle de GitHub dans tout cela.

GitHub ne remplace donc ni le Raspberry Pi, ni le Gold Master, ni les articles StalkerLabs.

Il occupe simplement une autre place dans l’ensemble.

StalkerLabs
    ↓
the story

GitHub
    ↓
the technical archive

Gold Master
    ↓
the machine state

Les articles racontent l’enquête.

GitHub conserve les éléments techniques.

Le Gold Master permet de retrouver l’état fonctionnel.

Et les trois ensemble racontent beaucoup mieux ce qui s’est réellement passé.

Un projet peut donc survivre à sa machine.

C’est probablement la conclusion la plus importante de cette dernière expérience.

Une carte micro-SD peut mourir.

Un Raspberry Pi peut mourir.

Un vieux pilote peut devenir difficile à retrouver.

Un ordinateur peut être remplacé.

Nous-mêmes pouvons oublier pourquoi une commande était nécessaire.

Mais si le travail est documenté correctement, le projet peut continuer d’exister.

La machine peut disparaître.
L’expérience, elle, peut rester.

Le Canon LBP-810 Revival est-il terminé ?

Pour cette série, oui.

Nous avons désormais :

Le dossier est donc suffisamment documenté pour être considéré comme reproductible.

Mais attention.

Il ne faudrait surtout pas en conclure que le laboratoire ferme ses portes.

Nous avons simplement terminé cette expérience.

Et dans notre cas, ce n’est pas exactement la même chose que terminer les expériences.

The experiment is completed.

The investigation is not.

There will always be another machine,
another driver,
another strange kernel,
another piece of hardware
that someone decided was obsolete.

And naturally,
we will want to know why it still works.

Conclusion :

Nous avons commencé avec une question relativement simple :

Peut-on encore faire fonctionner une Canon LBP-810 aujourd’hui ?

La réponse est désormais connue.

Oui.

Mais au cours de cette expérience, la question a progressivement changé.

Nous avons ensuite demandé :

Peut-on comprendre pourquoi elle fonctionne ?

Puis :

Peut-on reconstruire le serveur ?

Et finalement :

Peut-on conserver tout ce que nous avons appris ?

La réponse à cette dernière question passe désormais par Git, GitHub, la documentation et le Gold Master.

Le serveur fonctionne.

Nous savons pourquoi.

Nous savons le reconstruire.

Nous savons le restaurer.

Et maintenant, nous savons aussi conserver ce que nous avons appris.

════════════════════════════════════════════════════════════
                    EXPERIMENT COMPLETED
════════════════════════════════════════════════════════════

Canon LBP-810 Revival
C01 → C12

The printer works.
The server works.
The restoration works.
The knowledge is preserved.

The experiment is completed.
The investigation is not.
════════════════════════════════════════════════════════════

AxehGo & DebIA — Independent Research & Experiments in Linux, AI and Statistical Computing