Renault a écrit 7255 commentaires

La situation aujourd'hui me semble un peu plus subtile. Les mesures actuelles sont moins drastiques que celles prise en mars.

Il faut dire qu'en mars il y avait une certaine surprise et qu'on n'était pas aussi bien préparé. Sans masques et gel hydroalcoolique en quantité suffisante notamment.

On est pas encore dans le laisser-faire, mais on est plus tout a fait dans la volonté de barrer la route au virus coûte que coûte

Et alors ?

L'important est d'éviter de surcharger les hôpitaux, si on peut y parvenir en gardant un maximum d'activités économiques et sociales ouvertes c'est une bonne chose.

On est dans un compromis difficile à faire. Le but n'est pas d'avoir 0 morts, ni d'avoir la société qui tourne comme si de rien n'était.

Évidement, plus la population a des anticorps, moins les vagues arrivent de manière violente.

Oui, et de même avec un vaccin même s'il n'est pas donné à tout le monde faute de doses. D'ailleurs le fait de le donner en priorité aux personnes très âgées ou malades aidera sans doute à lâcher du lest plus vite.

mais les mesures contraignantes seront de moins en moins justifiées et passer graduellement vers un relatif laisser-faire. Parce qu'a vrai dire, on peut pas rester bien plus longtemps dans cette situation.

Oui, et ? Avec le vaccin qui se profile, il semble possible que la situation s'améliore d'ici le printemps. Il faut voir comment se passera la fin de l'hiver et la campagne de vaccination pour juger.

À dire vrai, je ne vois pas trop où tu veux en venir avec ton message par rapport à ma réponse.

On oublie aussi l'impact psychologique et économique du laisser faire, qui n'est pas nul. Même si pas simple à évaluer.

Admettons qu'on laisse la maladie se propager sans filtres. Les morts vont s'accumuler et les gens hospitalisés aussi. Non seulement il n'y a pas que des vieux qui meurent, mais une telle quantité de morts en une période de temps si courte cela bousculerait durablement l'économie aussi. Car ces personnes là étaient des travailleurs ou consommateurs et donc participaient à la vie du pays.

Un deuil reste un deuil, même si ce sont des personnes plus âgées que soi dans son entourage. Psychologiquement cela ne serait sans doute pas négligeable de devoir faire le deuil de manière si globale en si peu de temps. Sans compter la pression psychologique de vivre dans une telle situation, qui n'est pas si éloignée de ce qu'on vit en fait.

Et avec des hôpitaux surchargés pendant des mois voire années, n'importe quoi de parfaitement soignable en temps normal serait un risque d'y rester. Les gens feront attention pour ne pas tomber malade, ou pour ne pas contaminer un proche. Finalement les gens adopteront d'eux même (pour une grande part) un comportement prudent ce qui aurait un impact sur les secteurs économiques qui sont aujourd'hui fermés.

C'est difficile à évaluer car cette situation est assez inédite. Bien que les épidémies du passé ont montré que les gens n'étaient pas tendres avec les malades non plus. Difficile de savoir comment se comporterait exactement la population. Mais croire que le laisser faire ne conduirait à la mort de quelques vieux est ridicule, l'impact serait global et violent aussi. Après est-ce mieux d'agir ou de ne rien faire, difficile de trancher, mais au moins là on sait où on va et on évite d'accumuler les morts inutilement.

Tout à fait, j'avais oublié de souligner ce point. Merci !

Contaminations != malades ou mourrant

Je n'ai pas dit le contraire, mais si la population devient malade d'un coup, cela fait trop de malades sévères pour qu'on tienne le coup.

C'est le problème qu'on a eu avec la 1ère et 2e vague, on a évité de justesse la catastrophe, mais encore un peu et ça basculait à une surcharge complète.

Ensuite, bien qu'il y ait eu prévision d'une 2ème vague, il n'y a eu aucuns investissement (hors déprogrammation) en ce sens. Les hôpitaux privés non-requisitionnés?

Les cliniques ont été mobilisés pendant la crise. Même s'il a fallu une période d'adaptation car gérer une crise de cette ampleur ne se fait pas en 24h.

En chine, ils construisaient des hôpitaux d'appoints. Entre cet investissement et tuer l'économie et créer encore plus de malades collatéraux, doit-on vraiment réflechir à 2x?

Construire des hôpitaux c'est bien, mais il faut surtout des infirmiers, des médecins, des appareils respiratoires, etc. Tout cela est en quantité limité et il faut du temps pour les former ou les produire. Là encore, en 6 mois tu ne peux rien faire de très significatif de ce côté là.

