Oui Red Hat a soutenu CentOS longtemps (si ce n’est de tout temps) financièrement et « humainement », mais en laissant toute liberté à CentOS. Red Hat a acquis CentOS (la marque) et embauché le board de CentOS en 2014 seulement.
Cela fait quand même 10 ans, c'est énorme.
Elle était 100% identique au niveau du code source open-source et uniquement à ce niveau.
Cela se discute que c'était 100% identique, mais je vais revenir après là dessus.
Quant au fait que tu trouves ma formulation imparfaite, ambigu voire fallacieuse. Merci d’expliquer en quoi. Tu n’as fait que répondre à côté de la plaque pour défendre Red Hat là. Pour moi comme pour beaucoup un « rebuild » n’est pas un dérivé.
Un rebuild est par définition un dérivé car ce n'est pas une copie parfaite, je vais l'expliquer en quoi.
Par ailleurs tu viens de le dire enfin que pour toi un rebuild n'est pas un dérivé de ton point de vue. Ce n'était pas explicité dans tes précédents messages donc oui c'était cryptique comme point de vue sans ce rappel de vocabulaire (de ton point de vue car personnellement je ne suis pas d'accord).
Tu n’as clairement pas compris mon message. Ce que je reproche à Red Hat c’est d’avoir saboté « CentOS » (ie: CentOS tout court) en réutilisant le nom pour une distribution qui n’a plus rien à voir, mais fondamentalement plus rien à voir, en terme d’architecture et de destinations. Ils auraient pu créer un nouveau nom, un nouveau logo. Et s’ils ont réutilisé "CentOS" c’est clairement pour sa réputation et uniquement pour cela. Ils ne pouvaient ignorer la confusion.
Honnêtement des produits ou marques qui évoluent dans leur cibles ou caractéristiques principales tout en gardant le même nom pour des raisons commerciales ça arrive tous les jours. Que Red Hat le fasse ne me choque pas le moins du monde car honnêtement je m'en fou, c'est du détail. Que CentOS Stream s'appelle CentOS Stream ou Red Hat Community edition ou quoique ce soit d'autre ne change pas la réalité derrière le produit.
Et c'est pareil pour tout, si demain Debian Sid devient la version stable de Debian après tout leur historique, je ne vais rien dire non plus. Ou si demain Debian devient une rolling release aussi en gardant le même nom.
Mais bon, je pense que tu n’as pas bien compris la différence, si déjà tu ne vois pas l’intérêt d’une distribution « 100 % identique » (au niveau du code source, et seulement pour la partie opensource de celui-ci), tu es l’exemple parfait qu’ils ont « bien » fait de se permettre cette manipulation honteuse, car sa grossièreté ne saute manifestement pas aux yeux de tout le monde.
Revenons sur le compatible bug pour bug.
Pour moi c'est une promesse qui n'a jamais existé et n'existera probablement jamais. On s'en approche le mieux possible évidemment, mais l'atteindre de manière absolue pas vraiment. EN partant de ce principe là et par le modèle choisi, en réalité CentOS Stream est très similaire à ce qu'était CentOS de ce côté là, juste qu'au lieu d'être en retard avec RHEL il est en avance de phase.
Pourquoi le bug pour bug est une chimère ?
Déjà car il y a des mises à jour en continue dans RHEL et que chaque mise à jour introduit des changements (sinon ça n'aurait aucun intérêt). Par définition CentOS avait du retard, souvent de quelques jours voire plus. Il n'y a aucun jour X où le code de RHEL et CentOS étaient identiques. Et comme les flux de traitements sont différents, même en admettant qu'un lag réduit, RHEL pouvait publier 2 maj avec des jours d'écart quand CentOS va les proposer en même temps. Donc tu auras par exemple dans la nature des RHEL avec une de ces maj installées et pas l'être quand sur CentOS cette situation n'arrivera pas.
En plus les RHEL et CentOS ayant un système d'image traditionnelle ne sont jamais identiques entre elles, l'ordre des mises à jour n'est pas identique d'un site à l'autre même en suivant les mêmes instructions en même temps ce qui est source de bogues et de comportements différents.
Ce n'est pas pour rien que Red Hat investit la question des images à base de rpm-ostree et qu'il y a une "hype" pour les images immuables car ce sont les seuls moyens d'apporter la garantie que tu recherches. Sans cela, tu ne garanties rien pas plus qu'AlmaLinux ne le fait. Tu t'en approches mais c'est tout. De même pour la compilation reproductible même si cela n'est pas suffisant non plus, CentOS et RHEL n'ont jamais été été compatibles à ce sujet.
Et l'un dans l'autre la garantie apportée par CentOS Stream à cet égard n'est pas si différente que ce que faisait CentOS dans le passé. Mais dans l'autre sens.
Et rendait pas mal de services aussi.
Mais CentOS Stream aussi rend pas mal de services et est exploitable en production.
Sinon ALMA Linux et Rocky Linux n’auraient pas été créés pour remplacer CentOS dès que la décision de Red Hat a été connue.
Mais je ne condamne pas ces projets moi. Ils le font s'ils le veulent, on verra s'ils tiennent dans la durée, c'est tout ce que je leur souhaite mais l'histoire montre que c'est délicat.
C'est l'avantage du Logiciel Libre à cet égard par ailleurs. Et Red Hat est tout aussi libre d'arrêter de faire CentOS comme avant.
Tu sais qui a lancé le projet Rocky Linux ? Si tu ne sais pas renseigne toi
Merci je pense que je connais bien le dossier.
Et donc ? Perso je m'en fou un peu des noms, des problèmes d'égos, des gens qui font n'importe quoi ou qui étaient une référence un jour X pour faire n'importe quoi le lendemain ce n'est pas ce qui manque pour qu'on ne considère pas les arguments d'autorité.
Je pense que j'ai assez expliqué et justifié mon point de vue.
ça t’incitera peut-être à ôter les œillères qui font que tu ne vois rien à redire à la réutilisation du nom pour la nouvelle distribution de l’écosystème Red Hat (ie: CentOS Stream), bien que parfaitement légale, est foncièrement malhonnête intellectuellement parlant.
Ce serait bien d'éviter les attaques personnelles, je ne partage pas ton point de vue ne signifie pas que je suis aveuglé, con ou quoique ce soit d'autres.
Sinon tu t'attaches à une considération marketing, c'est ton droit, moi je m'en fou, c'est mon droit aussi.
Car fondamentalement, si CentOS Stream se nommait je ne sais pas Open Red Hat Community Edition, tout en arrêtant CentOS par ailleurs. Ton discours serait différent ? Étant donné ton propos j'en doute. Et s'il était différent, ce serait de tout façon peu cohérent.
Et Alma Linux comme Rocky Linux auraient été lancés aussi.
Bref, ça n'aurait fondamentalement rien changé je pense et cela ne devrait pas de toute manière car ce n'est qu'un nom. Cela ne change pas les propriétés de chaque entité.
Tu dis sûrement vrai, ce serait juste afin de connaître la valeur réel du facteur pifométrique « parfois plusieurs » que tu emploies, ainsi que quelques exemple des problèmes ayant, comme tu le suggères, eu lieu et auxquels tu fais allusion.
RHEL 6 sorti le 10 novembre 2010, CentOS sorti le 27 novembre 2011 (plus d'un an !)
RHEL 7 sorti le 10 juin 2014, CentOS 7 est sorti le 7 juillet 2014 (presque un mois)
RHEL 8 sorti le 7 mai 2019, CentOS 8 le 24 septembre 2019 (donc 4 mois après)
Bref, pour les mises à jour majeur, on voit bien un écart en moyenne de plusieurs mois.
Pour les sorties intermédiaires (donc par exemple 6.1) la page de Wikipédia anglaise fait le listing avec les délais pour chaque version :https://en.wikipedia.org/wiki/CentOS
En général il y a toujours au moins 2 semaines d'écart, et souvent 1 mois et parfois plus. Tes 2-3 jours n'ont jamais existé en vrai.
Cela te convient ? Oui, je pense comprendre le dossier en question.
Par ailleurs compiler une distribution c'est un peu mon boulot quotidien via Yocto pour différents clients, je suis également de près les arcanes de Fedora, cela m'aide à comprendre à quel point des problèmes peuvent survenir à tous les étages et la difficulté de la tâche dont de la reproduction de la compilation.
Cela signifiait que sans licence Red Hat, pas moyen de tester la version en développement pour s'assurer que son parc ou son application sera compatible car c'était un développement en mode fermé.
Tout à fait. Ça permettait « juste » de tester ses applications avec n’importe qu’elle version stable, publiée, de RHEL sans devoir acquérir une ou plusieurs licences ! Sérieusement, tu me sidères...
Ce que tu dis sur l’utilité d’avoir une distribution comme CentOS Stream est tout à fait juste également. Mais je crois sincèrement que tu ne vois pas à quoi servait une distribution comme CentOS, qui est exactement les mêmes usages qu’ALMA Linux ou Rocky Linux aujourd’hui.
Mais tu déformes totalement mon propos depuis le début.
Je ne dis pas que c'était le seul intérêt de CentOS, mais que ça en était une et avec un retard tel que c'était bloquant dans cette tâche (et pénalisait Red Hat par ailleurs).
Je ne dis pas que Alma Linux ou Rocky ne servent à rien et qu'il faut aussi les brûler en enfer. Ils existent, tant mieux, le libre est là pour ça. Mais je signe et persiste, pour beaucoup d'utilisateurs CentOS Stream fait le même job que CentOS et est en fait plus intéressant d'un point de vue écosystème et communautaire que ne l'était CentOS.
Tu peux ne pas être d'accord si tu veux, je pense avoir justifié mon point de vue qui ne me semble pas mauvaise justement.
[^] # Re: Tout dépend du point de vue ...
Posté par Renault (site web personnel) . En réponse au journal Les distro pionnières, en recul?. Évalué à 6.
Cela fait quand même 10 ans, c'est énorme.
Cela se discute que c'était 100% identique, mais je vais revenir après là dessus.
Un rebuild est par définition un dérivé car ce n'est pas une copie parfaite, je vais l'expliquer en quoi.
Par ailleurs tu viens de le dire enfin que pour toi un rebuild n'est pas un dérivé de ton point de vue. Ce n'était pas explicité dans tes précédents messages donc oui c'était cryptique comme point de vue sans ce rappel de vocabulaire (de ton point de vue car personnellement je ne suis pas d'accord).
Honnêtement des produits ou marques qui évoluent dans leur cibles ou caractéristiques principales tout en gardant le même nom pour des raisons commerciales ça arrive tous les jours. Que Red Hat le fasse ne me choque pas le moins du monde car honnêtement je m'en fou, c'est du détail. Que CentOS Stream s'appelle CentOS Stream ou Red Hat Community edition ou quoique ce soit d'autre ne change pas la réalité derrière le produit.
Et c'est pareil pour tout, si demain Debian Sid devient la version stable de Debian après tout leur historique, je ne vais rien dire non plus. Ou si demain Debian devient une rolling release aussi en gardant le même nom.
Revenons sur le compatible bug pour bug.
Pour moi c'est une promesse qui n'a jamais existé et n'existera probablement jamais. On s'en approche le mieux possible évidemment, mais l'atteindre de manière absolue pas vraiment. EN partant de ce principe là et par le modèle choisi, en réalité CentOS Stream est très similaire à ce qu'était CentOS de ce côté là, juste qu'au lieu d'être en retard avec RHEL il est en avance de phase.
Pourquoi le bug pour bug est une chimère ?
Déjà car il y a des mises à jour en continue dans RHEL et que chaque mise à jour introduit des changements (sinon ça n'aurait aucun intérêt). Par définition CentOS avait du retard, souvent de quelques jours voire plus. Il n'y a aucun jour X où le code de RHEL et CentOS étaient identiques. Et comme les flux de traitements sont différents, même en admettant qu'un lag réduit, RHEL pouvait publier 2 maj avec des jours d'écart quand CentOS va les proposer en même temps. Donc tu auras par exemple dans la nature des RHEL avec une de ces maj installées et pas l'être quand sur CentOS cette situation n'arrivera pas.
En plus les RHEL et CentOS ayant un système d'image traditionnelle ne sont jamais identiques entre elles, l'ordre des mises à jour n'est pas identique d'un site à l'autre même en suivant les mêmes instructions en même temps ce qui est source de bogues et de comportements différents.
Ce n'est pas pour rien que Red Hat investit la question des images à base de rpm-ostree et qu'il y a une "hype" pour les images immuables car ce sont les seuls moyens d'apporter la garantie que tu recherches. Sans cela, tu ne garanties rien pas plus qu'AlmaLinux ne le fait. Tu t'en approches mais c'est tout. De même pour la compilation reproductible même si cela n'est pas suffisant non plus, CentOS et RHEL n'ont jamais été été compatibles à ce sujet.
Et l'un dans l'autre la garantie apportée par CentOS Stream à cet égard n'est pas si différente que ce que faisait CentOS dans le passé. Mais dans l'autre sens.
Mais CentOS Stream aussi rend pas mal de services et est exploitable en production.
Mais je ne condamne pas ces projets moi. Ils le font s'ils le veulent, on verra s'ils tiennent dans la durée, c'est tout ce que je leur souhaite mais l'histoire montre que c'est délicat.
C'est l'avantage du Logiciel Libre à cet égard par ailleurs. Et Red Hat est tout aussi libre d'arrêter de faire CentOS comme avant.
Merci je pense que je connais bien le dossier.
Et donc ? Perso je m'en fou un peu des noms, des problèmes d'égos, des gens qui font n'importe quoi ou qui étaient une référence un jour X pour faire n'importe quoi le lendemain ce n'est pas ce qui manque pour qu'on ne considère pas les arguments d'autorité.
Je pense que j'ai assez expliqué et justifié mon point de vue.
Ce serait bien d'éviter les attaques personnelles, je ne partage pas ton point de vue ne signifie pas que je suis aveuglé, con ou quoique ce soit d'autres.
Sinon tu t'attaches à une considération marketing, c'est ton droit, moi je m'en fou, c'est mon droit aussi.
Car fondamentalement, si CentOS Stream se nommait je ne sais pas Open Red Hat Community Edition, tout en arrêtant CentOS par ailleurs. Ton discours serait différent ? Étant donné ton propos j'en doute. Et s'il était différent, ce serait de tout façon peu cohérent.
Et Alma Linux comme Rocky Linux auraient été lancés aussi.
Bref, ça n'aurait fondamentalement rien changé je pense et cela ne devrait pas de toute manière car ce n'est qu'un nom. Cela ne change pas les propriétés de chaque entité.
RHEL 6 sorti le 10 novembre 2010, CentOS sorti le 27 novembre 2011 (plus d'un an !)
RHEL 7 sorti le 10 juin 2014, CentOS 7 est sorti le 7 juillet 2014 (presque un mois)
RHEL 8 sorti le 7 mai 2019, CentOS 8 le 24 septembre 2019 (donc 4 mois après)
Bref, pour les mises à jour majeur, on voit bien un écart en moyenne de plusieurs mois.
Pour les sorties intermédiaires (donc par exemple 6.1) la page de Wikipédia anglaise fait le listing avec les délais pour chaque version :https://en.wikipedia.org/wiki/CentOS
En général il y a toujours au moins 2 semaines d'écart, et souvent 1 mois et parfois plus. Tes 2-3 jours n'ont jamais existé en vrai.
Cela te convient ? Oui, je pense comprendre le dossier en question.
Par ailleurs compiler une distribution c'est un peu mon boulot quotidien via Yocto pour différents clients, je suis également de près les arcanes de Fedora, cela m'aide à comprendre à quel point des problèmes peuvent survenir à tous les étages et la difficulté de la tâche dont de la reproduction de la compilation.
Mais tu déformes totalement mon propos depuis le début.
Je ne dis pas que c'était le seul intérêt de CentOS, mais que ça en était une et avec un retard tel que c'était bloquant dans cette tâche (et pénalisait Red Hat par ailleurs).
Je ne dis pas que Alma Linux ou Rocky ne servent à rien et qu'il faut aussi les brûler en enfer. Ils existent, tant mieux, le libre est là pour ça. Mais je signe et persiste, pour beaucoup d'utilisateurs CentOS Stream fait le même job que CentOS et est en fait plus intéressant d'un point de vue écosystème et communautaire que ne l'était CentOS.
Tu peux ne pas être d'accord si tu veux, je pense avoir justifié mon point de vue qui ne me semble pas mauvaise justement.