Comment acheter une souscription Red Hat

Le modèle RedHat

C’est sur cette philosophie que la société Red Hat repose.

En tant que partenaire d’ingénierie multidisciplinaire fort de relations collaboratives, elle a développé Red Hat Enterprise Linux, la plate-forme n°1 pour les charges de travail d’entreprise.

Innovation

Le Projet Fedora

Red Hat est à l’origine, d’une part, d’une distribution, fruit d’un travail collaboratif et axée sur les innovations (le Projet Fedora) et, d’autre part, d’une plate-forme d’entreprise axée sur la stabilité (Red Hat Enterprise Linux).

Cette approche permet d’équilibrer la tension dynamique entre innovation et stabilité. Le Projet Fedora (fedoraproject.org) désigne une distribution ouverte collaborative dédiée à l’innovation et au développement.

Une nouvelle version de Fedora est disponible environ tous les six mois, et chaque version de Fedora intègre le noyau Linux le plus récent ainsi que les principaux paquetages. La mission de Fedora est de promouvoir le développement et l’amélioration de logiciels Linux.

Citons à ce titre la page d’accueil du Projet Fedora : Fedora est un système d’exploitation basé sur Linux servant de vitrine aux logiciels libres les plus récents. Fedora est libre : tout le monde peut l’utiliser, le modifier et le distribuer. Il est construit de par le monde par des personnes regroupées autour d’une communauté : le Projet Fedora.

Le Projet Fedora est un projet ouvert, tout le monde peut participer.

Le Projet Fedora est la principale source de développement du nouveau code de Red Hat. Le cycle de développement habituel est le suivant : une fonctionnalité est développée, puis intégrée en amont (voir la section consacrée au suivi en amont), incluse dans Fedora, puis dans la version appropriée de Red Hat Enterprise Linux.

La vraie force du Projet Fedora vient d’une source surprenante. En effet, Fedora n’est pas un projet contrôlé par Red Hat. D’autres sociétés ont essayé de mettre en œuvre des projets communautaires, mais sans grand succès.

Généralement, elles souhaitent garder la main mise sur le projet et ses contributions. Les personnes extérieures à l’entreprise rechignent à contribuer. La communauté peine souvent à trouver son essor.

Le Projet Fedora, en revanche, est une organisation indépendante, dotée de son propre conseil d’administration. Red Hat est son plus grand sponsor et emploie des informaticiens qui travaillent directement sur des projets Fedora.

En aucun cas, Red Hat ne contrôle ce projet. Au contraire, elle travaille en étroite collaboration avec l’équipe du Projet Fedora et sa communauté. Grâce à cette coopération, elle a su impulser un projet sain et une communauté active.

Red Hat, en tant que partenaire et contributeur au Projet Fedora, récolte les fruits de cette relation qui profite aussi bien à Red Hat qu’à la communauté du Projet Fedora.

Comme c’est souvent le cas d’une approche communautaire open source, Red Hat a très largement bénéficié de n’avoir pas gardé le contrôle et de travailler avec une vaste communauté.

La communauté Fedora a fait maintes fois la preuve qu’elle était aux avant-postes en matière d’innovations technologiques tout en mettant au service de tous un système d’exploitation de grande qualité. Et qui en tire parti ? Red Hat, les clients de Red Hat et les partenaires de Red Hat.

Contributions de Red Hat

Un élément essentiel de ce mode de fonctionnement sont les contributions de Red Hat à l’écosystème Linux, tant sur le plan des contributions elles-mêmes que sur la façon dont elles sont mises en œuvre.

Red Hat a pris l’engagement de fournir des logiciels sous licence open source. Parfois, cela implique de racheter un éditeur de logiciels propriétaires, logiciels qui seront ensuite fournit dans le cadre d’une licence open source.

Dans d’autres cas, il peut arriver qu’un logiciel intègre des technologies disponibles sous licences propriétaires. Red Hat réalise un travail considérable pour pouvoir extraire une version open source de ce type de logiciel.

