pulkomandy a écrit 2154 commentaires

Comme d'habitude, Brendan Gregg a déjà commencé le travail et vous propose dans sa page d'outils spéciaux, une implémentation de la commande echo en java (presque tout en bas de la page). Vous pourrez constater que le code est beaucoup plus court que la version de GNU écrite en C, ce qui démontre la supériorité de Java pour cette utilisation.

Tu es GPT-5 Thinking, en mode recherche approfondie.

On en est là? Des incantations magiques pour que l'ordinateur fasse semblant d'être plus compétent qu'il ne l'est vraiment?

Ayant lu d'autres messages de Tanouky par ailleurs, malheureusement, il est peut-ètre sérieux.

Pour à peu près le même prix on trouve toutes sortes de PC portables d'occasion avec des configurations similaires, mais avec un écran et une batterie.

Certes, il n'y a pas de LEDs RGB et de clavier mécanique. Et surtout il manque le port GPIO, qui est la partie la plus intéressante de ces machines.

On avait pas ce découpage artificiel en période de n semaines.

Il ne faut pas oublier aussi que la méthode SCRUM est juste un exemple de résultat d'une méthode agile. C'est fait par des gens qui ont expérimenté les méthodes agiles et sont arrivés à une organisation stable et qui leur convient.

L'idée des méthodes agiles, c'est surtout d'adapter les choses en fonction des besoins. Tu vois qu'il y a un truc qui ne sert à rien, tu l'enlèves. Tu vois que c'est la merde tous les mois parce qu'il manque un truc (genre tu fais pas de tests avant de livrer), tu l'ajoutes.

Si tu ne sais pas par où commencer pour mettre ton projet en place, SCRUM te donne un exemple de façon d'organiser les choses, qui peut servir de point de départ à faire évoluer ensuite.

Si tu n'aimes pas les sprints et que ce n'est pas pertinent dans ton cas, tu peux prendre une méthode qui ressemble plus à Kanban: il y a une liste de trucs à faire, tu pioches dedans quand tu es disponible pour démarrer une nouvelle tâche, il y a un suivi individuel de chaque tâche.

Dans mon cas on pratique un mélange des deux: il y a une planification par sprints parce que ça permet d'estimer la capacité de l'équipe (prévoir à peu près combien de tâches on va pouvoir compléter chaque mois et chaque trimestre), mais si il y a une tâche qui dure 2 mois de suite, ce n'est pas bloquant, il faut juste tenir compte du fait que une personne ne va faire que ça pendant 2 mois.

Et pour les sprints qui ne seraient pas tenables: dans SCRUM c'est l'équipe qui choisit combien de "points" (et donc de tâches à compléter) sont prévues dans chaque sprint. Si vos sprints ne sont pas tenables, il suffit de moins les remplir. Bien évidemment, ce n'est pas facile à expliquer au management, mais ça, ce n'est pas le problème de la méthode SCRUM (qui n'a peut-être pas été conçue pour fonctionner avec un management hostile à ce genre de choses).

J'ai parfois l'impression qu'on attend de ces systèmes des performances infaillibles littéralement surhumaines

C'est ce que j'attend de l'informatique en général, oui. Peut être que je suis obsolète dans ce monde où la âérité et le processus scientifique ne sont plus considérés comme important. Ce qui compte c'est la vibe, les apparences, le "bon sens". Dans lwinformatique il me restait un domaine où je n'avais pas trop ce problème. Il pouvait toujours y avoir une réponse définitive, même si elle n'est pas forcément facile à obtenir, et qu'on peut rater des éléments de la question.

Avec les LLM on a de l'informatique qui ne garantit pas ça. Peut-êre qu'en re-posant la même question une deuxième fois ça aurait marché. Peut-être qu'en demandant la même chose demain ça ne marchera plus. La réhonse est convaincante et bien rédigée, c'est peut-être pas grave qu'elle soit fausse. Je comprend que ça convienne bien à plein d'humains, qui fonctionnent déjà comme ça de toutes façons. Mais pas moi.

Et en plus, ça fait tout ça en émettant plein de CO2, en consommant 10 fois plus d'eau et d'électricité qu'un humain, et en ignorant les hroblématiques de droit d'auteur ou en tout cas en en faisant une interprétation assez flexible. Et c'est aussi plein de gens sous-payés qui trient et étiquettent manuellement des données pour l'entraînement des modèles. Mais ça, tout le monde s'en fiche. C'est moins d'effort pour l'humain qui tient le clavier, alors, …

J'ai oien mis des guillemets autour de "trouvé". On peut mettre "inféré" à la place si on veut mettre ds mots compliqués. Et ça ne répond toujours pas à ma question, comment un LLM peut te dire à quoi correspond l'erreur 27 sur une machine à laver si l'information n'existe pas par ailleurs et sans sortir une réponse complètement inventée et sans rapport avec la réalité?

Il n'y a justement pas de magie. Il y a des entrées (les données d'entraînement et le prompt) et des sorties.

