Renault a écrit 7595 commentaires

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.

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.

Il y a deux contraintes :

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

j'ai vécu à Genève merci je connais mais c'est tellement mineure comme préoccupation

C'est mineur car le problème n'existe pas aujourd'hui : Genève et la France sont toute l'année à la même heure.

négligeable à l'échelle des pays concernés

À l'échelle européenne cela concerne quelques millions d'habitants, certes ce n'est pas fondamental mais cela ne me semble pas être négligeable non plus.

La question est : étant donné qu'il y a une problématique réelle, est-ce qu'il est nécessaire de se précipiter pour abolir le changement d'heure ? Je ne pense pas, malgré ses défauts on est habitué aussi et ça tourne. On peut prendre le temps de prendre des décisions et se concerter un minimum.

si seule une poignée de pays ne veulent pas abandonner le changement d'heure.

Mais c'est ça le truc, aucun État ne semble opposé à y mettre fin, mais tout le monde a constaté que les préférences des pays pour l'heure finale à adopter était chaotique et qu'il y aurait quelques difficultés si on ne se concerte pas.

Le moyen simple serait de dire tout le monde à l'heure d'hiver et après chacun adapte ses habitudes s'ils veulent un ciel éclairé longtemps après la journée de travail classique en été.

Ça me semble bancale quand tu sais que déjà on a le même fuseau horaire de Finisterre tout à l'est de l'Espagne jusqu'à Sokółka en Pologne à plus de 3000km de route.

Personnellement je ne vois pas le problème dans l'absolu.

Alors que Portugal et Espagne n'ont pas la même heure et les frontaliers se portent très bien de la situation. Où même entre l'Espagne et les Îles Canaries, la France métropolitaine et les DOM-TOMs ses colonies.

On ne parle pas de la même chose.
Quand je regarde la frontière hispano-portugaise, je ne vois pas de grandes villes à cheval sur une frontière. C'est-à-dire une ville où de manière significative des habitants vivent dans un pays différent tout en étant partie d'une agglomération située dans une autre et que du coup franchir la frontière se fait très régulièrement et plusieurs fois dans la journée.

En France tu as à minima Lille et Strasbourg dans cette situation, en Suisse tu as Genève et Bâle, la proximité de Vienne et Bratislava est également ridiculement faible, aux Pays-Bas tu as Maastricht, le cas Luxembourgeois peut se discuter, tu as aussi la relation Copenhague - Malmo entre le Danemark et la Suède, etc.

C'est aussi ce qui a motivé la mise en place de Schengen ce qui a décuplé ce phénomène car franchir la frontière n'est plus un obstacle.

La problématique de ces villes (et il y en a potentiellement d'autres) n'a rien à voir avec ce que tu décris. Quand tu vas dans les DOM-TOMs, tu prends l'avion, tu n'y accèdes pas en traversant une rue. Pareil pour les ïles Canaries. La quantité de gens qui font des déplacements réguliers entre ces territoires est également bien plus faible.

De la même façon d'ailleurs que malgré des liaisons courantes entre Paris et Londres, il faut utiliser un moyen de transport lourd et relativement long pour changer de fuseau horaire, la distinction est nette entre les deux territoires.

Bref, tout cela pour dire que les villes dont je parle ont des caractéristiques propres, qui ont été encouragé par l'UE et qui ne sont pas des détails à régler. Et ce sont des situations qui existent depuis 30 ans à plein régime, mais même depuis la 2e GM car le fuseau horaire est stable depuis.

Changer le fuseau horaire pour ces territoires ne doit pas s'improviser.

Que les changements d'heures aient lieu en même temps s'ils ont lieu, soit, ça a un peu de sens. Que tout le monde soit dans le même fuseau, bof. Quand je travaillais avec des équipes aux USA et en Inde + quelques collègues en Australie je m'en accomodais, Ça concentrais beaucoup de réunions entre 14 et 17h mais à mon sens c'était mieux que d'être convoqué presque toute la journée entre 9 et 18h au moins j'avais du temps pour être concentré sur un sujet précis.

Tu compares des situations de travail à distance alors qu'ici je te parle de situations physiques. Quand tu peux franchir la frontière régulièrement (je veux dire, pour certains c'est plusieurs fois par jour) pour différents services l'impact n'est pas le même.

Mais par contre je ne vois pas pourquoi, si l'Espagne veut changer d'heure, elle aurait besoin que ça se fasse au niveau européen.