Red Hat est un bon citoyen de la communauté open source. Comme nous l’avons déjà indiqué, l’ensemble du code doit être accepté en amont avant qu’il puisse être intégré à Red Hat Enterprise Linux.

Le développement est réalisé au vu et au su de tous et ce n’est qu’une fois que le code a été accepté par les mainteneurs amont qu’il est inclus dans un produit Red Hat. Red Hat joint véritablement le geste à la parole. Pour Red Hat, l’open source est une philosophie, et non un buzzword.

Le développement étant ouvert, il est normal que Red Hat travaille en étroite collaboration avec d’autres sociétés. Red Hat coopère avec des acteurs majeurs, tel qu’Intel, AMD, IBM, HP et Dell sur une large gamme de projets d’intérêt mutuel.

Par exemple, Red Hat travaille avec Intel et AMD sur la norme ACPI. Il s’agit d’une spécification d’interface matérielle visant à limiter la consommation d’énergie des processeurs.

La spécification inclut divers mécanismes, tels que la possibilité d’échanger à chaud un processeur, changer en temps réel la fréquence d’un processeur ou placer un processeur dans le mode veille approprié lorsqu’il n’est pas sollicité. L’interface ACPI ne peut être opérationnelle que si les fabricants l’intègrent à leur matériel.

Le système d’exploitation doit ensuite être modifié pour que les fonctionnalités ACPI puissent être exploitées. Ici, ces modifications impliquent un travail conséquent au niveau des planificateurs système et d’autres sous-systèmes.

Les constructeurs, tels qu’IBM, HP et Dell, sont eux-aussi amenés à prendre part au processus. En effet, ils doivent décider comment la gestion de l’alimentation doit être prise en charge par les systèmes et le BIOS.

Les systèmes, bien que reposant sur le même processeur, peuvent présenter d’immenses différences. C’est pour cette raison que les constructeurs doivent travailler en collaboration.

Enfin, la spécification ne peut être mise en œuvre que par le biais de nouveaux outils de contrôle de la gestion de l’alimentation. Ces outils doivent répondre à tous les scénarios d’utilisation : un utilisateur d’ordinateur portable configurera son système pour limiter au maximum la consommation d’énergie afin d’augmenter la durée de vie de la batterie.

A contrario, une société de bourse devra, quant à elle, exploiter ses systèmes à plein régime pour limiter le temps de latence.

Un autre exemple est la gestion de l’alimentation. Celle-ci ne peut progresser qu’au travers d’une solide coopération inter-entreprises pour développer et commercialiser des produits éco-énergétiques.

Il ne peut s’agir d’un effort ad-hoc, mais d’un effort continu qui implique les fabricants de processeurs (ajout de fonctionnalités de gestion de l’alimentation), les fabricants de matériel (conception de nouveaux systèmes) et les développeurs du noyau Linux. Une des avancées les plus significatives dont a fait l’objet le système d’exploitation est le noyau tickless, autrement dit un noyau sans cycle d’horloge.

Une nouveauté de Red Hat Enterprise Linux 6 à laquelle Red Hat a activement pris part, le noyau tickless révolutionne le fonctionnement du système d’exploitation. Auparavant, le noyau se réactivait des centaines, voire des milliers de fois par seconde (en fonction des cycles de l’horloge interne) pour vérifier s’il devait intervenir ou non.

Le noyau tickless est quant à lui piloté par des interruptions. En d’autres termes, le système reste en veille tant qu’il n’est pas sollicité. Comme le mode veille est peu gourmand en énergie, plus un système est en veille, plus les économies d’énergie sont grandes.

Le noyau tickless n’a pu voir le jour qu’au prix de changements massifs à plusieurs sous- systèmes Linux, une coopération étroite avec de nombreux fabricants et des tests poussés.

Les utilitaires système et applications basés sur les cycles d’horloge, ont dû être modifiés pour pouvoir être pilotés par les interruptions. Heureusement, cette initiative a bénéficié de l’appui de l’ensemble de la communauté Linux.