Et note aussi que si j'obtiens une réponse sur l'erreur 27 sur un forum sans explication, ou quelqu'un me dit "c'est la pompe de vidange qui est bouchée", je vais sùrement aussi me demander quelle est sa source (qui pourrait être une doc du fabricant non publiée, sa propre expérience de réparateur, …). Et ça permet de "gagner un niveau" sur les compétences (du simple "erreur 27 = pompe bouchée" à "comment trouver le problème lié à un code d'erreur")

Les LLM sont très intéressants pour les cas où vérifier une information est beaucoup plus simple (et sans danger) que de trouver l'information.

Oui vu comme ça c'est logique. Et pour le coup, dans mon travail salarié d'architecte/dévelopeur, trouver des informations est généralement facile (on peut demander au client pour le fonctionnel; pour le technique on peut lire notre code, lire le code des projets libres qu'on utilise, la littérature est abondante. Mais par contre pour vérifier les choses, c'est autrement plus compliqué.

Dans le cas d'une démonstration mathématique, il peut y avoir des étapes pas du tout intuitives, mais une fois trouvées on peut les vérifier. Effectivement j'imagine qu'il peut y avoir d'autres choses dans ce cas!

Mon emploi salarié actuel ne consiste pas du tout à dépanneredes machines à laver qui ont une erreur 27, donc je ne vois pas trop le rapport. Cela peut m'arriver pour mes loisirs, en revanche.

Mais admettons. Par quel mécanisme un LLM peut donner une telle information (et avoir raison) si ce n'est pas en tirant l'information de ses données d'entraînement ou éventuellement en faisant la recherche sur internet à ta place? Quelles autre alternative y-a-t'il aux deux options: soit l'info existait quelque part, le LLM l'a trouvée pour toi mais tu aurais pu en faire autant avec un bon vieux moteur de recherche; soit l'information n'existait pas, le LLM a "inventé" une explication?

Dans ce deuxième cas, qu'est-ce qui permettrait de supposer que l'explication donnée a une chance d'avoir un quelconque rapport avec la réalité?
Est-ge qu'il a des pouvoir de divination extralucides? Est-ce qu'il a trouvé et désassemblé le firmware de la machine à laver? Est-ce qu'il a contacté à ta place le faoricant pour récupérer des infos? Est-ce qu'il a asoiré dans ses données des infos confidentielles du fabricant qui ne sont pas sur internet? Dans ce derniers cas, est-ce que le faoricant en question a donné son accord pour la publication d.ces données et pourquoi il les a mis dans un LLM et pas directement en ligne sur son site?

Pour la réparation d'appareils, typiquement, la notice officielle ne mentionne que des cas débiles, genre "la lumière ne fonctionne plus -> remplacer l'ampoule", "l'appareil ne s'allume pas -> vérifier qu'il est bien branché", "l'appareil est branché et ne s'allume pas -> contacter le service après-vente". C'est ça, l'information qu'on a toujours eu, de la m***. Pour obtenir les données techniques, il fallait contacter le fabriquant et espérer sa bonne volonté, ou bien payer pour accéder aux protocoles de réparation destinés aux professionnels. Bref, je ne crois pas du tout au monde idyllique d'avant les LLM où il était facile de trouver des informations de qualité sur n'importe quel sujet, je crois que c'est un monde fantasmé.

Soit ton LLM a "trouvé" la réponse quelque part dans ses données d'entraînement, et donc elle existait bien quelque part, très probablement sur internet ; soit il l'a inventée, et donc c'est une réponse bidon qui ne sera vraie que sur un coup de chance.

Donc je ne vois pas quel problème ça résout. Au lieu de passer du temps à chercher une réponse, tu vas avoir une réponse tout de suite, et puis ensuite tu vas passer autant de temps qu'avant à vérifier si cette réponse est vraie. Tu as peut-être l'impression de ne pas avoir galéré et d'avoir été mis tout de suite sur une piste.

Pour reprendre l'exemple de la recherche d'itinéraire, c'est équivalent à partir dans une direction à l'instinct sans regarder un plan, se rendre compte que c'était pas la bonne direction, et dire "oui, mais au moins j'ai bougé". La direction est plus important que la vitesse, et les LLM te donne de la vitesse.

Je parlais de rétractation parce que j'ai un autre problème: j'ai un client sur mon téléhhone, un sur mon pc pro et un sur mon pc perso par exemple. Toutes les requêtes arrivent sur tous les clients. Une fois que j'ai accepté la requête, je n'ai pas besoin que des fenêtres de demande persistent sur les 2 autres clients qui étaient en ligne à ce moment là. Donc ce serait bien que le serveur puisse invalider ces requêtes.

Et même avec un seul client, si la requête http fait un timeout avant d'avoir reçu une réponse, invalider la demande de confirmation serait raisonable aussi.

Plusieurs différents hrojets, j'ai par exemple travaillé sur des réseaux de talkie walkie avec des antennes relais qui sont déployées en fonction des endroits où il y a une bonne réception radio et pas en fonction de l'accessibilité routière; ça peut être également des projets déployés sur des sites industriels, où il y a plein de monde autour, mais qui ne sont pas des personnes à qui on veut donner accès à l'équipement en question (je rentre pas dans les détails, j'ai signé un NDA).