Et malgré tout, il n'y aura jamais de quoi gérer 100 000 malades sévères en même temps avec toute la volonté du monde. C'est irréaliste.

Il faut des données et faits: bénéfices/risques.

Ça tombe bien, on a des gens compétents qui s'occupent de ça et du personnel très qualifié autour de cette question.

Minimisé le danger de la COVID? Ben c'est le cas, non? 59 000 morts avec commorbidités sur 66 M d'habitants pour la France en moins d'1an. Sachant qu'entre autre, la déclaration de mort par COVID a été largement surexploitée et là j'en été témoin personnellement.
PAR CONTRE, la COVID est effectivement catastrophique de par l'impact des mesures qui ont été prises ET c'est précisément sur ces points-là que le Pr Raoult, Pr Toussaint et autres se positionnent. Vue globale toussa…

Déjà, ne pas oublier que si cela n'a fait que 59 000 morts en France, c'est aussi parce qu'il y avait des mesures en place pour les limiter justement. ;)

Ensuite le principal problème de ce virus n'est pas sa mortalité directe, qui est certes un peu importante mais on en a vu d'autres. Le vrai problème est qu'une contamination un peu importante de la population entraine une saturation du système hospitalier. Et aucun pays du monde ne peut avoir un système hospitalier capable de gérer l'épidémie en mode on laisse faire. Et ce n'est pas un problème de politique de santé (même si certains choix n'aident pas), c'est un problème d'ordre de grandeur.

Si le système hospitalier ne tient plus, cela signifie que des tas de pathologies ou accidents qui se soignent (ou à défaut se gèrent) deviennent à risque important de décès. Ce qui concerne pas mal de monde, dont les plus jeunes aussi.

Et là en terme de décès ou de conséquence à long terme (donc économique), cela se pose là. Car trop de morts ou trop de peur de mourir car les hôpitaux sont plus des morgues que des lieux de soins n'aident pas psychologiquement et économiquement.

Pour le vaccin ARN: N'ayant pas la compétence, je me repose - en partie - sur le Pr. Perrone qui n'est pas un manchot. Ça ne veut pas dire qu'il est au fait de tout.

L'ARN est un sujet qui était vu en première / terminale S il y a environ 10 ans.

L'ARN sert à former les protéines dans les cellules. Les virus s'en servent pour se cloner par ailleurs. Le but du vaccin est qu'une cellule reproduise des bouts du virus pour que le système immunitaire puisse produire une mémoire contre ces bouts de virus.

L'ADN est dans le noyau de la cellule et n'en sort pas. L'ARN est produit dans le noyau et peut en sortir grâce à un mécanisme précis, mais il ne peut pas entrer dans le noyau.

Donc l'ARN ne peut changer ton ADN, car il ne peut pas entrer dans le noyau. Et heureusement ! Sinon cela voudrait dire que le moindre rhume / grippe / coronavirus qui traine changerait ton ADN. Si l'ADN n'était pas protégé dans le noyau, on serait bien plus sensible à des mutations du génome très indésirables.

Cette explication très simpliste ne justifie pas à lui seul que le vaccin ne présente aucun risque. Mais en tout cas il suffit à expliquer que ce type de vaccin n'altère pas ton génome.

Tu parles de quoi? CentOS Stream?

Oui, quoi d'autres ?

Je suis peut-être mauvaise langue, mais je ne vois que des masochistes pour aller faire du "communautaire" RH : ils ont la preuve que RH n'a rien à foutre du communautaire et que seul RH prend les décisions les plus importantes, ils seront toujours qu'un faire valoir.

RH a déjà pris des décisions qui n'ont pas plu au niveau communautaire, mais on ne peut pas résumer RH à ces moments là non plus ce serait malhonnête. Ils ont aussi montré ce qu'ils savaient faire positivement pour tout le monde.

J'avoue ne pas comprendre en quoi le "nouveau" CentOS a comme intérêt pour du communautaire.

C'est l'ancien CentOS où l'aspect communautaire avait finalement peu d'intérêt. CentOS devant être une copie conforme de RHEL, la question était surtout d'avoir des bras et des ressources nécessaires pour recompiler le système. Ce qui n'est pas une tâche facile mais finalement assez peu valorisante. Il n'y avait pas beaucoup de place pour apporter quelque chose de neuf.