Au lieu qu’une société teste le matériel et les applications, détecte les bogues et le résolve, ce travail a été partagé par des milliers de personnes à travers le monde entier. Contrairement à un système d’exploitation commercial, qui ne voit le jour que lorsque tout est fin prêt, les membres de la communauté ont pu travailler sous Linux et le tester au cours de toutes les phases du développement du noyau tickless.

Le résultat final peut être considéré comme une révolution qui procure des avantages substantiels et qui n’a pratiquement causé aucun problème.

Notez les avantages offerts par le développement ouvert basé sur la coopération. Les fabricants peuvent désormais commercialiser des processeurs dotés non seulement de nouvelles fonctionnalités, mais d’une interface commune pour celles-ci.

Cette interface commune permet d’innover en matière d’implémentation tout en facilitant le travail des fabricants de matériel et éditeurs de logiciels. Les fabricants de matériel peuvent tirer parti de ces nouvelles caractéristiques en les intégrant à leurs systèmes tout en s’assurant qu’elles seront prises en charge par le système d’exploitation.

Quant aux éditeurs, ils peuvent tirer parti des nouvelles caractéristiques que présentent les processeurs et les systèmes en vue de les exploiter pleinement.

Cette coopération réduit les efforts et les coûts engagés par chaque partie prenante et favorise la collaboration. En résultent des produits de grande qualité développés à un coût moindre.

Après tout, Red Hat est le premier contributeur au noyau Linux. Le dernier rapport de The Linux Foundation, intitulé Linux Kernel Development: How Fast it is Going, Who is Doing It, What They are Doing, and Who is Sponsoring It (linuxfoundation.org/publications), montre que la contribution de Red Hat pour l’ensemble des changements apportés au noyau s’élève à plus de 12 %, loin devant le deuxième contributeur (8 %).

Ces chiffres démontrent clairement l’engagement de Red Hat vis-à-vis du développement open source. Red Hat voit aussi les choses à long terme. Trouver une solution rapidement peut procurer une grande satisfaction, mais est-ce vraiment un objectif ? Ne vaut-il pas mieux essayer de prendre le temps et de se donner les moyens ?

Un exemple qui illustre ce propos est le projet Linux temps réel, dont Red Hat est le plus grand contributeur.

Un système temps réel est un système capable de terminer une tâche dans le délai imparti1. L’objectif est d’éviter d’interrompre une tâche avant qu’elle ne se termine : un défi majeur pour tout système multi-usage, multi-tâche, multi-utilisateur et multi-processeur.

La mise en œuvre du temps réel dans Linux a nécessité la modification de centaines de modules répartis dans des dizaines de sous-systèmes. Les développeurs travaillant sur ce projet s’y sont attelés et sont parvenus à mettre au point un système Linux temps réel opérationnel.

Des dizaines de milliers de lignes de code ont fait l’objet de changements. Nombre de ces changements étaient invasifs. En d’autres termes, ils auraient pu avoir un impact sensible sur un système, en modifier le comportement et provoquer d’autres effets secondaires.

C’est pourquoi ces changements ne peuvent être envisagés que s’ils sont largement justifiés. Ils font l’objet d’analyses et de tests poussés et sont validés avec la plus grande attention. La personne ou le groupe qui propose des changements invasifs doit être capable de convaincre ses pairs que les avantages surpassent le risque et les coûts engendrés.

En outre, quelques-uns des correctifs mis au point par l’équipe Linux risquaient de modifier le comportement fondamental de Linux, ce qui ne présentait aucun avantage pour la majorité des utilisateurs de Linux.

Et pourtant, l’implémentation de ces changements dans le noyau Linux offrait de réels avantages. Les patchs concernant le temps réel ont malgré tout été gérés à l’écart du noyau. Il a fallu intégrer ces changements dans chaque nouvelle version du noyau.