En fait, même si c'était une bête machine à laver, une fois que tu l'as vendue à un client, c'est difficile d'envoyer quelqu'un chez lui pour installer une mise à jour de firmware. Surtout si tu en as vendu plusieurs millions.

Dans mon cas,si on a pas trop foiré les choses, on peut faire des mises à jour à distance. Mais tout le code et la configuration permettant de se connecter à Internet et recevoir des mises à jour est assez critique.

Et de façon générale dans les systèmes embarqués, si tu fais un contrôleur de moteur (de voiture, d'avion, de train, de process industriel, peu importe) et qu'il fonctionne bien 99% du temps, si tu utilises la voiture (avion, train, etc) tous les jours, statistiquement, au bout de 3 mois (100 jours) tu as une panne. Si tu as vendu 100 voitures (avions, trains, bref t'as compris) tu en a une en panne par jour. Si tu en as vendu 100000 ou plus, je te laisse faire le calcul.

Et les LLM,actuellement, ils ne sont pas bons dans 99% des cas, loin de là.

Comme tous les raccourcisseurs et redirecteurs d'URL, celui-ci permet de logger qui accède à la page, et pourrait un jour se mettre à modifier les pages à la volée ou à distribuer du (vrai) malware sous son apparence humoristique.

Je trouve que ce serait particulièrement amusant si ça se produisait un jour.

Je n'ai pas précisé que je travaille sur des systèmes embarqués peu connectés, et donc un bug ça peut vouloir dire envoyer des gens dans des endroits à des centaines de kilomètres de la ville la plus proche, sur plusieurs continents, parfois à plusieurs heures ou jours de marche ou en hélicoptère parce qu'il n'y a pas d'autre accès possible, pour aller remettre le truc en route.

(Quand ce n'est pas du code embarqué dans un satellite, ou là, le satellite pourrait tout simplement devenir inutilisable).

J'imagine que tout le monde ne travaille pas avec de telles contraintes. Mais dans mon cas, le code qui marche à peu près, ça n'est pas suffisant. Et on laisse déjà passer suffisament de bugs comre ça sans avoir à passer par des LLM. En général on les intercepte avant que les versions ne soient trop deployées…

Je ne pense pas pouvoir contrôler l'usage de MAM lors de l'envoi du message.

En revanche il est possible de rentrer une adresse "full", c'est à dire avec une ressource: user@example.org/ressource. Dans ce cas, le message devrait être envoyé seulement à ce client là.

Je peux aussi essayer de remplacer le message par un iq, mais dans ce cas je crois que la ressource sera obligatoire.

La spec pourrait en revanche encourager l'envoi d'une rétractation qui permettrait d'"annuler" une demande dwautorisation une fois que un client y a répondu?

La loi de Kernighan:

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

Débugger du code est deux fois plus difficile que d'écrire ce même code. Donc, si vous écrivez du code aussi astucieux que possible, par définition, vous ne serez pas assez malin pour le débugger.

Bon courage avec du code généré que vous n'avez même pas écrit et qui reprend toute l'intelligence collective d'Internet sans discernement, donc.

En fait dans mon travail je dirai même que c'est complètement à côté de la plaque. Écrire du code c'est peut-être 1 à 10% du travail. Ce qui prend du temps, c'est d'écrire une spécification, de se mettre d'accord avec les clients sur ce qu'on doit faire, de vérifier que le code fait bien ce qu'on a dit, etc. Dans ce travail, la rédaction sous forme de code est un exercice pour s'assurer que on a pas oublié un cas tordu, que tout est bien formalisé. La structure des langages de programmation est là pour ça. Ça me semble donc incompréhensible de passer par un LLM pour se dispenser de cette formalisation et rester dans le flou du langage naturel. Je ne vois pas comment on peut aller au-delà d'un code qui marche "à peu près" ou "presque comme il faut". Et quand on en est là, il reste encore 90% du travail à faire.

Il n'y a pas d'ambiguité pour le 301, le POST est converti en GET par tous les navigateurs, et changer ça casserait plein de trucs. Ce n'est pas une spécification au départ, mais si Internet Explorer le fait, alors tout le monde doit le faire (à l'époque; je suppose que aujourd'hui ce sont les bêtists de Chrome qu'il faut reproduire au plus près).

Le code 308 permet donc d'avoir une redirection sans ce bug, et le 301 reste spécifié de façon floue et il faut deviner ou découvrir par soi-même qu'il faut convertir les POST en GET pour que certains sites fonctionnent (source: c'est un des trucs qui m'a convaincu d'arrêter d'essayer d'implémenter le protocole http from scratch pour Haiku, et d'utiliser curl comme tout le monde).

Avec 3Ko de RAM et sans périphérique d'affichage, ça va être compliqué.

Les gens se sont tellement habitués à avoir des machines surpuissantes qu'ils sont loin d'imaginer tout ce qu'on peut faire avec une machine pourtant bien incapable oe faire tourner Doom.

En terme de capacité mémoire on est plutôt proche du Commodore Vic-20, le précurseur du C64.

Le logiciel PulseView fait ça plutôt bien. Ils ont un wiki avec une liste de matériel compatible.

Le mien est l'un des nombreux "noname saleae clone", 8 canaux 24MHz. Je n'ai pas testé les autres options car les prix montent très vite si on a besoin de beaucoup de canaux à une fréquence acceptable (certains font du multiplexage, donc beaucoup de canaux, mais plus on en active, plus la fréquence d'échantillonnage diminue).

J'ai ajouté un diagramme de séquence expliquant ce qui est implémenté (j'ai laissé l'autre qui explique ce qui est dit dans la XEP 0070).

J'ai modifié le code pour utiliser le code statut 449, j'ai corrigé le problème de login quand javascript est désactivé, et j'ai mis à jour la documentation avec tout ça.

Je crois que c'était la dernière tâche à faire! Je vais pouvoir retourner à l'un de mes autres projets maintenant.

417 a l'air liée au header "Expect:", en gros ça permet de valider les en-têtes de la requête avant d'envoyer de grosses données.

Par exemple: pas la peine d'envoyer un fichier de 5Go sur un serveur via une requête POST pour recevoir finalement une réponse "non c'est trop gros".

On ajoute donc une réponse intermédiaire dès que le serveur a reçu les en-têtes et on permet à l'upload de se poursuivre.

412 quant à elle a l'air d'être lié à l'utilisation des requêtes conditionelles (If-Modified-Since par exemple).

Par contre le code 449 de Microsoft semble à peu près correspondre, je vais donc essayer ça:

https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-wdv/d5f72692-036d-435f-8037-fbc7024ecc50

En France, ça n'est plus autorisé depuis février 2025.

J'ai plus ou moins réussi à faire ce que je voulais.

La page tes-tlogin.html ci-dessus a disparu, elle n'est plus nécessaire.

Maintenant quand on accède à la page de login, on reçoit une réponse contenant:

• Un code d'erreur 402 (payment required). J'ai pris ce code un peu au hasard, sachant que on ne peut pas utiliser le code 401 (cela déclencherait l'affichage du dialogue de login du navigateur web) ni 200 (dans le cas d'un authorizer fastcgi, cela signifie que l'identification est valide et qu'on peut afficher la "vraie" page protégée par authentification). N'importe quel autre code devrait fonctionner, je suis ouvert à une meilleure proposition
• Un challenge WWW-Authenticate. En théorie ce challenge devrait être pris en compte même si ce n'est pas une page 401, pour indiquer qu'un autre contenu est disponible si on se connecte. Ça ne semble pas être utilisé en pratique
• Une page web avec un formulaire HTML de login et un peu de javascript. Si Javascript est désactivé, on devrait pouvoir avoir un lien vers le formulaire HTTP basique (et une page d'explication). Il faut que je finalise cette partie.

Le formulaire demande d'entrer seulement le JID. Il se charge ensuite de générer un token (en javascript) et de l'utiliser pour s'authentifier via XmlHttpRequest. Il refait donc une requête à la même URL, mais il faut répondre avec une erreur 401 et le challenge WWW-Authenticate, pour qu'il envoie ensuite le JID et le token. Pour distinguer cette requête de la première qui envoie un 402, je me suis basé sur le header HTTP X-Requested-With (la présence de ce header suffit à obtenir une réponse 401). À la réflexion, je ferais probablement mieux d'utiliser une query string (genre .../login?auth=basic) pour détecter ce cas.

Le XmlHttpRequest reçoit la réponse 401 avec challenge, répond au challenge avec une nouvelle requête. Celle-ci contient le JID et déclenche l'envoi vers le serveur XMPP. Enfin une fois la réponse XMPP reçue, la requête est autorisée par le serveur web, qui renvoie la réponse de la page située "en-dessous" de l'authorizer (dans mon cas, c'est le bugtracker Trac qui reprend la main, et initialise un cookie de session et une session avec le nom de l'utilisateur). Le XmlHttpRequest remplace le contenu de la page avec la réponse HTTP ainsi reçue.

Si on veut contourner le formulaire, il faut donc, soit utiliser l'en-tête X-Requested-With, soit l'option --auth-no-challenge de wget, par exemple. Mais comme indiqué plus haut, je vais sûrement remplacer ça par un paramètre dans l'URL, ça sera ainsi plus simple de l'utiliser également pour la versions sans Javascript.

J'ai mis à jour le README avec les explications de ce nouveau système.

Et il faut également que je regarde pour faire fonctionner le mode "fallback" pour les clients XMPP qui n'implémentent pas encore cette spécification…

Tout ce que je peux dire c'est que ça fonctionne chez moi. Le serveur et mon compte utilisateur sont tous les deux chez jabber.fr. Est-ce que tu peux recevoir des messages des utilisateurs de jabber.fr sans les avoir dans ton roster? (Je sais que certains serveurs n'autorisent pas de recevoir des messages d'inconnus, pour limiter le spam).

Les messages devraient venir de auth.pulkomandy.tk@jabber.fr

Chez Debian aussi, de ce que je comprend c'est poussé par les développeurs du noyau qui souhaitent mettre initramfs-tools à la retraite?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1114857