CentOS et Red Hat unissent leurs forces pour une plateforme communautaire stable

Posté par . Édité par Nils Ratusznik, Jérôme F., Nÿco et olivierweb. Modéré par Xavier Teyssier. Licence CC by-sa
53
8
jan.
2014
Red Hat

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.

  • # Bonne nouvelle (enfin je pense)

    Posté par (page perso) . É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 :)

  • # Choix ?

    Posté par (page perso) . É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 . Évalué à 10.

      C'était pas déjà le cas? (vraie question…)

      • [^] # Re: Choix ?

        Posté par (page perso) . É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 . É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 (page perso) . Évalué à 6. Dernière modification le 09/01/14 à 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 (page perso) . Évalué à 2.

              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.

              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 (page perso) . É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 (page perso) . É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 . É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 . Évalué à 3. Dernière modification le 04/02/14 à 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 (page perso) . É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 (page perso) . Évalué à 3.

        Ça répond en quoi à la question ?
        Pourquoi CentOS plutôt qu'une autre 100% compatible ?

        • [^] # Re: Choix ?

          Posté par (page perso) . É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 . É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 (page perso) . É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 . É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 (page perso) . Évalué à 0.

                  au moins dans la communauté enseignement recherche

                  Donc dans des domaines où un plantage serveur ne fait pas perdre d'argent directement…

                  La dernière fois que j'ai croisé des commerciaux de RH ils critiquaient ouvertement les clones, parfois avec un peu de mauvaise fois :)

                  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 . É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 . É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 (page perso) . É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 (page perso) . Évalué à 2.

        je suis pas sur du 100% binary compatible.

        • [^] # Re: Choix ?

          Posté par (page perso) . Évalué à 3.

          J'avais aussi en tête le 100% binary compatible, mais le projet parle de

          CentOS Linux aims to be functionally compatible with RHEL

          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 (page perso) . É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 (page perso) . É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 . Évalué à 4.

        CentOS est 100% binaire compatible avec RHEL, en d'autres termes : bah c'est pareil ;)

        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 (page perso) . É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 . Évalué à 7.

      cela veut dire en gros que si on veut un quasi-clône de RHEL il est désormais mieux de choisir CentOS ?

      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 . Évalué à 10.

    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.

    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 . É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 . Évalué à 4.

        (qui s'en plaindra !)

        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 (page perso) . Évalué à 10.

      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".

      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 (page perso) . Évalué à -1.

    CentOS est donc en quelque sorte une Fedora LTS (long term support).

    « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

    • [^] # Re: Fedora LTS

      Posté par (page perso) . É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.

      Il avait aussi le plus grand respect de l'humour parce que c'était une des meilleures armes que l'homme eût jamais forgées pour lutter contre lui-même.

      • [^] # Re: Fedora LTS

        Posté par (page perso) . É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 (page perso) . É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 . É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 . É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 . Évalué à 5. Dernière modification le 08/01/14 à 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 (page perso) . É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 . Évalué à 3.

            Peut etre parce que Red Hat fait ses gros sous sur les serveurs ?

      • [^] # Re: Fedora LTS

        Posté par . Évalué à 6.

        Ces trois distributions ont un rôle bien précis:

        • Fedora sert de plateforme de R&D pour Linux/RHEL et convient en même temps pour le marché de niche du desktop
        • RHEL vise les applications critiques où le support et la stabilité est primordiale: salle de marché, etc.
        • les clones sont utiles aux gens qui veulent la stabilité de RHEL et qui peuvent se passer du support, en partie pour des raisons financières. Ou qui ne veulent pas s'emmerder à gérer des tokens RHN.

        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 . Évalué à 5. Dernière modification le 08/01/14 à 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 (page perso) . Évalué à 9.

        le cycle de vie de des distros Debian est relativement court

        Si j'avais cru lire ça un jour… (je dis pas que tu as tort attention)

        • [^] # Re: Fedora LTS

          Posté par . É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 (page perso) . Évalué à 3.

            Mais franchement, 2 ans entre la Squeeze et la Wheezy, ça fait un peu court en environnement

            Ç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 . É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 (page perso) . É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 (page perso) . Évalué à 4. Dernière modification le 09/01/14 à 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 (page perso) . Évalué à 9. Dernière modification le 09/01/14 à 08:19.

          Si j'avais cru lire ça un jour… (je dis pas que tu as tort attention)

          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 . É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 . É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 . É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 . É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 . Évalué à -10.

    Ouaih ca y'est centos va être asphyxié par red hat.

    Debian pouahhhhhhh

  • # Quelle nouvelle surprenante !

    Posté par . Évalué à 2. Dernière modification le 09/01/14 à 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 . Évalué à 3.

      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).

      13 ans : 10 ans en standard, plus 3 ans optionnels avec l'abonnement ELS. Cf. https://access.redhat.com/support/policy/updates/errata/

      CentOS était déjà le vrai clone de la RHEL depuis longtemps, les autres sont plus récent.

      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…

      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.

      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 . É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 . Évalué à 2. Dernière modification le 10/01/14 à 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 (page perso) . Évalué à 2.

      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)

      je pense que c'est le cas pour RHEL 7. Pour RHEL 6, ç'est il semble faisable, mais j'ai jamais réussi.

      et automatise l'installation des drivers proprio,

      ça, je pense que tu peux oublier. Les drivers proprios, c'est juste pas maintenable.

      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.

      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 à ceux qui les ont postés. Nous n'en sommes pas responsables.