Si les changements avaient été inclus d’emblée dans le noyau standard, le travail d’intégration aurait été plus rapide, mais la stabilité n’aurait pas été assurée. Les développeurs dédiés à Linux temps réel ont entrepris un programme de cinq ans pour intégrer ces changements à Linux. Ils ont d’abord identifié ceux qui profiteraient le plus aux utilisateurs Linux.

Une centaine de changements, par exemple, aurait affecté une grande partie d’une seule version du noyau. Toutefois, en ciblant une dizaine de changements dans chaque version du noyau (et il en existe trois à quatre par an), l’intégration d’une centaine de changements a pris plus de trois ans.

L’intégration des changements par incrément est le mode de fonctionnement que la communauté Linux a choisi d’adopter. Les développeurs de l’équipe Linux temps réel ont également identifié les changements qui ne devaient pas faire partie du noyau principal. Ils ont ensuite œuvré pour que ces changements soient aussi faciles que possible à intégrer, en vue de réduire le travail nécessaire pour harmoniser les noyaux.

Ce processus a permis d’intégrer une partie des changements au noyau Linux principal dont ont pu tirer parti les utilisateurs généraux et d’intégrer le reste rapidement. Les responsables du programme Linux temps réel ont pu mettre en œuvre les changements qu’ils souhaitaient sans affecter les utilisateurs.

Comme les changements font désormais partie intégrante du noyau Linux principal, c’est toute la communauté Linux qui peut tester, prendre en charge et améliorer ce composant. Rien n’à voir avec ce qu’aurait pu fournir l’équipe temps réel seule.

L’exemple que nous venons de présenter n’est qu’un des nombreux avantages qu’offre le modèle de développement open source. Ce modèle, allié avec patience et pugnacité, est extrêmement positif.

Il illustre également la vue à long terme de Red Hat. En effet, Red Hat investit au long cours et travaille avec ses partenaires pour fournir un nouveau produit qui bénéficie à ses clients.

Suivi amont

L’autre élément fondamental du modèle d’innovation de Red Hat est la notion de suivi amont2. Dans le cadre du noyau Linux, cela signifie que Red Hat utilise le code issu de kernel. org. Red Hat n’ajoute aucune fonctionnalité en dehors du processus de développement public.

Toutes les nouvelles fonctionnalités développées par Red Hat sont d’abord soumises et validées par les mainteneurs du noyau (au final Linus Torvalds), puis intégrées à Red Hat Enterprise Linux. Red Hat Enterprise Linux demeure entièrement compatible avec le code Linux officiel, ce qui simplifie grandement le support Red Hat Enterprise Linux.

C’est aussi le gage que les clients de Red Hat ne sont pas dépendants de fonctionnalités propres à Red Hat. Red Hat tire automatiquement parti de tous les contributeurs au noyau Linux ainsi que de tous les paquetages intermédiaires. Et pour cela, Red Hat s’y emploie de deux manières.

Tout d’abord, via le Projet Fedora. Une nouvelle version Fedora sort environ tous les six mois. Chaque version de Fedora inclut la dernière version du noyau Linux ainsi que la dernière version de nombreux paquetages importants.

Grâce à cela, Fedora est une plate-forme de développement idéale, car elle est en lien étroit avec les développements en amont, fournit la base du développement des nouvelles fonctionnalités et constitue une boucle de feedback rapide.

Toutefois, de nombreuses sociétés estiment que Fedora change trop rapidement pour les environnements d’entreprise. C’est pour cette raison que Red Hat propose Red Hat Enterprise Linux uniquement en deux versions : majeures et mineures.

Les versions majeures sortent tous les deux à trois ans. Chacune d’elle est suivie pendant au minimum sept ans. Les versions mineures sortent environ tous les six mois pendant le cycle de vie d’une version majeure et leur développement est encadré par des règles strictes qui stipulent ce qui peut être modifié ou non.

Instantané, intégration et stabilisation

