Journal RHEL 9 beta is out : 1 an après , quid des successeurs ?

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
15
6
nov.
2021

Il y a presque un an que RedHat annonçait que CentOS changeait de modèle de développement en devenant une distribution tyoe "rolling release" servant de modèle à la RHEL.
CentOS Stream 8 recevant régulièrement des updates devenant la base pour RHEL 9.

De fait, il est désormais inconcevable d'utiliser CentOS Stream en production. Ainsi de nombreuses distributions se sont posées comme distribution remplaçante à CentOS peu de temps après cette annonce.
Liste non exhaustive:
Scientific Linux, Oracle Linux , Rocky Linux, Alma Linux , VZ

1 an après, où en sommes nous ?
Certes, je n'ai pas particulièrement suivi mais il me semble que

A - 2 distributions semblent s'être détachées . Ce sont Alma et Rocky.

B Alma est la version non commerciale de Cloudlinux , Inc
Rocky Linux est purement communautaire lancé par le fondateur de CentOS

C- Les deux distributions sont désormais utilisable en production (mars pour Alma et Juin pour Rocky)

Elles semblent très semblable, néanmoins la différence se fait sur la sécurité et sur le multi plate forme.

Alma a choisi le support de Secureboot et une migration depuis RHEL/CentOS ou Oracle 8 (assez difficilement )

Rocky ne supporte ni secureboot ni la migration mais supporte par contre l'architecture aarch64

À partir des différences, est ce que Alma sera plus installé dans les datacenter pour être plutôt applicatifs ?
Est ce que Rocky linux sera plutôt destiné aux développeurs , étudiants ou passionnés qui se verront ainsi une belle façon d'appréhender et de découvrir l’environnement RedHat sur leurs raspberry pi

Je ne sais pas, j'ai vérifié les deux sur un environnement x86_64 sans secureboot et les deux me semblent très similaires.

Chez les éditeurs, le replacement des matrices de support des systèmes d'exploitations n'est pas encore mis à jour ,mais des informations que j'ai pu reccueuilir ( à vrai dire, personne ne s'est vraiment posé la question) il y aura les éditeurs qui ne supporteront plus que RedHat et les éditeurs qui supporteront tous les clones.
Pensez vous que les clones non Alma, non Rocky, auront une chance d'être un peu plus déployé ?

