Sytoka Modon a écrit 4561 commentaires

Le problème comme tu le dis, ce n'est pas tellement la mise à jour, mais la quantité. Quelques serveurs, 100 serveurs, 1000 serveurs…

Dans toutes les mises à jour, que ce soit installations neuves ou mises à jour, on a par exemples les soucis suivants : changement dans les fichiers de config à faire, changement dans le schéma de la base de donnée qui n'est plus parfaitement compatible avec l'ancienne, changement dans l'interface du service, changement dans les fonctionnalités…

Bref, la quantité prends du temps et ce n'est pas le full-upgrade le plus compliqué de l'affaire.

Ensuite, il y a les projets LTS et ELTS (qui sont financés)

Les projets LTS et ELTS ne sont pas financés sur le saint-esprit. Il faut chaque année contribuer et motiver son entité de travail à participer au programme si Debian est utilisé dans l'entité.

L'argent ne vient pas du ciel. Donc hop, un tour chez freexian et une demande de devis. Je rappelle que freexian fonctionne aussi avec des bons de commande et Chorus donc si vous êtes dans la fonction publique, c'est une possibilité de financer du libre.

Je n'ai plus en tête des bouts de code ou je me suis fait piéger. Mais des bouts de code avec variables locales à la boucle, c'est hyper classique. Exemple :

INIT_EACH_SWITCH:
for my $sw (@SWITCH_LIST) {
  my ($session, $error) = Net::SNMP->session($sw);
  print "$error\n" if $error;
  ...

Les variables $session et $error sont locales à la boucle et ne sont pas définies avant. Il n'y a aucun risque que leurs valeurs proviennent du passage précédent.

Je me souvient que dans certains cas, il met arrivé d'initialiser la valeur d'une variable, disons $toto dans un test if () {}. Si le test n'est pas bon, alors on peut alors avoir cette variable $toto avec la valeur de la boucle précédente, alors qu'avec une déclaration dans la boucle, $toto vaut systématiquement 0.

En Python, j'ai aussi eu ce genre d'erreur. En début de boucle, il faut systématiquement écrire toto=0. En cas d'oubli, le programme fonctionne cependant et parfois sors des valeurs aberrantes. Il n'est pas toujours évident de détecter cet oubli. Je trouve donc beaucoup plus parlant le my $toto; de Perl d'autant plus que s'il n'est pas mis, Perl gueule et refuse d’exécuter le script (avec use strict;).

Je suis loin d'être parfait et je code (malheureusement) avec régulièrement des erreurs… Si le langage m'évite des erreurs sur les boucles, tant mieux !

Il y a des choses particulièrement bien en Perl qu'il n'y a pas d'aussi pratique en Python. Et inversement bien sur !

Déclaration d'une variable dans une boucle / bloc. La variable est ainsi initialisée à chaque pas. Impossible de récupérer la valeur de l'itération précédente en programmant ainsi. Cela évite bien des erreurs.

my $var

Déclaration d'un label pour chaque boucle.

next LABEL
last LABEL # dans une boucle

À mettre en début de traitement pour virer les cas particulier et indenter le moins possible le code.

next INNER_LOOP if $var !~ m/^yes$/i;

Personnellement, la gestion des boucles est un point important du fait qu'on les utilise souvent beaucoup en programmation déclarative. Les labels en Perl permettent de gérer clairement les boucles imbriquées.

Après, il est toujours possible de faire autrement, mais ce n'est pas toujours aussi compréhensible.

Non, je ne pense pas que cela provienne de son expertise. À mon humble avis, cela provient des textes écrit ou là un peu partout qui disent que Python est super et tout et tout. Il répète cela comme un automate.

Pour moi la preuve est de lui avoir demandé d'expliciter clairement les choses et qu'il s'est retrouvé sec à me dire que finalement, c'était bien pareil !

Perl a aujourd'hui le mot clef class. Le langage évolue. La période Perl6 / Raku est passée.

Exemple de ce que sait faire Perl, on peut déclarer des variables locales au bloc et non à la routine. Cela peut donner du code bien plus sur dans le cas de boucle par exemple (les variables peuvent alors être locale à la boucle).

Bref, cela reste un langage très intéressant, même en 2025. J'utilise Python si nécessaire et Perl si besoin.

Il y a un mois, je me suis amusé avec ChatGPT à lui dire de me faire un script en Perl. Il a voulu à plusieurs reprises me le (re)faire en Python a mesure que le projet avançait en me disant que Python, c'était bien mieux. J'ai finit par lui demander ce qu'il y avait de MIEUX dans le moteur Python. Sa réponse a été qu'au final, les deux langages même s'ils n'ont pas la même syntaxe, c'est globalement bonnet blanc et blanc bonnet ! Fin de ses tentatives voulant me forcer sur un langage de script ;-)

Rien n'empêche de faire un HTML, CSS et JS dans une archive zip et de faire tourner cela dans un navigateur.

À vrai dire, c'est plus ou moins ce que fait le format odt.

publivité -> publicité

Il y a aussi un passage en gras qui a foiré.

C'est vrai que la longueur de la mise en place de Raku n'a pas aidé. Mais aujourd'hui, Perl a retrouvé sa dynamique propre et le mot clef class comme les autres langage.

Deux choses que je préfère en Perl par exemple à Python.

1. le $ devant les variables. Je trouve que cela améliore la lisibilité des variables et en plus avec 'my', on déclare ses variables (surtout avec use strict). C'est bien plus clean.

2. on peut déclarer des variables locales pour chaque bloc. Ainsi on a des variables locales dans les boucles for / foreach / while. Cela permet de faire du code beaucoup plus robuste sans risque de récupérer la valeur du passage de la boucle précédente.

Donc au final, je code en Perl si possible plutôt qu'en Python.

J'ai passé pas mal de temps pour passer des pages Wiki à des pages web avec deux contraintes, je voulais des pages web et un PDF. Web pour les utilisateurs, PDF afin d'avoir un document autonome que je puisse avoir sur mon PC ou donner facilement.

J'ai utilisé mkdocs pendant longtemps, mais impossible d'avoir une table des matière correcte dans un PDF (et puis chaque moteur a son langage Markdown). Au final, je suis parti sur du RST avec Sphinx qui mouline pas si mal HTML et PDF.

Clair, on est limité avec RST, bien plus qu'avec LaTeX. Cependant, on a une version Web de bonne qualité.

Bilan : un outil pour faire tout ? Est-ce faisable ? Sphinx et LaTeX utilise des tables globales pour les liens.

À mon sens, la bonne idée de TeX (LaTeX) est d'avoir en gros le caractère \ pour indiquer une commande quasi partout. Ainsi ce qui n'est pas texte est facilement identifiable. L'autre bonne idée est d'avoir le mode math dans lequel on bascule facilement. Mais mauvaise idée dans le mode tabular qui ne fonctionne pas bien pareil (par exemple les accents historiques).

Les bidouilles de __type__ **wiki**, cela va un temps, mais c'est vite le souk dès que ce sont des documents compliqués. D'ailleurs à ce niveau là, je préfère les doubles symboles __, **, ~~, `` et // aux autres solutions…

Ah, et autres contraintes que je rencontre souvent, avoir du français et de l'anglais. Le plus simple est souvent d'avoir les deux langues dans le même fichier (facilite la maintenance) mais il faut ensuite mouliner et par exemple garder le paragraphe de la langue si celui-ci existe et sinon prendre la langue qui reste pour ce paragraphe. Spip gère très bien cela (pour le Web) avec <multi>[fr]français [en]anglais</multi>. C'est hyper pratique et je n'ai pas vraiment retrouvé aussi souple ailleurs.

Tout cela pour dire que créer une interface pour gérer pas mal de cas d'usage n'est pas facile ;-)

