Découvrez les coulisses de Red Hat Enterprise Linux 10 (partie 4)

Cette série s'intéresse aux équipes et à la planification qui ont contribué à la création de Red Hat Enterprise Linux 10. Des premières étapes conceptuelles jusqu'au lancement lors du Red Hat Summit 2025, nous partagerons des témoignages sur les coulisses de RHEL 10.

Partie 1 | Partie 2 | Partie 3

Dans notre précédent volet sur la création de Red Hat Enterprise Linux (RHEL) 10, nous nous sommes penchés sur le processus de test et sur la manière dont les principales fonctions (et leurs histoires) ont pris forme. Dans cette quatrième partie, nous verrons comment nos équipes ont peaufiné ces histoires alors qu'elles apportaient la touche finale aux diverses fonctions avant le gel du code.

2025 (6 mois avant le Summit 2025)

Brian Stinson, ingénieur logiciel principal

« Dernière ligne droite : c'est à ce moment-là que tout devient plus intense pour les équipes, car il ne s'agit pas seulement de finaliser les fonctions, il faut s'assurer que toutes les autres tâches requises ont été réalisées avant le lancement de la version. Tous les paquets sont-ils intégrés ? Ont-ils été testés dans les délais ? Ont-ils été soumis pour obtenir des retours ? Ces types d'activités s'intensifient rapidement à mesure que nous nous préparons à geler le code. »

Chris Wells, directeur principal, Marketing produit - RHEL Business Unit

« Je savais qu'il fallait nous approprier cette histoire et la rendre captivante. Nous n'allions pas changer les fonctions de cette version, mais nous pouvions changer la façon dont nous en parlions.

J'ai donc organisé une réunion ici à Columbus, à laquelle j'ai convié Marty Loveless, qui était le responsable marketing produit sur RHEL 10, et Scott McCarty, qui résidait à Acron, à deux heures de route environ. Il nous a rejoints pour la journée. Nous nous sommes enfermés dans une salle de réunion et nous nous sommes interrogés sur les différents angles d'approche que nous pouvions adopter pour raconter notre histoire. Nous avons essayé de nous concentrer sur les nouveautés et cherché s'il y avait un autre angle pour l'aborder.

Major Hayden, ingénieur logiciel principal senior

« Un autre employé Red Hat et moi, du côté ingénierie, nous étions chargés de créer le code, alors nous avons partagé les tâches. Notre principal défi, c'était la RAG [génération augmentée de récupération]. Nous imaginions plus ou moins qu'il fallait juste rassembler des fichiers PDF dans un bucket et ensuite, lancer les recherches. Mais nous nous trompions.

Nous avons rencontré de nombreuses difficultés, en particulier car c'était la première fois que beaucoup d'entre nous utilisaient des vecteurs. J'ai pris l'option calcul infinitésimal pendant mes études, donc je sais que les vecteurs sont des lignes sur un plan cartésien, mais c'est à peu près tout. Comment des phrases deviennent-elles des vecteurs ? Cela n'a aucun sens. J'ai donc ressorti mes cours de calcul infinitésimal pour comprendre comment cela fonctionnait.

Puis, nous nous sommes retrouvés bloqués, car nous n'obtenions tout simplement pas de résultats de qualité. 

Mais nous sommes tombés sur un article, de blog il me semble, qui recommandait de demander à un LLM d'affiner la question du client. Nous avons donc créé un processus d'affinage qui consistait à prendre la question d'un client et à la soumettre à un grand modèle de langage en précisant que cette question concernait très probablement RHEL, ou les produits Red Hat ou Linux. Nous lui avons ensuite demandé de transformer la requête du client en cinq questions plus spécifiques avec des mots-clés qui correspondaient aux sujets énoncés. Par exemple, un client pourrait envoyer la requête brute suivante : "SSH pas de redémarrage". L'affinage permettrait de formuler des questions plus spécifiques et d'utiliser des phrases qui ont plus de chances d'apparaître dans nos contenus RAG. La recherche vectorielle pourrait alors renvoyer davantage de documents. Et soudainement, nous avons commencé à obtenir de meilleurs résultats. »

Chris Wells

« Nous sommes parvenus à exploiter ce qui est, d'après moi, le vrai facteur de différenciation de Red Hat sur le marché, à savoir l'ensemble de nos connaissances et de notre expertise autour de Linux pour RHEL, à en faire un produit et à le mettre à disposition sous la forme d'un assistant via Lightspeed. Cette approche nous a donné une façon très convaincante de présenter RHEL 10. »

Stef Walter, directeur principal, Ingénierie Linux

« Beaucoup de clients, notamment des entreprises de renom, déployaient le mode image avant qu'il soit pris en charge. Ils se sont dit que c'était formidable, qu'ils ne voulaient pas attendre et donc ils sont passés à l'action.

Quand nous en avons pris conscience, nous avons été très surpris de comprendre que des clients déployaient le mode image sans attendre sa prise en charge. Ce mode est si précieux pour leurs processus informatiques et les changements qu'ils tentent d'apporter, qu'ils se lancent sans nous. Et maintenant, nous devons rattraper notre retard. »

Chris Wells

« Nous avions une histoire convaincante au sujet du mode image. Nous nous sommes demandé si nous pouvions parler du mode image comme d'une autre méthode pour appliquer des correctifs et mettre à jour les systèmes. L'année précédente, nous avions davantage présenté le mode image comme un moyen de déployer de nouveaux systèmes, de nouvelles images et de nouveaux sites d'edge computing. Ce qui fonctionne très bien. 

Nous nous sommes donc demandé si nous pouvions aller encore plus loin. Au lieu de simplement déployer ces systèmes à la périphérie du réseau, pourquoi ne pas créer une image de serveur de production, la rendre immuable et la déployer avec le mode image ? Ainsi, chaque fois qu'il faut mettre à jour ce serveur, il suffirait de mettre à jour l'image et de simplement réimager le système. Ce serait une autre méthode de déploiement, qui permettrait d'éviter l'un des principaux casse-têtes de la gestion des systèmes Linux, c'est-à-dire les explorer pour appliquer des correctifs. Car si on pouvait gérer les correctifs en mode image, ce serait beaucoup plus facile, beaucoup plus rapide et beaucoup moins risqué que de le faire avec les paquets traditionnels. »

Le lancement de RHEL 10 au Summit 2025 approche. C'est la partie la plus facile, n'est-ce pas ? Nous publierons le prochain article en 2026. L'équipe nous présentera les mécanismes et processus de lancement.