Le soucis est également la communication de ces boîtes autour de ces produits.
Ils mettent en avant un outil universel qui aurait le niveau d'un médecin ou d'un chercheur et serait à la frontière de l'intelligence humaine, etc. Et dans les faits c'est comme ça que ces interactions sont perçues par de nombreuses personnes, qui prennent ce que disent ces machines pour argent comptant en permanence. Ils ont retiré d'ailleurs des mises en garde concernant l'usage de ces outils dans un contexte médical.
Donc forcément des gens se sentent libre de s'en servir comme thérapeute ou confidents et comme prévus cela ne donne pas lieu à des résultats problématiques. Et ce n'est pas bon.
Rejeter la faute sur l'utilisateur, en particulier un ado / enfant, c'est cynique. Tu ne peux pas vendre d'un côté ton produit comme extraordinaire capable de 1000 et 1 choses et après dire "oui si on aborde des questions traumatiques ou le suicide ce n'est pas une bonne idée". À un moment tu as des responsabilités, et si ton produit n'est pas assez sûr dans ce genre de contexte il faut clairement le communiquer (et pas juste une ligne cachée dans des CGU que personne ne lit) ou assumer les responsabilités qui incombent. Il y a un manque de recul autour de l'usage de ces produits, ce sont eux qui décident de le survendre, de le mettre partout, et de le rendre disponible de manière large sans grosses restrictions.
C'est trop facile de blâmer l'utilisateur dans ce contexte et de se dédouaner. L'utilisateur n'a pas les moyens de se protéger de cela, personne n'a été formé à utiliser ces outils dans de bonnes conditions, et l'utilisateur est en plus trompé dans la réalité qui entoure ces produits. Ce n'est clairement pas assimilable à un mauvaise usage d'un produit du quotidien type marteau qui aurait été mal utilisé.
Et nouvelle interface web Anaconda comme pour Workstation.
Cela a été mentionné.
Mon petit commentaire : KDE Plasma Desktop brille par son absence dans toute la partie expérience utilisateur. Or, depuis Fedora 42, KDE Plasma n'est plus un simple spin (Fedora KDE Spin) mais une édition officielle à part entière, au même statut que Workstation.
GNOME est la seule exception à ce jour, car cela reste l'interface de référence, et que chaque version de GNOME est liée à une version unique de Fedora Linux donc le lien est fort. GNOME 49 sera disponible uniquement dans Fedora Linux 43.
Les mainteneurs de KDE Plasma dans Fedora Linux ont fait un choix différent. La version KDE Plasma change au cours d'une version. Ainsi Fedora Linux 42 et 43 utilisent la version 6.5. Alors que Fedora Linux 42 a connu la 6.3 et 6.4 entre temps.
C'est délicat de rédiger ainsi une liste de changements pour KDE Plasma dans ce contexte : quelqu'un qui installera Fedora Linux 43 dans quelques mois aura une version différente, et quelqu'un qui fera la mise à niveau depuis Fedora Linux 42 ne verra pas la différence sur ce point.
Oui enfin là on parle de déchets qui ont plus de 30 ans, ce n'est plus la politique actuelle depuis longtemps. Et ce ne sont pas non plus les déchets à très longue durée de vie qui étaient le sujet de discussion dans l'autre sujet.
De la même façon qu'il ne serait pas raisonnable de critiquer la gestion des déchets plus classiques ou industriels aujourd'hui en se basant sur les pratiques d'il y a 30 ans alors qu'il y a eu d'énormes évolutions entre temps.
Je ne suis pas contre rencontrer des libriste en Wallonie ou à Bruxelles, suivant le lieu et ce qu'on y fait je peux essayer de venir plus ou moins régulièrement.
pas une question de durée, mais cette loi est inutile car avec quinze ans de retard
On peut regretter que ce genre d'obligations n'arrive que maintenant, mais les faits sont là : ça arrive et ça va avoir de grandes répercutions et pour le mieux dans une industrie qui a été trop longtemps négligente.
Ce que je voulais souligner c'est que les États peuvent contraindre et savent le faire.
L'UE oblige à avoir maintenant 5 ans de mise à jour de sécurité après la vente du produit à partir de l'an prochain.
C'est une durée peut être insuffisante mais c'est un début et un vrai changement de mentalité qui concerne par ailleurs toute l'informatique embarquée (et pas que les téléphones).
Ce que je veux dire c'est que toute application qui manipule des données confidentielles, la bonne pratique c'est de garder en mémoire la dite donnée uniquement le temps nécessaire à son traitement et avant de libérer la mémoire il faut nettoyer cette zone avec des données.
Normalement on fait attention que les mots de passe ne soient stockés que dans des zones non enregistrables sur disque et de bien l'effacer avant de libérer la mémoire en question.
Valable d'ailleurs pour les données cryptographiques type clés privées.
Par contre, les études proposées par les industriels du nucléaire prétendent anticiper ce qui va arriver pendant les centaines de milliers et même des millions d'années à venir, ce n'est pas sérieux.
Reprenons :
1-Ces travaux ne sont pas de l'apanage uniquement des industriels du nucléaire, des universitaires de différentes spécialités font les analyses de cycle de vie, de même que la gestion des déchets du nucléaire ;
2-Les phénomènes climatologiques sont très complexes en vérité car ce sont des système très chaotiques avec de nombreuses inconnues à ce jour, c'est bien moins prévisible que ce qui se passe en profondeur dans le sous sol, le fonctionnement de la radioactivité et la science des matériaux ;
3-Tu n'expliques toujours pas comment une éventuelle fuite des déchets à longue durée de vie, qui causera une pollution locale réelle je ne dis pas le contraire, pourrait remettre en question le bilan carbone du nucléaire alors que la dite fuite ne fait pas d'émissions. Pourtant c'est essentiel pour être en mesure de contredire les bilans annoncés jusqu'ici.
C'est d'ailleurs pour toutes ces raisons que la France décide d'enfouir les déchets plutôt que de les garder en surface comme tu le voudrais : plus stable dans le temps, impact d'une fuite plus faible, moins de risques à cause de phénomènes très variables en surface que ce soit le climat comme les sociétés humaines.
L'évolution d'une chaîne de production qui va durer pendant des millions d'années,
Les déchets seront enfouis d'ici un délai bien plus court et n'y seront plus touchés. Même en admettant un accident dans ce stockage profond, l'impact sera local et ne nécessitera pas d'émettre une quantité astronomique de CO2. Le volume de déchets qui concerne des durée si longues est vraiment réduit au regard de la quantité d'électricité produite. L'impact d'une défaillance n'aurait d'ailleurs rien à voir avec une défaillance avec une centrale en fonctionnement (et pourtant, on a deux retours d'expérience dans ce cas, et on n'a pas émis des milliards de tonnes de CO2 à cause de ça).
C'est assez fort quand même d'affirmer inlassablement que le nucléaire n'est pas décarboné sur cette base alors que toutes les études disent que le nucléaire a des inconvénients mais pas celui-là en tenant compte du cycle de vie complet dont les déchets. Oui il y a des incertitudes, oui il y a des risques (mais on peut dire la même chose du bilan du renouvelable, du charbon, etc.) mais pas de nature à priori de changer significativement le résultat.
Et je trouve toujours curieux d'accepter les rapports concernant le climat, etc. mais refuser d'accepter leurs conclusions concernant le nucléaire dans le même temps. La méthode est la même pourtant.
Les scientifiques n'arrivent même pas à prévoir avec certitude la disparition de l'AMOC…
Mais quel rapport ?
On pourrait d'ailleurs te rétorquer que sur cette base on peut mettre le rapport du GIEC en entier à la poubelle car après tout il y a des incertitudes sur pas mal de phénomènes.
Cela ne me paraît pas être très raisonnable de réfuter leurs analyses de cycle de vie du nucléaire sur cette base sinon on peut refuser toute conclusion scientifique car des incertitudes il y en aura toujours.
La question est de se poser du pire scénario. Admettons que le stockage des déchets à vie longue a une fuite qui contamine une nappe environnante. L'eau est polluée localement. Voilà, comme elle peut l'être avec d'autres phénomènes ou industrie (dont le pétrole et le charbon, par exemple). Est-ce qu'on va devoir dépenser des millions de tonnes de CO2 pour gérer ça ? Non, de la même façon qu'on ne le fait pas pour d'autres contaminations locales qui arrivent pourtant régulièrement. Donc ce n'est pas de nature à priori de changer le bilan climatique du nucléaire de manière significative.
Cela ne me paraît pas très crédible de rejeter ces évaluations nombreuses d'un revers de la main.
T'a le gros des dépendances utilisé, par la plupart des projets C.
J'ai ri, c'est tellement divers en pratique.
Mais tu dépasses rarement la 10éne de libs.
Cela dépend des projets. Puis vu la taille des libs dont tu parles plus haut, cela n'a pas forcément beaucoup de sens de comparer quelques mini libs Rust avec de grosses libs C ou C++.
En C t'a souvent des libs à tout faire, et rien que SDL, t'a des htable, des threads, une gestion du filesystem.
Tu dis que c'est un avantage, mais c'est aussi un inconvénient : surface d'attaque plus grande, réinvention de la roue avec risque de bogues ou de failles en plus.
C'est d'ailleurs le problème en C, le peu d'abstraction offerte oblige à réinventer des structures de données élémentaires tout le temps. Code dupliqué, code moins bien testé, avec des garanties de sécurité ou d'utilisation plus faibles, etc.
Alors oui tu t'épargnes une lib parfois en le faisant à la main, mais tu perds aussi à côté.
Si tu considères que chaque libs maintenues pas une personne différente est un vecteur d'attaque pour des supply-chaines attaques, Rust est juste plus vulnérable.
Cela reste à démontrer.
Tu noteras que les problèmes du C sont connus, bien documentés et malgré tout avec les années on a toujours un taux de faille élevé dans un domaine qui pourrait être réduit à presque zéro dans d'autres langages. Les attaques de supply chain contre Rust ne semblent pas plus élevés en pratique que ce qu'on a connu pour le C ou C++ à ce jour.
Car c'est beau aussi la théorie mais il faut constater en pratique, les soucis de mémoire en C ce n'est pas juste de la théorie, c'est ce qu'on mesure en vrai malgré l'évolution des bonnes pratiques, de l'outillage, etc.
Apparemment il y a des études Suisses sur le sujet qui prennent en compte les déchets et les accidents et qui n'arrivent pas à cette conclusion :
Ton lien dit exactement ce que je dis : le nucléaire a un bilan carbone, sur son cycle de vie complet, similaire au renouvelable. C'est ce dont je parle depuis le début et que Madeiros conteste mais sans jamais appuyer son propos. Moi je veux bien mais toutes les études sérieuses vont dans ce sens à un moment qu'est-ce qu'il veut de plus ?
Cependant ton lien parle des impacts non climatiques, on peut en discuter, le nucléaire n'est pas parfait loin de là. Et même en tenant compte de ça le bilan du nucléaire reste meilleur que le charbon et le gaz pour produire de l'électricité, c'est ce qu'ils disent aussi. Donc là encore cela confirme qu'entre fermer des centrales à charbon ou des centrales nucléaires, faut peut être privilégier la sortie du charbon en premier.
Cargo (ou npm, ou pip), c'est des milliers de comptes de dev potentiellement trouables facilement, et des mises à jour permanentes.
Mais l'écosystème de C et C++ ce sont aussi des milliers de projets différents avec encore plus de développeurs derrière qu'on ne connaît pas.
Sur Debian, le nombre restreint de devs, le fait que pour devenir dev sur Debian, il faut montrer patte blanche, le rythme lent
Mais Debian le tout repose sur des mainteneurs qui génèrent eux mêmes les paquets sur leurs machines, faut s'assurer que leur système ne sont pas non plus attaqués. Ce n'est pas un hasard si Debian a poussé plus que les autres pour la compilation reproductible car c'est une source de vulnérabilité par rapport à des distributions qui génèrent des paquets sur des machines du projet et gérées par une équipe dédiée et compétente.
Bref, des attaques par supply chain tu peux en avoir partout dans ces écosystèmes techniquement, le C n'apporte aucune garantie de ce côté.
Pour contester l'appellation "énergie décarbonée", je ne parle pas de la durée de production mais de la durée de l'ensemble de la chaîne de l'industrie nucléaire.
Cela tombe bien car toutes les études sérieuses se fondent sur l'ensemble de la chaîne de production (de même pour l'éolien, solaire, etc.). La conclusion ne change pas, le nucléaire est sur ce critère au niveau des renouvelables.
Le nucléaire n'étant ni "décarboné" (belle supercherie mode greenwashing si l'on considère l'ensemble de la chaîne)
Plusieurs fois on t'a montré des sources scientifiques sur la question et tu continues d'ignorer. Fais ce que tu veux mais bon je n'ai vu aucun document qui appuyait ton propos.
Suivre le GIEC pour tout ce qu'ils disent mais ignorer leur évaluation carbone de la filière du nucléaire c'est bien du cherry picking bizarre. C'est aberrant.
allemands, comme plusieurs autres pays européens qui investissent massivement dans les énergies écologiques, ont distancé la France.
L'Allemagne a distancé la France sur quel critère ? Leur électricité est plus émettrice de CO2 encore à ce jour que la France ce qui devrait être notre priorité. Alors oui ils ont plus de renouvelable, mais ce n'est pas le seul enjeu.
Et surtout, ce n'est pas tellement de ça dont il s'agit. L'Allemagne aurait préservé son nucléaire tout en investissant dans le renouvelable comme ils l'ont fait, la chute des émissions aurait été spectaculaire. Et comme le Royaume-Uni dans l'intervalle, ils auraient fermé probablement l'ensemble de leurs centrales à charbon depuis (ou presque).
Alors oui, ils progressent, mais c'est dommage de perdre autant de temps pour un problème aussi majeur.
C'est assez facile de dire après coup qu'ils auraient pu garder le nucléaire. S'ils l'avaient gardé et qu'il y ait eu un accident ou des arrêts pour malfaçons on leur aurait reproché l'inverse.
Alors qu'en choisissant de garder le charbon à la place à coup sûr on peut leur reprocher d'avoir fait perdre du temps à une cause majeure de notre siècle.
Le renouvelable c'est justement plus adapté au court terme que le nucléaire vu les délais pour construire. Et de fait aujourd'hui ce sont bien les EnR qui permettent de limiter la casse au plus vite.
Personnellement je leur reproche d'avoir fermé des centrales nucléaires avant les centrales à charbon. Qu'ils ne construisent pas de nouvelles centrales nucléaires me paraît moins problématique. Ils ont perdu une décennie de décarbonation de leur électricité, ce n'est pas rien.
Après voilà le mal est fait et faut construire demain.
Ma comparaison avec npm, c'est car cargo ressemble plus à npm que make, donc ma remarque, c'est que cargo ajoute aussi une surface d'attaque que make n'a pas.
Je ne vois pas trop la différence dans l'absolu. La gestion des dépendance en C et C++ est pénible, avec beaucoup d'étapes manuelles, maintenir à jour la bibliothèque en cas de compilation statique est loin d'être automatique, les attaques sur des dépendances en C ou C++ n'ont pas attendu cargo pour exister dont xz a été la preuve. Et ce n'est pas pour rien que de nombreuses distributions ont investi dans la compilation reproductible pour justement identifier plus facilement si cela arrivait. Cela concerne tous les langages.
En terme de volume les attaques de supply chains restent moins courants que les soucis de mémoire.
Le nombre de vulnérabilités n'est pas forcément une valeur intéressante parce que la base d'utilisation de programme en C, et les enjeux a introduire des portes dérobées sont plus grandes que ceux pour leur équivalent en Rust.
Ce que tu ne comprends pas dans le propos, c'est que si tu prends un programme C donné et que tu le convertis en Rust, statistiquement tu peux réduire de 30% le nombre de failles. Et tu réduis aussi le risque de certains bogues, tu allèges la charge mentale des mainteneurs sur ces questions, etc. À périmètre fonctionnel constant. Ce n'est pas un détail. On ne parle pas de comparer un projet C d'un projet Rust qui n'ont rien à voir car cela n'a pas de sens.
En gros si libc/coreutils/curl devraient se voir remplacer par du rust, on va surement enlevé 29% de faille de sécurités lié à la mémoire, par contre le pourcentage de CVE lier à des attaque par supply chain, il va augmenter, mais vu que des coreutils qui utilise cargos pour build, ça reste quelques chose de marginal aujourd'hui, on ne peu pas prédire l'impact que ça auras.
Sauf que les attaques par supply chain sont malgré tout bien plus rares et concernent aussi les applications C et C++.
Vu que C/C++ son assez vulnérables aux erreurs mémoire, bah c'est la que les gents cherches les vulnérabilités.
Mais ça n'a en fait aucune importance.
Dans un code C ou C++, environ un tiers des failles sont liées à la mémoire en étant évitable en utilisant un langage tel que Rust. C'est ça qui est important. Cela signifie que techniquement un tiers de ces failles (et d'autres bogues par ailleurs) sont aujourd'hui évitables en utilisant un langage qui limite ces risques. ET ces garanties simplifient également le travail de maintenance en identifiant plus tôt les soucis.
On s'en fout pas mal de la comparaison avec JavaScript, Python ou autres car à priori les projets dont on parle ici ne sont pas concernés par de tels langages.
Donc est-ce que Rust est pertinent ? Oui. Est-ce la solution miracle à tous les problèmes ? Non, mais cela ne signifie pas qu'on doit ignorer ses atouts.
Aussi, Rust est tellement vendu comme langage sécurisé par Default, que les développeurs preuves faire moins attentions aux failles de sécurité, en se cachant derrière ce faux sentiment de sécurité qu'offre le langage.
Je ne connais pas de développeurs Rust qui considèrent que Rust est magique et qu'il n'y a pas de soucis de sécurité en l'utilisant.
À dire vrai j'ai plutôt vu le contraire, des développeurs C ou C++ expérimentés qui pensent qu'ils sont à l'abri des problèmes de mémoire car ils codent bien, font attention et sont sérieux. Pourtant de nombreux projets gérés par des personnes compétentes font des erreurs et introduisent des failles que Rust et d'autres outils peuvent identifier…
Je suppose quand même qu'une bonne partie des soucis attribués à une mauvaise gestion de mémoire n'est que la conséquence d'un mauvais choix d'algorithmique, qui est peut-être lui-même la conséquence d'une mauvaise spécification liée à une documentation un peu trop floue.
De mon expérience, non, souvent des races conditions ou des durées de vie ou gestion des objets qui ont été mal respectés.
De toute façon la cause sous-jacente du soucis de mémoire n'a pas une grande importance en l'espèce, si le compilateur peut te dire "attention ici ce n'est pas un comportement valide" tu vas relire et y réfléchir à nouveau avant de trouver une solution et de pousser ça dans le code final. C'est ça qui compte.
Un peu comme les tests automatiques avant de merger des commits, peu importe pourquoi un test est cassé dans le fond, le tout est d'être notifié et de travailler dessus pour régler le problème avant que le code incriminé ne pose des soucis chez quelqu'un.
[^] # Re: Sauf que
Posté par Renault (site web personnel) . En réponse au lien Le lycée sans téléphone portable : impossible ? Voici la solution « très simple » d’un professeur. Évalué à 5 (+2/-0).
En haut, qui ?
[^] # Re: Problème systémique
Posté par Renault (site web personnel) . En réponse au lien Le paradoxe de la génération smartphone. Évalué à 4 (+1/-0).
Je ne suis même pas sûr qu'on puisse dire qu'une génération en particulier a eu un niveau global élevé sur la question.
[^] # Re: relativiser
Posté par Renault (site web personnel) . En réponse au lien Suicide après discussions avec ChatGPT : OpenAI rejette la responsabilité sur le défunt. Évalué à 5 (+2/-0).
Le soucis est également la communication de ces boîtes autour de ces produits.
Ils mettent en avant un outil universel qui aurait le niveau d'un médecin ou d'un chercheur et serait à la frontière de l'intelligence humaine, etc. Et dans les faits c'est comme ça que ces interactions sont perçues par de nombreuses personnes, qui prennent ce que disent ces machines pour argent comptant en permanence. Ils ont retiré d'ailleurs des mises en garde concernant l'usage de ces outils dans un contexte médical.
Donc forcément des gens se sentent libre de s'en servir comme thérapeute ou confidents et comme prévus cela ne donne pas lieu à des résultats problématiques. Et ce n'est pas bon.
Rejeter la faute sur l'utilisateur, en particulier un ado / enfant, c'est cynique. Tu ne peux pas vendre d'un côté ton produit comme extraordinaire capable de 1000 et 1 choses et après dire "oui si on aborde des questions traumatiques ou le suicide ce n'est pas une bonne idée". À un moment tu as des responsabilités, et si ton produit n'est pas assez sûr dans ce genre de contexte il faut clairement le communiquer (et pas juste une ligne cachée dans des CGU que personne ne lit) ou assumer les responsabilités qui incombent. Il y a un manque de recul autour de l'usage de ces produits, ce sont eux qui décident de le survendre, de le mettre partout, et de le rendre disponible de manière large sans grosses restrictions.
C'est trop facile de blâmer l'utilisateur dans ce contexte et de se dédouaner. L'utilisateur n'a pas les moyens de se protéger de cela, personne n'a été formé à utiliser ces outils dans de bonnes conditions, et l'utilisateur est en plus trompé dans la réalité qui entoure ces produits. Ce n'est clairement pas assimilable à un mauvaise usage d'un produit du quotidien type marteau qui aurait été mal utilisé.
[^] # Re: J'aime beaucoup la "perte de productivité"
Posté par Renault (site web personnel) . En réponse au lien Pourquoi la prolongation de vie des appareils électroniques devient un dilemme économique majeur. Évalué à 4 (+1/-0).
Les applications et le systèmes sont plus lourds au gré des MaJ, pour des systèmes bas de gammes cela est un problème pour la durabilité.
[^] # Re: KDE Plasma Desktop Edition
Posté par Renault (site web personnel) . En réponse à la dépêche Sortie de Fedora Linux 43. Évalué à 5 (+2/-0).
Cela a été mentionné.
Le choix des thématiques se base sur la liste fournie par le projet officiel après validation par le FESCO ce qu'on peut voir dans la page suivante : https://fedoraproject.org/wiki/Releases/43/ChangeSet
GNOME est la seule exception à ce jour, car cela reste l'interface de référence, et que chaque version de GNOME est liée à une version unique de Fedora Linux donc le lien est fort. GNOME 49 sera disponible uniquement dans Fedora Linux 43.
Les mainteneurs de KDE Plasma dans Fedora Linux ont fait un choix différent. La version KDE Plasma change au cours d'une version. Ainsi Fedora Linux 42 et 43 utilisent la version 6.5. Alors que Fedora Linux 42 a connu la 6.3 et 6.4 entre temps.
C'est délicat de rédiger ainsi une liste de changements pour KDE Plasma dans ce contexte : quelqu'un qui installera Fedora Linux 43 dans quelques mois aura une version différente, et quelqu'un qui fera la mise à niveau depuis Fedora Linux 42 ne verra pas la différence sur ce point.
[^] # Re: ça peut pas être vrai si ?
Posté par Renault (site web personnel) . En réponse au lien Entre 1946 et 1993, plus de 200 000 fûts de déchets radioactifs ont été enfouis dans l'Atlantique. Évalué à 2 (+2/-3).
Oui enfin là on parle de déchets qui ont plus de 30 ans, ce n'est plus la politique actuelle depuis longtemps. Et ce ne sont pas non plus les déchets à très longue durée de vie qui étaient le sujet de discussion dans l'autre sujet.
De la même façon qu'il ne serait pas raisonnable de critiquer la gestion des déchets plus classiques ou industriels aujourd'hui en se basant sur les pratiques d'il y a 30 ans alors qu'il y a eu d'énormes évolutions entre temps.
[^] # Re: Responsabilité des constructeurs de téléphones mobiles?
Posté par Renault (site web personnel) . En réponse au lien TPG says person dead after failed Triple Zero call. Évalué à 4 (+1/-0).
J'ai déjà vu affiché l'indication "appel d'urgence uniquement" donc j'imagine que c'est possible.
# Pourquoi pas
Posté par Renault (site web personnel) . En réponse au message Seriez-vous preneur de rencontre sur Braine-le-Comte ?. Évalué à 4 (+1/-0).
Je ne suis pas contre rencontrer des libriste en Wallonie ou à Bruxelles, suivant le lieu et ce qu'on y fait je peux essayer de venir plus ou moins régulièrement.
[^] # Re: Responsabilité des constructeurs de téléphones mobiles?
Posté par Renault (site web personnel) . En réponse au lien TPG says person dead after failed Triple Zero call. Évalué à 4 (+1/-0).
On peut regretter que ce genre d'obligations n'arrive que maintenant, mais les faits sont là : ça arrive et ça va avoir de grandes répercutions et pour le mieux dans une industrie qui a été trop longtemps négligente.
Ce que je voulais souligner c'est que les États peuvent contraindre et savent le faire.
[^] # Re: Responsabilité des constructeurs de téléphones mobiles?
Posté par Renault (site web personnel) . En réponse au lien TPG says person dead after failed Triple Zero call. Évalué à 6 (+3/-0).
L'UE oblige à avoir maintenant 5 ans de mise à jour de sécurité après la vente du produit à partir de l'an prochain.
C'est une durée peut être insuffisante mais c'est un début et un vrai changement de mentalité qui concerne par ailleurs toute l'informatique embarquée (et pas que les téléphones).
[^] # Re: "Vulnérabilités"
Posté par Renault (site web personnel) . En réponse au journal Vulnérabilités multiples dans sudo-rs. Évalué à 4 (+1/-0).
Ce que je veux dire c'est que toute application qui manipule des données confidentielles, la bonne pratique c'est de garder en mémoire la dite donnée uniquement le temps nécessaire à son traitement et avant de libérer la mémoire il faut nettoyer cette zone avec des données.
[^] # Re: "Vulnérabilités"
Posté par Renault (site web personnel) . En réponse au journal Vulnérabilités multiples dans sudo-rs. Évalué à 3 (+0/-0). Dernière modification le 19 novembre 2025 à 08:53.
Valable d'ailleurs pour les données cryptographiques type clés privées.
# Un projet de Lennart
Posté par Renault (site web personnel) . En réponse au lien Coup de vieux, quand les jeunes Japonais se posent des questions sur les icônes de logiciels. Évalué à 5 (+2/-0).
Il veut révolutionner les icônes de Linux, encore un coupd de sa part !
[^] # Re: Mais pas sans énergies fossilles
Posté par Renault (site web personnel) . En réponse au lien Allemagne. En octobre 2025, les renouvelables ont couvert 58% des besoins électriques. Évalué à 6 (+4/-1).
Les projets d'enfouissement sont dans l'Hexagone donc je ne vois pas l'intérêt de la remarque.
[^] # Re: Mais pas sans énergies fossilles
Posté par Renault (site web personnel) . En réponse au lien Allemagne. En octobre 2025, les renouvelables ont couvert 58% des besoins électriques. Évalué à 4 (+3/-2).
Reprenons :
1-Ces travaux ne sont pas de l'apanage uniquement des industriels du nucléaire, des universitaires de différentes spécialités font les analyses de cycle de vie, de même que la gestion des déchets du nucléaire ;
2-Les phénomènes climatologiques sont très complexes en vérité car ce sont des système très chaotiques avec de nombreuses inconnues à ce jour, c'est bien moins prévisible que ce qui se passe en profondeur dans le sous sol, le fonctionnement de la radioactivité et la science des matériaux ;
3-Tu n'expliques toujours pas comment une éventuelle fuite des déchets à longue durée de vie, qui causera une pollution locale réelle je ne dis pas le contraire, pourrait remettre en question le bilan carbone du nucléaire alors que la dite fuite ne fait pas d'émissions. Pourtant c'est essentiel pour être en mesure de contredire les bilans annoncés jusqu'ici.
C'est d'ailleurs pour toutes ces raisons que la France décide d'enfouir les déchets plutôt que de les garder en surface comme tu le voudrais : plus stable dans le temps, impact d'une fuite plus faible, moins de risques à cause de phénomènes très variables en surface que ce soit le climat comme les sociétés humaines.
[^] # Re: Mais pas sans énergies fossilles
Posté par Renault (site web personnel) . En réponse au lien Allemagne. En octobre 2025, les renouvelables ont couvert 58% des besoins électriques. Évalué à 6 (+5/-2).
Les déchets seront enfouis d'ici un délai bien plus court et n'y seront plus touchés. Même en admettant un accident dans ce stockage profond, l'impact sera local et ne nécessitera pas d'émettre une quantité astronomique de CO2. Le volume de déchets qui concerne des durée si longues est vraiment réduit au regard de la quantité d'électricité produite. L'impact d'une défaillance n'aurait d'ailleurs rien à voir avec une défaillance avec une centrale en fonctionnement (et pourtant, on a deux retours d'expérience dans ce cas, et on n'a pas émis des milliards de tonnes de CO2 à cause de ça).
C'est assez fort quand même d'affirmer inlassablement que le nucléaire n'est pas décarboné sur cette base alors que toutes les études disent que le nucléaire a des inconvénients mais pas celui-là en tenant compte du cycle de vie complet dont les déchets. Oui il y a des incertitudes, oui il y a des risques (mais on peut dire la même chose du bilan du renouvelable, du charbon, etc.) mais pas de nature à priori de changer significativement le résultat.
Et je trouve toujours curieux d'accepter les rapports concernant le climat, etc. mais refuser d'accepter leurs conclusions concernant le nucléaire dans le même temps. La méthode est la même pourtant.
Mais quel rapport ?
On pourrait d'ailleurs te rétorquer que sur cette base on peut mettre le rapport du GIEC en entier à la poubelle car après tout il y a des incertitudes sur pas mal de phénomènes.
Cela ne me paraît pas être très raisonnable de réfuter leurs analyses de cycle de vie du nucléaire sur cette base sinon on peut refuser toute conclusion scientifique car des incertitudes il y en aura toujours.
La question est de se poser du pire scénario. Admettons que le stockage des déchets à vie longue a une fuite qui contamine une nappe environnante. L'eau est polluée localement. Voilà, comme elle peut l'être avec d'autres phénomènes ou industrie (dont le pétrole et le charbon, par exemple). Est-ce qu'on va devoir dépenser des millions de tonnes de CO2 pour gérer ça ? Non, de la même façon qu'on ne le fait pas pour d'autres contaminations locales qui arrivent pourtant régulièrement. Donc ce n'est pas de nature à priori de changer le bilan climatique du nucléaire de manière significative.
Cela ne me paraît pas très crédible de rejeter ces évaluations nombreuses d'un revers de la main.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par Renault (site web personnel) . En réponse au journal Vulnérabilités multiples dans sudo-rs. Évalué à 5 (+2/-0).
J'ai ri, c'est tellement divers en pratique.
Cela dépend des projets. Puis vu la taille des libs dont tu parles plus haut, cela n'a pas forcément beaucoup de sens de comparer quelques mini libs Rust avec de grosses libs C ou C++.
Tu dis que c'est un avantage, mais c'est aussi un inconvénient : surface d'attaque plus grande, réinvention de la roue avec risque de bogues ou de failles en plus.
C'est d'ailleurs le problème en C, le peu d'abstraction offerte oblige à réinventer des structures de données élémentaires tout le temps. Code dupliqué, code moins bien testé, avec des garanties de sécurité ou d'utilisation plus faibles, etc.
Alors oui tu t'épargnes une lib parfois en le faisant à la main, mais tu perds aussi à côté.
Cela reste à démontrer.
Tu noteras que les problèmes du C sont connus, bien documentés et malgré tout avec les années on a toujours un taux de faille élevé dans un domaine qui pourrait être réduit à presque zéro dans d'autres langages. Les attaques de supply chain contre Rust ne semblent pas plus élevés en pratique que ce qu'on a connu pour le C ou C++ à ce jour.
Car c'est beau aussi la théorie mais il faut constater en pratique, les soucis de mémoire en C ce n'est pas juste de la théorie, c'est ce qu'on mesure en vrai malgré l'évolution des bonnes pratiques, de l'outillage, etc.
[^] # Re: Mais pas sans énergies fossilles
Posté par Renault (site web personnel) . En réponse au lien Allemagne. En octobre 2025, les renouvelables ont couvert 58% des besoins électriques. Évalué à 6 (+4/-1).
Ton lien dit exactement ce que je dis : le nucléaire a un bilan carbone, sur son cycle de vie complet, similaire au renouvelable. C'est ce dont je parle depuis le début et que Madeiros conteste mais sans jamais appuyer son propos. Moi je veux bien mais toutes les études sérieuses vont dans ce sens à un moment qu'est-ce qu'il veut de plus ?
Cependant ton lien parle des impacts non climatiques, on peut en discuter, le nucléaire n'est pas parfait loin de là. Et même en tenant compte de ça le bilan du nucléaire reste meilleur que le charbon et le gaz pour produire de l'électricité, c'est ce qu'ils disent aussi. Donc là encore cela confirme qu'entre fermer des centrales à charbon ou des centrales nucléaires, faut peut être privilégier la sortie du charbon en premier.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par Renault (site web personnel) . En réponse au journal Vulnérabilités multiples dans sudo-rs. Évalué à 5 (+2/-0).
Mais l'écosystème de C et C++ ce sont aussi des milliers de projets différents avec encore plus de développeurs derrière qu'on ne connaît pas.
Mais Debian le tout repose sur des mainteneurs qui génèrent eux mêmes les paquets sur leurs machines, faut s'assurer que leur système ne sont pas non plus attaqués. Ce n'est pas un hasard si Debian a poussé plus que les autres pour la compilation reproductible car c'est une source de vulnérabilité par rapport à des distributions qui génèrent des paquets sur des machines du projet et gérées par une équipe dédiée et compétente.
Bref, des attaques par supply chain tu peux en avoir partout dans ces écosystèmes techniquement, le C n'apporte aucune garantie de ce côté.
[^] # Re: Mais pas sans énergies fossilles
Posté par Renault (site web personnel) . En réponse au lien Allemagne. En octobre 2025, les renouvelables ont couvert 58% des besoins électriques. Évalué à 5 (+3/-1).
Cela tombe bien car toutes les études sérieuses se fondent sur l'ensemble de la chaîne de production (de même pour l'éolien, solaire, etc.). La conclusion ne change pas, le nucléaire est sur ce critère au niveau des renouvelables.
[^] # Re: Mais pas sans énergies fossilles
Posté par Renault (site web personnel) . En réponse au lien Allemagne. En octobre 2025, les renouvelables ont couvert 58% des besoins électriques. Évalué à 6 (+5/-1).
Plusieurs fois on t'a montré des sources scientifiques sur la question et tu continues d'ignorer. Fais ce que tu veux mais bon je n'ai vu aucun document qui appuyait ton propos.
Suivre le GIEC pour tout ce qu'ils disent mais ignorer leur évaluation carbone de la filière du nucléaire c'est bien du cherry picking bizarre. C'est aberrant.
L'Allemagne a distancé la France sur quel critère ? Leur électricité est plus émettrice de CO2 encore à ce jour que la France ce qui devrait être notre priorité. Alors oui ils ont plus de renouvelable, mais ce n'est pas le seul enjeu.
Et surtout, ce n'est pas tellement de ça dont il s'agit. L'Allemagne aurait préservé son nucléaire tout en investissant dans le renouvelable comme ils l'ont fait, la chute des émissions aurait été spectaculaire. Et comme le Royaume-Uni dans l'intervalle, ils auraient fermé probablement l'ensemble de leurs centrales à charbon depuis (ou presque).
Alors oui, ils progressent, mais c'est dommage de perdre autant de temps pour un problème aussi majeur.
[^] # Re: Mais pas sans énergies fossilles
Posté par Renault (site web personnel) . En réponse au lien Allemagne. En octobre 2025, les renouvelables ont couvert 58% des besoins électriques. Évalué à 7 (+6/-2).
Alors qu'en choisissant de garder le charbon à la place à coup sûr on peut leur reprocher d'avoir fait perdre du temps à une cause majeure de notre siècle.
Personnellement je leur reproche d'avoir fermé des centrales nucléaires avant les centrales à charbon. Qu'ils ne construisent pas de nouvelles centrales nucléaires me paraît moins problématique. Ils ont perdu une décennie de décarbonation de leur électricité, ce n'est pas rien.
Après voilà le mal est fait et faut construire demain.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par Renault (site web personnel) . En réponse au journal Vulnérabilités multiples dans sudo-rs. Évalué à 5 (+2/-0).
Je ne vois pas trop la différence dans l'absolu. La gestion des dépendance en C et C++ est pénible, avec beaucoup d'étapes manuelles, maintenir à jour la bibliothèque en cas de compilation statique est loin d'être automatique, les attaques sur des dépendances en C ou C++ n'ont pas attendu cargo pour exister dont xz a été la preuve. Et ce n'est pas pour rien que de nombreuses distributions ont investi dans la compilation reproductible pour justement identifier plus facilement si cela arrivait. Cela concerne tous les langages.
En terme de volume les attaques de supply chains restent moins courants que les soucis de mémoire.
Ce que tu ne comprends pas dans le propos, c'est que si tu prends un programme C donné et que tu le convertis en Rust, statistiquement tu peux réduire de 30% le nombre de failles. Et tu réduis aussi le risque de certains bogues, tu allèges la charge mentale des mainteneurs sur ces questions, etc. À périmètre fonctionnel constant. Ce n'est pas un détail. On ne parle pas de comparer un projet C d'un projet Rust qui n'ont rien à voir car cela n'a pas de sens.
Sauf que les attaques par supply chain sont malgré tout bien plus rares et concernent aussi les applications C et C++.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par Renault (site web personnel) . En réponse au journal Vulnérabilités multiples dans sudo-rs. Évalué à 9 (+6/-0).
Mais ça n'a en fait aucune importance.
Dans un code C ou C++, environ un tiers des failles sont liées à la mémoire en étant évitable en utilisant un langage tel que Rust. C'est ça qui est important. Cela signifie que techniquement un tiers de ces failles (et d'autres bogues par ailleurs) sont aujourd'hui évitables en utilisant un langage qui limite ces risques. ET ces garanties simplifient également le travail de maintenance en identifiant plus tôt les soucis.
On s'en fout pas mal de la comparaison avec JavaScript, Python ou autres car à priori les projets dont on parle ici ne sont pas concernés par de tels langages.
Donc est-ce que Rust est pertinent ? Oui. Est-ce la solution miracle à tous les problèmes ? Non, mais cela ne signifie pas qu'on doit ignorer ses atouts.
Je ne connais pas de développeurs Rust qui considèrent que Rust est magique et qu'il n'y a pas de soucis de sécurité en l'utilisant.
À dire vrai j'ai plutôt vu le contraire, des développeurs C ou C++ expérimentés qui pensent qu'ils sont à l'abri des problèmes de mémoire car ils codent bien, font attention et sont sérieux. Pourtant de nombreux projets gérés par des personnes compétentes font des erreurs et introduisent des failles que Rust et d'autres outils peuvent identifier…
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par Renault (site web personnel) . En réponse au journal Vulnérabilités multiples dans sudo-rs. Évalué à 10 (+8/-0).
De mon expérience, non, souvent des races conditions ou des durées de vie ou gestion des objets qui ont été mal respectés.
De toute façon la cause sous-jacente du soucis de mémoire n'a pas une grande importance en l'espèce, si le compilateur peut te dire "attention ici ce n'est pas un comportement valide" tu vas relire et y réfléchir à nouveau avant de trouver une solution et de pousser ça dans le code final. C'est ça qui compte.
Un peu comme les tests automatiques avant de merger des commits, peu importe pourquoi un test est cassé dans le fond, le tout est d'être notifié et de travailler dessus pour régler le problème avant que le code incriminé ne pose des soucis chez quelqu'un.