10 ans après la création de Fedora, Red Hat récidive en refondant le projet CentOS.
CentOS devient un projet sponsorisé par Red Hat, l'objectif principal étant d'accélérer l'adoption d'Entreprise Linux (RHEL & clones) et pour CentOS de franchir une étape supplémentaire pour être plus qu'un clone de RHEL. Les clones de RHEL font partie de la stratégie commerciale de Red Hat depuis des années et cette nouvelle ne fait que la confirmer.
Parmi les changements, on observera :
- une nouvelle gouvernance : le comité actuel est conservé mais voit arriver de nouveaux membres, des contributeurs historiques comme Fabian Arrotin et des membres nommés par Red Hat (Carl Trieloff, Karsten Wade, Mike McLean) ;
- une gouvernance plus ouverte que par le passé (grâce à des groupes d'intérêts) ;
- Karanbir Singh, leader du projet depuis 9 ans rejoint l'équipe Open Source And Standards pour superviser le « nouveau » CentOS ;
- des contributeurs seront employés par Red Hat pour travailler à temps plein sur CentOS ;
- la marque CentOS et ses aspects légaux seront gérés par Red Hat Legal ;
- et il était plus que temps, le site officiel de CentOS a droit à une cure de jouvence !
Par contre, certaines choses ne changent pas :
- CentOS et RHEL restent des projets distincts et indépendants : gouvernance, systèmes de construction des distributions ou ressources matérielles (entre autres) sont toujours séparés ;
- aucun changement pour Fedora qui continue sa réflexion sur son modèle de release (Fedora.Next).
Quelques détails
Les personnes
Karanbir Singh n'est pas le seul à rejoindre Red Hat, trois autres principaux contributeurs de CentOS sont aussi embauchés Jim Perrin, Johnny Hughes et Fabian Arrotin.
Les groupes de travail et CentOS variants
Il s'agit en fait d'une (re)formulation de quelque chose qu'on observe déjà : CentOS a pour but d'être fidèle à RHEL, et minimise les écarts techniques envers celle-ci. Les ajouts de fonctionnalités sont réalisés via des dépôts supplémentaires (comme CentOSplus). Certains ajouts font l'objet d'un groupe de travail (nommé SIG pour Special interest groups). C'est le cas en particulier de Xen4CentOS. D'autres groupes de travail sont présents, comme OpenStack, Gluster et oVirt.
Ces groupes de travail permettent, à partir d'une base stable, de créer un système avec des fonctionnalités supplémentaires, si possibles éprouvées. De la même manière qu'on a pu observer la création de « spins » de Fedora, on assistera à l'apparition de « variants » de CentOS.
Aller plus loin
- Projet CentOS (569 clics)
- FAQ CentOS chez Red Hat (207 clics)
- L'annonce de Karanbir Singh sur la liste CentOS (91 clics)
- Robyn Bergeron (Fedora Project Leader) accueille CentOS (71 clics)
- L'annonce sur le site de Red Hat (158 clics)
# Bonne nouvelle (enfin je pense)
Posté par ManuxFr (site web personnel) . Évalué à 4.
Utilisateur de CentOS depuis 2008, je pense que c'est une excellente nouvelle…
Et puis un francophone dans l'équipe, ça peut être que mieux :)
[^] # Re: Bonne nouvelle (enfin je pense)
Posté par GeneralZod . Évalué à 4.
Y en a deux: Tru et Fabian ;)
# Choix ?
Posté par Kerro . Évalué à 5.
Une question pour les connaisseurs (j'utilise principalement Debian) : cela veut dire en gros que si on veut un quasi-clône de RHEL il est désormais mieux de choisir CentOS ?
[^] # Re: Choix ?
Posté par Maclag . Évalué à 10.
C'était pas déjà le cas? (vraie question…)
[^] # Re: Choix ?
Posté par Kerro . Évalué à 3.
Il y a (avait ?) d'autres distributions qui étaient bien plus promptes à publier les nouvelles versions.
Et d'autres ajoutes quelques modifications.
Comme CentOS était (comme les autres) obligée de réinventer le processus de construction de la distribution à chaque fois, prendre CentOS ou pas ne permettait pas d'avoir du 100% Red Hat.
Avec ce partenariat, j'imagine que CentOS va avoir accès facilement à la possibilité de produire les nouvelles versions en même temps que Red Hat. Et peut-être avoir des versions plus récentes.
[^] # Re: Choix ?
Posté par Arkem . Évalué à 4.
En quoi consiste le fait de réinventer le processus de construction de la distribution? La recompilation des paquets sources est-elle si compliquée sous Red-Hat? Y a t-il une différence avec les distributions basées sur Debian? (ce n'est pas un lâcher de Troll, mais un vraie question ici aussi)
[^] # Re: Choix ?
Posté par Joris Dedieu (site web personnel) . Évalué à 6. Dernière modification le 09 janvier 2014 à 12:44.
Pour prendre un exemple simple, si tu compiles subversion sur un système ayant un support de kerberos, le script de construction (./configure) va détecter sa présence et ajouter automatiquement le support de kerberos à svn. Même si tu n'as rien de tel dans ton SPEC, tu peux donc avoir des dépendances qui se sont crées simplement au build. Dans cet exemple c'est relativement trivial mais cela peut être beaucoup plus subtil. Tu peux par exemple avoir des différences simplement lié à l'ordre de build quand tu bootstrape ta distro.
Or, si tu vises la compatibilité binaire, il ne s'agit pas simplement d'éviter ce type de phénomènes mais de reproduire exactement ce qui s'est passé chez RedHAT. Centos doit donc imaginer comment RedHat construit sa distribution et vérifier qu'aucune différence n'a été induite par le processus de build.
[^] # Re: Choix ?
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 2.
C’est pour éviter (ou du moins minimiser) ce genre d’aléas que l’on construit en principe les binaires dans un environnement étanche (tinderbox, jails, etc.).
[^] # Re: Choix ?
Posté par claudex . Évalué à 4.
Ça ne change pas grand chose au problème. Kerboros, il est dans cet environnement étanche ou pas ?
« 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: Choix ?
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 3.
Si c’est une dépendance explicite, même indirecte, oui. Sinon, ça va dépendre du système.
Ceci dit, c’est vrai que Kerberos est un cas limite, et que cela s’appliquerait plus à cyrus-sasl.
[^] # Re: Choix ?
Posté par gemegik . Évalué à 1.
Je ne connais pas le système de build de CentOS, mais celui de Debian traite ce problème : les paquets sont construits dans un chroot où ne sont installés que :
- le méta-paquet build-essential (make, gcc et leurs amis),
- les paquets listés dans la propriété build-depends du paquet à construire.
Ainsi, le build est 100% reproductible d'une machine à l'autre, modulo l'arch et le noyau.
[^] # Re: Choix ?
Posté par GeneralZod . Évalué à 2.
C'est exactement le même principe pour Fedora et Enterprise Linux (RHEL & clones), on utilise Mock qui est un chroot avec un système minimal et les dépendances récupérés via yum.
[^] # Re: Choix ?
Posté par Misc (site web personnel) . Évalué à 3.
Je pense que le souci dans le cas de Centos, c'est l'ordre du rebuild, et les soucis de bootstrapping.
Par exemple, tu as des dépendances circulaires parfois, donc il faut noter ce que t doit retire, puis remettre ça, etc. C'est pas mortel, mais c'est laborieux.
[^] # Re: Choix ?
Posté par benoar . Évalué à 3.
Ce que Debian essaye (essayait ? je ne connais pas l'état d'avancement exact) de résoudre avec les “build profiles”, cf. https://wiki.debian.org/DebianBootstrap
[^] # Re: Choix ?
Posté par Misc (site web personnel) . Évalué à 4.
Ce qui est aussi en cours de test :
https://blog.torproject.org/category/tags/deterministic-builds
https://wiki.debian.org/ReproducibleBuilds
https://securityblog.redhat.com/2013/09/18/reproducible-builds-for-fedora/
[^] # Re: Choix ?
Posté par Xaapyks . Évalué à 3. Dernière modification le 04 février 2014 à 12:34.
Ça veut dire que sur RHEL on a accès aux paquets binaires, mais pas aux scripts qui ont servis à les créer ?
On ne peut donc pas par exemple ajouter un patch ou un switch de configure et le reconstruire ?
[^] # Re: Choix ?
Posté par ManuxFr (site web personnel) . Évalué à 8.
CentOS est 100% binaire compatible avec RHEL, en d'autres termes : bah c'est pareil ;)
La différence réside principalement dans le support :
- Communautaire pour CentOS ;
- Payant sous forme de souscription pour le chapeau rouge.
[^] # Re: Choix ?
Posté par Kerro . Évalué à 3.
Ça répond en quoi à la question ?
Pourquoi CentOS plutôt qu'une autre 100% compatible ?
[^] # Re: Choix ?
Posté par claudex . Évalué à 8.
Il me semble que les autres ne garantissent pas la comptabilité binaire, ça ne veut pas dire qu'elles ne sont pas compatible mais CentOS fait le boulot de vérifier que c'est bien le cas.
« 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: Choix ?
Posté par GeneralZod . Évalué à 7.
L'objectif de Red Hat dans cette initiative, c'est d'accroitre et de renforcer la notoriété d'Enterprise Linux (RHEL & clones).
CentOS est le projet avec la plus grosse communauté et qui a fait un travail incroyable pour apporter de la valeur ajoutée (virtualisation, cloud, paquets supplémentaires), et communautaire (les CentOS Dojo).
Les autres clones de RHEL se divisent en deux catégories principalement:
* distro scientifique: Scientific Linux, Fermi Linux (marché de niches et peu ouvertes à l'extérieur)
* Oracle Linux (des concurrents directs pas très fair play qui plus est)
C'était le choix le plus logique.
[^] # Re: Choix ?
Posté par Misc (site web personnel) . Évalué à 2.
Et scientific linux, je crois que c'était 2 personnes ( dont une qui bosse maintenant sur openshift chez RH )
[^] # Re: Choix ?
Posté par sylvainf_ . Évalué à 2.
Scientific linux est un clone soutenu par le CERN qui l'utilise massivement dans son infrastructure. De mémoire il ont effectivement une toute petite équipe qui s'en occupe, mais c'est à mon avis un gage de qualité de voir qu'une grosse organisation soutient le projet. Dans les fais SL sortait les nouvelles versions et les patchs généralement plus rapidement que CentOS, et c'est pourquoi, au moins dans la communauté enseignement recherche, beaucoup ont switché de CentOS vers SL.
Contrairement à ce que son nom indique c'est d'ailleurs bien un clone tout aussi généraliste que l'original.
Concernant la décision de RedHat, je dois dire que c'est surprenant. La dernière fois que j'ai croisé des commerciaux de RH ils critiquaient ouvertement les clones, parfois avec un peu de mauvaise fois :)
[^] # Re: Choix ?
Posté par Zenitram (site web personnel) . Évalué à 0.
Donc dans des domaines où un plantage serveur ne fait pas perdre d'argent directement…
Les commerciaux ont une vue court terme basée sur leur ventes annuelles (bref, de l'individuel).
La boite, le management, a une vue long terme basée sur le gain qu'il retireront de leurs actions en bourse dans 5 ans ou plus (en théorie, des fois ils pensent court terme aussi quitte à tuer la boite! Mais la on parle d'une boite qui vit depuis longtemps)
D'où une différence de réaction :).
[^] # Le rôle de Scientific Linux
Posté par fabrices . Évalué à 6.
Scientific Linux est soutenu par l’institue de recherche Fermi Lab à Chicago qui est dédié à la recherche en physique des particules. L'institut emploi au moins deux personnes à pleins temps qui ne partent jamais en congé en même temps. Cela explique pourquoi SL6 est sorti bien avant Centos6.
SL est utilisé en autre sur les grilles de calcul du LHC et pour l’infrastructure informatique du LHC au CERN. Une expérience comme le LHC est incroyablement complexe et requiert une infrastructure informatique conséquente qui fonctionne 24h/24h. Bien que je ne connaisse pas les moyens des grandes entreprises en Europe, il est fort probable que la grille LHC soit dans le top 10 des infrastructure informatiques (hors supercalculateurs). Jadis le CERN et DESY ont même accueillie des pièces uniques d'IBM en Europe et des silos STK. De plus le coût de construction et de fonctionnement d'un accélérateur de particule est telle que seul une collaboration mondiale peut en assurer le financement. La France et son industrie est d'ailleurs bien contente que le CERN soit en majorité sous son sol.
Alors même si un incident est moins grave que dans le secteur bancaire, les administrateurs systèmes ont quand même une lourde responsabilité sur le dos.
Du point de vue différence entre RHEL et SL, le mécanisme de souscription RHN (et le coût) ne facilite pas la gestion d'un parc de centaines de machines. RHEL est une évidence pour une salle de marché, SL l'est pour la grille LHC.
Personnellement j'utilise SL au sein d'une petite PME pour ces deux raisons: support garantie sur les mises à jour et pas de souscription RHN, trop chère et trop contraignant.
[^] # Re: Choix ?
Posté par GeneralZod . Évalué à 3.
Pour parler au débotté avec les commerciaux de Red Hat, certains n'hésitent pas à utiliser CentOS comme variable d'ajustement des coûts. Après tout, c'est un bon argument commercial, mais faut pas s'attendre à ce qu'ils te sortent ça dès le départ ;)
[^] # Re: Choix ?
Posté par Misc (site web personnel) . Évalué à 3.
Le CERN fait sa propre variante de SL. Et je pense que SL est aussi utilisé parce qu'ils offrent openafs, qui est sous une license juridiquement incompatible avec la GPL, et la raison de son absence chez Fedora.
De ce que j'ai aussi compris d'une discussion avec un ancien dev de Scientific Linux, SL est aussi différente dans la philosophie. Par exemple, les ugrades sont fait de façon automatique car ils se sont rendus compte que les clusters sont installés par des étudiants sans grand expérience en sysadmin, et qu'il faut donc ne pas compter sur le fait de faire l'upgrade à la main, ce genre de choses.
L'idée d'avoir des upgrades auto risque de faire grincer des dents les entreprises avec un staff plus qualifié, qui doit suivre des procédures, etc, etc.
[^] # Re: Choix ?
Posté par Misc (site web personnel) . Évalué à 2.
je suis pas sur du 100% binary compatible.
[^] # Re: Choix ?
Posté par claudex . Évalué à 3.
J'avais aussi en tête le 100% binary compatible, mais le projet parle de
Sachant que pour être fonctionnellement compatible (c'est-à-dire faire tourner les même logiciel), il vaut mieux être binairement compatible, je ne sais pas ce qu'il faut en penser.
« 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: Choix ?
Posté par Misc (site web personnel) . Évalué à 4.
binairement compatible, ça implique de recompiler dans le même ordre tout, et c'est AMHA non documenté et fait de façon organique. Donc il y a déjà des divergences à la base.
Et sinon, il y a ça :
http://crunchtools.com/centos-post-mortem-analysis/
[^] # Re: Choix ?
Posté par claudex . Évalué à 4.
Il me semblait que c'était pour ça qu'ils prenaient plus de temps que les autres pour sortir leur version. Après, il peut bien sûr avoir des cas où ça n'a pas marché.
« 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: Choix ?
Posté par WhiteCat . Évalué à 4.
On remarque d'ailleurs étonnamment dans le communiqué de presse de Red Hat qu'ils insistent à mort sur le fait que RHEL et CentOS sont clairement "différentes".
[^] # Re: Choix ?
Posté par ManuxFr (site web personnel) . Évalué à 1.
Oui elles sont clairement "différentes", mais pas au niveau technique (enfin à mon avis).
En effet, elles ne ciblent pas le même public.
La "grosse" boite qui installe un soft qui lui "impose" une RHEL pour conserver le support toussa.
La société Red-Hat gagne de l'argent (beaucoup même il parait) sur les "services", ils veulent donc bien préciser que d'un côté vous avez un clone "brut" d'une RHEL et de l'autre tout l'écosystème Red-Hat.
[^] # Re: Choix ?
Posté par WhiteCat . Évalué à 7.
Bah c'était déjà le cas avant. Si on voulait un quasi-clone de RHEL c'était soit CentOS soit Scientific Linux.
# attitude vis-à-vis des clônes...
Posté par Maclag . Évalué à 10.
J'ai du rater un épisode. Au dernier que j'ai, RedHat avait décidé de diffuser ses patches en un seul gros foutoir au lieu de les avoir séparés proprement, et il était quasiment admis que le but de la manœuvre était de pourrir la vie des clones qui feraient de la concurrence "déloyale".
Je ne suis pas convaincu que ce soit vraiment un changement, mais une adaptation intelligente:
Les gens qui installent un clone le font le plus souvent faute de budget alloué à la licence, ce ne sont pas des clients perdus mais simplement pas des clients tout court.
Si les clones disparaissent, ces non-clients vont probablement installer autre chose. Et comme Bill Gates le disait si bien: mieux voir vaut un Windows piraté qu'un autre système! Ici, mieux voir un clone de RedHat qu'une Suse ou Debian, par exemple.
Du coup RedHat s'assure qu'au moins un de ces clones offre désormais une distribution plus ou moins avalisée par RedHat. Ça n'en rendra le projet que plus pérenne, et confortera la base de "non-clients" (voire étendra?).
Toujours est-il que je prend ça comme une bonne nouvelle pour les utilisateurs de RedHat (qui peuvent utiliser le clone chez eux hors boulot s'ils le souhaitent) et de CentOS.
[^] # Re: attitude vis-à-vis des clônes...
Posté par manifesto . Évalué à 5.
le gros machin de livraison des patches etait pour géner le vrai concurrent de redhat qui est la truc de Oracle (unbreakable ;-)) .
D'ailleurs je crois que la tentative d'Oracle de supplanter RH n a pas trop de succès (qui s'en plaindra !).
[^] # Re: attitude vis-à-vis des clônes...
Posté par WhiteCat . Évalué à 4.
Pas moi ! J'ai testé une fois le fameux Unbreakable kernel (pour faire de la virtualisation KVM), et ben j'ai regretté et je suis revenu à CentOS.
[^] # Re: attitude vis-à-vis des clônes...
Posté par claudex . Évalué à 10.
Ce n'était pas contre les clones (même si ça les affectait tous), c'était contre Oracle qui fait du support moins cher que Red Hat pour sa distribution qui est un clone de RHEL. Il me semble que CentOS a toujours été bien vu par Red Hat mais a fait les frais de la politique d'Oracle.
« 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
# Fedora LTS
Posté par Sébastien Wilmet . Évalué à -1.
CentOS est donc en quelque sorte une Fedora LTS (long term support).
[^] # Re: Fedora LTS
Posté par Adminrezo (site web personnel) . Évalué à -1.
Je n'y comprend pas grand chose.
RedHat qui sponsorise déjà Fedora va maintenant sponsoriser CentOS.
A quoi ça sert ?
Ce serait pas plus simple de rassembler tous ses efforts dans une seule distribution avec différentes versions (stable/récente, serveur/poste de travail) façon Ubuntu.
[^] # Re: Fedora LTS
Posté par claudex . Évalué à 7.
Fedora et RHEL, ce n'est pas la même distribution (même si la deuxième est basée sur la première), il y a des paquets en plus et en moins dans RHEL, les versions sont différentes (RHEL 7 est basé sur Fedora 17 mais a un systemd plus récent par exemple). Il y a des contributeurs non Red Hat dans Fedora avec un pouvoir de décision…
CentOS et Red Hat, ce n'est pas la même chose non plus, et rien que pour simplifier la vie, Red Hat n'a pas intérêt à appeler sa version gratuite RHEL, sinon bonjour le support. Sans compter que CentOS, c'est aussi un projet à part avec des dépôts en plus, qui ne sont pas pris en charge par Red Hat.
« 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: Fedora LTS
Posté par Xavier . Évalué à 2.
Hello,
RHEL7 est basée sur Fedora 19: http://www.redhat.com/about/news/archive/2013/12/red-hat-announces-availability-of-red-hat-enterprise-linux-7-beta
Bonne journée.
[^] # Re: Fedora LTS
Posté par djano . Évalué à -1.
Oui, mais RHEL est une version "hardened" de Fedora, avec une QA plus poussee (plus de moyens?) et puis surtout un long support (payant bien sur, mais c'est le jeu ma pauvre Lucette!)
[^] # Re: Fedora LTS
Posté par Misc (site web personnel) . Évalué à 4.
Les distributions n'ont pas les mêmes communautés. Fedora est une distribution pour l'innovation au niveau de la distribution même, alors que la, l'idée pour Centos, c'est pour l'innovation au dessus de la distribution ( ie, les plateformes qui s'appuient sur une plateforme stable qui ne bouge pas trop ).
Tu peux pas tout faire bouger en même temps.
[^] # Re: Fedora LTS
Posté par BuckFuck . Évalué à 5.
Non.
- Fedora : c'est du desktop bleeding edge avec une grosse communauté.
- RHEL : serveur stable avec des clients.
- CentOS : serveur stable avec une grosse communauté.
Pour moi, CentOS permet de concilier communauté et stabilité. C'est ce qui manquait au niveau de la "gamme" Redhat.
[^] # Re: Fedora LTS
Posté par WhiteCat . Évalué à 6.
Ça ne manquait pas du tout. CentOS existe depuis bientôt 10 ans.
Et maintenant que Red Hat soutien officiellement CentOS, c'est un gage de qualité supplémentaire pour tous les utilisateurs CentOS (et RHEL par effet de bord).
[^] # Re: Fedora LTS
Posté par BuckFuck . Évalué à 5. Dernière modification le 08 janvier 2014 à 22:18.
J'ai écrit que cela manquait au niveau de la "gamme" RedHat. Il n'y aucune mention négative vis-à-vis de CentOS dans mes propos. Faut pas lire en diagonale ! ;-)
Sinon, entièrement d'accord pour l'effet de bord qui peut profiter à tout le monde…
[^] # Re: Fedora LTS
Posté par WhiteCat . Évalué à 2.
Ok je vois ce que tu voulais dire.
[^] # Re: Fedora LTS
Posté par Ermaion (site web personnel) . Évalué à 1.
RHEL ou CentOS sont très bien pour le desktop aussi, même mieux que Debian selon moi. Je comprendrais jamais l'origine de ce mythe qui veut que RHEL/CentOS ne sont adaptés qu'aux environnements serveurs.
[^] # Re: Fedora LTS
Posté par djano . Évalué à 3.
Peut etre parce que Red Hat fait ses gros sous sur les serveurs ?
[^] # Re: Fedora LTS
Posté par fabrices . Évalué à 6.
Ces trois distributions ont un rôle bien précis:
Une des caractéristiques de RHEL est son nombre limité de paquets et parfois ancien: c'est par pragmatisme, on ne peut pas garantir le bon fonctionnement de 50000 paquets. Fedora, Debian/Ubuntu ferment les yeux sur cette réalité. RHEL se doit d'être 100% fonctionnel.
Je trouve ce nouveau positionnement assez logique.
[^] # Re: Fedora LTS
Posté par BuckFuck . Évalué à 5. Dernière modification le 08 janvier 2014 à 21:20.
Je vais essayer de répondre par rapport à ce que j'ai pu comprendre (je suis Gentooiste au niveau domestique et Debianeux au niveau professionnel donc je suis loin de la galaxie Red Hat). Donc :
- Fedora : distribution communautaire servant de laboratoire. Ce qui fonctionne est par la suite implémenté dans RHEL. Pas le meme usage que RHEL ou CentOS (Desktop vs Server).
- RHEL : coeur de métier de RedHat. Distributions "very LTS". Licences pas données. Pierre angulaire de diverses certifications.
- CentOS : clone parfait de RHEL. Pas de licence payante et support seulement communautaire. Vient d'être adoubé par Redhat comme clone officiel.
En gros, stratégie intelligente. Tu veux un truc stable et vraiment LTS, tu prends du CentOS. Le jour où as vraiment besoin d'un support avancé, tu bascules sur du RHEL (en fait, tu ne bascules pas, tu changes juste le logo).
Personnellement, je bosse dans une structure avec des moyens plus que suffisants. Par goût et philosophie, mes serveurs sont sous Debian Squeeze. Je dois les migrer et j'hésitais entre la Wheezy (affectif) et la future Ubuntu 14.04 LTS (pragmatisme dû au LTS). J'avais commencé à réfléchir à du CentOS parce que Debian m'enquiquine sur certains aspects (manque de finition sur certains points, inconcevable en environnement professionnel - on s'en sort mais en bidouillant. Mon boulot n'est pas de bidouiller mais de faire avancer les projets.) et aussi que le cycle de vie de des distros Debian est relativement court, plus que Ubuntu LTS et à 1000 lieues de RedHat (et CentOS). Le fait que CentOS soit reconnu "officiellement" constitue un plus. Sur du tout-venant, tu restes sur CentOS, tu as les compétences pour. Et pour un truc plus spécifique, moyennant une licence RHEL, tu bénéficies d'un support avancé. Sans compter que (et ca me chagrine), Redhat fait un peu la pluie et le beau temps au niveau du microcosme des distributions Linux (aka systemd).
C'est en tout cas ce que j'ai compris. M'en vais de ce pas essayer la v7 beta de RedHat. ;-)
[^] # Re: Fedora LTS
Posté par Sufflope (site web personnel) . Évalué à 9.
Si j'avais cru lire ça un jour… (je dis pas que tu as tort attention)
[^] # Re: Fedora LTS
Posté par BuckFuck . Évalué à 2.
Rassure-toi, je n'avais jamais pensé l'écrire un jour non plus (Sarge -> Etch = 5 ans). Mais franchement, 2 ans entre la Squeeze et la Wheezy, ça fait un peu court en environnement "serveurs"…
[^] # Re: Fedora LTS
Posté par claudex . Évalué à 3.
Ça fait quand même 3 ans de support (même si ça reste court).
« 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: Fedora LTS
Posté par jolitorax . Évalué à 1.
Pour des projets à court terme, Debian est l'idéal. D'autant que la mise à jour d'une stable vers l'autre est relativement facile.
Nous utilisons les deux environnements, suivant les envies et le type de projet. Debian stable d'un coté et RedHat, Centos, Scientific Linux pour le support plus long terme. A noter que le support 10 ans est "relativement" récent chez RedHat.
[^] # Re: Fedora LTS
Posté par Misc (site web personnel) . Évalué à 2.
Sarge est sorti en juin 2005, etch en avril 2007. Dans mon souvenir, la durée de vie, c'est temps entre release + 1 an. Donc c'est woody qui a été supporté 4 ans ( 3 ans de dev + 1 an ).
Je sais pas d'ou tu sors tes 5 ans :/
[^] # Re: Fedora LTS
Posté par M.Poil (site web personnel) . Évalué à 4. Dernière modification le 09 janvier 2014 à 08:10.
Pour le choix de l'OS je ne peux que conseiller le blog de
Benjamin Schweizer avec son joli calendrier du cycle de vie des OS, c'est ce qui nous avait décidé à prendre de l'Ubuntu LTS plutôt que du Debian.
Is it a Bird? Is it a Plane?? No, it's Super Poil !!!
[^] # Re: Fedora LTS
Posté par Zenitram (site web personnel) . Évalué à 9. Dernière modification le 09 janvier 2014 à 08:19.
A mon avis, on ne parle pas de la même chose. Le gros problème avec Debian en pro est que tu as 1 an pour migrer tous (y compris celui que tu as installé la veille) tes serveurs Debian le jour où une release sort. Et ça depuis le debut de Debian.
Et 1 an, c'est très très court et pas du tout synchronisable avec des nouvelles versions des applications que tu mets dessus. Bref, c'est de la bidouille et des prières au final alors que CentOS, tu changes quand tu changes l'appli ou la machine (coût plus faible car moins de tests de non regression à faire sur une machine que tu dois payer en plus car on ne fait pas les tests sur la prod', et tu as dans les 8 ans pour migrer). Après certes si tu fais des upgrades sur la même machine unique juste en priant que ça marche, ça marche dans 99% des cas (une bête appli web dessus) certes.
[^] # Re: Fedora LTS
Posté par MTux . Évalué à 4.
Le deuxième effet kisscool c'est que quand ton serveur est lancé en prod, parfois la version est déjà obsolète (si le projet a débuté en milieu ou fin de vie de la distribution).
[^] # Re: Fedora LTS
Posté par GeneralZod . Évalué à 3.
Actuellement, depuis que les Softwares Collections (SCL) sont dispos c'est de moins en moins vrais.
Et il est probable qu'avec Docker, on verra de nouveaux patterns.
[^] # Re: Fedora LTS
Posté par NilugeKiWi . Évalué à 1.
On est apparemment encore loin d'une solution raisonnable pour les Software Collections.
Ayant assisté à kla présentation des Software Collections au FOSDEM 2014, si j'ai bien compris toute la problématique de factorisation des dépendances et de gestion des updates de sécurité facilitées qui en découle vient seulement d'être soulevée suite à l'usage de la première version des SC livrés par redhat; aucune solution n'est arrêtée, et il n'y a pas de choix évident…
Pour l'instant les Software Collections c'est un peu ce qui est fait en packaging proprio sous windows: "on livre toutes les dépendances avec le soft, et ça marche; pour les updates de sécurité, on relivre tout à chaque fois (ou pas… en fonction du mainteneur)".
Cela dit, la piste est clairement intéressante: la problématique est là, partout, et a besoin d'être résolue une bonne fois pour toutes.
[^] # Re: Fedora LTS
Posté par Xavier Poinsard . Évalué à 1.
La grosse différence c'est que Debian supporte la montée de version.
Redhat/Centos déconseille les montées de version majeures et recommandent la réinstallation.
# c'est donc plié
Posté par coucou78 . Évalué à -10.
Ouaih ca y'est centos va être asphyxié par red hat.
Debian pouahhhhhhh
[^] # Re: c'est donc plié
Posté par MTux . Évalué à 9.
OUI, tout comme RedHat a tué Fedora…
Oh wait.
# Quelle nouvelle surprenante !
Posté par Prolixman . Évalué à 2. Dernière modification le 09 janvier 2014 à 16:30.
Je confirme que Red Hat est un champion du support jusqu'à 10 ans en cycle de vie étendu pour ces distributions (7 ans en standard).
Red Hat n'a pas du tout tué Fedora, fedora est plus vivant que jamais, voir fedora 20, je suis en fedora 20 interface GNOME et l'un de mes parents également avec l'interface pour Xorg -> Mate ;)
Au travail : RHEL4/RHEL5/RHEL6 et CentOS6.
La stratégie est intelligente, mon point de vue sur le choix des distributions du monde Red Hat et sa communauté :
Fedora, je le recommande surtout pour le "Desktop", les applications sont plus récentes et le cycle de vie très court.
RHEL : orienté/connu pour sa version pour serveur entreprise (voir il existe des versions desktop), entité où le support est important. Applications matures - cycle de vie lent (3 distri de fedora à la sortie d'une nouvelle environ mais avec des backportages noyau (pilotes etc…)) ce qui permet de bien vivre cette longue vie. Pour le web, Red Hat s'est ouvert, il propose par défaut un php par exemple mais en option un autre ainsi on a le choix depuis la fin de la RHEL5 et ça continue sur la RHEL6.
CentOS : idem mais serveur - applications matures - identique à RHEL mais sans support Red Hat. On enlève la marque RHEL et c'est identique à 96% - 16 paquets réellement modifié dont 3 avec des noms différents) (il a quelques modifications, en plus de la partie RHN à remplacer par un spacewalk par exemple), mais 100% compatible avec la RHEL : un vrai clone. De plus, il y a des canaux qui n'existe pas sur la Red Hat ex : CentOSPlus. En terme de canaux, je privilégie les équivalent Red Hat, et si il n'y a pas ce que je veux, EPEL pour qu'une installation puisse se faire autant sur RHEL6 que CentOS6.
Conclusion :
que vont ils faire ? les possibilités sont nombreuses, CentOS et Red Hat ont beaucoup à y gagner ! le plus important c'est ce que GNU/Linux généralement va y gagner !
CentOS était déjà le vrai clone de la RHEL depuis longtemps, les autres sont plus récent.
Donc c'est normal qu'il le reconnaisse, mais Red Hat pouvait également fournir leurs binaires gratuitement mais sans offrir de support. Il avait le choix… mais l'avenir nous dira pourquoi… Aujourd'hui, les installations se font de la même façon en toutes transparences sur RHEL et CentOS.
Après il y a plus de correctifs, bug non présent sur la Rhel tel qu'effet de bord résiduel. Il y a un peu plus de 10000 paquets sur les canaux natif provenant de la RHEL.
[^] # Re: Quelle nouvelle surprenante !
Posté par Jérôme F. . Évalué à 3.
13 ans : 10 ans en standard, plus 3 ans optionnels avec l'abonnement ELS. Cf. https://access.redhat.com/support/policy/updates/errata/
Pas tout à fait : si les paquets ont comme tu le soulignes à 96% les mêmes sources, la compilation se fait selon des processus totalement différents.
Une manière industrielle côté Red Hat Enterprise Linux, avec un suivi précis de tout ce qui s'y passe, une recompilation au fil de l'eau (voire nombreuse jusqu'à ce que ça marche) côté CentOS.
Donc une visée de 100% de compatibilité binaire, dans les faits un peu moins, du fait des conditions de compilation. Souvent ça passe, des fois ça passe pas…
Parce que justement les binaires de Red Hat Enteprise Linux sont différents de ceux de CentOS, et apportent une valeur beaucoup plus importante :
- certifications matérielles,
- certifications logicielles,
- assurance qualité industrielle,
- émission de correctifs recompilés dans les mêmes conditions que le paquet original.
CentOS n'apporte rien de tout ça, mais en contre-partie est accessible à la communauté.
Encore une fois, CentOS va avoir pour vocation de fournir un socle stable pour les développements d'applications (oVirt, OpenStack, OpenShift Origin, etc.) au delà du système d'exploitation, alors que Fedora était un sable beaucoup trop mouvant pour ça, avec un cycle de vie beaucoup trop rapide pour ces projets.
Et pour enfoncer le clou, Red Hat n'offrira pas de support sur CentOS, dont Red Hat ne maîtrise ni ne maîtrisera les conditions de compilation. La séparation actuelle entre l'entreprise Red Hat et le projet CentOS restera.
# Good news...
Posté par loste . Évalué à 2.
N'appréciant pas les évolutions récentes (post 2010, disons) d'Ubuntu, j'étais un peu orphelin à la fin du support de leur dernière LTS utilisée (10.04). Passé à Debian (wheezy) en version XFCE, disons que de base j'ai un peu l'impression de revenir 10 ans en arrière par rapport aux dernières gnome 2 (gnome shell chez moi, même pas en rêve) niveau bureau et que pour ce qui est MAJ de l'applicatif de base, c'est quand même lent: CentOS 6.5, je viens d'an installer au bureau comme machine labo et bien que basé sur un 2.6.32 (donc idem ubuntu 10.04, loin derrière le 3.2 Debian stable) propose une suite bureautique à jour (libre office 4.x) et mozilla (mail/web) en version ESR.
Certes, on n'a pas la variété de soft dispo d'un apt-get install côté Debian… et un yum bien moins confortable à l'usage (devoir se fader des yum search car y'a toujours pas l'autocompletion sur l'install, contrairement à apt, c'est quand même bien casse-c… à l'usage en 2014). Coller le support proprio d'une carte nvidia (même si nouveau a bien progressé) oblige aussi à se retrousser un peu plus les manches que chez ubuntu, mais c'est une seule fois et pour un paquet d'années.
Car au final, niveau durée de support et MAJ des release intermédiaires, ca aide à supporter les moins! En prime ils ont visiblement su ramener Gnome à la raison avec le classic mode: Pas demain la veille que j'éprouve l'envie de patouiller un écran de PC alors les environnements graphiques adaptés au tactile non merci.
Si RH revoit l'installeur (qui pose encore pb en collant l'iso sur clef USB, avec toutes ces machines qui sortent sans lecteur et ces utilisateurs qui ont perdu l'habitude de graver des galettes on ne peut pas dire que cela attire le chaland) et automatise l'installation des drivers proprio, ils ont une sérieuse carte à jouer y compris chez les particuliers et avec l'ouverture possible sur des partenariats avec les fabricants, qu'ils ont déjà sur le marché pro.
Celle qu'Ubuntu est en train de gâcher avec Unity, son store… en fait.
[^] # Re: Good news...
Posté par xcomcmdr . Évalué à 2. Dernière modification le 10 janvier 2014 à 15:25.
Et pourquoi pas Xubuntu 12.04 (LTS pour 3 ans), ou Xubuntu 14.04 (LTS de 3 ans) ?
Tu auras un Xfce récent (*), des logiciels et un kernel linux récent, une logithèque importante, des PPA en cas de besoin, un Xfce modernisé (notamment un support natif de pulseaudio). Aussi, un thème graphique élégant (Greybird, thème d'icônes elementary-xfce), un très bon DM (lightdm), une communauté importante, etc…
(*) Xfce 4.8 sur la 12.04, avec un PPA fait par l'équipe Xubuntu pour la 4.10, et un autre pour la 4.12 (toujours en développement)
Xfce 4.10 sur la 14.04.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Good news...
Posté par Misc (site web personnel) . Évalué à 2.
je pense que c'est le cas pour RHEL 7. Pour RHEL 6, ç'est il semble faisable, mais j'ai jamais réussi.
ça, je pense que tu peux oublier. Les drivers proprios, c'est juste pas maintenable.
Les partenariats, tout le monde a tenté. Par exemple pour le dernier cas avec RH :
http://www.pcworld.idg.com.au/article/431533/dell_offers_new_laptops_red_hat_enterprise_linux/
Mandriva l'a fait, suse l'a fait, linspire, etc. Et chaque fois, ça ne semble ne pas décoller, et mon corrolaire, c'est que ça ne rapporte pas assez, parce que le marché des pcs pour particulier est un marché ou les marges sont minimes. Donc soit tu vends des tonnes de machines, soit tu fait ça à perte en gagnant ailleurs. Ça marche peut être pour Google, mais pas pour les autres distributeurs linux.
Donc tout le monde vise le monde pro, comme par exemple Canonical qui communique sur le fait qu'ils ont Google et Qualcomm comme client ( http://insights.ubuntu.com/news/ubuntu-12-04-to-feature-extended-support-period-for-desktop-users/ ), RH qui a Pixar ( http://www.muktware.com/2013/04/pixar-animation-studios-uses-red-hat-enterprise-linux/4271 ), etc.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.