pulkomandy a écrit 2280 commentaires

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

Je préfère cette version:

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…

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é?

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

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.

utiliser cette idiotie de dose équivalente en bananes pour tenter de discréditer le propos est d'autant plus malhonnête

Je prend les repères que je peux.

Tu sais bien que ce qui compte ce n'est pas la dangerosité d'une portion de myrtilles mais l’accumulation quotidienne d'aliment contaminés

A priori il s'agit surtout du Cesium-137 ici.

Il ne semble pas s'accumuler dans l'organisme humain, il est éliminé au bout de quelques mois.

Wikipedia donne d'ailleurs une conversion en Sierets pour l'ingestion: 1 Becquerel de Cesium 137 = 12 nSv. Donc, 300 Becquerels pour 100 grammes de myrtilles très contaminées = 3.6 µSv. Comme ça, on peut se reporter directement au graphique de XKCD, sans passer par la case des bananes. C'est un peu plus élevé que mon approximation précédente.

Je ne cherche pas à discréditer quoi que ce soit, je suis juste embêté face à des chiffres donnés sans contexte et sans ordre de grandeur, pour des unités que je ne suis (heureusement) pas habitué à manipuler. Ça me semble important pour comprendre les enjeux.

Je fais le même genre de calcul quand on annonce un budget en millions ou en milliards d'euros à l'échelle d'un pays; souvent, calculer le montant par habitant m'aide à me faire une idée plus claire de ce que ça représente.

Et donc oui, après avoir fait ce petit calcul, on peut en conclure que ce n'est pas la dangerosité d'une portion de myrtilles qui est dangereuse. La question de l'"effet cocktail" peut effectivement se poser, mais, à ma connaissance, c'est difficile d'avoir des informations fiables là-dessus. Et ça ne me semble pas être le sujet de l'article non plus, d'ailleurs.

Comme souvent dans leurs articles, Reporterre balance des chiffres sans mettre aucun contexte.

ça fait combien, 3000 Becquerels par kilo de myrtille? C'est dangereux?

Pour faire simple, prenons l'unité de référence, la dose équivalente en bananes.

Une banane normale (pas cultivée à proximité d'un accident nucléaire émet environ 15Bq. Et une banane c'est environ 100 grammes. On arrive donc à 150Bq par kilo.

Les myrtilles très contaminées sont donc 20 fois plus radioactives qu'une banane normale (note: cette conversion est approximative, parce que les Bq ne se convertissent pas directement en Sieverts, ça dépend du type de rayonnement et de l'isotope, je suppose que ce n'est pas forcément du potassium dans les myrtilles).

Si on mange 100g de ces myrtilles (sélectionnées pour être les plus contaminées du lot) au petit déjeuner, on doit donc arriver autour de 2 µSv, c'est à dire quelque part entre une randonnée sur le plateau du Colorado et une radio des dents. Ou encore, l'équivalent de l'utilisation d'un écran cathodique pendant 2 ans.

De plus, en cherchant les articles de recherche correspondants, je lis ici que la limite pour les myrtilles en Europe est à 600 Bq/kg et pas 1200 comme indiqué par Reporterre, est-ce que cela a changé depuis 2021? Et les produits mesurés sont bien en dessous de cette limite, autour de 250Bq/kg pour les plus contaminés. Pas très loin d'une banane, donc.

Les écrans eInk couleur, c'est toute une aventure.

Actuellement la plupart des liseuses utilisent un filtre de couleur posé par-dessus l'écran eInk monochrome. Ce qui réduit le contraste (le blanc devient plus gris, le noir aussi) et ne donne pas des couleurs très vives.

Il existe une autre technologie pour faire de "vrais" écrans e-Ink couleur, avec des capsules contenant des encres de 4 couleurs (il existe plusieurs variantes, soit avec du cyan-jaune-magenta et du blanc, soit avec du rouge, jaune, noir et blanc, soit avec du rouge, jaune, blue et blanc). En ce moment ces écrans sont nommés "Spectra" ou "ACeP". Normalement, sur un écran e-Ink on met une charge électrique positive pour le noir et négative pour le blanc (ou l'inverse), les particules d'encre sont polarisées et vont se mettre en surface ou en profondeur de l'écran. Ces écrans couleur arrivent à utiliser des niveaux de charge intermédiaires, des impulsions, et des particules qui bougent plus ou moins vite pour arriver à faire monter à la surface les différentes couleurs.

Ils sont très rares sur les liseuses parce que cette technologie ne permet pas un temps d'affichage acceptable (compter environ 20 secondes pour rafraîchir l'écran). On en trouve par contre pour des cadres photo numériques, où ce temps de chargement des images n'est pas aussi problématique, ou encore pour des étiquettes de prix dans les supermarchés, des écrans publicitaires en remplacement d'affiches papier, … bref des utilisations où l'image affichée ne change pas souvent ou de façon limitée (il est possible de faire clignoter certaines zones de l'image avec un choix de couleurs limité par exemple, sur un système d'affichage publicitaire ça peut être intéressant).

L’une en couleur, à partir de 285 € en ce moment, vendue au choix, en noir ou en rouge, et l’autre à partir de 120 € avec également plusieurs choix de couleurs.

Donc les liseuses en couleurs sont noires ou rouges, mais les liseuses de plusieurs couleurs sont en noir et blanc. Il faut pas se tromper…

J'aurais pu vous faire un journal racontant la même chose, mais c'est franchement hors sujet et puis j'ai un peu la flemme de tout réécrire en français. J'espère que ça vous intéressera quand même.

La réaction de l'IETF est de se demander quelle est la solution la plus rapide pour mettre ce document à la poubelle. La procédure normale serait d'attendre son expriration sans rien faire, mais des sites de news commencent à s'emparer du sujet et à raconter n'importe quoi (par exemple que c'est un projet de l'IETF, alors ou'ils l'ont juste reçu et publié).