Car c'est géré au niveau européen pour uniformiser les pratiques et cela a du sens pour éviter pas mal de problèmes.
Surtout qu'il y a au niveau européen beaucoup de villes transfrontalières avec des gens qui vivent et travaillent dans des pays différents. Si tu ajoutes des différences de fuseaux horaires dans ces villes là c'est rapidement compliqué de s'y retrouver.

Alors peut être que l'Espagne n'est pas concernée par ce genre de problématiques transfrontalières mais pour beaucoup d'autres pays cela mérite une attention. D'où le fait d'ailleurs que le dossier n'a pas beaucoup avancé, les États sont d'accords globalement pour mettre fin à ce mécanisme mais il y a de fortes divergences sur l'heure légale à retenir État par État (ce qui est un peu idiot car on pourrait juste changer les habitudes si on souhaite un soleil "tardif" en été). Et à cause des éléments indiqués, introduire un écart horaire avec un pays voisin qui a été quasiment tout le temps pour les personnes vivantes aujourd'hui, ce n'est pas anodin.

proche de quoi ? D'un panier moyen, non ?

C'est ce que je dis.

Dont la composition n'est pas publique, me semble-t-il ?

On a quelques éléments mais pas tout effectivement. Cependant l'objectif étant d'être représentatif de l'inflation dans la mesure du produit, mesurer l'évolution du prix d'une Porsche 911 n'a pas beaucoup d'intérêt.

Ce serait bien plus intéressant pour le débat public et représentatif des réalités vécues de produire un suivi de l'inflation par déciles ou duodéciles de revenus et de richesse.

Je ne comprends pas ce que tu veux comme indicateur. L'objectif est de mesurer l'évolution des coûts, pas des revenus avec cet indicateur.

Après si tu veux avoir une représentation réaliste de la pauvreté ou du pouvoir d'achat un indicateur seul ne suffira de toute façon pas comme pour toute mesure complexe. Car l'inflation mesurée a aussi des nombreuses limites :

• L'inflation prend en compte l'évolution technique, en gros si le produit type téléphone portable coûte plus cher mais qu'il est plus performant, son impact dans l'inflation est moindre que si le modèle était strictement identique ;
• L'inflation n'est pas uniforme sur les produits, donc l'inflation mesurée ne correspondra pas forcément à l'inflation ressentie par ceux qui achètent des produits relativement éloignés du panier moyen ;
• L'inflation ne touche pas de manière uniforme selon le revenu, car de fait la composition de tes dépenses moyennes dépend de tes revenus ;
• L'inflation n'est pas uniforme dans l'espace, elle peut progresser plus vite dans certaines régions de France que d'autres pour diverses raisons (coût du transport pour acheminer les produits, faible concurrence localement, taxation locale différente, production locale du produit, etc.).

Mais des limites comme ça tu en auras pour chaque indicateur qui suivra les revenus ou la pauvreté à l'échelon national de manière globale.

Tu as plusieurs définition de taux de pauvreté ou de manière de l'aborder, tu peux l'aborder grossièrement à partir d'un seuil basé sur le revenu médian, tu peux l'aborder aussi par le revenu restant après dépenses obligatoires, ou encore par la faculté à payer certaines factures obligatoires ou imprévues dans les délais et sans crédits, etc.

Il faut mixer tout ça si tu veux voir la situation et son évolution, mais c'est plus complexe et difficile à mettre en place. En tout cas on ne manque pas de données à ce sujet il me semble si ça t'intéresse vraiment.

Quand l'Insee mesure l'inflation, elle mesure une information macroéconomique pour décideurs menant grand train. Quand le pékin de base parle d'inflation, il s'agit plutôt d'une information microéconomique. D'où le désaccord qui me semble bien moins une affaire de ressenti qu'une discordance sémantique.

Cela montre surtout qu'un indicateur unique ne peut pas représenter la situation individuelle de tout le monde. Cela ne signifie pas que l'inflation telle que mesurée par l'INSEE n'a aucune valeur ni aucun sens. Mais on ne peut pas conclure grand chose avec uniquement cette information mais cela donne un indice sur pas mal de choses.

Par ailleurs, mesurer l'inflation individuellement est aussi délicat. La mémoire humaine n'est pas infaillible et une liste de chiffres de prix dans le temps ce n'est pas vraiment notre point fort. Les individus peuvent probablement constater des évolutions de prix, avoir une idée précise pour certains produits car ils les achètent souvent mais ce sera flou pour beaucoup d'autres produits à moins qu'ils conservent et comparent les factures.

