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
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.
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.
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é.
Un jour on développera des langages dédiés à la communication avec les machines, qui ne laissent pas de place à l'ambiguïté, seront plus faciles à débugger, pourront s'exécuter pas à pas.
Je pensais juste une somme (en prenant checksum au sens littéral, c'est vrai qu'on utilise par abus de langage le même mot pour des mécanisme de contrôle qui ne sont pas des sommes).
En supposant que tu as tes données à comparer dans un buffer linéaire (int64 buffer[]):
int64 checksum = 0;
for (int i = 0; i < sizeof(buffer)/sizeof(int64); i++)
checksum += buffer[i];
Pas besoin de s'embèter à faire plus compliqué si le risque n'est pas une dégradation de canal de communication (qui change juste quelques bits) ou une attaque malicieuse (ou ce serait facile de changer deux variables de façons qui se compensent).
C'est possible d'utiliser un xor au lieu d'une addition, mais je pense que dans un truc fait en logiciel ça changera pas grand chose aux performances, et l'addition doit avoir des propriétés légèrement meilleures (il y a un peu d'interaction entre les bits, alors que le xor serait strictement "vertical", assurant une intégrité de chaque bit oe façon indépendante)
Je m'étonne du choix d'un CRC dans ce contexte. Un bête checksum sur 64 bits serait bien plus rapide à calculer, et pas forcément moins mauvais. Les CRC sont intéressants surtout si on veut faire de la correction d'erreur ou de la détection fine (divergence de quelques bits maximum), et encore, pour ces usages on a fait mieux depuis. Mais là, s'il y a une divergence d'état de jeu, il y a des chances que les différences dans différentes variables ne se compensent pas et ce sera bien détecté?
Le seuil est un mécanisme légal pour éviter un souci de santé publique.
Imaginons un scénario dif#érent: quelqu'un a sous la main un stock de césium 137 pur dont il ne sait pas quoi faire. Pour s'en débarrasser, il décide d'en verser un petit peu dans chaque lot de bouillie de myrtilles, de façon à être toujours pile en dessous du seuil. On est d'accord, c'est parfaitement légal et probablement sans danger (le seuil étant choisi de façon prudente).
Est-ce qu'on peut quand même dénoncer le fait que éthiquement et moralement, c'est quand même pas super?
En quoi le problème est différent lorsqu'il swagit de diluer un stock de myrtilles contaminées avec dwautres lots? D'un point de vue légal et sanitaire c'est toujours ok. D'un point de vue moral et éthique, ça ne me semble pas mieux.
Le risque est le même, mais dans un cas (ou tu as une myrtille très radioactive au milieu d'autres qui ne le sont pas), il aurait pu être éliminé complètement (en triant et en ne commercialisant pas du tout les myrtilles contaminées, plutôt que de les mélanger aux autres).
Même si le risque de problème de santé est faible, c'est dommage oe ne pas l'éliminer. Surtout que dans le concensus actuel sur la mesure des dégâts des radiations, on considère qu'il n'y a pas de dose anodine: une accumulation de petites doses (du genre, manger des kilos de myrtilles chaque annéee) pourrait avoir autant d'effet qu'une grosse exposition aux radiations d'un seul coup.
On manque de données (là encore, heureusement) pour être tout à fait certains que c'est le bon modèle. Certains défendent une approche considérant que les petites dosës font des petits dégâts facilement réparés par les mécanismes de défense du corps, et donc sans effet d'accumulation.
D'autres théories vont même plus loin en disant que les petites doses de radiations stimulent l'immunité naturelle et auraient donc un effet positif. Mais là, on bascule vite dans la pseudoscience financée par des gens qui ont probablement un stock de myrtilles radioactives à écouler.
[^] # 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.
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.
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.
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.
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.
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?
[^] # Re: Décideurs pressés
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien The mismeasure of open source. Évalué à 10.
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.
[^] # Re: Mouis, bof
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Comment des groupes néonazis ou identitaires profitent de dons défiscalisés grâce à des associations prétendument "d’intérêt général". Évalué à 7.
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.
[^] # Re: footprint
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Une étude (de STMicroelectronics + INRIA + Freie Uniresität Berlin) Rust vs C pour programmer dans l'embarqué. Évalué à 8.
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à?)
[^] # Re: comme d'habitude ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Et ça continue [DirtyFrag]. Évalué à 5.
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.
[^] # Re: Ah désolé je viens de poster à ce sujet en forum et liens, je n'avais pas vu ce journal
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Et ça continue [DirtyFrag]. Évalué à 6.
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.
[^] # Re: apps gtk ou qt
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Nouvelle version du bureau Agnostep pour les 35 ans de GNUstep. Évalué à 9.
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.
[^] # Re: Polo
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Darty, le libre et Linux. Évalué à 4.
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.
[^] # Re: 5, 4, 3…
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Le minage de bitcoins n'est plus rentable. Évalué à 6.
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.
[^] # Re: Un classique des nouveaux business
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal L'envolée des prix des agents IA. Évalué à 9.
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.
[^] # Re: Un classique des nouveaux business
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal L'envolée des prix des agents IA. Évalué à 6.
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.
[^] # Re: Il ne nous reste plus qu'un mème à sortir
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal La crise économique qui vient. Évalué à 10.
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.
[^] # Re: Il ne nous reste plus qu'un mème à sortir
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal La crise économique qui vient. Évalué à 10.
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.
[^] # Re: Mettez d'urgence vos kernels à jour !
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien [Copy Fail] The same 732-byte Python script roots every Linux distribution shipped since 2017.. Évalué à 7.
Je complète un peu après avoir lu l'article:
[^] # Re: Mettez d'urgence vos kernels à jour !
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien [Copy Fail] The same 732-byte Python script roots every Linux distribution shipped since 2017.. Évalué à 7.
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é.
[^] # Re: La réalité face à la complexité
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal "Cursor et Claude ont supprimé ma prod". Évalué à 10.
Je préfère cette version:
[^] # Re: Clairement un gros problème côté infra
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal "Cursor et Claude ont supprimé ma prod". Évalué à 10.
Un jour on développera des langages dédiés à la communication avec les machines, qui ne laissent pas de place à l'ambiguïté, seront plus faciles à débugger, pourront s'exécuter pas à pas.
Mais ça, c'est le futur…
[^] # Re: Pourquoi un CRC?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Sortie de Bim! en version 16, avec des bots. Évalué à 7.
Je pensais juste une somme (en prenant checksum au sens littéral, c'est vrai qu'on utilise par abus de langage le même mot pour des mécanisme de contrôle qui ne sont pas des sommes).
En supposant que tu as tes données à comparer dans un buffer linéaire (int64 buffer[]):
int64 checksum = 0;
for (int i = 0; i < sizeof(buffer)/sizeof(int64); i++)
checksum += buffer[i];
Pas besoin de s'embèter à faire plus compliqué si le risque n'est pas une dégradation de canal de communication (qui change juste quelques bits) ou une attaque malicieuse (ou ce serait facile de changer deux variables de façons qui se compensent).
C'est possible d'utiliser un xor au lieu d'une addition, mais je pense que dans un truc fait en logiciel ça changera pas grand chose aux performances, et l'addition doit avoir des propriétés légèrement meilleures (il y a un peu d'interaction entre les bits, alors que le xor serait strictement "vertical", assurant une intégrité de chaque bit oe façon indépendante)
# Pourquoi un CRC?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Sortie de Bim! en version 16, avec des bots. Évalué à 8.
Je m'étonne du choix d'un CRC dans ce contexte. Un bête checksum sur 64 bits serait bien plus rapide à calculer, et pas forcément moins mauvais. Les CRC sont intéressants surtout si on veut faire de la correction d'erreur ou de la détection fine (divergence de quelques bits maximum), et encore, pour ces usages on a fait mieux depuis. Mais là, s'il y a une divergence d'état de jeu, il y a des chances que les différences dans différentes variables ne se compensent pas et ce sera bien détecté?
Et effectivement, des CRC, y'en a plein avec des propriétés différentes, il y a même un "zoo" pour les cataloguer: https://users.ece.cmu.edu/~koopman/crc/index.html
[^] # Re: Jouons avec les unités
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien J’ai constaté que les myrtilles de Tchernobyl étaient proches de mon petit-déjeuner. Évalué à 8.
Le seuil est un mécanisme légal pour éviter un souci de santé publique.
Imaginons un scénario dif#érent: quelqu'un a sous la main un stock de césium 137 pur dont il ne sait pas quoi faire. Pour s'en débarrasser, il décide d'en verser un petit peu dans chaque lot de bouillie de myrtilles, de façon à être toujours pile en dessous du seuil. On est d'accord, c'est parfaitement légal et probablement sans danger (le seuil étant choisi de façon prudente).
Est-ce qu'on peut quand même dénoncer le fait que éthiquement et moralement, c'est quand même pas super?
En quoi le problème est différent lorsqu'il swagit de diluer un stock de myrtilles contaminées avec dwautres lots? D'un point de vue légal et sanitaire c'est toujours ok. D'un point de vue moral et éthique, ça ne me semble pas mieux.
[^] # Re: Jouons avec les unités
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien J’ai constaté que les myrtilles de Tchernobyl étaient proches de mon petit-déjeuner. Évalué à 3.
Le risque est le même, mais dans un cas (ou tu as une myrtille très radioactive au milieu d'autres qui ne le sont pas), il aurait pu être éliminé complètement (en triant et en ne commercialisant pas du tout les myrtilles contaminées, plutôt que de les mélanger aux autres).
Même si le risque de problème de santé est faible, c'est dommage oe ne pas l'éliminer. Surtout que dans le concensus actuel sur la mesure des dégâts des radiations, on considère qu'il n'y a pas de dose anodine: une accumulation de petites doses (du genre, manger des kilos de myrtilles chaque annéee) pourrait avoir autant d'effet qu'une grosse exposition aux radiations d'un seul coup.
On manque de données (là encore, heureusement) pour être tout à fait certains que c'est le bon modèle. Certains défendent une approche considérant que les petites dosës font des petits dégâts facilement réparés par les mécanismes de défense du corps, et donc sans effet d'accumulation.
D'autres théories vont même plus loin en disant que les petites doses de radiations stimulent l'immunité naturelle et auraient donc un effet positif. Mais là, on bascule vite dans la pseudoscience financée par des gens qui ont probablement un stock de myrtilles radioactives à écouler.