Et le 16 août, soit il y a deux jours, c'était l'anniversaire du CPAN : 30 ans déjà. Le CPAN avait repris l'idée du CTAN (TeX) en améliorant encore le concept. Le CPAN est une super idée plutôt que d'aller disperser le code sur 50 forges… plus ou moins libre. Au moins, le code est sur 50 CPAN !

Bref, Perl c'est du bon, mangez-en.

Si tu regardes la commande module, c'est une fonction bash (pas le choix si on veut modifier le shell courant) qui fait un eval du résultat de la commande modulecmd. Cette dernière est programmée historiquement en TCL.

Bref, tu peux tes traitements par exemple en Perl et faire un eval du résultat dans ta fonction Bash. J'ai dis Perl car très stable et c'est quasiment partout…

Je suis entièrement d'accord et d'ailleurs, le projet Debian est à fond dans le Reproductible Build. C'est ce que j'ai dis. Reproductible Build est à mettre au même niveau que la signature de code, on est SUR que le code qui tourne est compilé à partir de ces codes sources là.

La reproductibilité bit à bit à l’exécution est intéressante dans certains cas, mais pas nécessaire dans tous les cas. Et c'est souvent dans les cas de code de calcul, qui sont complexes et font intervenir des quantités d'opérations, que s'accrocher sur cette notion de bit à bit pour les résultats a peu de sens. Mieux vaut avoir un code robuste avec des critères objectifs. Ainsi les algorithmes peuvent être refait dans d'autres langages par d'autres équipes sur d'autres CPU, l'important est le résultat scientifique, à epsilon près ;-)

Si c'est un code élément finis, tu as un ensemble de cas test. Une simple dérive, c'est par exemple les mêmes résultats en terme de contrainte et de déformation à 10-7 par exemple.

Ce que je veux dire, c'est qu'il y a de nombreux cas où une petite dérive du calcul n'est pas du tout gênante. Bien sur, si ton code n'a aucun cas test, alors c'est compliqué de qualifier le code…

