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 bubar🦥 (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) :
Á 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 Sytoka Modon (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 claudex . Évalué à 9.
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 Sytoka Modon (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 Misc (site web personnel) . Évalué à 9.
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) .
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 claudex . Évalué à 6.
Ben du coup, CentOS et Scientific Linux était bien libre.
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 Misc (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 Sytoka Modon (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 Misc (site web personnel) . Évalué à 8. Dernière modification le 07 novembre 2021 à 22:28.
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
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.
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 BAud (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 Misc (site web personnel) . Évalué à 4.
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 BAud (site web personnel) . Évalué à 3.
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.
ah bah oui, c'est d'ailleurs indiqué sur https://distrowatch.com/dwres.php?resource=faq#phr
(bon faut lire l'anglois)
j'espère t'y revoir IRL début février prochain
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 Misc (site web personnel) . Évalué à 3.
ça va être assez dur si c'est en virtuel:
https://fosdem.org/2022/news/2021-10-22-fosdem-online-2022/
[^] # Re: Fermilab & CERN, scientific linux
Posté par claudex . Évalué à 5.
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.
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 Misc (site web personnel) . Évalué à 4.
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 barmic 🦦 . Évalué à 3.
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 claudex . É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 barmic 🦦 . É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 BAud (site web personnel) . Évalué à 0.
bin oui, Debian fonctionne aussi bien
les incompétents, yen a partout :/ (et ça ose tout, tontons flingueurs inside :D)
[^] # Re: Fermilab & CERN, scientific linux
Posté par claudex . É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 barmic 🦦 . É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.
ç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 claudex . Évalué à 4.
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.
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 barmic 🦦 . Évalué à 3.
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).
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 claudex . Évalué à 4.
Du coup, tu n'as aucune distribution utilsée en entreprise qui est supportée. Vu qu'elles ont toutes des patchs spécifiques.
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.
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 barmic 🦦 . É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.
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 claudex . Évalué à 3.
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.
Tu es jeté sur quel type de demande exactement ?
Ç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 barmic 🦦 . Évalué à 2. Dernière modification le 09 novembre 2021 à 14:13.
Par exemple sur de la conf d'iLO HPE pour en savoir un peu plus pour de l'authentification.
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 claudex . Évalué à 3.
Je pense que tu surestime beaucoup les clients standard de ces fournisseurs.
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 barmic 🦦 . Évalué à 2.
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 claudex . É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 claudex . Évalué à 3.
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 Misc (site web personnel) . Évalué à 3.
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).
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 barmic 🦦 . É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 ?
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 Misc (site web personnel) . É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.
On voit ça par exemple sur les conteneurs, comme décrit par un de mes collègues: http://crunchtools.com/5040-2/
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 barmic 🦦 . Évalué à 2.
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.
Pas qu'un seul, mais oui c'est ce que j'ai dis plusieurs fois.
Dès mon premier commentaire :
Dans mon second :
Encore dans un autre :
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 Misc (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 barmic 🦦 . É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 Misc (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 Misc (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 nsbs . É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 nsbs . É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 Lionel Schinckus . É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 Misc (site web personnel) . Évalué à 7.
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 Renault (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 Misc (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 Renault (site web personnel) . Évalué à 6.
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.
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 :
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 Psychofox (Mastodon) . Évalué à 10. Dernière modification le 06 novembre 2021 à 22:03.
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 Eh_Dis_Mwan . É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 benja . Évalué à 1.
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 Misc (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 Guillawme (site web personnel, Mastodon) . Évalué à 5.
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 :
Il y a deux façons d'installer le pilote propriétaire de Nvidia :
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 :
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 BAud (site web personnel) . Évalué à -7.
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
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 Guillawme (site web personnel, Mastodon) . Évalué à 9.
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. :-)
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 ?
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. ↩
Enfin ça, c'est quand on a un gouvernement qui veut bien y mettre les moyens. ↩
[^] # Re: Utilisation en production
Posté par BAud (site web personnel) . Évalué à -3.
arf, une ministre de la santé qui s'appelle Vidal ?! j'avais loupé ça, you made my day comme on dit outre-atlantique :-)
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 ?
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 BAud (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 BAud (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 Renault (site web personnel) . Évalué à 9.
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 Guillawme (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 JEANPOL_PARLFOR . É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 ckiller . É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 Tarnyko (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 Misc (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 Tarnyko (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 nsbs . É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 ?
[^] # Re: Pensez red hat.
Posté par Misc (site web personnel) . Évalué à 4.
En contribuant directement à Centos Stream, ou en proposant des paquets forkés, je suppose.
# Rocky pour l'embarqué et la direction
Posté par Tarnyko (site web personnel) . Évalué à 3. Dernière modification le 07 novembre 2021 à 19:59.
Ç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.
[^] # Re: Rocky pour l'embarqué et la direction
Posté par Misc (site web personnel) . Évalué à 5.
Sauf erreur de ma part, il a quitté CentOS pour des raisons non publiques:
https://blog.centos.org/2019/03/greg-kurtzer-centos-founder/
Et il a donné le projet à ce fameux individu non nommé dans l'article vers ~2004 (cf un article récent sur le poste du dit individu en question qui a quitté le board de CentOS il y a 3 semaines), donc je ne suis pas 100% sur de voir comment l'historique apporte des garanties morales :/
[^] # Re: Rocky pour l'embarqué et la direction
Posté par Tarnyko (site web personnel) . Évalué à 3.
Il a sans doute fait trop confiance au dit individu ; péché de jeunesse ;-).
[^] # Re: Rocky pour l'embarqué et la direction
Posté par Misc (site web personnel) . Évalué à 3.
Ce n'est pas les échos que j'ai eu, mais je reconnais que la source des échos est sans doute non neutre.
[^] # Re: Rocky pour l'embarqué et la direction
Posté par scpcouret . Évalué à 1.
Alma linux supporte également l'architecture aarch64.
Alma linux vous permet de tester la version 8.5 beta également, depuis qu'elle est sortie je trouve qu'il ont une excellente réactivité proche de la version oracle linux.
# Secure Boot
Posté par WhiteCat . Évalué à 6.
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"
[^] # Re: Secure Boot
Posté par Tarnyko (site web personnel) . Évalué à 2.
Très bonne nouvelle !
Faute de pouvoir le dégager ou s'en passer, il faut bien faire avec…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.