Le site arthur.bebou.netlib.re - retour accueil
git clone git://bebou.netlib.re/arthur.bebou
Log | Files | Refs |
commit 0e67de04d5e5fdb6b03eb2ed1ab587ffc72e5ea6 parent d6e3780c75f986bd6f5947fd658167864c1ec8d1 Auteurice: Arthur Pons <arthur.pons@unistra.fr> Date: Sat, 26 Apr 2025 13:43:48 +0200 Ajout article portage catium debian 1997 Il est cool celui-ci Diffstat:
| A | contents/catium-archeo/index.sh | | | 344 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
1 file changed, 344 insertions(+), 0 deletions(-)
diff --git a/contents/catium-archeo/index.sh b/contents/catium-archeo/index.sh @@ -0,0 +1,344 @@ +#! page +title: Faire du retro-portage, l\'exemple de catium +author: Arthur Pons +description: Et si l\'on essayait de faire fonctionner catium dans le passé ? Qu\'est-ce que cela va nous coûter ? +publication: 2025-04-26 + +section: main + +Article pas relu. J'ai un nouveau clavier dont les touches sont très dures donc +j'oublie souvent des lettres. + +Le travail décrit dans cet article est le fruit d'une collaboration avec +Guillaume Salagnac et Lou Paul-Dauphin, respectivement chercheur et stagiaire +au CITI à l'INSA Lyon. Merci à eux. + +## Introduction + +Phenix est une équipe de recherche s'intéressant à la frugalité dans le +numérique. Dans ce cadre là elle s'intéresse aux liens entre nos pratiques du +numériques et les technologies anciennes[^1]. Elle explore ces liens en tentant +de répondre à des questions du type : "Etait-il possible de faire wikipedia en +1997 ?" et "Si oui, pour quels compromis ?". Ce faisant elle met à jour dans +quelle mesure les progrés en informatique sont des conditions nécessaires ou pas +à reproduire des services numériques aujourd'hui presque universellement +reconnus comme souhaitables. + +Par ailleurs j'avais pour envie de tester jusqu'à quand fallait-il remonter pour +que catium ne fonctionne plus. Autrement dit répondre à la question "depuis +quand catium peut-il fonctionner tel quel sans qu'il n'ait besoin d'être modifié +?". Alors forcément lorsque j'en ai parlé à Guillaume et Lou ça a parfaitement +matché. C'est l'occasion pour nous de tester empiriquement l'intuition que l'on +a souvent tenu pour vraie à Katzele, celle que de faire des logiciels avec la +boite à outil traditionnelle d'Unix permet de faire du logiciel qui nécessite +peu de maintenance à long terme. + +## Le portage + +Dans le cadre de l'archéologie wikipedienne Lou a fait fonctionné un debian bo +1.3 datant de 1997 en suivant [ce +tuto](https://www.arsouyes.org/articles/2019/51_debian1.3/), corrigé depuis dans +[cet article](https://www.arsouyes.org/articles/2025/2025-03-04_Archeologie/) +suite aux problèmes rencontrés. Si vous voulez vous aussi avoir une debian 1.3 +mais que vous préférez qemu vous pouvez suivre le readme de [ce dépôt +github](https://github.com/rdebath/debian-bo). + +Pour répondre à notre question il était alors plus simple de prendre le problème +à l'envers, c'est à dire porter catium sous debian 1997 puis affirmer que catium +fonctionne tel quel depuis cette date là. La question devient alors "Qu'est-ce +que ça coûte de porter catium en 1997 ?". Un autre question intéressante serait +"Si le portage iso-fonctionnel n'est pas possible ou trop coûteux, qu'à-t-on +gagné depuis 1997 ?" ou, formulé autrement, "Que perd-t-on dans catium en se +limitant à des technologies de 1997 ?". + +### Le makefile + +Pour le makefile les modifications suivantes ont été faites : + + 1. Utiliser la fonction `$(shell cmd)` disponible depuis au moins 1988[^2] + plutôt que l'opérateur presque équivalent `!= cmd` introduit en 2011[^4]. + 2. Utiliser la fonction `patsubt` disponible depuis au moins 1988 à la place + des substitutions de référence `$(var:a=b)` introduites en 1989[^3]. + +Seule la première était nécessaire pour que le makefile fonctionne sous debian +bo mais la seconde ne coûte rien alors pourquoi pas. + +### Le script page + +A la tentative d'exécution de la page de demo `index.sh` nous avons obtenu +l'erreur suivante : + + bash: mktemp : not a command + +Et pour cause, `mktemp` n'existe dans les GNUcoreutils que depuis décembre +2007[^5]. Le [manuel d'OpenBSD](https://man.openbsd.org/mktemp.1) dit que la +commande est apparue dans OpenBSD 2.1 datant de 1997[^7] mais je n'en trouve pas +mention dans [les changelog](https://www.openbsd.org/plus21.html). Il est donc +possible qu'un `mktemp` portable ait existé à ou juste après la sortie de debian +bo mais il n'y était pas par défaut. + +La solution retenue pour résoudre notre souci est de fabriquer un dossier +temporaire "à la main" en se basant sur le `pid` du processus : + + tmpdir="/tmp/catium-$$" + mkdir -p "$tmpdir" + +J'ai connaissance des [limites à la création de dossiers +temporaires](https://dotat.at/@/2024-10-22-tmp.html) comme ceci et à fortiori +dans le dossier `/tmp` mais honnêtement ici on s'en fiche un peu. Un compromis +pourrait être d'utiliser le dossier `~/.tmp` s'il existe mais flemme et ce ne +changera rien pour notre objectif de portabilité. + +Les prochaines erreurs arrivaient groupées, j'ai nommé les : + + bash: syntax error near unexpected token `cat' + +Ces erreurs étaient déclenchées par une syntaxe particulière de déclaration de +fonction dont en voici un exemple : + + save() cat >> "$tmpdir/$1" + +Il se trouve que cette syntaxe n'est pas POSIX[^8][^9]. Les fonctions shell +doivent être suivies d'une `coumpound command` qui doit commencer et finir par +un mot réservé (`for` par ex) ou un opérateur de contrôle (`{` par ex) et finir +par le mot réservé ou l'opérateur de contrôle correspondant (`done` et `}`). +`cat` n'est ni l'un ni l'autre donc `bash` ne le parse pas. J'ai longtemps cru +que cette syntaxe était POSIX puisque `dash` le comprend et parce que j'avais mal +lu la [page du wiki de shellcheck sur le +sujet](https://www.shellcheck.net/wiki/SC1064). L'exemple donné à la fin avec la +boucle `for` m'avait fait pensé que c'était ok de ne pas mettre de `{}` en +toute circonstance mais ce n'est ici rai que parce que `for` et `done` sont des +mot réservés qui se correspondent. + +Une fois la confusion levée la correction a été très simple. Encadrer les +commandes des fonctions par des `{}` sans oublier de terminer la dernière +commande par `;` si la fonction est écrite sur une seule ligne[^10]. + +Je n'ai pas résisté à l'envie d'envoyer un mail à Marc à ce sujet ce qui a été +un grand succès puisque l'on a eu le droit à [un magnifique pavé +Chantresque](https://groupes.renater.fr/sympa/arc/unix/2025-04/msg00000.html) +salade tomates oignons : + + * Réponse à un mail perso sur une liste de diff publique + * Du bashism de bash + * Un cours d'histoire sur le shell + * Des takes militantes + * Des arguments soutenus par des bouts de code ésotériques mais convaincants + +Nouvel obstacle dans notre portage sous debian 1997, cet ensemble d'erreur : + + bash: page: line 3: title: command not found + bash: page: line 3: author: command not found + ... + +Autrement dit `bash` ne semble pas instancier les alias `title:`, `author:` etc. +En lisant la partie `ALIAS` du manuel de bash je suis tombé sur : + + ALIAS + + [...] + + Les alias ne sont pas développés quand l'interpréteur n'est pas + interactif sauf si l'option expand_aliases de l'interpréteur est + créée par la commande shopt (consultez la descrip‐ tion de shopt dans + COMMANDES INTERNES DE L'INTERPRÉTEUR ci-dessous). + + [...] + +Il se trouve que c'est exactement ce dont on nous avions besoin mais j'ai mal +compris `développés`. J'ai cru que le manuel parlait de développer les +éventuelles variables qui se trouvait dans la déclaration de l'alias et non pas +de créer l'alias tout court. J'ai donc cherché une autre explication sans +succès. C'est Guillaume qui est indépendamment tombé sur cette info, a +correctement compris le texte et a demandé à Lou de tester la modif avec succès. +On considère souvent que le plus difficile est de trouver les informations dans +les mégas pages de manuel de la mort mais une fois l'information trouvée faut-il +encore la comprendre ! Idem avec la page de shellcheck au sujet des compounds +commands. C'est donc ça la puissance d'un directeur de thèse ? + +Il y aurait des moyens automatiques de tester si le shell utilisé est `bash` +puis d'appliquer la configuration mais, à ma connaissance, pas de manière +simple, fiable et cohérente de debian 1.3 jusqu'à debian 12. La solution retenue +a donc été d'introduire la ligne de configuration spécifique à bash dans la +section prévue à cet effet dans `page` : + + ## + # 3. Config si vous utilisez bash + ## + + # Si votre sh est bash alors décommenter la ligne suivante + # Sous linux vous pouvez vérifier en faisant + # readlink $(whereis sh) + + # shopt -s expand_aliases + +Et j'ai le plaisir de vous annoncer qu'avec ces modifications catium fonctionne +sous debian 1.3, en 1997, sans installer de paquets. + +### Des bugs dans le layout + +Premier bug, la présence de cette syntaxe censée mettre fin à la génération en +produisant un message d'erreur en l'absence d'un titre : + + <title>${title?La page dont le chemin s'affiche au dessus nécessite un titre}</title> + +La syntaxe `${param?mot}` n'est pas correcte. Ce doit être `${param:?mot}`. + +Autre bug, sur la même ligne, l'apostrophe empêche `zsh` et `bash` de parser +correctement le fichier. Il s'attend à voir une apostrophe fermante. Cela fait +plutôt sens et il est vrai que j'ai été surpris la première fois en constatant +que `dash` comprenant ça correctement. J'ai cru sur le moment que la partie +droite du `:?` était spécifiée comme étant spéciale. Il semblerait que non +et que `dash` est simplement très permissif. A vérifier. La forme correcte pour +tous les shells testés est donc : + + <title>${title:?"La page dont le chemin s'affiche au dessus nécessite un titre"}</title> + +Dans la même veine la ligne d'après posait problème et a été corrigée en double +quotant toute la valeur par défaut : + + ${STYLE:+"<link rel=stylesheet href=$STYLE />"} + +### Le traducteur markdown + +Catium a ceci de particulier qu'il ne présuppose pas en quoi vous voulez écrire +vos page. C'est pourquoi à la première exécution il vous force à ouvrir le +script `page` et à écrire/décommenter la fonction qui appelera le traducteur. +En pratique le langage de markup le plus utilisé avec catium est markdown et +le traducteur associé [`lowdown`](https://kristaps.bsd.lv/lowdown/)[^11]. + +Du fait de ce fonctionnement catium peut s'adapter à tous les usages. En 1997, +si l'on avait utilisé catium pour écrire de l'HTML on aurait probablement écrit +de l'HTML à la main. Le traducteur aurait alors été la fonction identitié : + + save() { cat >> "$tmpdir/$1"; } + +Cela dit, si l'on voulait se poser la question d'utiliser, en 2025 et donc avec +la connaissance de markdown, une debian 1.3, il serait sympa d'avoir un +traducteur. J'ai donc testé mon traducteur +[`katdown`](http://git.bebou.netlib.re/katdown/log.html) écrit en `awk` POSIX. +**Attention**, je précise que ce traducteur implémente une toute petite partie de +markdown et même pas correctement. Il est ultra méga pété. Mais, mais, pour des +documents très simples et dans des contextes où c'est pas forcément la mort +d'avoir parfois un doc un peu cassé, il faisait le taf en 1997, interprété par +`mawk`. C'est chouette. + +Une autre alternative serait [`markdown.awk` de Paul +Hänsch](https://git.plutz.net/?p=cgilite;a=blob;f=markdown.awk;h=bef97d1b7955191cb6b63af748c761d5288dea3a;hb=HEAD) +mais il fait 999 lignes et semble ne pas fonctionner avec le `mawk` pré installé +sur debian 1.3. + +## Discussion + +### Sur le nom de la pratique + +Ce que l'on fait ici est de porter du logiciel d'aujourd'hui pour qu'il +fonctionne sur du vieux matériel. C'est, je crois, une pratique assez rare. Le +fait que l'on porte en arrière dans le temps m'a donné envie d'appeler ça du +rétro-portage. Pourtant quand j'ai [initiallement porté catium vers OpenBSD et +MacOS](/portabilite/) je ne me suis pas demandé si je faisais quelque chose de +particulier alors même que le mac de Timothée tourne sur un vieux MacOS. Je +suppose que c'est la quantité de temps conséquente qui sépare 1997 de 2025 qui +me donne envie de lui donner un nom particulier. Sinon on peut simplement +appeler ça du portage/porting et la pratique plus large de l'arhéologie +numérique. + +### Sur le coût + +Qu'est-ce que cela a coûté de porter ? + +Le portage nous a pris ~2h30. Il a initiallement mobilisé uniquement Guillaume +et Lou puis, vers la fin, moi en renfort. On peut donc dire que le coût a été +2h de personnes fortes en shell et 30m du mainteneur du projet. Ce n'est pas +rien. + +Guillaume m'a confié s'attendre à beaucoup plus. Personnellement c'était à peu +près ce à quoi je m'attendais. On peut adopter plusieurs perspectives qui ne +s'excluent pas : + + 1. Se dire qu'il est "normal" que le portage ait été facile puisqu'après tout + le logciel est très simple. + 2. Se dire que mine de rien ces affaires de compatibilité entre les différents + shells c'est bien relou et caractéristique de ce pourquoi beaucoup de + personnes ne comptent pas sur cet environnement technique pour fabriquer + leurs outils. + 3. Se dire que c'est assez exceptionnel qu'un logiciel écrit en 2023/2024 soit + portable en 1997 en moins de deux heures. + 4. Sûrement d'autres + +Quand on analyse plus en détail on se rend compte que l'histoire des alias et +les bugs dans le layout sont avant tous des corrections pour porter vers `bash`, +également nécessaires en 2025. Si c'est une bonne idée de l'avoir fait puisque +de nombreuses personnes utilisent ce shell nous avons eu ici à le faire +uniquement parce que bash est le seul shell installé par défaut sur debian 1.3. +Cela veut dire que si l'on avait initiallement écrit catium pour fonctioner avec +`bash` les seules modifications à faire auraient été la substitution de la +syntaxe `!=` par la fonction `$(shell)` dans le makefile et le retrait de la +dépendance à `mktemp`. + +### Sur l'objectif + +Derrière les recherches de Phenix et les intuitions de Katzele se cache un +problème important. Nous aimerions pouvoir objectiver ce qui fait qu'un logiciel +est fiable et réparable dans le temps mais il est impossible de prédire le +futur. L'un comme l'autre nous faisons l'hypothèse que le fait qu'un logiciel +fonctionnait il y a 20 ans et fonctionne encore sans changement majeur est une +bonne raison de penser qu'il a une chance de fonctionner encore dans 20 ans. + +Cela dit il ne faudrait pas se laisser aller à penser que cette relative +fiabilité ne serait *que technique* et le *seul et meilleur indicateur* de ce +qui fonctionnera dans 20 ans. + +Par exemple si le shell et les commandes traditionnelles d'Unix utilisées dans +catium changent suffisament peu pour pouvoir être utilisées de la même manière +en 1997 et en 2025, il serait faux de dire que ce sont exactement les mêmes +logiciels qui fonctionnent sous le capot. Des efforts humains non +négligeables[^12] ont été consentis durant ces 28 ans pour maintenir ces outils +en état de marche, s'adapter aux ouveau matériels, corriger des bugs etc. Il ne +faut pas confondre fiabilité des "API" et fiabilité du code sous-jacent. + +Par ailleurs la durabilité d'une techno peut aussi se faire malgré des mises à +jour fréquentes. Il est raisonnable d'estimer qu'il est durable de faire du +javascript, malgré le fait que ça n'existait pas en 1997, malgré le fait que ce +soit techiquement plus compliqué que du C89, malgré le fait que de nouvelles +fonctionnalités sortent "fréquemment", parce que des entreprises extrêmement +riches et puissantes dépendent de cette technologie. C'est, dans le fond, un +pari assez similaire à celui que l'on fait en visant du shell et des utilitaires +unix standards, mais à plus haut niveau et se reposant davantage sur la +perpétuation d'entreprises "too big to fail". Pourquoi pas ? Après tout le shell +n'a pas toujours existé non plus et pourtant il aurait été bon de parier sur sa +durabilité à sa création. + +Finalement, comme Guillaume et Matthieu me l'avaient fait remarquer, il serait +dommage de ne se poser *que* la question de la fiabilité dans le temps et non +pas de la *réparabilité* et de l'*appropriabilité*. On pourrait imaginer créer +un outil tellement sur-ingénieuré qu'il soit capable de prévoir tous les cas +possibles, tous les imprévus, toutes les innovations technologiques. Cet outil +imaginaire serait impossiblement complexe à écrire, à maintenir, à modifier, à +adapter. Peut-être qu'il serait capable de fonctionner dans 100 ans mais +personne ne serait capable de l'adapter aux inévitables changements de nos +besoins durant ce centenaire. À moins qu'il remplisse le plus essentiel des +besoins il deviendrait rapidement obsolète. Il faut donc s'atteler à maximiser +la fiabilité *et* la réparabilité. Que l'outil ne nécessite pas d'être souvent +réparé a fur et à mesure que son environnement technique change mais que, +lorsque c'est inévitablement le cas ou lorsque le besoin change, il puisse être +raisonnablement facilement modifié en fonction des ressources dont on dispose. +Comme exemple on peut citer le développement de l'[indice de +durabilité](https://www.ecologie.gouv.fr/politiques-publiques/indice-durabilite) +suite aux limites de l'indice de réparabilité qui pouvait donner un 10/10 à un +téléphone très facile à réparer mais tombant en panne tous les deux jours. + +[^1]: Dans un contexte numérique donc pas forcément si anciennes que ça +[^2]: https://git.savannah.gnu.org/cgit/make.git/tree/ChangeLog.1#n4241 +[^3]: https://git.savannah.gnu.org/cgit/make.git/tree/ChangeLog.1#n3362 +[^4]: https://git.savannah.gnu.org/cgit/make.git/tree/ChangeLog.3#n1475 +[^5]: https://git.savannah.gnu.org/cgit/coreutils.git/tree/NEWS#n4025 +[^6]: https://man.openbsd.org/mktemp.1 +[^7]: https://www.openbsd.org/21.html +[^8]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_05 +[^9]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_04 +[^10]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_04_01 +[^11]: parce que c'est celui qui était utilisé pour le site de Katzele pour son + bon compromis "stabilité/taille/fonctionnalités". +[^12]: bien que possiblement asez faibles en comparaison à d'autre + environnements techniques