CentOS Stream étant en amont de RHEL, là les gens peuvent pousser des choses différentes. Comme chez Fedora par ailleurs aujourd'hui. Tu veux que l'installateur propose Btrfs par défaut ? Avec CentOS ancienne version ce n'était pas possible si RHEL ne le faisait pas, avec CentOS Stream cela devient envisageable.

Pareil, tu veux supporter un matériel précis que le noyau fourni par RHEL ne fourni pas (car trop vieux) ? Avec CentOS ancienne version cela n'était pas possible non plus, sans utiliser des images personnalisées en dehors du système commun évidemment.

Là cela devient aussi possible plus facilement. Etc.

CentOS Stream est un vrai moyen d'ouvrir le développement de RHEL et d'apporter des choses qui par le passé n'étaient pas possibles sans devoir faire beaucoup de chose dans son coin en plus du projet.

de ce que j'analyse, ça va être surtout que CentOS Stream est un nom pour cacher "RHEL Beta" contrôlé par RH avec quelques retours publics pris (ou pas) en compte par RH

Bien sûr Red Hat y trouve son compte. Une partie du travail viendra de l'extérieur gracieusement. CentOS Stream sera un petit peu moins stable (tout comme en un sens RHEL était un peu moins stable que CentOS, ce qui n'empêcher pas les gens de s'en servir tu noteras).

À mon sens c'est intéressant, et il faudra sans doute un peu de temps pour que la dynamique se mette pleinement en place. Il faudra juger sur le temps long.

En réalité, à la base RH n'avait pas la marque CentOS. La où ça a merdé est quand les gens derrière la marque / nom de domaine ont filé la marque à RH.

Certains semblent oublier ce que c'était CentOS avant 2014, quand Red Hat a racheté les droits et a engagé des membres clés du projet. CentOS a failli mourir plusieurs fois, fautes de finances, le projet a eu des retards énormes aussi.

Peut être que sans ce rachat par Red Hat, CentOS aurait disparu complètement du paysage aujourd'hui.

Donc c'était intéressant pour ces personnes là de vendre CentOS et d'être embauché, être payé à faire ce qui te plaît, à avoir une visibilité financière et logistique c'est plus sympa comme cadre de travail.

Et tout a été fait dans la légalité et de manière honnête. Après on peut regretter que CentOS à l'ancienne disparaisse et dire que c'est volontairement pour améliorer les ventes de RHEL, ce qui est certainement vrai en partie. Mais c'est la vie et légal, tant que les sources de RHEL permettent de refaire CentOS comme avant je n'ai pas d'objections particulières, un peu de regret mais sans plus.

Oui, le C de CentOS est oublié… Il y a eu un bon gros entubage, car RH dit merde a C de CentOS après avoir réussi à choper la marque. C'est un coup pourri (autant de RH que de ceux qui ont filé le nom à RH) qu'il ne faudra pas oublier dans le futur, pour bien faire attention à s'en protéger.

CentOS serait peut être mort sans ce rachat depuis un moment, il ne faut pas l'oublier non plus. Cela justifie pour moi pleinement ce transfert des deux côtés.

Après oui le côté communautaire chez CentOS est bien moins présent que chez Fedora par exemple et c'est dommage. Après la structure et son but sont moins propices à une participation communautaire très forte, à quoi bon avoir une grande communauté hyper active pour juste recompiler les sources de RHEL à l'identique ? Cela n'attire pas les foules et c'était source de ses difficultés passées.

À voir comment cela va se réorganiser après ce changement, j'espère plus d'ouverture et une organisation plus communautaire, oui.

On pourrait débattre de l'exagération de l'importance de CentOS et de pourquoi on le tue, si déjà on appelle correctement ce qui est fait, plutôt que de parler de changement mineur.

Je ne dis pas que c'est un changement mineur, mais que ce changement ne signifie pas que c'est absurde d'utiliser le terme CentOS pour CentOS Stream.

Ce n'est pas la première fois qu'un projet, informatique ou pas par ailleurs, évolue et s'adapte. Cela ne me choque pas et ne me pose pas de soucis particuliers. Car je pense que CentOS Stream partage bien plus de choses avec CentOS à l'ancienne que tu ne veux le voir.

Notre désaccord est je pense ici et ce n'est pas grave, je ne pense pas qu'il y a de toute façon une bonne réponse à ce sujet. À dire vrai, je m'en fou pas mal du nommage et de ce genre de considérations, ce qui est important c'est en pratique ce que cela va donner et manifestement c'est trop tôt pour cela.

