Le projet CentOS annonce un changement majeur de stratégie, ne reproduisant plus la version stable RHEL dès CentOS 8 et devenant l’incubateur des nouveautés pour RHEL (soit une version bêta de RHEL). Ce changement va faire grincer les dents des très nombreux administrateurs ayant retenu la distribution et qui vont donc devoir trouver des alternatives.
CentOS est une distribution GNU/Linux créée en 2002 dont le principe est une reproduction à l’identique de Red Hat Enterprise Linux via recompilation des paquets à partir des sources publiées par Red Hat des différents logiciels libres qui composent la distribution.
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.
Le changement proposé par le projet est de devenir l’incubateur des logiciels depuis Fedora avant d’entrer dans RHEL, CentOS devenant de fait la version bêta de RHEL. CentOS 8, en tant que recompilation de RHEL 8 n’existera plus dès fin 2021, à la faveur de CentOS Stream. Une FAQ a été publiée pour documenter le changement.
Cette option n’est évidemment pas acceptable pour bien des utilisateurs actuels de la distribution qui devront probablement chercher une autre solution. Parmi les alternatives sont souvent cités Oracle Linux et Scientific Linux (dont le développement de la version 8 avait été arrêté pour utiliser CentOS à la place). Plus éloignés, on retrouve openSUSE Leap, Debian, ou encore Ubuntu. Le fondateur de CentOS, Gregory Kurtzer, a annoncé vouloir relancer un projet similaire à CentOS.
Aller plus loin
- Annonce du projet CentOS (174 clics)
- CentOS sur Wikipédia (95 clics)
- FAQ relatif au changement (90 clics)
# Pourquoi ce titre ?
Posté par Sytoka Modon (site web personnel) . Évalué à 10.
CentOS n'est plus indépendant depuis des années. D'après repris par Red-Hat et donc désormais IBM. J'ai envie de dire que c'était évident depuis le début…
Red-Hat n'a jamais donné les clefs permettant de reconstruire RHEL.
Debian propose quelque chose d'équivalent avec toutes les recettes disponibles et travaillent d'arrache pied sur le projet reproductible build. Il est temps de miser sur du vrai communautaire ;-)
[^] # Re: Pourquoi ce titre ?
Posté par Renault (site web personnel) . Évalué à 9.
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.
5 à 10 ans de support, je ne crois pas. ;)
RHEL et CentOS aussi…
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é.
[^] # Re: Pourquoi ce titre ?
Posté par madhatter (site web personnel) . Évalué à 10.
Pourtant, Debian LTS c'est au minimum 5 ans de support. ;)
There is no spoon...
[^] # Re: Pourquoi ce titre ?
Posté par Renault (site web personnel) . Évalué à 1.
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. ;)
[^] # Re: Pourquoi ce titre ?
Posté par claudex . Évalué à 10.
Ça me semble autant fiable que le support Debian classique. Sinon, ça commencé avec Debian 6, donc on voit que ça tient dans la durée.
Une distribution ne file pas les clefs des dépôts de sécurité à n'importe qui normalement.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pourquoi ce titre ?
Posté par Babelouest (site web personnel) . Évalué à 10.
La page que tu mentionnes est sur le site Debian officiel, les dépôts pour les paquets du support étendu sont hébergés sur les serveurs Debian, je dirais que ca à le goût d'un projet officiel, pour autant que le terme officiel ait du sens.
Le processus est forcément différent, vu que le cycle de vie normal dans Debian n'inclus pas de LTS, il fallait soit changer le processus actuel, soit mettre le Debian LTS en dehors du processus original. Ils ont choisit la deuxième option.
Les personnes sont différentes parce que les mainteneurs d'un paquet ne sont pas nécessairement ni uniquement ceux qui font le support LTS. Des fois oui, des fois non, généralement non.
La grosse différence est qu'un paquet dans le cycle normal est mis à jour par son mainteneur ou son équipe quand le logiciel upstream est mis à jour ou que des bugs dans le paquet sont corrigés, puis ca finit dans testing.
Pour le support LTS, les mises à jour autorisées sont des mises à jour de sécurité principalement (voire uniquement, je suis pas sûr). Donc le numéro de version ne changera pas, seuls des patches seront autorisés, et avec l'autorisation des membres de l'équipe de support LTS, comme c'est le cas pour les patches de sécurité pour Debian stable en fait.
Comme le projet Debian dans son ensemble :)
Vu que ce support est plus destiné aux entreprises ou grosses structures qui ne veulent/peuvent pas mettre à jour facilement, ils les encouragent à contribuer ou participer financièrement.
[^] # Re: Pourquoi ce titre ?
Posté par Adrien . Évalué à 8.
Si 5 ans n'est pas assez, il y a aussi « Extended LTS », mais ce n'est pas pour toute la distro :-)
https://deb.freexian.com/extended-lts/
[^] # Re: Pourquoi ce titre ?
Posté par paulez (site web personnel) . Évalué à 10.
C'est un peu fallacieux de dire ça, CentOS faisait un assez gros travail pour rendre ça possible, c'est d'ailleurs pour ça que beaucoup de projets sont basés sur CentOS.
RedHat ne fait que balancer les srpm dans ses repos. CentOS faisait tout le boulot de les extraire, versionner ça dans un git, suivre les mises à jours de sécurité, etc.
Plus le boulot initial pour boostraper la distro (arriver à compiler from scratch) ce qui n'est pas du tout trivial (et probablement cassé avec les dernières versions des srpms, il faut avoir l'historique pour avoir une chance).
Tuer CentOS telle qu'elle l'était, ça monte vraiment une volonté de fermeture de la part de RedHat.
[^] # Re: Pourquoi ce titre ?
Posté par Renault (site web personnel) . Évalué à 10.
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.
[^] # Re: Pourquoi ce titre ?
Posté par Zenitram (site web personnel) . Évalué à 7.
Reprenons, c'était quoi le but de CentOS? D'avoir une copie conforme (sans marques) de RHEL.
Maintenant, RH décide d'ouvrir un truc complètement différent et tue CentOS, se disant que ça peut essayer de faire passer la pilule de cette mort.
Qu'ils ouvrent ça, c'est peut-être bien, mais pas le sujet.
Qu'ils tuent CentOS, ben ça se voit quand même.
Tu argumentes sur du hors sujet en prenant le marketing de RH, on peut enlever le marketing et regarder ce qu'il y a?
2 sujets différents. Les gens intéressés par l'un ne sont pas forcement intéressé par l'autre.
Mais si tu penses l'inverse, es-tu prêt à t'engager à faire le taf de debuggage quand un logiciel X validé pour RHEL 8 ne passe pas sur CentOS Stream? Nan, parce que le sujet est la, pas sur l'ouverture du dev de RHEL dont on se fout complet pour 99% des gens qui utilisent CentOS.
[^] # Re: Pourquoi ce titre ?
Posté par orfenor . Évalué à 1.
Faut pas déconner, il n'est pas hors sujet du tout. Je trouve très pertinent d'argumenter sur les avantages techniques pour Red Hat de créer Centos Stream. Comme il te le dit un peu plus bas, Renaud dédramatise. Il connaît bien Red Hat, il trouve qu'on exagère. Soit.
D'autres gens qui connaissent bien Red Hat s'inquiètent tellement qu'ils ne discutent même pas et ont déjà commencé le boulot sur un nouveau clone de RHEL, Rocky Linux (y compris une équipe chinoise)
[^] # Re: Pourquoi ce titre ?
Posté par Zenitram (site web personnel) . Évalué à 10. Dernière modification le 10 décembre 2020 à 15:15.
Personne ne remet en cause CentOS Stream. Juste ue ça aurait pu s'appeler RHEL Stream, car ça n'a rien à voir avec CentOS par rapport à l'affichage sur leur site web pendant 15 ans (=être une copie à la version près de chaque paquet de l'upstream).
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.
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é.
Si CentOS Steam était si génial que ça, pourquoi RH ne continue pas CentOS 8 (qui ne leur coûte pas beaucoup, c'est une copie de RHEL et peanuts pour eux) le temps que la majorité des gens passent à CentOS Stream pour que la majorité des gens s'en foutent? Pourquoi ils n'annonce pas en même temps que RHEL 9 ne verra jamais le jour mais remplacé par RHEL Stream car "Stream" c'est le futur et que les versions c'est le passé il parait? Bizarre… Et on connaît le scénario depuis longtemps, c'est le scénario de tuer un projet gênant pour son business.
[^] # Re: Pourquoi ce titre ?
Posté par orfenor . Évalué à 2.
Pourquoi veux-tu qu'il parle comme le marketing ? s'il parlait plutôt comme un tech informé ? Je pense qu'il connaît mieux Red Hat que nous. Et pourquoi le taxer de malhonnêteté intellectuelle ? il a le droit de penser autrement. Tu as toujours cette façon extrêmement binaire de voir les choses plutôt que faire crédit d'un peu d'intelligence aux autres.
En plus tu as tendance à mettre les gens dans une impasse avec des questions inquisitrices dont, à l'heure actuelle, personne ne peut connaître les réponses. Pourquoi Red Hat fait comme ça on n'en sait rien, mais on peut supposer qu'ils ont bien réfléchi, et que leur orgueilleuse équipe de développeurs a son mot à dire. On aura certainement les réponses un peu plus tard vu qu'un tas de monde va s'en mêler sur la liste kernel. Pas la peine d'imaginer d'avance des trucs tordus et de les faire peser sur Renaud parce qu'il défend une position différente.
Je penses que Renaud se trompe, mais ses arguments sont intéressant, il n'est d'ailleurs pas le seul à les dire (vu ailleurs pendant ma nuit de veille).
[^] # Re: Pourquoi ce titre ?
Posté par Zenitram (site web personnel) . Évalué à 4. Dernière modification le 10 décembre 2020 à 15:58.
J'attendrai de lui des arguments techniques, basé sur des faits.
Dire "un peu redéfini" à la placer de "tué", c'est cacher les faits, et ça ne peut que bloquer la discussion (pas de débat possible sur la réalité du fait que la réalité est déjà niée).
Tu me dis que je mets les gens dans une impasse, mais l'impasse ici est de nier un fait.
Euh… On se demandait surtout pourquoi RH aidait un CentOS qu'il n'aimait pas à une époque, compétition contre son business model. Ha, c'était pour le tuer, on comprend mieux.
Je n'en doute pas. Mais pas le sujet, leur but n'est pas le même que la communauté autour de CentOS.
Bon, la je craque, trop de fois l'erreur : Renault!
Je n'ai encore vu aucun argument pour tuer CentOS Stream, que des trucs hors sujet.
Si vous avez des arguments sur le sujet (CentOS plus utile alors que RHEL utile), sortez les!
Oui, mais toujours pas le sujet (personne ne dit quoique ce soit contre CentOS Stream le mal nommé, en fait les gens s'en foutent de lui car ils veulent un clone de RHEL quand ils parlent de CentOS car… C'était l'idée derrière CentOS).
Et encore une fois, RIEN n’empêchait RH de garder les deux. Un projet est tué, pourquoi faire comme le marketing et parler d'un autre projet indépendant (à part le nom)?
Il faudrait arrêter déjà de parler de CentOS Steam quand on parle de CentOS, argumenter sur pourquoi un clone de RHEL est inutile alors que RHEL est toujours utile, et la il n'y a plus personne.
Il est sans doute temps de s'arrêter, ça tourne en rond avec du CentOS Stream hors sujet comme argument unique et refus de parler de faits…
[^] # Re: Pourquoi ce titre ?
Posté par orfenor . Évalué à 1.
Ben justement tu n'en sais RIEN. Va donc lire ce qu'en disent les personnes qui bossent déjà sur Rocky Linux et qui avaient fondé Centos au lieu d'élucubrer sur du vent. C'était dans les cartons de Red Hat depuis longtemps.
(La discussion est dans le Slack indiqué sur la page de Rocky Linux, je ne sais pas comment mettre un lien sur un slack privé.)
[^] # Re: Pourquoi ce titre ?
Posté par Renault (site web personnel) . Évalué à 4.
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.
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.
[^] # Re: Pourquoi ce titre ?
Posté par Raphaël G. (site web personnel) . Évalué à 0.
Ils ont aussi passé les patchs du kernel en un patch fusionné à cause des pompeurs à sens unique de oracle unbreakable linux qui avait tendance à un peu trop faire du copié/collé à pas cher et oublier la partie contribuer en retour…
[^] # Aimer le libre mais en fait il fait chier à filer trop de libertés
Posté par Zenitram (site web personnel) . Évalué à 7. Dernière modification le 20 décembre 2020 à 10:48.
J'ai l'impression que certaines personnes veulent aimer le libre et ont du mal avec le lui… Pour info, le libre se fout complet de l'upstream, et ne dit rien sur une retour.
Donner en positif de mettre des bâtons dans les roues de gens utilisant les droits donnés, ça en dit long sur une vision du libre : t'es libre, mais si tu utilises les libertés je dis du mal de toi pour te donner mauvaise réputation (à la manière d'autoriser l’homosexualité mais en dire du mal en pression sociale pour que tu ne "tombes" pas dans cette autorisation).
Tu ajoutes ta propre morale à un libre qui n'a pas ta morale.
Donc rappelons un fait : il n'y a aucune partie contribuer en retour dans le libre, le libre s’intéressant à celui qui reçoit et non pas celui qui donne, c'est très clairement lisible dans la définition du libre (celui qui donne n'est pas nommé du tout).
RH est libre de faire ses patchs comme il veut (c'est légal à défaut d'être correct envers celui qui reçoit, dont ses clients), mais trouver positif de l’offuscation volontaire pour artificiellement limiter ses clients, gloups : non, c'est merdique envers leur propres clients (et ici je ne parle pas de Oracle ou autre "pompeurs" car ils ne sont pas le sujet, le libre étant leur sujet).
[^] # Re: Aimer le libre mais en fait il fait chier à filer trop de libertés
Posté par barmic 🦦 . Évalué à -2.
C'est rigolo de donner des leçons sur le libre quand il y a quelques jours à peine tu amalgamais libre et gratuit ;p ("koa ?! Vous me dites de payer ? Mais c'est fou d'entendre ça sur un site de libriste ! Vous êtes contre le libre !")
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Aimer le libre mais en fait il fait chier à filer trop de libertés
Posté par Zenitram (site web personnel) . Évalué à -1. Dernière modification le 20 décembre 2020 à 14:11.
Tu n'as tellement rien contre moi que tu es obligé de (te) mentir pour m'attaquer.
Vu que je dis exactement l'inverse : j'ai toujours dit libre != gratuit.
Le sujet dont tu parles étant complètement autre chose (que ce qui est annoncé soit respecté, et ça n'a rien à voir avec le libre comme principe général : "koa ?! Vous me dites de faire ce que je dis que je fais? Mais c'est fou d'entendre ça" est ta réaction, pas la mienne).
Ça en devient pathétique. Tu devrais quand même te demander pourquoi tu as besoin de (te) mentir, la réalité sur ce que tu penses est-elle si horrible?
J'ai l'impression que ce qui te dérange ce sont les gens qui demandent à ce qu'on respecte ce qu'on dit (par exemple ici je demande à ce quand on dit "tu as le droit de ne rien remonter upstream" on ne dit pas en même temps "si tu fais ce que je t'autorise à faire tu es un méchant qui contribue pas"; si tu veux que les gens doivent contribuer en retour, met ça dans la licence, bon par contre du coup ça ne sera pas libre, faut choisir :) ).
[^] # Re: Aimer le libre mais en fait il fait chier à filer trop de libertés
Posté par orfenor . Évalué à 4.
Mais pourquoi tu as besoin de transformer le truc en agression ? Bon sang, tu fais ce coup là tout le temps. Tu ne peux pas te contenter d'écrire qu'il te confonds avec un autre, puisque tu as toujours défendu la différence entre libre et gratuit ?
[^] # Re: Aimer le libre mais en fait il fait chier à filer trop de libertés
Posté par Zenitram (site web personnel) . Évalué à 0.
Il ne me confond pas avec un autre, il se créé une réalité parallèle sur moi pour pouvoir m'attaquer, justement c'est bien le soucis qu'il sait très bien qui il vise (il pense à un autre conflit qu'on a eu il y a quelques jours mais dont il ne peut objectivement pas défendre sa position et en vient à inventer pour s'en sortir).
Parce que l'attaque est un peu différente de ce que tu imagines. Et rassure-toi sur ma santé mentale, je ne le prend pas comme agression mais comme confirmation qu'il n'a aucun argument réel à m'opposer, bref je le prend très bien, je le prend presque comme un hommage.
[^] # Re: Aimer le libre mais en fait il fait chier à filer trop de libertés
Posté par orfenor . Évalué à 1.
Mets au moins un smiley alors :-) ce sera moins lourd pour les autres
[^] # Re: Aimer le libre mais en fait il fait chier à filer trop de libertés
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
Tu devrais essayer de troller sans traiter quelqu'un de menteur pour une fois :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pourquoi ce titre ?
Posté par paulez (site web personnel) . Évalué à 8. Dernière modification le 10 décembre 2020 à 15:08.
Je suis tout à faire d'accord que CentOS Streams est une très belle idée, et permet d'ouvrir le développement de RHEL. En effet, actuellement un utilisateur de CentOS 7 rencontrant un bogue n'a aucun moyen de contribuer à sa résolution. Avec CentOS Streams, il peut contribuer au stream pour proposer un correctif qui un jour pourrait arriver dans CentOS.
Donc CentOS Streams c'est une super idée. Mais ça n'est pas CentOS. RH essaie de nous faire passer la mort de CentOS par un "voyez c'est mieux qu'avant !" mais clairement, ils annoncent la fin de CentOS, sachant que CentOS Streams avait déjà été annoncée.
Est-ce que tu penses qu'il y aura plus de gens prêts à contribuer gratuitement au développement de RHEL sans pouvoir l'utiliser gratuitement, que d'utilisateurs actuels de CentOS ?
On peut aussi discuter de la moindre importance aujourd'hui d'une distribution à très longue durée de vie avec la containérisation, mais si c'était vraiment ça le problème, RedHat arrêterait le support longue durée de RHEL, pas CentOS. Clairement donc l'objectif de RedHat est de forcer les utilisateurs de CentOS à passer sur RHEL.
[^] # Re: Pourquoi ce titre ?
Posté par orfenor . Évalué à 4.
Non, il n'y en a pas quelques uns, mais seulement deux : la version d'Oracle dont on se méfie vu leurs pratiques commerciales, et la version ultra confidentielles de l'université de Princeton dont je parle un peu plus bas. Tous les autres, sauf erreur, sont basées sur Centos y compris celle d'Amazon.
Ensuite, n'importe qui n'est pas vrai. C'est un énorme et difficile boulot et un besoin conséquent d'infrastructure. En témoigne la taille des équipes. Celle réunie par Greg pour remplacer Centos est déjà importante (une douzaine) alors que ça date de cette nuit. Je ne peux pas mettre de lien parce que tout a été supprimé pour reconstruction. Ça devrait apparaître quelque part dans https://github.com/rocky-linux
[^] # Re: Pourquoi ce titre ?
Posté par el_profesor . Évalué à 1.
Pour Debian il y a un support de 5 ans : https://wiki.debian.org/fr/LTS/
# À voir en vrai
Posté par Renault (site web personnel) . Évalué à 10.
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.
[^] # Re: À voir en vrai
Posté par Psychofox (Mastodon) . Évalué à 10. Dernière modification le 09 décembre 2020 à 13:50.
L'intérêt c'était le support long terme. Une debian tu dois faire une upgrade de version majeure régulière quand tu peux utiliser la même RHEL/centos pendant 10 ans sans risque de rien casser. Les seules réelles alternatives à du RHEL based quand on veut des versions figées avec autant d'années de support c'est ubuntu LTS.
[^] # Re: À voir en vrai
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 10.
« pendant 10 ans » Non, pas de mon expérience. Par exemple, pour un serveur Internet, n'avoir que les vieilles versions de TLS n'est pas acceptable, les clients, notamment les navigateurs ne les acceptant plus. Et c'est pourtant ce qui arrive si on reste sur de vieilles RHEL.
[^] # Re: À voir en vrai
Posté par jtremesay (site web personnel) . Évalué à 7.
Il y a des millieux où malheureusement, « tant que ça marche, on ne touche pas ». J'ai du maintenir de la compatibilité avec RHEL5 beaucoup trop longtemps à mon gout.
[^] # Re: À voir en vrai
Posté par Psychofox (Mastodon) . Évalué à 7.
serveur != web. Il existe plein d'autres usages et pour certains une librairie ssl plus à jour peut être fournie avec le logiciel supporté.
Et dans de nombreux environnements il y a un gros load balancer en frontend qui sert d'endpoint ssl, parce que c'est plus facile à gérer tous tes certs au même endroit, quite à ne pas chiffrer ou chiffrer avec des ciphers plus anciens entre le LB et les serveurs internes. Ça peut être vu comme moche mais pour certains c'est acceptable.
[^] # Re: À voir en vrai
Posté par gnumdk (site web personnel) . Évalué à 10.
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
- CentOS quand l'éditeur (Oracle ou autre) demande RedHat.
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.
[^] # Re: À voir en vrai
Posté par orfenor . Évalué à 4.
Dans ce que j'ai lu cette nuit (cf plus bas) il y avait plein de labos de recherche sous Centos, pour des besoins de logiciels précis.
[^] # Re: À voir en vrai
Posté par Renault (site web personnel) . Évalué à 4.
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.
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.
[^] # Re: À voir en vrai
Posté par vinishor (site web personnel) . Évalué à 1.
Je me permets de rajouter mes 2 cents, puisque j'ai un serveur CentOS à la maison et que je teste du BSD en parallèle.
Un truc que j'ai remarqué est qu'OpenBSD ou FreeBSD par exemple sont très stables et utilisables en entreprise, alors que les versions de leurs paquets sont beaucoup plus récentes que celles de CentOS 7 par exemple (CentOS 8 est moins en retard pour le coup, mais y a une différence quand même).
Donc, oui, la question du support à long terme n'est pas à balayer comme ça, mais techniquement, c'est possible de faire tourner des sites entiers avec des systèmes plus récents sans que tout casse d'un coup. Après, il doit y avoir une question de coût et de maintenance derrière, mais c'est une autre paire de manches.
[^] # Re: À voir en vrai
Posté par Joris Dedieu (site web personnel) . Évalué à 7.
C'est vrai que FreeBSD est très stable. Par contre les ports en rolling release demandent un gros travail de suivie et d'intégration. C'est justement pour éviter ce travail que le boites utilisent centos.
Pour utiliser les deux en production (et centos, et FreeBSD) je peux te garantir que ce n'est pas du tout le même travail.
[^] # Re: À voir en vrai
Posté par Bruno Ethvignot (site web personnel) . Évalué à 1.
Les ports en rolling release sont de mon point de vue une catastrophe. Je ne vois pas comment on peut maintenir un serveur en production avec ce genre de système.
[^] # Re: À voir en vrai
Posté par Psychofox (Mastodon) . Évalué à 2.
À base de snapshots et un serveur de build des ports. Tu ne vas quand même pas recompiler sur chaque machine.
[^] # Re: À voir en vrai
Posté par Bruno Ethvignot (site web personnel) . Évalué à 1.
Quand tu as un serveur en production sous FreeBSD et que le fait d'installer un module Perl, met à jour Perl dans une version majeure et casse le fonctionnement de SpamAssassin, j'avoue que ça fait peur…
[^] # Re: À voir en vrai
Posté par Psychofox (Mastodon) . Évalué à 3.
C'est pour ça que quelque soit le système d'exploitation en général on fait l'opération sur un environnement de test avant de le faire en production.
[^] # Re: À voir en vrai
Posté par Bruno Ethvignot (site web personnel) . Évalué à 3.
Sur un système Debian, qui n'est pas en semi-rolling release, tu peux installer un paquet Debian d'un module Perl sans casser la production.
Le système des ports en rolling release de FreeBSD est assez surprenant pour un système qui est réputé comme stable. Je trouve ça très très casse-gueule. Tu n'as pas toujours un autre serveur pour tester et tu peux difficilement tout tester.
Personnellement je préfère la politique Debian, aucune montée en version des logiciels sur un système d'exploitation. Seuls les correctifs de sécurité et certains correctifs de bugs sont sélectionnés et appliqués.
[^] # Re: À voir en vrai
Posté par Kwiknclean . Évalué à 1.
J'vois pas trop ce que ça demande comme travail, ou en tout cas pas plus que celui de l'intégration d'une montée de version de RH.
Par exemple t'es en PHP-7.3 , pkg ne va pas te changer violemment de branche sur la 7.4 sans prévenir, il reste sur la 7.3.
D'façon : iocage snapshot, update (problem ?) iocage rollback de la snasphot (ou équivalent tu remontes ton backup de jail avec ton outil de ton choix).
[^] # Re: À voir en vrai
Posté par lym . Évalué à 5.
Il faut dire qu'utiliser un clone Red-Hat ne se justifie vraiment que pour avoir une version d'OS homogène sur un parc matériel qui va forcément diverger sur les 10 ans de support assuré: Là, avoir Red-Hat qui se tape le boulot de backport du support du nouveau matériel arrivant en flux continu sur un kernel antédiluvien peut avoir une utilité.
Mais la contrepartie, c'est quand même des dépôts qui sont un vide absolu comparé à la richesse côté Debian. Les premiers mois/années, on peut au moins recompiler de manière a peu près fiable ce qui manque soit-même (pour éviter les acrobaties avec les dépôts de la Fée-Dora, sport de masse sous RH) mais cela se gâte très vite.
Pour ma part, entre la gestion de paquets inférieure (en disponibilité et à l'usage) et le cycle AMHA trop long, j'ai toujours trouvé que Debian offrait un meilleur compromis stabilité/nouveauté.
Scientific-Linux devenu un CentOS, après que RH ait déjà savonné la planche aux coucous d'Oracle, les jours de la "RH du pauvre" semblaient comptés. Car le débouché entre Fée-Dora et RH semble pour le moins limité.
[^] # Re: À voir en vrai
Posté par KiKouN . Évalué à 3.
C'est la faute de certains sites de moules où on y parlait à l'époque principalement de Debian et de Slack.
Fin, ça me convient.
[^] # Re: À voir en vrai
Posté par barmic 🦦 . Évalué à 9.
C'est pas une question de compatibilité. Sincèrement OSEF de ça. C'est une question de support. La plupart des services de support qui certifie avec RHEL acceptent CentOS. C'est une confiance qui prend du temps à acquérir. Prendre la marque CentOS pour en changer le contenu ça peut très bien mettre à mal cette confiance quelque soit la réalité et d'autant plus si pour une raison ou une autre il y a un problème dans l'une des premières versions.
Je comprends que Red Hat veuille vendre ses licences. Se faire payer son travail ce n'est pas sale.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: À voir en vrai
Posté par Maclag . Évalué à 5.
Mais est-ce qu'ils ne se tirent pas une balle dans le pied du coup?
Bill Gates avait admis qu'il préférait voir des machines avec un Windows pirate plutôt qu'avec un système concurrent.
Les fournisseurs de solutions "certifiées RedHat" vont sans doute bientôt recevoir des demandes pour le support d'autres distros, comme Debian ou plus probablement Ubuntu LTS. Quel volume, et à quel point ces demandes pourraient être suivies, c'est une grande question.
Mais un admin qui a fait du CentOS dans ces structures des années serait certainement plus enclin à prendre du RedHat le jour où il doit préparer une installation avec un support payant.
Maintenant, si l'admin a passé des annnées sous Ubuntu LTS parce que c'est ça qu'il connait, recommendera-t-il RedHat sans expérience de première main dessus?
[^] # Re: À voir en vrai
Posté par collinm (site web personnel) . Évalué à 1.
redhat et ubuntu ne joue pas trop dans la même cour
red hat a beaucoup de développeur sur de nombreux projet….. pas trop le cas d'unbutu
a devoir changer, j'opterais plutôt pour suse
www.solutions-norenda.com
[^] # Re: À voir en vrai
Posté par Pierre-Alain TORET (Mastodon) . Évalué à 1.
Intéressant, je n'ai pas du tout la même expérience en presque 10 ans au MEN avec uniquement des RHEL et quelques Debian historiques.
# une piste ?
Posté par Franck . Évalué à 5. Dernière modification le 09 décembre 2020 à 13:40.
pour info sur le github de Greg Kurtzer (createur du projet CentOS initial)
https://github.com/hpcng/rocky
[^] # Re: une piste ?
Posté par orfenor . Évalué à 3.
Le projet a migré sur https://github.com/rocky-linux et certains voudraient déplacer l'activité principale chez Gitlab
# CentOS se saborde‑t‑elle... et surtout qui saborde-t-elle en même temps ?
Posté par lcatinaud . Évalué à 6.
De mon point de vue c'est aussi très compliqué pour toutes les distros alternatives qui se basaient sur CentOS : sauf erreur, la modif va les obliger à changer de distribution de base pour s'assurer de la stabilité de leurs ajouts et de leur maintenance sur le long terme. Rude pour les projets dont la maintenance arrivait encore à être assuré par quelques personnes, car clairement, il va falloir faire le choix de migrer, lourdement, ou de tout arrêter :(
[^] # Re: CentOS se saborde‑t‑elle... et surtout qui saborde-t-elle en même temps ?
Posté par damaki . Évalué à 3.
Ça pourrait faire très mal à XCP NG. Mais ça va d'autant plus stimuler les communautés pour fournir à nouveau une alternative open source.
[^] # Re: CentOS se saborde‑t‑elle... et surtout qui saborde-t-elle en même temps ?
Posté par Plam . Évalué à 2.
Absolument aucun problème pour XCP-ng, ni de suite ni avant longtemps. Cf la réponse du release manager de XCP-ng ici : https://xcp-ng.org/forum/post/34224
# pourquoi ?
Posté par tbartolone . Évalué à -4.
Un choix bien évidemment ridicule de la part de CentOS
Au lieu de cela, il auraient pu créer un projet parallèle, tout en conservant CentOS.
Décidemment, jamais grand chose de stable très longtemps dans le monde de l'open source
[^] # Re: pourquoi ?
Posté par Christophe "CHiPs" PETIT (site web personnel) . Évalué à 8.
18 ans, c'est pas si mal !
[^] # Re: pourquoi ?
Posté par Renault (site web personnel) . Évalué à 9.
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. ;)
[^] # Re: pourquoi ?
Posté par Psychofox (Mastodon) . Évalué à 10. Dernière modification le 09 décembre 2020 à 14:53.
Ce qui est moche, c'est pas de migrer vers une rolling release. Ce qui est moche, c'est d'avoir sorti en 2019 la centos-8 en parrallèle avec la centos-stream et d'avoir annoncé qu'elle serait supporté jusqu'en 2029. Pour dire 1 an et 3 mois après quand de nombreuses entités/entreprises ont déjà lancé des campagnes de migrations que en fait non, l'année prochaine on coupe le support sauf si vous migrez vers la rolling-release.
Ils auraient très bien pu annoncer ce changement avant de sortir la 8, ou de la sortir avec un support à 2 ou 5 ans mais en l'annonçant dès le début, ou décider de continuer comme défini jusqu'à 2029 mais en précisant qu'il n'y aurait pas de version 9.
Ça c'est franchement malhonnête et normalement digne d'Oracle, pas de RedHat.
[^] # Re: pourquoi ?
Posté par Renault (site web personnel) . Évalué à 6.
Je suis d'accord que la transition (ou le timing) n'est pas bon pour cette annonce.
[^] # Re: pourquoi ?
Posté par Sébastien Wilmet . Évalué à 3. Dernière modification le 09 décembre 2020 à 17:48.
Je suis d'accord que c'est un coup bas de la part de Red Hat.
Mais en même temps, les utilisateurs de CentOS n'ont pas signé un contrat de support à long terme, et ne payent généralement rien. Voici un extrait de la licence GPL :
Le projet CentOS est tout à fait dans leurs droits, donc.
Mais c'est vrai que, il y a quelques années d'ici, le projet CentOS était encore un projet communautaire. Puis Red Hat a engagé deux ou trois développeurs clés du projet CentOS, pour initialement continuer le projet CentOS comme avant. Puis ils ont lancé ce CentOS Stream, puis voilà maintenant où ils en sont… Red Hat a en quelques sortes pris le contrôle du projet CentOS (!).
[^] # Re: pourquoi ?
Posté par Psychofox (Mastodon) . Évalué à 7.
Ça je crois que tout le monde en est conscient. Je ne parle pas de légalité, mais de respect et de confiance et on pourrait croire que non mais dans le domaine professionnel, ce que le projet centos revendique, ça a son importance.
[^] # Re: pourquoi ?
Posté par ddfdom . Évalué à 2.
c'est digne d'Oracle ou IBM et RedHat c'est maintenant IBM plus rien ne me surprends du coup
[^] # Re: pourquoi ?
Posté par Zenitram (site web personnel) . Évalué à 9.
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.
La critique n'est pas de forcer RH à faire quoi que ce soit, c'est d'avoir pourri à la Microsoft et d'autres ("achat" pour tuer) un truc qui aurait pu vivre sa vie tranquille.
Maintenant, ce que j'aimerai bien savoir c'est si celui qui a le nom de domaine a reçu de la thune (car la thune est partout, il ne faut pas se le cacher) pour filer les clés à RH, ou si il s'est fait berner comme un débutant à ne pas avoir protégé des rapaces…
En pratique, ce sera sans doute "juste" changer dans la tête le nom, comme Matamo a dû le faire contre un emmerdeur qui a posé un trademark sur l'ancien nom (Piwik). C'est lourd. Et oui, je sais, seulement si une personne est motivée, mais je pense qu'il y a un besoin qui sera rempli comme à l'époque… CentOS.
[^] # Re: pourquoi ?
Posté par Renault (site web personnel) . Évalué à -3.
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…
[^] # Re: pourquoi ?
Posté par Zenitram (site web personnel) . Évalué à 10. Dernière modification le 09 décembre 2020 à 21:39.
???
Il est complètement redéfini : c'est la base même du projet qui est balancé à la poubelle, sa raison d'être.
Alors OK ce qui est nouvellement proposé te plaît peut-être, mais ce n'est pas le sujet, ici le projet CentOS est pas un peu redéfini, il est bien tué, sous excuse d'une autre projet complètement indépendant.
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".
je n'ai absolument rien contre. Juste que ça n'a rien à voir avec CentOS, utiliser le nom CentOS pour ça est juste vouloir tuer CentOS tel que connu.
Ils auraient pu l'appeler… RHEL Stream, qui remplacerait RHEL, que ça aurait du sens de remplacer CentOS par CentOS Stream, mais non. Ils auraient pu utiliser un autre nom pour un projet complètement différent (ou au pire continuer avec CentOS tout en créant CentOS Stream), mais non, comment ne pas voir que c'est pour flinguer CentOS?
Euh… A moins que tu me démontres que CentOS Stream va rester 100% compatible RHEL de la même version, alors que RH dit l'exact contraire dans sa comme, ça a au contraire pas beaucoup de sens de ne pas considérer que CentOS va être tué en procédant ainsi…
PS : d'hab j'arrive bien à suivre ton argumentaire, logique et posé, il se passe quoi comme "amour" pour RH pour ne pas être habituel dessus?
[^] # Re: pourquoi ?
Posté par tisaac (Mastodon) . Évalué à 7.
C'est amusant parce qu'en lisant cet dépêche et les premiers commentaires, je me disais que si tu débarquais dans la discussion, ton attitude aurait été de dire
Donc, là, c'est un peu toi que je trouve ne pas être habituel.
En même temps, ici, je peux concevoir que ce qui est en jeu, n'est pas seulement un porteur de projet et son projet mais une communauté qui avait son projet, communauté qui a été racheté et puis un 180° est imposé au projet par le nouveau lead de "la communauté".
Surtout, ne pas tout prendre au sérieux !
[^] # Re: pourquoi ?
Posté par Zenitram (site web personnel) . Évalué à 4. Dernière modification le 09 décembre 2020 à 22:15.
Oui, c'est la différence qui fait que je ne fais ce que tu attendais.
Car pour moi c'est du même style que l'exemple GPL que je donne : trahir l'essence même du projet, sans respecter ses engagements (CentOS 8 qui change subitement de date de EOL par exemple).
Ca serait Ubuntu qui changerait leur business model, ils passeraient en rolling release, ben ça n'a jamais été vendu que le but était des versions tous les 2 ans (juste un moyen), donc ça passe. Ici l'essence CentOS est 100% compatible RHEL.
Et c'est ce qu'il se passera sans doute, merci le libre. Je fais la différence entre qui est le chef (RH a racheté la "marque", curieux de combien ils ont mis, pas très transparent dès le départ) et décide (ils sont libre), et l'âme de la communauté (qui peut se barrer et faire comme avant 2014) qui fera peut-être alors plus attention à ne pas perdre la marque.
C'est un rappel important pour tout groupe : même en libre celui qui a la marque a le plus de pouvoir, ça coûte mais ne sous-estimez pas la protection autant de la marque que du nom de domaine, protégez des individus qui pourraient vouloir la vendre ensuite sur votre dos.
[^] # Re: pourquoi ?
Posté par freem . Évalué à 8.
T'inquiètes, il a juste été un peu redéfini :)
[^] # Re: pourquoi ?
Posté par barmic 🦦 . Évalué à 5.
Ça n'est pas si simple. CentOS c'est une marque. C'est la seule distribution qui soit acceptée par les services de support qui certifie RHEL. C'est en ça que c'est un sabordage. On prend une marque qui gène et on casse son image. Pour revenir au même point il faut non seulement faire le travail de fork, mais aussi gérer l'image de ta distribution (avoir suffisamment de visibilité) pour qu'elle soit de nouveau acceptée.
Mais oui Red Hat gère ses marques et ses projets comme elle l'entends. Ça n'est pas un projet communautaire.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: pourquoi ?
Posté par Zenitram (site web personnel) . Évalué à 8. Dernière modification le 12 décembre 2020 à 12:10.
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.
Plus maintenant, oui. Depuis que ceux ayant le nom de domaine l'ont filé à RH.
Mais n'oublions pas qu'à la base, CentOS veut dire
Community enterprise Operating System
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.
[^] # Re: pourquoi ?
Posté par barmic 🦦 . Évalué à 3. Dernière modification le 12 décembre 2020 à 13:22.
C'est pas "en réalité", mais "par le passé". Ils ont pas volée la marque ils l'ont acheté. Ensuite si le principe qui veut qu'une entreprise fournisse sont produit payant et la copie identique gratuite ne paraît pas fragile, c'est assez naïf. Ils ont profité jusque ici, maintenant on va voir comment les choses se passent. Est-ce que RockyLinux va pouvoir se démarquer et en combien de temps ? Est-ce que les gens vont raquer pour avoir une vraie RHEL ?
Ce n'est pas à toi que je vais expliquer que le travail a un coût et que RH investie énormément dans tout l'écosystème linux (et dans le bureau linux ce qui ne rapporte pas des masses). Oui ça fait mal de se faire couper le robinet quand tu en profitais gratuitement, oui ils auraient pu être moins violent, mais il s'agit là d'épiphénomènes au concept de base : si tu veux une RHEL, achètes-en une. Ils font un travail suffisamment conséquent pour que ce ne soit pas du vol.
Tu parle d'oublier, mais ça n'est pas la première fois que RH fait ce genre de choses. Par exemple pour leur kubernetes managé, je sais plus si c'est le passage de la version 2 à 3 ou 3 à 4, ils ont laissé quelques semaines à leur clients pour faire le changement ! Et là c'est leurs clients à qui ils ont dit qu'ils devaient être passé à la nouvelle plateforme en moins de 2 mois.
A chacun de juger de la solidité de ce qu'il utilise. Le principe de faire des choix pas très solide (comme continuer à utiliser une distribution dont l'objectif ne semble pas en accord avec son possesseur) et se dire que si on gueule assez ça tiendra me fatigue un peu.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: pourquoi ?
Posté par Zenitram (site web personnel) . Évalué à 7. Dernière modification le 12 décembre 2020 à 13:50.
Pourquoi parles-tu de vol? Tu es le seul à utiliser ce mot comme si tu essayais de le mettre dans la bouche de tes contradicteurs, ça fait bizarre.
Les 2 les plus à défendre RH n'arrêtent pas de rappeler que c'est légal. Pourquoi? D'autres ont dit que ça ne l'était pas? Amener le sujet de légalité alors que personne n'en parle, c'est un aveu de faiblesse d'argument objectif sur le sujet?
Ca arrive, c'est la vente de support qui peut être un business model.
C'est un peu bizarre de lire ça sur un site libriste, vu que l'idée du libre est justement de ne pas être lié à cette description. C'est assez fou d'arriver à lire sur un site libriste un des classiques arguments contre le libre.
Ce n'est pas le sujet.
Ici on parle d'un engagement complètement lâché (CentOS devait être maintenu jusqu'à fin 2029, engagement sous la responsabilité de RH) et d'un projet tué.
Cette manie de défendre RH avec des truc hors sujet, y compris en reprenant le refrain anti-libre, montre surtout que vous n'avez aucun argument pour défendre RH.
Je ne veux pas une RHEL, pas besoin du support. Une CentOS d'avant fin 2021 me va.
Ca tombe bien, des gens prévoient de faire une "community enterprise operating system designed to be 100% bug-for-bug compatible with America's top enterprise Linux distribution"
Ho, dit donc, ça ressemble à un texte vu sur le site de CentOS il y a quelques années ;-), maintenant sur https://rockylinux.org . Avec un pic sur ce lâchage :
"Rocky Linux aims to function as a downstream build as CentOS had done previously"
Bref, il y a un besoin, je n'en doute pas, et il y a des gens qui veulent continuer ce qu'une entité décidé de tuer, en refaisant ce qui est tué (ils ont réussi une fois, le monde a changé depuis, mais aussi en simplifiant des process, et avec du sponsoring qui peut venir de grosses boites qui n’existaient pas à l'époque). Vive le libre :).
[^] # Re: pourquoi ?
Posté par barmic 🦦 . Évalué à 2.
Parce que tu semble leur reprocher d'avoir pris cette marque. Pourquoi les gens derrière CentOS qui apparemment était communautaire ont pu vendre ? D'ailleurs comment CentOS a pu être vendu si c'était communautaire ? Je présume que la partie communauté s'est perdu avant que RH n'arrive.
Je n'aime pas RHEL (pour RedHat plus généralement c'est plus compliqué il y a des choses que j'aime bien et d'autres pas du tout) et contrairement à toi qui semble découvrir que c'est une entreprise, je peux te donner des exemples d'autres bévues de leur part. Ce n'est pas parce que je te reprends que je défend RedHat je dis juste que c'est logique.
Hein ?! Mais tu troll à 10000% en fait1 ! Je vais donc arrêter là. Si tu n'es pas là pour échanger ce n'est pas la peine.
Parce que non zenitram ne confond pas libre et gratuit. ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: pourquoi ?
Posté par ckiller . Évalué à 2.
C'est beaucoup trop cher pour héberger un simple lamp,
349€ par an, faut pas déconner. et c'est chiant à renouveler tous les ans.
[^] # Re: pourquoi ?
Posté par barmic 🦦 . Évalué à 3.
Ce n'est pas fait pour. Tu as l'embarra du choix pour un lamp.
Qu'est-ce qui amène à vouloir une RHEL ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: pourquoi ?
Posté par ckiller . Évalué à 4.
Bof, Centos/RHEL ne serait pas ready pour faire serveur web. c'est nouveau ça.
Passons. A laréflexion, quand on voit la version des paquets php embarqués dans Centos 7 ou 8, tu as peut-être raison.
Les points qui aussi peuvent/pouvaient amener à choisir Centos.
SELinux beaucoup mieux intégrer que Debian qui considère par défaut que ce n'est pas installé (https://wiki.debian.org/SELinux)
Il y a d'autres distrib qui l'intègre proprement ?
Une stabilité qui permet de rester de se donner le temps de faire autre chose que des mises à jours d'OS
Ca dépend du nombre et se faire chier avec des licences, c'est un truc que je n'ai pas envie.
Bref, j'aimais bien centos, j'irais bien sûr voir ailleurs.
Une distrib qui allie sécurité et sérinité et un peu doc fait par des gens qui savent.
Et bien sûr, pas chez Red Hat, pourquoi ? parce que j'ai jamais aimé IBM.
Peut-être "alpinelinux". Cela me fera acheter moins de disquette.
[^] # Re: pourquoi ?
Posté par barmic 🦦 . Évalué à 1.
Ce n'est pas ce que j'ai dis. J'ai dis que si tu ne cherche que te faire un lamp sans prise de tête ce n'est pas fait pour. C'est fait pour faire un lamp qui ne bouge pas pendant 10 ans, c'est à dire que les versions de logiciels ne bougent pas sauf pour mises à jour de sécurité. Ce que tu semble découvrir quand tu dis :
Je ne sais pas, mais bon oui tu peux chercher tout ce que tu veux de plus ou moins unique dans CentOS ce n'est pas pour selinux que les gens utilisent centos. Elle n'est pas connue pour ça, ce n'est pas mis en avant par le projet, tu n'en vois même pas trace dans les commentaires, ni toi ni moi ne sommes au courant de si c'est une particularité ou pas, tu peux trouver des foules de recherches sur comment désactiver tout ou parti d'selinux et beaucoup moins pour ajouter des règles, ce n'est même pas une distribution qui s'annonce comme particulièrement sécurisé.
C'est ce dont je parle dans mon commentaire, mais supporté des versions non supportées upstream c'est un travail qui coute chère.
Ta licence de ton produit certifié aussi tu le paie par machine (voir par CPU quand on parle d'Oracle). Les licences "site" (qui te permettent d'en installer autant que tu souhaite) coûtent des prix fous.
Un coup tu lui reproche sa stabilité un coup c'est son intérêt.
Ton problème a 1 ans et demi du coup parce que ça fait un certain temps qu'IBM a racheté RH qui a racheté centos.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: pourquoi ?
Posté par Raphaël G. (site web personnel) . Évalué à -2.
Franchement SELinux c'est un peu de la sodomisation intellectuelle…
J'ai eu a subir ça chez un employeur, il faut deviner une partie des accès parce que ça ne remonte pas une partie des accès à des ressources de manière explicite et tout le monde trouve ça normal…
C'est vraiment limité au cas de figure où tu mets en place une application ou service en qui tu as pas confiance, si t'as la maîtrise de ce que tu mets en place ça a ZÉRO intérêt à mon avis.
Sur n'importe quelle distribution de base normale (Mageia, Fedora, *Rpm, *Deb, etc) t'as accès aux droits unix et éventuellement aux acls et franchement ça suffit largement dans la plupart des cas.
[^] # Re: pourquoi ?
Posté par claudex . Évalué à 6.
C'est vrai que les failles de sécurité, ça n'arrive que dans des applications pour lesquelles on n'a pas confiance.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: pourquoi ?
Posté par ckiller . Évalué à 2.
Au contraire. Les acls sont bien moins simple (et puissantes)
Je te conseille la lecture de https://blog.microlinux.fr/selinux/ "SELinux expliqué aux administrateurs frileux"
un système de défense ne doit pas se reposer sur une seule couche de sécurité
[^] # Re: pourquoi ?
Posté par Raphaël G. (site web personnel) . Évalué à 0.
Je pensais avoir choisi mes mots avec soin.
Les personnes qui ont un usage réellement utile de SELinux me semblent aussi nombreuses que les militaires dans la population générale, soit une proportion congrue.
Tu sembles considérer que tout le monde à le besoin d'avoir de multiples couches de sécurité et durcir tous les couches, ce n'est généralement pas le cas dans la vrai vie…
Je n'ai jamais dis que SELinux était moins puissant que les acls.
Je pense avoir voulu dire que dans 99% des cas, les acls suffisent.
Pour une application web par exemple et ça va se borner à des bons vieux :
setfacl -m u:apache:rwX vers/le/cache
setfacl -m u:apache:r /etc/app.conf
Quel intérêt d'aller explique que php peut rien exécuter dans vers/le/cache, tu peux très bien configurer apache-mod_php en collant un RemoveType .php sur le répertoire qui suffira largement.
Passé un temps SELinux marchait même pas sur XFS par défaut, fallait changer la taille par défaut de l'inode de 128 à 512 à la création du filesystem…
[^] # Re: pourquoi ?
Posté par claudex . Évalué à 3.
Et donc la moindre faille dans ton code php permettra d'exécuter ce qui est dans le cache.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: pourquoi ?
Posté par Raphaël G. (site web personnel) . Évalué à -3.
Pardonne moi, mais le dev qui utilise exec, include ou require pas sécurisé est juste à pendre.
Si tu fais du code sérieux, je vois zéro raison de charger du code dépendant de variable get/post/cookie sans nettoyage sérieux préalable !
De nos jours, t'as un système d'autoload dans la majorité des framework qui va te charger tout seul les classes dont t'as besoin sans risque.
La seule fois où j'ai eu à subir une magnifique injection sql c'est un rigolo qui avait oublié d'échapper correctement un authcode de transfert de domaine qui nous a fait un magnifique update sans clause where quand ovh a trouvé malin de fournir un truc du style "toto';bla" comme authcode…
C'est aussi possible de recruter des développeurs compétents qui font pas n'importe quoi :)
[^] # Re: pourquoi ?
Posté par claudex . Évalué à 7.
J'oubliais qu'il suffisait de dire aux dev de ne pas perdre de temps à ajouter des bugs et que magiquement, il n'y avait aucun problème dans le programme.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: pourquoi ?
Posté par Renault (site web personnel) . Évalué à 6.
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.
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.
[^] # Re: pourquoi ?
Posté par Zenitram (site web personnel) . Évalué à 4. Dernière modification le 12 décembre 2020 à 14:01.
Tu parles de quoi? CentOS Stream?
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.
J'avoue ne pas comprendre en quoi le "nouveau" CentOS a comme intérêt pour du communautaire.
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, et ceux voulant du communautaire vont vers Fedora (desktop, court terme) ou Debian (long terme), allez imaginons Ubuntu pour un mix communautaire piloté par une entreprise (Ubuntu a ses travers, mais ils sont connus :), pas toujours avec tout le monde d'accord mais moins violent dans les décision unilatérales comme le montre RH aujourd'hui).
Avant le passage "forcé" en tuant CentOS, CentOS Stream avait-il trouvé son public?
L'histoire dira qui de nous deux était le plus proche de la réalité.
[^] # Re: pourquoi ?
Posté par Renault (site web personnel) . Évalué à 4.
Oui, quoi d'autres ?
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.
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.
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.
[^] # Re: pourquoi ?
Posté par Renault (site web personnel) . Évalué à 4.
Question de point de vue.
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.
[^] # Re: pourquoi ?
Posté par Dante . Évalué à 10.
Redéfini c'est le moins que l'on puisse dire: la 1ère ligne sur https://www.centos.org/about/ :
The CentOS Linux distribution is a stable, predictable, manageable and reproducible platform derived from the sources of Red Hat Enterprise Linux (RHEL).
est tout simplement effacée.
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.
Heureusement qu'ils l'annoncent maintenant, la très grandes majorité des serveurs a encore les 4 ans restant de la centos7 pour mettre en place une autre solution.
[^] # Re: pourquoi ?
Posté par Renault (site web personnel) . Évalué à 2.
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.
[^] # Re: pourquoi ?
Posté par PLuG . Évalué à 10.
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 !
Dans ce cadre Centos est utilisé pour avoir une version RHEL beaucoup moins chère. C'est la version gratuite de RHEL qui interesse ces institutions.
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.
Je ne suis pas sûr que du coup les clients prennent du support pour 100% de leur parc, ou que les milliers de machines centos passent en RHEL, à moins que RedHat fasse en même temps une offre commerciale qui déchire pour ce genre d'usages.
Les débouchées sont Oracle Linux ou un fork de Centos
[^] # Re: pourquoi ?
Posté par Fulgrim . Évalué à 2.
Si c'est pour les serveurs intégration/preprod mais qu'on t'a distribué une RHEL pour ta prod, vue que cette dernière est libre tu peux pas t'appliquer la GPL et l'installer aussi sur ces serveurs (sans support, comme les centos gratuites) ?
[^] # Re: pourquoi ?
Posté par Zenitram (site web personnel) . Évalué à 2.
La distro est libre, mais ne te libère pas du droit des marques, et c'est exactement pour ça que CentOS existe (existait) : pouvoir installer sur ces serveurs sans support (dont on n'a pas besoin).
Si la réponse à ta question était positive CentOS n'aurait eu aucune raison d'être ;-).
[^] # Re: pourquoi ?
Posté par Psychofox (Mastodon) . Évalué à 5.
Techniquement tu peux prendre une redhat qui a une souscription, faire des mirroirs des repos redhat depuis celle-ci et configurer des redhat sans souscription pour avoir accès aux miroirs.
Mais mais mais : il me semble de mémoire (je ne gère plus de système redhat) que parmi les termes de la souscription tu t'engages quand tu souscris un système à payer une souscription pour chaque autre système Redhat de ton réseau.
Donc la question n'est pas lié à la marque redhat et aux logos, ni aux faits que les paquets sont sous gpl ou non. C'est le contrat qui te lie à RedHat pour avoir la souscription (que tu ne peux éviter pour avoir accès aux repos redhat) qui t'en empêche.
[^] # Re: pourquoi ?
Posté par Zenitram (site web personnel) . Évalué à 1.
Ca doit quand même être lié, un peu chaud, risqué, d'utiliser un logo RH sans accord de RH.
Aussi, oui.
A ce sujet, voir le contrat grsecurity similaire, certains ont hurlé à la violation de GPL tout ça… Mais en fait la GPL n’empêche pas de bloquer l'accès direct au patch suivant (contrat entre 2 parties, hors GPL donc) et personne en réalité ne fait de procès car l'issue est connue.
[^] # Re: pourquoi ?
Posté par PLuG . Évalué à 1.
oui et non, si tu ne prends pas le support, tu n'accèdes pas aux mises à jour.
[^] # Re: pourquoi ?
Posté par Renault (site web personnel) . Évalué à 4.
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.
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.
[^] # Re: pourquoi ?
Posté par PLuG . Évalué à 5.
En fait, quand tu fais de la PRODUCTION, tu veux le MEME système. Pas en avance, pas en retard, juste le MEME.
Je ne dis pas que Centos devient Fedora (et j'utilise beaucoup Fedora et ce n'est pas instable non plus …).
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".
[^] # Re: pourquoi ?
Posté par Renault (site web personnel) . Évalué à 2.
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.
[^] # Re: pourquoi ?
Posté par Zenitram (site web personnel) . Évalué à 2.
Ha, mais c'est facile à virer cet effet de bord, suffit d'ouvrir le repo RHEL… Ha, comment ça c'est trop facile et du coup ça enlèverait l’intérêt de tuer CentOS? ;-).
Ce n'est pas un effet de bord, c'est voulu.
Alors que c'est si simple, suffit d'ouvrir le repo en public… Sauf si l'idée est de tuer ce pourquoi CentOS était fait ;-).
Il sera inutilisable pour ce pourquoi il a été fait depuis 15 ans (être une copie conforme de RHEL).
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.
[^] # Re: pourquoi ?
Posté par Renault (site web personnel) . Évalué à 4.
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.
[^] # Re: pourquoi ?
Posté par Zenitram (site web personnel) . Évalué à 1.
OK, donc on est d'accord que RH tue CentOS?
Qu'on aime ou pas le choix, on peut quand même le nommer.
Ma réaction initiale était sur ton "un peu redéfini", pas sur un débat d'exagération ou pas. Tuer un projet n'est pas "un peu le redéfinir", c'est le tuer, pas la peine de tourner autour du pot pour défendre ce choix, tu peux le défendre en disant ce mot si tu penses que c'est la bonne chose à faire.
CentOS Stream n'ayant aucun lien avec RHEL, c'est un autre projet hors sujet avec un nom emprunté à un truc hors sujet… On sait maintenant pourquoi en fait (marketing… Mais bon CentOS étant utilisé par des techos, ça ne marche pas pareil qu'avec les décideurs pressés).
J'avoue que je n'avais pas vu le piège marketeux avant.
[^] # Re: pourquoi ?
Posté par Glandos . Évalué à 2.
Ah c'est pour ça que CentOS utilise Pagure : https://git.centos.org/
Profession : troll.
[^] # Re: pourquoi ?
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 10 décembre 2020 à 07:52.
Si la FSF décide que la GPLv4 a une clause NC, ça serait à peu près libre (ce n'est qu'un petit changement), donc OK pour toi? Si la FSF décide que la GPLv4 devient comme MIT, ça serait à peu près du libre car ce n'est qu'un changement de copyleft à copyfree et c'est toujours libre donc ça va pour toi? et en plus la FSF a le droit de changer d'avis et tous les gens qui on mis GPLv3 ou supérieur et dit que quoi que ferait la FSF ça serait OK?
Le problème que tu ne vois pas est que CentOS est à la base, ça raison d'être à la base, de ne pas être à peu près RHEL, mais de l'être exactement.
Rien de légalement problématique, c'est certain, tout est question de confiance.
Ce qui brise encore plus la confiance qu'une communauté peut porter sur RH. Ce changement n'est pas que très fort, il revient même sur les anciennes promesses.
Les promesses n'engagent que ceux qui y croient, certes, et aucun engagement légal. Mais la communauté qui a suivit CentOS et RH a bien le droit de se poser la question de la confiance et réfléchir à la suite : continuer à faire la pub indirectement de RH, qui a fait un très sale coup, en reprenant ce qui avait été fait il y a 15 ans (avec un RH pas sponsor mais pas en mode attaque), ou aller voir ailleurs (le monde a changé, bouge plus rapidement, qui sait peut-être que les 5 ans de Ubuntu sont suffisant de nos jours, et qui sait peut-être que Ubuntu en profiterait pour s'engager sur plus longtemps hors "Extended Security Maintenance" coûteux pour attirer plus de monde; ou qui sait les gens parleront d'un CentOS pour prolonger les Ubuntu en rebuildant les patchs de Ubuntu en ESM… Peut-être l'heure du choix, autant pour une communauté que pour une entreprise)
[^] # Re: pourquoi ?
Posté par Pol' uX (site web personnel) . Évalué à 0.
Dans la liste des raisons qui font que la GPL est un bon choix de licence, il y a l'article 14 (Revised Versions of this License) qui encadre les modalités de révision de la licence avec un engagement formel de la FSF que « new versions will be similar in spirit to the present version ».
Adhérer à l'April, ça vous tente ?
[^] # Re: pourquoi ?
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 10 décembre 2020 à 11:39.
JUSTEMENT.
Renault dit en pratique qu'un détail majeur est un détail mineur ("un peu redéfini"), mon exemple est exactement ça : définir "in spirit", qu'on peut tordre pour excuse un changement majeur.
Tu n'as pas fait attention à mes exemple choisi exactement pour ce que tu dis alors que tu m'opposes cette phrase :
- L'un est très adoré par une tonne de libristes qui pensent que des méchants ont pris d’assaut le libre et qu'il faut corriger. "similar in spirit" peut passer si on le tort à peine (même pas besoin de tordre comme le fait RH ou Renault avec CentOS).
- L'autre est toujours compatible avec les 4 libertés définies par RMS et la FSF, ui peuvent être changée comme l'idée originale comme CentOS a changé son affichage "copie conforme". "similar in spirit" peut passer si on le tort un peu plus.
Bref, c'est bien de ça dont je parle, de quand un projet avec une base décider de tuer cette base sans le dire (en le faisant passer pour un changement mineur, une idée identique, etc).
Tout est dans la définition de "similaire"… Ici, quel que soit l'affichage c'est bien l'idée première de ce qu'est CentOS (et qui était affiché en grand pendant 15 ans) qui est tué, j'ai du mal à comprendre comment quiconque peut voir autre chose que flinguer CentOS tel qu'il est dans l'idée ("spirit") et comment on peut dire "un peu redéfini" dessus, à part les markéteux de RH.
[^] # Re: pourquoi ?
Posté par Pol' uX (site web personnel) . Évalué à 1.
Les tricheurs tendent à penser que tout le monde triche. C'est d'ailleurs « marrant » d'être aux prises avec un tricheur et de s’apercevoir de la situation au fur et à mesure qu'on se fait prêter des intentions foireuses alors qu'on sait qu'on était plutôt dans l'innocence voire la naïveté.
Moi je n'ai fait que mettre une aparté dans la discussion, mettant en lumière un élément qui n'est pas nécessairement connu de tous mais qui a sa pertinence, par exemple lorsqu'on fait un choix de licence.
C'est cocasse de se faire désigner d'opposant pour ça par la personne « opposante systématique » probablement parmi les plus toxiques de ce site.
Adhérer à l'April, ça vous tente ?
[^] # Re: pourquoi ?
Posté par Jean Gabes (site web personnel) . Évalué à 10.
Heu ok tu sembles vouloir faire le service après vente/pompier sur cette annonce, mais faut pas prendre les admins pour plus bêtes qu'ils sont. C'est un "buy to kill" fait par IBM pour augmenter ses revenus à court terme via la vente de licences RH. Point. Ils ont tout à fait le droit, aucun soucis là dessus. Mais faut pas tenter de le cacher non plus.
Par contre la fuite va être massive passé 2/3ans, car un coup comme ça, tu le fais pas deux fois, et ta crédibilité en tant que "gestionnaire de communauté" est morte en même temps que l'atomisation du temps de support.
# Fork probable
Posté par David Demelier (site web personnel) . Évalué à 8.
Pour ceux qui sont fans de RHEL et aimaient CentOS, je suppose qu'il y aura assez de gens mécontents pour démarrer un fork identique. À vrai dire, CentOS c'est principalement un simple rebuild massif des .src.rpm. Si des gens sont motivés, il suffira de le refaire®.
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.
Et à choisir, je préfèrerai largement fedora dans ce cas qui a l'avantage d'avoir une immense base utilisateur et COPR.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Fork probable
Posté par Renault (site web personnel) . Évalué à 3.
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.
[^] # Re: Fork probable
Posté par eingousef . Évalué à 10.
Du coup c'est ça le plan si j'ai bien compris ?
bravo les mecs, vous avez inventé les branches
_o_*splash!*
[^] # Re: Fork probable
Posté par legranblon (site web personnel) . Évalué à 10.
En fait, c'est un aveu à demi-mot que leur modèle actuel marche mal et que debian avait raison depuis le début … Vous verrez, ils passeront à apt et au .deb ;-)
[^] # Re: Fork probable
Posté par David Demelier (site web personnel) . Évalué à 7.
Pour avoir déjà contribué quelques RPM et essayé des paquets debian, je me demande comment les paquets debian peuvent avoir plus de popularité.
L'avantage des RPMs côté développeur, c'est qu'il n'y a pas besoin de doctorat pour en écrire 🙃
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Fork probable
Posté par Guillawme (site web personnel, Mastodon) . Évalué à 1.
Cette lecture m’avait suggéré le contraire : https://linuxfr.org/users/guillawme/liens/argh-p-m-dissecting-the-rpm-file-format
Mais bon je n’y connais rien, j’ai seulement utilisé apt et dnf mais je n’ai jamais essayé de produire des paquets.
[^] # Re: Fork probable
Posté par Raphaël G. (site web personnel) . Évalué à 2.
L'organisation en rpm c'est un fichier spec qui fait toute la procédure de génération du paquet.
Au final ça se résume à avoir le tar.gz/bz2/xz + fichiers patch dans SOURCES et le fichier .spec dans SPECS.
Pour ce qui est des fichiers debians, c'est un peu la fête du slip, t'as le fichier source, auquel est appliqué un patch tar.* qui pose un répertoire debian avec tout un tas de chose dedans.
Je suis pas objectif, je package pour Mageia, mais le format debian, je n'y vois vraiment aucun avantage, même maintenant…
Le seul "défaut" du rpm, c'est qu'on a besoin d'un système de gestion de dépendance qui n'est pas fourni par rpm, mais urpmi/dnf/yum/yast/up2date/etc…
Si on regarde côté debian, de toute façon, personne installe un .deb à coup de dkpg -i, au final apt-get update & apt-get install ça revient bien au urpmi.update -a & urpmi.
[^] # Re: Fork probable
Posté par Victor STINNER (site web personnel) . Évalué à 2.
J'utilise Fedora sur mon poste de travail depuis de nombreuses années et c'est très stable. La migration d'une version à l'autre se fait sans aucun soucis (aucun soucis majeur dumoins, y'a toujours des petits bricoles) tous les 6 mois (avril et octobre).
Fedora est un OS à part entière. RHEL est plus un fork qu'une branche de Fedora.
[^] # Re: Fork probable
Posté par reno . Évalué à 4.
Dommage on n'est pas Vendredi autrement j'aurais rappeler le coup de KDE4.0 mis par défaut sur Fedora alors que côté projet KDE on voyait ça comme une version expérimentale..
/S
[^] # Re: Fork probable
Posté par Olivier Abad . Évalué à 1.
On est maintenant vendredi alors je peux.
Je n'ai pas trouvé les mots "alpha" ou même "beta" dans les release notes !
[^] # Re: Fork probable
Posté par Psychofox (Mastodon) . Évalué à 1. Dernière modification le 11 décembre 2020 à 09:31.
Toutes les distribes ont proposé du 4.x et il n'y avait pas que la 4.0 qui était foireuse, toute la branche était instable et globablement à chier.
Et il y a prescription, c´était il y a 12 ans. Je réutilise Fedora depuis la version 28 et donc sur les 5 dernières versions je n'ai pas eu de problème particulier.
[^] # Re: Fork probable
Posté par fabrices . Évalué à 0.
Les bricoles du genre poweroff pour reprendre la main … tu comprends pourquoi sur Centos tu as un kernel 3 au lieu de 5
Perso pour un poste de travail, avec Fedora/KDE il y a un peu trop de couacs
Et c'est parfois aussi trop récent, il faut un peu de 6ème sens pour faire tourner minikube sur cgroups2
J’exclue pas que WSL va prendre une bonne part de marché sur ce segment … un conteneur pour le dev, tu veux une base de données pas de soucies
# Résumé des infos de cette nuit
Posté par orfenor . Évalué à 10. Dernière modification le 09 décembre 2020 à 15:07.
Ayant des serveurs Centos, j'ai (sur)veillé cette nuit dans trois principaux fils de discussion :
Je reporte de mémoire sans références, désolé.
Sur l'intérêt de Centos
Les autres clones
Les autres distributitions
Plus jamais Red Hat
RockyLinux
C'est le nom, provisoire peut-être, du nouveau clone de Red Hat immédiatement lancé par l'entreprise de Greg Kuntzer. Greg est à l'initiative de Centos, il sait faire. Plein de monde le rejoint. Surtout des bonnes volontés pour l'instant. Greg propose de payer des gens (il a les sous). On réclame une gouvernance communautaire pour empêcher un rachat.
[^] # Re: Résumé des infos de cette nuit
Posté par Glandos . Évalué à 4.
Commentaire supplémentaire sur https://lists.debian.org/debian-devel/2020/12/msg00122.html
C'est un peu tristement drôle, puisque ça y dit que de toutes façons, le futur, c'est pas la compatibilité binaire, vu que tout est « conteneurs ». Pour ceux qui ne sont pas d'accord avec ça, vous fatiguez pas, j'y ai déjà répondu ;)
Sinon, on y apprend quand même que l'annonce était déjà passée en août, mais inaperçue à cause de la pandémie. C'est vrai ce mensonge ?
[^] # Re: Résumé des infos de cette nuit
Posté par fero14041 . Évalué à 2.
Grand merci, orfenor, pour ce somptueux résumé!
[^] # Nouveau résumé des infos de cette nuit
Posté par orfenor . Évalué à 10.
Une nouvelle nuit a passé, mais cette fois j'ai dormi.
En plus j'ai une urgence sur un système bien planté : celui de mon frangin qui n'a pas osé me déranger tout de suite (apprenez l'autonomie à votre famille, mais faites rentrer dans leur crâne à coup de marteau qu'une obscure ligne de commande glanée sur un forum n'est pas une façon de réparer).
Ça se structure vite et beaucoup. Il n'y a pas grand chose à raconter, ça bosse loin des discussions. Il y a maintenant deux acteurs puissants et prêts à financer un clone :
Rocky Linux
C'est le clone lancé par Greg Kuntzer qui s'appuie sur son entreprise et a déjà réuni et structuré une équipe. Le site web se construit et une communauté chinoise promet de s'organiser.
Le nom choisi est un hommage ému a un grand ancien de l'équipe Centos trop tôt disparu. Quelqu'un qui marquait les esprits :
Le Slack est très encombré de blabla et de discussions sur la forme a prendre (fondation, asso, …) et les outils a mettre au point, sans que les principaux concernés ne répondent. Ils préfèrent bosser.
Cloud Linux
Je vous renvoie au communiqué officiel. Ils ont les ressources matérielles, humaines et financières et sont parfaitememt au courant de Rocky Linux. Et ils veulent se garantir eux-mêmes contre la tentation de refermer le projet :
Du côté des chercheurs
Scientific-Linux était un clone direct de RHEL, coexistant avec Centos, Oracle et Springdale. Mais sa dernière version se base sur Centos et plus sur Red Hat. La communauté scientifique attend de voir ce que le CERN et les université américaines vont décider par rapport à Scientific-Linux C'est assez critique pour la science parce qu'ils ont des milliers de bécane tournant avec.
[^] # Re: Nouveau résumé des infos de cette nuit
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
Peut-être que SL va juste attendre (y a encore quelque mois pour se décider …mais c'est chaud pour bosser sereinement) si ça va se baser sur RockyLinux ou directement sur RHEL (dans ce dernier cas, il y a tout le travail supplémentaire de la communauté par rapport aux logos et éléments de marque déposée ainsi que la mise en place de dépôts etc.) ?
Il faut noter aussi que le CERN se tourne vers la compilation croisée des principaux outils de la communauté scientifique et un système de gestion/paquetage qui s'affranchi de toute plateforme… (je crois qu'il y a eu un journal ou une dépêche dessus par ici) Donc ce peut être le moment d'en virage où SL s'endormirait pour toujours.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Nouveau résumé des infos de cette nuit
Posté par Psychofox (Mastodon) . Évalué à 2.
Pour l'instant mis à part Springdale c'est Cloudlinux qui semblerait prêt en premier. Il maintiennent déjà une distro basées sur centos8 avec leurs outils proprios ajoutés en plus, donc ils ont déjà tout l'outillage et les processus de synchro, il faut juste qu'ils fasse une branche libre sans leurs outils proprios et le rendre publique.
Rockylinux étaient encore à se demander comment faire sur leur slack avant ce week-end.
[^] # Re: Résumé des infos de cette nuit
Posté par fabrices . Évalué à 0.
Red Hat a quand même le mérite de fournir une documentation de synthèse et en libre accès ( pour l'instant ) !
Un jour j'ai voulu installer une distribution sur un vieux 32-bit et j'ai dû me rabattre sur Debian … au moment de configurer la stack réseau, je me suis posé la question c'est quoi la stack sur cette Debian ??? … je fais une recherche sur Google, et je trouve que des docs Debian qui datent de … désespoir, pas envie de lister les paquets installés, pas envie de chercher pendant une semaine dans des mailing lists … je me dis que je vais tenter ma chance en utilisant la doc de RHEL … ouf ça marche … mais franchement Debian … donc ça va si tu suis son développement en continu, mais pas si tu dois prendre le truc en main sur le pouce sur un serveur … Je parle d'IT sur serveurs pas de Linux mumuse
[^] # Re: Résumé des infos de cette nuit
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
Je dis peut-être une bêtise, mais je pense (ai l'impression) que depuis un certain temps, il n'y a plus d'archives de versions plus maintenues. (enfin, ça peut se trouver si on sait où chercher, mais c'est juste plus dans les accès officiels…)
Du coup, la doc Red Hat que t'as trouvée c'est à cause du support long que recherche les entreprises.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# NixOS
Posté par cluxter . Évalué à 1.
Pour l'administration d'un serveur, je crois que le top du top est NixOS. C'est une distrib qui est en train de prendre de l'ampleur et pour l'avoir essayée je pense que ça va continuer. Dès que j'ai un moment je passe mon serveur dessus. C'est peut être le moment pour un certain nombre d'administrateurs de s'y mettre, ou au moins de l'essayer.
[^] # Re: NixOS
Posté par Psychofox (Mastodon) . Évalué à 8.
Indépendemment des spécificités techniques des distribs, le choix est parfois directement lié à l'achat d'une licence ou du support d'un logiciel.
[^] # Re: NixOS
Posté par zimoun . Évalué à 2.
Oui, clairement les principes derrières Nix ou Guix sont vraiment à regarder. Le côté déclaratif et sans état, ca facilite la vie dans l'administration des parcs. Enfin, de mon point de vue. :-) Et même conceptuellement, une même machine peut avoir différentes branches (stable, testing, experimental, etc.) qui coexistent.
# copyright pas de moi
Posté par farib . Évalué à 5.
C'est l'histoire de la vie
Le cycle éternel
Qu'un enfant béni
Rend immortel
La ronde infinie
De ce cycle éternel
C'est l'histoire
L'histoire de la vie
[^] # Re: copyright pas de moi
Posté par Sak . Évalué à 1.
ok
# Commentaire supprimé
Posté par mobuysellram . Évalué à 0. Dernière modification le 09 décembre 2020 à 19:26.
Ce commentaire a été supprimé par l’équipe de modération.
# il y a une pétition sur change.org
Posté par PLuG . Évalué à 2.
https://www.change.org/p/centos-governing-board-do-not-destroy-centos-by-using-it-as-a-rhel-upstream
pour ceux que cela intéresse …
[^] # Re: il y a une pétition sur change.org
Posté par tisaac (Mastodon) . Évalué à 10.
Je trouve ironique d'utiliser une plateforme dénommée change.org pour s'opposer à un changement de cap :-)
Surtout, ne pas tout prendre au sérieux !
[^] # Re: il y a une pétition sur change.org
Posté par fabrices . Évalué à -1.
mouais … Red Hat est une entreprise à but lucratif qui payent des gens pour entre autre développer du libre. Pas sûr que Gtk existerait encore sans les sous de RHEL …
L'IT change, Red Hat s'adapte, ont ils un intérêt à maintenir un clone gratuit de RHEL ???
Pour des conteneurs sur AWS et cie, Amazon peut se passer de Red Hat et le client n'a pas forcément besoin de Centos en tant que distribution classique.
[^] # Re: il y a une pétition sur change.org
Posté par Zenitram (site web personnel) . Évalué à 6.
Arrêtez avec ces excuses bidons pour gens assez idiots pour gober ça : si c'était vraiment la raison, RH aurait annoncé la fin de RHEL 8 pour fin 2021.
Pour la raison pour laquelle ils ont maintenu pendant 5 ans (suite à sponsoring de leur part).
Si la raison n'était pas bonne, fallait pas le faire
Si la raison n'était plus bonne, fallait laisser CentOS repartir en solo
Appeler un chat un chat : ici, ce n'est pas un manque d’intérêt, c'est une volonté de tuer un truc dérangeant. Rien de passif, c'est très actif, et c'est ça qu'il ne faut pas oublier.
# BSD
Posté par mohamed.berzig . Évalué à 0.
Pour moi Linux c'est fini, je passe sur OpenBSD
# Mageia
Posté par Raphaël G. (site web personnel) . Évalué à 0.
Me moinsez pas s'il vous plait :)
Sinon il est peut-être l'heure de donner votre coup de main à la finalisation de la Mageia 8 qui est en cours.
Vous aurez ainsi une distribution flambant neuve pour tous les usages dont vous rêviez, du franco-français à la base et soutenu par une équipe internationale de compétition ^_^
Pour contribuer c'est par ici :
https://www.mageia.org/
Perso j'ai mon accès contributeur depuis des lustres et je fixe tout ce qui me va pas chaque fois que je suis assez
énervémotivé et ça fait une super distribution.Big up à ennael et les autres sans qui ce projet n'aurait jamais existé :)
[^] # Re: Mageia
Posté par Zenitram (site web personnel) . Évalué à -1.
Ben, du hors sujet colleur d'affiche…
Celle qui ne voit aucun problème à avoir ses propres serveurs avec une version de distro qu'elle a elle-même indiquée comme plus maintenue, ou ça a changé?
PS : tu fais du hors sujet, je fais du hors sujet, égalité.
[^] # Re: Mageia
Posté par Raphaël G. (site web personnel) . Évalué à 1.
Hum, on attends tes contributions pour payer les sysadmins de mageia a mettre à jour des machines non critique de l'infrastructure…
On est quand même sacrément loin des épisodes de debian qui a réduit à 65535 clés possibles en shootant l'entropie via un patch qui corrigeait des avertissements de compilation…
J'ai un accès contributeur chez eux, même sur un paquet sur lequel je suis le développeur, pour un client letsencrypt https://git.rapsys.eu/acme/
J'ai du passer comme tout le monde par la procédure complète (rapport de bug, triage, validation, push admin) pour pousser un paquet de mise à jour sur la version courante.
Faut aussi comprendre que les furieux d'antan qui avaient pas de vie et passaient leur temps sur du logiciel libre sont passé à autre chose et font ce qu'ils peuvent désormais…
Par exemple, j'ai passé du temps en packaging lua en local pour mettre en place un Jitsi Meet et corrigé pas mal de bugs sur la pile lua, rien que remonter ça dans mageia ça prend une petite semaine que j'ai pas forcément.
[^] # Re: Mageia
Posté par barmic 🦦 . Évalué à 3. Dernière modification le 24 décembre 2020 à 09:25.
Ça questionne tout de même la durée de vie des versions si elle est trop courte même pour le projet, non ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Mageia
Posté par BAud (site web personnel) . Évalué à 3.
et ça fait gagner des semaines à pas mal de monde qui l'a aussi rencontré :-)
merci pour avoir eu cette démarche méliorative :p
c'est un peu l'objectif et tu l'as bien compris ou te le connais déjà bien : une petite action sert à pas mal de monde (bon, ils ne s'en rendront pas compte, certains le remarqueront, tant mieux) et c'est ça qui peut servir à tout le monde, tant mieux, tant pis si ça t'a pris du temps, en même temps tu voulais que cela fonctionne pour toi :-) bref
au plaisir de se revoir, si possible pas masqué :/
# Fedora ?
Posté par Denis Szalkowski . Évalué à -4.
Gregory Kurtzer ne ferait-il pas mieux d'intégrer le projet Fedora ?
[^] # Re: Fedora ?
Posté par BAud (site web personnel) . Évalué à 0. Dernière modification le 05 janvier 2021 à 01:27.
Fedora et CentOS sont 2 projet très distincts, même s'il y a de la perméabilité…
C'est complexe on va dire.
Je laisserai des personnes plus au fait pour élaborer, afin de ne pas m'attirer les foudres de pas mal de potes (le souci n'est pas Red Hat, c'est IBM actuellement qui ne comprend rien, eh merde j'en ai trop dit… bah blue shark, big blue, comprenne qui pourra et fuck ibm pour avoir tué OS/2).
# Question potentiellement stupide...
Posté par omer666 . Évalué à 2.
…mais n'est-il pas plus facile de créer un nouveau clone de RHEL maintenant qu'on a ouvert le développement upstream ?
De même, y a-t-il des retours sérieux sur la compatibilité de CentOS Stream avec RHEL à l'heure actuelle ?
Attention, je ne cautionne en rien la décision prise, cependant je questionne son supposé impact négatif.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.