Sytoka Modon a écrit 4586 commentaires

Et puis Bash n'est pas du tout has been. Il est même très intéressant dans de nombreux cas. Il ne faut juste pas mélanger les usages. C'est clair que shellcheck fait un super boulot pour éviter certaines formes pas top.

Cependant, pour l'admin système, heureusement qu'il est là avec un écosystème bien stable.

Pour faire aussi du PowerShell sous Windows, un langage de script ne remplace pas un langage de shell dans tous les domaines, et PowerShell est plus un langage de script avec l'espace comme séparateur que de shell à mon sens.

Après il faut passer au Perl ou, plus moderne, Python.

Phrase typique que te sors une IA.

Si tu la titilles un peu, pourquoi Python est plus moderne que Perl, en pratique, elle sèche assez vite. Voire il est facile de faire dire à l'IA qu'au final, non, tu as raison, il vaut mieux faire en Perl qu'en Python.

Juste pour dire que c'est amusant ce genre de chose que tout le monde répète, mais sans forcément de fondement réel.

De mémoire je faisais du Sphinx avec Material. Je me fiche de la reproductibilité bit à bit dans 99% des cas, en plus, quand je change de machine, je change de CPU donc le résultat n'est pas toujours le même (à la décimale près).

En science, on souhaite qu'un résultat soit reproductible … à epsilon près, dans la très grande majorité des cas.

Bon, quand je fait de la CI, je vais prendre par exemple une Debian stable -> trixie en ce moment. Mais à chaque fois, ma Debian stable à les dernières mises à jour de sécurité et tout n'est pas cassé.

Ben ça, c'est hyper dur de l'avoir dans l'écosystème Python. Soit tu as tout pareil au numéro exact, sans correction de sécurité, soit c'est au petit bonheur la chance (heureusement, cela se passe quand même souvent bien).

Alors oui, les tests aident. Mais quand même, c'est dans l'esprit que je trouve qu'il manque quelque chose.

Imagine si le W3C changeait les choses sans phases de transition hyper longue ?

C'est souvent la réponse donnée. Refaire une installation avec les mêmes versions… Mais franchement, ce n'est pas soutenable dans la durée. C'est un pis aller pour ne pas faire du rétrocompatible. Personnellement, je n'ai pas envie que ma CI se relance sur des versions de modules qui ont 5 ans ou 10 ans d'âge.

Heureusement que le noyau Linux et la libc sont rétro-compatible. À chaque fois que l'API est cassée, c'est très pénible pour tout le monde.

Certains écosystème ne veulent pas l'entendre.