Il y a un sacré soucis d’honnêteté intellectuelle, chose inhabituelle chez Renault mais peut-être que c'est parce qu'on touche trop son domaine (c'est un classique pour les gens "dedans" d'être objectif sur l'extérieur mais pas objectif sur proche de soit), à parler comme le marketing RH plutôt que de dire que CentOS est abandonné après avoir été récupéré.

Je pense qu'on a surtout une différence de point de vue autour de ça, j'ai donné ma vision, tu as donné la tienne, je ne pense pas qu'on pourra en dire plus avant d'avoir du concret sous la dent (à savoir comment ça va donner avec une RHEL 9 par exemple).

Comme je dis, je comprends tout à fait la différence que cela impose et de ses implications éventuelles. Et moi cela me va ce changement, et je ne trouve pas cela absurde que CentOS garde ce nom malgré ce changement d'orientation du projet car cela n'a rien de nouveau dans ce monde.

Si tu veux, pour mieux coller avec ton discours, tu dis que CentOS est mort, moi non. Mais je peux te concéder sans problèmes qu'une certaine idée de CentOS est morte à cause du changement.

Après que RedHat veuille limiter en même temps les licences CentOS dans un contexte où RHEL serait meilleure, sans doute, même sans preuves je comprends tout à fait que cela puisse être une motivation d'agir ainsi. De la même façon qu'ils ont déjà réduits la documentation autour de certaines mises à jour pour complexifier la tâche de Oracle par le passé. Tu vois, je sais être critique. Mais je sais voir la plu valu de CentOS Stream qui me semble à mon sens plus pertinente que CentOS à l'ancienne mais cela est mon point de vue.

J'avoue ne toujours pas comprendre pourquoi tu arrives à défendre RH la dessus, si encore tu défendais la volonté de RH de tuer CentOS pour des raisons que tu trouves légitimes, mais non la tu copies l'annonce marketing qui enrobe l'arrêt de mort de CentOS.

Je défends RH car je ne suis pas d'accord avec la plupart des annonces catastrophistes ici même qui me semblent bien exagérer la situation. Et qui ne voient pas non plus que cela résulte d'un processus long (CentOS Stream cela ne date pas d'hier) mais aussi que cela ouvre en fait le développement de RHEL ce qui est aussi une bonne chose.

Mais je suis critique aussi, mais je ne vais pas insister dessus car nous sommes d'accord là dessus donc cela n'a pas d'intérêt. Notamment ce qui tourne autour de CentOS 8 et de la baisse de la durée de support initiale de CentOS. J'ai été également critique quand Red Hat a abandonné sa solution maison Pagure pour Gitlab dans Fedora pour le développement. Et pour d'autres sujets encore.

Oui, idéalement j'aurais aimé aussi qu'ils conservent CentOS et CentOS Stream en parallèle, quelque soit le nom derrière chacun. Ils ne le font pas, c'est dommage mais là encore je ne vais pas insister dessus. Et à titre personnel je trouve la solution retenue plus pertinente que l'ancienne quitte à choisir. Mais je comprends que pour certains cela ne sera pas le cas. Et je persiste, je préfère voir en pratique avant d'anticiper un désastre basé sur rien.

Mais je ne vais pas les accuser de tous les maux de la Terre pour le plaisir d'exprimer un désaccord dans cette annonce.

Le gros argument Centos quand on parle avec une production informatique c'est que c'est la MEME chose que RHEL.
au rpm près. avec les mêmes versions. le même code. pas "à peu près".

Ce n'est pas le même dans le temps car il y a forcément une latence induite. Mais les paquets seront globalement identiques, comme par le passé. Tu n'auras pas une CentOS avec le noyau 5.4 quand RHEL sera en 5.2, RHEL récupèrera les versions de CentOS.

Et je ne comprends pas l'argument, Debian n'est pas RHEL, pourtant c'est prêt pour être utilisé en production, en quoi ne pas être identique au bit près (ce que CentOS n'a jamais été par ailleurs) à RHEL empêche de s'en servir en production ?

Vraiment, pour la plupart des usages, être vraiment identique à RHEL n'est pas fondamental, ce qui compte c'est que ce soit fiable et maintenu longtemps. Ce qui sera toujours vrai pour CentOS demain.

Pour preuve, beaucoup ont des infras (petites ou grosses), avec uniquement CentOS. En quoi la correspondance parfaite compte pour eux ? Ce ne seront pas les petites divergences éventuelles qui vont casser toutes les applications, qui d'ailleurs pourront plus facilement tester leurs produits avec ce nouveau workflow qu'avant pour l'éviter.

Tuer CentOS telle qu'elle l'était, ça monte vraiment une volonté de fermeture de la part de RedHat.

C'est au contraire tout l'inverse.

Reprenons, comment avant cela fonctionnait ?

Red Hat décidait à un moment dans l'espace temps de prendre une Fedora version n comme base pour sa future RHEL. En général cela signifie reprendre à peu près les mêmes versions de paquets mais pas toujours pour diverses raisons.

Ensuite pendant souvent 2 ans, Red Hat travaille dessus entièrement en interne. Il publie de temps en temps des bétas. Quand la version v de RHEL sort, alors CentOS peut commencer à récupérer ce travail et produire de son côté sa version et publier les mises à jour.

En gros, RHEL était le fruit d'un travail assez opaque. Sans licences RHEL (payante ou gratuite, car il y en a) tu ne pouvais rien tester du tout car CentOS ne publiait rien. Tu devais attendre la sortie finale de RHEL pour découvrir tout cela.

Le but est de maintenant faire l'inverse. C'est CentOS qui recevra le travail initial. L'infrastructure de CentOS ne changera pas, les contributions extérieures seront possibles. Comme CentOS sera la base de RHEL, son développement devient de fait plus ouvert et moins opaque.

Cela simplifie aussi le travail car la transition CentOS -> RHEL sera plus simple et rapide que dans l'autre sens. Cela permet aussi aux utilisateurs RHEL (qui n'oublions pas payent pour la plupart, donc ils peuvent avoir le droit à un peu plus de stabilité) de bénéficier des retours de CentOS avant. Et rien n'empêche in fine de reconstruire une CentOS à l'ancienne, en se basant aussi sur ce que CentOS publie par ailleurs ce qui est finalement plus simple à faire sans doute.