À l’instar des versions Fedora, chaque version majeure de Red Hat Enterprise Linux comporte un nouveau noyau et une nouvelle version de la plupart des paquetages. Il peut s’agir de changements importants apportés aux bibliothèques et interfaces, fichiers de configuration, structures des données sur disque et du noyau, etc.

La première étape d’une version majeure de Red Hat Enterprise Linux commence par la prise d’un instantané du noyau et des dernières versions stables des milliers de paquetages qui forment une distribution Linux.

La phase suivante se compose des processus d’intégration et de stabilisation. Elle requiert des mois de travail d’ingénierie qui vise à :

  • Vérifier que tous les paquetages fonctionnent ensemble
  • Rechercher et corriger les bogues
  • Créer les fichiers de configuration appropriés pour Red Hat Enterprise Linux,
  • Réaliser des tests sur un large panel de systèmes et de périphériques,
  • Configurer les paramètres système,
  • Vérifier que le produit est conforme à l’identité de Red Hat Enterprise Linux.

Les partenaires de Red Hat prennent part à cette phase pour s’assurer que la plate-forme répond à leurs besoins et à ceux de leurs clients.

Un exemple est la prise en charge du matériel. La grande majorité des développeurs Linux travaillant sur de petits systèmes, Linux est optimisé pour ces systèmes. (Un petit système de nos jours est un ordinateur tout de même doté de 4 à 16 processeurs et de 8 à 32 Go de mémoire.)

Les serveurs modernes sont bien plus puissants et il est nécessaire de vérifier que Linux fonctionne correctement sur ces systèmes.

Red Hat a considérablement investi pour tester et configurer ses produits sur de gros systèmes. La société en possède une douzaine dans ses laboratoires : systèmes équipés d’au moins 64 processeurs et 100 Go de mémoire, réseaux SAN ou réseaux Ethernet et Infiniband Gbit/s.

Red Hat recourt à des suites de tests automatisées qui incluent les applications d’entreprise les plus répandues. La société compte aussi des experts en conception et en configuration de gros systèmes. Elle a tissé des liens étroits avec des entreprises, telles que IBM, HP, Dell, Intel, AMD, SGI et d’autres, pour vérifier que toute nouvelle version de Red Hat Enterprise Linux est capable d’exploiter leurs systèmes et technologies.

Outre le suivi amont que nous avons évoqué, la phase d’intégration et stabilisation est le secteur dans lequel Red Hat investit le plus en termes d’ingénierie. Il s’agit aussi de la phase la plus importante, car elle est ce qui distingue le plus Red Hat Enterprise Linux des autres systèmes d’exploitation Linux.

Parmi les héros méconnus de Red Hat, une équipe d’ingénieurs chargée des performances repousse les limites des tests, tant matériels que logiciels, en s’appuyant sur de nombreux benchmarks et charges de travail applicatives.

Ce n’est qu’en exécutant des charges de travail lourdes et complexes qu’il est possible de mettre à jour les problèmes de performances, tout particulièrement avec les systèmes actuels. Des facteurs, tels que le nombre d’UC élevé, les quantités astronomiques de mémoire, les goulots d’étranglement des communications, la bande passante et la latence des E/S, les sous-systèmes de stockage, la virtualisation, l’architecture système et les paramètres système, doivent tous être pris en compte pour les nouveaux systèmes et nouvelles versions de Red Hat Enterprise Linux.

L’équipe d’ingénieurs chargée des performances chez Red Hat excelle dans la recherche et la résolution des problèmes de performances, avant qu’ils n’affectent les clients.

Si un client rencontre un problème de performance, l’équipe a toute l’expérience requise pour le répliquer, et, via le processus d’assistance fournie dans le cadre d’un abonnement Red Hat Enterprise Linux, peut proposer des suggestions ou travailler avec l’équipe d’ingénieurs de Red Hat pour le résoudre.

Ce travail d’intégration et d’optimisation des performances est beaucoup plus important qu’il n’y paraît. Prenons l’exemple d’un serveur de base de données. Supposons qu’il ait fonctionné correctement pendant des années.