Et vous , avez vous pu faire votre choix pour vos futures mises à jours ? Pensez vs à changer totalement de distributions (vers debian) voir système (BSD) ?

  • # Fermilab & CERN, scientific linux

    Posté par  (Mastodon) . Évalué à 10. Dernière modification le 06 novembre 2021 à 20:06.

    L'avis du CERN & du Fermilab est intéressant me semble t il :

    https://listserv.fnal.gov/scripts/wa.exe?A2=SCIENTIFIC-LINUX-USERS;4c8eeca4.2110

    Traduction (approximative) :

    Le CERN et le Fermilab ont évalué de près le paysage de la distribution Linux. Nous observons que les organisations nationales de cyberinfrastructure soutiennent de plus en plus de domaines scientifiques. Par conséquent, en plus des considérations spécifiques au LHC ou au HEP, il sera utile d'avoir un choix largement reconnu et répondant aux besoins d'une recherche scientifique plus large.

    Red Hat a fait une proposition au CERN concernant un programme de licence académique. En fin de compte, cela nécessiterait des frais généraux importants sur les sites externes, et nous avons donc des inquiétudes sur l'attractivité de cette proposition pour d'autres sites.

    À l'avenir, nous proposons de cibler CentOS Stream comme distribution standard pour les expériences. Nous pensons que le déploiement de CentOS Stream 8 est à faible risque, et nous avons maintenant des mois d'expérience dans l'exécution de services informatiques et expérimentons des charges de travail hors ligne sur CentOS Stream 8 sans aucun problème majeur. Nous pensons qu'en cas de problème avec l'adoption de CentOS Stream 8, il serait simple de réévaluer d'autres options avant la fin de la prise en charge de CentOS Stream 8. CentOS Stream 8 est une distribution prise en charge jusqu'en mai 2024. Des chemins de migration triviaux sont fournis par les différentes communautés ELC (Enterprise Linux Clone).

    Á titre individuel c'est également mon choix, depuis plusieurs mois mes petits serveurs tournent grâce à CentOS Stream 8. Sans aucun problème, seulement l'abandon d'une caractéristique secondaire sur la diffusion vidéo qui nécessitait un dépôt externe, celui-ci s'avérant ne pas suivre le rythme de CentOS Stream.

    • [^] # Re: Fermilab & CERN, scientific linux

      Posté par  (site web personnel) . Évalué à 6.

      Je n'ai jamais compris pourquoi le CERN qui promeut le libre n'est jamais passé à Debian. Ce serait un super acteur de poids dans le monde pour la promotion de cette distribution collaborative. Une occasion manquée ;-)

      (Cela fait plus de 20 ans que je suis passé de RH à Debian sur tout mon parc sans avoir jamais regretté la bascule).

      • [^] # Re: Fermilab & CERN, scientific linux

        Posté par  . Évalué à 9.

        Je n'ai jamais compris pourquoi le CERN qui promeut le libre n'est jamais passé à Debian.

        CentOS ou Scientific Linux n'est pas libre ?

        « 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: Fermilab & CERN, scientific linux

          Posté par  (site web personnel) . Évalué à 4.

          CentOS ou Scientific Linux étaient basé sur RHEL qui ne fournissait pas les recettes de construction de la distribution, entraînant de fait la galère pour reconstruire une équivalent de la RHEL.

          Avec Debian, toutes les recettes sont données, et c'est hyper facile de faire une distribution dérivée ou augmentée.

          • [^] # Re: Fermilab & CERN, scientific linux

            Posté par  (site web personnel) . Évalué à 9.

            CentOS ou Scientific Linux étaient basé sur RHEL qui ne
            fournissait pas les recettes de construction de la
            distribution, entraînant de fait la galère pour
            reconstruire une équivalent de la RHEL.

            Les SRPMS sont sur ftp.redhat.com depuis grosso modo toujours.

            Example: http://ftp.redhat.com/pub/redhat/linux/enterprise/4/en/os/x86_64/SRPMS/

            Et avec l'intégration de Centos, il y a eu un dépôt git sur git.centos.org avec tout ce qui est utilisé pour compiler RHEL.

            Et avec Centos Stream, c'est encore plus transparent vu que les gens peuvent justement participer (contrairement à l'ancienne Centos, et c'est aussi une des raisons d'avoir fait le changement) .

            Avec Debian, toutes les recettes sont données, et c'est
            hyper facile de faire une distribution dérivée ou
            augmentée.

            Que je sache, Debian fourni exactement la même chose que ce que fournit RHEL ou Centos, à savoir des paquets sources.

            Et dans les 2 cas, les systèmes de build sont des logiciels libres (exemple, koji & mock pour Centos/RHEL/FEdora, pbuilder, etc pour Debian).

          • [^] # Re: Fermilab & CERN, scientific linux

            Posté par  . Évalué à 6.

            CentOS ou Scientific Linux étaient basé sur RHEL qui ne fournissait pas les recettes de construction de la distribution, entraînant de fait la galère pour reconstruire une équivalent de la RHEL.

            Ben du coup, CentOS et Scientific Linux était bien libre.

            'est hyper facile de faire une distribution dérivée ou augmentée.

            Ce n'est pas le sujet de savoir si c'est libre 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: Fermilab & CERN, scientific linux

        Posté par  (site web personnel) . Évalué à 8.

        Sans doute parce que Debian ne réponds pas aux besoins du CERN.

        Par exemple, acheter des clusters de matos et avoir une assurance assez forte que ça va marcher parce que tu as les mêmes patchs que la version RHEL qui est certifié.

        Ou avoir un cycle de vie logiciel prévisible et un peu plus long que 2/3 ans.

        • [^] # Re: Fermilab & CERN, scientific linux

          Posté par  (site web personnel) . Évalué à 3.

          Je ne connais pas grand monde qui fait fonctionner un cluster sous RHEL, c'est trop cher les licences.

          Quand tu es le CERN est que tu achètes 20 racks d'un coup, le constructeur est près à faire quelques efforts ! Et comme je l'ai dis, depuis 20 ans, aucun soucis sous Debian. Quand au cycle de vie, avec la LTS / ELTS, il y a moyen d'avoir plus long. Et j'ai parlé de Debian ou dérivée donc cela aurait pu être Ubuntu.

          Personnellement, j'ai toujours eu l'impression qu'ils mettaient beaucoup d'énergie à suivre RHEL et que celle-ci aurait pu être mieux utilisé… Et les noyaux sous Debian / RHEL… peuvent être les mêmes. À vrai dire, le code dérive des mêmes dépôts. Mais bon, tout cela est une impression personnelle.

          • [^] # Re: Fermilab & CERN, scientific linux

            Posté par  (site web personnel) . Évalué à 8. Dernière modification le 07 novembre 2021 à 22:28.

            Je ne connais pas grand monde qui fait fonctionner un cluster
            sous RHEL, c'est trop cher les licences.

            Pourtant:

            https://www.redhat.com/en/about/press-releases/red-hat-powers-future-supercomputing-red-hat-enterprise-linux

            Il y a sans doute des chiffres sur les déploiments d'openshift ou d'openstack mais j'ai rien trouvé de publique.

            Mais si la version 3 d'openshift a été testé sur 2000 noeuds, ç'est sans doute parce que des clients ont demandés:

            https://docs.openshift.com/container-platform/3.11/scaling_performance/cluster_maximums.html

            Quand au cycle de vie, avec la LTS / ELTS, il y a moyen
            d'avoir plus long. Et j'ai parlé de Debian ou dérivée donc
            cela aurait pu être Ubuntu.

            Sauf que Ubuntu fait pas ça gratuitement non plus.
            Ubuntu, c'est au max 10 ans si tu payes:

            https://ubuntu.com/about/release-cycle

            RHEL, c'est jusqu'à 13 ans si tu payes:
            https://access.redhat.com/support/policy/updates/errata/

            et ça, c'est sans rentrer dans les détails de ce qui est couvert exactement. Par exemple, Ubuntu mets à jour le kernel pour réduire les couts, ce qui va sans doute casser la compatibilité de l'ABI interne du kernel, ce qui est pas forcément super pour des drivers en dehors du dit kernel.

            Dans mon souvenir (d'il y a longtemps), le CERN va parfois refaire des drivers de cartes réseaux pour les perfs, donc je peux comprendre qu'ils ont pas envie de faire du portage tout les 2/3 ans.

            D'ailleurs, si on regarde le top 10 sur:
            https://www.top500.org/lists/top500/list/2021/06/

            Il y a 3 RHEL, 3 Centos, 1 Ubuntu, 1 dérivé d'Ubuntu, 1 OS custom et 1 cray linux.

            Si on pousse dans les 25 premiers, on retrouve de la RHEl, de la SLES, du craylinux, et "linux". De ce que j'ai vu, il y a 0 debian dans les 25 premiers (ou alors, pas sous le nom Debian).

            Ça veut pas dire que Debian n'est pas valable, mais clairement, il n'y a pas que le CERN qui fait le choix de prendre RHEL ou une dérivée.

            Personnellement, j'ai toujours eu l'impression qu'ils
            mettaient beaucoup d'énergie à suivre RHEL et que celle-ci
            aurait pu être mieux utilisé… Et les noyaux sous Debian /
            RHEL… peuvent être les mêmes. À vrai dire, le code dérive des
            mêmes dépôts. Mais bon, tout cela est une impression
            personnelle.

            Dire que le code dérive des mêmes dépots, c'est une grosse simplification.

            Le code, ça se teste, ça se corrige, et ça, ça coûte des ressources. Je ne sais pas combien de personnes il y a sur ça au CERN, mais Scientific Linux, c'était 2 personnes à temps plein pour faire un dérivé de Centos, il n'y a pas non plus de quoi faire des miracles avec ça, même si ça donne une distro séparé.

            • [^] # Re: Fermilab & CERN, scientific linux

              Posté par  (site web personnel) . Évalué à 4.

              Bon, Misc< est employé Red Hat (disclaimer), pour autant il bénéficie de bonnes infos, fait partie des fondateurs de Mageia (même s'il s'en est éloigné :/)

              Au moins il sait sourcer ses positions ;-)

              Donc, bon, je lui donne toute ma confiance, même s'il ne soutient pas autant Debian que moi ;-) (Mandriva était maintenu par des debianneux, des gentooistes, des fedoristes et autres distros, ce n'est pas pour rien que le premier travail côté Mageia a été d'avoir un build system autonome hébergé chez des amis du libre (que ce soit free ou lost-oasis, plutôt debianneux pour le coup :D)

              Pour le coup c'est surtout AdamW qui a fait que rawhide soit à tout moment installable et ce qui se voit sur CentOS aussi (comme l'était cooker et que l'est cauldron que j'utilise au jour le jour).


              Gentoo actuellement 53ème sur https://distrowatch.com/ o_O

              • [^] # Re: Fermilab & CERN, scientific linux

                Posté par  (site web personnel) . Évalué à 4.

                Gentoo actuellement 53ème sur https://distrowatch.com/ o_O

                C'est presque vendredi, donc je vais sauter à pied joint. DW ne mesure que l'audience de son propre site (sauf erreur de ma part). Et quand l'audience max d'une page, c'est 3000 visites par jour (parce que la distro a été annoncé dans Distro watch weekly), ça ne me parait pas super représentatif, ni ne permet de tirer grand chose.

                Linuxfr, c'est ~1890 comptes utilisés y a moins de 3 mois. Le FOSDEM, c'est dans les 8000 personnes (cf la page web). Et Canonical parle de 25 millions d'utilisateurs Ubuntu en 2014.

                Donc bon, ça veut juste dire que personne ne va voir la page de Gentoo sur Distrowatch, sans doute parce que Gentoo n'est pas mentionné dans les news.

                • [^] # Re: Fermilab & CERN, scientific linux

                  Posté par  (site web personnel) . Évalué à 3.

                  Donc bon, ça veut juste dire que personne ne va voir la page de Gentoo sur Distrowatch, sans doute parce que Gentoo n'est pas mentionné dans les news.

                  bin oui, une rolling release, c'est tous les jours qu'il y a une mise à jour ;-)
                  Je reste en cauldron parce que j'ai confiance en neoclust et marja (côté QA). Et elle n'apparaît pas non plus sur distrowatch ;-)

                  Chez Red Hat, j'ai 2-3 contact, côté Fedora un peu plus, chez CentOS un peu moins (genre 1)
                  Côté Mageia j'ai gardé plus d'amis, dont toi et pas que.

                  DW ne mesure que l'audience de son propre site

                  ah bah oui, c'est d'ailleurs indiqué sur https://distrowatch.com/dwres.php?resource=faq#phr
                  (bon faut lire l'anglois)

                  Le FOSDEM, c'est dans les 8000 personnes (cf la page web).

                  j'espère t'y revoir IRL début février prochain

                  Et Canonical parle de 25 millions d'utilisateurs Ubuntu en 2014

                  côté Mageia, nous privilégions de ne pas faire de stats sur nos utilisateurs. Sans doute à notre détriment, mais bon. C'est une question de respect et de choix éthique envers nos utilisateurs.
                  Des gens comme MLO ou blogdrake (espagnol) aident bien et j'aime bien les initiatives comme https://wiki.mageia.org/en/Category:Non-English (tellement c'est un contre-pied voire inattendu o_O)

          • [^] # Re: Fermilab & CERN, scientific linux

            Posté par  . Évalué à 5.

            Quand tu es le CERN est que tu achètes 20 racks d'un coup, le constructeur est près à faire quelques efforts !

            Quelques efforts mais pas trop quand même (vu que c'est un appel d'offre avec le moins cher qui gagne). De plus, il pourra peut-être réussi à tester/patché une debian stable, mais il n'y a pas de garantie pour la prochaine. Alors que pour une distribution qui est déjà supportée sur le matos, il y a une plus grande garantie.

            Personnellement, j'ai toujours eu l'impression qu'ils mettaient beaucoup d'énergie à suivre RHEL et que celle-ci aurait pu être mieux utilisé… Et les noyaux sous Debian / RHEL… peuvent être les mêmes. À vrai dire, le code dérive des mêmes dépôts. Mais bon, tout cela est une impression personnelle.

            Quand tu maîtrise bien RHEL, c'est moins d'effort que de passer à Debian, pour un avantage assez minimal.

            « 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: Fermilab & CERN, scientific linux

              Posté par  (site web personnel) . Évalué à 4.

              Quelques efforts mais pas trop quand même (vu que c'est un
              appel d'offre avec le moins cher qui gagne). De plus, il
              pourra peut-être réussi à tester/patché une debian stable,
              mais il n'y a pas de garantie pour la prochaine. Alors que
              pour une distribution qui est déjà supportée sur le matos,
              il y a une plus grande garantie.

              Surtout, le constructeur va faire quoi ?

              Aller demander à chacun des fournisseurs d'aller faire des patchs sur une distro qui n'est justement pas géré par une entité commercial, à qui on va dire "on est volontaire, on fait ça sur notre temps libre, mets ça dans le BTS, on regarderas plus tard" ?

              Le constructeur va avoir ni une garantie contractuelle que le travail va être fait ( ce qui est un souci si tu signes toi un contrat qui dit que ça va être fait), ni que ça va être fait dans le temps imparti. Donc les fabricants qui veulent faire des efforts vont voir les autres entités commerciales, eg, Suse, RH, Canonical en fonction de la demande (entités commerciales qui vont pas faire le taf gratos, donc le fabricant a autant passer par les mêmes en fonction de la demande des clients ).

            • [^] # Re: Fermilab & CERN, scientific linux

              Posté par  . Évalué à 3.

              Quelques efforts mais pas trop quand même (vu que c'est un appel d'offre avec le moins cher qui gagne). De plus, il pourra peut-être réussi à tester/patché une debian stable, mais il n'y a pas de garantie pour la prochaine. Alors que pour une distribution qui est déjà supportée sur le matos, il y a une plus grande garantie.

              Tu parle d'une distribution pas libre de RHEL ? Dans les faits qui j'ai souvent entendu cet argument je n'ai jamais eu l'occasion de l'observer. RedHat travaille étroitement avec les projets upstream et so j'ai peut être un jour croisé un microcode qui était packagé en rpm, vu sa qualité utiliser le tar qui était à côté était aussi bien.

              Par contre j'ai vu des fabricants refuser tout support qui tu n'a pas RHEL ou centos. Je trouve ça très dommage, même si on peut l'expliquer, ça ressemble beaucoup aux machines qui perdent le support et ou la garantie qui tu vire le windows ou l'OSX installé.

              https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

              • [^] # Re: Fermilab & CERN, scientific linux

                Posté par  . Évalué à 3.

                Je n'ai pas compris ce que tu voulais dire.

                « 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: Fermilab & CERN, scientific linux

                  Posté par  . Évalué à 3.

                  Je n'ai jamais pu constater de support matériel différent entre RHEL et une autre distribution.

                  Par contre j'ai souvent vu des fabricants refuser tout SAV si tu n'est pas sur RHEL.

                  https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                  • [^] # Re: Fermilab & CERN, scientific linux

                    Posté par  (site web personnel) . Évalué à 0.

                    Je n'ai jamais pu constater de support matériel différent entre RHEL et une autre distribution.

                    bin oui, Debian fonctionne aussi bien

                    Par contre j'ai souvent vu des fabricants refuser tout SAV si tu n'est pas sur RHEL.

                    les incompétents, yen a partout :/ (et ça ose tout, tontons flingueurs inside :D)

                  • [^] # Re: Fermilab & CERN, scientific linux

                    Posté par  . Évalué à 3.

                    Via des backports, j'ai déjà vu supporté du matos plus récent sur rhel qui ne l'était pas sur une debian stable. Mais oui, globalement, c'est juste une "assurance".

                    « 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: Fermilab & CERN, scientific linux

                      Posté par  . Évalué à 3.

                      Comme je disais c'est un peu plus puisque tu retrouve de la part des fabricants un peu la même démarche que pour les ventes liées. Je dis ça sans complotisme je ne crois pas du tout que RH soit derrière ça. Juste que RH rassure les fabricants parce que c'est une entreprise qui a une image de sérieux et puis 10 ans de support (oulala c'est bien 10 ans de support (non1)). C'est pour ça qu'on a pu voir Suze à l'époque de Novel avoir le même traitement.


                      1. ça n'est une bonne idée que dans quelques cas particulier d'avoir des temps de support aussi long. RH ne fait pas de magie pour toi. Si tu utilise ce support incroyable de 10 ans. Soit tu passe d'une version n à n+1 et tu as 2 ans de support restant… Soit tu passe de la version n à n+5 et bonjour le saut de 10 ans d'un coup. On va trouver des cas où c'est utile et ça a du sens, mais c'est justement des cas, pas le général du tout (alors qu'on le présente comme un argument commun). Bref 

                      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                      • [^] # Re: Fermilab & CERN, scientific linux

                        Posté par  . Évalué à 4.

                        Comme je disais c'est un peu plus puisque tu retrouve de la part des fabricants un peu la même démarche que pour les ventes liées. Je dis ça sans complotisme je ne crois pas du tout que RH soit derrière ça. Juste que RH rassure les fabricants parce que c'est une entreprise qui a une image de sérieux et puis 10 ans de support (oulala c'est bien 10 ans de support (non1)).

                        Tu extrapole beaucoup il me semble. J'ai plutôt l'impression que c'est "on ne veut pas gérer 42 distributions" (rien que pour pouvoir reproduire facilement) et "on veut pouvoir payer quelqu'un pour corriger en cas de besoin". Donc avoir RHEL et Suse de supporter, c'est pas mal. D'ailleurs, on voit Ubuntu qui commence à être supporté, pareil parce qu'il y a quelqu'un qu'on peut payer et il y a de la demande client.

                        C'est pour ça qu'on a pu voir Suze à l'époque de Novel avoir le même traitement.

                        Ce n'est pas simplement parce que c'était une (grosse) boîte américaine avec les contacts chez les constructeurs déjà établis ?

                        « 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: Fermilab & CERN, scientific linux

                          Posté par  . Évalué à 3.

                          Tu extrapole beaucoup il me semble. J'ai plutôt l'impression que c'est "on ne veut pas gérer 42 distributions" (rien que pour pouvoir reproduire facilement) et "on veut pouvoir payer quelqu'un pour corriger en cas de besoin". Donc avoir RHEL et Suse de supporter, c'est pas mal. D'ailleurs, on voit Ubuntu qui commence à être supporté, pareil parce qu'il y a quelqu'un qu'on peut payer et il y a de la demande client.

                          Si c'était le cas, on ne te jetterais pas pour cause d'utilisation non conforme pour des problèmes purement hardware.

                          Après je me suis peut être pas très bien exprimé, je ne crois pas que ce soit quelque chose de particulièrement machiavélique, soit c'est une reproduction de comportement que l'on trouve ailleurs (sur le matériel avec vente liée par exemple) soit c'est de l'incompétence/mauvaise organisation/volonté de réduire le nombre de demande de support.

                          S'ils ne voulaient pas supporter 42 distributions, ils pourraient parfaitement supporter le nombre qu'ils veulent de noyau LTS (la dernière, les 2 dernières, les 3 dernières…) et te dire de te débrouiller avec ton OS (éventuellement avoir une préco pour une distrib', mais une préconisation pas un truc qui sert à t'invalider en support).

                          Ce n'est pas simplement parce que c'était une (grosse) boîte américaine avec les contacts chez les constructeurs déjà établis ?

                          Si c'est le cas du coup c'est moins "on veut pas supporter 42 distributions" que "on ne supporte que les distributions avec qui on a un accord financier". Mais ça revient plus ou prou au même, faut avoir une cravate et un chéquier pour pouvoir exister en tant que distribution.

                          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                          • [^] # Re: Fermilab & CERN, scientific linux

                            Posté par  . Évalué à 4.

                            ils pourraient parfaitement supporter le nombre qu'ils veulent de noyau LTS

                            Du coup, tu n'as aucune distribution utilsée en entreprise qui est supportée. Vu qu'elles ont toutes des patchs spécifiques.

                            soit c'est de l'incompétence/mauvaise organisation/volonté de réduire le nombre de demande de support.

                            Ou c'est juste que les trois clients qui payent et qui n'ont pas RHEL/Suse/Ubuntu, ça ne vaut pas trop la peine de se fatiguer pour les 42€ de marge qu'ils apportent. Je ne vois pas trop pourquoi une boîte commencerait à avoir un process compliqué pour des cas d'utilisation marginaux.

                            Mais ça revient plus ou prou au même, faut avoir une cravate et un chéquier pour pouvoir exister en tant que distribution

                            Non, c'est surtout "il faut un point de contact pour exister". Rien que pour publier des images Debian sur les cloud ça a été compliqué pour savoir comment s'organiser pour se faire représenter. Alors, pour mettre en place un système qui répond avec un devis à une demande d'un constructeur (pour un cas marginal, parce qu'au final, ça fonctionne), je pense que c'est quasiment mission impossible.

                            « 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: Fermilab & CERN, scientific linux

                              Posté par  . Évalué à 3.

                              Du coup, tu n'as aucune distribution utilsée en entreprise qui est supportée. Vu qu'elles ont toutes des patchs spécifiques.

                              Bof, non, soit il s'agit de patch du constructeur et les distributions vont les inclures soit c'est mergé upstream et ça passe aussi.

                              Non, c'est surtout "il faut un point de contact pour exister".

                              Comprends moi. Je vois pas pourquoi on me jette parce que j'utilise un gentoo quand je demande des conseils sur des éléments purement matériel. Il n'est pas question que les constructeurs soient experts toutes distributions juste qu'elles acceptent que leur job c'est de fournir du matériel et le minimum logiciel pour le faire tourner.

                              https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                              • [^] # Re: Fermilab & CERN, scientific linux

                                Posté par  . Évalué à 3.

                                Bof, non, soit il s'agit de patch du constructeur et les distributions vont les inclures soit c'est mergé upstream et ça passe aussi.

                                Mais les distributions backport beaucoup de truc, inclus des trucs hors tree et autres choses qui font que ça n'est pas équivalent à un kernel LTS vanilla. Donc tu n'auras pas forcément la même chose.

                                Comprends moi. Je vois pas pourquoi on me jette parce que j'utilise un gentoo quand je demande des conseils sur des éléments purement matériel.

                                Tu es jeté sur quel type de demande exactement ?

                                Il n'est pas question que les constructeurs soient experts toutes distributions juste qu'elles acceptent que leur job c'est de fournir du matériel et le minimum logiciel pour le faire tourner.

                                Ça c'est ta vision du boulot d'un constructeur (et la mienne aussi). Mais ce n'est pas ce qui est attendu par les clients entreprises qui veulent ouvrir un ticket en disant "ça ne marche pas" et que le fournisseur lance des outils de debug (ou en fasse lancer par le client) pour avoir un diagnostique pour savoir s'il doit envoyer un disque, une carte mère ou dire au client que c'est normal que la diode verte soit allumée quand le serveur tourne.

                                « 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: Fermilab & CERN, scientific linux

                                  Posté par  . Évalué à 2. Dernière modification le 09 novembre 2021 à 14:13.

                                  Tu es jeté sur quel type de demande exactement ?

                                  Par exemple sur de la conf d'iLO HPE pour en savoir un peu plus pour de l'authentification.

                                  Ça c'est ta vision du boulot d'un constructeur (et la mienne aussi). Mais ce n'est pas ce qui est attendu par les clients entreprises qui veulent ouvrir un ticket en disant "ça ne marche pas" et que le fournisseur lance des outils de debug (ou en fasse lancer par le client) pour avoir un diagnostique pour savoir s'il doit envoyer un disque, une carte mère ou dire au client que c'est normal que la diode verte soit allumée quand le serveur tourne.

                                  Ils file ces machines à des professionnels dont c'est le boulot de les garder en condition opérationnel. Le constructeur donne des spec il n'est pas là pour mettre à leur norme la pièce dans la quelle les machines sont installées, vérifier le réseau électrique, etc. Ils te fournissent même des formations si tu veux en savoir plus sur leurs machines.

                                  https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                                  • [^] # Re: Fermilab & CERN, scientific linux

                                    Posté par  . Évalué à 3.

                                    Ils file ces machines à des professionnels dont c'est le boulot de les garder en condition opérationnel.

                                    Je pense que tu surestime beaucoup les clients standard de ces fournisseurs.

                                    Le constructeur donne des spec il n'est pas là pour mettre à leur norme la pièce dans la quelle les machines sont installées, vérifier le réseau électrique, etc.

                                    Ce n'est pas pour rien qu'il y a une mesure de la tension en entrée, de la température en entrée…

                                    « 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: Fermilab & CERN, scientific linux

                                      Posté par  . Évalué à 2.

                                      Je pense que tu surestime beaucoup les clients standard de ces fournisseurs.

                                      Si c'est pour être purement client, l'hébergement c'est bien.

                                      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                                      • [^] # Re: Fermilab & CERN, scientific linux

                                        Posté par  . Évalué à 3.

                                        C'est un autre débat que ces fournisseurs n'ont pas vraiment intérêt à encourager.

                                        « 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: Fermilab & CERN, scientific linux

                                    Posté par  . Évalué à 3.

                                    Par exemple sur de la conf d'iLO HPE pour en savoir un peu plus pour de l'authentification.

                                    Je n'ai jamais eu affaire à HPE mais chez d'autre, j'ai eu des demandes du support pour que j'exécute des commandes de debug sans qu'ils me demandent jamais quelle était la distribution avec laquelle je les lançais.

                                    « 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: Fermilab & CERN, scientific linux

                            Posté par  (site web personnel) . Évalué à 3.

                            S'ils ne voulaient pas supporter 42 distributions, ils
                            pourraient parfaitement supporter le nombre qu'ils veulent de
                            noyau LTS (la dernière, les 2 dernières, les 3 dernières…) et
                            te dire de te débrouiller avec ton OS (éventuellement avoir
                            une préco pour une distrib', mais une préconisation pas un
                            truc qui sert à t'invalider en support).

                            C'est une distinction artificielle basé sur un détail purement technique, et supposer qu'il y a une frontière entre l'userspace et le noyau pour le support.

                            Tu peux pas juste avoir le support du noyau, vu qu'une partie de l'userspace en dépend. Par exemple, iptables/nftables va dépendre du noyau, vu que tu as des bouts dans le kernel. Gluster peut utiliser des appels systèmes spécifiques du kernel (genre io_uring), SElinux (ou apparmor) interagit aussi avec le kernel, la glibc va masquer certains syscall ou en émuler d'autres. Ou simplement udev.

                            Les distributions vont faire des efforts pour que ça casse pas trop souvent (ne serais que pour les upgrades), mais si ça casse, elles vont pas dire "on va corriger pour ton kernel custom", mais "ça marche avec notre noyau, corrige le tien".

                            Donc l'idée d'avoir un OS séparé du noyau, c'est une illusion, tout est mis pour fonctionner ensemble, et c'est pas parce que tu estimes qu'il y a une frontière que la frontière a du sens pour un autre usage (eg, délimiter les responsabilités pour le support).

                            Si c'est le cas du coup c'est moins "on veut pas supporter 42
                            distributions" que "on ne supporte que les distributions avec
                            qui on a un accord financier". Mais ça revient plus ou prou au
                            même, faut avoir une cravate et un chéquier pour pouvoir
                            exister en tant que distribution.

                            Il y a plusieurs alternatives, comme avoir les distributions faire le support niveau 1, mais ça demande aussi un chéquier soit coté distribution. Tu peux aussi faire le support en interne, et avoir ta propre équipe kernel. Ça demande de sortir aussi le chéquier, mais ça semble être courant dans les boites de tech d'une certaine taille (cf https://danluu.com/in-house/ ).

                            Mais ça demande toujours de sortir le chéquier parce que visiblement, personne ne veut le faire gratuitement, et ça mérite sans doute la question de "pourquoi ?".

                            • [^] # Re: Fermilab & CERN, scientific linux

                              Posté par  . Évalué à 2.

                              Tu peux pas juste avoir le support du noyau, vu qu'une partie de l'userspace en dépend. Par exemple, iptables/nftables va dépendre du noyau, vu que tu as des bouts dans le kernel. Gluster peut utiliser des appels systèmes spécifiques du kernel (genre io_uring), SElinux (ou apparmor) interagit aussi avec le kernel, la glibc va masquer certains syscall ou en émuler d'autres. Ou simplement udev.

                              Parce que tu pense que les fabriquants (je pense aux fabriquants de matériel - on parle de DELL, IBM, Oracle,… - qui supportent actuellement RH pas d'embarquer où RHEL est inexistant) ont une intrication aussi grande ? Par exemple tu aurait un iptables-hp qui utilise l'appel système créé par HP qui utilise le circuit top moumout de la carte réseau HP ?

                              Comme je le dis plus haut, je n'arrive pas à trouver de cas où ce que tu affirme se révèle. Dans les faits, ses constructeurs sont supporté upstream (de leur fait ou pas) et tu marche aussi bien avec une slackware qu'avec la RHEL.

                              https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                              • [^] # Re: Fermilab & CERN, scientific linux

                                Posté par  (site web personnel) . Évalué à 2.

                                Parce que tu pense que les fabriquants (je pense aux
                                fabriquants de matériel - on parle de DELL, IBM, Oracle,… - qui
                                supportent actuellement RH pas d'embarquer où RHEL est
                                inexistant) ont une intrication aussi grande ? Par exemple tu
                                aurait un iptables-hp qui utilise l'appel système créé par HP
                                qui utilise le circuit top moumout de la carte réseau HP ?

                                Je pige pas la question. je dit juste que décider de ne supporter que le kernel n'a aucun sens car il n'est pas un composant isolé, vu que l'userspace plus haut en dépend.

                                On voit ça par exemple sur les conteneurs, comme décrit par un de mes collègues: http://crunchtools.com/5040-2/

                                Comme je le dis plus haut, je n'arrive pas à trouver de cas où
                                ce que tu affirme se révèle. Dans les faits, ses constructeurs
                                sont supporté upstream (de leur fait ou pas) et tu marche
                                aussi bien avec une slackware qu'avec la RHEL.

                                Dans les faits, les constructeurs devraient demander de lancer des outils de diagnostiques avant un RMA. Soit un outil dans le bios/EFI (auquel cas on retire la couche avant et la distro, OSEF), soit des outils en userspace (et on revient à la question du support des distros).

                                Ensuite, ça n'a pas l'air d'avoir été ton expérience et je crois comprendre qu'on a du te dire "merde" à un ticket pour divers raisons lié à la distro. Je ne vais pas te contredire sur ce point mais perso, je n'ai pas eu ce souci. Et pourtant, on fait pas tourner RHEL dans mon équipe mais Centos/Fedora/Debian en fonction des demandes. On a que je sache jamais eu de tickets refusés.

                                Mais je suppose que c'est pas ce qui t'arrive, donc peut être que tu devrais clarifier les faits, parce que j'ai pas le sentiment de pouvoir suivre en ayant qu'une sous partie de l'histoire.

                                • [^] # Re: Fermilab & CERN, scientific linux

                                  Posté par  . Évalué à 2.

                                  Je pige pas la question. je dit juste que décider de ne supporter que le kernel n'a aucun sens car il n'est pas un composant isolé, vu que l'userspace plus haut en dépend.

                                  L'énorme majorité des cas le userspace dépend du HAL et il n'y a pas de raison particulière pour que le matériel expose autre chose. Si j'ai bien compris ton lien parle d'autre chose : faire tourner des applications d'une version à une autre d'un noyau. Là c'est l'ABI du noyau qui est en question.

                                  Ensuite, ça n'a pas l'air d'avoir été ton expérience et je crois comprendre qu'on a du te dire "merde" à un ticket pour divers raisons lié à la distro.

                                  Pas qu'un seul, mais oui c'est ce que j'ai dis plusieurs fois.

                                  Dès mon premier commentaire :

                                  Par contre j'ai vu des fabricants refuser tout support qui tu n'a pas RHEL ou centos

                                  Dans mon second :

                                  Par contre j'ai souvent vu des fabricants refuser tout SAV si tu n'est pas sur RHEL.

                                  Encore dans un autre :

                                  Si c'était le cas, on ne te jetterais pas pour cause d'utilisation non conforme pour des problèmes purement hardware.

                                  Ce n'était pas clair ?

                                  https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                                  • [^] # Re: Fermilab & CERN, scientific linux

                                    Posté par  (site web personnel) . Évalué à 2.

                                    Ben tu dis pas quel fabricant, quel support, quel demande est ce que tu as eu ni rien.

                                    Moi, j'ai l'expérience contraire. Donc c'est peut être une question de contrat de support (donc de coût). Peut être que c'est une question de taille du client (donc pareil, de coût).

                                    • [^] # Re: Fermilab & CERN, scientific linux

                                      Posté par  . Évalué à 2.

                                      Par exemple sur de la conf d'iLO HPE pour en savoir un peu plus pour de l'authentification.

                                      Le truc tourne indépendamment de l'OS, hein. Par contre je ne connais pas la contractualisation, mais dire vous n'avez pas assez payé pour ce niveau de support c'est différent de "vous avez pas l'OS qu'on veut donc débrouille toi".

                                      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                                      • [^] # Re: Fermilab & CERN, scientific linux

                                        Posté par  (site web personnel) . Évalué à 3.

                                        Ok, oui, mais du coup, ça n'a aucun sens vu que la question de l'ilo ne dépend même pas de l'état du serveur.

                                        Le support niveau 1 a juste l'air d'être mauvais (ça arrive, mais bon, pareil, question de cout). Mais c'est vrai que c'est pas ce que j'avais en tête quand tu as dit "support".

                        • [^] # Re: Fermilab & CERN, scientific linux

                          Posté par  (site web personnel) . Évalué à 4.

                          Oui, c'est 100% une question économique.

                          C'est en bossant chez un éditeur que j'ai fini par piger à quel point une partie de la communauté du libre (mais pas que) se fait des idées sur sa propre importance vis à vis des éditeurs (genre Microsoft et co, vers les années 2000).

                          Par exemple justement, les histoires de vente lié y a 15/20 ans sur linuxfr, c'est pas du tout pour empêcher Linux de percer comme on a pu me dire un jour.

                          C'est parce que les gros clients de Microsoft, c'est les vendeurs de PC, et parce que vendre un PC avec Windows, ça permet de levendre aussi avec les trucs Norton et co (et donc Norton qui va payer pour être la), donc de faire baisser les prix, donc d'être compétitif envers les autres vendeurs de PC.

                          Je dit pas que c'est une situation saine, loin de la, Microsoft reste en situation de monopole, même si l'industrie des intégrateurs semble s'en accommoder.

                          Mais c'est pas du tout le discours qu'on avait autour de ça, ou du moins, c'est pas l'explication qu'on donnait.

                          La, c'est pareil, il y a des mécanismes économiques en jeu qui passent assez souvent par dessus la tête des gens qui sont hors de ce bout de l'industrie, et on va croire que parce qu'on veux une chose, d'autres veulent pareil, et que ça a du sens économiquement de le faire.

                          Ensuite, bah, les accords d'exclusivités, ça existe. Les accords commerciaux, ça reste en général secret. Et dans le cas de Micorosoft vis à vis des fabricants, il y a clairement un déséquilibre vu qu'il y a un acteur (MS) face à une poignée, donc il est assez facile pour l'un de faire jouer la concurrence.

                          À minima, le logiciel libre permet d'éviter la situation, vu que n'importe quel constructeur peut à tout moment dire "on va prendre Centos/Alma/Rocky/Oracle/Suse/Ubuntu/RHEL" pour négocier avec tout les autres, et pareil du coté des éditeurs.

                          Et c'est aussi pour ça que je pense que l'annonce de la fin de CL 8 était une bonne chose, vu que ça a enfin fait bouger la communauté pour faire des choses. Les histoires lors de la sortie de Centos 6 (et son retard) sont connus, mais c'est que la partie immergé.

                          Après l'arrivée des responsables de Centos chez RH, mes collègues ont vu que la communauté a commencé à se reposer de plus en plus sur RH (exemple, lors des dojos Centos), les tentatives de faire des SIG (Software Interest Group) ont pas forcément super bien marché. Et que la communauté, c'était surtout une communauté d'utilisateurs, donc l'idée de co-création était assez étrangère pour eux.

                          Au moins, avec Rocky/Alma, il y a des gens motivés pour gérer l'infra, faire des présentations, etc, etc. C'est triste d'avoir du passer par un choc comme celui la, mais je sais que c'est pas faute d'avoir tenté autre chose avant.

  • # Utilisation en production

    Posté par  . Évalué à 9.

    "De fait, il est désormais inconcevable d'utiliser CentOS Stream en production."
    C'est une affirmation un peu péremptoire…

    Concernant le modèle rolling release, mis à part quelques amateurs éclairés qui mettent à jour leurs serveurs très régulièrement, je n'ai pas vu beaucoup de grandes sociétés "orchestrer" des campagnes de mises à jour sur des parcs de centaines de serveurs de manière régulière (quand je dis régulière, ce ne serait qu'une à deux fois pas an)

    Concernant les mises à jours apportées à CentOS Stream 8, ce sont les mises à jours qui arriveront plus tard sur RHEL 8. CentOS Stream n'est pas une beta de la prochaine version de RHEL. Les utilisateurs de CentOS Stream 8 ont des mises à jour au fil de l'eau, que les utilisateurs de RHEL 8 auront à la prochaine version mineure (à quelques exceptions).

    C'est si grave que ça pour que ce soit "inconcevable" de l'utiliser en prod ?

    • [^] # Re: Utilisation en production

      Posté par  . Évalué à 3.

      Par contre, si on parle d'utilisation en production, on ne pense pas assez aux nouvelles communautés de Alma et de Rocky…
      Est-ce qu'elles existeront encore dans 3 ou 4 ans une fois tous les workloads migrés ?
      Est-ce qu'elles tiendront la cadence en terme de mise à jour ? Si une faille importante est corrigée dans RHEL, en combien de temps sera-telle disponible sur Alma/Rocky, et ce, tout au long de la vie de la distribution ?

    • [^] # Re: Utilisation en production

      Posté par  . Évalué à 5.

      Tout dépends de quel grosse société, on parle. Car il me semble que Facebook a choisi CentOS Stream 8 pour ses serveurs et Google a son propre Debian « Sid ». Et avec des conteneurs, les mises à jour des paquets traditionnels ont de moins en moins d’importance. C’est surtout le kernel, la glibc/muslc,… qui ont de l’importance.

      Donc en fait, le mieux est d’avoir un juste milieu entre stabilité et nouveauté, et dans ce cas CentOS Stream 8 a du sens.

      Être trop loin du programme upstream n’est pas toujours bon, et ce n’est pas toujours facile de corriger une faille de sécurité dans une ancienne version sans faire d’erreurs ou introduire d’autres bugs.

      Tout dépend des besoins et du contexte.

      • [^] # Re: Utilisation en production

        Posté par  (site web personnel) . Évalué à 7.

        Donc en fait, le mieux est d’avoir un juste milieu entre
        stabilité et nouveauté, et dans ce cas CentOS Stream 8 a du
        sens.

        Mais CS8 va avoir les mêmes mises à jours que RHEL (et donc que l'ancienne Centos avant), donc l'aspect "nouveauté" est quand même assez réduit.

        La raison pour Facebook d'avoir pris Stream est justement pour pouvoir envoyer des correctifs, chose qui était difficile avant (un mec de Facebook a fait un talk sur le sujet y a quelque années, et il a donné des détails dans un bar après la présentation, genre tout ce qui concerne IP v6 sur Centos 7, vu que Centos a dit "faut voir RH", et RH a dit "nous allons donner la plus grande consideration à votre demande mais pour le moment lol nope" avant que les gens de facebook aillent boire des bieres avec les bonnes personnes)

        Les réactions vis à vis de CS8 m'ont fait prendre conscience qu'il y a beaucoup plus d'admins qui n'ont pas l'air d'avoir une idée claire sur le fonctionnement d'une distrib linux que je le pensais. Par fonctionnement, je parle de comment le logiciel passe de "un tarball" à "mon serveur en prod". Si il n'y a que des correctifs de bugs, qu'il y a un CI importante, et un contrôle de ce qui est mis en place ou pas, CS8 devrait n’être que RHEL avec 2 à 3 mois d'avance, et donc meilleure pour les admins (vu qu'il n'y a plus à attendre pour les bugfixes mineurs, voir que les admins peuvent y contribuer en envoyant le correctif)

        À la place, j'ai le sentiment qu'il y a plus quelque chose qui ressemble à une envie d'avoir RHEL sans en avoir le budget pour, et qu'il y a une forme de rancune.

        • [^] # Re: Utilisation en production

          Posté par  (site web personnel) . Évalué à 5.

          Je trouve aussi qu'autour de cette annonce il y a eu beaucoup de critiques assez injustifiées ou à côté de la plaque, parmi les quelques points valides.

          Cela montre une mauvaise compréhension de comment tout cela fonctionne d'un côté, mais après je trouve que Red Hat a aussi échoué au niveau marketing pour cette annonce ce qui a accentué le problème.

          Le fait que ce soit fait peu après l'arrivée de CentOS 8, avec changement à effet immédiat pour cette version a je pense généré pas mal de stress et généré une incompréhension qui n'a pas aidé les utilisateurs à réfléchir sur les impacts et digérer l'annonce. Je pense que ça a été une erreur de l'avoir fait comme ça, avec ce timing en particulier.

          Ils auraient pu préparer ce changement pour RHEL 9 ou avant la sortie de CentOS 8 histoire d'éviter que certains se retrouvent avec des CentOS 8 sur des machines avec un changement de programme à faire en cours de route en passant à CentOS Stream ou à une autre solution. Cela aurait donné plus de temps à tout le monde d'analyser l'annonce et à Red Hat de bien expliquer son plan.

          • [^] # Re: Utilisation en production

            Posté par  (site web personnel) . Évalué à 3.

            Je pense que fondamentalement, il n'y avait aucun bon moment.

            Le fait juste au moment de la release de RHEL/Centos 8, ça aurait sans doute fait grincer des dents autant. Le faire 1 ou 2 ans avant Centos 8, en dehors d'impliquer de voyager dans le temps, aurait aussi été vu comme une trahison. Et le faire aujourd'hui pour RHEL 9 aurait été pareil que le faire pour EL 8.

            La raison donné pour le faire au moment ou ça a été annoncé, c'est parce que justement, la majorité des admins sys (comme vu par la charge sur les miroirs) n'étaient pas encore passé à EL 8.

            • [^] # Re: Utilisation en production

              Posté par  (site web personnel) . Évalué à 6.

              Le fait juste au moment de la release de RHEL/Centos 8, ça aurait sans doute fait grincer des dents autant.

              Pas sûr, puis ça aurait pu être annoncé en amont. Par exemple en laissant la branche 8 telle que prévue à l'origine, et faire l'annonce à ce moment là pour la future 9.

              Le faire 1 ou 2 ans avant Centos 8, en dehors d'impliquer de voyager dans le temps, aurait aussi été vu comme une trahison. Et le faire aujourd'hui pour RHEL 9 aurait été pareil que le faire pour EL 8.

              Je ne pense pas.
              Disons que probablement beaucoup de gens auraient quand même formulés des critiques hors sol et l'auraient mal vécu quelque soit le timing. Je n'en doute pas un seul instant.

              Mais malgré tout ça aurait retiré des arguments :

              • Les gens qui avaient déjà migré sur CentOS 8 (il y en avait, même si c'était probablement une minorité) et qui doivent réfléchir à l'impact que cela aurait pour eux, quitte à changer de crèmeries ;
              • Cela aurait donné du temps avant la sortie de RHEL 9 de réfléchir réellement à l'impact de tout ceci et de ne pas avoir un sentiment d'urgence à gérer.

              Après c'est mon point de vue quand je vois le retour de certains, il est évident que certains auraient critiqué en toute circonstance.

    • [^] # Re: Utilisation en production

      Posté par  (Mastodon) . Évalué à 10. Dernière modification le 06 novembre 2021 à 22:03.

      Concernant le modèle rolling release, mis à part quelques amateurs éclairés qui mettent à jour leurs serveurs très régulièrement, je n'ai pas vu beaucoup de grandes sociétés "orchestrer" des campagnes de mises à jour sur des parcs de centaines de serveurs de manière régulière (quand je dis régulière, ce ne serait qu'une à deux fois pas an)

      Et pour avoir mis en place des mises à jours mensuelles ou bi-mensuelles sur des parcs de >1500 serveurs à plusieurs entreprises ça me désole profondément car c'est essentiellement de l'obstruction psychologique et qu'il n'y a pas de barrière majeure. Ça s'automatise même très bien si on a un bon process qui assure par exemple d'avoir des snapshots de miroirs pour que la mise à jour effectuée en prod se fait exactement avec les mêmes versions de paquets que testés 15j avant en environnement de test, avoir une bonne gestion et connaissance des applis clusterisées, des fenêtres de maintenance bien précises pour les bascules de noeud primaires, etc.

      La plupart des admins windows le font mensuellement, un sysadmin unix/linux qui ne le fait pas ou n'en est pas capable est une honte pour la profession.

      • [^] # Re: Utilisation en production

        Posté par  . Évalué à 3.

        Tout est dit. Néanmoins, il y a beaucoup "ça marche bien donc je ne touche à rien" jusqu'au jour au disaster sans procédure vraiment prête. La prod n'a pas forcément à être bleeding edge mais les cve majeurs doivent être à minima corrigé asap.

      • [^] # Re: Utilisation en production

        Posté par  . Évalué à 1.

        La plupart des admins windows le font mensuellement, un sysadmin unix/linux qui ne le fait pas ou n'en est pas capable est une honte pour la profession.

        Des entreprise où tu as une équipe d'admin windows mais qu'un seul sysadmin linux, j'ai vu ça aussi… Entre la db oracle, le(s) site(s) web, les serveurs d'applications, on hésiterait bien deux fois avant de tout mettre à jour (qui plus est, de manière automatique). Dans les entreprises mixtes linux/windows, les trucs un peu pointus ont tendance à se trouver sous linux (sinon pourquoi avoir du linux?), et ce sont rarement des trucs évidents à automatiser/clusteriser/etc. Possible, certes comme tu dis "bonne gestion et connaissance des applis clusterisées, des fenêtres de maintenance bien précises pour les bascules de noeud primaires, etc." mais l'adminsys s'il est tout seul n'a jamais eu le temps de préparer cela pour chaque type d'application différente, et dans ce cas on appelle un contractant (comme toi si j'ai bien compris… ).

        À côté de ça, mettre-à-jour un clusteur d'Active Directory, un exchange ou un parc de desktop, cela me semble assez banale finalement, et puis ça justifie bien le salaire de deux ou trois admins windows.

        Et si tu grattes un peu, tu trouveras aussi une application critiques sous windows, et comme par hasard, elle n'est pas mise-à-jour… Et c'est soit une application hyper spécifique, ou un setup hyper customisé… Genre un apache httpd avec un cgi écrit en visualbasic qui gère la borne du parking, tu vois, ce genre de truc.

        Alors que cela ne soit pas les bonnes pratiques, ok, mais avant de parler de honte pour la profession peut-être qu'il faut essayer de comparer ce qui est comparable au niveau de l'effort-coût et des ressources (temps-homme) mises en oeuvres par la direction? Il faut bien tout comparer: 1) la complexité de l'application 2) sa criticité 3) les ressources disponibles.

        La différence d'effectifs admin win/unix peut s'expliquer assez facilement:

        Linux a longtemps été bien plus facile à mettre à jour qu'un Windows (apt-get existait bien avant qu'active directory fut une chose). Aussi l'équipe windows a un périmètre qui s'étend à tous les utilisateurs. Le jour où tous les desktop se sont retrouvés bloqués, le budget pour engager des winsys supplémentaire a subitement été débloqué. Entre temps, Windows s'est amélioré au niveau de la facilité d'administration. D'un autre côté, on n'a pas cessé de complexifier les applications qui tournent sous linux (un truc "HA" par ici, un autre truc proprio par là, etc). Il s'en suit, je pense, que cela a entrainé un certain déséquilibre dans le recrutement des équipes IT, qui n'est plus en phase avec les besoins actuels.

    • [^] # Re: Utilisation en production

      Posté par  (site web personnel) . Évalué à 3.

      Moi, j'utilise Centos Stream 8 en production (toute les machines C8, hyperviseur, site web, DNS, etc).

      Et y a pas vraiment grand chose à en dire vu que ça marche.

    • [^] # Re: Utilisation en production

      Posté par  (site web personnel, Mastodon) . Évalué à 5.

      "De fait, il est désormais inconcevable d'utiliser CentOS Stream en production."
      C'est une affirmation un peu péremptoire…

      Eh bien moi j'ai un exemple concret de la difficulté à utiliser CentOS Stream "en production".

      Je suis chercheur, et dans mon domaine (la cryo-microscopie électronique) quasiment tous les logiciels d'analyse d'images exploitent l'accélération matérielle fournie par les GPU. Ces logiciels utilisent quasiment tous CUDA, une bibliothèque scientifique propriétaire de Nvidia. Cela cause deux problèmes :

      1. Puisqu'on ne peut pas se passer de ces logiciels (ça reviendrait à renoncer à analyser les données issues de nos expériences), il faut acheter les GPU de Nvidia, alors que ce ne sont pas toujours le meilleur compromis selon les critères auxquels on attache de l'importance.
      2. Il faut utiliser le pilote propriétaire de Nvidia, car CUDA n'est bien sûr pas compatible avec le pilote libre nouveau.

      Il y a deux façons d'installer le pilote propriétaire de Nvidia :

      1. en exécutant en tant que root un binaire téléchargé depuis le site de Nvidia, ou
      2. en ajoutant le dépôt de Nvidia au gestionnaire de paquets pour ensuite installer le pilote selon la même procédure que les autres logiciels de la distribution.

      La première méthode est à éviter, pour plein de raisons, mais surtout parce que le pilote installé ainsi n'est bien sûr pas mis à jour automatiquement. Par conséquent, les mises à jour automatiques du noyau par le gestionnaire de paquets cassent systématiquement le pilote. C'est une plaie de devoir réinstaller le pilote manuellement à chaque fois qu'une mise à jour même mineure du noyau débarque.

      La seconde méthode fonctionne bien, car le gestionnaire de paquets n'installera jamais des versions du noyau et du pilote marquées comme incompatibles. Seulement, Nvidia ne fournit ces paquets pré-compilés du pilote que pour la version du noyau de la distribution RHEL stable. C'est expliqué ici. Puisque CentOS Stream a quasiment tout le temps un noyau plus récent que RHEL (par définition, puisque CentOS Stream se veut upstream par rapport à RHEL), ce paquet du pilote Nvidia n'est quasiment jamais compatible avec CentOS Stream. On se retrouve alors dans l'une des deux situations suivantes :

      1. On a réussi à installer le pilote pendant une période où le noyau de CentOS Stream était toujours à une version compatible avec le paquet du pilote. On se retrouve par contre coincé sur cette version du noyau jusqu'à la prochaine mise à jour du noyau de RHEL quand Nvidia publiera la version correspondante du paquet du pilote. Du coup, utiliser CentOS Stream n'a pas trop d'intérêt (un de ses "arguments de vente" est que les mises à jour sont plus fréquentes qu'avec RHEL).
      2. La version du noyau installée n'est pas compatible avec le paquet du pilote Nvidia. Il faut choisir entre rétrograder la version du noyau (pas vraiment recommandé en général) à la dernière version compatible avec le pilote, ou se passer du pilote jusqu'à la prochaine version du noyau compatible (comme dans la situation 1, mais dans le cas où on n'a même pas pu installer le pilote au départ), ce qui peut mettre plusieurs mois à arriver (car la prochaine mise à jour du noyau ne suffit pas, il faut aussi tomber sur une version que Nvidia accepte de supporter avec son pilote).

      Pour résumer : quand on a besoin du pilote Nvidia, CentOS Stream c'est la galère en permanence, alors que RHEL ou ses clones qui suivent strictement ses versions (Alma, Rocky et autres) "juste marchent".

      • [^] # Re: Utilisation en production

        Posté par  (site web personnel) . Évalué à -7.

        quand on a besoin du pilote Nvidia, CentOS Stream c'est la galère

        bin, suffirait de pas avoir besoin de nVidia ;-)
        Intel c'est poussif, AMD fait quelques efforts :

        https://www.reddit.com/r/Amd/comments/9vbrh4/where_is_amds_equivalent_to_cuda/
        https://www.hardware.fr/articles/678-5/amd.html
        https://stackoverflow.com/questions/7110106/amd-equivalent-of-the-cuda-driver-api

        et j'ai pas cherché longtemps sur https://duckduckgo.com/?t=ffab&q=%C3%A9quivalent+cuda+chez+amd&ia=web

        Je suis chercheur, et dans mon domaine (la cryo-microscopie électronique) quasiment tous les logiciels d'analyse d'images exploitent l'accélération matérielle fournie par les GPU.

        dommage d'être chercheur et de ne pas trouver :/ Là où la recherche est là pour expérimenter justement (voire innover).
        j'avais une image passée sur la 3bune pour illustrer, mais je ne la retrouve plus :/

        • [^] # Re: Utilisation en production

          Posté par  (site web personnel, Mastodon) . Évalué à 9.

          bin, suffirait de pas avoir besoin de nVidia ;-)

          Va expliquer ça aux gens qui développent les logiciels que j'utilise. Moi je suis biochimiste de formation et de profession, et sysadmin par nécessité (et parce que j'y prends suffisamment plaisir, quand ça marche bien, pour ne pas vouloir le laisser à d'autres). Mais après tout ça, quand il reste du temps dans la semaine ce n'est pas le code, l'algèbre linéaire et les transformées de Fourier que j'aime pratiquer comme passe-temps. :-)

          dommage d'être chercheur et de ne pas trouver :/ Là où la recherche est là pour expérimenter justement (voire innover).

          Tu préfères que je dépense tes impôts 1 comment ? En pratiquant ma spécialité qui consiste à déterminer des structures de protéines ? ce qui aide énormément à concevoir des trucs parfois utiles comme, au hasard, des vaccins ou des médicaments antiviraux pour se sortir du pétrin quand une pandémie nous tombe dessus 2. Ou bien en bidouillant CentOS Stream en espérant que ça finisse par tomber en marche pour que je puisse enfin analyser mes images ?

          Je suis d'accord avec toi que c'est important d'expérimenter. Mais une répartition des tâches est tout de même indispensable de nos jours, tant il y a de domaines complexes. Les polymathes comme Léonard de Vinci, ça n'existe quasiment plus. Est-il raisonnable d'attendre de biochimistes qu'ils soient aussi experts en informatique appliquée à l'analyse d'images ?


          1. Façon de parler. Vu que la recherche publique est si mal financée en France, j'ai pas eu la chance d'y travailler depuis ma thèse, et c'est actuellement l'argent du contribuable suédois que je gaspille. 

          2. Enfin ça, c'est quand on a un gouvernement qui veut bien y mettre les moyens

          • [^] # Re: Utilisation en production

            Posté par  (site web personnel) . Évalué à -3.

            Enfin ça, c'est quand on a un gouvernement qui veut bien y mettre les moyens.

            arf, une ministre de la santé qui s'appelle Vidal ?! j'avais loupé ça, you made my day comme on dit outre-atlantique :-)

            Ou bien en bidouillant CentOS Stream en espérant que ça finisse par tomber en marche pour que je puisse enfin analyser mes images ?

            bin les deux, vu que tu sembles impliqué : tes fournisseurs peuvent t'aider, c'est un peu à ça que sert le support ;-) sinon, à quoi bon le payer ?

            Les polymathes comme Léonard de Vinci

            merci de ne pas me prêter de prétentions ubuesques ;-)
            je suis au mieux autodidacte, même si ma prof' de réseau et celle de bases de données en école d'ingé se désolaient que je ne vienne qu'en TP et pas à leurs cours :D
            Bon le prof en info a sans doute été content que je ne vienne qu'à un seul de ses cours dans mes 3 ans d'école sup'… (j'ai posé 3 questions sur l'Ada, il n'a pas été foutu de répondre à une seule… c'était pourtant l'objet de ce cours de 3A, j'avais fait de l'Ada en 1A… pas pour rien que je n'étais jamais allé à son cours… le prof^Wmec il avait au mieux 25 personnes sur une demi-promo soit 150 pour 300, c'est dire combien il était nul :p et je ne parle pas de ses polyconchiés)

            • [^] # Re: Utilisation en production

              Posté par  (site web personnel) . Évalué à -2.

              c'est polyconchiés que vous n'avez pas compritte ?!

              Pourtant c'est connu et reconnu : https://fr.wiktionary.org/wiki/conchier

              • [^] # Re: Utilisation en production

                Posté par  (site web personnel) . Évalué à -3. Dernière modification le 09 novembre 2021 à 02:32.

                Bon ya que Mali<, Ludo<, BAud< du v4 et quelques fanfarons qui peuvent comprendre le terme, venu du T4 (migré au X2 ensuite). Nous avons passé de bons moments — j'ai fait partie des rares personnes à suivre la tournée sur la côte — même des anciens m'ont remercié d'être viendu o_O Et pourtant, je ne sais pas sortir un son d'un Piston :/

      • [^] # Re: Utilisation en production

        Posté par  (site web personnel) . Évalué à 9.

        Il y a deux façons d'installer le pilote propriétaire de Nvidia :

        Tu as oublié une méthode : EPEL avec notamment le dépôt RPMFusion, qui fournit par exemple le pilote proprio nVidia pour les dérivés de RHEL et Fedora.
        RPMFusion est de ce que j'en ai lu compatible avec CentOS Stream : https://rpmfusion.org/Configuration/

        De plus, RPMFusion fourni le paquet akmod-nvidia qui repose sur dkms ce qui permet d'adapter le module nvidia à un noyau différent sans avoir la version précompilée disponible. Il y a quelques années je m'en étais servi et ça fonctionnait bien sur Fedora donc je ne vois pas de raisons que cela ne fonctionne pas ici.

        Bref, à priori CentOS Stream semble pleinement compatible avec ton workflow.

        Sinon, l'autre objectif avec CentOS Stream est qu'il soit l'amont de RHEL, nVidia devrait en toute logique s'adapter à cette nouvelle donne pour fournir à CentOS Stream ce qu'ils fournissent à RHEL aujourd'hui. Peut être qu'ils ne le feront jamais, mais pas impossible que cela arrive. Faut que eux aussi s'adaptent à la nouvelle donne ce qui peut prendre du temps.

        • [^] # Re: Utilisation en production

          Posté par  (site web personnel, Mastodon) . Évalué à 1.

          Merci, je ne connaissais pas cette option. Les deux stations de travail que j’administre sont déjà sous Rocky, mais je note, car ça pourrait m’être utile plus tard.

          Cela dit, pour mon usage actuel je préfère le rythme de mises à jour plus conservateur de RHEL et ses clones que de CentOS Stream (il y a déjà certaines dépendances d’un programme que j’utilise qui sont trop récentes dans Rocky 8.4).

  • # CentOS, c'est fini ! Et dire que c'était mon premier amour...

    Posté par  . Évalué à 3.

    Concernant la migration vers Rocky Linux, c'est bien géré depuis la première version stable :
    https://www.tecmint.com/migrate-centos-8-to-rocky-linux/

  • # Pensez red hat.

    Posté par  . Évalué à 7.

    Comme on aime bien payer au pkus prêt d'upstream et que red hat, c'est aussi une sacré force de développement et qu'on supporte le logiciel libre, pour la prod, on a acheté les licences rhel.

    Ca n'a pas été trop cher, et la suppression des centos s'est fait sans difficultés.

    • [^] # Re: Pensez red hat.

      Posté par  (site web personnel) . Évalué à 3.

      Il est clair que si l'on se base sur le travail upstream de l'équipe RHEL, il est moralement juste de le soutenir un minimum. Une licence par profil d'installation serait une bonne métrique.

      • [^] # Re: Pensez red hat.

        Posté par  (site web personnel) . Évalué à 4.

        Sinon, il y a aussi la boite fondé par Gregory Kurtzer, CtrlIQ.

        Le site dit texto "CIQ, founded by Gregory Kurtzer, is the Official Support for Rocky Linux."

        • [^] # Re: Pensez red hat.

          Posté par  (site web personnel) . Évalué à 3.

          Bien dit, on peut la soutenir aussi ! (en retenant que le vrai upstream c'est Red Hat)

        • [^] # Re: Pensez red hat.

          Posté par  . Évalué à 2.

          je suis impatient de savoir comment il va réussir à faire du support et surtout à traiter les demandes de nouvelles fonctionnalités, de corriger des bugs… tout en étant downstream de Red Hat.
          QIC aura du support chez Red Hat et ils feront comme si ce sont eux qui ont ces besoins ?

  • # Rocky pour l'embarqué et la direction

    Posté par  (site web personnel) . Évalué à 3. Dernière modification le 07 novembre 2021 à 19:59.

    Rocky ne supporte ni secureboot ni la migration mais supporte par contre l'architecture aarch64

    Ça a été l'élément décisif pour moi : le support aarch64.
    Le confort de pouvoir utiliser la même distro sur un desktop/serveur et de l'embarqué (majoritairement des Raspberry Pi 4), avec CentOS 8 actuellement, est tel que je ne reviendrai pas en arrière.

    Puis il faut quand même prendre en compte l'historique du chef de projet et les garanties morales qu'il apporte.

  • # Secure Boot

    Posté par  . Évalué à 6.

    Rocky ne supporte ni secureboot ni la migration mais supporte par contre l'architecture aarch64

    Concernant le Secure Boot sur Rocky Linux, ça sera supporté très prochainement :
    https://docs.rockylinux.org/release_notes/8.4/#known-issues
    => "However, once the proper packages have been built and signed, another set of ISOs for Rocky Linux version 8.4 will be released with Secure Boot support available"

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.