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.
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.
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 !
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 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 ;-)
À 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.
L'auteur devrait regarder du côté de Sather https://fr.wikipedia.org/wiki/Sather. Il y avait dans ce langage tout ce qui était amusant avec des API chouettes. Héritage de structure et inclusion de code, interface… Une gestion contravariante (donc sure) des paramètres et surtout des iterators (en pratique comme les coroutines) avec la notion de yield et de paramètres once (évalué juste la 1er fois et non les suivantes). Je n'ai jamais revu un autre langage avec des itérateurs aussi esthétiques et pratiques.
Autre chose amusante en Sather, on pouvait ajouter un noeud dans l'arbre des classes après coup. Ainsi une classe système pouvait dériver d'une classe que l'utilisateur définie et que le concepteur n'avait pas pensé. Rare sont les langages à le permettre or toutes les arbres de classe sont imparfaits et nécessitent un jour de définir une classe virtuelle maître à différent endroit pour son utilisation spécifique.
On pouvait installer Debian sur certaine machine SGI, mais il y avait des bogues dans X11 de mémoire. Bref, c'était pas vraiment que IRIX en pratique (et puis les machines étaient globalement des vaux).
Bonne initiative, mais attention à ne pas tomber dans le trou Microsoft. Sous UNIX, les exécutables n'ont pas d'extension et ne doivent pas en avoir. Un bon exécutable doit pouvoir être reprogrammer dans un autre langage. Et puis, on s'en fout qu'il soit programmé en Python, C, Rust… lors de son utilisation.
Bref, le renomme lidecli sans l'extension .py finale très moche.
Je veux dire tu ne peux pas avoir ton serveur d'envoi pour des listes indépendamment de celui qui gère le DNS et le serveur de courriel, en utiliser un à toi en gros ;-)
Évidement, on peut mettre plusieurs serveurs dans le champs SPF et avoir une infrastructure en cluster, géré par la même entité (de préférence ou il faut bien s'entendre pour tous les champs et certificats).
Personnellement, on j'aimais bien l'aventure des processeurs FORTH de Charles H. Moore https://en.wikipedia.org/wiki/Charles_H._Moore. Il essayait une autre voie, je trouvais cela amusant.
[^] # Re: History
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Perl 5.42 est sorti. Évalué à 3 (+1/-0).
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.
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.
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.
[^] # Re: Les derniers mètres sont les plus durs
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Typst, un système de composition de document qui grandit. Évalué à 3 (+1/-0).
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 ;-)
# 30 ans du CPAN
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Perl 5.42 est sorti. Évalué à 10 (+8/-0).
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.
[^] # Re: quid novis?
Posté par Sytoka Modon (site web personnel) . En réponse au journal Auxilium - Simplifiez le Traitement des Arguments de vos Scripts Shell. Évalué à 2 (+0/-0).
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…
[^] # Re: Reproductibilité et résilience
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Elpe, un compromis entre NixOS et Ubuntu. Évalué à 2 (+0/-0).
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 ;-)
[^] # Re: Reproductibilité et résilience
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Elpe, un compromis entre NixOS et Ubuntu. Évalué à 3 (+1/-0).
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…
# Reproductibilité et résilience
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Elpe, un compromis entre NixOS et Ubuntu. Évalué à 4 (+2/-0).
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…
[^] # Re: Version "tunée" commerciale Ondsel terminée
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche FreeCAD 1.0. Évalué à 7.
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…
[^] # Re: TCL/TK, un vieux langage qui demande à être utilisé au quotidien
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de Tcl/Tk 9.0. Évalué à 8.
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.
[^] # Re: Paradoxe libre
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de Tcl/Tk 9.0. Évalué à 10.
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).
[^] # Re: infecte notation ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Y a le Frido 2024 qu'est là. Évalué à 2.
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…
[^] # Re: Non, HTTP/3 n'est pas vraiment sur UDP
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche 24 ans de libcurl. Évalué à 3.
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.
[^] # Re: Obscur, mais [:pertinent]
Posté par Sytoka Modon (site web personnel) . En réponse au sondage Quelle est ma suite bureautique libre ? . Évalué à 2.
Il y a eu un commit il y a deux semaines…
https://gitlab.gnome.org/World/AbiWord
[^] # Re: À part l'ISA ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Linus Torvalds: comment éviter que RISC-V ne reproduise les erreurs du passé?. Évalué à 3.
Disons que Debian fait quand même partie des premières distrib ;-)
# Format Typst
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Une histoire de formats : il n’y a pas que la taille qui compte. Évalué à 4.
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
# Metafont
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Comment écrit-on les systèmes d’écriture aujourd’hui ?. Évalué à 8.
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
[^] # Re: Objet
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Perl 5.38.0 est sorti. Évalué à 4.
À 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.
# Sather
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche À la découverte du langage V. Évalué à 3. Dernière modification le 05 septembre 2023 à 16:04.
L'auteur devrait regarder du côté de Sather https://fr.wikipedia.org/wiki/Sather. Il y avait dans ce langage tout ce qui était amusant avec des API chouettes. Héritage de structure et inclusion de code, interface… Une gestion contravariante (donc sure) des paramètres et surtout des iterators (en pratique comme les coroutines) avec la notion de yield et de paramètres once (évalué juste la 1er fois et non les suivantes). Je n'ai jamais revu un autre langage avec des itérateurs aussi esthétiques et pratiques.
Autre chose amusante en Sather, on pouvait ajouter un noeud dans l'arbre des classes après coup. Ainsi une classe système pouvait dériver d'une classe que l'utilisateur définie et que le concepteur n'avait pas pensé. Rare sont les langages à le permettre or toutes les arbres de classe sont imparfaits et nécessitent un jour de définir une classe virtuelle maître à différent endroit pour son utilisation spécifique.
[^] # Re: Histoire de crâner
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Debian 30 ans déjà.... Évalué à 2.
On pouvait installer Debian sur certaine machine SGI, mais il y avait des bogues dans X11 de mémoire. Bref, c'était pas vraiment que IRIX en pratique (et puis les machines étaient globalement des vaux).
[^] # Re: Hou, sympa !
Posté par Sytoka Modon (site web personnel) . En réponse au journal Editer en parallèle les paramètres BIOS de plusieurs machines grâce à tmux. Évalué à 3. Dernière modification le 04 août 2023 à 11:41.
J'utilise tssh qui reprend le fichier de config de clusterssh, mais utilise tmux.
Le source https://gricad-gitlab.univ-grenoble-alpes.fr/legi/soft/trokata/tssh
Le manuel https://legi.gricad-pages.univ-grenoble-alpes.fr/soft/trokata/tssh/
# Pas d'extension
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Lidecli : Un outil en ligne de commande pour interagir avec les environnements de bureau. Évalué à 10.
Bonne initiative, mais attention à ne pas tomber dans le trou Microsoft. Sous UNIX, les exécutables n'ont pas d'extension et ne doivent pas en avoir. Un bon exécutable doit pouvoir être reprogrammer dans un autre langage. Et puis, on s'en fout qu'il soit programmé en Python, C, Rust… lors de son utilisation.
Bref, le renomme
lideclisans l'extension.pyfinale très moche.[^] # Re: retour d'expérience
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Debian 12 : le début d'une nouvelle ère. Évalué à 3.
De mémoire, ce n'était pas zoom le bug mais wayland qui ne le permet pas.
[^] # Re: Nice
Posté par Sytoka Modon (site web personnel) . En réponse au journal galae, le service email qui vous veut du bien. Évalué à 2.
Je veux dire tu ne peux pas avoir ton serveur d'envoi pour des listes indépendamment de celui qui gère le DNS et le serveur de courriel, en utiliser un à toi en gros ;-)
Évidement, on peut mettre plusieurs serveurs dans le champs SPF et avoir une infrastructure en cluster, géré par la même entité (de préférence ou il faut bien s'entendre pour tous les champs et certificats).
[^] # Re: Nice
Posté par Sytoka Modon (site web personnel) . En réponse au journal galae, le service email qui vous veut du bien. Évalué à 5.
Tu ne peux pas dans une infra moderne car tes courriels sont signés par DKIM et ton serveur doit être dans la base SPF de ton domaine (je simplifie).
Si tu ne fait pas cela, tu ne peux pas dialoguer avec gmail par exemple.
# F-CPU
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche AltairX : le processeur du futur ?. Évalué à 8.
Cela me rappelle l'aventure du F-CPU qui me semblait plus communautaire https://linuxfr.org/news/le-retour-de-f-cpu-le-processeur-libre
Personnellement, on j'aimais bien l'aventure des processeurs FORTH de Charles H. Moore https://en.wikipedia.org/wiki/Charles_H._Moore. Il essayait une autre voie, je trouvais cela amusant.