pulkomandy a écrit 2292 commentaires

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).

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!

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.

Il y a plusieurs hypothèses possibles:

• 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

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?

Ce sont des indicateurs pas du tout fiables, mais il n'existe pas grand chose d'autre. Et ce sont donc des indicateurs qui sont souvent utilisés, par exemple dans des analyses et articles de recherche sur le financement de l'open source.

C'est facile de voir le problème quand on connaît l'open source "de l'intérieur", mais c'est loin d'être le cas de tout le monde.

Si on veut faire campagne pour le financement de l'open source, ou ne serait-ce que pour la reconnaissance des compétences et de l'expertise en Europe (ou en France ou ailleurs), il va falloir commencer par là. Car énormément de choses passent sous les radars tandis que les startuppers qui utilisent les technos à la mode récoltent les financements en montrant leurs étoiles Github.

Il y a souvent une confusion entre les associations reconnue d'utilité publique (effectivement assez peu nombreuses et déjà bien contrôlées) et les associations d'intérêt général, pour lesquelles il n'y a pas de processus de certification. L'association vérifie elle-même si elle vérifie les 3 critères nécessaires et peut se déclarer d'intérêt général auprès de ses donateurs.

Cela concerne donc potentiellement toutes les associations, et il n'y a pas de registre listant les associations d'intérêt général ou celles qui ne le sont pas.

Il y a tout au plus une procédure dite de "rescrit mécénat": une asociation peut demander à l'administration de vérifier si elle respecte bien les critères. En l'absence de réponse au bout de 6 mois, on considère que c'est validé par défaut, et l'administration ne pourra pas invalider les déductions d'impôts effectuées, même si on se rend compte plus tard que l'association n'est finalement pus d'intérêt général.

J'en ai lu un qui disait "c'est parce que les développeurs Rust aiment tellement leur langage qu'ils font plus d'efforts pour optimiser leur code, surtout si on les met en concurrence aâec des développeurs C". C'est une façon de voir les choses. Une autre façon de voir les choses est que tout le temps gagné à ne pas se battre avec des pointeurs null, de la corruption de données, etc permet de passer plus de temps à faire des optimisations. Quoi qu'il en soit, peu importe, tant cue le résultat est là.

Les performances des deux langages sont similaires: le "produit" fonctionne (lecture de senseurs 7000 fois par seconde, formatage en json, envoi sur un port série) et la RAM et la ROM ne sont pas remplies. Les différeces d'utilisation RAM sont liées au choix d'une lib json utilisant des allocaions dynamiques en C, et d'une utilisant des allocations statiques et sur la pile en Rust (l'une comme l'autre équipe aurait pu faire d'autre choix). La conclusion est: il n'y a pas de raison pour préférer le C au Rust (sans avoir besoin de donner les raisons de préférer le Rust au C que tout le monde connaît déjà?)