Par ailleurs, pour rappel les outils pour créer Fedora sont globalement réutilisés par RHEL et CentOS, et le tout reste accessible et documenté. Par ailleurs le dépôt externe de Fedora, RPMFusion utilise sa propre infrastructure basée sur celle de Fedora. Et cela ne changera pas non plus.

La différence c'est que ceux qui font tourner des milliers de serveurs en Centos ils ne veulent pas être bêta testeurs … ils sont même prêt à avoir les patchs de RHEL un peu en retard !

Bêta testeur, il ne manquait plus que cela. Donc pour toi jusqu'ici RHEL c'était la bêta test de CentOS ? RHEL recevait les choses en avance et certains problèmes sont identifiés au niveau de RHEL avant que CentOS ne le voit.

Je pense vraiment qu'il y a une dramatisation. Le but est que CentOS soit la base de RHEL (tout comme RHEL était avant la base de CentOS). L'objectif est d'avoir un cycle de développement plus rapide et d'ouvrir plus facilement les contributions à RHEL de l'extérieur. Le but n'est pas que CentOS devienne un système instable pour tester tout et n'importe quoi et être incompatible avec RHEL dans la foulée.

Oui il y aura des effets de bords dans ces choix, c'est évident, mais tout n'est pas négatif justement d'une part, et d'autre part il n'y a pas besoin de sortir les gros mots en faisant croire que d'un coup CentOS deviendra inutilisable pour la majorité des usages.

Après on verra en pratique à l'usage, mais CentOS ne sera pas Fedora et sera largement prête pour la production.

Redhat n'a pas d'offre spécifique pour les machines hors production (developpement, tests, validation, …) centos permettait de sortir une grosse partie du parc de serveurs des couts de support. C'est certainement cela qui pousse IBM a revoir la copie.

Si, cela existe justement, et Red Hat semble vouloir étendre les conditions d'accès pour combler l'absence d'une CentOS à l'ancienne. Après les conditions ne sont pas encore connues donc difficile de juger sur pièce en l'état.

la CentOS est très utilisé dans l'enseignement supérieur et la recherche. Beaucoup de cluster de calculs fonctionnent en CentOS. Ce sont des milliers de serveurs. La version stream n'est pas du tout adaptée pour ces systèmes où les adjectifs de la première ligne sont très important.

Je ne vois pas en quoi ce changement d'orientation fait que CentOS ne sera pas stable, ni prévisible, etc.

Par contre oui, cette fois RHEL proviendra de CentOS et non l'inverse, mais dans les faits ce sera assez compatible et proche.

Il est complètement redéfini : c'est la base même du projet qui est balancé à la poubelle, sa raison d'être.

