Euh tu sais que la configuration de NetworkManager que tu l'édites à la main, que tu utilises la GUI de GNOME ou nmcli cela revient au même ? Les fichiers sont stockés au même endroit et de la même façon, la conf est identique… Et heureusement, ce ne sont que des interfaces utilisateurs différents, le reste de l'outil est le même.
Notons que la TV en direct utilise du multicast pour être distribué sur le territoire national. C'est bien moins coûteux et gourmand que des flux individuels pour la même qualité d'image.
Écrire un algo en pseudo code ne me semble pas très pertinent dans un cadre pro. Dans un contexte scolaire je pense que ça peut avoir du sens car tu apprends.
Par contre faire la conception sur papier, poser les idées, passer du temps à réfléchir dessus, etc. cela a du sens dans un contexte pro. Après chacun son outil mais je trouve la papier pratique pour cela.
Je trouve, oui. En quoi ça ne serait pas pertinent selon toi ?
Je veux dire, tout le monde ne connaît pas le sujet, l'article est assez trompeur sur les capacités (je trouve), le manque de recul sur l'IA est assez important en ce moment dans l'esprit de beaucoup de gens, rappeler concrètement les limites ne me paraît pas inutile.
Peut être, cela n'est cependant pas trivial et ne peut être déduit avec ce qui a été publié.
Mon propos n'est pas de dire que l'approche ne mènera à rien dans tous les cas. Je dis juste que ce qui est présenté pour l'instant ne montre rien de si extraordinaire pour justifier un article aussi dithyrambique.
C'est une preuve de concept, faut creuser la question et pourquoi pas, ça peut donner des résultats intéressants (ou pas).
C'est un peu comme lire les articles scientifiques de certains présentant des nouveaux matériaux ou traitements médicaux révolutionnaires alors qu'en vrai la plupart n'iront pas plus loin que le labo où la découverte a été publié car finalement c'était une mauvaise piste. Ce n'est pas un mal de communiquer dessus mais je trouve la forme souvent excessive.
Après c'est Korben, ce n'est pas la première fois qu'il fait ça et typiquement je ne le lis pas pour cette raison.
Perso je suis moyennement convaincu, l'article de Korben semble très pute à clic.
Ce n'est pas inintéressant mais franchement limité à ce stade. De ce qu'on peut en lire (car honnêtement je ne trouve pas que le dépôt apporte beaucoup d'infos sur l'entrainement et les tests). Cela semble travailler sur des fonctions apparemment isolées et relativement triviales (en tout cas, pas d'exemples montrant le contraire), le résultat est déjà obtenu par des outils plus classiques (décompiler du binaire en instruction C avec peu de valeur ajoutée n'a rien d'extraordinairement difficile). Le seul ajout est celui de tests automatiques mais le taux d'échecs même dans un cas simple est encore très faible.
Alors oui, c'est le début, mais c'est encore la partie simple : le modèle arrivera-t-il à fonctionner sur un programme entier à apporter de la valeur ajoutée comme ça ? Pas sûr non plus. Ce n'est en tout cas pas à ce stade une révolution mais plus une preuve de concept à creuser.
Ce raisonnement dépend de la structure de l'empreinte des coûts environnementaux comme financiers.
Une infrastructure télécom ce sont beaucoup de coûts fixes, c'est même l'essentiel du prix de la facture. Que tu consommes ou pas tes données, le coût financier et environnemental sera proche. Car il faut maintenir l'infrastructure, les antennes relais, les bornes de distributions, les serveurs, etc.
D'ailleurs cela se voit bien, quand des offres illimités sont apparus, ils étaient rarement dans les prix haut de gammes des forfaits limités de l'époque. Et aujourd'hui un forfait à 100 Gio en France pour mobile est significativement moins cher que pour la plupart des pays voisin avec des quotas pourtant bien plus bas.
Pour l'illimité au moins tu ne te poses pas la question, ce mois ci tu consommes plus pour X ou Y raison, aucun problème. Cela a aussi un coût mental de se préoccuper de savoir si on a de quoi tenir le mois, s'il faut acheter plus de data exceptionnellement, si on doit réduire significativement son usage car on ne veut pas payer plus, etc.
Bah non, si du moins l'outil qui parse ces déclarations n'en est pas une.
Ce qui est pertinent c'est de considérer la conception et maintenance plus que l'exécution, une IA reste un programme comme un autre à la fin, la différence se situe en amont lors de son élaboration.
La conception fait que l'algo exécutée par l'IA n'est à priori pas connu dans le détail par ses concepteurs et utilisateurs (sinon autant écrire l'algo directement à la main, c'est plus fiable et efficace). L'algo est élaborée de manière dynamique en fonction de comment il a été entrainé et des tâches qu'il doit mener.
Cela rend aussi la maintenance délicate, difficile d'apporter des garanties fortes de fonctionnement car le détail de l'algo n'est pas connu, et corriger des défauts à la main est difficile (un peu comme altérer un binaire sans le code source, c'est faisable mais délicat). Il faut probablement ajouter des éléments lors de la conception et entrainement en croisant les doigts que cela règle le problème sans en introduire d'autres.
Le HTML ou autres type de documents déclaratifs ne sont pas forcément de la programmation d'une part, et d'autres part le moteur de rendu est un algo conçu et éditable à la main.
Une personne centenaire peut partager le même numéro de sécurité sociale qu'une personne récemment née.
Cela pourrait arriver aussi si un département a beaucoup trop de naissance le même jour (je doute que ce soit déjà arrivé et si cela risque d'arriver).
Si tu demande à brûle pourpoint un avis à ChatGPT sur un sujet plus ou moins lié à la politique, il n'est jamais catégorique (hors hallucinations possible, mais ça ne m'a pas l'air d'être le cas).
J'ai vu assez d'exemples qui montraient qu'il était capable de tout, surtout suivant comment tu le prépares.
C'est tout le problème de ces systèmes, avoir des garanties de fonctionnement est difficile (si ce n'est impossible).
Oui, c'est bien pour ça que j'écarte cette hypothèse.
Ce n'était pas clair si tu l'écartais pour cette raison ou parce que tu souhaitais plutôt évaluer les autres hypothèses.
Evidemment. Par contre, c'est l'absence de nuances dans la réponse que m'interroge.
Des réponses non nuancées des LLM ce n'est pas le plus dur à obtenir à priori. Et c'est d'ailleurs une partie du problème.
J'ai pas l'impression que tu ais compris le sens de mes propos.
Honnêtement tes interrogations semblaient plus génériques que cela donc effectivement je n'avais pas compris où tu voulais en venir.
J'ai sans doute un biais à analyser ta réponse ainsi car des gens qui utilisent des LLM pour tout et n'importe quoi sans recul bah j'en croise un peu trop et je trouve cela problématique à plus d'un titre. Donc mes excuses pour ce biais d'interprétation.
Je trouve la réponse de ChatGPT assez étonnante, généralement les llms ne sont pas aussi catégorique
Tu trouves ?
ont souvent des réponses de type thèse / antithèse / synthèse ou avantage / inconvénient / résumé.
Tout dépend du prompt et du sujet, tu as de tout.
Si on écarte l'idée d'une déduction logique de la part du modèle
Un LLM ne fait pas vraiment de déduction logique de ce style.
Un biais induit par les développeurs dans les données d'apprentissage sur ce sujet.
Il me semble assez improbable de croire que des données d'entrainement soit sans biais tout court. Il y a forcément une sélection et un biais introduit à cette étape même si ce n'est pas conscient.
J'espère que c'est la deuxième hypothèse parce que dans le cas contraire on est vraiment dans la merde
Perso je pense surtout qu'il faut se rappeler des limites de ces technos et d'arrêter de les utiliser comme si elles n'en avaient pas. Cela peut rendre des services mais il faut avoir un regard critique quant aux réponses données.
Oui Red Hat a soutenu CentOS longtemps (si ce n’est de tout temps) financièrement et « humainement », mais en laissant toute liberté à CentOS. Red Hat a acquis CentOS (la marque) et embauché le board de CentOS en 2014 seulement.
Cela fait quand même 10 ans, c'est énorme.
Elle était 100% identique au niveau du code source open-source et uniquement à ce niveau.
Cela se discute que c'était 100% identique, mais je vais revenir après là dessus.
Quant au fait que tu trouves ma formulation imparfaite, ambigu voire fallacieuse. Merci d’expliquer en quoi. Tu n’as fait que répondre à côté de la plaque pour défendre Red Hat là. Pour moi comme pour beaucoup un « rebuild » n’est pas un dérivé.
Un rebuild est par définition un dérivé car ce n'est pas une copie parfaite, je vais l'expliquer en quoi.
Par ailleurs tu viens de le dire enfin que pour toi un rebuild n'est pas un dérivé de ton point de vue. Ce n'était pas explicité dans tes précédents messages donc oui c'était cryptique comme point de vue sans ce rappel de vocabulaire (de ton point de vue car personnellement je ne suis pas d'accord).
Tu n’as clairement pas compris mon message. Ce que je reproche à Red Hat c’est d’avoir saboté « CentOS » (ie: CentOS tout court) en réutilisant le nom pour une distribution qui n’a plus rien à voir, mais fondamentalement plus rien à voir, en terme d’architecture et de destinations. Ils auraient pu créer un nouveau nom, un nouveau logo. Et s’ils ont réutilisé "CentOS" c’est clairement pour sa réputation et uniquement pour cela. Ils ne pouvaient ignorer la confusion.
Honnêtement des produits ou marques qui évoluent dans leur cibles ou caractéristiques principales tout en gardant le même nom pour des raisons commerciales ça arrive tous les jours. Que Red Hat le fasse ne me choque pas le moins du monde car honnêtement je m'en fou, c'est du détail. Que CentOS Stream s'appelle CentOS Stream ou Red Hat Community edition ou quoique ce soit d'autre ne change pas la réalité derrière le produit.
Et c'est pareil pour tout, si demain Debian Sid devient la version stable de Debian après tout leur historique, je ne vais rien dire non plus. Ou si demain Debian devient une rolling release aussi en gardant le même nom.
Mais bon, je pense que tu n’as pas bien compris la différence, si déjà tu ne vois pas l’intérêt d’une distribution « 100 % identique » (au niveau du code source, et seulement pour la partie opensource de celui-ci), tu es l’exemple parfait qu’ils ont « bien » fait de se permettre cette manipulation honteuse, car sa grossièreté ne saute manifestement pas aux yeux de tout le monde.
Revenons sur le compatible bug pour bug.
Pour moi c'est une promesse qui n'a jamais existé et n'existera probablement jamais. On s'en approche le mieux possible évidemment, mais l'atteindre de manière absolue pas vraiment. EN partant de ce principe là et par le modèle choisi, en réalité CentOS Stream est très similaire à ce qu'était CentOS de ce côté là, juste qu'au lieu d'être en retard avec RHEL il est en avance de phase.
Pourquoi le bug pour bug est une chimère ?
Déjà car il y a des mises à jour en continue dans RHEL et que chaque mise à jour introduit des changements (sinon ça n'aurait aucun intérêt). Par définition CentOS avait du retard, souvent de quelques jours voire plus. Il n'y a aucun jour X où le code de RHEL et CentOS étaient identiques. Et comme les flux de traitements sont différents, même en admettant qu'un lag réduit, RHEL pouvait publier 2 maj avec des jours d'écart quand CentOS va les proposer en même temps. Donc tu auras par exemple dans la nature des RHEL avec une de ces maj installées et pas l'être quand sur CentOS cette situation n'arrivera pas.
En plus les RHEL et CentOS ayant un système d'image traditionnelle ne sont jamais identiques entre elles, l'ordre des mises à jour n'est pas identique d'un site à l'autre même en suivant les mêmes instructions en même temps ce qui est source de bogues et de comportements différents.
Ce n'est pas pour rien que Red Hat investit la question des images à base de rpm-ostree et qu'il y a une "hype" pour les images immuables car ce sont les seuls moyens d'apporter la garantie que tu recherches. Sans cela, tu ne garanties rien pas plus qu'AlmaLinux ne le fait. Tu t'en approches mais c'est tout. De même pour la compilation reproductible même si cela n'est pas suffisant non plus, CentOS et RHEL n'ont jamais été été compatibles à ce sujet.
Et l'un dans l'autre la garantie apportée par CentOS Stream à cet égard n'est pas si différente que ce que faisait CentOS dans le passé. Mais dans l'autre sens.
Et rendait pas mal de services aussi.
Mais CentOS Stream aussi rend pas mal de services et est exploitable en production.
Sinon ALMA Linux et Rocky Linux n’auraient pas été créés pour remplacer CentOS dès que la décision de Red Hat a été connue.
Mais je ne condamne pas ces projets moi. Ils le font s'ils le veulent, on verra s'ils tiennent dans la durée, c'est tout ce que je leur souhaite mais l'histoire montre que c'est délicat.
C'est l'avantage du Logiciel Libre à cet égard par ailleurs. Et Red Hat est tout aussi libre d'arrêter de faire CentOS comme avant.
Tu sais qui a lancé le projet Rocky Linux ? Si tu ne sais pas renseigne toi
Merci je pense que je connais bien le dossier.
Et donc ? Perso je m'en fou un peu des noms, des problèmes d'égos, des gens qui font n'importe quoi ou qui étaient une référence un jour X pour faire n'importe quoi le lendemain ce n'est pas ce qui manque pour qu'on ne considère pas les arguments d'autorité.
Je pense que j'ai assez expliqué et justifié mon point de vue.
ça t’incitera peut-être à ôter les œillères qui font que tu ne vois rien à redire à la réutilisation du nom pour la nouvelle distribution de l’écosystème Red Hat (ie: CentOS Stream), bien que parfaitement légale, est foncièrement malhonnête intellectuellement parlant.
Ce serait bien d'éviter les attaques personnelles, je ne partage pas ton point de vue ne signifie pas que je suis aveuglé, con ou quoique ce soit d'autres.
Sinon tu t'attaches à une considération marketing, c'est ton droit, moi je m'en fou, c'est mon droit aussi.
Car fondamentalement, si CentOS Stream se nommait je ne sais pas Open Red Hat Community Edition, tout en arrêtant CentOS par ailleurs. Ton discours serait différent ? Étant donné ton propos j'en doute. Et s'il était différent, ce serait de tout façon peu cohérent.
Et Alma Linux comme Rocky Linux auraient été lancés aussi.
Bref, ça n'aurait fondamentalement rien changé je pense et cela ne devrait pas de toute manière car ce n'est qu'un nom. Cela ne change pas les propriétés de chaque entité.
Tu dis sûrement vrai, ce serait juste afin de connaître la valeur réel du facteur pifométrique « parfois plusieurs » que tu emploies, ainsi que quelques exemple des problèmes ayant, comme tu le suggères, eu lieu et auxquels tu fais allusion.
RHEL 6 sorti le 10 novembre 2010, CentOS sorti le 27 novembre 2011 (plus d'un an !)
RHEL 7 sorti le 10 juin 2014, CentOS 7 est sorti le 7 juillet 2014 (presque un mois)
RHEL 8 sorti le 7 mai 2019, CentOS 8 le 24 septembre 2019 (donc 4 mois après)
Bref, pour les mises à jour majeur, on voit bien un écart en moyenne de plusieurs mois.
Pour les sorties intermédiaires (donc par exemple 6.1) la page de Wikipédia anglaise fait le listing avec les délais pour chaque version :https://en.wikipedia.org/wiki/CentOS
En général il y a toujours au moins 2 semaines d'écart, et souvent 1 mois et parfois plus. Tes 2-3 jours n'ont jamais existé en vrai.
Cela te convient ? Oui, je pense comprendre le dossier en question.
Par ailleurs compiler une distribution c'est un peu mon boulot quotidien via Yocto pour différents clients, je suis également de près les arcanes de Fedora, cela m'aide à comprendre à quel point des problèmes peuvent survenir à tous les étages et la difficulté de la tâche dont de la reproduction de la compilation.
Cela signifiait que sans licence Red Hat, pas moyen de tester la version en développement pour s'assurer que son parc ou son application sera compatible car c'était un développement en mode fermé.
Tout à fait. Ça permettait « juste » de tester ses applications avec n’importe qu’elle version stable, publiée, de RHEL sans devoir acquérir une ou plusieurs licences ! Sérieusement, tu me sidères…
Ce que tu dis sur l’utilité d’avoir une distribution comme CentOS Stream est tout à fait juste également. Mais je crois sincèrement que tu ne vois pas à quoi servait une distribution comme CentOS, qui est exactement les mêmes usages qu’ALMA Linux ou Rocky Linux aujourd’hui.
Mais tu déformes totalement mon propos depuis le début.
Je ne dis pas que c'était le seul intérêt de CentOS, mais que ça en était une et avec un retard tel que c'était bloquant dans cette tâche (et pénalisait Red Hat par ailleurs).
Je ne dis pas que Alma Linux ou Rocky ne servent à rien et qu'il faut aussi les brûler en enfer. Ils existent, tant mieux, le libre est là pour ça. Mais je signe et persiste, pour beaucoup d'utilisateurs CentOS Stream fait le même job que CentOS et est en fait plus intéressant d'un point de vue écosystème et communautaire que ne l'était CentOS.
Tu peux ne pas être d'accord si tu veux, je pense avoir justifié mon point de vue qui ne me semble pas mauvaise justement.
Non je ne parlais pas de chiffre d'affaire mais j'ai effectivement fait un lapsus entre revenu et bénéfice.
Revenue en anglais ça veut dire chiffre d'affaire aussi. ;)
Reste que c'est vite absorbé comme amende. Le challenge pour eux, c'est que ça ne se répète pas.
Oui car globalement Apple a de belles marges donc un CA élevé implique avec eux un bilan net très positif.
Mais c'est une confusion courante de mélanger bénéfices et CA, c'est bien de faire attention.
Je vais essayer de faire le plus clair possible pour que tout le monde puisse comprendre de quoi on parle
Ton propos est tout sauf clair.
CentOS existe depuis très longtemps, probablement depuis autant de temps que RHEL. Ce n’est pas une distribution « dérivée » de RHEL, c’était (jusqu’à la version 7) une distribution dite « downstream » de RHEL.
C'est donc une version dérivée. RHEL n'a jamais été une copie 100% identique (sinon ça n'aurait aucun intérêt).
C’est ça, il ya maintenant de nombreuses années qui a poussé certaines personnes à créer « CentOS », une distribution dite « binairement compatible » avec RHEL.
Ce qui est dommage dans ton explication c'est que tu passes outre qu'avant que Red Hat ne récupère CentOS (car cela n'a pas toujours été dans les mains de Red Hat), CentOS a plusieurs fois failli disparaître faute de main d’œuvre. En fait sans ce rachat à l'époque, CentOS aurait sans doute déjà disparu.
Car bon faire une distribution finalement c'est une tâche non triviale et ingrate, c'est difficile de motiver des gens sur la durée pour un projet qui finalement n'introduit rien de nouveau par définition.
À un moment donné RH s’est rendu compte qu’un certains nombre d’entités (déjà client ou client potentiel) montaient leur truc sur du CentOS, mais qu’une fois le truc validé, il y avait un financier pour suggérer que le risque de ne pas avoir de support était sensiblement inférieur au risque de migrer le truc. Que ça marchait plutôt bien. Et là ! L’idée, mais alors L’IDÉE!! de RH, on va transformer CentOS en une sorte de « preview » de notre next version ! }
Ou alors tu réfléchis 5 minutes à la situation, tu discutes avec les employés de Red Hat et tu vois que la décision de changer de modèle pour CentOS a du sens et des bénéfices et que c'est loin d'être une lubie de commerciaux.
CentOS avant CentOS Stream posait pas mal de problèmes. Comme c'était un downstream de RHEL, il y avait un délai pour fournir les versions (parfois plusieurs mois), de même pour les correctifs de sécurité. Cela signifiait que sans licence Red Hat, pas moyen de tester la version en développement pour s'assurer que son parc ou son application sera compatible car c'était un développement en mode fermé. Et de manière bizarre, CentOS avait de fait le retour des clients de RHEL concernant les MaJ alors que ce sont eux qui payent et non l'inverse. Puis si tu voulais changer un truc dans RHEL il n'y avait pas de canaux simples pour cela car le développement est fermé.
Aujourd'hui c'est plus logique, CentOS Stream devient l'amont, donc les clients qui payent ont les retours de ceux qui ne payent pas. Mais aussi quiconque peut facilement tester ou ajouter quelque chose dans RHEL via CentOS Stream car le développement devient ouvert. Les délais entre CentOS Stream / RHEL sont bien plus faibles qu'à l'époque. Un développement plus ouvert ça devrait être justement salué plutôt que de défendre un modèle de développement plus opaque tel qu'il était en place.
Et cela n'empêche nullement des entreprises comme Meta de miser massivement sur CentOS Stream en production, RH n'a aucun intérêt à saboter CentOS Stream en terme de stabilité car ils s'en servent après…
Qui ne sont donc pas des dérivées de RHEL, mais, et c’est clair que c’est pas compréhensible de manière évidente… J’espère avoir participé à une meilleure compréhension avec ce message.
Rocky Linux et ALMA Linux sont bien des dérivés de RHEL. Ton message n'explique en rien en quoi ils ne le sont pas.
Bref, ton message est pas très clair et ton scénario n'est pas très bon par ailleurs.
Perso c'est mon rapport de stage de fin d'étude que j'ai rédigé avec roff.
Cela fonctionne bien, en fait c'est vraiment comme un LaTeX un peu primitif, avec quelques limitations mais rien de bloquant dans mon cas.
C'est un exercice amusant à faire une fois. De nos jours on préfèrera en effet un autre format que celui-là dans cette tâche. Entre LaTeX, HTML, Markdown, etc. il y a pas mal de moyens de rédiger un document qui rend bien facilement.
Honnêtement à part pour les serveurs je ne vois pas bien l'intérêt du hot patching.
Et même pour les serveurs, cela est en général une solution temporaire, pour couper en cas de maintenance ou de baisse d'activité quand l'impact est moins élevé.
Niveau sécurité redémarrer la machine de temps en temps est nécessaire car tout ne peut être patché à la volée. Même pour le noyau qui a une telle possibilité cela reste une solution complexe qui ne fonctionne pas pour tous les correctifs.
Celle d'octobre ne devrait-elle pas être 24.10.x ?
Les versions de LibreOffice sont calendaires pour la partie majeure de la numérotation.
24.2.0 est la première version basée sur le code de février 2024. Si un correctif est effectué (en général il y en a 7), alors on incrémente uniquement le dernier numéro ainsi 24.2.7.
Quand LibreOffice sortira sa prochaine version majeure dans l'année, souvent durant l'été, ce sera 24.7.0 et ainsi de suite pour les correctifs associés.
La Tchétchénie n'était pas indépendante de la Russie, une intervention armée extérieure signifiait un conflit ouvert avec la Russie. Ce n'était pas une bonne idée, surtout dans une période de détente avec la Russie. C'est une chose d'intervenir dans les Balkans, s'en est une autre d'intervenir en Russie.
Quant à assassiner Poutine, même topo. Tuer un chef d'État étranger c'est donner une raison pour un conflit ouvert.
Alors peut être que ce conflit arrivera quand même, mais de là à le provoquer unilatéralement ce n'est pas la même chose que de laisser Poutine justement franchir le Rubicon lui même. Je tempèrerais le "99% de chance que cela arrive" également.
Les réponses de 2008 et de 2014 ont été trop molles, ça c'est certain, mais la Tchétchénie pas vraiment, ou tuer Poutine ce n'était pas une bonne idée. Puis même si on personnifie cette guerre comme celle de Poutine, il n'est pas le seul à soutenir cela non plus (et son remplaçant pourrait donc être pire), et le tuer ainsi de l'extérieur serait justement le meilleur moyen de mettre la population russe derrière le nouveau dirigeant pour répondre à cette attaque.
Tout à fait, le public a un peu trop confiance quant au caractère absolu des preuves médico-légales modernes alors qu'il y a des erreurs possibles. Dans les films / séries c'est rarement évoqué mais cela arrive.
C'est assez difficile d'être certain à 100% qu'une personne est coupable. D'où l'importance aussi des procédures en appel.
Ce n'est pas si rare qu'une personne soit libérée de prison des années après alors qu'elle était innocente depuis le début.
Cela ne change pas foncièrement la donne, car il faut remplacer les centrales nucléaires existantes d'ici 2050 ce qui serait déjà bien.
Et le GIEC comme l'AIE n'ont pas cette contrainte et vont dans le même sens à l'échelle mondiale et même au niveau européen.
Je suis favorable au nucléaire, et en particulier pour maintenir le parc existant le plus longtemps possible, mais cela ne signifie pas que le renouvelable est à jeter à la poubelle. Il faudrait une sacrée étude démontrant qu'on peut s'en passer à bas coût pour respecter nos engagements climatiques pour remettre cela en question. Et je suppose que tu n'as pas ça en poche. Ce serait bien que tu sources ton point de vue avec des rapports complets comme ceux-là, sinon c'est plus de l'idéologie qu'autre chose.
Bien sûr sans reposer le tout sur une chute de la production électrique via une sobriété inédite et probablement irréaliste.
RTE projette dans son scénario le plus nucléarisé 8 fois plus de solaire et 3 fois plus d'éolien qu'aujourd'hui. Et les autres scénarios sont évidemment plus ambitieux
Tandis que l'AIE demande de tripler le renouvelable d'ici 2030 pour respecter l'accord de Paris :
Prior to the COP28 climate change conference in Dubai, the International
Energy Agency (IEA) urged governments to support five pillars for action by
2030, among them the goal of tripling global renewable power capacity.
Several of the IEA priorities were reflected in the Global Stocktake text agreed by
the 198 governments at COP28, including the goals of tripling renewables and
doubling the annual rate of energy efficiency improvements every year to 2030.
Tripling global renewable capacity in the power sector from 2022 levels by 2030
would take it above 11 000 GW, in line with IEA’s Net Zero Emissions by 2050
(NZE) Scenario.
Les scénarios du GIEC convergent quant au fait qu'il faut décarboner vite et que le renouvelable est nécessaire pour atteindre les objectifs à un coût acceptable.
Bref, cela me semble être des sources assez sérieuses et indépendantes entre elles.
Un panneau produit moins de 20% du temps autour de midi. Il y a de toute façon des limites sur son utilisabilité, au delà d'un certain volume, le courant sera jeté ("grounded").
Merci je suis au courant de tout cela, mais si cela limite l'efficacité des panneaux solaires et donc le fait de reposer uniquement sur eux pour la transition énergétique, cela ne signifie pas qu'il ne faut pas en produire.
Toutes les études le disent : il faut de l'éolien et du solaire et bien plus qu'aujourd'hui. Aucune étude ne fait l'impasse dessus.
Les centrales nucléaires ne sont pas construit pour 40 ans. Elles ont une autorisation d'exploitation pour 40 ans, renouvelable après étude.
Aucun entrepreneur ne fait une maison pour 50 ans, aucun travail de rénovation n'a une durée de vie de 10 ans, aucun produit de consommation casse dès 2 ans + 1 jour, etc. Les 20 ans dont tu parles sont la base pour le calcul de rentabilité et de la conception pour assurer une durée de vie suffisamment longue dans ce but, cela ne veut pas dire qu'ils ne peuvent pas tenir plus longtemps.
Les éoliennes sont essentiellement remplacées aujourd'hui pour y mettre des plus puissantes à la place avant qu'elles ne soient hors d'usage.
Cela ferait aussi beaucoup de CO2 et diminuerait l’intérêt de la filière.
Source ?
Oui mais l'intensité d'usage de matériaux des ENR est un problème en soi. Les projections d'utilisation de métaux ou de béton sont colossales pour tenir le rythme de construction d'éolienne (c'est de l'ordre de x10).
Mais toutes les études en tiennent compte et toutes convergent vers ce point : il faut de l'éolien et du solaire. Quoique tu fasses tu en auras besoin. Alors si tu mets du nucléaire en plus, il en faudra moins, si tu fais de la sobriété également, etc.
Mais on ne peut pas se passer de ces technologies dans le cadre de la transition énergétique, il n'y a rien qui va en ce sens.
[^] # Re: Network Manager CLI
Posté par Renault (site web personnel) . En réponse au journal [ HS ] ... enfin, pas tant que ça.. Évalué à 6.
Euh tu sais que la configuration de NetworkManager que tu l'édites à la main, que tu utilises la GUI de GNOME ou nmcli cela revient au même ? Les fichiers sont stockés au même endroit et de la même façon, la conf est identique… Et heureusement, ce ne sont que des interfaces utilisateurs différents, le reste de l'outil est le même.
[^] # Re: Magré toutes ces âneries, il y a du vrai
Posté par Renault (site web personnel) . En réponse au journal [HS] 3 Gigas par semaine .... Évalué à 8.
Notons que la TV en direct utilise du multicast pour être distribué sur le territoire national. C'est bien moins coûteux et gourmand que des flux individuels pour la même qualité d'image.
[^] # Re: Code sur papier
Posté par Renault (site web personnel) . En réponse au journal [HS] 3 Gigas par semaine .... Évalué à 9. Dernière modification le 19 mars 2024 à 11:23.
Écrire un algo en pseudo code ne me semble pas très pertinent dans un cadre pro. Dans un contexte scolaire je pense que ça peut avoir du sens car tu apprends.
Par contre faire la conception sur papier, poser les idées, passer du temps à réfléchir dessus, etc. cela a du sens dans un contexte pro. Après chacun son outil mais je trouve la papier pratique pour cela.
[^] # Re: Très cool
Posté par Renault (site web personnel) . En réponse au lien Quand l’IA se met à décompiler du binaire. Évalué à 9. Dernière modification le 19 mars 2024 à 10:51.
Je trouve, oui. En quoi ça ne serait pas pertinent selon toi ?
Je veux dire, tout le monde ne connaît pas le sujet, l'article est assez trompeur sur les capacités (je trouve), le manque de recul sur l'IA est assez important en ce moment dans l'esprit de beaucoup de gens, rappeler concrètement les limites ne me paraît pas inutile.
[^] # Re: Très cool
Posté par Renault (site web personnel) . En réponse au lien Quand l’IA se met à décompiler du binaire. Évalué à 6.
Peut être, cela n'est cependant pas trivial et ne peut être déduit avec ce qui a été publié.
Mon propos n'est pas de dire que l'approche ne mènera à rien dans tous les cas. Je dis juste que ce qui est présenté pour l'instant ne montre rien de si extraordinaire pour justifier un article aussi dithyrambique.
C'est une preuve de concept, faut creuser la question et pourquoi pas, ça peut donner des résultats intéressants (ou pas).
C'est un peu comme lire les articles scientifiques de certains présentant des nouveaux matériaux ou traitements médicaux révolutionnaires alors qu'en vrai la plupart n'iront pas plus loin que le labo où la découverte a été publié car finalement c'était une mauvaise piste. Ce n'est pas un mal de communiquer dessus mais je trouve la forme souvent excessive.
Après c'est Korben, ce n'est pas la première fois qu'il fait ça et typiquement je ne le lis pas pour cette raison.
[^] # Re: Très cool
Posté par Renault (site web personnel) . En réponse au lien Quand l’IA se met à décompiler du binaire. Évalué à 4.
Et encore très élevé, pardon.
[^] # Re: Très cool
Posté par Renault (site web personnel) . En réponse au lien Quand l’IA se met à décompiler du binaire. Évalué à 5.
Perso je suis moyennement convaincu, l'article de Korben semble très pute à clic.
Ce n'est pas inintéressant mais franchement limité à ce stade. De ce qu'on peut en lire (car honnêtement je ne trouve pas que le dépôt apporte beaucoup d'infos sur l'entrainement et les tests). Cela semble travailler sur des fonctions apparemment isolées et relativement triviales (en tout cas, pas d'exemples montrant le contraire), le résultat est déjà obtenu par des outils plus classiques (décompiler du binaire en instruction C avec peu de valeur ajoutée n'a rien d'extraordinairement difficile). Le seul ajout est celui de tests automatiques mais le taux d'échecs même dans un cas simple est encore très faible.
Alors oui, c'est le début, mais c'est encore la partie simple : le modèle arrivera-t-il à fonctionner sur un programme entier à apporter de la valeur ajoutée comme ça ? Pas sûr non plus. Ce n'est en tout cas pas à ce stade une révolution mais plus une preuve de concept à creuser.
[^] # Re: Magré toutes ces âneries, il y a du vrai
Posté par Renault (site web personnel) . En réponse au journal [HS] 3 Gigas par semaine .... Évalué à 9.
Ce raisonnement dépend de la structure de l'empreinte des coûts environnementaux comme financiers.
Une infrastructure télécom ce sont beaucoup de coûts fixes, c'est même l'essentiel du prix de la facture. Que tu consommes ou pas tes données, le coût financier et environnemental sera proche. Car il faut maintenir l'infrastructure, les antennes relais, les bornes de distributions, les serveurs, etc.
D'ailleurs cela se voit bien, quand des offres illimités sont apparus, ils étaient rarement dans les prix haut de gammes des forfaits limités de l'époque. Et aujourd'hui un forfait à 100 Gio en France pour mobile est significativement moins cher que pour la plupart des pays voisin avec des quotas pourtant bien plus bas.
Pour l'illimité au moins tu ne te poses pas la question, ce mois ci tu consommes plus pour X ou Y raison, aucun problème. Cela a aussi un coût mental de se préoccuper de savoir si on a de quoi tenir le mois, s'il faut acheter plus de data exceptionnellement, si on doit réduire significativement son usage car on ne veut pas payer plus, etc.
[^] # Re: Vrai question C'est quoi l'IA ?
Posté par Renault (site web personnel) . En réponse au journal Cybersécurité: des chercheurs ont créé un ver qui attaque l’IA. Évalué à 4.
Bah non, si du moins l'outil qui parse ces déclarations n'en est pas une.
Ce qui est pertinent c'est de considérer la conception et maintenance plus que l'exécution, une IA reste un programme comme un autre à la fin, la différence se situe en amont lors de son élaboration.
La conception fait que l'algo exécutée par l'IA n'est à priori pas connu dans le détail par ses concepteurs et utilisateurs (sinon autant écrire l'algo directement à la main, c'est plus fiable et efficace). L'algo est élaborée de manière dynamique en fonction de comment il a été entrainé et des tâches qu'il doit mener.
Cela rend aussi la maintenance délicate, difficile d'apporter des garanties fortes de fonctionnement car le détail de l'algo n'est pas connu, et corriger des défauts à la main est difficile (un peu comme altérer un binaire sans le code source, c'est faisable mais délicat). Il faut probablement ajouter des éléments lors de la conception et entrainement en croisant les doigts que cela règle le problème sans en introduire d'autres.
Le HTML ou autres type de documents déclaratifs ne sont pas forcément de la programmation d'une part, et d'autres part le moteur de rendu est un algo conçu et éditable à la main.
[^] # Re: La question que je me pose...
Posté par Renault (site web personnel) . En réponse au lien 43 millions de comptes France-Travail potentiellement compromis. Évalué à 3.
Une personne centenaire peut partager le même numéro de sécurité sociale qu'une personne récemment née.
Cela pourrait arriver aussi si un département a beaucoup trop de naissance le même jour (je doute que ce soit déjà arrivé et si cela risque d'arriver).
C'est improbable mais pas impossible.
[^] # Re: Laissons à ChatGPT le droit de se défendre ;)
Posté par Renault (site web personnel) . En réponse au lien The AI industry is pushing a nuclear power revival — partly to fuel itself. Évalué à 6. Dernière modification le 13 mars 2024 à 19:11.
J'ai vu assez d'exemples qui montraient qu'il était capable de tout, surtout suivant comment tu le prépares.
C'est tout le problème de ces systèmes, avoir des garanties de fonctionnement est difficile (si ce n'est impossible).
Ce n'était pas clair si tu l'écartais pour cette raison ou parce que tu souhaitais plutôt évaluer les autres hypothèses.
Des réponses non nuancées des LLM ce n'est pas le plus dur à obtenir à priori. Et c'est d'ailleurs une partie du problème.
Honnêtement tes interrogations semblaient plus génériques que cela donc effectivement je n'avais pas compris où tu voulais en venir.
J'ai sans doute un biais à analyser ta réponse ainsi car des gens qui utilisent des LLM pour tout et n'importe quoi sans recul bah j'en croise un peu trop et je trouve cela problématique à plus d'un titre. Donc mes excuses pour ce biais d'interprétation.
[^] # Re: Laissons à ChatGPT le droit de se défendre ;)
Posté par Renault (site web personnel) . En réponse au lien The AI industry is pushing a nuclear power revival — partly to fuel itself. Évalué à 9.
Tu trouves ?
Tout dépend du prompt et du sujet, tu as de tout.
Un LLM ne fait pas vraiment de déduction logique de ce style.
Il me semble assez improbable de croire que des données d'entrainement soit sans biais tout court. Il y a forcément une sélection et un biais introduit à cette étape même si ce n'est pas conscient.
Perso je pense surtout qu'il faut se rappeler des limites de ces technos et d'arrêter de les utiliser comme si elles n'en avaient pas. Cela peut rendre des services mais il faut avoir un regard critique quant aux réponses données.
[^] # Re: Tout dépend du point de vue ...
Posté par Renault (site web personnel) . En réponse au journal Les distro pionnières, en recul?. Évalué à 6.
Cela fait quand même 10 ans, c'est énorme.
Cela se discute que c'était 100% identique, mais je vais revenir après là dessus.
Un rebuild est par définition un dérivé car ce n'est pas une copie parfaite, je vais l'expliquer en quoi.
Par ailleurs tu viens de le dire enfin que pour toi un rebuild n'est pas un dérivé de ton point de vue. Ce n'était pas explicité dans tes précédents messages donc oui c'était cryptique comme point de vue sans ce rappel de vocabulaire (de ton point de vue car personnellement je ne suis pas d'accord).
Honnêtement des produits ou marques qui évoluent dans leur cibles ou caractéristiques principales tout en gardant le même nom pour des raisons commerciales ça arrive tous les jours. Que Red Hat le fasse ne me choque pas le moins du monde car honnêtement je m'en fou, c'est du détail. Que CentOS Stream s'appelle CentOS Stream ou Red Hat Community edition ou quoique ce soit d'autre ne change pas la réalité derrière le produit.
Et c'est pareil pour tout, si demain Debian Sid devient la version stable de Debian après tout leur historique, je ne vais rien dire non plus. Ou si demain Debian devient une rolling release aussi en gardant le même nom.
Revenons sur le compatible bug pour bug.
Pour moi c'est une promesse qui n'a jamais existé et n'existera probablement jamais. On s'en approche le mieux possible évidemment, mais l'atteindre de manière absolue pas vraiment. EN partant de ce principe là et par le modèle choisi, en réalité CentOS Stream est très similaire à ce qu'était CentOS de ce côté là, juste qu'au lieu d'être en retard avec RHEL il est en avance de phase.
Pourquoi le bug pour bug est une chimère ?
Déjà car il y a des mises à jour en continue dans RHEL et que chaque mise à jour introduit des changements (sinon ça n'aurait aucun intérêt). Par définition CentOS avait du retard, souvent de quelques jours voire plus. Il n'y a aucun jour X où le code de RHEL et CentOS étaient identiques. Et comme les flux de traitements sont différents, même en admettant qu'un lag réduit, RHEL pouvait publier 2 maj avec des jours d'écart quand CentOS va les proposer en même temps. Donc tu auras par exemple dans la nature des RHEL avec une de ces maj installées et pas l'être quand sur CentOS cette situation n'arrivera pas.
En plus les RHEL et CentOS ayant un système d'image traditionnelle ne sont jamais identiques entre elles, l'ordre des mises à jour n'est pas identique d'un site à l'autre même en suivant les mêmes instructions en même temps ce qui est source de bogues et de comportements différents.
Ce n'est pas pour rien que Red Hat investit la question des images à base de rpm-ostree et qu'il y a une "hype" pour les images immuables car ce sont les seuls moyens d'apporter la garantie que tu recherches. Sans cela, tu ne garanties rien pas plus qu'AlmaLinux ne le fait. Tu t'en approches mais c'est tout. De même pour la compilation reproductible même si cela n'est pas suffisant non plus, CentOS et RHEL n'ont jamais été été compatibles à ce sujet.
Et l'un dans l'autre la garantie apportée par CentOS Stream à cet égard n'est pas si différente que ce que faisait CentOS dans le passé. Mais dans l'autre sens.
Mais CentOS Stream aussi rend pas mal de services et est exploitable en production.
Mais je ne condamne pas ces projets moi. Ils le font s'ils le veulent, on verra s'ils tiennent dans la durée, c'est tout ce que je leur souhaite mais l'histoire montre que c'est délicat.
C'est l'avantage du Logiciel Libre à cet égard par ailleurs. Et Red Hat est tout aussi libre d'arrêter de faire CentOS comme avant.
Merci je pense que je connais bien le dossier.
Et donc ? Perso je m'en fou un peu des noms, des problèmes d'égos, des gens qui font n'importe quoi ou qui étaient une référence un jour X pour faire n'importe quoi le lendemain ce n'est pas ce qui manque pour qu'on ne considère pas les arguments d'autorité.
Je pense que j'ai assez expliqué et justifié mon point de vue.
Ce serait bien d'éviter les attaques personnelles, je ne partage pas ton point de vue ne signifie pas que je suis aveuglé, con ou quoique ce soit d'autres.
Sinon tu t'attaches à une considération marketing, c'est ton droit, moi je m'en fou, c'est mon droit aussi.
Car fondamentalement, si CentOS Stream se nommait je ne sais pas Open Red Hat Community Edition, tout en arrêtant CentOS par ailleurs. Ton discours serait différent ? Étant donné ton propos j'en doute. Et s'il était différent, ce serait de tout façon peu cohérent.
Et Alma Linux comme Rocky Linux auraient été lancés aussi.
Bref, ça n'aurait fondamentalement rien changé je pense et cela ne devrait pas de toute manière car ce n'est qu'un nom. Cela ne change pas les propriétés de chaque entité.
RHEL 6 sorti le 10 novembre 2010, CentOS sorti le 27 novembre 2011 (plus d'un an !)
RHEL 7 sorti le 10 juin 2014, CentOS 7 est sorti le 7 juillet 2014 (presque un mois)
RHEL 8 sorti le 7 mai 2019, CentOS 8 le 24 septembre 2019 (donc 4 mois après)
Bref, pour les mises à jour majeur, on voit bien un écart en moyenne de plusieurs mois.
Pour les sorties intermédiaires (donc par exemple 6.1) la page de Wikipédia anglaise fait le listing avec les délais pour chaque version :https://en.wikipedia.org/wiki/CentOS
En général il y a toujours au moins 2 semaines d'écart, et souvent 1 mois et parfois plus. Tes 2-3 jours n'ont jamais existé en vrai.
Cela te convient ? Oui, je pense comprendre le dossier en question.
Par ailleurs compiler une distribution c'est un peu mon boulot quotidien via Yocto pour différents clients, je suis également de près les arcanes de Fedora, cela m'aide à comprendre à quel point des problèmes peuvent survenir à tous les étages et la difficulté de la tâche dont de la reproduction de la compilation.
Mais tu déformes totalement mon propos depuis le début.
Je ne dis pas que c'était le seul intérêt de CentOS, mais que ça en était une et avec un retard tel que c'était bloquant dans cette tâche (et pénalisait Red Hat par ailleurs).
Je ne dis pas que Alma Linux ou Rocky ne servent à rien et qu'il faut aussi les brûler en enfer. Ils existent, tant mieux, le libre est là pour ça. Mais je signe et persiste, pour beaucoup d'utilisateurs CentOS Stream fait le même job que CentOS et est en fait plus intéressant d'un point de vue écosystème et communautaire que ne l'était CentOS.
Tu peux ne pas être d'accord si tu veux, je pense avoir justifié mon point de vue qui ne me semble pas mauvaise justement.
[^] # Re: perspective
Posté par Renault (site web personnel) . En réponse au lien Amende record pour Apple, qui commence une semaine de tous les dangers - letemps.ch. Évalué à 3.
Revenue en anglais ça veut dire chiffre d'affaire aussi. ;)
Oui car globalement Apple a de belles marges donc un CA élevé implique avec eux un bilan net très positif.
Mais c'est une confusion courante de mélanger bénéfices et CA, c'est bien de faire attention.
[^] # Re: Tout dépend du point de vue ...
Posté par Renault (site web personnel) . En réponse au journal Les distro pionnières, en recul?. Évalué à 2.
Je ne comprends pas ton commentaire, que veux-tu exprimer ou éclaircir ?
[^] # Re: Tout dépend du point de vue ...
Posté par Renault (site web personnel) . En réponse au journal Les distro pionnières, en recul?. Évalué à 10.
Ton propos est tout sauf clair.
C'est donc une version dérivée. RHEL n'a jamais été une copie 100% identique (sinon ça n'aurait aucun intérêt).
Ce qui est dommage dans ton explication c'est que tu passes outre qu'avant que Red Hat ne récupère CentOS (car cela n'a pas toujours été dans les mains de Red Hat), CentOS a plusieurs fois failli disparaître faute de main d’œuvre. En fait sans ce rachat à l'époque, CentOS aurait sans doute déjà disparu.
Car bon faire une distribution finalement c'est une tâche non triviale et ingrate, c'est difficile de motiver des gens sur la durée pour un projet qui finalement n'introduit rien de nouveau par définition.
Ou alors tu réfléchis 5 minutes à la situation, tu discutes avec les employés de Red Hat et tu vois que la décision de changer de modèle pour CentOS a du sens et des bénéfices et que c'est loin d'être une lubie de commerciaux.
CentOS avant CentOS Stream posait pas mal de problèmes. Comme c'était un downstream de RHEL, il y avait un délai pour fournir les versions (parfois plusieurs mois), de même pour les correctifs de sécurité. Cela signifiait que sans licence Red Hat, pas moyen de tester la version en développement pour s'assurer que son parc ou son application sera compatible car c'était un développement en mode fermé. Et de manière bizarre, CentOS avait de fait le retour des clients de RHEL concernant les MaJ alors que ce sont eux qui payent et non l'inverse. Puis si tu voulais changer un truc dans RHEL il n'y avait pas de canaux simples pour cela car le développement est fermé.
Aujourd'hui c'est plus logique, CentOS Stream devient l'amont, donc les clients qui payent ont les retours de ceux qui ne payent pas. Mais aussi quiconque peut facilement tester ou ajouter quelque chose dans RHEL via CentOS Stream car le développement devient ouvert. Les délais entre CentOS Stream / RHEL sont bien plus faibles qu'à l'époque. Un développement plus ouvert ça devrait être justement salué plutôt que de défendre un modèle de développement plus opaque tel qu'il était en place.
Et cela n'empêche nullement des entreprises comme Meta de miser massivement sur CentOS Stream en production, RH n'a aucun intérêt à saboter CentOS Stream en terme de stabilité car ils s'en servent après…
Rocky Linux et ALMA Linux sont bien des dérivés de RHEL. Ton message n'explique en rien en quoi ils ne le sont pas.
Bref, ton message est pas très clair et ton scénario n'est pas très bon par ailleurs.
[^] # Re: faire revivre le Display Port
Posté par Renault (site web personnel) . En réponse au lien Le HDMI forum trahit les utilisateurs, persiste, et signe ; malgré les efforts d'AMD. Évalué à 3.
Les FAI nationaux en France ne peuvent pas faire ce qu'ils veulent et l'ANSSI les audite de temps en temps car ce sont des acteurs stratégiques.
# Peut servir pour tout type de document
Posté par Renault (site web personnel) . En réponse au lien « Serving my blog posts as Linux manual pages ». Évalué à 4. Dernière modification le 01 mars 2024 à 09:40.
Perso c'est mon rapport de stage de fin d'étude que j'ai rédigé avec roff.
Cela fonctionne bien, en fait c'est vraiment comme un LaTeX un peu primitif, avec quelques limitations mais rien de bloquant dans mon cas.
C'est un exercice amusant à faire une fois. De nos jours on préfèrera en effet un autre format que celui-là dans cette tâche. Entre LaTeX, HTML, Markdown, etc. il y a pas mal de moyens de rédiger un document qui rend bien facilement.
Mais amusant de s'en servir dans ce contexte.
[^] # Re: et les drivers graphiques sous Linux ?
Posté par Renault (site web personnel) . En réponse au lien Fenêtre travaille sur le Hot Patching (Redmond découvre enfin que c’est faisable ?). Évalué à 5.
Et même pour les serveurs, cela est en général une solution temporaire, pour couper en cas de maintenance ou de baisse d'activité quand l'impact est moins élevé.
Niveau sécurité redémarrer la machine de temps en temps est nécessaire car tout ne peut être patché à la volée. Même pour le noyau qui a une telle possibilité cela reste une solution complexe qui ne fonctionne pas pour tous les correctifs.
[^] # Re: Numérotation des versions
Posté par Renault (site web personnel) . En réponse à la dépêche LibreOffice 24.2 : nouvelle année, nouvelle numérotation, nouvelle version. Évalué à 4.
Les versions de LibreOffice sont calendaires pour la partie majeure de la numérotation.
24.2.0 est la première version basée sur le code de février 2024. Si un correctif est effectué (en général il y en a 7), alors on incrémente uniquement le dernier numéro ainsi 24.2.7.
Quand LibreOffice sortira sa prochaine version majeure dans l'année, souvent durant l'été, ce sera 24.7.0 et ainsi de suite pour les correctifs associés.
[^] # Re: Ukraine
Posté par Renault (site web personnel) . En réponse à la dépêche L’auteur de Nginx enfourche le proprio. Évalué à 10.
La Tchétchénie n'était pas indépendante de la Russie, une intervention armée extérieure signifiait un conflit ouvert avec la Russie. Ce n'était pas une bonne idée, surtout dans une période de détente avec la Russie. C'est une chose d'intervenir dans les Balkans, s'en est une autre d'intervenir en Russie.
Quant à assassiner Poutine, même topo. Tuer un chef d'État étranger c'est donner une raison pour un conflit ouvert.
Alors peut être que ce conflit arrivera quand même, mais de là à le provoquer unilatéralement ce n'est pas la même chose que de laisser Poutine justement franchir le Rubicon lui même. Je tempèrerais le "99% de chance que cela arrive" également.
Les réponses de 2008 et de 2014 ont été trop molles, ça c'est certain, mais la Tchétchénie pas vraiment, ou tuer Poutine ce n'était pas une bonne idée. Puis même si on personnifie cette guerre comme celle de Poutine, il n'est pas le seul à soutenir cela non plus (et son remplaçant pourrait donc être pire), et le tuer ainsi de l'extérieur serait justement le meilleur moyen de mettre la population russe derrière le nouveau dirigeant pour répondre à cette attaque.
[^] # Re: C'est certainement pas faux, mais bourré d'arguments fallacieux
Posté par Renault (site web personnel) . En réponse au lien Aux apatrides du web merdique (via les LIDD de Next.ink). Évalué à 3.
Tout à fait, le public a un peu trop confiance quant au caractère absolu des preuves médico-légales modernes alors qu'il y a des erreurs possibles. Dans les films / séries c'est rarement évoqué mais cela arrive.
C'est assez difficile d'être certain à 100% qu'une personne est coupable. D'où l'importance aussi des procédures en appel.
Ce n'est pas si rare qu'une personne soit libérée de prison des années après alors qu'elle était innocente depuis le début.
[^] # Re: Plus de renouvelables, mais pas moins de charbon
Posté par Renault (site web personnel) . En réponse au lien La Chine met le paquet sur le solaire. Évalué à 8. Dernière modification le 13 février 2024 à 18:00.
Cela ne change pas foncièrement la donne, car il faut remplacer les centrales nucléaires existantes d'ici 2050 ce qui serait déjà bien.
Et le GIEC comme l'AIE n'ont pas cette contrainte et vont dans le même sens à l'échelle mondiale et même au niveau européen.
Je suis favorable au nucléaire, et en particulier pour maintenir le parc existant le plus longtemps possible, mais cela ne signifie pas que le renouvelable est à jeter à la poubelle. Il faudrait une sacrée étude démontrant qu'on peut s'en passer à bas coût pour respecter nos engagements climatiques pour remettre cela en question. Et je suppose que tu n'as pas ça en poche. Ce serait bien que tu sources ton point de vue avec des rapports complets comme ceux-là, sinon c'est plus de l'idéologie qu'autre chose.
Bien sûr sans reposer le tout sur une chute de la production électrique via une sobriété inédite et probablement irréaliste.
[^] # Re: Plus de renouvelables, mais pas moins de charbon
Posté par Renault (site web personnel) . En réponse au lien La Chine met le paquet sur le solaire. Évalué à 9.
Il y a trois rapports importants sur le sujet :
RTE projette dans son scénario le plus nucléarisé 8 fois plus de solaire et 3 fois plus d'éolien qu'aujourd'hui. Et les autres scénarios sont évidemment plus ambitieux
Tandis que l'AIE demande de tripler le renouvelable d'ici 2030 pour respecter l'accord de Paris :
Les scénarios du GIEC convergent quant au fait qu'il faut décarboner vite et que le renouvelable est nécessaire pour atteindre les objectifs à un coût acceptable.
Bref, cela me semble être des sources assez sérieuses et indépendantes entre elles.
[^] # Re: Plus de renouvelables, mais pas moins de charbon
Posté par Renault (site web personnel) . En réponse au lien La Chine met le paquet sur le solaire. Évalué à 10.
Mais on peut en récupérer une partie ! Les métaux qu'ils contiennent sont souvent récupérables, pas tous, mais c'est loin d'être 0%.
Le gros du poids d'un panneau solaire c'est le verre et l'aluminium pour le cadre, qui sont bien entendus recyclables en général : https://www.youtube.com/watch?v=3foJDstoHR8 ou https://www.engie.be/fr/blog/panneaux-solaires/panneaux-solaires-recyclage-2020/
Même les cellules de silicium peuvent l'être.
Merci je suis au courant de tout cela, mais si cela limite l'efficacité des panneaux solaires et donc le fait de reposer uniquement sur eux pour la transition énergétique, cela ne signifie pas qu'il ne faut pas en produire.
Toutes les études le disent : il faut de l'éolien et du solaire et bien plus qu'aujourd'hui. Aucune étude ne fait l'impasse dessus.
Aucun entrepreneur ne fait une maison pour 50 ans, aucun travail de rénovation n'a une durée de vie de 10 ans, aucun produit de consommation casse dès 2 ans + 1 jour, etc. Les 20 ans dont tu parles sont la base pour le calcul de rentabilité et de la conception pour assurer une durée de vie suffisamment longue dans ce but, cela ne veut pas dire qu'ils ne peuvent pas tenir plus longtemps.
Les éoliennes sont essentiellement remplacées aujourd'hui pour y mettre des plus puissantes à la place avant qu'elles ne soient hors d'usage.
Source ?
Mais toutes les études en tiennent compte et toutes convergent vers ce point : il faut de l'éolien et du solaire. Quoique tu fasses tu en auras besoin. Alors si tu mets du nucléaire en plus, il en faudra moins, si tu fais de la sobriété également, etc.
Mais on ne peut pas se passer de ces technologies dans le cadre de la transition énergétique, il n'y a rien qui va en ce sens.