Tu peux aussi avoir des biais de perception, le prix de la baguette que tu achètes tous les jours qui augmente de 10 centimes tu le verras et ça te marquera un moment, mais l'impact de cette inflation dans le budget du ménage sera très faible alors qu'un budget plus important mais fluctuant ou invisible (car prélevé automatiquement par exemple) ne sera pas perçu de la même façon.

Il n'y a pas de mesure miracle pour résoudre cette discordances, si ce n'est publier et analyser un maximum d'indicateur en gardant à l'esprit que les situations individuelles seront forcément différentes.

D'où l'importance de la composition du panier moyen utilisé comme étalon qui est plus proche d'une consommation des services de base que celui de quelqu'un qui se paye une Porsche.

Il y a beaucoup à redire sur le calcul de l'inflation qui sera forcément imparfait (prendre en compte l'évolution des produits, choix des produits considérés, etc.) mais heureusement il n'est pas influencé par des produits de luxe car ces produits ne sont pas considérés du tout.

Globalement les algos pertinents sur de telles machines sont ceux massivement parallélisables donc plein de petits calculs similaires en parallèle car justement les données en entrée peuvent être rassemblées dans un état quantique unique ce qui permet de réduire le nombre d'opérations nécessaires.

Tout ce qui tourne sur un GPU (et donc l'IA) est un bon candidat potentiel pour un tel usage car justement c'est le point fort d'un GPU face aux CPU.

Après cela ne signifie pas que c'est facilement transposable malgré tout, faut revoir le fonctionnement derrière et il y a d'autres contraintes. Mais l'IA serait justement un sujet sans doute investigué dans ce contexte.

La vérité est qu'on en sait probablement rien.

Oui il y a des défis non négligeables à surmonter avant d'avoir des ordinateurs quantiques capables de faire des tâches qu'une machine classique ne peut pas faire. Et même si cela arrive un jour, cela sera certainement pour certaines tâches spécifiques et pas à la disposition de tout à chacun car les contraintes de fonctionnement seront probablement importantes.

Mais les progrès sont aussi réels et il n'est pas impossible que les derniers obstacles seront résolus. Pas demain, mais dans une ou plusieurs décennies cela n'a rien d'aberrant à envisager.

Dans le contexte de la sécurité des échanges, où certains messages doivent rester confidentiels même dans 30 ans pour des raisons d'État ou de vie privée, et que le coeur même de la sécurité informatique en dépend et nécessite beaucoup de temps pour s'adapter, tenter d'anticiper en développant des solutions qui résistent aux capacités de ces machines ne me semble pas être de l'excès de zèle.

Par contre il y a aussi des doutes concernant l'efficacité des dits algorithmes alternatifs aussi. Ce n'est pas une mince affaire.

Tu peux en donnant les bonnes options à GRUB à priori : https://discussion.fedoraproject.org/t/how-to-change-layout-in-luks-passphrase/145687

Ce n'est pas très simple pour l'utilisateur néophyte, et je pense en effet que de fournir la solution idéale n'est pas triviale bien que techniquement possible.

De toute façon un rendement brut sur ces questions n'est en réalité même pas très important.

Que les éoliennes convertissent mieux l'énergie du vent en électricité que le nucléaire par rapport à l'énergie de fission des atomes d'uranium ou même l'inverse n'est pas pertinent. Même en considérant toute la chaine de production. Tant que l'énergie injectée pour produire ces engins est inférieure à ce qu'on retire sur la durée de vie de ces installations c'est OK de ce point de vue.

La critique initiale portait que globalement le stockage de l'électricité a un rendement faible quelque soit la techno retenue. Le renouvelable intermittent en a besoin si on souhaite un scénario où ils sont prédominants dans le paysage énergétiques. Sauf que le rendement du stockage est faible ce qui implique qu'on doit surdimensionner la production de renouvelable pour être capable de stocker et restituer suffisamment d'énergie au moment opportun. Et ce n'est pas un petit défi et à ce jour aucun système électrique global n'a un tel système de stockage de manière significative. Et qu'on doit tenir compte de ce stockage quand on prend en compte les impacts et les coûts évidemment.

Cela n'est cependant pas impossible non plus à priori.