Question de point de vue.

Donc pour toi, la GNU GPLv4 deviendrait non libre genre NC (pour les trolls qui adorent le NC et voudraient que ça soit compatible libre) que tu dirais "un peu redéfini"? Désolé mais non, la base du libre est "quelque soit votre usage" comme la base de CentOS est "stabilité de RHEL".

Sauf que ici on garde la stabilité de RHEL à peu près, et la compatibilité avec RHEL à défaut d'être parfaite sera très bonne. Je ne dis pas que cela n'aura pas d'impact négatifs pour certains cas d'usage que CentOS remplissait, mais le monde ne va pas s'effondrer par ce changement, même au sein de l'univers Red Hat.

Je suis convaincu que la plupart des gens ne verront pas la différence en pratique. Car la compatibilité à l'identique n'est pas le seul point d'intérêt de CentOS d'une part, et que globalement il n'y a pas de raison pour qu'une CentOS et une RHEL alignées en terme de versions soient incompatibles.

Après on verra bien, je peux me tromper, mais à partir des éléments communiqués je ne suis pas convaincu par la plupart des opposants à ce changement. Je sais qu'il y aura des utilisateurs vraiment lésés (mais je ne suis pas convaincus qu'ils soient si nombreux dans les faits) et je suis convaincu que le timing est très mauvais : cela aurait dû être fait avant CentOS 8, ou avec une CentOS 8 qui va au bout de son cycle.

Tu veux mon expérience dans la fonction publique (Ministère de l'éducation, Ministère des Affaires Etrangères, Ministère de la Recherche):
- Debian, debian et encore debian

Notons que la communauté Linux en France est très portée sur Debian de manière générale, cela est un peu moins vrai à l'étranger.

Donc si CentOS, n'est plus 100% équivalent de RedHat, ben autant te dire qu'il sera remplacé. Soit par l'achat de licences RedHat soit par un équivalent.

CentOS sera tellement proche de Red Hat de manière générale que si c'est pour une question de compatibilité cela ne sera pas un vrai problème en fait.

C'est même potentiellement bénéfique de ce côté. Avant le travail sur RHEL était interne, aujourd'hui il sera ouvert via CentOS. Donc CentOS au lieu d'être en retard sera un peu en avance. Les outils qui voudront être compatibles avec RHEL pourront utiliser CentOS comme base de travail à ce sujet. Avant il fallait soit une licence RHEL (potentiellement gratuite suivant le cas) ou attendre que CentOS soit sortie soit des semaines ou mois après. En particulier pour les versions majeurs où aucune beta de CentOS n'était disponible.

Ce qui est chiant est que le nom était pour ça. Ils étaient indépendant de RH et vivait leur vie. tiens, RH aime bien et finance, de plus en plus… Pour finalement acheter le nom et tuer le projet.

Tuer le projet, bah voyons.

Je pense qu'on peut émettre des critiques mais pas besoin d'aller aussi loin quand même. Le projet n'est pas tué, ni mort, mais il a été un peu redéfini. Comme tout projet, cela arrive. Il y a des avantages et inconvénients à ce changement et je pense qu'il n'y a pas besoin d'en faire des caisses non plus.

L'avantage en procédant ainsi c'est que justement CentOS devienne un projet qui peut recevoir plus de contributions de l'extérieur (car son but n'est plus uniquement de refaire le travail de RHEL, mais d'intervenir avant). D'autant plus qu'il n'y avait pas de versions beta de CentOS par le passé (donc tu devais attendre que Red Hat ait fini tout le travail en interne avant de bénéficier du saut de version, super). Les amateurs d'une distro stable et gratuite ne seront plus la dernière roue du carrosse comme jusqu'à aujourd'hui avec des mois de latence pour obtenir une nouvelle version et des jours / semaines pour des mises à jour de sécurité.

Pour Red Hat cela permet d'obtenir des retours plus larges avant que cela n'arrive dans RHEL.

Et globalement CentOS restera très proche de RHEL, en terme de compatibilité ce sera pas mal du tout.

En un sens, Red Hat a ouvert sa manière de développer RHEL qui était auparavant un processus entièrement interne et dont CentOS récupérait le résultat. Mais cela n'a pas beaucoup de sens de considérer que CentOS a été tué en procédant ainsi…

Je n'en avais jamais entendu parlé avant, et je pense comprendre pourquoi.

De ce que j'en vois, Debian LTS ce n'est pas vraiment pareil que Ubuntu LTS par exemple. Déjà car l'état de ce projet semble semi-officiel, pas spécialement mis en avant, avec un processus de maintenance différent, par des personnes à priori différente d'après ce qu'ils disent. De nombreuses architectures ne semblent pas concernées non plus.

C'est un support volontaire additionnel, comme Fedora legacy en son temps, ou comme n'importe qui pourrait le faire pour n'importe quelle distribution qui a atteint la fin de son support. En terme de garanties cela semble plus faible qu'une Debian avec un support officiel de 5 ans.

Mais ce n'est pas inintéressant pour autant. ;)

En revanche coté choix j'ai aussi du mal à comprendre. Fedora est déjà un peu la version “early adopters” des prochaines RHEL, j'ai l'impression que CentOS va simplement faire la même chose.

Oui enfin entre une Fedora et RHEL, il y a environ 3 ans d'écart, c'est un gouffre en terme de fraicheur des paquets. Et Fedora a un support d'une moyenne de 13 mois seulement. RHEL est globalement bien plus conservateur encore dans certains choix par défaut (à quelques exceptions près).

Ici le but est de mettre CentOS avant RHEL plutôt qu'après. Mais CentOS resterait assez proche finalement de RHEL en terme de cycles de développement, de fiabilité ou de durée de support par rapport à Fedora.

Pour moi ce changement est pertinent pour de nombreux cas d'usage, et pour Red Hat cela fait aussi pleinement sens. Mais bien sûr il y a des cas où la situation d'avant était préférable.

Je suis d'accord que la transition (ou le timing) n'est pas bon pour cette annonce.

Au lieu de cela, il auraient pu créer un projet parallèle, tout en conservant CentOS.

Le temps et les ressources ne sont pas infini. Si Red Hat ne souhaite plus maintenir un clone parfait de CentOS, c'est leur droit et ta proposition n'a pas de sens.

Notons qu'il y aura probablement des projets pour refaire CentOS comme à l'origine, en tout cas si ça t'intéresse tu pourrais y investir du temps au lieu d'allouer ceux des autres. ;)