Les performances se sont dégradées à en devenir inacceptables en raison de l’augmentation du volume de données et du nombre d’utilisateur. La décision est prise de le remplacer par un serveur doté de deux fois plus de processeurs et de quatre fois plus de mémoire.

Malgré cela, le nouveau serveur est plus lent que l’ancien. De nombreuses possibilités sont envisageables allant d’une mauvaise configuration du matériel au changement d’algorithmes fondamentaux du système d’exploitation en raison de l’augmentation de la mémoire et du nombre de processeurs. Ce problème n’est pas si anodin, quel que soit le système d’exploitation.

La seule façon de le résoudre est d’exécuter les charges de travail sur de nouveaux systèmes, rechercher les problèmes de performances et d’évolutivité, puis de les corriger. Nul besoin de préciser que cette démarche exige d’importants investissements et un grand savoir-faire de la part de l’éditeur du système d’exploitation.

C’est là que se démarque Red Hat Enterprise Linux, des distributions pour ordinateur de bureau et/ou communautaires.

Une grande partie du travail de création d’une plate-forme d’entreprise se fait dans l’ombre, mais est absolument nécessaire. En effet, il faut tester, configurer, corriger le logiciel sur un large panel de matériels, configurations et applications.

Jour après jour, il faut vérifier le moindre détail et s’assurer que les « pièces mobiles » fonctionnent ensemble. Un travail d’ampleur nécessitant des personnes, des processus, des systèmes et une infrastructure. Et surtout, ce travail ne peut s’accomplir qu’avec les ressources de l’entreprise et la volonté de bien faire les choses.

Ce travail ne fait jamais l’objet de communiqués de presse, ni n’est mis en valeur dans des documents marketing. De nombreux observateurs le trouvent plutôt ennuyeux. S’il est correctement réalisé, c’est le résultat qui est ennuyeux.

Des systèmes qui fonctionnent. Un comportement prévisible. Pas de panne sensationnelle. Et des administrateurs système qui peuvent dormir sur leurs deux oreilles !

Comme tout un chacun a accès au code Linux, il peut être difficile de reconnaître les entreprises capables de fournir ce travail et celles qui se cantonnent à recycler le travail des autres. Et pourtant, il existe de bons indices.

Premièrement, consultez l’historique des sources (commits) du noyau Linux et des principaux paquetages. Il est facile de déterminer qui contribue à la maintenance et au développement de Linux.

Consultez également le type de correctifs soumis. Si ceux-ci incluent de nouvelles fonctionnalités, concernent de grands systèmes (grande capacité de mémoire et nombre important de processeurs), portent sur une infrastructure commune, l’engagement de l’entreprise envers Linux est réel.

Au contraire, si l’entreprise propose peu de correctifs, ne travaille pas sur de grands systèmes ou si elle ne se concentre que sur les fonctionnalités qui l’intéressent directement, il est normal d’avoir des doutes.

Deuxièmement, évaluez la relation de travail entre la société et les acteurs du monde technologique. Travaille t-elle avec d’autres entreprises pour s’assurer que le nouveau matériel est pris en charge dès sa commercialisation ? Se procure-t-elle les derniers systèmes ? Reçoit-elle des feuilles de route et des mises à jour régulières ? Ses partenaires principaux missionnent-ils des ingénieurs dans ses locaux pour faciliter la coordination ?

Troisièmement, prêtez attention au processus de qualification et de certification du matériel. La société a-t-elle établie un programme permettant de tester et de qualifier les systèmes qu’elle prend en charge ou s’appuie-t-elle sur des certifications externes ? Les systèmes sont- ils véritablement testés ou la société ne se base-t-elle que sur des hypothèses ? Combien de systèmes ont été certifiés ? Quand le système de certification a-t-il été établi ?

Quatrièmement, la société s’est-elle engagée auprès de la communauté ou souhaite-t-elle uniquement apporter des nouveautés et des changements de manière ponctuelle ? Croit-elle en les avantages à long terme de la compatibilité avec la communauté en amont ou est-elle prête à apporter des changements incompatibles pour atteindre des objectifs à court terme ?

