Je connaît plein de gens qui regrettent d'avoir une voiture à moteur thermique, choix qui était économiquement cohérent quand ils l'ont acheté, mais qui ne l'est plus avec de l'essence bien au-dessus de 2€ le litre.
Ils ont pas encore revendu leur voiture pour la plupart, mais il est probable qu'ils passent à l'électrique lorsqu'ils le feront (enfin, si on ne file pas toute l'électricité aux datacenters pour l'IA)
Je viens de changer de téléphone, j'en ai profité pour virer tous les services Google.
L'application de la Caisse d'épargne s'installe sans aucun problème, le "sécuripass" s'active (par code de confirmation SMS + délai d'attente d'une semaine + envoi d'une alerte par mail), l'application se déverrouille (si on veut faire comme ça) avec le scanner d'empreinte digitale, pas de code à rentrer, aucun problème. Merci la Caisse d'épargne! L'identification repose sur l'accès à l'appli plus un code à 6 chiffres (là, j'aurai préféré pouvoir mettre un mot de passe fort).
L'application du Crédit Mutuel refuse complètement de se lancer. Le support technique me dit que toutes les versions d'Android modifiées sont considérées comme "rootées" et donc l'application est volontairement incompatible et que je dois contacter mon conseiller pour avoir une solution alternative. Contacté par mail, mon conseiller me demande de prendre rendez-vous via le site de banque en ligne, auquel je n'ai pas accès puisque je n'ai plus mon ancien téléphone avec l'application permettant d'y accéder. J'ai accès à un mode "de secours" ou on peut uniquement consulter le solde des comptes, ce mode est activé pour seulement une semaine et pour y accéder il faut une carte en carton avec une grille de numéros à rentrer (en plus d'un mot de passe fort). Si j'arrive à prendre rendez-vous, je pourrai recevoir un "digipass" qui fonctionne apparemment par lecture de QR Codes affichés par le site internet. Je vous raconterai ça…
À la banque populaire, le système proposé est un boîtier "sécuriplus" dans lequel il faut insérer sa carte bancaire et taper des chiffres. Je ne suis plus dans cette banque, mais ce système fonctionnait assez bien, avec un mode simple (validation du code secret par génération d'une signature à 8 chiffres) et un mode signature (par exemple pour ajouter un bénéficiaire: signature sur 8 chiffres du numéro de compte à ajouter, qu'il faut rentrer dans le boîtier puis recopier la réponse). C'est un boîtier très simple avec un écran affichant une ligne de texte, mais les opérations à faire sont assez bien expliquées par le site quand on fait la manipulation.
Donc j'ai plutôt l'impression que l'imagination de manque pas? Toutes les banques ont des solutions différentes!
Les « ruines de code », même chose que code legacy ? Du code en ruine peut-il être toujours utilisé ? Ou alors c'est un projet ou un module inutilisé depuis des années, que plus personne ne comprend.
Je dirais que c'est plutôt du code qui n'est plus utilisé. C'est une question qui va se poser un jour pour Github ou d'autres forges logicielles par exemple: faut-il supprimer les vieux dépôts qui n'ont plus aucune activité? Que faire des projets individuels abandonnés par leur auteur?
C'est aussi une question de préservation de l'histoire de l'informatique: parfois nous n'avons plus les sources mais seulement les binaires, pour du matériel qui n'est plus fabriqué. Peut-on garder ce code "vivant" et exécutable? Faut-il le faire?
Il y a des aspects de préservation (avec des projets comme Software Heritage), d'archivage, d'émulation. Et tout ça, on y pense pas quand on crée un nouveau projet (surtout sur une plateforme à la Github ou créer un projet, ça se fait en 2 clics).
Effectivement si tu vas sur Github et que tu prends un projet au hasard, tu as 90% de chances de tomber sur un truc abandonné, pas de maintenance, pas d'utilisateurs. Et ça ne peut qu'augmenter avec le temps si on ne supprime jamais rien. C'est donc, dans l'ensemble, un vaste champ de ruines logicielles, avec quelques endroits toujours occupés et entretenus au milieu.
Parfois, on trouve aussi parmi ces ruines des choses qui peuvent être réhabilitées et remises en service, pour un effort bien moins important que de reconstruire de zéro. Ou au contraire, des logiciels qu'on a choisi de préserver pour leur intérêt historique (comme les anciennes versions de UNIX), qui ne sont pas vraiment des ruines.
Franchement je préfère lire un truc mal écrit mais à la main. Les textes générés par IA sont trop longs, répètent 10 fois la même info, à un moment on se rend bien compte que ça tourne en rond et que ça mène nulle part.
En surface c'est bien écrit, mais le texte n'a pas de structure.
Faire de la correction d'orthographe et de grammaire, oui, ok très bien. Mais générer un article entier, ça donne pas un résultat meilleur au final.
Alors mon travail en temps que dev humain, c'est justement de répondre à chaque ligne de spécification avec 12 questions pour lever les ambiguïtés. J'y arrive déjà pas toujours en traduisant moi-même les spécifications en code, je fais des suppositions sur certains trucs et parfois je me trompe.
Ça se prépare un peu en amont avant de se lancer dans la programmation, certes, mais il y a un moment où on arrive à un niveau de détail trop fin pour pouvoir travailler en langage "naturel". C'est là qu'on écrit du code, et que ça oblige à mettre en évidence les cas qu'on a raté (plus ou moins facilement et à la compilation ou à l'exécution, selon le langage de programmation choisi).
J'imagine pas avec l'"aide" d'un LLM qui ne pose jamais de questions et génère du code même si ce qu'on lui demande est complètement idiot/dangereux/incohérent. Peut-être le jour ou les LLMs seront aussi psychorigides et pénibles avec les détails que les développeurs humains. Mais à ce moment là, personne n'aura plus envie de les utiliser.
Juste le volume de code généré peut être un obstacle. Que ce soit pour étudier un projet en particulier ou pour en trouver un parmi des millions existants sur github ou ailleurs qui fuit ce dont tu as besoin.
C'est un peu comme la dépendance à la voiture: jusque dans les années 60, ça n'existait pas (la dépendance hein, pas les voitures). Puis les infrastructures ont évolué, et aujourd'hui quand je dis que j'ai jamais passé mon permis de conduire parce que j'ai pas besoin, y'a des gens qui me prennent pour un extraterrestre.
J'espère que le logiciel et l'internet vont rester navigables/praticables sans l'aide de LLMs. C'est quoi l'équivalent d'une piste cyclable ou d'une ligne de train dans ce contexte?
Je crois que les équipe de modération ont été pas mal réduites aussi. Et c'était déjà pas très efficace avant (forcément, sur un site avec une telle fréquentation).
Là aussi, ça va continuer à fonctionner jusqu'à qu'il y aie un gros scandale qui se finisse devant la justice si le truc est laissé complètement à l'abandon, et ça peut durer très très longtemps si il y a quand même un minimum qui continue d'être fait, ça rend juste le site pas fréquentable.
surtout, ça se projette assez mal dans l'avenir, puisque les progrès des agents au cours des derniers mois font qu'une petite extrapolation ne laisse que quelques mois de marge aux meilleurs développeurs humains du monde.
"à ce rythme là, à la fin du mois tu aura plus de quatre douzaines de maris. à ta place, je demanderais un tarif de gros sur les gâteaux de mariage"
(peut-être bien que c'est vrai, mais je pense quand même qu'on manque un peu de données pour dire que ça va continuer à s'améliorer indéfiniment, et où se trouve le plafond).
Je mentionne au passage le site Is AI profitable yet?, qui permet de visualiser à quel point ce n'est pas rentable pour les fournisseurs de LLMs actuellement (sauf NVidia, bien sûr).
Et aussi à quel point le milliard de dollars investi par Mistral en fait un petit joueur dans le domaine…
D'après cette page, le temps que j'écrive ce commentaire, Amazon, Google, Microsoft et Meta ont perdu (ou investi, selon comment on voit les choses) chacun presque un million d'euros.
Pour la portabilité comme pour beaucoup d'autres choses, 99% du travail est nécessaire pour 1% des plateformes les plus inhabituelles. Donc une bibliothèque qui ne fonctionne que sur 99% du parc de machines, c'est relativement facile, et surtout, ça n'aide personne parce cue ces plateformes ont probablement déjà un bon choix de bibliothèques disponibles. La valeur ajoutée en allant dans le dernier 1% (là ou personne ne va) serait donc peut-être plus intéressante.
Haiku assure bien la compatibilité avec les binaires de BeOS. Historiquement c'était très complet, il était même possible d'utiliser les pilotes de périphériques et modules noyau de BeOS.
Cette possibilité pour les modules noyau a été retirée car elle empêchait d'activer des nouvelles fonctionnalités de sécurité (SMAP et SMEP et des permissions plus strictes au niveau du partage de la mémoire et de l'espace utilisateur).
Le noyau peut donc maintenant utiliser du C++ moderne.
Il faut préciser aussi que l'utilisation de gcc2 concerne uniquement la version 32bit x86 de Haiku. Toutes les autres versions (x86 64 bits, RISC-V, et maintenant ARM64 plus les autres en cours de développement) utilisent uniquement un gcc récent.
En revanche, toutes les bibliothèques standard de Haiku sont en C++98 compilable avec gcc2. Le projet maintient une version forkée de gcc2 avec de nombreuses corrections et le report de certaines fonctionnalités plus récentes et indispensables pour pouvoir implémenter la libc standard (par exemple, la possibilité d'utiliser des "wide chars").
Le problème concerne surtout le C++: entre gcc2 et gcc3, le frontend C++ de gcc a beaucoup changé, en particulier, le mangling des symboles a été remplacé pour correspondre à celui défini dans l'ABI officielle du processeur Itanium (il se trouve que c'est le premier processeur à imposer une convention pour le nommage des symboles C++, la même convention est utilisée depuis par gcc sur tous les processeurs).
Pour le C, il y a d'autres possibilités de contournement, nous savons par exemple compiler des versions récentes de ffmpeg avec un compilateur récent et faire en sorte que des applications BeOS compilées avec gcc2 puissent l'utiliser.
En ce qui concerne le C++, une autre possibilité serait de modifier un compilateur récent pour générer des symboles compatibles avec gcc2. C'est un projet qui est mentionné dans les forums de Haiku régulièrement sans que quelqu'un aie vraiment envie de s'y atteler (gros travail en vue, pour peu de bénéfices). On pensait plutôt laisser mourir tranquillement le support du 32 bit dans quelques années, la plupart des applications étant déjà remplacées par d'autres solutions.
Mais, un développeur assisté d'un LLM s'est lancé dans un patch pour clang permettant de générer des bibliothèques avec l'ABI de gcc2. On va voir ce que ça donne, sachant que l'utilisation de LLMs pour contribuer à Haiku est interdite et que les développeurs de clang/llvm ne semblent pas très motivés pour adopter ce code non plus (maintenir une deuxième ABI non standardisée risque de leur compliquer la vie). Cela ne permettrait de toutes façons pas de faire du C++ moderne, car de nombreuses constructions n'ont tout simplement pas de représentation dans l'ABI de gcc2, et la librairie standard C++ n'est pas du tout la même par exemple (celle de gcc2 date d'avant la finalisation du standard C++98 et présente quelques différences).
100 teraWatt.an divisé par 365x24 heures/an ça ne fait "que" 12GWh.
De la même façon, est-ce qu'il est bien précisé que la colonie de 1 million d'habitants sur Mars, ce sont des humains? Parce que l'objectif est un peu plus facile à atteindre avec une colonie de bactéries par exemple.
C'est une version mineure, encore heureux qu'il n'y a que des trucs ennuyeux dedans, non?
Mais bon, c'est vrai que ces derniers temps on a tendance à oublier toutes les bonnes pratiques du développement et de la maintenance des logiciels, alors peut-être que ça devient remarquable de faire ce genre de choses…
C'est une solution qui embête tous les humains qui veulent se connecter ou poster du contenu. Le tout sans forcément bloquer les IA.
Et la première chose à faire avant même tout ça, c'est déjÀ de décider si les contenus générés par LLM sont interdits, parce que actuellement, en l'absence de règles, ils ne le sont pas. La solution pour faire appliquer la règle, si besoin, c'est à voir dans un second temps, non?
Je crois que cet article parle juste de la loi de Goodhart. En faisant du TDD avec les yeux sur les indicateurs (la couverture de code et les 100% de tests OK), on oublie les objectis originaux de la méthode: avoir une base de test assez complète, de façon à pouvoir se lancer dans une refactorisation du code en minimisant les risques de déclencher des régressions non détectées.
Et, bien sûr, d'avoir des tests qui sont associés aux besoins et spécifications du produit (ou, à la rigueur, du module en cours de développement), sinon ça ne sert à rien.
On pourrait réfléchir à un système de tag démarrant par filtre_, genre filtre_traduction_IA, pour les gens qui ne veulent pas voir des traductions réalisées automatiquement par IA, ou alors filtre_assisté_IA, etc.
Si 99% des lecteurs vont tout de suite tout masquer, ça ne sert à rien de se lancer dans du code pour faire ça. On interdit les contenus générés ou assistés par LLM, et le problème est réglé.
Parce que, sinon, le moinssage existant fonctionne déjà relativement bien pour masquer le contenu généré par des LLMs, donc, c'est déjà plus ou moins en place. Ça rajoute juste du travail inutile pour les LLMs et leurs prompteurs (qui vont se faire moinsser) et les lecteurs (qui vont commencer à lire un nouveau contenu, et se dire "mais quelle honte, c'est du texte généré!" et moinsser).
Pour l'effet de communauté, ce qui marche très bien aussi ce sont les "fantasy consoles": il y a eu Pico-8, puis Tic-80 et Micro-W8 (en plus de l'historique CHIP8 qui a déjà été mentionné), et dans un style un peu différent il y a uxn et Varvara.
Et pour les nostalgiques de la micro informatique, il y a aussi le Commodore 64 qui a récemment relancé sa production, et ses concurrents, le Spectrum Next, et les machines de chez Foenix. Là c'est éventuellement un CPU d'époque, associé à un FPGA.
Enfin il y a le système RC2014, plutôt basé entièrement sur des composants d'époque, avec un bus standard (qui rapelle un peu le bus S-100 des machines CP/M) et tout un tas de modules pour composer sa propre machine.
Je n'ai toujours pas compris l'intérêt de ces machines où on branche un processeur 8 bit (chiant à programmer, il faut le dire) avec un CPU moderne à côté pour faire la génération vidéeo et tout le reste.
Pourquoi ne pas prendre un RP2040 tout seul et l'utiliser comme un micro-ordinateur? D'un point de vue simplicité, un coeur ARM ou RISC-V c'est quand même plus sympa qu'un z80 ou un 6502. Et un seul processeur, c'est mieux que deux.
Dans ce genre d'idée, j'ai travaillé un peu sur la Bitbox (à base de STM32) mais plus récemment avec un Lichee Pi Zero, on est sur un truc un peu plus gros et compliqué, mais U-Boot faisant le travail pénible d'initialisation du matériel, on peut faire de la programmation "baremetal" ARM par-dessus sans problème.
La base de l'argument semble quand même intéressante. Si tu demandes à un nouvel arrivant de relire du code, et que c'est seulement à ce moment là qu'il pose une question sur un truc qui semblait évident, tu viens probablement de détecter un problème de documentation, ou d'onboarding par exemple. Et tu vas sûrement le corriger pour que le prochain nouveau ne pose pas la même question.
Je me garderai bien d'avoir un avis sur comment remplacer ce processus de revue par quelque chose introduisant moins de latence dans un contexte de développement assisté/augmenté par des LLM qui est ce que semble chercher l'auteur.
Par contre je pense que ça met le doigt sur la bonne explication et valorisation du processus de revue: ça détecte les problèmes assez tard, donc à un moment où ils coûtent cher à corriger. Et donc, c'est intéressant surtout si on en profite pour éliminer non seulement le problème immédiat, mais aussi ses manifestations futures. Que ça soit en mettant en place de nouveaux outils (de formatage de cude par exemple), en améliorant la documentation, en faisant monter en compétence les personnes concernées sur un point difficile du langage de programmation (oui, je fais du C++), en améliorant la façon dont on rédige les spécifications ou les user stories, ou parfois avec des questionnements plus vastes sur l'architecture, les technologies choisies, le processus de déâeloppement en lui-même, …
Et c'est quelque chose qui n'est pas forcément bien compris par tout le monde, et qu'il faut expliquer ou parfois même défendre. Car, effectivement, à première vue, on irait 10 fois plus vite sans relecture de code.
Projet que je n'aurai jamais lancé sans l'aide de Claude par manque de temps.
J'avais réalisé une version en C++ à partir d'une traduction/adaptation Javascript du code original, de mémoire, cela ne m'avait pas pris plus d'une journée, le code n'étant pas très gros, et la traduction assez "mécanique" en dehors de quelques détails (par exemple, la version originale et la traduction Javascript génèrent du code à la volée pour précalculer la rotation des vaisseaux, ma âersion génère une liste de lignes à tracer).
Bon, je n'avais pas mis de musique, et mon émulation du tube cathodique est peut-être beaucoup plus simple.
le prestataire a fait exactement ce qu'on lui a demandé, et maintenant tout le monde se rend compte que c'était stupide et s'invente des excuses (peu probable)
le prestataire a fait une erreur en ne vérifiant pas sa playlist (c'est la raison avancée officiellement, "on a pris une playlist années 1940 sans vérifier le contenu). Il se trouve par malchance que 1) ça se passe dans une ville d'extrême-droite et 2) personne n'a décidé de couper la musique (ou ne se trouvait à proximité du bouton pour le faire) lorsque la diffusion a commencé
le prestataire (ou un de ses exécutants) n'avait pas envie de travailler pour l'extrême droite, et a trouvé un moyen de saboter la cérémonie avec une plaisanterie de mauvais goût bien choisie pour les circonstances
[^] # Re: Spéculations
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Gains potentiels de l'IA en terme d'optimisation énergétique, et consommation d'énergie. Évalué à 7 (+4/-0).
Je connaît plein de gens qui regrettent d'avoir une voiture à moteur thermique, choix qui était économiquement cohérent quand ils l'ont acheté, mais qui ne l'est plus avec de l'essence bien au-dessus de 2€ le litre.
Ils ont pas encore revendu leur voiture pour la plupart, mais il est probable qu'ils passent à l'électrique lorsqu'ils le feront (enfin, si on ne file pas toute l'électricité aux datacenters pour l'IA)
# Retour d'expérience
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le secteur bancaire « moderne ». Évalué à 9 (+6/-0).
Je viens de changer de téléphone, j'en ai profité pour virer tous les services Google.
L'application de la Caisse d'épargne s'installe sans aucun problème, le "sécuripass" s'active (par code de confirmation SMS + délai d'attente d'une semaine + envoi d'une alerte par mail), l'application se déverrouille (si on veut faire comme ça) avec le scanner d'empreinte digitale, pas de code à rentrer, aucun problème. Merci la Caisse d'épargne! L'identification repose sur l'accès à l'appli plus un code à 6 chiffres (là, j'aurai préféré pouvoir mettre un mot de passe fort).
L'application du Crédit Mutuel refuse complètement de se lancer. Le support technique me dit que toutes les versions d'Android modifiées sont considérées comme "rootées" et donc l'application est volontairement incompatible et que je dois contacter mon conseiller pour avoir une solution alternative. Contacté par mail, mon conseiller me demande de prendre rendez-vous via le site de banque en ligne, auquel je n'ai pas accès puisque je n'ai plus mon ancien téléphone avec l'application permettant d'y accéder. J'ai accès à un mode "de secours" ou on peut uniquement consulter le solde des comptes, ce mode est activé pour seulement une semaine et pour y accéder il faut une carte en carton avec une grille de numéros à rentrer (en plus d'un mot de passe fort). Si j'arrive à prendre rendez-vous, je pourrai recevoir un "digipass" qui fonctionne apparemment par lecture de QR Codes affichés par le site internet. Je vous raconterai ça…
À la banque populaire, le système proposé est un boîtier "sécuriplus" dans lequel il faut insérer sa carte bancaire et taper des chiffres. Je ne suis plus dans cette banque, mais ce système fonctionnait assez bien, avec un mode simple (validation du code secret par génération d'une signature à 8 chiffres) et un mode signature (par exemple pour ajouter un bénéficiaire: signature sur 8 chiffres du numéro de compte à ajouter, qu'il faut rentrer dans le boîtier puis recopier la réponse). C'est un boîtier très simple avec un écran affichant une ligne de texte, mais les opérations à faire sont assez bien expliquées par le site quand on fait la manipulation.
Donc j'ai plutôt l'impression que l'imagination de manque pas? Toutes les banques ont des solutions différentes!
[^] # Re: Légèrement partial
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Reddit - GitHub Copilot's new billing system is wreaking havoc. Évalué à 6 (+3/-0).
Si on va sur la page liée dans le premier commentaire:
https://github.com/orgs/community/discussions/categories/copilot-conversations
Les discussions en début de page:
et ça continue comme ça…
Je ne pense pas que Ed Zitron aie créé des faux comptes Github pour créer tous ces sujets de discussion et troller Github.
[^] # Re: Les ruines de code
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Qucocoma Philippe Samyn ?. Évalué à 5 (+2/-0).
Je dirais que c'est plutôt du code qui n'est plus utilisé. C'est une question qui va se poser un jour pour Github ou d'autres forges logicielles par exemple: faut-il supprimer les vieux dépôts qui n'ont plus aucune activité? Que faire des projets individuels abandonnés par leur auteur?
C'est aussi une question de préservation de l'histoire de l'informatique: parfois nous n'avons plus les sources mais seulement les binaires, pour du matériel qui n'est plus fabriqué. Peut-on garder ce code "vivant" et exécutable? Faut-il le faire?
Il y a des aspects de préservation (avec des projets comme Software Heritage), d'archivage, d'émulation. Et tout ça, on y pense pas quand on crée un nouveau projet (surtout sur une plateforme à la Github ou créer un projet, ça se fait en 2 clics).
Effectivement si tu vas sur Github et que tu prends un projet au hasard, tu as 90% de chances de tomber sur un truc abandonné, pas de maintenance, pas d'utilisateurs. Et ça ne peut qu'augmenter avec le temps si on ne supprime jamais rien. C'est donc, dans l'ensemble, un vaste champ de ruines logicielles, avec quelques endroits toujours occupés et entretenus au milieu.
Parfois, on trouve aussi parmi ces ruines des choses qui peuvent être réhabilitées et remises en service, pour un effort bien moins important que de reconstruire de zéro. Ou au contraire, des logiciels qu'on a choisi de préserver pour leur intérêt historique (comme les anciennes versions de UNIX), qui ne sont pas vraiment des ruines.
[^] # Re: /dev/null
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Publication de contenus augmentés par l'IA. Évalué à 10 (+7/-0).
Est-ce une raison pour supprimer les lois interdisant de jeter ses détritus par terre et encourager tout le monde à le faire? Je ne pense pas
[^] # Re: Hein
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche SelfRecover — protocole AGPL de récupération de compte sans email. Évalué à 8 (+6/-1).
C'est pas sympa pour les Tamagotchi dont la programmation est bien plus subtile!
[^] # Re: certains usages
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Publication de contenus augmentés par l'IA. Évalué à 10 (+13/-0).
Franchement je préfère lire un truc mal écrit mais à la main. Les textes générés par IA sont trop longs, répètent 10 fois la même info, à un moment on se rend bien compte que ça tourne en rond et que ça mène nulle part.
En surface c'est bien écrit, mais le texte n'a pas de structure.
Faire de la correction d'orthographe et de grammaire, oui, ok très bien. Mais générer un article entier, ça donne pas un résultat meilleur au final.
[^] # Re: Deuxième liberté
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Audition de la direction de Mistral AI et Solo dev. Évalué à 7 (+4/-0).
Alors mon travail en temps que dev humain, c'est justement de répondre à chaque ligne de spécification avec 12 questions pour lever les ambiguïtés. J'y arrive déjà pas toujours en traduisant moi-même les spécifications en code, je fais des suppositions sur certains trucs et parfois je me trompe.
Ça se prépare un peu en amont avant de se lancer dans la programmation, certes, mais il y a un moment où on arrive à un niveau de détail trop fin pour pouvoir travailler en langage "naturel". C'est là qu'on écrit du code, et que ça oblige à mettre en évidence les cas qu'on a raté (plus ou moins facilement et à la compilation ou à l'exécution, selon le langage de programmation choisi).
J'imagine pas avec l'"aide" d'un LLM qui ne pose jamais de questions et génère du code même si ce qu'on lui demande est complètement idiot/dangereux/incohérent. Peut-être le jour ou les LLMs seront aussi psychorigides et pénibles avec les détails que les développeurs humains. Mais à ce moment là, personne n'aura plus envie de les utiliser.
[^] # Re: Deuxième liberté
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Audition de la direction de Mistral AI et Solo dev. Évalué à 7 (+4/-0).
Juste le volume de code généré peut être un obstacle. Que ce soit pour étudier un projet en particulier ou pour en trouver un parmi des millions existants sur github ou ailleurs qui fuit ce dont tu as besoin.
C'est un peu comme la dépendance à la voiture: jusque dans les années 60, ça n'existait pas (la dépendance hein, pas les voitures). Puis les infrastructures ont évolué, et aujourd'hui quand je dis que j'ai jamais passé mon permis de conduire parce que j'ai pas besoin, y'a des gens qui me prennent pour un extraterrestre.
J'espère que le logiciel et l'internet vont rester navigables/praticables sans l'aide de LLMs. C'est quoi l'équivalent d'une piste cyclable ou d'une ligne de train dans ce contexte?
[^] # Re: Proportion de petits projet solo ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Audition de la direction de Mistral AI et Solo dev. Évalué à 6 (+3/-0).
Je crois que les équipe de modération ont été pas mal réduites aussi. Et c'était déjà pas très efficace avant (forcément, sur un site avec une telle fréquentation).
Là aussi, ça va continuer à fonctionner jusqu'à qu'il y aie un gros scandale qui se finisse devant la justice si le truc est laissé complètement à l'abandon, et ça peut durer très très longtemps si il y a quand même un minimum qui continue d'être fait, ça rend juste le site pas fréquentable.
[^] # Re: Pour être plus précis ...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Audition de la direction de Mistral AI et Solo dev. Évalué à 10 (+8/-0).
"à ce rythme là, à la fin du mois tu aura plus de quatre douzaines de maris. à ta place, je demanderais un tarif de gros sur les gâteaux de mariage"
(peut-être bien que c'est vrai, mais je pense quand même qu'on manque un peu de données pour dire que ça va continuer à s'améliorer indéfiniment, et où se trouve le plafond).
[^] # Re: La demande
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Audition de la direction de Mistral AI et Solo dev. Évalué à 10 (+8/-0).
Je mentionne au passage le site Is AI profitable yet?, qui permet de visualiser à quel point ce n'est pas rentable pour les fournisseurs de LLMs actuellement (sauf NVidia, bien sûr).
Et aussi à quel point le milliard de dollars investi par Mistral en fait un petit joueur dans le domaine…
D'après cette page, le temps que j'écrive ce commentaire, Amazon, Google, Microsoft et Meta ont perdu (ou investi, selon comment on voit les choses) chacun presque un million d'euros.
[^] # Re: Ford ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien sp.h is the standard library that C deserves (nouvelle bibliothèque standard pour le langage C). Évalué à 7 (+4/-0).
Pour la portabilité comme pour beaucoup d'autres choses, 99% du travail est nécessaire pour 1% des plateformes les plus inhabituelles. Donc une bibliothèque qui ne fonctionne que sur 99% du parc de machines, c'est relativement facile, et surtout, ça n'aide personne parce cue ces plateformes ont probablement déjà un bon choix de bibliothèques disponibles. La valeur ajoutée en allant dans le dernier 1% (là ou personne ne va) serait donc peut-être plus intéressante.
[^] # Re: GCC 2
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Nouvelles de Haiku - Printemps 2026. Évalué à 9 (+6/-0).
Haiku assure bien la compatibilité avec les binaires de BeOS. Historiquement c'était très complet, il était même possible d'utiliser les pilotes de périphériques et modules noyau de BeOS.
Cette possibilité pour les modules noyau a été retirée car elle empêchait d'activer des nouvelles fonctionnalités de sécurité (SMAP et SMEP et des permissions plus strictes au niveau du partage de la mémoire et de l'espace utilisateur).
Le noyau peut donc maintenant utiliser du C++ moderne.
Il faut préciser aussi que l'utilisation de gcc2 concerne uniquement la version 32bit x86 de Haiku. Toutes les autres versions (x86 64 bits, RISC-V, et maintenant ARM64 plus les autres en cours de développement) utilisent uniquement un gcc récent.
En revanche, toutes les bibliothèques standard de Haiku sont en C++98 compilable avec gcc2. Le projet maintient une version forkée de gcc2 avec de nombreuses corrections et le report de certaines fonctionnalités plus récentes et indispensables pour pouvoir implémenter la libc standard (par exemple, la possibilité d'utiliser des "wide chars").
Le problème concerne surtout le C++: entre gcc2 et gcc3, le frontend C++ de gcc a beaucoup changé, en particulier, le mangling des symboles a été remplacé pour correspondre à celui défini dans l'ABI officielle du processeur Itanium (il se trouve que c'est le premier processeur à imposer une convention pour le nommage des symboles C++, la même convention est utilisée depuis par gcc sur tous les processeurs).
Pour le C, il y a d'autres possibilités de contournement, nous savons par exemple compiler des versions récentes de ffmpeg avec un compilateur récent et faire en sorte que des applications BeOS compilées avec gcc2 puissent l'utiliser.
En ce qui concerne le C++, une autre possibilité serait de modifier un compilateur récent pour générer des symboles compatibles avec gcc2. C'est un projet qui est mentionné dans les forums de Haiku régulièrement sans que quelqu'un aie vraiment envie de s'y atteler (gros travail en vue, pour peu de bénéfices). On pensait plutôt laisser mourir tranquillement le support du 32 bit dans quelques années, la plupart des applications étant déjà remplacées par d'autres solutions.
Mais, un développeur assisté d'un LLM s'est lancé dans un patch pour clang permettant de générer des bibliothèques avec l'ABI de gcc2. On va voir ce que ça donne, sachant que l'utilisation de LLMs pour contribuer à Haiku est interdite et que les développeurs de clang/llvm ne semblent pas très motivés pour adopter ce code non plus (maintenir une deuxième ABI non standardisée risque de leur compliquer la vie). Cela ne permettrait de toutes façons pas de faire du C++ moderne, car de nombreuses constructions n'ont tout simplement pas de représentation dans l'ABI de gcc2, et la librairie standard C++ n'est pas du tout la même par exemple (celle de gcc2 date d'avant la finalisation du standard C++98 et présente quelques différences).
[^] # Re: Quelques extraits
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien SpaceX Files Its S-1: Full Breakdown Of The Largest IPO In American History [Introduction en bourse de SpaceX / xAI / X]. Évalué à 6 (+4/-1). Dernière modification le 22 mai 2026 à 12:35.
100 teraWatt.an divisé par 365x24 heures/an ça ne fait "que" 12GWh.
De la même façon, est-ce qu'il est bien précisé que la colonie de 1 million d'habitants sur Mars, ce sont des humains? Parce que l'objectif est un peu plus facile à atteindre avec une colonie de bactéries par exemple.
[^] # Re: Boring
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Debian 13.5 reminds Linux users why boring distributions still win. Évalué à 4 (+1/-0).
C'est une version mineure, encore heureux qu'il n'y a que des trucs ennuyeux dedans, non?
Mais bon, c'est vrai que ces derniers temps on a tendance à oublier toutes les bonnes pratiques du développement et de la maintenance des logiciels, alors peut-être que ça devient remarquable de faire ce genre de choses…
[^] # Re: Modération à l'inscription
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal [LinuxFr] Confiance, IA et contenu. Évalué à 8 (+5/-0).
C'est une solution qui embête tous les humains qui veulent se connecter ou poster du contenu. Le tout sans forcément bloquer les IA.
Et la première chose à faire avant même tout ça, c'est déjÀ de décider si les contenus générés par LLM sont interdits, parce que actuellement, en l'absence de règles, ils ne le sont pas. La solution pour faire appliquer la règle, si besoin, c'est à voir dans un second temps, non?
# Rien de nouveau, non?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Le culte du TDD et des LLMs. Évalué à 7 (+4/-0).
Je crois que cet article parle juste de la loi de Goodhart. En faisant du TDD avec les yeux sur les indicateurs (la couverture de code et les 100% de tests OK), on oublie les objectis originaux de la méthode: avoir une base de test assez complète, de façon à pouvoir se lancer dans une refactorisation du code en minimisant les risques de déclencher des régressions non détectées.
Et, bien sûr, d'avoir des tests qui sont associés aux besoins et spécifications du produit (ou, à la rigueur, du module en cours de développement), sinon ça ne sert à rien.
[^] # Re: Comment faire appliquer la règle!
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal [LinuxFr] Confiance, IA et contenu. Évalué à 8 (+5/-0).
Si 99% des lecteurs vont tout de suite tout masquer, ça ne sert à rien de se lancer dans du code pour faire ça. On interdit les contenus générés ou assistés par LLM, et le problème est réglé.
Parce que, sinon, le moinssage existant fonctionne déjà relativement bien pour masquer le contenu généré par des LLMs, donc, c'est déjà plus ou moins en place. Ça rajoute juste du travail inutile pour les LLMs et leurs prompteurs (qui vont se faire moinsser) et les lecteurs (qui vont commencer à lire un nouveau contenu, et se dire "mais quelle honte, c'est du texte généré!" et moinsser).
[^] # Re: Une vague de fraicheur...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Outil en ligne de commande : pourquoi pas l'assembleur ? [Article gratuit de la semaine]. Évalué à 5 (+2/-0).
Oui en effet je parlais surtout des 2 premiers.
Pour l'effet de communauté, ce qui marche très bien aussi ce sont les "fantasy consoles": il y a eu Pico-8, puis Tic-80 et Micro-W8 (en plus de l'historique CHIP8 qui a déjà été mentionné), et dans un style un peu différent il y a uxn et Varvara.
Et pour les nostalgiques de la micro informatique, il y a aussi le Commodore 64 qui a récemment relancé sa production, et ses concurrents, le Spectrum Next, et les machines de chez Foenix. Là c'est éventuellement un CPU d'époque, associé à un FPGA.
Enfin il y a le système RC2014, plutôt basé entièrement sur des composants d'époque, avec un bus standard (qui rapelle un peu le bus S-100 des machines CP/M) et tout un tas de modules pour composer sa propre machine.
Bref, y'en a pour tous les goûts!
[^] # Re: Une vague de fraicheur...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Outil en ligne de commande : pourquoi pas l'assembleur ? [Article gratuit de la semaine]. Évalué à 7 (+4/-0).
Je n'ai toujours pas compris l'intérêt de ces machines où on branche un processeur 8 bit (chiant à programmer, il faut le dire) avec un CPU moderne à côté pour faire la génération vidéeo et tout le reste.
Pourquoi ne pas prendre un RP2040 tout seul et l'utiliser comme un micro-ordinateur? D'un point de vue simplicité, un coeur ARM ou RISC-V c'est quand même plus sympa qu'un z80 ou un 6502. Et un seul processeur, c'est mieux que deux.
Dans ce genre d'idée, j'ai travaillé un peu sur la Bitbox (à base de STM32) mais plus récemment avec un Lichee Pi Zero, on est sur un truc un peu plus gros et compliqué, mais U-Boot faisant le travail pénible d'initialisation du matériel, on peut faire de la programmation "baremetal" ARM par-dessus sans problème.
[^] # Re: c'est intéressant
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Whoa, I produced this prototype so fast! I have super powers!. Évalué à 7 (+4/-0).
La base de l'argument semble quand même intéressante. Si tu demandes à un nouvel arrivant de relire du code, et que c'est seulement à ce moment là qu'il pose une question sur un truc qui semblait évident, tu viens probablement de détecter un problème de documentation, ou d'onboarding par exemple. Et tu vas sûrement le corriger pour que le prochain nouveau ne pose pas la même question.
Je me garderai bien d'avoir un avis sur comment remplacer ce processus de revue par quelque chose introduisant moins de latence dans un contexte de développement assisté/augmenté par des LLM qui est ce que semble chercher l'auteur.
Par contre je pense que ça met le doigt sur la bonne explication et valorisation du processus de revue: ça détecte les problèmes assez tard, donc à un moment où ils coûtent cher à corriger. Et donc, c'est intéressant surtout si on en profite pour éliminer non seulement le problème immédiat, mais aussi ses manifestations futures. Que ça soit en mettant en place de nouveaux outils (de formatage de cude par exemple), en améliorant la documentation, en faisant monter en compétence les personnes concernées sur un point difficile du langage de programmation (oui, je fais du C++), en améliorant la façon dont on rédige les spécifications ou les user stories, ou parfois avec des questionnements plus vastes sur l'architecture, les technologies choisies, le processus de déâeloppement en lui-même, …
Et c'est quelque chose qui n'est pas forcément bien compris par tout le monde, et qu'il faut expliquer ou parfois même défendre. Car, effectivement, à première vue, on irait 10 fois plus vite sans relecture de code.
# C'est triste le manque de temps
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Spacewar. Évalué à 7 (+4/-0).
J'avais réalisé une version en C++ à partir d'une traduction/adaptation Javascript du code original, de mémoire, cela ne m'avait pas pris plus d'une journée, le code n'étant pas très gros, et la traduction assez "mécanique" en dehors de quelques détails (par exemple, la version originale et la traduction Javascript génèrent du code à la volée pour précalculer la rotation des vaisseaux, ma âersion génère une liste de lignes à tracer).
Bon, je n'avais pas mis de musique, et mon émulation du tube cathodique est peut-être beaucoup plus simple.
[^] # Re: Ne pas mettre sur le compte…
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Cérémonies du 8 Mai : la chanson "Maréchal, nous voilà !", à la gloire de Pétain, diffusée à Carpentras et à Canet-en-Roussillon, villes RN et LR. Évalué à 10 (+8/-0).
Il y a plusieurs hypothèses possibles:
[^] # Re: Ne pas mettre sur le compte…
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Cérémonies du 8 Mai : la chanson "Maréchal, nous voilà !", à la gloire de Pétain, diffusée à Carpentras et à Canet-en-Roussillon, villes RN et LR. Évalué à 10 (+9/-0).
On peut quand même rigoler sur le fait que les idiots et l'extrême droite se retrouvent souvent ensemble, ou c'est interdit?