Red-Hat n'a jamais donné les clefs permettant de reconstruire RHEL.

Bien sûr que si, n'importe qui peut faire un CentOS like en partant des sources de Red Hat. Il y en a quelques uns dans la nature, et peut être qu'un autre reviendra. Là dessus rien ne change.

Debian propose quelque chose d'équivalent

5 à 10 ans de support, je ne crois pas. ;)

avec toutes les recettes disponibles

RHEL et CentOS aussi…

et travaillent d'arrache pied sur le projet reproductible build.

Je rappelle que la compilation reproductible a aussi de la collaboration de la part de l'écosystème Red Hat d'une part. D'autre part ce projet a plus d'importances pour Debian qui n'a pas une infrastructure centrale pour créer les paquets ce qui l'expose à d'avantage de risques de ce côté.

Cette approche est un argument de choix pour de nombreux administrateurs qui peuvent bénéficier d’une plate‑forme GNU/Linux professionnelle de qualité, supportée par de nombreux logiciels tiers. Qualité à un prix imbattable, puisque CentOS est gratuite mais n’offre pas directement de support.

Je pense que tu résumes bien le point important de CentOS : c'est un système fiable et proche de RHEL. C'est donc un bon choix pour faciliter la maintenance d'un parc sans acheter des licences RHEL pour des postes qui n'en ont pas besoin.

Après, la question est à quel point les utilisateurs ont besoin d'un clone presque identique de RHEL ? Pas sûr qu'ils soient si nombreux que cela en proportion. D'abord il suffit de voir la quantité de Debian dans la nature pour des fonctions similaires à CentOS pour se convaincre que ce n'est pas une catastrophe même pour des systèmes importants (mais pas critiques) d'avoir un système qui n'a pas les propriétés de RHEL en temps de support et qualité de service autour. L'important est que le système soit fiable.

De nombreux parcs utilisent CentOS, par exemple, pour des postes type administratif. Est-ce que le secrétariat d'une boîte a vraiment besoin d'un clone de RHEL ? Je ne pense pas, et en ce sens le changement de CentOS ne les impactera pas tant que cela.

Pour des serveurs non critiques, c'est la même chose, tant que CentOS est suffisamment fiable, être un clone de RHEL n'est pas spécialement essentiel.

Le positionnement de CentOS était difficile depuis longtemps. Car en étant un clone de RHEL en gratuit c'était la dernière roue du carrosse, avec des sorties tardives et des latences dans les mises à jour aussi. Sa plu valu était discutable pour de nombreux cas d'usage.

