La distribution CentOS, telle qu’on la connait aujourd’hui, cessera d’exister dans un an. Une décision radicale de Red Hat, largement décriée par la communauté. L’entreprise jure qu’il s’agit d’inclure plus rapidement les retours des utilisateurs dans la gestation de sa RHEL. Mais beaucoup y voient une marque d’avarice.
Red Hat a dans son giron trois plateformes : deux gratuites – CentOS et Fedora – et une payante, Red Hat Enterprise Linux (RHEL). Cette dernière est le produit phare, commercialisé avec du support technique aux entreprises pour équiper les serveurs et stations de travail, aussi bien sur site que dans les centres de données.
Quelles différences alors entre CentOS et Fedora ? Dans les grandes lignes, la première est une reconstruction de RHEL, tandis que la deuxième sert de laboratoire pour tester de nouvelles technologies. Fedora est largement connue pour intégrer en permanence les dernières versions des composants et pour effectuer certaines bascules longtemps avant tout le monde. Wayland est par exemple son serveur d’affichage par défaut depuis 2016.
Toute nouvelle branche de RHEL est initialement un fork de Fedora.
CentOS était initialement un projet indépendant, signifiant « Community ENTerprise Operating System ». Puisque les sources de RHEL étaient libres (et le sont toujours), une communauté s’était formée autour d’un concept simple : pouvoir fournir un système aussi stable que RHEL, mais gratuit.
Bien sûr, cela voulait dire aussi se débrouiller en cas de problème, car aucun technicien ne viendrait à la rescousse. Le succès de CentOS fut en tout cas énorme, au point d’être la distribution la plus utilisée sur les serveurs il y a une dizaine d’années. Une position perdue depuis, mais la distribution reste quand même parmi les plus populaires.
La situation va cependant changer à très court terme. CentOS dispose d’une variante nommée Stream depuis septembre 2019, utilisée comme « rolling release » sur la base de la branche de développement de Red Hat. Depuis qu'elle existe, la frontière est devenue plus floue avec Fedora, même si cette dernière conserve en partie son image d’électron libre et travaille sur des technologies longtemps à l’avance.
Red Hat ne va garder que CentOS Stream
Et Red Hat vient d'annoncer un changement majeur : CentOS n’existera plus dans un an. Comme l'on pouvait s'y attendre, l'éditeur souhaite se concentrer sur Stream et va donc faire disparaitre cette distribution très appréciée.
CentOS 8 – la mouture la plus récente – devait normalement bénéficier d’un support de dix ans, comme les précédentes. Ce ne sera pas le cas : après le 31 décembre 2021, il n’y aura plus rien. CentOS 7, très utilisé, sera pour sa part supporté jusqu’à la fin du cycle prévu, soit 2024. Le support de CentOS 6, lui, s’est terminé le 30 novembre.
Red Hat met l’accent sur sa Developer Subscription, permettant d’obtenir RHEL 8 et autres versions plus anciennes gratuitement. Partout où c’est possible, la bascule est recommandée. Mais il y a un sérieux hic : la formule s’adresse aux développeurs et particuliers, pas aux entreprises. La licence est attribuée à la personne ouvrant le compte, non à un poste, interdisant son utilisation dans le cadre d’un déploiement.
En outre, puisqu’il s’agit d’une formule gratuite, aucun support n’est fourni en dehors des ressources habituelles. Enfin, un même compte ne peut avoir qu’une seule licence Developer attachée. Dans le cas d’une équipe de vingt développeurs par exemple, chacun doit se créer indépendamment un compte pour récupérer sa licence.
Le processus, déjà lourd pour un groupe de développeurs, est clairement inadéquat dans un parc plus vaste. De plus, il faudrait changer de système dès lors que la machine ne serait plus utilisée par la même personne.
La transition entre CentOS et CentOS Stream
On entre maintenant dans une partie floue. Red Hat assure que Stream n'est pas la nouvelle bêta de RHEL. Pourtant, elle est basée sur sa branche de développement, signifiant nécessairement des bugs propres à un code non finalisé. Ce, même si l'entreprise assure que le code publié dans Stream ne l’est qu’après vérification.
La nouvelle orientation est présentée comme un progrès, Red Hat y voyant une distribution « davantage influencée par la communauté, mais gardant la même priorité sur la sécurité, la stabilité et un flux de travail clair pour les développeurs ». La société la présente ainsi :
« Ce n’est pas un remplacement de CentOS Linux. C’est plutôt l’étape suivante, naturelle et inévitable prévue pour atteindre l’objectif du projet, qui est de faire avancer l’innovation autour de Linux en entreprise. Stream raccourcit la boucle des retours entre développeurs de tous bords du paysage RHEL, permettant à toutes les voix – qu’elles émanent de grands partenaires ou de contributeurs individuels – d’être entendues à mesure que nous façonnons les futures versions de RHEL »
Actuellement, la recommandation officielle pour les utilisateurs de CentOS 8 est pourtant de basculer sur CentOS Stream 8. Mais même ceux qui le feront ne seront pas « tranquilles » bien longtemps. Chaque version majeure de RHEL aura en effet sa branche Stream. Puisqu’il s’écoule environ trois ans entre deux versions et que le support est à chaque fois de cinq ans, il existera une période d’environ deux ans entre une Stream et la suivante.
Et même ainsi, ceux qui utilisaient CentOS pour des serveurs pourront difficilement poursuivre avec Stream, car la distribution n’a pas la même orientation : elle doit servir aux tests. Elle n’est donc pas en phase avec les besoins de stabilité et de fiabilité d’un système pour serveur. En outre, puisqu’elle est basée sur la branche de développement, elle n’est pas une reconstruction de RHEL, ce qui était justement la grande force de CentOS.
Trop sans doute aux yeux de Red Hat.
Des réactions très négatives
Depuis l’annonce initiale la semaine dernière, les avis sont en très grande partie négatifs. Il pleut littéralement des reproches et critiques dans les commentaires, et l’amertume ressentie est grande.
« Je n’éprouve que de la colère. Pour chaque serveur RHEL, j’ai dix boites CentOS. Je viens juste de débuter la migration vers CentOS 8. Stream n’est pas une option, j’ai besoin de stabilité et de fiabilité, pas d’une nouvelle Fedora », tempête ainsi Gleen Steen. Un avis qui résume à lui seul la longue litanie que l’on peut lire un peu partout. Le mot « avarice » revient lui aussi souvent pour qualifier le comportement de Red Hat.
Un nombre élevé de développeurs pointent également l’utilisation massive de CentOS pour les tests avant déploiement sur RHEL. Puisque les parités fonctionnelles et binaires sont quasi complètes, CentOS offrait une plateforme idéale pour s’assurer du fonctionnement d’un code avant le plongeon dans le grand bain.
Beaucoup cherchent aussi un responsable à blâmer. Certains penchent pour Red Hat, puisque l’entreprise avait « racheté » CentOS il y a quasiment sept ans. D’autres pour IBM, qui s'est payé Red Hat en octobre 2018 pour 34 milliards de dollars. Mais une opinion ressort clairement : CentOS faisait trop d’ombre à RHEL et a donc été éliminé.
Une pétition a été mise en ligne sur Change.org. Elle s'approche des 10 000 signatures.
Chez Red Hat, on ne partage évidemment pas ces points de vue. Dans un billet de blog (sur lequel les commentaires sont fermés), Chris Wright, directeur technique, souligne ainsi l’utilisation chez Facebook d’un dérivé de Stream pour alimenter des millions de serveurs à travers le monde.
Intel est également cité, le fondeur se disant « excité par le potentiel de CentOS Stream » dans son écosystème client. Red Hat promet que Stream sera la nouvelle autoroute pour les retours de la communauté, mais il semble bien que la communauté, justement, soit vent debout contre cette décision unilatérale.
Rocky Linux et les autres alternatives
Il n’a pas fallu longtemps pour que Greg Kurtzer, cofondateur de CentOS, n’annonce un nouveau projet : Rocky Linux. Il s’agira de reprendre là où CentOS s’arrête.
On retrouvera donc une distribution qui sera une reconstruction de RHEL, puisque les sources de la distribution restent ouvertes. Pour l’instant, Rocky Linux n’est qu’un nom et un concept. Toutes les bonnes volontés sont appelées à se pencher sur le nouveau projet pour s’organiser.
Dans le dépôt GitHub, on peut lire pour l’instant une FAQ revenant sur les points importants de l’annonce de Red Hat et la manière dont la nouvelle distribution sera pilotée, à savoir « par la communauté, pour la communauté ».
En attendant que ce projet avance, plusieurs alternatives sont à considérer et ont été mentionnées dans de nombreux commentaires. Oracle Linux est l’une d’elles, même si la situation peut paraitre étrange : se détourner de CentOS à cause du comportement jugé « oppressif » d’une grande entreprise pour aller vers Oracle ? Et pourtant, Oracle Linux est elle aussi une reconstruction de RHEL avec une parité binaire complète. Elle est gratuite et sa licence est attachée à la machine, pas à une personne spécifique.
Autre distribution souvent citée, Springdale Linux. Il s’agit là encore d’une recompilation de RHEL avec une parité binaire préservée. Éditée par les universités de Princeton et Rutgers, elle est orientée vers les travaux scientifiques.
Cloud Linux est elle aussi une reconstruction de RHEL. Certains hausseront un sourcil : Cloud Linux n’est-elle pas justement une alternative à RHEL, avec un modèle commercial similaire ? Si. Mais l’équipe de développement a rebondi sur la décision de Red Hat pour annoncer qu’une version « séparée et totalement libre » sera proposée durant le premier trimestre 2021, pour combler le vide laissé par CentOS.
La compatibilité avec RHEL est annoncée comme totale. Nul doute que d’ici un an, la situation évoluera encore.
Commentaires (79)
#1
Le plus choquant n’est pas la décision en soi, mais plutôt le timing par rapport à CentOS 8 qui venait d’être lancé.
Une façon de mettre le couteau sous la gorge.
#1.1
Complètement !
Au delà de ça, l’image à la fois de RedHat et de Linux pour l’usage en entreprise va en prendre un coup… non pas auprès des IT pro qui savent très bien que d’autres distributions existent etc., mais auprès des « décideurs » (sic) qui vont voir ici la confirmation d’un « risque » avec des « impacts » et l’occasion de pousser des solutions propriétaires voir infonuagiques à la place de systèmes libres :-(
#2
Je pense que l’annonce a été suivie de trop de commentaires précipitées sans essayer de comprendre le changement dans son ensemble. Dommage que l’article n’essaye pas de prendre un peu de recul car il y a des choses à dire. :)
Déjà je pense que vouloir tuer CentOS tel qu’il existait n’est pas forcément vrai. Red Hat a racheté CentOS en 2014, et CentOS a été pendant longtemps menacé financièrement de mourir. Personne ne payait assez pour l’infra et les autres ressources nécessaires à son développement. Il y a eu des retards colossaux par moment. Et la structure de l’époque n’était pas très transparente. C’est un élément à ne pas oublier, CentOS n’a pas eu une vie paisible avant d’être dans le giron de Red Hat.
Si Red Hat voulait tuer CentOS, ne pas le racheter aurait été peut être plus efficace pour que RHEL reste au devant de la scène.
Ensuite, on associe CentOS Stream un peu trop à une bêta de RHEL mais là encore ça me semble assez exagéré. En fait ce qui fini dans CentOS Stream doit finir dans RHEL. Tout comme ce qui finissait dans RHEL doit finir dans CentOS. Donc à part si tout le monde considérait que RHEL était la bêta inutilisable en prod de CentOS, CentOS Stream ne le sera pas non plus. Cela me semble par ailleurs plus logique que cela se fasse dans ce sens que l’inverse. La QA a beaucoup progressé aussi pour laisser moins de bogues à l’utilisateur final.
Cela implique aussi d’autres choses. Outre le fait que CentOS Stream sera un système stable. CentOS Stream sera compatible avec RHEL aussi. Il n’y aura pas de divergences fortes.
L’autre implication est dans les délais. CentOS a toujours eu un train de retard sur RHEL. Que ce soit pour produire les nouvelles versions ou recevoir les mises à jour de sécurité. Ce qui est aussi une bonne nouvelle, car en prod ce n’est pas forcément souhaitable d’être autant en retard. Avant, CentOS n’avait jamais de bêta. Donc sans utiliser RHEL, il fallait attendre des mois après la sortie de la version finale de RHEL pour connaître le contenu et valider son travail avec CentOS, le temps que CentOS publie la nouvelle version correspondante.
En fait, CentOS Stream ouvre le développement de RHEL. Qui était avant un processus totalement opaque et interne. CentOS derrière ne faisait que recompiler RHEL et apportait peu de correctifs à RHEL. Cela veut dire que sans être employé Red Hat ou un gros client de cette entreprise, il était difficile d’influer le contenu de RHEL. Comme CentOS Stream est public et communautaire en amont de RHEL, cela sera plus facile de le faire.
Je pense que cette annonce est loin d’être le drame décrit partout. Le véritable regret je pense à avoir c’est le sort de CentOS 8, et la réduction du temps de support officiel de 10 à 5 ans. Mais là encore, ce n’est pas une catastrophe même si c’est décevant.
#2.1
L’intérêt de CentOS, c’est d’avoir un système stable et maintenu longtemps. Uniquement. C’est l’unique intérêt pour l’installation sur des serveurs.
Une entreprise ne peux pas s’amuser à migrer ses serveurs et tous ses applicatifs tous les 2 ans pour une nouvelle version d’OS, cela représente une charge de travail, et donc un coût totalement prohibitif.
#2.2
Je partage ton point de vue.
#2.3
Je comprends ton point de vue mais si, pour ceux qui voulaient un système stable et fiable, identique à redhat et un support de 10 ans c’est une catastrophe.
Comme dit MoonRa centos Stream est p-e bien mais ce n’est pas centos. C’est autre chose.
Donc quand on a besoin de centos (stabilité, fiabilité, support de 10ans, identique à redhat) bah on l’a dans l’OS.
Ca sans même parler de la confiance puisqu’on a installé centos 8 en pensant avoir 10 ans de support et finalement on en aura que 2.
#3
Ce qui me choque, ce n’est pas tant l’arrêt de CentOS car je comprends qu’IBM cherche à amortir ses 34 milliards d’une façon ou d’une autre et ne pas faire un CentOS 9 ne me parait pas extravaguant.
C’est plutôt l’arrêt du support promis de 10 ans. Il ne reste plus qu’1 an avant que tous les serveurs CentOS 8 (dont les miens ^^’ ) soient inutilisables. Cela signifie un très gros travail de migration et d’adaptation en peu de temps !
Rompre cette promesse de la longévité du support, voici ce qui est choquant et très décevant !
#4
Cela ne devrait pas, en tout cas avant 4 ans. ;-)
Passer de CentOS 8 à CentOS Stream 8 n’est pas compliqué, ni spécialement risqué. Il y a quand même un peu plus de temps devant toi qu’une année donc.
#5
Migrer de CentOS 8 à CentOS Stream 8, c’est comme migrer de CentOS 8 à RHEL 8 (ou vice versa) dans le fond. C’est un peu de travail forcément mais tu n’as pas un travail de validation complet à refaire car il a déjà été fait.
#5.1
Le problème avec Stream c’est que le paradigme change. On passe d’une copie d’un système hyper stable, c’est à dire sans modifications majeures de version de logiciel, juste des corrections, APRES validation sur le système d’origine (RHEL), à un système dont les mises à jour de logiciels seront plus importantes (ce qui pourra créer des changements pour les utilisateurs) AVANT la validation dans le système d’origine. Cela n’est clairement pas possible pour une utilisation professionnelle en tant que serveur. Sur un serveur, on installe le système, on configure ses applications et après il n’y a que des mises à jour de sécurité à faire (en gros), pas de changements majeurs pendant plusieurs années.
Cette façon de faire ne me pose absolument aucun problème pour un poste personnel ou même une station de travail, j’utilise d’ailleurs Fedora personnellement, mais pour un serveur et surtout pour toute une flotte de serveurs, c’est juste impossible.
Ce n’est pas pour rien qu’il y a tant de retours négatifs sur cette décision.
#6
Tu sembles croire que CentOS Stream va introduire des changements importants pour l’utilisateur en cours de route. Ce n’est pas le cas.
Il y aura évidemment un peu plus de MaJ que par le passé, mais pas tellement et aucune rupture profonde. Tout comme jusqu’ici je ne crois pas que les plaintes aient été nombreuses sur la fiabilité et la qualité des MaJ de RHEL.
Red Hat ne va pas pousser de la merde sur CentOS Stream en flot continue, ce n’est pas le but.
C’est pourtant exactement ce que fera CentOS Stream.
Comme je le disais, je comprends certaines critiques liées à l’annonce. Mais pour moi il y a aussi beaucoup de critiques qui reposent sur du vent, car les gens n’ont pas lu tous les messages pour expliquer ce changement, et qu’ils n’ont jamais utilisé CentOS Stream avant de juger.
#6.1
Stop ce bull shit, RedHat sont indéfendables. Tu bosses pour eux ou quoi?
5 ans de support, c’est très peu. Sachant qu’une distribution n’est pas réellement utilisée avant 1 ou 2 ans le temps que la distribution soit stable, plus le temps que les équipes d’infra le propose et que les dev passent dessus. Une mise en prod sur une Stream 3 ans après la release, parce que oui, les releases applicattive ne sont pas calqué sur les release Stream hein, bah il ne reste plus que 2 ans de support.
Cas concret: Avec un support de 5 ans, ca fait 1 an que Centos 7 ne devrait plus être supportée. Combien aujourd’hui ont migrés 100% de leur production sur CentOS/RHEL 8? On doit pas être loin de 0%.
Et quoi que t’en dise, un bug découvert sur Stream ne passera jamais en RHEL, donc c’est strictement ce qu’on appelle une beta.
Faut bien remettre les choses à leur place, RHEL, c’est avant tout du code libre, produit bénévolement. Ce code n’appartient pas et n’appartiendra jamais à RedHat, même si RedHat contribue beaucoup au libre, leur role principale, c’est de mettre le papier cadeau autour des projets (concrêtement, pondre des RPM).
Le statu-quo était convenable pour tout le monde, Redhat se fait de l’oseil, influence les décisions, mais laisse facilement ceux qui n’ont pas besoin de support la possibilité d’utiliser la distribution à travers CentOS. Plus maintenant.
Quand on voit le tarif prohibitif des souscriptions (accès au repository) RedHat prohibitif, très clairement, Rocky Linux risque très rapidement trouver des contributeurs et prendre son envol.
#6.2
Stream n’est pas l’équivalent d’une distribution linux “stable”, c’est à dire qui ne propose pas de changements radicaux subitement.
si il vous faut maintenir des serveurs à jour, avec des correctifs de sécurité par exemple, vous ne pouvez pas vous permettre de passer à Stream: trop risqué.
Il vous faudra à une autre distribution maintenue à moindre coût que RHEL.
#6.3
Disclaimer: je bosse pour Red Hat, pas dans l’équipe RHEL, ce que j’écris ici n’engage que moi.
Comme a dit un collègue: “C’est à ca qu’on voit qu’on est une boite d’ingés et pas une boite de marketing, on n’a pas su communiquer suffisamment sur Stream”.
Centos Stream != Fedora. Stream n’aura pas de changement radicaux, parce que c’est justement ce que propose RHEL.
J’ai moi-meme été grandement rassuré par ca:
https://blog.centos.org/2020/12/centos-stream-is-continuous-delivery/
#6.4
En quoi CentOS Stream va introduire subitement des changements majeurs que RHEL n’aurait pas ? CentOS Stream sera très proche de RHEL le long de son évolution, il n’y aura pas plus de rupture avec CentOS Stream qu’avec RHEL.
Si tu trouves que RHEL est bien pour la production (et je pense que c’est objectivement le pas), je ne vois pas de raisons pour laquelle CentOS Stream serait différent.
#6.5
Merci pour tes explications.
Il faut comprendre également la vision des intégrateurs logiciels dont je fais partie.
RHEL étant une recompilation sans le support RH, j’ai par habitude d’utiliser Centos en Hors Prod pour ne pas payer de licence en entreprise du hors prod à coût rédibitoire (souvent des versions en virtualisé et non physique donc incompatible avec la licence de base).
En prod, RHEL sans aucun doute et donc aucun changement
En hors prod, la bascule va devenir payante car il faudra utiliser RHEL et non Centos Stream de part le fait que pour les tests applicatifs, il faut les même versions de chaque côté.
Centos Stream étant comme tu l’indiques la prochaine release d’une version, elle peut poser des problème lié au versionning.
Enfin, concernant la logique purement financière, personne n’est dupe y compris chez l’éditeur l’ayant rachété 34Md qui intégre les solutions redhat et les pousse comme jamais.
Soit dit en passant, des bons produits d’ailleurs.
#6.6
Tu pars du principe que les maj sont faites tous les jours.
Bah non, chez l’éditeur qui possède RedHat, ce n’est pas le cas pour la qualification et le suivi de ces produits.
Du coup avoir une maj mensuel ou trimestriel n’est pas un risque en soit sachant que le domaine où j’interviens n’est pas un système critique.
Posséder un Centos et RHEL au même niveau est dès lors largement faisable.
Il y a un point important à ne pas oublier, leur licensing (hors prod) pose problème lié à la gestion de VM.
L’objectif est simple, faire payer la hors prod et\ou tout autre périmète qui ne nécessitait pas une licence avec support équivalent à de la prod.
En me positionnant au niveau éditeur, c’est logique (elle n’est PAS une société à but non lucratif).
Il faut rentabiliser l’un des plus gros rachat d’entreprise de leur histoire.
#7
CentOS vas mourrir, Stream n’est pas son remplaçant, c’est autre chose.
#8
Ça a fait l’effet d’une petite bombe au boulot, on ne pourra simplement plus utiliser CentOS en substitution à RHEL si les versions de packages commencent à diverger entre les serveurs sous CentOS et ceux sous RHEL, d’autant que ça risque de poser problème avec les logiciels commerciaux où des problèmes rencontrés sous CentOS Stream ne seront plus forcement reproductibles sous RHEL.
Et je ne crois pas qu’on soit prêt à dépenser entre 100k et 200k€ par an pour des abonnements RHEL… on attend comment ça décante dans la communauté, pour nous, l’idéal serait de voir le retour de Scientific Linux.
#8.1
C’est exactement le contraire en fait.
Centos Stream correspond a la prochaine release mineur de RHEL.
C’est pour ca qu’il y aura un Centos Stream 8 et un Centos Stream 9 [1]
Les problèmes seront donc plus rapidement corrigés avec Stream qu’avec Centos, qui nécessitait un rebuild à posteriori d’une release de RHEL.
[1] https://blog.centos.org/2020/12/centos-stream-is-continuous-delivery/
#8.2
Je ne vois pas en quoi c’est le contraire, Stream aura des packages plus récents avec des corrections de problèmes existants en avance de phase par rapport à RHEL, mais il y aura aussi inévitablement des changements qui vont apporter de nouveaux problèmes. Et on ne pourra simplement plus se permettre d’avoir un mix RHEL/CentOS sur nos systèmes où tous les packages doivent être à exactement la même version/revision, donc les solutions qui s’offrent à nous sont :
Dans tous les cas, Red Hat n’en sortira pas gagnant, surtout après avoir ébréché la confiance des clients payants ou non.
#9
Ha ok c’est centOS stream c’est pas une rolling release.
#10
Ca dépends ce qu’on entends par “problème” en fait. Les bugs et failles de sécurité en sont certainement. Tout comme l’incompatibilité des nouvelles versions de libs avec les softs installés (typiquement tout ce qui est soft de bases de données proprio). Pour ma part j’attends de voir, mais je peux déjà dire que mes collègues US qui utilisent CentOS pour leurs DB envisagent de migrer vers autre chose (en Europe on a choisi Ubuntu et zéro soft de DB proprio, on est plus tranquilles déjà :p ).
#10.1
C’est la ou je rejoins Renault: beaucoup a été dit “A chaud” sans réellement analyser en fait.
Comme le fait que Stream est un CD, pas une rolling release.
Il ne devrait pas y avoir d’incompatibilité de version de lib, parce qu’il y aura 2 streams: Stream 8 et Stream 9.
Et comme on peut ouvrir un BZ sur Stream, et que Stream est la prochaine version de RHEL, ca permet de detecter les problèmes plus tot, et donc de les corriger plus tot aussi.
Je trouve que c’est gagnant/gagnant: les utilisateurs de Stream ont une version à jour rapidement, et leur rapports de bugs permettent d’améliorer le produit plus rapidement qu’avant. (ie: pas besoin de le reproduire sur RHEL pour être pris en compte !)
Apres, une raison aussi de cette migration est la disponibilité de UBI: maintenant que beaucoup d’applications tournent dans des containers, le niveau d’exigence de compatibilité change.
UBI étant redistribuable, vous pourriez avoir le meme container aux US et en Europe :)
#10.2
Je veux bien le croire, sauf que la réalité de la majorité des services IT c’est : pas de temps, pas de budget, pas de personnel, pas une priorité. Donc le mal est fait parce que les gens vont retenir que CentOS n’est plus une copie sans support de RHEL (ce qui allait très bien à tout le monde) et vont chercher une alternative (comme le font mes collègues) avant même de se poser la question de savoir ce qu’est CentOS Stream.
Quand au fait de faire tourner tous les workloads dans des conteneurs déjà on en est (très, très) loin, et ensuite je crois pas que Redhat soit le mieux positionné pour ça.
#10.3
C’est bien dommage. On ne peut pas fournir un service sans budget (et donc acheter les produits) ni personnel (pour installer et tout maintenir de son côté).
Parce que meme si on est full upstream (Foreman + Centos), ca nécessite du temps pour s’en occuper, du temps pour se former, etc. (Je mets de coté la faible valeur ajoutée perçue)
Si vous avez encore du Centos 6 (EOL le 30 novembre 2020), vous ne devez pas encore etre passé à Centos 8, n’est-ce pas ?
Et le support de Centos 7 est le 30 juin 2024 (Ca n’a pas changé): assez de temps pour passer a Centos Stream donc :)
#11
À part le support de 10 ans, le reste tu l’as globalement avec CentOS Stream.
Vraiment, c’est important de le comprendre.
Et je ne dis pas que c’est un petit changement, passer de 10 à 5 ans j’ai conscience que cela peut impacter du monde.
Tu en auras 5 avec CentOS Stream 8. Ce n’est pas 10, j’en conviens et c’est selon moi le seul et vrai problème.
#11.1
RedHat promet que tu en auras 5. Il promettait aussi que centos 8 en aura 10. C’est pour ca que je parlais de confiance.
Pour la fiabilité et la stabilité je ne pense clairement pas que centos stream, une “rolling preview” sera aussi stable que centos.
Et centos Stream ne sera clairement pas identique à redhat.
#11.2
Quand on prend une CentOS c’est pour avoir une RHEL gratuitement. Si on veut autre chose, on prend une debian, une ubutu, une fedora server, que sais-je. On peut définir la CentOS Stream comme une “Fedora Server ++”, et donc que cela soit encore plus intéressant. Pas de problème la-dessus : ce sera un super truc , mais ce n’est pas une RHEL !
Quand on me demande une machine de préproduction, alors que la production est en RHEL, ce n’est pas pour avoir quelque chose de différent “qui fait plus mieux”, c’est pour avoir la même chose, “bug to bug”.
Ensuite le second point est la perte vertigineuse de confiance de RedHat.. “Ne vous inquiétez pas, nous n’allons pas vous enlever du jour au lendemain le driver de votre carte RAID dans une update, parce qu’il est obsolète et qu’il nous gêne”.. Cette phrase était crédible…. avant… Mais après avoir vu que la CentOS 8 va disparaître le 31 décembre 2021, malgré le support de 10 ans “affiché”, cela le devient beaucoup moins.
Donc la CentOS Stream sera certainement une excellente distribution. Mais personnellement, je ne la prendrais pas.
#12
Je vais me faire l’avocat du diable mais un système stable, fiable et avec un support de 10ans, ça a un coût.
Actuellement, ce coût était payé par les clients de Red Hat pour tous ceux qui utilisaient gratuitement CentOS (en gros, c’est le support de RHEL qui servait de support indirect à CentOS).
C’est finalement assez étonnant que CentOS ait duré aussi longtemps….
#12.1
L’un et l’autre ne sont pas opposés. On peut être client de redhat et utiliser centos.
Et je comprends leur choix, ca n’empêche pas que ce soit une mauvaise nouvelle.
#13
Merci pour cette synthèse globale posée. Je ne savais pas trop quoi penser dans cette cacophonie émotive cette semaine.
Je basculerai mes serveurs perso de la branche 8 à Stream, ça n’est pas trop un soucis de ce côté.
Côté taff, j’ai alerté les différents projets car généralement la dette technique est toujours mal prise en compte (on a encore des CentOS 6 qui traînent c’est dire …). Le support à 5 ans aurait tendance à mieux accélérer les choses, mais les entreprises n’aiment pas non plus avoir le couteau sous la gorge.
#14
Beaucoup de bruit pour rien en fait, quand j’utilisais encore CentOS, j’aurai préféré avoir CentOS Stream plutôt que d’avoir a gérer le passage entre les versions mineures.
Merci a Renault pour les clarifications
#15
Je suis curieux d’avoir ton avis la dessus :)
#16
Je ne bosse pas pour eux.
J’estime mon propos argumenté et basé sur assez de faits pour qu’on évite de tomber dans ce genre d’accusations, merci.
Une des raisons pour laquelle certaines applications métiers tardent à support CentOS Stream ou RHEL c’est que justement CentOS sort très tardivement après la sortie d’une RHEL… Les versions de développements étant réservés à certains.
Or CentOS Stream aura une disponibilité des versions de développement bien plus tôt. Cela aidera les éditeurs tiers à supporter les nouvelles versions de CentOS / RHEL plus vite.
Tu oublies que CentOS 8 est sortie avec cinq mois de retard sur RHEL 8, et qu’il n’y avait pas de Beta comme RHEL a pour tester quoique ce soit avant la sortie finale.
Cela ne sera pas le cas à l’avenir. Non pas que ce soit parfait, mais tu ne peux pas comparer les deux situations comme ça sans tenir compte du contexte qui a changé.
Donc RHEL était une Beta de CentOS jusqu’ici ? C’est absurde !
Red Hat est l’un des plus grands contributeurs au hasard de GNOME, systemd, le noyau Linux, la pile de virtualisation, etc. Une paille.
Bien sûr que Red Hat n’a pas écrit tout le système seul, mais on ne doit pas pour autant retirer leur énorme valeur ajoutée dans les autres projets libres qu’ils embarquent.
#17
+1 N’en déplaise à tous ceux qui essaient de minimiser l’impact
#18
C’est ta mauvaise foi qui me fait dire que tu as des intérêt lié à RedHat. Tes arguments n’ont aucun sens sur de la prod, à moins simplement que tu ne saches pas de quoi tu parles.
5 mois de retard sur un support de 8⁄10 ans, on s’en sort très bien, je te rassure.
5 mois de retard, c’est rien. Il faut de toute façon au moins 2 ans pour migrer une plateforme, ensuite 5 ans d’exploitation avant de passer à la release suivante, et encore 3 ans bonus pour encaisser les retards ou laisser mourir les projets qui arrivent à terme. Avec un overlap de deux versions majeures de 4 ans.
Stream c’est 5 ans. Le début de Stream 9 signe la fin de support de Stream 8. Aucune boite ne proposera le support de Stream car ca veut dire qu’elle devra adapter, tester et fournir une version final les quelques jours d’overlap de deux version majeures de Stream. Pareil pour une prod, aucune DSI qui sait ce qu’elle fait n’ira sur Stream.
Ah donc tu penses que magiquement toutes les boites du monde vont migrer toutes leurs infra de Centos Stream 8 à Stream 9 en quelques jours? Comme dit plus haut, soit c’est de la propagande, soit tu sais pas de quoi tu parles.
Ce n’est pas ce que j’ai dit et ca n’a rien à voir. Les bugs identifiés dans RHEL se retrouvent dans CentOS quoi qu’il arrive.
C’est exactement ce que j’ai dit, RedHat contribue beaucoup au libre et propose une distribution serieuse pour la communauté et donc est apprécié de la communauté. C’est un deal gagnant/gagnant et RedHat gagne déjà beaucoup d’argent avec cet état. IBM veut maintenant gagner plus, au détriment de la communauté.
Ce que RedHat fait ici, c’est d’inverser le sens de la contribution. C’est n’est plus RedHat qui contribue au libre, mais la communauté qui contribue à RedHat. Et je pense que ca ne vas pas bien se passer car au final, ce sont les dev du libre qui décident.
#19
Ce que RedHat devrait faire d’urgence, c’est rendre RHEL8 en self-support gratuit.
Parceque bon, le dégât reste surtout au niveau de l’image: RedHat a pris le contrôle un projet communautaire et l’a transformé pour ses besoins quitte à faire fi de la communauté d’origine et des raisons pour lesquelles elle l’utilisait. Centos a réeussi à montrer l’impossibilité de construire une vision long terme en abandonnant une plateforme qui était supposée vivre encore quelques années, posant la question: quel sera le prochain changement d’avis avec abandon des engagements.
De plus, en l’absence d’un RHEL 8 gratuit sans support, les utilisateurs vont se diriger vers des alternatives comme Oracle Linux qui se permet le luxe de jouer les chevaliers blancs… un comble, à moins que le but soit justement de filer des clients à Oracle qui offre un clone de RHEL gratuit, sans support et avec un basculement vers le support pro très aisé (contrairement à devoir réinstaller l’OS pour passer de CentOS à RHEL)
Et qu’on ne me dise pas que proposer RHEL 8 gratuit sans support reviendrait à affaiblir la marque, IBM-RedHat arrive déjà très bien à défoncer la perception de valeur de ses produits en fourguant Openshift perpétuellement gratuit à l’achat de solutions “cloud pak”. Ici, maintenant, ce qu’il faut, c’est redorer l’image en faisant un geste peu couteux réaffirmant la solidité de l’écosystème.
#20
Ca ne suffisait pas à RH de pourrir la vie des adminsys avec systemd, maintenant c’est le coup de grâce…
Ils sont bien gentils avec leur f*ing licence dev, mais il faut la renouveler manuellement tous les ans, du coup on se retrouve avec une journée de perdue à essayer de naviguer sur leur site atroce pour retrouver où faire ça…
#21
Sérieusement, moi j’aime plutôt bien Systemd. Cela a ramené pas mal d’ordre et de standardisation dans des problématiques qui viraient vite au foutoir quand on installait des produits tiers. J’en avais vraiment marre de devoir réécrire les scripts init des différents fournisseurs parcequ’ils étaîent bâclés ou absents.
Pour le reste, l’entitlement dev a bien peu d’intérêt, et pour le coup CentOS streams et Fedora sont des alternatives tout à fait acceptables.
#22
Encore que je pense que la question de la stabilité de CentOS 8 Stream reste à affiner, ce qui est beaucoup plus tragique et inexcusable, c’est la fin du support de 10 ans, qui était la marque de fabrique indissociable de CentOS, allié à une distribution de qualité pour l’entreprise et très utilisée (même si peu connue par le grand public et les informaticiens du dimanche, ce n’est pas une tempête dans un verre d’eau, c’est juste une grave atteinte à l’écosystème GNU/Linux en entreprise). En tant qu’admin, je privilégiais CentOS pour les machines qui soient ont besoin d’une forte pérennité, soit qui ont une exigence de compatibilité RHEL, et ben la il ne me reste que Ubuntu Server et ses 5 ans (Debian c’est trop court, et je n’ai pas confiance au support LTS tiers).
#23
Non pas encore de CentOS 8 mais j’espérais pouvoir en avoir pour les plateformes de CICD.
M’enfin, j’ai pété les burnes toute l’année justement pour dégager CentOS 6, donc y’a le temps justement. Mais j’aimerais que pour une fois ce soit réfléchi au moins 2 jours avant la EOL de la distrib…
#24
Disclaimer: je bosse pour Red Hat, pas dans l’équipe RHEL, ce que j’écris ici n’engage que moi.
Je souhaitais ne répondre qu’au dernier point, mais je fais une réponse plus complète au final.
Ben pas forcement.
Quand tu bosses upstream, que tu veux monter un CI/CD, les 6 mois de retard entre Centos et RHEL font très mal, justement:
OpenStack, 1 release tous les 6 mois.
Kubernetes, 1 release tous les 3 mois.
Et comme il n’y avait pas de beta de Centos 8 dispo, ben… c’était une vraie galère à gérer.
En tant que dev upstream, je suis content de ce que Stream peut apporter.
Ca soulève d’autres questions aussi, comme le support des anciennes branches, vu que Stream est en CD.
Je peux aussi dire qu’aucune DSI qui sait ce qu’elle fait n’ira sur un OS sans support, ou sans les personnes qui savent supporter l’OS, mais ca ne fait pas avancer le débat, n’est-ce pas ?
Stream n’est pas une beta. Ca sera déjà une selection de patchs, testés upstream, puis downstream, avant d’être intégré dans stream. On est loin d’une version beta.
La, il s’agit d’avoir une meilleure integration, et une meilleure visibilité du boulot effectué en interne.
Tu y vas très fort je trouve ! (C’est ce qui m’a choqué dans ton post).
Dire que Red Hat ne contribue plus au libre est méconnaître l’engagement de Red Hat. Ce n’est pas simplement “emballer dans du papier cadeau les sources fournies”.
Les dev bossent upstream first. Et ils continueront ; ll continueront de gérer des communautés; ils continueront de gérer des projets; ils continueront d’héberger des confs virtuelles tant que le Covid ne permettra pas des rencontres physiques, etc.
Fedora reste Fedora, rien ne change ici, tout comme la fourniture des SRPMS ; Il n’y a aucune inversion de quoi que ce soit.
L’engagement open source avec les utilisateurs est meme renforcé avec Stream je trouve: (avis perso, encore une fois, je ne travaille pas dans l’équipe RHEL / Centos)
#24.1
C’est bien de bloquer les updates dans TheForeman, mais c’est encore pire, tu n’es simplement plus à jour… justement le fond du problème.
Avec une release majeur RHEL tous les 4,5-5 ans et un support de Stream de 5 ans. Pendant combien de temps sera l’overlap de maintenance Stream 8 et Stream 9? Aucun? 1 mois? 6 mois comme Fedora?
Parce que même 6 mois pour que:
,c’est évidement fait pour que plus aucune prod de tourne sur CentOS et donc forcer la migration vers RHEL. Je ne doute pas de ta bonne foi, mais dire le contraire, c’est ne pas voir l’évidence et propager un mensonge qu’on vous balance en interne.
La vrai vie de la prod, c’est de gérer plusieurs projets en parallèle et se mettre des contraintes d’update d’une prod complète en 6 mois, ca veut dire “n’utilisez surtout pas Stream en prod”.
En tuant CentOS, un autre projet va venir le remplacer, mais ca va prendre une bonne paire d’année et pendant ce temps la, beaucoup auront migré sur RHEL8. C’est de la pure décision business de gens qui n’ont jamais tapé une ligne de commande de leur vie.
Ok alors si Stream est si bien, que les patchs sont testé et validé, que tous vas plus vite pour le mieux sans rien casser, pourquoi RHEL n’est pas Stream aussi? A t’entendre, RHEL c’est obsolète… non ?
#24.2
Tu peux bloquer les updates le temps de valider ces updates. Rien de plus.
Concernant le recouvrement Centos Stream 8⁄9… faudra voir quand 9 sortira, je n’ai pas les infos.
Apres, si tu supposes que tout le monde ment en interne, je n’y peux rien…
Je comprends certaines reactions, mais il ne faut pas non plus penser que tout le monde a un master plan pour faire chier le monde.
Beaucoup de decisions, bonnes ou mauvaises, sont prises de bonne foi, avec les informations dont on dispose à un moment donné. (Et encore une fois, la decision est prise par le board de Centos … qui ne contient pas que des employés Red Hat)
En tant que dev upstream, je vois Stream comme une vraie opportunité pour le CI/CD, mais aussi pour la prod (Facebook tourne avec un Centos et leur kernel par exemple, mais ils ont les équipes kernel pour du self-support).
D’un point de vue prod, je vois 2 cas:
#24.5
“Beaucoup de decisions, bonnes ou mauvaises, sont prises de bonne foi, avec les informations dont on dispose à un moment donné.”
Il n’y a pas de “décisions de bonne foi” dans une boite qui vaut 34 milliards, il n’y a que des dollars sonnant et trébuchants.
A part si le big boss est actionnaire majoritaire et est convaincu par la philosophie du libre, les décisions du top management n’iront jamais dans le sens de la beauté de la technique, et encore moins dans le monde “obscur” du libre que les businessmen ne comprennent pas.
Autant pour nous, la philosophie derrière un projet à toute son importance, autant pour un décideur qui gère les dollars, un business, c’est de l’argent qui entre, de l’argent qui sort, et comment on maximise le profit tout de suite.
IBM, on voit où ils sont aujourd’hui, une société de dinosaure qui essaye de faire du profit sur son trésor de guerre accumulé pendant qu’ils savaient encore faire quelquechose. Ils ont acheter une boite, RedHat, 34Mds, elle doit maintenant rapporter beaucoup, le plus vite possible.
Croire que l’arrêt de CentOS, c’est pour le bien de la communauté et la promotion de la CI/CD, c’est juste ne pas voir l’éléphant dans le corridor. Tout ce qui se trouve entre la décision initial de tuer CentOS et la finalité qui est que la communauté n’aura plus de système d’exploitation iso-rhel sans support, c’est du détail pour geek en quête de beaux principes.
Quant au board de CentOS, chapeauté par RedHat, lui même chapeauté par IBM… on sait qui décide au final.
Bon, je vais m’arrêter, puisque ni toi, ni moi ne se laissera convaincre.
#24.3
Je vais me faire l’avocat du diable 5min, mais de mon expérience le cycle de vie logiciel est toujours horriblement négligé.
Comme je disais dans mon précédent commentaire, les CentOS 6 que nous avons en production n’ont commencé à être remplacées que cette année (après avoir tanné le pion des PO pendant plusieurs mois) … Et du fait que le client utilise un miroir local pour yum, la bascule vers le repo Vault ne s’est pas faite naturellement provoquant une erreur 404 partout. Très pratique pour des déploiements automatisés quand toutes les tâches yum se bananent à cause de ça. Bref.
Le cycle de vie logiciel doit être embarqué dès la naissance du projet. Ca s’anticipe et ça se budgétise comme n’importe quel autre composant de l’application.
Chez la plupart des clients où je bosse, le choix de CentOS a été simple : c’est gratuit, point. On nivelle constamment l’infrastructure par le bas tout en se mettant des contraintes fortes de disponibilité et de durabilité : c’est un oxymore pur et simple. Ca gueule que l’uptime de l’appli n’est pas à 99% mais ça refuse de mettre la moindre redondance pour encaisser un déploiement continu transparent.
Personnellement je suis partisan du choix le plus adapté au besoin et non du choix dogmatique “parce qu’on fait comme ça picétout”. De ce fait, j’estime qu’il faut savoir prendre en compte dans son TCO l’obsolescence logicielle et si l’application est trop critique ou que le besoin de support à long terme (comme les 10 de RHEL) sont vitaux, dans ce cas on prend RHEL. Et par défaut CentOS pour du moindre coût, mais en acceptant l’absence de support éditeur (démerde toi avec le Web et les forums) et désormais, un support moins long.
#24.4
Tu décris bien la réalité et tu dois savoir comme moi que très peu de boites font de la CI/CD pour le déploiement de leurs OS. Et qu’aucune ne sera capable d’upgrade un parc de milliers de machines en moins de 6 mois. C’est dommage, mais c’est comme ca. Donner Facebook comme exemple (Tophe), c’est facile, avec une armée de sysadmin à gérer le moindre flag du moindre fichier de conf, et surtout une autre armée capable de tout customiser et maintenir cette customisation.
C’est malheureux, mais les boites qui font de la tech pour faire de la tech, il n’y en a pas beaucoup.
Ensuite évidement que le prix est le facteur important dans le choix de CentOS vs RHEL. Et c’est bien pour ca qu’IBM arrête CentOS, pour tenter de rameuter du monde sur RHEL et gagner encore plus. Ils s’en tapent de CentOS vu que ca ne rapporte pas de dollars directement dans leur poche (34 milliards, il faut de la rentabilité). Typiquement une vue de stratégie business court terme. Il n’y a pas besoin d’entrer dans les détails pour voir l’évidence.
“IBM tue CentOS, les boites doivent choisir entre payer des peoples a gérer deux OS différents (Stream 8 va s’arrêter la ou RHEL 8 existera encore 5 ans) ou payer”
L’avantage du mix rhel/centos, c’est de pouvoir mettre du support là où t’en a besoin, machines critiques, prérequis applicatif externe, frontaux publique, et sans devoir rien changer à ton provisioning (autre que l’url du repo), de pouvoir mettre aussi du centos pour gérer tes serveurs de dev et preprod et autre serveur à la con type ntp. La décision maintenant, c’est de savoir si il faut lacher 5000€ de plus par an par hyperviseur pour le dev et la preprod, s’il faut switch sur autre chose, ou si on attend patiemment le remplacant de centos (unbreakable linux? fuck)
#25
Autour de moi on utilise surtout Debian, le support est moindre (coucou python-lxml2 pété il y a 2 jours sur Debian stable, pour les apps pas encore migrées sur Python 3), mais on a rarement des problèmes. On doit pas avoir les mêmes nécessités qui obligent à avoir un support sur 10 ans, mais ça nous semble généralement stable.
#26
C’est exactement ne pas connaitre Red Hat: le CEO, CTO, et le management de RHEL sont tous convaincus par la philosophie du libre. On peut ne pas être d’accord avec leur decision, mais tu devrais au moins écouter ce qu’ils disent.
Exemple simple: regardes les entreprises rachetées par Red Hat: toutes celles qui avaient du code source fermé sont devenues open source. Ca prend forcement du temps, mais c’est ce qu’il se passe.
Et jusqu’à present, cette amour du libre permet d’avoir des nouveaux clients et de recruter des ingés aussi convaincus qui comptent et contribuent upstream. (beaucoup ne font que ca d’ailleurs !)
Et pourquoi changer quand le CA augmente ?
Et pourtant, parfois, il serait tellement simple de pousser un patch downstream only pour corriger un bug ou ajouter une feature, mais non -> tu expliques au client qu’il va attendre 6 mois le temps que ca soit discuté/revu/re-discuté/accepté upstream puis qu’il devra faire une mise à jour pour être sur la prochaine release.
Parce que Upstream First. C’est contraignant, mais c’est la philosophie de la boite.
Ben… le board de Centos. Tu peux interpeler les membres non-Red Hat leur demander leur opinion là dessus: ca sera le plus simple !.
Je comprends qu’à resources constantes, tu ne peux que faire des choix. Ils essayent de résoudre 1 probleme, c’est devenu un PR Hell; je n’y peux pas grand chose, à part dire qu’il n’y a pas de master evil plan.
Pour preuve ? Regarde Oracle qui appelle du pied les utilisateurs Centos.
A mon avis, un utilisateur Centos ne payera pas pour du RHEL, ou pour du support d’une autre entreprise. Meme ce master plan pour les “forcer” à passer sur du RHEL ne fonctionne pas: ces personnes utilisent Centos 7, qui est encore supporté jusqu’en 2024.
D’ici là, soit Stream aura fait ses preuves, et ils migreront tranquillement en étant rassuré, soit ils seront passés sur autre chose (Scientific Linux / Rocky Linux / autre distrib derivée de RHEL.
Et dans les 2 cas, l’utilisateur ne paiera pas.
La culture d’entreprise est juste … différente … d’une autre grosse taule.
Mais je conviens qu’il faut le vivre pour le comprendre.
#26.1
J’avais dit que j’arrêtais :S
Ca c’est sure, très peu payerons du RHEL là où CentOS était utilisé, et le peu qui payeront sera compensé par le nombre qui migrerons vers une autre distro.
“The CentOS Project
Community-driven free software effort focused on delivering a robust open source ecosystem around a Linux platform. “
A en croire le forum, commentaires refusés sur le thread de l’annonce: https://forums.centos.org/viewtopic.php?f=54&t=76600
Ou a en croire le blog: https://blog.centos.org/2020/12/future-is-centos-stream/
Je n’ai pas l’impression que CentOS soit très “community-driven”, comme ils disent, mais bel est bien business driven.
Il y avait une autre solution simple si l’objectif n’était pas le benef a court terme: Faire une RHEL Stream + RHEL et CentOS Stream + CentOS…
#26.2
C’est pour ça que j’ai dit “à ressources constantes, faut prendre des décisions”.
Et donc non, la capitalisation boursière n’a pas d’impact sur les budgets. Le fait d’être racheté par IBM (parce que c’est ça qui semble t’influencer) n’a pas changé ma vie jusqu’à présent.
Je n’en sais rien côté sales, mais côté engineering, CNET’s business as usual.
Haters gonna hate: les gens qui ralent sont forcément plus vocaux. Et bcp ralent simplement parce que ça change.
Leur vie ne change pas, pour certains, Stream pourraient simplifier leur vie, mais je crois que bcp ont râlé à chaud.
Donc bad Buz et PR Hell.
Au lieu d’être en retard, Centos aura un bug fix d’avance. Pour autant, il n’y a pas de raison de casser la compatibilité, ou ça la cassera aussi sur RHEL=> pas de changement à ce niveau.
D’où les 2 versions Stream 8 et Stream 9.
Avec Centos, tu avais aussi un délai entre la sortie mineure de RHEL et celle de Centos.
Donc la compatibilité exacte ne pouvait pas se faire, sauf si tu bloquais la release de RHEL avec Satellite.
Chose que tu peux faire côté Stream, n’est-ce pas ?
Il y a le coût du tooling, mais tu dois déjà avoir déployé un foreman/satellite, c’est donc le coût de la conf initiale à absorber, pour pouvoir fournir la version de Stream correspondant à la version de RHEL. Ce que tu faisais dans l’autre sens pour avoir les mêmes versions releases entre RHEL et Centos.
Ainsi, Stream te fournit le même service (memes versions), avec un délai reduit à zéro, tout en ayant une vision sur les prochains fixes qui arrivent dans RHEL, pour mieux tester/préparer tes applis et des déploiements vers la prod.
Ainsi, Stream est une avancée pour toi, non ?
#27
En fait la CICD pour les OS, c’est l’Infrastructure as Code. A titre personnel je travaille avec des couches plus élevées que l’OS qui n’est qu’un service à mes yeux, si j’ai besoin d’un environnement c’est un rôle Ansible qui va me le faire. C’est un niveau d’industrialisation qui est vraiment plaisant
(et sans passer par du Cloud public fancy pour le coup, derrière c’est du VMWare à papa)
C’est par contre un investissement de départ assez élevé, mais pour te donner une idée du ROI dans mon contexte, on est passé de 2 mois à 2 jours pour fournir une instance applicative d’un ERP assez lourdingue prête à l’emploi (temps de provisionning de VM, mise en place des prérequis infra, installation des composants, toutes les paramétrages métier en veux-tu en voilà … tout ça c’est en très grande partie automatisé). Si on avait pu pousser la redondance, les migrations auraient même pu se faire de manière relativement transparente, sauf au moment de changer la base de données. Mais les frontaux et back auraient pu être intervertis de manière transparente, dommage.
#27.1
Je te rassure, j’ai bien compris.
Je ne préfères pas entrer dans les détails, mais c’est la même par ici, IaC full on-prem. Mais on dérive du sujet…
#28
My 2 cents :
On peut retourner l’annonce dans tous les sens, c’est un gros bras d’honneur de la part d’IBM/RedHat vis-à-vis de la base d’utilisateurs qui utilise CentOS. Ca aurait été acceptable pour CentOS 9, mais là c’est inexcusable de ramener le support à 1 an alors que le support de CentOS 8 était calé sur RHEL 8 et prévu jusqu’en 2029.
Je comprends la stratégie derrière de ne conserver que CentOS Stream qui est (quoi qu’on en dise) l’antichambre de RHEL 8 en étant upstream (mais avec les CVE qui restent downstream ca va être rigolo à gérer). Là en tuant le CentOS historique, ils coupent les pieds de ceux qui veulent simplement une release downstream compatible bug pour bug avec RHEL 8.
Au final, ceux qui ne veulent/peuvent pas basculer sur CentOS Stream, il reste 3 options :
Nous concernant, on ne passera par sur CentOS Stream pour tout un tas de bonnes raisons que je ne détaillerai pas ici. On a mis en pause les migrations vers CentOS 8 et on n’a pas encore décidé ce qu’on allait faire. En tous cas notre chargé de compte RedHat (car on a aussi des licences RHEL et RHEL for VD) va avoir droit à un beau mail.
#28.1
On est à peu près à la même situation. Un gros millier de serveurs et/ou VM à migrer. Tout en centos, même pour la prod. Pour le moment, on continue la migration vers centos8. On se donne 6 mois pour choisir.
Après avoir viré Oracle pour Postgresql, ça serait “amusant” de se tourner vers Oracle pour du libre. Sauf que les expériences précédentes avec java, entre autre, ça n’incite pas à la confiance non plus.
#29
La première chose à faire est d’arrêter de lier Stream à CentOS comme le fait le marketing RH, vu que ça n’a rien à voir et que les marketeux se sont dit qu’annoncer tuer CentOS n’était pas fun donc qu’il reprenaient le nom pour un truc qui n’a rien à voir.
Ce n’est pas que vous n’avait pas su communiquer suffisamment sur Stream, c’est que RH a repris un nom X pour un produit Y qui n’a rien à voir, ce n’est pas ne pas savoir, c’est avoir des marketeux les plus de mauvais foi (et ils sont payés pour).
Le problème est inverse : vous avez d’assez bon marketeux pour convaincre quelques personnes (y compris en interne?) que Stream a un lien quelconque avec CentOS, bon c’est tellement gros que pas assez de monde est convaincu, raté mais le fait que quelques personnes soient convaincues de la chose et essayent de défendre l’indéfendable de RH, perso je dirai que ça empire même les choses.
Bref, ce n’est pas que vous n’avez pas su communiquer, c’est que la tentative de cacher se débarrasser de CentOS n’a pas marché.
(et on s’en fou de Stream, ce n’est pas le sujet, quelque soit votre communication sur lui)
#30
Les seuls CVE qui seront gérés downstream sont ceux où Red Hat a une clause de confidentialité à respecter le temps que les éditeurs aient un correctif sous la main avant de dévoiler la faille à tout le monde.
Cela ne concerne donc pas tous les CVE, et en général ces délais sont raisonnablement courts. Je ne pense pas que cela soit un travail si difficile à gérer.
Mais les versions seront globalement identiques. Tu crois que quand tu faisais “dnf update” sur RHEL et CentOS tu avais exactement les mêmes versions tous les jours ? Bah non, il y a toujours eu de minimes différences, car CentOS a toujours eu de la latence dans ce processus. Ici ce sera pareil mais dans l’autre sens, RHEL aura un chouilla de retard. Et il y a des outils pour t’aider à avoir deux systèmes avec les mêmes composants…
Pas tellement plus qu’avant en fait.
#30.1
Stream support 5 ans
Rhel support 10 ans
Tu fais quoi les 5 dernières années?
Comme le dis Jerôme7573, Centos est tué par RedHat et essaye proposer une upstream bêta en remplacement, ça n’a juste rien à voir.
#31
+1.
J’ai un copain qui a une boîte de services informatiques, et qui met du CentOS sur les serveurs qu’il installe chez ses clients. “Pas content” est un euphémisme pour décrire ce qu’il pense.
En ce moment, c’est vers Debian qu’il se tourne. Ses clients veulent du rock-solid, pas du beta-test, et il n’a pas vraiment le choix. COmme il a déjà monté des serveurs sous Debian stable pour certains de ses clients sur demande explicite de ces derniers, ça sera pas trop un choc pour sa boîte, mais ça fait vraiment skier.
#31.1
Une image plutôt qu’un long texte sur ce que je pense de ce comportement des clients (les miens inclus).
A mes yeux, le principal foirage de Red Hat c’est d’abandonner le support long terme de CentOS 8. Même si la branche 8 de Stream est supportée 5 ans, c’est un doigt dans le cul avec un ongle de sale en termes de comm et de décision.
L’annoncer pour CentOS 9 aurait déclenché un bien moins grand shitstorm je pense, en laissant le temps aux clients de repenser leur stratégie.
M’enfin, 5 ans ça laisse aussi le temps de voir les choses … Pour avoir connu un ERP dont l’éditeur a été racheté par un fond US et la licence qui a fait x3 dans la foulée, là dans le cas présent le projet était dedans jusqu’au dernier cheveu.
#31.2
Quand tu as un serveur qui sert à ta boîte pour faire de la VPC, le fait que la distro qui tourne dessus est abandonnée en rase campagne par son développeur comme un clebs sur une aire d’autoroute, t’es pas très rassuré pour la pérennité de ton business. Heureusement que le prestataire de service (mon copain) t’a expliqué qu’il a de quoi remplacer, parce que sinon, t’étais mal. C’est le cas de 90% des clients non-institutionnels de mon copain…
Par chance, il n’a pas fait beaucoup d’installation/migrations vers CentOS 8, mais il va avoir du boulot en plus (et à ses frais) pour ceux qu’il a déjà migré. Avec de gros clients VPC/industrie/services dedans, le genre qui veut pas du beta-test sur le serveur qui gère leur flotte de camions avec positionnement GPS en temps réel, leur serveur d’affacturage clients/fournisseurs ou leurs machine-outils, pas le genre de comique qui veut niquer les GAFA avec un budget de PME de 10 salariés.
Eux, tu leur explique que dans le cadre de la garantie, tu vas leur mettre du Debian Stable sans supplément de prix sur leurs serveurs, et que ça ne changera rien pour eux à tous points de vue, tu gardes le contrat.
Les alternatives proposées, mentionnées dans l’article, pour celles qui existent, ça ne correspond pas aux besoins de ses clients.
#31.3
Ma remarque était plus destiné à ceux qui pleurent CentOS parce qu’ils perdent une distrib gratuite supportée 10 ans tout en fixant dessus un SLA délirant en voulant éviter de débourser pour du RHEL ou équivalent.
J’aime pas cette vision en fait. Perso ça me saoule d’entendre gueuler que l’appli n’a pas assez de redondance mais d’avoir l’impression de demander de financer le programme Apollo dès qu’il s’agit d’en rajouter.
Le fond de l’image, c’est pas un comique qui veut créer le nouveau facebook avec 3 francs 6 sous, c’est mon quotidien où tout le monde veut de la scalabilité, de la redondance, de la performance, mais pas à plus de 10€/mois.
Concernant les alternatives proposées, c’est con, mais Oracle Linux c’est pour ainsi dire presque la même chose que CentOS (il y aurait juste quelques optims pour Oracle DB notamment niveau kernel il me semble) et tout aussi gratuit. De mon côté j’ai des clients qui y songeaient il y a quelques mois pour les bases de données Oracle justement (actuellement sur CentOS). Ca va surement les encourager à passer dessus au final.
#32
Mais pourquoi tout ce raffut ? Tout ce qui se fait racheter fini un jour par ne plus exister.
Du plus violent. Ex: MySql, Openoffice qui sont des morts vivant en sursis (plus pour les apparences qu’autre chose) puisque MariaDb et libreOffice (et d’autres) les remplacent avantageusement.
Au plus doux ou on peut classer cet exemple. Sept ans pour débrancher ce n’est pas ce qui ressemble à une célérité lumineuse.
Que cela en fasse suer plus d’un me fait dire que ces gens soit :
Enfin bref ils faut être demeuré pour croire qu’une boite en rachète une autre pour le plaisir.
Soit c’est pour :
Business as usual…
#33
Pour les gens en manque de ressources, Centos était la solution idéale grâce à ses 10 ans de support. La possibilité d’acheter un serveur avec 7 ans de garantie, de configurer aux petits oignons, et de l’oublier ensuite dans un coin en appliquant juste les mises à jours de sécurité. Et au bout de 7 ans, on arrive à négocier avec la direction pour acheter la machine suivante un peu en avance, ce qui permet de faire les tests dessus et de basculer la production quand tout marche.
On est loin de l’intégration continue ou autres buzzword à la mode, c’est l’informatique de grand papa. Mais ça fait l’affaire à moindre coût à pas mal d’endroits. Et avec les ressources financières et humaines, c’est çà où donner toutes ses données aux GAFAM (avec copie à la NSA au passage). Passer à 5 ans, que ce soit en Stream ou sur une Debian/Ubuntu LTS est une sacré régression (on n’installe pas l’OS tout juste sorti, donc ça fait 4 ans réels maximum). Donc au moins une mise à jour majeure de version sur le cycle de vie du matériel avec tous les problèmes associés.
Ceci dit, je doute que Redhat vende beaucoup à ce public. Les tarifs proposés sont purement délirants. 350\( par an pour la version sans support que l'on n'a même pas le droit d'installer sur une VM. 800\)/an minimum pour la vraie version. On va revenir à l’époque de Scientific Linux (ou un de ses équivalents si SL n’est pas relancée) et les 6 mois de retard à chaque sortie de version mineure.
#34
Je comprends. Mon pote vend du service sans bosser pour Red Hat pour des raisons personnelles. En gros, il veut son indépendance, et pouvoir proposer à ses clients ce que ces derniers veulent vraiment, et pas une solution maison plaquée sur toutes les situations. Ceux qui veulent (et peuvent) se payer du Red Hat, ils ne passent pas par lui.
Grosso merdo, il a deux gros clients où ça va l’emmerder : une boîte de VPC et un atelier d’usinage de précision. La première a tous ses serveurs sous CentOS7. La mutation était prévue à la fin du support, ça sera sous Debian Stable. L’atelier est aussi sous CentOS7, avec des postes Autocad sous Win 7 et des PLC qui commandent les machines-outil.
Les autres gros clients, c’est de l’Open BSD direct (finance, transport matières dangereuses, armée…) donc le problème n’existe pas.
Il m’a dit hier soir au téléphone que, pour ses clients PME/cabinets libéraux/petites autorités publiques (communes), il avait fait un mix CentOS/Debian pour ne pas avoir les deux pieds dans le même sabot. Ben, la moitié du parc est à remplacer à la fin du support CentOS…
Le pote en question, il fait pas du low cost, mais il a des petits clients qui ne peuvent pas banquer pour le support Red Hat, et n’en on pas besoin d’ailleurs. Un cabinet de notaire, il a besoin d’un serveur avec sauvegarde déportée, un VPN et trois postes de bureautique plus deux portables pour les clercs quand ils vont chez les clients. Red Hat, c’est overkill pour eux.
Oracle Linux, comme il y a Oracle dedans, il prend pas… Je lui ai parlé des autres, il attend de voir ce que ça donnera.
#35
Je me demande parmis tout ceux qui commentent, combien bossent réellemet dans l’infra.
Pour ma part, dans mon ancien taff que j’ai quitté il ‘y a un an, on avait encore quelques redhat et centos 5 qui trainaient, la majorité étaient sous centos 6⁄7 quand à centos 8 c’était pas prévu avant l’année prochaine.
Je suis dba/ devops / sysadmin, je travaille dans les bases de données et heu stream même en temps que serveur ? Pas pour une utilisation pro non, pas avec le risque de tomber sur des paquets instables sachant que la plupart du temps n évite de mettre les serveurs à jour sauf faille de secu
#36
En gros, il l’a toujours, son indépendance, mais il va devoir taffer plus pour être à la hauteur de ses prétentions… Soit ses clients veulent la stabilité, la compatibilité et la certification de RedHat et du coup, ben il va falloir qu’ils payent Red Hat ou qu’ils bougent vers Oracle Linux, ou alors ils réduisent leurs exigences et vont vers Stream ou une autre distribution en connaissance de cause… S’il a beaucoup de clients, il peut envisager de mettre en place un dépôt qu’il stabilise lui-même basé sur stream.
Supprimer Centos 8 reste en tout cas une erreur commerciale dans la mesure où ça va pousser du monde vers Oracle Linux et une fois là, pas besoin de réinstaller pour avoir du support payant. Redhat se met lui-même des freins à son adoption.
#37
Son choix, c’est migration vers Debian de tout ce qu’il a en CentOS. Il coûte cher, c’est pas pour rien. Ça fait du boulot, mais il a mitigé la charge de travail 1) en mettant Debian chez la moitié des clients que ça dérangeait pas et 2) en prévoyant à l’origine une mise à jour vers CentOS8 dans le courant 2021 pour les postes en 7, mais qui sera au final une migration vers Debian.
Pour les quelques postes qu’il a déjà installés ab initio en CentOS8 (trois clients, des cabinets libéraux), ben, faut tout refaire courant 2021…
+1. C’est vraiment du tirage de balle dans le pied. Mon pote a eu des clients qui ont évolué vers Red Hat parce que le service qu’il proposait ne leur suffisait plus, et ils n’ont quasiment rien eu à faire parce que leurs postes avaient été installés en CentOS dès le départ.
Là, s’il met tout en Debian, les clients qui voudront aller voir ailleurs, ils n’iront pas chez Red Hat…
#38
Pourquoi une telle précipitation ? La branche 8 de Stream reste maintenue pour 5 ans. Ca laisse le temps de repenser sa stratégie.
#39
C’est clair, mais d’un autre côté je ne parierais pas sur les 5 ans, vu la démonstration de changement d’avis unilatéral en mode rien-à-cirer-de-ce-qu’on-a-dit-avant … l’année prochaine ce ne sera peut-être plus que un an…
CentOS va devoir prouver sa constance pour regagner les confiances.
Quand on choisi une distribution payante, on, paye aussi pour un engagement de la part du fournisseur. Là CentOS on ne leur doit rien et ça tombe bien car ils ne se sentent redevables de rien…
#39.1
A titre personnel je pense que la confiance envers le board décisionnaire de CentOS est morte et enterrée. Ils n’ont aucune chance de la récupérer après une telle annonce unilatérale.
Je ne serais par contre pas aussi certain pour l’abandon du support de 5 ans car l’objectif de Stream est tout de même d’être un upstream ouvert de RHEL acceptant les contributions externes, le dev de celle-ci n’ayant jamais été très communautaire.
Réduire ce support signerait tout simplement la suppression de CentOS Stream… Et donc au final revenir au mode initial de Fedora laboratoire de test et dev RHEL fermé. A ce moment là autant annoncer la suppression pure et simple de la distrib immédiatement, la pilule serait certainement mieux passée je pense.
Dans tous les cas, CentOS a tout perdu.
Pour ma part je basculerai mes VM de mon serveur personnel sur la branche Stream et jugerai sur pièces.
#40
Je lui poserai la question. Le connaissant, quand il voit du micmac dans une distro, il a plutôt tendance à se barrer en courant dans l’intérêt de ses clients.
CentOs, c’était pour lui la distro rock solid pour les clients qui voulaient quelque chose pour supporter leurs .rpm maison. Voir les mainteneurs faire un doigt comme ça à leurs utilisateurs, c’est pas vraiment encourageant pour la suite.
Je n’en dis pas plus parce qu’après, on va rentrer dans les spéculations perso, et pas dans la politique de qualité de mon ami et de son entreprise. Je n’ai pas ses exigences mais, en tant qu’utilisateur tux depuis quinze ans, voir que la distro que j’utilise me dit merde du jour au lendemain, ça ne m’inciterait pas à rester.
#41
Free like a speech, not free like a beer.
#42
Là dessus on est d’accord. Comme je l’ai mis dans mon message juste au dessus, la confiance envers CentOS est morte et enterrée.
L’image de Red Hat en tant que société de l’open source a aussi pris un coup dans la gueule. Quand l’un des plus grands supporters fait un tel coup à la communauté, ça craint.
Par contre, à l’inverse de beaucoup d’avis, je ne pense pas que Red Hat ait fait ça pour détruire CentOS ou transformer ses utilisateurs en clients RHEL. Si les clients ne payaient pas pour CentOS, ils ne paieront pas pour RHEL et iront voir une alternative gratuite (potentiellement Oracle Linux pour avoir les 10 ans de support, ou changer de crèmerie et partir sur de la Debian). Même si pour beaucoup Oracle c’est le Grand Satan, il n’y a pas beaucoup de distribs Linux supportées aussi longtemps. Et pour le coup, le modèle économique de OL est plus en phase avec les logiciels communautaires : distribuée et installable gratuitement, et possibilité de souscrire à un support payant.
D’ailleurs, Debian supporte ses releases pendant 5 ans aussi il me semble ?
#42.1
5 ans de support pour les Debian Stable, je confirme.
Debian 8 n’est plus supportée depuis juin de cette année, et DEbian 9 l’est toujours. On en est à la version 10 pour celle qui est en cours.
#43
Renault ne l’a pas dit (pourtant, c’est pas un secret), mais il est le président (ou, au minimum, un membre) de l’association BorsaLinux, visant notamment à promouvoir Fedora en Francophonie, et rédige à ce titre toutes les dépêches sur les sorties des nouvelles versions de Fedora sur LinuxFR (dépêches très complètes au demeurant). Il bosse pas pour RH, mais il est au moins à considérer comme plus proche du dossier que toi et moi, ce qu’ont d’ailleurs montré ses messages ici.
#44
Ce qui m’étonne le plus c’est de voir que RH peut “arrêter” comme ça CentOS.
Je pensais que CentOS était un fork de la communauté, qui était une copie conforme du code de RHEL, mais sans support technique…
#44.1
Ils avaient embauché les développeurs il me semble et intégré la distrib dans leur périmètre.