Pour avoir une forme de reproductibilité assez simple à mettre en œuvre là ou il y en a besoin, il y a les container, par exemple AppTainer https://apptainer.org/.

Il n'y a pas moyen de garantir la reproductibilité dans la plupart des cas ! Il suffit de changer de CPU (ou de GPU) et plus rien n'est garanti !

Ce qui est important, c'est soit le résultat, soit une faible dérive avec le résultat précédent. Dans de nombreux cas, une faible dérive suffit. En plus, cela a un avantage de plus travailler sur la résilience du code aux modifications que sur le dernier bit. En science, un résultat doit être reproductible par d'autres équipes pour valider un résultat, mais cela ne signifie nullement relancer le même code dans les mêmes conditions. 1 + 1 = 3 est faux, mais reproductible par un bogue de codage. Le valider n'est pas de la science…

La stabilité des API, la correction des bogues est souvent un sujet plus important que la reproductibilité bit à bit…

Cela dis, le projet « Reproductible Build » qui permet de garantir que le code compilé est bien issu de ces sources là est carrément important. C'est le même type de garantie qu'un hash certifiant qu'un téléchargement s'est passé sans modification lors du transfert. C'est une signature numérique.

Bref, la reproductibilité, c'est bien à bon escient. Parfois, cela se transforme un peu trop en religion…

Le coeur de FreeCAD, c'est OpenCASCADE de mémoire et c'était la base qu'avait réalisé Matra Datavision pour sa nouvelle version de CAO Euclid qui devait révolutionner le domaine (à l'époque Euclid était en compétition avec Catia, c'était la concurrence entre PSA et Renault…). Bref, tout cela date d'avant 2000.

Je rappelle juste ces faits pour rappeler qu'il y a eu beaucoup d'heure d'ingénieur à la base payé par des entreprises ayant pignon sur rue. La chute d'Euclid n'a pas été sans créer quelques remous…

Je me souviens d'un programme graphique en tcl/tk, c'était vraiment compliqué de le maintenir. Je l'avais refait en mieux avec Perl/Tk et c'était bien plus simple à comprendre et à structurer en block.

D'ailleurs, la version devrait toujours fonctionner car le langage Perl est hyper stable.

Si MOTIF avait été libre, les développeurs de Gimp n'auraient pas programmé GTK. Il faut savoir que MOTIF était globalement vachement bien foutu pour l'époque et on pouvait via les ressources changer l'aspect de l'application.

Comme quoi, le libre a effectivement du bon (d'ailleurs, pendant longtemps, Qt n'était pas complètement libre non plus).

Après, cela reste la grande bataille sur les limites avec les infiniment petits ou pas. Cauchy est passé par là et à mis les math d'accord avec un epsilon…

Les physiciens sont restés avec leurs mains ;-)

Et puis, il y a eu Robinson en 1964 qui a réussit à mettre les infiniment petits dans les math après plus de 100 ans de recherche. Au début des années 70, Nelson fait une version plus digeste.

Bref, avoir un au numérateur et un autre au dénominateur n'est pas complètement idiot au sens de l'analyse non standard (ou de la physique, avec les unités). Bref, si on veut veut pas de x, y…

C'est surtout que c'est impossible de modifier la configuration des routeurs aujourd'hui… Déjà IPv6 a du mal à être déployé. Les DSI ferment quasi tout sauf http/https ! Donc on se retrouve avec du https pour tout et n'importe quoi. Bilan, on fait du https sur udp pour pouvoir ensuite faire tout ce que l'on veut pour franchir les routeurs… Et comme les DSI ne seront pas contentes : boites noires et EDR partout.

Cela me semble irréversible, mais n'est pas vraiment très respectueux d'un internet sobre.

Il y a eu un commit il y a deux semaines…

https://gitlab.gnome.org/World/AbiWord

Disons que Debian fait quand même partie des premières distrib ;-)

Typst est un nouveau format / formateur de texte dans la logique de TeX. Il a pour objectif d'être complet et plus simple que le couple TeX/LaTeX.

https://github.com/typst/typst

Il ne faut pas oublier le système metafont assez génial en son temps et qui fonctionne encore très bien. Je pense que personne n'a encore fait de meilleur système pour le rendu scientifique.

Les fonts metafont permettaient de mettre des accents et des cédilles un peu partout et de manière propre. Le système a certainement des défauts dont le principal est de ne pas avoir été inventé par un grand constructeur ;-)

Allez, une référence Wikipédia pour changer de crémerie https://fr.wikipedia.org/wiki/Metafont

À mon avis, cela va plus loin. Avec Corinna, l'objet est codé en dur dans la machine donc ce ne sera pas une table de hashage (ou un tableau, ou un scalaire, ou une array inversé…).

Donc en principe, cela devrait être plus performant.