Ici CentOS va se mettre entre Fedora et RHEL ce qui me semble, de mon point de vue, plus intéressant pour pas mal de monde finalement. Pour ceux qui seront lésés de ce changement, il reste les forks existants ou faire le sien comme CentOS l'était à l'origine vis à vis de RHEL. C'est l'avantage du libre sur ce point.

J'attends de voir en vrai comment cela se passera. Mais je ne pense pas que ce soit la catastrophe.

Je pense qu'on se trompe de débat. Une architecture micro-noyau et l'usage de Rust permettent de limiter certains types d'erreurs ou d'attaques, mais c'est loin d'être suffisant pour dire que leur adoption implique une meilleure sécurité par essence.

La sécurité, c'est un peu comme la performance, c'est transversale dans le projet. Et en plus c'est un sujet assez complexe qui évolue vite, donc faire les choses bien demandent surtout beaucoup d'expérience et de moyens pour les mettre en œuvre.

Si Linux part avec un handicap de ce côté à cause de sa conception et du langage C, il a eu pas mal de fonctionnalités pour contrer ces faiblesses et pour apporter des protections plus complexes. Puis le langage C malgré ses défauts a pas mal d'outils au point pour détecter les erreurs les plus courantes et certaines failles potentielles. Dont les compilateurs qui sont de plus en plus rigoureux à ce sujet. Le recul avec le C est important. Et globalement les développeurs du noyau ont quand même une certaine expérience et s'ils font des erreurs comme tout le monde, ils n'incluent pas des failles à chaque ligne ajoutée non plus.

Donc si la sécurité de Redox OS repose sur Rust et l'architecture micro-noyau, cela ne signifie absolument pas qu'il soit plus sécurisé à utiliser que le noyau Linux en l'état actuel.

non. si tu veux du linux suivi, maintenu, utilisé, tu as systemd avec. Dire que tu peux prendre autre chose, c'est loin de la réalité.

Tu es libre de maintenir tout ce qu'il te faut pour éviter systemd. Tu peux le faire même si c'est long et compliqué.

Personne n'est obligé par contre de t'écouter et de faire ce travail pour toi.

De même si que les distros et autres logiciels trouvent systemd nuls ou pas adaptés à leurs besoins, rien ne les oblige à accepter ce travail par exemple.

Non, il y a d'autres choix possibles ton faux dilemme ne marche pas avec moi.

Ce n'est pas un faux dilemme dans le sens où la question du packaging a des problématiques et des critères de décisions qui n'a pas une solution optimale sur tous les critères. Tu dois faire des choix, privilégier certains critères au détriment d'autres. C'est de ingénierie classique.

Tu peux avoir des parties plus petites et composables pour réduire ce qui est complètement inutile (mon wireshark n'a pas besoin de tout le KDE platform).
Tu peux faire du spécifique à la appimage.

Mais tout ça est possible avec Flatpak justement.

Tout le monde peut écrire son runtime (et donc découper autrement), tout le monde peut faire son Flatpak qui contient toutes ses dépendances à l'intérieur. Mais ça a aussi des inconvénients et c'est pour ça que les Flatpak que tu télécharges n'ont pas choisi cette voie.

Plus tu découpes les runtime, plus la maintenance est complexe, or les gens qui maintiennent ces runtime n'ont pas un temps infini. D'autant qu'ils sont maintenus principalement pour leur écosystèmes respectifs (GNOME et KDE) où donc la majorité des applications qui en dépendent vont en tirer pleinement partis. Puis tu perds en réutilisation s'il y a 20 000 runtimes différents qui permettent d'utiliser Qt 5.15 et que chaque application en utilise un différent.

Ensuite si chaque Flatpak embarque toutes ses dépendances à la AppImage, tu perds les bénéfices liés au runtime en terme de maintenance (dont de sécurité) et en mutualisation de ressources.

Mais bref, Flatpak autorise les comportements que tu décris, mais ceux qui les ont fait ont manifestement choisi de le faire autrement. Et ce n'est pas un mal en soit.

Entre autre parce que si tu utilise flatpak pour installer 25 applications qui demandent la même version de gnome, c'est peut être que tu avais juste besoin d'une distribution avec cette version de gnome.

Ou si je veux avoir la dernière version de GNOME mais garder d'autres composants un peu plus ancien, je fais comment ? Ce n'est pas si simple.

Et tu passes outre les autres avantages de Flatpak : bac à sable, portails, etc.