On a une source qui dit que ces frigos étaient exposés directement sur internet? Parce que c'est aussi tout à fait possible qu'il y avait un VPN mais que le hacker a réussi à s'infiltrer dedans, non?
les logiciels libres sont gratuits, c'est pas pour autant qu'on en est le produit
Peut-être pas les utilisateurs, mais les développeurs qui travaillent sans être rémunérés et qui produisent du logiciel de qualité utilisé par des giga-entreprises, je crois que si, c'est un sacré bon produit.
Je comprends pas ces arguments qu'on voit régulièrement passer et qui ne correspondent à rien à mon expérience quotidienne avec de l'IA, y compris en équipe.
Je répondais à un commentaire qui se termine comme ça:
Ou est-ce qu'on est en train de voir émerger le développement entièrement automatisés de logiciel dont les spécifications sont connues (car on a une implémentation de référence) ?
J'imagine que ce n'est pas ce que tu pratiques (puisque il y a une équipe d'humain qui font des trucs).
Donc oui, c'est une question un peu hypothétique ou éventuellement pour les gens pratiquant le "vibe coding" le plus extrême. Ce n'est certainement (et à mon avis, heureusement) pas le cas de tous les gens qui utilisent de l'IA, dont certains font sûrement des choses très bien en gardant la main (ou au moins un œuil) sur le code produit.
En fait ça dépend comment on interprète les 4 libertés et même la notion de "liberté" elle même.
Prenons un autre exemple. Je développe un logiciel. Je le compile. Je distribue le binaire (sans les sources) avec une autorisation d'étudier, redistribuer, modifier et utiliser le programme.
Du point de vue des 4 libertés, c'est un logiciel libre.
Mais si tu prends par exemple la licence GPL, elle va un peu plus loin dans la façon dont la liberté de modifier un programme doit s'appliquer.
The “source code” for a work means the preferred form of the work for making modifications to it. “Object code” means any non-source form of a work.
The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities.
The Corresponding Source need not include anything that users can regenerate automatically from other parts of the Corresponding Source.
Et toute la section 6 est très claire sur le fait que je ne peux pas me contenter de distribuer le binaire en disant "c'est bon vous avez qu'à le désassembler vous-même". Ce n'est pas "the preferred form of the work for making modifications to it".
Maintenant prenons le cas d'un logiciel généré par un troupeau de LLMs agentiques. Est-ce qu'on peut se contenter de diffuser le code "source" généré? Ou bien est-ce qu'il faut publier tous les prompts, toute l'infrastructure, et les LLMs utilisés, pour pouvoir redéployer tout ça et regénérer le code "source" à partir de là? Puisque, après tout, le code généré est inutilisable.
Et donc, plus généralement, la liberté, est-ce que c'est juste "tu as le droit de modifier le logiciel mais démerde toi, et on va tout faire pour que ça soit très compliqué", ou est-ce qu'il y a un minimum d'équité pour donner vraiment les moyens aux gens de faire des modifications?
Gimp ne fait pas tout ce que fait Photoshop, et il a un fonctionnement très différent sur pas mal de points.
C'est un peu comme dire "Si les gens veulent un truc qui ressemble à Windows, opensource et gratuit mais fiable, pourquoi n'utilisent-ils pas tout simplement Linux?"
Oui certes ça ressemble, mais il y a plein de trucs que tu ne peux pas faire, ou que tu dois faire différemment, ou alors tu ne peux pas importer tes fichiers existants.
Bref, une migration comme ça, ça s'improvise pas. Sinon ça ferait bien longtemps que plus personne n'achèterait de logiciel payant.
Regarde le nombre de logiciels propriétaires qui sont mal codés, sans doute plein de code spaghetti, avec plein de dette technique etc. et les gens les utilisent quand même.
Les nogiciels générés par llm sont 100 à 1000 fois pire à ce niveau là. Avec la même conclusion qui arrive 100 à 1000 fois plus vite: si on ne prend pas le temps de traiter la dette technique, à la fin, on finit par tout jeter et tout recommencer.
Alors, c'est toujours la mode de faire des emballages plastique jetables utilisables une seule fois. Est-ce que c'est une raison pour faire la même chose avec du logiciel? Personellement, je pense pas.
Et à un moment, il va bien falloir payer tous ces LLMs. Comment ces logiciels vont se financer? Si le code est illisible par des humains, est-ce que c'est vraiment du logiciel libre?
Donc oui, ok, ça va plus vite. Je pense pas que c'était ça le hroblème qu'on avait. Je voudrais du logiciel plus fiable, mieux sécurisé, plus léger et plus accessible. Pas grave si ça prend quelques années pour le faire.
Pour Logo, est-ce que ce n’est pas par hasard la disponibilité sur les Thomson du plan calcul…? LSE aurait peut-être eu le même essor s’il avait bénéficié de la même diffusion facilitée ?
Les deux langages étaient disponibles sur les machines Thomson (ainsi que le BASIC bien sûr).
Historiquement, le C (et le C++ en a hérité) spécifie très peu de choses, le moins possible. À chaque compilateur de choisir comment il implémente le standard.
Dans le cas présenté ici, pour passer des arguments à une fonction, le compilateur va en général les pousser sur la pile avant d'appeler la fonction.
Généralement en C cela se fait de la droite vers la gauche, car c'est la solution la plus simple pour gérer les fonctions à nombre d'arguments variables. La fonction appelée peut accéder à arguments[0] pour le premier argument, arguments[-1] pour le second, etc. Cela étant situé sur la pile, les index positifs sont réservés pour le contexte de la fonction elle-même (variables locales, préparation de l'appel d'autres fonctions, …). Il faut donc commencer par pousser le dernier argument, puis l'avant dernier, puis… jusqu'au premier.
Ainsi la fonction appelée a besoin d'un seul pointeur sur la pile pour accéder à la fois à ses variables locales et à ses arguments.
Cependant, il existe des architectures ou des compilateurs pour lesquels tous les arguments ne sont pas passés sur la pile. Par exemple, les 2 ou 4 premiers (en partant de la gauche cette fois-ci, vous suivez?) arguments peuvent être passés dans des registres.
Il peut arriver qu'un compilateur décide de préparer d'abord ces 2 ou 4 premiers arguments avant de pousser les autres.
Il peut aussi arriver qu'un compilateur soit obligé de traiter les arguments de gauche à droite, par exemple pour assurer la compatiblité avec une convention d'appel d'un autre langage utilisée par le système d'exploitation. C'est typiquement le cas pour Windows, où les APIs utilisent plutôt la convention d'appel de Pascal. Voire, encore pire, sur Amiga, ou des extensions au langage C permettent de spécifier manuellement quels arguments doivent être passés dans quels registres.
Le langage pourrait imposer un ordre d'évaluation, mais dans ce cas, certains compilateurs devraient évaluer les arguments puis ensuite réordonner les résultats pour préparer l'appel de la fonction.
La façon dont les arguments sont disposés en mémoire ou dans les registres peut être définie par une documentation d'ABI spécifique à un compilateur, une architecture ou un système d'exploitation. On pourra indirectement en déduire l'ordre probable d'évaluation des arguments, mais sans garantie. Cela laisse un peu de liberté à l'optimiseur s'il décide de réordonner les choses.
Ma question pour le fil : combien d'entre vous ont réellement regardé les paramètres de dérivation de leur gestionnaire plutôt que de garder les valeurs par défaut, et lesquels utilisez-vous ?
J'ai pas regardé la config de mon KeepassXC.
Pour Vaultwarden il me semble avoir vu des alertes dans l'interface web indiquant que la configuration en place n'était plus conforme aux recommandations actuelles et qu'il fallait faire des modifications (mais c'est sur un truc ou je n'ai pas la main pour faire ce genre de config).
Pour moi la conclusion est: si jamais votre coffre de mots de passe a été volé, même s'il est chiffré, tout ce que ça vous apporte, c'est du temps pour renouveller tous les mots de passe avant que le chiffreemnt du coffre puisse être cassé. Quelques mois ou années si le coffre est bien chiffré avec des bons paramètres, peut-être seulement quelques jours ou quelques heures dans le cas contraire. Mais dans tous les cas, un jour le coffre sera cassé.
En gros: tu as une "definition of done" pour savoir quand une user story est finie et prête à déployer en prod (avec toutes les phases de test, relecture, validation, etc que cela nécessite).
C'est une bonne idée de valider les choses au fil de la réalisation de l'US plutôt que tout à la fin (exemple avec la fabrication d'une voiture: tu fais des contrôle qualité tout le nong de la chaîne d'assemblage, pas une fois que toute la voiture est assemblée).
Du coup, logiquement, tu peux repousser une partie de cette validation avant même l'entrée de la user story dans un sprint pour sa réalisation. Tu peux t'assurer par exemple que toutes les infos nécessaires sont disponibles, que les grandes lignes de l'architecture à mettre en place sont définies, peut-être même une définition des scénarios de test qu'il faudra jouer.
Oui ça demande du temps de préparer tout ça. Mais d'un autre côté ça augmente la fiabilité du chiffrage et ça permet donc à l'équipe de s'engager avec une bonne confiance sur ce qu'elle va pouvoir réaliser dans un sprint.
Selon les projets, ça peut être nécessaire ou pas. Dans certains cas, l'incertitude sur le chiffrage n'est pas importante, et livrer une version avec un ou deux sprints de retard sur ce qui était annoncé ne pose aucun problème (juste les utilisateurs attendront un peu). Par contre si il y a des deadlines critiques (publier un jeu vidéo avant noel, mettre à jour un logiciel de compta avant l'entrée en application d'une loi, installer le code dans un satellite avant sa mise en orbite), tu as intérêt à être très fiable sur ce genre de choses, et là, avoir une bonne definition of ready va au moins permettre d'anticiper les problèmes.
Ça déPend aussi si les dévs de l'équipe sont autonomes pour concevoir l'architecture pendant la réalisation d'une user story, ou si tu as une équipe de débutants avec seulement quelques personnes capables de faire la conception d'architecture. Ou si ton PO est surbooké et risque de bloquer le développement si on a une question pour lui pendant la réalisation de la user story.
Est-ce au'on peut arrÊter de propager cette rumeur sans fondement?
Détruire une copie d'un ouvrage ne dispense pas du droit d'auteur. Le seul truc qui s'approcherait vaguement de cette idée, c'est le droit à la copie privée en france qui n'oblige en aucun cas à détruire l'original. Et le droit d'auteur s'applique à l'oeuvre indépendament de son support.
La rumeur vient d'une supposition d'un libraire allemand ayant levé l'alerte sur ces achats de livres par les entreprises d'IA. Il n'y connaît pas plus que nous en termes de droit d'auteur et en plus la citation n'a pas forcément été bien traduite à partir de la publication originale en allemand. Mais tout le monde la répète bêtement sans vérifier.
Les entreprises procèdent comme ça parce que c'est la solution la moins chère et la plus rapide pour scanner un livre. C'est tout.
Le principe de base est simple: ces méthodes sont adaptées quand ce n'est pas possible d'écrire une spécification complète dès le départ. Les besoins ne sont pas complètement identifiés, ou alors on sait déjà qu'on voudra étendre le projet plus tard ou qu'il va devoir évoluer pour d'autres raisons.
La mise en pratique est donc de démarrer assez rapidement le développement, et de réaliser la spécification au fur et à mesure, en présentant des versions du travail en cours et en s'en servant pour identifier ce qui ne marche pas, les points à améliorer, etc.
Ça ne dispense pas de faire de la documentation, bien au contraire. Tout au long du projet, l'architecture évolue, et mintenir des documents à jour coûte plus cher que de les écrire une bonne fois pour toutes au début.
Ensuite, on peut pousser ces méthodes beaucoup plus loin: puisque la spécification et l'architecture du code sont modifiaples tout au long du projet, la même idée peut s'appliquer à toute l'organisation du projet. On peut donc décider d'ajouter ou de supprimer des réunions récurrentes, d'attribuer un rôle spécifique à une personne (archiect, product owner, scrum master), choisir quand on fait des livraisons, etc.
La méthode scrum est le résultat auquel est arrivé une équipe oe développeurs après plusieurs années de pratique et d'expérimentation. Elle met en place tout un tas de choses plutôt oien pensées: oes sprints de durée courte avec un périmètre de travail fixé à l'avance, ce qui fait que les urgences peuvent être reportées au sprint suivant la plupart du temps. La séparation des rôles entre scrum master et product owner pour que l'un puisse rappeler les règles à l'autre s'il était tenté d'y faire une entorse. Le chiffrage des user stories en "points" qui ne sont pas directement une estimation de temps mais permettent tout de même d'équilibrer la charge des sprints.
Souvent, ce modèle est appliqué bêtement sans être compris. Il n'est pas forcément adapté à toutes les situations. Il faudrait donc l'adapter en pratiquant l'agile. Mans pour cela, il faut d'abord bien le comprendre, sans quoi, des modifications qui semblent anodines peuvent complètement déséquilibrer l'ensemble (et comme on est en entreprise, ce sera au profit du management et au détriment des gens qui font le travail).
D'ailleurs, petite boutade, que faut-il faire d'un rapport de sécurité soumis par un nazi reconnu ? Ou est la limite ?
Si tu as bien mis tous les répulsifs à nazis dans ton projet (écriture inclusive, drapeaux arc en ciel, code de conduite…), normalement, tu ne devrais pas avoir ce problème :D
J'ai l'impression qu'une partie de l'écosystème est en mode "tant que c'est open source c'est tout bon", ou qui a à cœur de produire de l'open source, mais sans vision plus large autour.
Oui, il y en a, et il y en a même beaucoup, mais ne leur concédons pas la victoire trop vite. C'est pour ça que j'ai été embêté par la généralisation.
Il y a deux écoles là dedans:
Ceux qui choisissent de rester dans un cadre strictement open source avec les licenses habituelles, mais qui vont ajouter des règles au niveau de la communauté autour du projet via par exemple un code de conduite. Dans ce cas, un nazi peut toujours forker le code mais il ne peux pas renvoyer ses modifications dans le projet original
Ceux qui pensent que cette approche n'est pas suffisante, et incluent des contraintes directement dans la license. Quelques exemples sur le site de l'organisation ethical source.
Ce deuxième cas pose "problème" car de telles licenses rentrent souvent en conflit avec les définitions du libre de la FSF ou encode la définition du logiciel libre que Debian utilise pour déterminer si un logiciel peut être inclus dans la distribution ou si il doit être placé dans les dépôts non-free. Je ne sais pas s'il existe une distribution Linux (ou d'un autre système UNIX) qui serait plus ouverte à l'idée de ce nouveau type de license.
On voit que ces licenses sont assez variées dans ce qu'elles autorisent ou non. La license hippocratique va même jusqu'à proposer un outil sur son site web permettant de choisir soi-même ce qu'on veut interdire ou pas.
Il y a enfin une troisième catégorie intermédiaire: l'utilisation de licenses légalement mal fichues, soit l'AGPLv3, soit la license JSON qui dit simplement "The software should be used for Good, not Evil" sans définir ces deux derniers termes. IBM a demandé et obtenu une exception (pour elle-même et ses sous-fiffres) pour avoir le droit de faire le Mal en utilisant un logiciel distribué sous cette license. C'était la solution la plus simple pour apaiser ses services juridiques. (ça n'arrêtera peut-être pas les nazis, cela dit).
Il y a des projets open source qui rejettent les contributeurs fascistes, agresseurs sexuels, racistes, ou pour plein d'autres raisons. Il y a des projets qui ne le font pas.
Ou que le monde de l'open source a globalement une vision tunnel plus ou moins concentrée sur le code, les questions de licences et les modèles de développement…
ça me semble un peu exagéré. Les licenses libres effectivement sont concentrées exclusivement sur cet aspect, mais de là à généraliser au "monde de l'open source", ça me semble aller un peu vite tout de même. Ou alors on peut aussi bien généraliser au monde de l'informatique, qui ne fait pas forcément mieux ni moins bien à ce sujet.
Ce sera l’AGC (Apollo Guidance Computer) qui sera le premier à utiliser des circuits intégrés. Lourd, 32 kilos, il préfigure néanmoins les ordinateurs portables puisque tous les éléments, ordinateur, mémoire, écran et dispositif de saisie étaient réunis dans un seul boitier.
Petite erreur il me semble: l'AGC ne dispose pas lui-même d'un clavier et d'un écran dans son boîtier. Il s'agit d'un boîtier séparé appelé DSKY (Display-Keyboard). On voit bien les deux boîtiers côte à côte sur l'image utilisée par Wikipedia par exemple.
En revanche, c'est l'apparition à la fois de l'ingénierie logicielle, mot et concept inventé par Margaret Hamilton. Et c'est aussi le premier système embarqué au sens moderne (auparavant on trouvait embarqués dans divers véhicules, missiles et autres objets des système analogiques et/ou électromécaniques, mais pas des ordinateurs).
pour l'IA, il y a des applications réellement pratiques qui font avancer la recherche médicale par exemple.
Des LLM ou d'autres applications d'IA qui ne consomment même pas un millième des ressources?
Parce que oui l'IA pour la reconaissance de motifs dans des images (analyse de radios, d'IRM, …) ou pour le pliage de molécules, ça marche très bien et c'est relativement efficace. Mais ça ne demande pas d'aspirer tout internet et de consommer des gigawatts d'électricité.
Tu décris une méthode qui ressemble beaucoup au cycle en V traditionnel.
Il y a beaucoup de gens qui ne travaillent pas comme ça, mais avec des méthodes dites "agiles" ou ces étapes ne sont pas du tout découpées de la même façon.
En ce qui me concerne, l'écriture de code n'est pas seulement pour dire à la machine ce qu'elle doit faire. Il s'agit d'une méthode de formalisation des besoins exprimés. Cette formalisation dans un langage strict et structuré fait que on se rend compte, lors de l'écriture du code, qu'il y a des cas non prévus dans la spécification, voire des informations contradictoires. Cela permet aussi de se poser la question des bonnes structures de données à adopter pour faire le traitement de façon efficace.
Il y a donc constamment des allers-retours entre l'écriture du code et la rédaction de la spécification.
Je ne suis pas capable de faire ce travail en exprimant les choses en langage naturel (français ou anglais). Je ne pense pas que la personne qui rédige la spécification pourrait remplacer mon travail par l'utilisation d'un LLM. Je ne pense même pas qu'elle pourrait réduire mon travail: si une partie du code était générée par un LLM, ça me ferait d'autant plus de code à relire et à comprendre. Pour moi cela demande plus d'effort de lire et comprendre le code de quelqu'un d'autre, que d'écrire moi-même du code. De plus, le processus mis en place (écriture par une personne et relecture par une autre) est un moyen supplémentaire de détecter les divergences avec la spécification et les oublis. Lors de l'utilisation d'un LLM, c'est la première chose qui va sauter: le développeur ayant demandé au LLM de générer le code, ne l'a pas écrit, mais il l'a relu. Il va donc penser qu'une deuxième relecture n'est pas utile.
Il y a des cas où le code n'est pas critique, suffisamment simple, et où ça peut marcher. Mais dans ce cas, je ne vois pas l'intérêt d'en faire un journal sur linuxfr, car on apprendra rien de nouveau.
22 ans de moulage sur Linuxfr et ce serait un contributeur débutant? Je n'y crois pas…
C'est pas compliqué: les personnes qui n'ont ni fait l'effort d'écrire leur propre code, ni fait l'effort d'écrire peur propre journal, personne n'a envie de lire le résultat (ni le code, ni le journal). Si iels veulent des commentaires positifs et encourageants, après tout, ils peuvent en demander à leur LLM préféré qui saura faire ça très bien. Pourquoi embêter des humains pour ça? Il faut pousser la démarche jusqu'au bout, remplacer les développeurs, mais aussi les utilisateurs et les détracteurs du projet par des LLM. Ainsi les gens pourront enfin cesser de passer du temps devant leur ordinateur, pourront sortir prendre le soleil, et le monde sera meilleur.
Comme je l'ai écrit, la réponse aux questions dépend beaucoup du projet et aussi des raisons pour lesquelles on souhaite (ou pas) rejeter l'utilisation de LLMs.
Si les raisons sont une inquiétude sur la qualité du code ou des rapports de sécurité (avec un rapport qualité/volume produit), alors, effectivement, on peut limiter le problème d'autres façons (en disant simplement qu'on rejette les contributions de mauvaise qualité, peu importe comment elles sont faites).
Ça soulève d'autres questions. Je reprend les cas que je connaît. Dans Haiku, on reçoit souvent des contributions (faites à la main) qui ne vont pas au bout des choses. On aide les gens à mieux comprendre l'architecture, à améliorer leur proposition s'ils en ont envie, ou bien on reprend le truc en main et on finalise ou on réécrit les changements. Ce faisant, on a en tant que relecteur la satisfaction d'aider quelqu'un à monter en compétence, et les gens qui envoient des patchs en profitent pour apprendre des choses (clairement sans Haiku je n'aurais jamais acquis autant de connaissances sur le fonctionnement des systèmes UNIX, la programmation en C++, la conception d'IHM, …).
Dans ce contexte on a même réussi à encadrer des contributeurs âgés de 13 à 17 ans dans le cadre du Google Code-In. Niveau qualité du code produit, il est clair qu'un LLM aujourd'hui est loin devant ce qu'on peut attendre d'un adolescent de 13 ans. Cependant, nous avons pu faire fonctionner ce mode de contribution assez spécial, en particulier parce que nous avons produit une liste de tâches très détaillée et aussi parce que nous avons recruté les participants d'une année pour aider à encadrer ceux de l'année suivante.
Je ne pense pas que on puisse avoir une telle qualité d'échanges humains si on reçoit des masses de contributions générées par LLM. Dans le cas de Haiku encore, c'est déjà difficile sans LLM de répondre à toutes les demandes de revue de code. Et il n'est pas question ici de mettre en place un système de "réponse automatique" par LLM (on l'a fait par contre sur les aspects qui sont automatisables, comme le formatage du code, et il faudrait développer ou mettre en place d'autres outils par exemple pour le respect des conventions de nommage).
Voilà pour le cas où l'argument est sur la qualité et le volume des contributions. Ça dépend du volume de contributions reçu, de l'intérêt que les développeurs ont pour le partage de compétence via la revue de code, de la disponibilité des contributeurs. Pour des exemples de projets qui font des choix très différents parce qu'ils ont des contraintes différentes, citons sqlite (c'est impossible de leur faire accepter un patch, ils préfèrent réécrire le code eux-mêmes), ou Linux (très gros volume de contribution, ne peut pas trop se permettre d'avoir des failles de sécurité, pas assez de gens pour traiter toutes les contributions reçues: l'utilisation de LLM peut être une bonne solution une fois qu'on en est là).
Ensuite il y a l'argument du copyright. Là je peux citer Ryan Gordon qui travaille sur SDL. Lorsqu'il reçoit un patch généré par LLM, son souci principal est que cela pourrait être recopié de code source existant par ailleurs dans les données d'entraînement du LLM utilisé et sans en citer l'auteur. Devant l'incertitude au niveau de la license, l'option qu'il retient est de réécrire le code de façon différente (ce aui est d'autant plus difficile que le patch est simple). On a fait ce genre de choses chez Haiku aussi: une personne a vibe codé un tas de modifications (autour de la gestion de l'USB et des périphériques MIDI en particulier), un développeur de Haiku a regardé les changements et réécrit des correctifs de sa propre main. Là aussi, les enjeux ne sont pas les mêmes selon le projet. J'ai travaillé dans des entreprises où le risque de contamination du code interne par de la GPL faisait vraiment très peur aux juristes (de façon justifiée ou pas). Il y a d'autres projets où c'est beaucoup plus détendu là dessus (par exemple Linux qui n'est pas connu pour insister très fortement sur le respect de la GPL).
Enfin il y a l'argument des conséquences écologiques et en utilisation de ressources. Et là aussi le compromis change selon, disons les orientations politiques et éthiques du projet. Peut-être qu'on en a rien à faire. Peut-être que la fin justifie les moyens. Ou peut-être que c'est un projet très orienté sur la réduction des ressources et l'informatique frugale, auquel cas, le choix d'utiliser massivement des LLM serait discutable. Il n'y a pas une seule réponse et ça n'a pas forcément à être 100% oui ou non. De la même façon que plein de gens sont écologistes mais prennent quand même l'avion pour partir en vacances parce que "ça change rien, l'avion décollera peu importe si je suis dedans ou pas". Bon courage pour calculer le bilan carbone précis de chaque contribution, et savoir si oui ou non, le résultat net est positif. Je ne pense pas que ça soit faisable, et donc, la solution est forcément une décision arbitraire, qui peut être très simple (pas d'IA, ou full open bar) ou plus nuancée, ou décidée au cas par cas selon l'humeur du moment.
Pour en revenir au cas pratique de Haiku: la raison officielle qui conduit à interdire l'utilisation de LLMs, ce sont les problèmes de copyright. Dans ce contexte, il n'y a pas de problème si quelqu'un fournit un cas de test généré par un LLM (il servira à tester la correction mais ne sera pas intégré dans le code source), ou si quelqu'un fournit une contribution contenant du code généré par LLM (elle ne sera pas intégrée mais elle pourra servir de référence pour refaire une implémentation indépendante). Bien sûr cette approche n'a aucun sens si l'argument retenu était celui de la consommation de ressources (on fait 2 fois le travail: de ce point de vue c'est donc moins bien); et il n'a aucun sens non plus du point de vue de la qualité des contributions et de la montée en compétence des contributeurs (on passe du temps à réécrire du code qui existe déjà, on ne crédite pas directement les gens ayant utilisé le LLM comme auteurs des changements mais seulement comme ayant identifié le problème).
Il y a encore d'autres raisons pour exclure les LLMs que j'ai entendues, mais sur lesquelles j'ai moins réfléchi. Par exemple, le fait que les LLMs sont peut-être vraiment conscients, et que c'est donc une forme d'esclavage ou d'exploitation animale de les utiliser; ou encore des raisons religieuses, dans certaines religions, tenter de recréer l'intelligence humaine qui est l'aboutissement du travail de Dieu, c'est mal vu (je résume n'importe comment parce que je suis totalement incompétent dans ce domaine). Je suppose que cela amènerait encore des réponses différentes.
J'ai un avis sur la question, mais je vais le formuler sous forme de auestions pour que chacun puisse prendre sa propre décision pour ses propres projets (et la réponse n'est pas forcément la même dans tous les cas, par exemple en ce qui me concerne, l'approche de la sécurité dans Haiku n'est pas la même que dans mon emploi salarié, ou que dans d'autres projets que je maintiens):
Est-ce que trouver des failles de sécurité justifie l'impact écologique des LLMs lancés à toute vapeur pour faire une recherche par force brute de vulnérabilités?
Est-ce que la charge de travail est bien gérée, c'est à dire que les gens qui ont lancé le LLM prennent le temps d'analyser ce qu'ils ont trouvé et de faire une explication claire, une vraie analyse d'impact et une proposition de correction, ou bien est-ce qu'il s'agit de noyer les développeurs de logiciels libres sous des rapports dont la majorité ne sont pas des failles exploitables, et les laisser se débrouiller avec ça?
Ce sont des questions qui se posaient déjà avant l'arrivée de l'IA. Dans Haiku par exemple on s'attend à ce que les contributeurs fasse un peu d'efforts pour formater leur code correctement selon nos règles (certaines personnes refusent de le faire et considèrent que c'est une perte de temps), le tester avant de nous l'envoyer (on reçoit régulièrement des propositions de changements qui ne compilent même pas), répondre aux questions des développeurs sans s'énerver, parfois devoir faire du refactoring pour rendre une solution plus générale plutôt que un patch contournant le problème, etc. C'est assez exigeant, mais le but est que les gens qui commencent à participer à Haiku par de petites contributions s'impliquent de plus en plus et que leur travail nécessite de moins en moins de revue pour être intégré.
Lorsque la contribution externe est générée par LLM, le rapport de force change beaucoup. Il y a alors deux options faciles: interdire les LLM pour tout le monde, ou utiliser soi-même des LLM pour tenter de rééquilibrer. Il y a plein d'options moins faciles: accepter le déséquilibre, interdire toutes les contributions externes, …
C'est un peu comme si une entreprise avait un serveur email implémentant SMTP légèrement différent, empêchant les emails de s'échanger avec d'autres serveurs, mais que comme c'était une multi-nationale avec beaucoup de clients, on considérait que c'est aux autres de changer. Fort heureusement, les emails étaient déjà trop répandus et il y avait déjà beaucoup de gros fournisseurs, donc même avec sa puissance, Google n'a pas pu faire de même avec GMail.
Du côté des serveurs je ne sais pas, mais du côté des clients, l'implémentation IMAP de Google fait des choix assez inhabituels, et la mauvaise intégration avec les clients "lourds" existants a conduit pas mal de monde à oublier l'existence de Thunderbird et de ses concurrents pour utiliser exclusivement le webmail.
Il se passe aussi un peu la même chose avec le web: Google n'a pas réussi à imposer ses spécifications au W3C (qui a un fonctionnement à peu près aussi lourd que celui de la XSF) et donc cela a abouti à la création d'un organisme de standardisation concurrent, le WhatWG, avec la spécification de HTML5 et de plein d'autres trucs dont certains abandonnés entretemps (QUIC, SDCH, SPDY, HTTP 2, HTTP 3, …).
On peut donc imaginer ce qu'il se serait passé si la XSF avait accepté telle quelle la spécification de Google:
Google pose sa spec sur la table
La XSF accepte sans réfléchir
D'autres clients essaient d'implémenter la spec
Google ou les implémenteurs d'autres clients se rendent compte que la spec est incomplète, mal fichue, etc
Google ou les autres implémenteurs décident finalement de corriger la spécification de façon incompatible avec l'original
Certains clients implémentent l'ancienne spec, d'autres la nouvelle
Pas d'interopérabilité entre les différents protocoles
"ouin ouin XMPP c'est nul il y a des problèmes de compatibilité entre clients"
Bref, Google a fait un truc fonctionnant avec une seule implémentation de client et une seule implémentation de serveur. C'est beaucoup plus facile de faire ça que de faire une spécification interopérable pour un protocole standardisé. Ils n'avaient aucun intérêt à faire l'autre moitié du travail, ni à attendre que ça soit fait avant de déployer leur client. Je ne vois pas bien ce que la XSF aurait pu faire pour changer ça.
Apple said that iPhone 18 Pro Max devices that have been affected by this cellular issue on the AT&T network cannot have service reactivated with a software update. Instead, Apple said the device must be replaced entirely
Apple did not disclose the underlying cause of the issue.
Et ben j'aurais bien aimé avoir plus de détail sur ce bug qui n'est pas réparable et nécessite carrément de changer le téléphone. Suppositions possibles (mais il y en a sûrement plein d'autres):
Le modem envoie n'importe quoi et se fait bannir du réseau de AT&T
Destruction matérielle ou logicielle du modem (firmware corrompu, données essentielles effacées, mauvaise configuration qui endommage l'émetteur radio?)
Le logiciel du téléphone envoie des commandes invalides au modem qui finit par se mettre dans un mode de sécurité non déverrouillable.
[^] # Re: Objets connectés, IoT et stupidité de ce système
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Les frigos de plus de 200 supermarchés visés par une cyberattaque. Évalué à 4 (+1/-0).
On a une source qui dit que ces frigos étaient exposés directement sur internet? Parce que c'est aussi tout à fait possible qu'il y avait un VPN mais que le hacker a réussi à s'infiltrer dedans, non?
[^] # Re: Quels choix de programmation, aucun retour d'expérience... et la doc?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien “Mec, je sais coder” : après Photoshop, il recrée Word, Excel et PowerPoint, gratuits et sans abonnement. Évalué à 8 (+5/-0).
Peut-être pas les utilisateurs, mais les développeurs qui travaillent sans être rémunérés et qui produisent du logiciel de qualité utilisé par des giga-entreprises, je crois que si, c'est un sacré bon produit.
[^] # Re: Le monde du logiciel libre va-t-il se scinder en deux ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Vers la fin du logiciel propriétaire?. Évalué à 4 (+1/-0).
Je répondais à un commentaire qui se termine comme ça:
J'imagine que ce n'est pas ce que tu pratiques (puisque il y a une équipe d'humain qui font des trucs).
Donc oui, c'est une question un peu hypothétique ou éventuellement pour les gens pratiquant le "vibe coding" le plus extrême. Ce n'est certainement (et à mon avis, heureusement) pas le cas de tous les gens qui utilisent de l'IA, dont certains font sûrement des choses très bien en gardant la main (ou au moins un œuil) sur le code produit.
[^] # Re: Le monde du logiciel libre va-t-il se scinder en deux ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Vers la fin du logiciel propriétaire?. Évalué à 5 (+2/-0).
En fait ça dépend comment on interprète les 4 libertés et même la notion de "liberté" elle même.
Prenons un autre exemple. Je développe un logiciel. Je le compile. Je distribue le binaire (sans les sources) avec une autorisation d'étudier, redistribuer, modifier et utiliser le programme.
Du point de vue des 4 libertés, c'est un logiciel libre.
Mais si tu prends par exemple la licence GPL, elle va un peu plus loin dans la façon dont la liberté de modifier un programme doit s'appliquer.
Et toute la section 6 est très claire sur le fait que je ne peux pas me contenter de distribuer le binaire en disant "c'est bon vous avez qu'à le désassembler vous-même". Ce n'est pas "the preferred form of the work for making modifications to it".
Maintenant prenons le cas d'un logiciel généré par un troupeau de LLMs agentiques. Est-ce qu'on peut se contenter de diffuser le code "source" généré? Ou bien est-ce qu'il faut publier tous les prompts, toute l'infrastructure, et les LLMs utilisés, pour pouvoir redéployer tout ça et regénérer le code "source" à partir de là? Puisque, après tout, le code généré est inutilisable.
Et donc, plus généralement, la liberté, est-ce que c'est juste "tu as le droit de modifier le logiciel mais démerde toi, et on va tout faire pour que ça soit très compliqué", ou est-ce qu'il y a un minimum d'équité pour donner vraiment les moyens aux gens de faire des modifications?
# 72ème lien sur le même sujet
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien “Mec, je sais coder” : après Photoshop, il recrée Word, Excel et PowerPoint, gratuits et sans abonnement. Évalué à 9 (+7/-1).
C'est bon, on a vu, merci, y'a déjà 2 liens et un journal.
[^] # Re: Le monde du logiciel libre va-t-il se scinder en deux ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Vers la fin du logiciel propriétaire?. Évalué à 6 (+3/-0).
Gimp ne fait pas tout ce que fait Photoshop, et il a un fonctionnement très différent sur pas mal de points.
C'est un peu comme dire "Si les gens veulent un truc qui ressemble à Windows, opensource et gratuit mais fiable, pourquoi n'utilisent-ils pas tout simplement Linux?"
Oui certes ça ressemble, mais il y a plein de trucs que tu ne peux pas faire, ou que tu dois faire différemment, ou alors tu ne peux pas importer tes fichiers existants.
Bref, une migration comme ça, ça s'improvise pas. Sinon ça ferait bien longtemps que plus personne n'achèterait de logiciel payant.
[^] # Re: Le monde du logiciel libre va-t-il se scinder en deux ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Vers la fin du logiciel propriétaire?. Évalué à 6 (+4/-1).
Les nogiciels générés par llm sont 100 à 1000 fois pire à ce niveau là. Avec la même conclusion qui arrive 100 à 1000 fois plus vite: si on ne prend pas le temps de traiter la dette technique, à la fin, on finit par tout jeter et tout recommencer.
Alors, c'est toujours la mode de faire des emballages plastique jetables utilisables une seule fois. Est-ce que c'est une raison pour faire la même chose avec du logiciel? Personellement, je pense pas.
Et à un moment, il va bien falloir payer tous ces LLMs. Comment ces logiciels vont se financer? Si le code est illisible par des humains, est-ce que c'est vraiment du logiciel libre?
Donc oui, ok, ça va plus vite. Je pense pas que c'était ça le hroblème qu'on avait. Je voudrais du logiciel plus fiable, mieux sécurisé, plus léger et plus accessible. Pas grave si ça prend quelques années pour le faire.
[^] # Re: Standard Cocorico
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Un peu de fun polyglotte. Évalué à 4 (+1/-0).
Les deux langages étaient disponibles sur les machines Thomson (ainsi que le BASIC bien sûr).
https://www.epi.asso.fr/fic_pdf/b45p170.pdf
Lettre d'un professeur se plaignant que le LSE est ignoré: https://www.epi.asso.fr/fic_pdf/b45p064.pdf
La cartouche LSE pour MO5 et TO7 avec sa documentation: https://dcmoto.pages-perso.free.fr/programmes/lseg-edl/index.html
[^] # Re: Intéressant !
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Un peu de fun C++esque. Évalué à 10 (+9/-0).
Historiquement, le C (et le C++ en a hérité) spécifie très peu de choses, le moins possible. À chaque compilateur de choisir comment il implémente le standard.
Dans le cas présenté ici, pour passer des arguments à une fonction, le compilateur va en général les pousser sur la pile avant d'appeler la fonction.
Généralement en C cela se fait de la droite vers la gauche, car c'est la solution la plus simple pour gérer les fonctions à nombre d'arguments variables. La fonction appelée peut accéder à arguments[0] pour le premier argument, arguments[-1] pour le second, etc. Cela étant situé sur la pile, les index positifs sont réservés pour le contexte de la fonction elle-même (variables locales, préparation de l'appel d'autres fonctions, …). Il faut donc commencer par pousser le dernier argument, puis l'avant dernier, puis… jusqu'au premier.
Ainsi la fonction appelée a besoin d'un seul pointeur sur la pile pour accéder à la fois à ses variables locales et à ses arguments.
Cependant, il existe des architectures ou des compilateurs pour lesquels tous les arguments ne sont pas passés sur la pile. Par exemple, les 2 ou 4 premiers (en partant de la gauche cette fois-ci, vous suivez?) arguments peuvent être passés dans des registres.
Il peut arriver qu'un compilateur décide de préparer d'abord ces 2 ou 4 premiers arguments avant de pousser les autres.
Il peut aussi arriver qu'un compilateur soit obligé de traiter les arguments de gauche à droite, par exemple pour assurer la compatiblité avec une convention d'appel d'un autre langage utilisée par le système d'exploitation. C'est typiquement le cas pour Windows, où les APIs utilisent plutôt la convention d'appel de Pascal. Voire, encore pire, sur Amiga, ou des extensions au langage C permettent de spécifier manuellement quels arguments doivent être passés dans quels registres.
Le langage pourrait imposer un ordre d'évaluation, mais dans ce cas, certains compilateurs devraient évaluer les arguments puis ensuite réordonner les résultats pour préparer l'appel de la fonction.
La façon dont les arguments sont disposés en mémoire ou dans les registres peut être définie par une documentation d'ABI spécifique à un compilateur, une architecture ou un système d'exploitation. On pourra indirectement en déduire l'ordre probable d'évaluation des arguments, mais sans garantie. Cela laisse un peu de liberté à l'optimiseur s'il décide de réordonner les choses.
# J'ai pas regardé
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal 100 100 itérations : ce que le vol des coffres LastPass dit du choix d'un gestionnaire. Évalué à 6 (+4/-1).
J'ai pas regardé la config de mon KeepassXC.
Pour Vaultwarden il me semble avoir vu des alertes dans l'interface web indiquant que la configuration en place n'était plus conforme aux recommandations actuelles et qu'il fallait faire des modifications (mais c'est sur un truc ou je n'ai pas la main pour faire ce genre de config).
Pour moi la conclusion est: si jamais votre coffre de mots de passe a été volé, même s'il est chiffré, tout ce que ça vous apporte, c'est du temps pour renouveller tous les mots de passe avant que le chiffreemnt du coffre puisse être cassé. Quelques mois ou années si le coffre est bien chiffré avec des bons paramètres, peut-être seulement quelques jours ou quelques heures dans le cas contraire. Mais dans tous les cas, un jour le coffre sera cassé.
[^] # Re: Le problème est en aval
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le vibe coding, linuxfr, et moi. Évalué à 4 (+1/-0).
La "definition of ready" fait partie de scrum, c'est assez bien expliqué ici par exemple: https://www.scrum.org/resources/blog/walking-through-definition-ready
En gros: tu as une "definition of done" pour savoir quand une user story est finie et prête à déployer en prod (avec toutes les phases de test, relecture, validation, etc que cela nécessite).
C'est une bonne idée de valider les choses au fil de la réalisation de l'US plutôt que tout à la fin (exemple avec la fabrication d'une voiture: tu fais des contrôle qualité tout le nong de la chaîne d'assemblage, pas une fois que toute la voiture est assemblée).
Du coup, logiquement, tu peux repousser une partie de cette validation avant même l'entrée de la user story dans un sprint pour sa réalisation. Tu peux t'assurer par exemple que toutes les infos nécessaires sont disponibles, que les grandes lignes de l'architecture à mettre en place sont définies, peut-être même une définition des scénarios de test qu'il faudra jouer.
Oui ça demande du temps de préparer tout ça. Mais d'un autre côté ça augmente la fiabilité du chiffrage et ça permet donc à l'équipe de s'engager avec une bonne confiance sur ce qu'elle va pouvoir réaliser dans un sprint.
Selon les projets, ça peut être nécessaire ou pas. Dans certains cas, l'incertitude sur le chiffrage n'est pas importante, et livrer une version avec un ou deux sprints de retard sur ce qui était annoncé ne pose aucun problème (juste les utilisateurs attendront un peu). Par contre si il y a des deadlines critiques (publier un jeu vidéo avant noel, mettre à jour un logiciel de compta avant l'entrée en application d'une loi, installer le code dans un satellite avant sa mise en orbite), tu as intérêt à être très fiable sur ce genre de choses, et là, avoir une bonne definition of ready va au moins permettre d'anticiper les problèmes.
Ça déPend aussi si les dévs de l'équipe sont autonomes pour concevoir l'architecture pendant la réalisation d'une user story, ou si tu as une équipe de débutants avec seulement quelques personnes capables de faire la conception d'architecture. Ou si ton PO est surbooké et risque de bloquer le développement si on a une question pour lui pendant la réalisation de la user story.
[^] # Re: Non
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le vibe coding, linuxfr, et moi. Évalué à 8 (+5/-0).
Est-ce au'on peut arrÊter de propager cette rumeur sans fondement?
Détruire une copie d'un ouvrage ne dispense pas du droit d'auteur. Le seul truc qui s'approcherait vaguement de cette idée, c'est le droit à la copie privée en france qui n'oblige en aucun cas à détruire l'original. Et le droit d'auteur s'applique à l'oeuvre indépendament de son support.
La rumeur vient d'une supposition d'un libraire allemand ayant levé l'alerte sur ces achats de livres par les entreprises d'IA. Il n'y connaît pas plus que nous en termes de droit d'auteur et en plus la citation n'a pas forcément été bien traduite à partir de la publication originale en allemand. Mais tout le monde la répète bêtement sans vérifier.
Les entreprises procèdent comme ça parce que c'est la solution la moins chère et la plus rapide pour scanner un livre. C'est tout.
Le droit d'auteur ils en ont rien à faire.
[^] # Re: Le problème est en aval
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le vibe coding, linuxfr, et moi. Évalué à 5 (+2/-0). Dernière modification le 08 octobre 2026 à 23:52.
On trouve de tout dans les méthodes agiles.
Le principe de base est simple: ces méthodes sont adaptées quand ce n'est pas possible d'écrire une spécification complète dès le départ. Les besoins ne sont pas complètement identifiés, ou alors on sait déjà qu'on voudra étendre le projet plus tard ou qu'il va devoir évoluer pour d'autres raisons.
La mise en pratique est donc de démarrer assez rapidement le développement, et de réaliser la spécification au fur et à mesure, en présentant des versions du travail en cours et en s'en servant pour identifier ce qui ne marche pas, les points à améliorer, etc.
Ça ne dispense pas de faire de la documentation, bien au contraire. Tout au long du projet, l'architecture évolue, et mintenir des documents à jour coûte plus cher que de les écrire une bonne fois pour toutes au début.
Ensuite, on peut pousser ces méthodes beaucoup plus loin: puisque la spécification et l'architecture du code sont modifiaples tout au long du projet, la même idée peut s'appliquer à toute l'organisation du projet. On peut donc décider d'ajouter ou de supprimer des réunions récurrentes, d'attribuer un rôle spécifique à une personne (archiect, product owner, scrum master), choisir quand on fait des livraisons, etc.
La méthode scrum est le résultat auquel est arrivé une équipe oe développeurs après plusieurs années de pratique et d'expérimentation. Elle met en place tout un tas de choses plutôt oien pensées: oes sprints de durée courte avec un périmètre de travail fixé à l'avance, ce qui fait que les urgences peuvent être reportées au sprint suivant la plupart du temps. La séparation des rôles entre scrum master et product owner pour que l'un puisse rappeler les règles à l'autre s'il était tenté d'y faire une entorse. Le chiffrage des user stories en "points" qui ne sont pas directement une estimation de temps mais permettent tout de même d'équilibrer la charge des sprints.
Souvent, ce modèle est appliqué bêtement sans être compris. Il n'est pas forcément adapté à toutes les situations. Il faudrait donc l'adapter en pratiquant l'agile. Mans pour cela, il faut d'abord bien le comprendre, sans quoi, des modifications qui semblent anodines peuvent complètement déséquilibrer l'ensemble (et comme on est en entreprise, ce sera au profit du management et au détriment des gens qui font le travail).
[^] # Re: Chambre blanche
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien AI Makes "Open-Source, Clean Room" Implementations Of Adobe Photoshop & Premier In Rust. Évalué à 7 (+4/-0). Dernière modification le 08 octobre 2026 à 21:21.
Il y a au moins un exemplaire des sources de la version 1.0 sur le site du Computer History Museum (avec une license n'autorisant ni l'exploitation commerciale ni la redistribution). Pas certain que ça aide.
[^] # Re: Je suis un Amish!
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Debian, IA, vibe coding & rsync : la croisée des chemins ?. Évalué à 6 (+3/-0).
Si tu as bien mis tous les répulsifs à nazis dans ton projet (écriture inclusive, drapeaux arc en ciel, code de conduite…), normalement, tu ne devrais pas avoir ce problème :D
Oui, il y en a, et il y en a même beaucoup, mais ne leur concédons pas la victoire trop vite. C'est pour ça que j'ai été embêté par la généralisation.
Il y a deux écoles là dedans:
Ce deuxième cas pose "problème" car de telles licenses rentrent souvent en conflit avec les définitions du libre de la FSF ou encode la définition du logiciel libre que Debian utilise pour déterminer si un logiciel peut être inclus dans la distribution ou si il doit être placé dans les dépôts non-free. Je ne sais pas s'il existe une distribution Linux (ou d'un autre système UNIX) qui serait plus ouverte à l'idée de ce nouveau type de license.
On voit que ces licenses sont assez variées dans ce qu'elles autorisent ou non. La license hippocratique va même jusqu'à proposer un outil sur son site web permettant de choisir soi-même ce qu'on veut interdire ou pas.
Il y a enfin une troisième catégorie intermédiaire: l'utilisation de licenses légalement mal fichues, soit l'AGPLv3, soit la license JSON qui dit simplement "The software should be used for Good, not Evil" sans définir ces deux derniers termes. IBM a demandé et obtenu une exception (pour elle-même et ses sous-fiffres) pour avoir le droit de faire le Mal en utilisant un logiciel distribué sous cette license. C'était la solution la plus simple pour apaiser ses services juridiques. (ça n'arrêtera peut-être pas les nazis, cela dit).
[^] # Re: Architecture de l'AGC
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Margaret Hamilton (1936-2026). Évalué à 4 (+1/-0).
Oui, j'avais mis le lien dans mon premier commentaire?
[^] # Re: Je suis un Amish!
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Debian, IA, vibe coding & rsync : la croisée des chemins ?. Évalué à 5 (+2/-0).
Il y a des projets open source qui rejettent les contributeurs fascistes, agresseurs sexuels, racistes, ou pour plein d'autres raisons. Il y a des projets qui ne le font pas.
ça me semble un peu exagéré. Les licenses libres effectivement sont concentrées exclusivement sur cet aspect, mais de là à généraliser au "monde de l'open source", ça me semble aller un peu vite tout de même. Ou alors on peut aussi bien généraliser au monde de l'informatique, qui ne fait pas forcément mieux ni moins bien à ce sujet.
# Architecture de l'AGC
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Margaret Hamilton (1936-2026). Évalué à 6 (+3/-0).
Petite erreur il me semble: l'AGC ne dispose pas lui-même d'un clavier et d'un écran dans son boîtier. Il s'agit d'un boîtier séparé appelé DSKY (Display-Keyboard). On voit bien les deux boîtiers côte à côte sur l'image utilisée par Wikipedia par exemple.
En revanche, c'est l'apparition à la fois de l'ingénierie logicielle, mot et concept inventé par Margaret Hamilton. Et c'est aussi le premier système embarqué au sens moderne (auparavant on trouvait embarqués dans divers véhicules, missiles et autres objets des système analogiques et/ou électromécaniques, mais pas des ordinateurs).
[^] # Re: C'est une bonne innovation ça, l'IA ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Debian, IA, vibe coding & rsync : la croisée des chemins ?. Évalué à 7 (+4/-0).
Des LLM ou d'autres applications d'IA qui ne consomment même pas un millième des ressources?
Parce que oui l'IA pour la reconaissance de motifs dans des images (analyse de radios, d'IRM, …) ou pour le pliage de molécules, ça marche très bien et c'est relativement efficace. Mais ça ne demande pas d'aspirer tout internet et de consommer des gigawatts d'électricité.
# Méthode de travail
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le vibe coding, linuxfr, et moi. Évalué à 10 (+9/-2).
Tu décris une méthode qui ressemble beaucoup au cycle en V traditionnel.
Il y a beaucoup de gens qui ne travaillent pas comme ça, mais avec des méthodes dites "agiles" ou ces étapes ne sont pas du tout découpées de la même façon.
En ce qui me concerne, l'écriture de code n'est pas seulement pour dire à la machine ce qu'elle doit faire. Il s'agit d'une méthode de formalisation des besoins exprimés. Cette formalisation dans un langage strict et structuré fait que on se rend compte, lors de l'écriture du code, qu'il y a des cas non prévus dans la spécification, voire des informations contradictoires. Cela permet aussi de se poser la question des bonnes structures de données à adopter pour faire le traitement de façon efficace.
Il y a donc constamment des allers-retours entre l'écriture du code et la rédaction de la spécification.
Je ne suis pas capable de faire ce travail en exprimant les choses en langage naturel (français ou anglais). Je ne pense pas que la personne qui rédige la spécification pourrait remplacer mon travail par l'utilisation d'un LLM. Je ne pense même pas qu'elle pourrait réduire mon travail: si une partie du code était générée par un LLM, ça me ferait d'autant plus de code à relire et à comprendre. Pour moi cela demande plus d'effort de lire et comprendre le code de quelqu'un d'autre, que d'écrire moi-même du code. De plus, le processus mis en place (écriture par une personne et relecture par une autre) est un moyen supplémentaire de détecter les divergences avec la spécification et les oublis. Lors de l'utilisation d'un LLM, c'est la première chose qui va sauter: le développeur ayant demandé au LLM de générer le code, ne l'a pas écrit, mais il l'a relu. Il va donc penser qu'une deuxième relecture n'est pas utile.
Il y a des cas où le code n'est pas critique, suffisamment simple, et où ça peut marcher. Mais dans ce cas, je ne vois pas l'intérêt d'en faire un journal sur linuxfr, car on apprendra rien de nouveau.
# Non.
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal L'IA et. Évalué à 10 (+11/-1).
22 ans de moulage sur Linuxfr et ce serait un contributeur débutant? Je n'y crois pas…
C'est pas compliqué: les personnes qui n'ont ni fait l'effort d'écrire leur propre code, ni fait l'effort d'écrire peur propre journal, personne n'a envie de lire le résultat (ni le code, ni le journal). Si iels veulent des commentaires positifs et encourageants, après tout, ils peuvent en demander à leur LLM préféré qui saura faire ça très bien. Pourquoi embêter des humains pour ça? Il faut pousser la démarche jusqu'au bout, remplacer les développeurs, mais aussi les utilisateurs et les détracteurs du projet par des LLM. Ainsi les gens pourront enfin cesser de passer du temps devant leur ordinateur, pourront sortir prendre le soleil, et le monde sera meilleur.
[^] # Re: hum
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Debian, IA, vibe coding & rsync : la croisée des chemins ?. Évalué à 8 (+6/-1).
Comme je l'ai écrit, la réponse aux questions dépend beaucoup du projet et aussi des raisons pour lesquelles on souhaite (ou pas) rejeter l'utilisation de LLMs.
Si les raisons sont une inquiétude sur la qualité du code ou des rapports de sécurité (avec un rapport qualité/volume produit), alors, effectivement, on peut limiter le problème d'autres façons (en disant simplement qu'on rejette les contributions de mauvaise qualité, peu importe comment elles sont faites).
Ça soulève d'autres questions. Je reprend les cas que je connaît. Dans Haiku, on reçoit souvent des contributions (faites à la main) qui ne vont pas au bout des choses. On aide les gens à mieux comprendre l'architecture, à améliorer leur proposition s'ils en ont envie, ou bien on reprend le truc en main et on finalise ou on réécrit les changements. Ce faisant, on a en tant que relecteur la satisfaction d'aider quelqu'un à monter en compétence, et les gens qui envoient des patchs en profitent pour apprendre des choses (clairement sans Haiku je n'aurais jamais acquis autant de connaissances sur le fonctionnement des systèmes UNIX, la programmation en C++, la conception d'IHM, …).
Dans ce contexte on a même réussi à encadrer des contributeurs âgés de 13 à 17 ans dans le cadre du Google Code-In. Niveau qualité du code produit, il est clair qu'un LLM aujourd'hui est loin devant ce qu'on peut attendre d'un adolescent de 13 ans. Cependant, nous avons pu faire fonctionner ce mode de contribution assez spécial, en particulier parce que nous avons produit une liste de tâches très détaillée et aussi parce que nous avons recruté les participants d'une année pour aider à encadrer ceux de l'année suivante.
Je ne pense pas que on puisse avoir une telle qualité d'échanges humains si on reçoit des masses de contributions générées par LLM. Dans le cas de Haiku encore, c'est déjà difficile sans LLM de répondre à toutes les demandes de revue de code. Et il n'est pas question ici de mettre en place un système de "réponse automatique" par LLM (on l'a fait par contre sur les aspects qui sont automatisables, comme le formatage du code, et il faudrait développer ou mettre en place d'autres outils par exemple pour le respect des conventions de nommage).
Voilà pour le cas où l'argument est sur la qualité et le volume des contributions. Ça dépend du volume de contributions reçu, de l'intérêt que les développeurs ont pour le partage de compétence via la revue de code, de la disponibilité des contributeurs. Pour des exemples de projets qui font des choix très différents parce qu'ils ont des contraintes différentes, citons sqlite (c'est impossible de leur faire accepter un patch, ils préfèrent réécrire le code eux-mêmes), ou Linux (très gros volume de contribution, ne peut pas trop se permettre d'avoir des failles de sécurité, pas assez de gens pour traiter toutes les contributions reçues: l'utilisation de LLM peut être une bonne solution une fois qu'on en est là).
Ensuite il y a l'argument du copyright. Là je peux citer Ryan Gordon qui travaille sur SDL. Lorsqu'il reçoit un patch généré par LLM, son souci principal est que cela pourrait être recopié de code source existant par ailleurs dans les données d'entraînement du LLM utilisé et sans en citer l'auteur. Devant l'incertitude au niveau de la license, l'option qu'il retient est de réécrire le code de façon différente (ce aui est d'autant plus difficile que le patch est simple). On a fait ce genre de choses chez Haiku aussi: une personne a vibe codé un tas de modifications (autour de la gestion de l'USB et des périphériques MIDI en particulier), un développeur de Haiku a regardé les changements et réécrit des correctifs de sa propre main. Là aussi, les enjeux ne sont pas les mêmes selon le projet. J'ai travaillé dans des entreprises où le risque de contamination du code interne par de la GPL faisait vraiment très peur aux juristes (de façon justifiée ou pas). Il y a d'autres projets où c'est beaucoup plus détendu là dessus (par exemple Linux qui n'est pas connu pour insister très fortement sur le respect de la GPL).
Enfin il y a l'argument des conséquences écologiques et en utilisation de ressources. Et là aussi le compromis change selon, disons les orientations politiques et éthiques du projet. Peut-être qu'on en a rien à faire. Peut-être que la fin justifie les moyens. Ou peut-être que c'est un projet très orienté sur la réduction des ressources et l'informatique frugale, auquel cas, le choix d'utiliser massivement des LLM serait discutable. Il n'y a pas une seule réponse et ça n'a pas forcément à être 100% oui ou non. De la même façon que plein de gens sont écologistes mais prennent quand même l'avion pour partir en vacances parce que "ça change rien, l'avion décollera peu importe si je suis dedans ou pas". Bon courage pour calculer le bilan carbone précis de chaque contribution, et savoir si oui ou non, le résultat net est positif. Je ne pense pas que ça soit faisable, et donc, la solution est forcément une décision arbitraire, qui peut être très simple (pas d'IA, ou full open bar) ou plus nuancée, ou décidée au cas par cas selon l'humeur du moment.
Pour en revenir au cas pratique de Haiku: la raison officielle qui conduit à interdire l'utilisation de LLMs, ce sont les problèmes de copyright. Dans ce contexte, il n'y a pas de problème si quelqu'un fournit un cas de test généré par un LLM (il servira à tester la correction mais ne sera pas intégré dans le code source), ou si quelqu'un fournit une contribution contenant du code généré par LLM (elle ne sera pas intégrée mais elle pourra servir de référence pour refaire une implémentation indépendante). Bien sûr cette approche n'a aucun sens si l'argument retenu était celui de la consommation de ressources (on fait 2 fois le travail: de ce point de vue c'est donc moins bien); et il n'a aucun sens non plus du point de vue de la qualité des contributions et de la montée en compétence des contributeurs (on passe du temps à réécrire du code qui existe déjà, on ne crédite pas directement les gens ayant utilisé le LLM comme auteurs des changements mais seulement comme ayant identifié le problème).
Il y a encore d'autres raisons pour exclure les LLMs que j'ai entendues, mais sur lesquelles j'ai moins réfléchi. Par exemple, le fait que les LLMs sont peut-être vraiment conscients, et que c'est donc une forme d'esclavage ou d'exploitation animale de les utiliser; ou encore des raisons religieuses, dans certaines religions, tenter de recréer l'intelligence humaine qui est l'aboutissement du travail de Dieu, c'est mal vu (je résume n'importe comment parce que je suis totalement incompétent dans ce domaine). Je suppose que cela amènerait encore des réponses différentes.
[^] # Re: hum
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Debian, IA, vibe coding & rsync : la croisée des chemins ?. Évalué à 6 (+3/-0).
J'ai un avis sur la question, mais je vais le formuler sous forme de auestions pour que chacun puisse prendre sa propre décision pour ses propres projets (et la réponse n'est pas forcément la même dans tous les cas, par exemple en ce qui me concerne, l'approche de la sécurité dans Haiku n'est pas la même que dans mon emploi salarié, ou que dans d'autres projets que je maintiens):
Ce sont des questions qui se posaient déjà avant l'arrivée de l'IA. Dans Haiku par exemple on s'attend à ce que les contributeurs fasse un peu d'efforts pour formater leur code correctement selon nos règles (certaines personnes refusent de le faire et considèrent que c'est une perte de temps), le tester avant de nous l'envoyer (on reçoit régulièrement des propositions de changements qui ne compilent même pas), répondre aux questions des développeurs sans s'énerver, parfois devoir faire du refactoring pour rendre une solution plus générale plutôt que un patch contournant le problème, etc. C'est assez exigeant, mais le but est que les gens qui commencent à participer à Haiku par de petites contributions s'impliquent de plus en plus et que leur travail nécessite de moins en moins de revue pour être intégré.
Lorsque la contribution externe est générée par LLM, le rapport de force change beaucoup. Il y a alors deux options faciles: interdire les LLM pour tout le monde, ou utiliser soi-même des LLM pour tenter de rééquilibrer. Il y a plein d'options moins faciles: accepter le déséquilibre, interdire toutes les contributions externes, …
[^] # Re: LOL
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Element Pro c'est de la "merde absolue", d'après un type de la Commission européenne. Évalué à 5 (+2/-0).
Du côté des serveurs je ne sais pas, mais du côté des clients, l'implémentation IMAP de Google fait des choix assez inhabituels, et la mauvaise intégration avec les clients "lourds" existants a conduit pas mal de monde à oublier l'existence de Thunderbird et de ses concurrents pour utiliser exclusivement le webmail.
Il se passe aussi un peu la même chose avec le web: Google n'a pas réussi à imposer ses spécifications au W3C (qui a un fonctionnement à peu près aussi lourd que celui de la XSF) et donc cela a abouti à la création d'un organisme de standardisation concurrent, le WhatWG, avec la spécification de HTML5 et de plein d'autres trucs dont certains abandonnés entretemps (QUIC, SDCH, SPDY, HTTP 2, HTTP 3, …).
On peut donc imaginer ce qu'il se serait passé si la XSF avait accepté telle quelle la spécification de Google:
Bref, Google a fait un truc fonctionnant avec une seule implémentation de client et une seule implémentation de serveur. C'est beaucoup plus facile de faire ça que de faire une spécification interopérable pour un protocole standardisé. Ils n'avaient aucun intérêt à faire l'autre moitié du travail, ni à attendre que ça soit fait avant de déployer leur client. Je ne vois pas bien ce que la XSF aurait pu faire pour changer ça.
[^] # Re: en fr
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien AT&T : Quand l'iPhone 18 Pro se transforme définitivement en iPod. Évalué à 7 (+4/-0).
Et ben j'aurais bien aimé avoir plus de détail sur ce bug qui n'est pas réparable et nécessite carrément de changer le téléphone. Suppositions possibles (mais il y en a sûrement plein d'autres):