Oltre l’evidenza: dietro le quinte di Red Hat Enterprise Linux 10 (quarta parte)

Questa serie analizza le persone e la pianificazione che hanno contribuito alla creazione e al rilascio di Red Hat Enterprise Linux 10. Dalle prime fasi concettuali al lancio al Red Hat Summit 2025, leggeremo le testimonianze dirette sulla nascita di RHEL 10.

Parte 1 | Parte 2 | Parte 3

Nella puntata precedente della storia di come è nato Red Hat Enterprise Linux (RHEL) 10, abbiamo approfondito il processo utilizzato per la fase di test e il modo in cui le funzionalità principali (e le storie che le riguardano) hanno iniziato a delinearsi. Nella quarta parte della serie, queste storie diventano più chiare, mentre il team lavora per apportare gli ultimi ritocchi alle varie funzionalità prima del congelamento del codice.

2025 (sei mesi al Red Hat Summit 2025)

Brian Stinson, Principal Software Engineer

"Ultimo periodo: in questa fase le cose si fanno un po' più intense per i singoli team perché non ci si chiede solo se le funzionalità siano quasi pronte, ma anche se siamo riusciti a completare tutte le attività che consentiranno il rilascio. Ho incluso tutti i pacchetti? Abbiamo eseguito il QE secondo la pianificazione corretta? Sono stati inviati per il feedback? Questi tipi di attività si intensificano notevolmente mentre ci avviciniamo al “code freeze."

Chris Wells, Senior Director, Product Marketing - RHEL Business Unit

"Sapevo che avremmo dovuto prendere questa storia e cercare di renderla interessante. Non avremmo cambiato le funzionalità di questa versione. Potevamo solo cambiare il modo di presentarle.

Così ho organizzato un incontro a Columbus con Marty Loveless, Lead Product Marketing Manager per RHEL 10, e Scott McCarty, che vive ad Akron, a solo un'ora o due di distanza. Ci ha raggiunti in auto per passare la giornata con noi. Ci siamo chiusi in una sala conferenze e abbiamo fatto un brainstorming sui diversi punti di vista da cui osservare i vari aspetti. Abbiamo cercato di osservare le novità per capire se esisteva un punto di vista diverso.

Major Hayden, Senior Principal Software Engineer

"Io ed un altro collega di Red Hat ci occupavamo della progettazione del codice, quindi ci siamo divisi il lavoro. La RAG (retrieval augmented generation) è stata la nostra sfida principale. Ipotizzavamo che funzionasse così: si carica un insieme di PDF bucket e si avvia immediatamente la ricerca. Non è così.

La sfida era complessa principalmente perché molti di noi avevano a che fare con i vettori per la prima volta. Ad esempio, ho studiato analisi matematica a scuola e sapevo che i vettori sono linee su un piano cartesiano, ma nient’altro. In che modo queste frasi diventano vettori? Non aveva alcun senso. Così un giorno ho dovuto mettermi a studiare di nuovo l'analisi matematica per capire come funzionasse.

L'ostacolo più grande che abbiamo incontrato è stato non riuscire a ottenere risultati di qualità. 

Abbiamo letto un articolo in un blog in cui si suggeriva di chiedere all'LLM di perfezionare la domanda del cliente. Alla fine abbiamo creato questo processo di perfezionamento delle domande in cui riceviamo il quesito dal cliente e lo inviamo a un LLM dicendo: "Questa domanda riguarda molto probabilmente RHEL, i prodotti Red Hat o Linux. Puoi trasformare questa domande del cliente in cinque quesiti più specifici con parole chiave in linea con questi argomenti?" Un cliente potrebbe dire, ad esempio: "SSH no restart". Il perfezionamento delle domande le rende più specifiche e utilizza frasi che hanno più probabilità di apparire all'interno dei nostri contenuti RAG. In questo modo la ricerca vettoriale avrebbe trovato corrispondenze in più documenti. All'improvviso abbiamo iniziato a ottenere risultati migliori."

Wells

"Poter sfruttare quello che ritengo sia l'elemento distintivo di Red Hat sul mercato, ovvero tutta la nostra conoscenza ed esperienza su Linux per RHEL, per trasformarlo in un prodotto e fornirlo come assistente tramite Lightspeed ci ha permesso di parlare di RHEL 10 in modo efficace."

Stef Walter, Senior Director, Linux Engineering

"Tutti i nostri clienti, e parliamo di nomi importanti, distribuivano la modalità immagine prima che fosse supportata. Dicevano: "È fantastico, non ci importa. La distribuiamo ora".

Il vero successo è arrivato quando siamo rimasti sorpresi nel vedere che la stavano distribuendo in produzione senza aspettarci. Questo aspetto è così prezioso per i loro processi IT e per il cambiamento che cercano di apportare, che non ci intendono aspettare. E ora dobbiamo tenere il passo".

Wells

"Avevamo una storia molto efficace sulla modalità immagine. Ci siamo chiesti: "E se parlassimo della modalità immagine come di un modo diverso per applicare patch e aggiornare i sistemi?" Nell'ultimo anno abbiamo descritto la modalità immagine più come un modo per distribuire nuovi sistemi, nuove immagini e distribuzioni edge. Il che è perfettamente valido e corretto. 

Ma ci siamo detti: "E se facessimo un ulteriore passo avanti? Se invece di limitarci a eseguire la distribuzione all'edge, creassimo letteralmente l'immagine di un server di produzione, rendendola immutabile e distribuendola in questo modo?" Ogni volta che è necessario eseguire un aggiornamento su un server, è sufficiente aggiornare l'immagine e in sostanza reinstallare l'immagine del sistema. Sarebbe un modo diverso di eseguire la distribuzione. In questo modo si eliminerebbe una delle maggiori difficoltà nella gestione dei sistemi Linux: l'applicazione delle patch. Gestire le patch tramite la modalità immagine sarebbe molto più semplice, rapido e meno rischioso rispetto al metodo tradizionale basato sui pacchetti.

Siamo in procinto di lanciare Red Hat Enterprise Linux 10 al Red Hat Summit 2025. Questa è la parte più facile, vero? Leggi il prossimo articolo nel 2026: il team illustrerà i meccanismi e i processi di lancio effettivi.