Support

Au terme des phases de prise d’instantané, d’intégration et de stabilisation, la nouvelle version de Red Hat Enterprise Linux est disponible. À ce stade, la version majeure de Red Hat Enterprise Linux commence à bifurquer du développement aval.

Plus précisément, c’est le développement aval qui se poursuit et bifurque de Red Hat Enterprise Linux. Le noyau Linux et les logiciels associés continuent leur évolution, la version de Red Hat Enterprise Linux reste stable.

Versions majeures

Cela signifie que chaque version majeure de Red Hat Enterprise Linux offre une plate-forme stable et cohérente pour exécuter des applications. Dès lors qu’une version majeure est disponible, Red Hat s’engage à assurer la stabilité des interfaces API, ABI et KABI ainsi que de l’ensemble des paquetages pendant toute la durée de vie de la version.

Cela signifie également que les mises à jour contenues dans les versions mineures de Red Hat Enterprise Linux n’auront pas d’incidence sur les applications et les outils. En fait, Red Hat se donne beaucoup de mal pour que les versions mineures n’entraînent aucun dysfonctionnement des applications. Tout problème éventuel est considéré comme un bogue qui doit être corrigé.

Versions mineures

Les versions majeures de Red Hat Enterprise Linux sont mises à jour régulièrement. On parle alors de versions mineures. Celles-ci sortent environ tous les six mois. Chaque version majeure fait l’objet de plusieurs versions mineures.

Les versions mineures de Red Hat Enterprise Linux sont le vecteur de nouvelles fonctionnalités, correctifs de bogues et prises en charge matérielles.

Le code aval est alors rétroporté (ou backporté). Toutes les modifications sont soigneusement examinées pour vérifier qu’elles sont compatibles avec la version majeure et n’affectent pas les applications. Les nouvelles fonctionnalités sont généralement ajoutées dans les deux ans qui suivent la sortie d’une version majeure de Red Hat Enterprise Linux.

Elles sont d’abord intégrées en aval, puis rétroportées. La plupart d’entre elles sont intégrées à une version Fedora, puis testées dans celle-ci avant d’être incluses dans Red Hat Enterprise Linux. Fedora constitue un environnement de développement et un banc d’essai de choix des nouvelles fonctionnalités avant qu’elles ne soient incorporées à Red Hat Enterprise Linux.

Ce processus permet d’améliorer sensiblement la qualité et la stabilité de Red Hat Enterprise Linux. Red Hat déploie beaucoup d’efforts pour s’assurer que les nouvelles versions sont compatibles. Les fonctionnalités sont des ajouts au code existant (plutôt que des modifications).

La phase dite de hardware enablement ou médiation avec le matériel consiste à assurer le bon fonctionnement des nouveaux processeurs et des périphériques, tels que les contrôleurs réseau, de stockage, graphiques, entre autres.

La plupart des nouveaux périphériques sont pris en charge via l’ajout de pilotes ou l’extension de pilotes existants. Les nouveaux processeurs requièrent parfois des modifications du noyau qui touchent à la gestion de la mémoire, des ressources, de l’alimentation ou bien encore à l’affinité de processeurs ou à la topologie système.

Lorsque les processeurs implémentent de nouvelles instructions, il est parfois nécessaire de modifier le compilateur gcc et toolchain associé. Cette phase doit répondre à deux objectifs : prendre en charge les nouveaux périphériques et ne pas nuire aux périphériques et applications existants.

Red Hat s’y attelle principalement au cours des quatre premières années du cycle de vie d’une version majeure. La plupart des modifications apportées à chaque version mineure sont des correctifs.

Les bogues critiques sont rapidement corrigés par le biais d’errata asynchrones alors que la majorité des correctifs sont inclus dans la version mineure suivante. Chaque version mineure fait l’objet de tests poussés, comprenant l’analyse de l’interaction possible entre les différents correctifs.