Quand on évalue une faille de sécurité, il y a plusieurs critères à considérer: facilité de mise en oeuvre, pré-requis (comme avoir déjà la possibilité d'exécuter du code non privilégié), conséquences, …

Celles-ci sont d'un niveau assez haut pour certains de ces critères, et surtout elles ont été publiées très vite, alors que le processus recommandé est de d'abord prévenir les équipes de Linux ainsi que des principales distributions, de sorte que la faille soit publiée après le déploiement du correctif. Ça n'a pas été fait dans les règles, peut-être parce que les entreprises ayant découvert ces failles cherchent à faire un maximum de bruit pour se faire de la publicité.

Cela explique la panique autour de ces problèmes. Pour l'évaluation de faille, une bonne partie est à faire en fonction du contexte: c'est assez différent entre un PC personnel, un système embarqué sur lequel il n'y a pas du tout de shell, un serveur mutualisé d'hébergement web qui fournit des accès ssh à tout le monde, … À vous de finir cette évaluation dans votre contexte pour déterminer à quel niveau d'urgence il faut traiter l'installation des correctifs.

L'espace de rédaction de dépêches dispose déjà d'un bouton "marquer comme urgent" pour prévenir l'équipe de modération qu'il faut publier rapidement. Ça sera peut-être pas fait dans la minute, mais parfois c'est pas mal de prendre un tout petit peu de recul.

Alors, oui, mais le problème c'est que si l'application s'affiche mal avec un thème, les gens vont se plaindre au développeur de l'application. Et tester une application avec des centaines de thèmes différents, c'est pas simple.

Cela ajoute donc de la complexité dans le code et du travail de maintenance, et c'est là que les gens qui n'en ont rien à carrer, comme tu dis, sont un problème, parce que c'est pas eux qui vont faire ce travail en général.

Il y a plusieurs technologies selon ce qu'on veut faire. Pour les T-Shirts du FOSDEM qui ont un nombre limité de couleurs unies (2 ou 3 couleurs, pas de dégradé) je ne pense pas que ça soit fait à base de papier transfert. C'est plutôt de la sérigraphie (ou "screen printing" en anglais).

Ça peut se faire aussi en DIY, même si on peut toujours compliquer les choses (avec par exemple des encres qui ne sèchent que lors d'une exposition aux UV).

Ce n'est pas trop difficile de trouver des boutiques proposant ce genre de service (ou d'autres techniques pour des séries plus petites) pour se faire imprimer un vêtement avec le motif qu'on veut, sans avoir besoin de repeindre accidentellement son salon/garage/bureau au passage.

Même dans ce cas là, c'est pas super intéressant. D'après l'article, pour que le minage de bitcoin soit intéressant, il faut que l'électricité utilisée coûte moins de 0.07$ par kWh. À ce prix là, tu peux revendre directement ton électricité gratuite à EDF, ça te rapportera à peu près autant sans avoir besoin d'investir dans des ASIC de minage de bitcoin à haute performance.

J'imagine que c'est similaire dans d'autres pays, à moins de ne pas payer l'électricité et d'être en plus déconnecté du réseau électrique, ce qui rendrait la vente impossible.

Tu as bien compris, c'est pour ça qu'ils se dépêchent de vendre le plus d'actions possibles avant qu'elles ne valent plus rien.

Et en général, le fondateur, il n'a pas acheté ses actions. Donc il ne peut rien perdre à ce jeu.

C’est pareil pour Uber. Uber ne peut devenir rentalbe que s’il remplace tous les transports en commun courte distance dans le monde entier. Ça fait partie de leur business plan.

Pour être rentables, il faudrait en plus qu'ils remplacent tous leurs chauffeurs par des véhicules autonomes.

C'est un plan de type "avec des si" où il faut un alignement de planètes qui n'arrive qu'une fois tous les deux millénaires, et encore, seulement si les vents sont favorables. Ça marche que dans les films, ce genre de chose.

Mais c'est pas très grave pour Uber qui pourra toujours "pivoter" vers un autre truc plus réaliste. Après avoir essayé la livraison de repas, j'ai vu qu'ils se mettent à la réservation d'hôtels.

Pour ma part, je trouve que ces derniers temps j'atteins ou je dépasse les limites du nombre de choses inquiétantes que je suis capable de traiter en parallèle. Tant mieux si vous y arrivez mieux que moi.

C'est plutôt dans l'autre sens: on est en pleine crise climatique avec un réchauffement à +3°, et y'a encore des dinosaures pour s'inquiéter d'une crise économique comme si c'était ça le problème.

Je complète un peu après avoir lu l'article:

• le problème se trouve dans des fonctions de cryptographie du noyau qui sont exposées assez directement à l'espace utilisateur. Ces fonctions écrivent 4 octets dans une zone fournie par l'utilisateur alors que celui-ci n'avait pas le droit d'écrire dedans. Dans l'attaque, on fait en sorte que ce pointeur pointe vers les données de su dans le cache disque.
• comme l'attaque s'en prend au cache disque, elle permet de contourner certaines solutions de sandboxing comme kubernetes. En effet dans ce cas là, il y a un seul kernel et un seul cache disque. Cela fait ou fera l'objet d'un deuxième blog (j'ai pas regardé si il était déjà disponible) pour les détails

Les détails sont sur un blog. En très résumé: utilisation de splice() de façon tordue pour corrompre le cache disque. Cela permet de remplacer le contenu d'un binaire qui est setuid (dans l'exemple c'est su qui est visé). Ainsi, lorsqu'on exécute ce binaire, c'est la version corrompue qui se lance, et comme il y a le bit setuid, il se lance en root.

Les détails sont dans le "de façon tordue" mais je vais aller lire le blog et je pense qu'il vaut mieux prendre les infos à la source que mon résumé.