je vois que tu prends plusieurs précautions à ce sujet (mentions sur l'IA, le titre plus adapté à LinkedIn, etc.)

C'est un habitué et un ancien de DLFP. On serait tous plus tolérant avec lui. Peu d'entre nous on fait autant que lui.

Je n'utilise aucun de ces outils… Dans mon boulot, c’est plutôt LabView qui est utilisé pour piloter les manips (pas toujours, mais souvent). Cependant, je n'ai jamais codé et lancé LabView à mon niveau.

Un critère qui me semble important est la Stabilité (Pérennité, Rétro-compatibilité…).

Du peu que j’ai vu, on n’a pas envie de refaire tous les ans !

Personnellement, j’ai des doutes que Scilab décolle réellement un jour et Python (et ses modules) cassent trop souvent ses API. J'en ai encore fait les frais sur de la CI avec Gitlab avant l'été.

Karl Williamson qui s'occupe d’Unicode dans Perl parle du caractère U+00DF qui serait lié au « ss » de l'Allemand (ß -LATIN SMALL LETTER SHARP S).

A priori, cela pose problème dans la gestion de la bibliothèque regex, car ce serait un cas très particulier.

https://github.com/Perl/perl5/commit/548fbca1a3f3ea8f7f55ec876cd47b2d9c6db3c1

Je ne suis pas spécialiste du tout. Mais en lisant les posts de Karl, j’ai eu l’impression que plusieurs choix fait dans Unicode semblent poser des soucis.

Bon, à vrai dire, ce nouveau caractère SURSOLIDUM ne se retrouverait que dans des articles mathématiques du XVI siècle.

N'importe qui te le dira sur ce site que SSH yapamieux

SSH, c'est super, mais ce n'est pas le top pour tout. Il ne faut pas exagérer.

Par exemple, pour une session graphique distante, x2go est mieux. SSH par exemple ne sait pas garder une session.

Autre exemple, ssh est assez dépendant d'une coupure réseau. Il faut se reconnecter.

Sur une liaison type console (terminal), alors le couple mosh + byobu est hyper pratique. Ton portable change de réseau, ta session mosh continue de fonctionner. Certes c'est de l'UDP et il faut ouvrir la plage sur ton routeur.

Donc oui, ssh est vraiment top, mais il ne répond pas parfaitement à tous les usages.

Le soucis est que x2go ne semble plus maintenu depuis des années. Pourtant, c'est vrai que c'était une super solution facile a utilisé (et malheureusement jamais intégré dans Xorg)…

Moi j'ai compris qu'il s'est aidé d'un IA pour faire le paquet, pas pour faire le logiciel…

Donc cela reste une contribution IA modeste et en plus, pour ce genre de chose, l'IA doit être aussi bonne que beaucoup de développeur Debian pour la mise en place des fichiers rules et autres.

Vote électronique et fiable sont antinomique ! Le vote électronique est utilisable pour des votes secondaires, par exemple en milieu professionnel. En plus, il pourrait y avoir des amendes sévères en cas de tricherie.

Dès que c'est citoyen, le pouvoir risque de tout corrompre ;-)

L'expérience des jurés citoyens montre que cela fonctionne bien. Par exemple, la convention citoyenne a eu un résultat inattendu sachant qu'au départ, beaucoup de citoyen tirés au sort était contre durcir les mesures.

Trop de vote comme en Suisse mène j'ai l'impression à une politique très à droite (c'est mon impression). Les personnes voient midi à leur porte. Dans les procès d'assise, il me semble que les personnes prennent leur intime conviction et tranche pour la collectivité.

Il faudrait plus de retour sur le tirage au sort, mais j'ai l'impression que c'est le système qui a le moins de biais. D'ailleurs, les états ne veulent pas le mettre en place et en France, il y a un net recul des jurés dans la justice depuis 30 ans.

J'ai été président de bureau de vote avec des machines. On ne contrôle rien de rien. À la fin, on branche une imprimante, on appuis sur un bouton (je simplifie un peu) et hop on a le résultat. On signe le PV et c'est finit.

Il est impossible de savoir si le programme fonctionne bien.

La seule chose que l'on contrôle est la comparaison entre le nombre de signature et ce que la machine dit (sachant qu'en tant que président, on initialise chaque vote via un dongle physique).

Avec le vote papier, chaque bureau est indépendant. Les électeurs participent, voient l'urne, dépouillent. Le président juste explique les consignes, surveille et conseille. Les électeurs chez moi ont tous adorés dépouiller et comprendre ce que le vote démocratique voulait dire.

Une fois dépouillé, tout part à la poubelle dans le bureau même, rien ne remonte à la mairie. Il est impossible de recompter. S'il y a tricherie, c'est bureau par bureau et les statistiques peuvent montrer s'il y a une grosse tricherie ponctuellement. Il n'y a pas un bureau qui change de tout au tout sans raison d'une élection à une autre et sans changement dans les autres.

Le point important est l'autonomie de chaque bureau. La triche ne peut être normalement que locale et réduite. Si elle se généralise, alors il y a forcément beaucoup de monde dans le secret.

Évidement on peut améliorer les choses.

Un point qui me semble important dès qu'on parle démocratie et élection, c'est le tirage au sort. La base de la justice en France, c'était les jurés tirés au sort. Je parle au passé, car il y en a de moins en moins, c'est de plus en plus des pros qui jugent.

Il est tout à fait possible de tirer au sort par exemple 800 personnes qui prendrait une partie des décisions. Le Sénat serait remplacés par 3 sessions annuelles de 4 mois de personnes tirées au sort qui voterait oui ou non les lois sans possibilités de les amender, cela fonctionnerait à mon sens bien mieux.

De plus en plus de service utilise LiveKit. Par exemple, il me semble que BBB a migré dessus. LaSuite de la DINUM (service VISIO) est aussi basé dessus. Ils ont préféré LiveKit à Jitsi par exemple, car on pilote mieux l'interface utilisateur (Jitsi est plus une application tout en un).

As-tu un comparatif LiveKit / Galène ?

Je viens de voir que les deux sont programmés en Go.

À noter pour le service public (et le privé travaillant pour le public), l'application web de l'ANSSI

https://messervices.cyber.gouv.fr/services/mon-service-securise.html

Cela pourrait sembler assez proche de Deming ?

NIS2 va être intégré dans Mercator.

Quelle différence entre les deux produits ? Faut-il mettre en place les deux ? A-ton des liens possible entre les deux pour éviter une certaine redondance ?

Concernant Peertube, une instance métropolitaine serait mieux ! Les petites communes autour n'ont pas les moyens d'avoir chacune une instance. Donc une instance par agglomération est souhaitable.

Les LLM te pondent du code avec un style un jour et un autre style le lendemain… Si ton code est un peu sérieux, en gros plus que les quelques 500 lignes, tu vas rapidement te retrouver avec plusieurs styles très propre, mais différent.

Si tu veux un truc propre et fonctionnel, tu te retrouve à reprendre des bouts régulièrement.

Quand je vois la taille de l'objet et que tout passe par USB, je me dis que cela va rapidement intégrer le coeur des CPU.

Cela me rappelle l'intégration d'AES dans les CPU il y a une quinzaine d'année (ajout d'instructions dédiées). Avant, chiffrer un poste ou faire un transfert avec SSH se sentait en terme de CPU / débit. De nos jours, le chiffrement AES est quasi transparent.

