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.
À un moment donné faut arrêter de considérer la gestion mémoire comme le problème principal des failles de sécurité. Oui c'en est une mais on peut faire des conneries dans tous les langages.
C'est quand même 33% des failles de sécurité rapportées. Ce n'est pas un détail et je ne crois pas qu'une classe d'erreur passe devant en fait.
Cela ne résout pas tout mais élimine une bonne partie du problème.
N'oublions pas que les serveurs du monde tournent toujours sur un noyau entièrement codé en C, comme quoi c'est possible.
Cela ne veut pas dire qu'on ne peut pas faire mieux. ;)
Ne pas oublier outre les bogues en eux même, limiter ces erreurs c'est aussi une charge mentale et un effort de maintenance à faire.
Jusqu'à preuve du contraire, le progrès humain s'est toujours construit sur des structures stables, donc des États-nations.
De nombreux pays ne sont pas des États nations et sont pourtant stables depuis longtemps. D'ailleurs la notion est tellement flou que selon le point de vue certains États peuvent l'être ou pas à la foi. Par exemple il y a des arguments pour mettre le Royaume-Uni dans cette catégorie, mais des arguments pour le contester. Situation qui dure depuis des siècles tout de même.
Puis on a des contre exemples de toute façon. La Renaissance qui est une période de grandes avancées scientifiques comme culturelles en Europe a émergé en parti du St Empire Romaine Germanique et du nord de l'Italie, très loin d'être des États nation à cette époque. Et les États nation ont aussi été à l'origine des deux conflits mondiaux en partie, car il y avait volonté d'inclure les territoires que ces États estimaient devoir obtenir, en terme de stabilité et de progrès on a vu mieux aussi.
C'est quand même curieux de faire de telles généralités sur la base d'une notion aussi floue et contestée.
Après c'est peut être également lié au fait que l'on ait un population plus âgée.
Ou qu'on a aussi une autre vision du monde. L'Europe n'a pas la même culture que les USA sur de nombreux points et j'ai envie de dire tant mieux.
Personnellement je ne suis pas convaincu que la préoccupation des USA sur les sujets que tu cites soit les priorités qu'ils devraient avoir, ni que la réponse qu'ils apportent à ces problèmes soit également la bonne.
Ha bon parce que l’Égypte antique n'était pas un état-nation ? Les cité états de Mésopotamie ? Rome avant l'Empire ?
Plus récemment, la France n'est elle pas un état nation depuis l'avènement des Capétiens (en particulier Philippe Auguste) ?
L'Angleterre depuis les Plantagenêt ? La Chine, La Rus' de Kiev ? etc…
Sur quels critères au Moyen-Âge l'Angleterre comme la France seraient déjà des États nations ? Cela n'a pas beaucoup de sens.
Ce sont des territoires contrôlés essentiellement par un régime, mais avec une grande diversité culturelle et des changements d'ailleurs d'allégeances très réguliers par endroit car cela se faisait par la force. Les peuples concernés n'étaient pas vraiment consultés et avec les moyens de l'époque n'avaient pas non plus un grand loisir de connaître la culture et de partager quoique ce soit avec des gens à l'autre bout du pays dont ils ignoraient probablement l'existence. La grande partie de la population était soumise à son seigneur local et ils formaient des communautés qui étaient essentiellement locales. La diversité de langues en témoigne en France, qui a commencé à réellement régresser durant le XIXe siècle et pas avant.
L'émergence d'une nation est un processus très lent et n'a probablement pas de sens très large avant la Révolution française en Europe. Seuls quelques territoires pourraient avoir localement une notion de nation mais qui ne s'appliqueraient pas à l'ensemble d'un tel territoire comme la France ou l'Angleterre.
Le jour où ce sera un problème je pense que la MaJ va juste échouer faute d'espace disponible.
De toute façon ce problème est globalement hypothétique pour un futur raisonnablement lointain selon la config. Sur ma Fedora par exemple je n'utilise pas plus de 500 Mio encore. Mais cela dépend des pilotes nécessaires à chaque machine.
Il y a des pays relativement isolés par choix (Russie et Chine entre autres) avec des interconnexions limitées et contrôlées par l'État central ce qui permet un filtrage au niveau étatique et donc techniquement la possibilité de tout couper s'ils le souhaitent.
D'autres qui le sont aussi mais probablement pour des raisons économiques, pas assez de besoin et de budget pour investir dans cela.
Aux USA et en Europe c'est une autre équation par exemple, les interconnexions sont très nombreuses et souvent gérées par plusieurs acteurs différents. S'isoler des autres pays ou de certains services est donc plus difficile.
Microsoft refuse d'installer Windows 11 sur des processeurs plus anciens même s'ils font tourner Windows 10 sans problème. La liste de compatibilité est connue mais son établissement est opaque, pour quelles raisons certains processeurs sont compatibles et d'autres pas.
Microsoft oblige la présence d'un composant de sécurité nommé TPM 2.0, il a été généralisé il y a quelques années mais pour les modèles plus anciens ce n'est pas le cas. Il existe une possibilité d'ajouter la puce après coup dans certains cas, en particulier pour des ordinateurs fixes. À la base Windows 11 devait en tirer parti pour améliorer sa sécurité d'où l'obligation de sa présence mais de nombreuses personnes arrivent à le faire fonctionner sans, donc peut être que ce n'est pas si fondamental qu'indiqué à l'époque.
[^] # 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é à 5 (+3/-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é à 3 (+2/-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é à 5 (+4/-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.
[^] # 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é à 8 (+6/-1).
C'est quand même 33% des failles de sécurité rapportées. Ce n'est pas un détail et je ne crois pas qu'une classe d'erreur passe devant en fait.
Cela ne résout pas tout mais élimine une bonne partie du problème.
Cela ne veut pas dire qu'on ne peut pas faire mieux. ;)
Ne pas oublier outre les bogues en eux même, limiter ces erreurs c'est aussi une charge mentale et un effort de maintenance à faire.
[^] # Re: Après le jour, la nuit ; après la pluie, le beau temps
Posté par Renault (site web personnel) . En réponse au lien L’hyperstition, un concept au cœur de la vision de Nick Land, idéologue des Lumières sombres. Évalué à 6 (+3/-0).
De nombreux pays ne sont pas des États nations et sont pourtant stables depuis longtemps. D'ailleurs la notion est tellement flou que selon le point de vue certains États peuvent l'être ou pas à la foi. Par exemple il y a des arguments pour mettre le Royaume-Uni dans cette catégorie, mais des arguments pour le contester. Situation qui dure depuis des siècles tout de même.
Puis on a des contre exemples de toute façon. La Renaissance qui est une période de grandes avancées scientifiques comme culturelles en Europe a émergé en parti du St Empire Romaine Germanique et du nord de l'Italie, très loin d'être des États nation à cette époque. Et les États nation ont aussi été à l'origine des deux conflits mondiaux en partie, car il y avait volonté d'inclure les territoires que ces États estimaient devoir obtenir, en terme de stabilité et de progrès on a vu mieux aussi.
C'est quand même curieux de faire de telles généralités sur la base d'une notion aussi floue et contestée.
Ou qu'on a aussi une autre vision du monde. L'Europe n'a pas la même culture que les USA sur de nombreux points et j'ai envie de dire tant mieux.
Personnellement je ne suis pas convaincu que la préoccupation des USA sur les sujets que tu cites soit les priorités qu'ils devraient avoir, ni que la réponse qu'ils apportent à ces problèmes soit également la bonne.
[^] # Re: Après le jour, la nuit ; après la pluie, le beau temps
Posté par Renault (site web personnel) . En réponse au lien L’hyperstition, un concept au cœur de la vision de Nick Land, idéologue des Lumières sombres. Évalué à 6 (+3/-0).
Sur quels critères au Moyen-Âge l'Angleterre comme la France seraient déjà des États nations ? Cela n'a pas beaucoup de sens.
Ce sont des territoires contrôlés essentiellement par un régime, mais avec une grande diversité culturelle et des changements d'ailleurs d'allégeances très réguliers par endroit car cela se faisait par la force. Les peuples concernés n'étaient pas vraiment consultés et avec les moyens de l'époque n'avaient pas non plus un grand loisir de connaître la culture et de partager quoique ce soit avec des gens à l'autre bout du pays dont ils ignoraient probablement l'existence. La grande partie de la population était soumise à son seigneur local et ils formaient des communautés qui étaient essentiellement locales. La diversité de langues en témoigne en France, qui a commencé à réellement régresser durant le XIXe siècle et pas avant.
L'émergence d'une nation est un processus très lent et n'a probablement pas de sens très large avant la Révolution française en Europe. Seuls quelques territoires pourraient avoir localement une notion de nation mais qui ne s'appliqueraient pas à l'ensemble d'un tel territoire comme la France ou l'Angleterre.
[^] # Re: /boot
Posté par Renault (site web personnel) . En réponse à la dépêche Sortie de Fedora Linux 43. Évalué à 6 (+3/-0).
Le jour où ce sera un problème je pense que la MaJ va juste échouer faute d'espace disponible.
De toute façon ce problème est globalement hypothétique pour un futur raisonnablement lointain selon la config. Sur ma Fedora par exemple je n'utilise pas plus de 500 Mio encore. Mais cela dépend des pilotes nécessaires à chaque machine.
[^] # Re: Non
Posté par Renault (site web personnel) . En réponse au lien "Est-ce que Internet pourrait être déconnecté ?" Le monde moderne repose sur un château de cartes. Évalué à 5 (+2/-0).
Les pays ne sont pas comparables sur ce point.
Il y a des pays relativement isolés par choix (Russie et Chine entre autres) avec des interconnexions limitées et contrôlées par l'État central ce qui permet un filtrage au niveau étatique et donc techniquement la possibilité de tout couper s'ils le souhaitent.
D'autres qui le sont aussi mais probablement pour des raisons économiques, pas assez de besoin et de budget pour investir dans cela.
Aux USA et en Europe c'est une autre équation par exemple, les interconnexions sont très nombreuses et souvent gérées par plusieurs acteurs différents. S'isoler des autres pays ou de certains services est donc plus difficile.
[^] # Re: Windows 11, pourquoi ?
Posté par Renault (site web personnel) . En réponse à la dépêche Revue de presse de l’April pour la semaine 42 de l’année 2025. Évalué à 9 (+6/-0).
Il y a deux contraintes :