CentOS Stream 10 (nommée « Coughlan ») est la première version du projet, étiqueté « Stream » depuis sa récente réorientation par Red Hat en 2023.
D’après son éditeur, c’est « une distribution Linux sur laquelle les membres de la communauté Open Source peuvent développer des systèmes, les tester et contribuer à une distribution mise à jour en continu, en amont de Red Hat Enterprise Linux [RHEL], en coopération avec les équipes de développement Red Hat. »
Qu'est-ce que CentOS Stream ?
CentOS (pour Community Enterprise OS) Stream est une distribution qui s’intercale après Fedora et avant RHEL :
Dans les faits, c’est une RHEL 10 (basée sur Fedora 40) dans laquelle les corrections et mises à jour arrivent au fil de l’eau (rolling release) plutôt que par mises à jour mineures (point release, par ex. : RHEL 10.1, 10.2, 10.3, etc.). Attention, il ne s’agit pas pour autant d’une version beta de la prochaine RHEL (qui vient d’être rendue publique, par ailleurs) mais bien un canal en amont, mis à jour en continu, duquel seront extraites les futures versions mineures de RHEL 10 au cours de son cycle de vie.
Quelles sont les nouveautés ?
Nouvelles versions logicielles
Étant située en amont de RHEL, CentOS en reprend les grandes caractéristiques, à savoir :
- Noyau Linux 6.12
- Python 3.12
- Go 1.23
- Rust 1.82
- Valkey 7.2 (fork de Redis, déprécié suite à un changement de licence plus restrictive)
- GNOME 47 (« Denver » sorti en septembre 2024)
- DNF 4.20 & RPM 4.19
- et d’autres encore…
Suppression de X.org
À noter que le serveur d’affichage X.org n’est plus disponible, seul Wayland est supporté et XWayland servira d’appoint pour les applications n’ayant pas migré vers le nouveau protocole. Cette pratique, mise en œuvre dans Fedora à partir de la version 42, est jugée suffisamment mature et est intégrée maintenant à CentOS/RHEL 10.
Architectures supportées
Plusieurs architectures sont supportées : ARM 64 bits (ARMv8), IBM Power9, IBM Z14 et x86_64 v3. C’est le « v3 » qui interpelle ici : seuls les processeurs prenant en charge des instructions ajoutées aux processeurs Intel et AMD à partir de 2015 sont pris en charge. Cela exclut les processeurs antérieurs mais aussi les plus récents qui ne prennent pas totalement en charge toutes ces extensions (comme les processeurs Intel Atom, même les plus récents). Ce choix discutable (en termes de performance et d'obsolescence programmée) et discuté tant au niveau de sa dénomination que de son bien fondé (notamment par Linus et son tact légendaire) serait vraisemblablement repris par d'autres distributions comme Ubuntu à l’avenir.
Durée du support
En termes de durée de support cette nouvelle version recevra des mises à jour pendant 5 ans (jusqu’en 2030). Cela la place en concurrence directe avec Ubuntu LTS (supportée 5 ans par Canonical) et Debian Stable (supportée 3 ans par le projet). CentOS Stream peut aussi être comparée à Alma Linux ou Rocky Linux qui sont des forks gratuits de RHEL qui tentent de reproduire bogue pour bogue RHEL (ce que CentOS ne prétend pas faire car située en amont de RHEL). À titre de comparaison, les versions de Fedora ne sont supportées que 13 mois.
Suppression des applications de bureau
Dernier point notable : CentOS (et donc RHEL) font l’impasse sur de nombreux logiciels courants pour les ordinateurs de bureau : des paquets comme Firefox, Thunderbird ou LibreOffice ont été supprimés du dépôt principal. Les utilisateurs sont plutôt encouragés à installer ces logiciels via le dépôt communautaire EPEL (qui fait partie du projet Fedora) ou via le système universel Flatpak et son dépôt Flathub.
L’objectif est d’abord de réduire la charge de maintenance en limitant le nombre de paquets que Red Hat doit maintenir tout au long du cycle de vie de la distribution en reportant cette tâche sur les bénévoles d’EPEL et/ou sur les projets/développeurs qui éditent leurs propres binaires directement via Flathub. Ensuite, cela permet d’avoir des versions plus récentes de ces logiciels en gardant une base minimale stable.
Reste à voir si, dans la pratique, ces deux moyens s’avéreront suffisants pour compenser le faible nombre de paquets disponibles dans le dépôt de base.
Conclusion
Pour résumer : une base RHEL (orientée donc vers la stabilité) avec des correctifs qui arrivent en continu pendant 5 ans et une compatibilité avec les dépôts EPEL/Flathub. Bref, une proposition rafraîchie qui rassemble tous les ingrédients pour en faire une plate-forme de développement stable ou un système à faire tourner sur le PC familial et l’oublier pendant 5 ans sans craindre de mauvaises surprises. On est sur le même créneau que Debian Stable et Ubuntu LTS mais dans l’univers Fedora/Red Hat.
Aller plus loin
- Annonce de la sortie de CentOS Stream 10 (31 clics)
- Page des téléchargements (33 clics)
- Notes de version (14 clics)
- Commentaire à l'origine de la dépêche (21 clics)
# Une pensée émue pour les bénévoles...
Posté par Lenbootil . Évalué à 10 (+12/-0).
Ah.
Vu le prix de la licence RHEL, on pourrait (mais y'a p'têt qu'à moi que ça le fait ?) trouver cette décision (et la façon dont elle est présentée) un poil déplacée.
Et si j'étais taquin, j'ajouterais que si Red Hat se sent obligé de, hem…, "reporter" cette charge de travail sur d'autres, ça pourrait avoir un tout petit rapport avec une récente vague de licenciements dans l'entreprise, à un moment où, pourtant, ladite entreprise se porte comme un charme.
Si.
Mais ce n'est pas mon genre.
[^] # Re: Une pensée émue pour les bénévoles...
Posté par Eridor . Évalué à 4 (+3/-0).
Sans en savoir davantage, je suppute que c'est un moyen pour Red Hat de montrer que ses produits et services concernant d'abord le monde des serveurs et de l'embarqué où les logiciels de bureau ne sont pas utiles. Il est probable que le nombre de clients qui payent du support pour ces logiciels soit dérisoire et ne représente pas grand chose en terme de revenu pour l'entreprise. Je suppose que le constat doit être le même pour Canonical qui, si je ne m'abuse, fait surtout son chou gras avec leur offre pour serveurs.
Bref, "l'année du bureau Linux", c'est (toujours) pas pour demain ! :)
Après Canonical fait pareil : seuls les dépôts "Base" et "Universe" sont supportés 5 ans par l'entreprise, ce qui n'est pas le cas pour le dépôt "multiverse" qui est alimenté par la communauté de bénévoles.
Et pour aller plus loin : est-ce que le travail d'empaqueteur et mainteneur d'applications de bureau ne ferait pas doublon avec les développeurs/éditeurs qui peuvent maintenant fournir des binaires directement aux utilisateurs via Flatpak ?
C'est peut-être le pari de Red Hat (mais pour des motivations sans doute uniquement économiques)
[^] # Re: Une pensée émue pour les bénévoles...
Posté par Lenbootil . Évalué à 1 (+2/-1).
Et c'est bien dommage, étant donné que la fin du support de Windows 10 arrive à grands pas.
Mais là, on sort du monde de l'entreprise.
Je n'ai pas dit que l'herbe était plus verte ailleurs.
Personnellement, je ne suis pas fan d'Ubuntu non plus.
Peuvent. Pas "doivent".
Encore une fois, Red Hat est en train d'imposer sa vision de GNU/linux au reste du monde.
[^] # Re: Une pensée émue pour les bénévoles...
Posté par Eridor . Évalué à 6 (+5/-0).
Autant je comprends qu'on puisse ne pas apprécier ce choix, autant je ne vois pas en quoi Red Hat tente d'imposer quoi que ce soit ici.
Ils ont fait un choix, décrit dans la dépêche, pour leur distribution commerciale, c'est tout. Le projet Debian, comme tant d'autres, continue de proposer un système d'exploitation complet avec plein de paquets dans les dépôts.
Si l'utilisateur n'est pas heureux du choix de Red Hat, rien ne l'empêche de changer crémerie. Chaque projet a son approche, ses moyens propres, ses priorités et ses objectifs. Je ne vois rien d'autre ici que l' expression de la liberté donnée aux utilisateurs, propre aux logiciels libres.
[^] # Re: Une pensée émue pour les bénévoles...
Posté par Psychofox (Mastodon) . Évalué à 3 (+1/-1).
Soit dit-en passant "en reportant cette tâche sur les bénévoles d’EPEL" ce n'est pas tout à fait vrai vu que de nombreuses applis sont déjà dispo via flatpak ou d'autres plateformes comme nix ou pkgsrc.
[^] # Re: Une pensée émue pour les bénévoles...
Posté par Lenbootil . Évalué à 2 (+4/-2).
Même remarque. Le modèle "magasins (au pluriel…) d'applications" ne semble si désirable que ça à tout le monde. Et encore moins au point de l'imposer à toutes et à tous, et surtout pour de mauvaises raisons (économie de travail sur le dos des mainteneurs bénévoles ou des développeurs (bénévoles ou non) de logiciels tiers, dans le cas présent).
Après la conteneurisation, les paquets et les magasins virtuels. Dans les deux cas, plutôt que de s'appuyer sur un environnement logiciel existant, on préfère laisser les autres embarquer tout ce dont leurs logiciels ont besoin dans leurs propres bulles. Le moindre exécutable devient une enclume, et on perd ce qui fait justement la force des distribs, à savoir un ensemble logiciel léger, cohérent, facile à mettre à jour (pour les admins/utilisateurs), avec une gestion fine et transparente des dépendances.
[^] # Re: Une pensée émue pour les bénévoles...
Posté par gnumdk (site web personnel) . Évalué à 0 (+2/-4).
C'était crédible jusque là.
Autant j'entends l'argument de la légèreté (même si il vaut mieux utiliser Alpine à ce moment là) mais ça s'arrête là.
Mettre à jour ses applications sous Debian stable, c'est juste l'enfer.
En en vrai, moi qui suis en full Flatpak, ai je vraiment perdu de l'espace disque?
174 applications Flatpak installées pour 50 Gio consommés. Ce sera possiblement mieux avec des paquets mais avec beaucoup moins de flexibilité que Flatpak sur le déplacement dans l'historique du paquet en cas de régression.
[^] # Re: Une pensée émue pour les bénévoles...
Posté par Lenbootil . Évalué à 0 (+2/-2).
Ou antiX. Sur base Debian, d'ailleurs.
L'enfer ?
apt update && apt full-upgrade. Reboot si mise à jour noyal. Fin.
Serveur web + PHP + instance java + bases PostgreSQL + caches Redis.
Sous Gentoo. Les régressions et les mises à jour pénibles, c'est bon, je connais.
[^] # Re: Une pensée émue pour les bénévoles...
Posté par Letho . Évalué à 0 (+1/-2).
Ça, c'est seulement si ton application est présente dans les repos, et seulement si elle l'est à la version souhaitée. Si ce n'est pas le cas, s'il faut passer par un repo tiers, pour peu par exemple qu'une version de lib soit incompatible, ça peut rapidement devenir l'horreur.
Tu parles ici d'une utilisation serveur. Et effectivement, sur mes serveurs de production, j'essaie au plus possible de me tenir aux repos officiels.
Une utilisation desktop n'a pas les mêmes impératifs. Et en tant qu'utilisateur, comme en tant que développeur, Flatpak permet de s'affranchir du « est-ce packagé pour ma distribution ». Sur ce point, par rapport à l'existant, c'est une bénédiction.
dnf, apt et consorts restent parfait pour gérer les mises à jour du système.
[^] # Re: Une pensée émue pour les bénévoles...
Posté par Lenbootil . Évalué à 3 (+3/-0).
Dans ce cas, pourquoi choisir la branche stable de Debian ?
En desktop RPM, si on veut les versions récentes des logiciels courants, on installe une Fedora, pas une RHEL.
Problème XY. Avant d'adapter un outil manifestement inadapté, mieux vaut se demander s'il n'existe pas un autre outil directement conçu pour ses besoins.
Station multimedia, kodi + divers lecteurs (audio, images, vidéo, documents divers…), navigateur web, utilisation quotidienne. Également sous Gentoo.
PC portable, avec tous les outils courants (suite bureautique, messagerie, navigateur, logiciels de lecture et d'édition multimedias), et de quoi faire tourner des VMs "maquettes". Lui aussi sous Gentoo, et lui aussi utilisé au quotidien.
Zéro Flatpak, Snap, Nix, et j'en passe. Et pourtant, dans les deux cas, il y a des logiciels installés depuis des overlays, ou hors dépôts, à partir des sources. L'avantage de Gentoo, là-dessus, c'est que les outils pour le faire sont installés par défaut. Et le passage par la case compilation, c'est long, mais ça évite de devoir installer trouze versions (avec les problèmes de sécurité afférents) de la même bibliothèque.
Je ne cherche pas ici à faire de la propagande pour une ou plusieurs distribs en particulier. J'ai juste décidé d'utiliser celles qui correspondent le mieux à mes besoins.
[^] # Re: Une pensée émue pour les bénévoles...
Posté par Jean Gabes (site web personnel) . Évalué à 2 (+0/-0).
Le problème vient quand tu dois livrer son logiciel à différents clients qui ont des systèmes et des installations différentes. Là se placer au sein de la distribution devient un véritable enfer car tu dois refaire ton travail d'intégration X fois, et c'est une très grosse perte de temps au final, surtout que tous son bien différents.
[^] # Re: Une pensée émue pour les bénévoles...
Posté par Lenbootil . Évalué à 4 (+4/-0).
L'intégration d'un logiciel dans un environnement précontraint, c'est justement le boulot des intégrateurs et des intégratrices.
Et là, on arrive à un autre problème de l'informatique en entreprise aujourd'hui : pour aller toujours plus vite, et en payant toujours moins cher, on a réduit la place de l'intégration, et on a inventé les devops.
Je sais, je sais, je suis devenu un vieux con.
[^] # Re: Une pensée émue pour les bénévoles...
Posté par Letho . Évalué à 1 (+2/-2).
Parce qu'on peut vouloir une base système d'une stabilité remarquable et des logiciels récents. C'est tout l'intérêt de la séparation système / applications utilisateur.
C'est discutable. Je suis sous Fedora sur mon PC perso, et je n'ai aucun problème à faire une mise à niveau majeure tous les six mois. Tout n'est toutefois pas disponible dans les repos, ni à jour, et je privilégie généralement les Flatpak fournis directement par les projets upstream.
J'ai également une équipe de dev à gérer. Je songe sérieusement à les passer sous CentOS Stream 10, voire une Alma Linux 10 ; une base système stable, des environnements de dev containerisés, et Flatpak pour le reste.
Je ne suis pas d'accord avec le « manifestement inadapté ». Je suis sous Linux depuis la RedHat 5.2. Je suis passé par Slackware, Mandrake, Gentoo (que j'ai adorée), Foresight, Ubuntu, Debian, Fedora, Arch et d'autres. La difficulté à installer un logiciel en-dehors du cadre prévu par la distribution a toujours été une plaie.
C'est vrai pour l'utilisateur, qui veut pouvoir utiliser la dernière version de son logiciel fétiche sans avoir à se demander si oui ou non elle est disponible pour son système, comme pour le développeur, qui n'a pas envie d'être tributaire des process de packaging des N distributions existantes, et encore moins de devoir tout se farcir lui-même.
Une solution pertinente pour cela, c'est de se mettre d'accord sur un format cross-distribution de packaging d'applications. C'est, entre autres choses, ce que propose Flatpak. Et je trouve parfaitement pertinent de le coupler avec une distribution offrant une base système stable.
Et je le comprends parfaitement. Gentoo, c'est super cool. Ma conjointe, elle, veut juste cliquer sur « installer Spotify ». Comme sur son téléphone.
Encore une fois, je parle ici plutôt d'utilisation desktop. Et je réagissais également à ce que tu disais quelques commentaires plus haut sur les magasins d'application. C'est à nuancer pour une utilisation serveur, bien que j'ajoute parfois des repos upstream sur mes AlmaLinux (notamment pour Docker).
[^] # Re: Une pensée émue pour les bénévoles...
Posté par Lenbootil . Évalué à 2 (+2/-0). Dernière modification le 20 décembre 2024 à 18:05.
C'est pas faux.
Cela dit, je vais faire un gros raccourci à la truelle, mais je vois la séparation système/applis comme une Windowsification. La différence étant que, pour le moment, le système est suffisamment protégé des applications pour rester stable. Vu l'évolution toujours surpenante de systemd (tiens, en parlant de trucs plus ou moins imposés par Red Hat…), ça pourrait ne pas durer.
Ça ne me rajeunit pas non plus, tout ça.
La difficulté d'installation dépend aussi du logiciel et de la façon dont il a été développé, et, pour certains logiciels, ne dépend pas de la distrib choisie, on est d'accord là-dessus.
En tant qu'utilisateur, pour des tests ou une utilisation ponctuelle, je passe par des VMs. Ça pose d'autres problèmes, mais ça résout celui de la compatibilité. Et si c'est pour une utilisation pérenne, n'ayant aucun logiciel "fétiche", je vois les choses différemment : soit ça s'installe et ça fonctionne, soit j'en trouve un autre. Soit, au pire, je scripte.
En tant qu'admin système/sécurité, la méthode conteneurs, c'est aussi sûr que le BYOD : quand on ne maîtrise plus rien, la question n'est pas de savoir si on va se faire poutrer, mais quand.
Pour les devs, n'ayant qu'une vision très partielle des relations entretenues avec les équipes de maintenance des distribs et des contraintes que ça impose, je ne peux que supposer que tu as raison, et je comprends tout-à-fait ce point de vue.
Il est là, le problème.
La mienne a trouvé la commande magique pour que tout fonctionne : "CHÉÉÉÉÉÉRRRIIIIII !!!!!"
(attention, le nombre de points d'exclamation est important. Une erreur pour engendrer des problèmes de latences plus ou moins élevées :) )
Cela dit, pour son PC et ses besoins, Gentoo n'était pas la distrib la plus adaptée. Elle arrive à se débrouiller avec une LMDE, et l'admin est content qu'elle utilise un système stable, léger, et facile à entretenir.
Je comprends.
Docker pour les serveurs, Flatpak pour les stations… Même principe, pour deux utilités différentes ?
[^] # Re: Une pensée émue pour les bénévoles...
Posté par gnumdk (site web personnel) . Évalué à 3 (+1/-0).
Je peux aussi me placer du point de vue du développeur, si tu utilises mon paquet Flatpak que je maintiens sur Flathub, j'ai 100% confiance dans ton rapport de bug.
Si tu es sous Debian Stable, déjà je fronce les sourcils. Si tu es sous ArchLinux, vu le nombre de fois où Arch a poussé des version de développement suite à une boulette d'un packageur, je fronce les sourcils :)
Et si tu es sous Gentoo? J'ai presque envie de t'envoyer un WONTFIX tant que tu n'a pas un patch à me proposer vu que j'ai aucune idée des options de builds de ton OS et que le bug peut être n'importe où.
[^] # Re: Une pensée émue pour les bénévoles...
Posté par Eridor . Évalué à 3 (+2/-0).
Il faut lire la phrase jusqu'au bout :
Le reste de ta remarque concernant d'autres solutions reste pertinent. EPEL est juste le dépôt supplémentaire quasi-incontournable pou RHEL et dérivés quand on veut enrichir le système de base qui est; il faut bien l'admettre, radin en applications préinstallées, souvent dépassées.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.