On peut stocker la fiche au format fodt. C'est alors un fichier texte (les images sont encodées en BASE64). Ce format est idéal pour une forge car Git sais alors faire un diff dessus.

Je confirme, on peut quasiment écrire le même script avec peu de variante en Perl. C'est assez proche en réalité.

J'ai aussi fait un truc du genre pour passer du markdown trac au rst, mais en Perl. Je le trouve souvent plus robuste et plus lisible comme langage dès qu'on dépasse quelques lignes.

Cela ne fonctionne pas, car la résolution n'est pas du tout équivalente entre les deux.

Je veux rester sur le même environnement que mes utilisateurs, c'est pour cela que j'ai arrêté les trucs spécifiques.

Lorsque j'ai un second clavier, je ferme le portable et hop, la bascule des fenêtres en gardant le même style (plein écran ou non) est automatique.

Mais parfois, je me branche sur un écran externe sans avoir un second clavier, l'ordinateur portable reste donc ouvert. Le besoin est alors d'envoyer toutes les fenêtres sur ce second écran.

Voila besoin simple et à mon sens assez courant ;-)

J'aimerais de mon côté basculer toutes les fenêtres de l'écran A vers l'écran B en gardant les fenêtres plein écran sur B si plein écran sur A, sachant que la résolution n'est pas la même.

Pas trouvé de solution simple à ce problème qui m'arrive régulièrement…

À noter que je suis sous GNOME X11.

En général, ce genre de choix lié au formatage est fait dès le début, c'est pour cela que je suis remonté à 1989.

tous les éditeurs de code de l'époque où le python a été crée étaient capable de le faire.

Hum, pas sur qu'en 1989, tous les éditeurs étaient capable de cela.

Sinon, pour le calcul numérique (non HPC), Python mélange aujourd'hui deux types d'objet qui ne fonctionnent pas pareil : les intrinsèques et les numpy. Cela oblige a du bricolage qui ne sera pas facile à corriger.

Julia pourrait prendre sa place dans le calcul, on verra. Je pensais qu'il aurait déjà pris plus de place en 2025. Alors ce sera peut-être un autre.