Más de lo que se ve a simple vista: Detrás de escena de Red Hat Enterprise Linux 10 (parte 4)

En esta serie, se analiza al personal y la planificación que se necesitaron para diseñar y lanzar Red Hat Enterprise Linux 10. Escucharemos relatos de primera mano sobre el origen de RHEL 10, desde las primeras etapas conceptuales hasta el lanzamiento en Red Hat Summit 2025.

Parte 1 | Parte 2 | Parte 3

En la entrega anterior de la historia sobre el origen de Red Hat Enterprise Linux (RHEL) 10, obtuvimos información sobre el proceso de prueba y las características del título (y las historias en torno a esas características) comenzaron a formarse. En la cuarta parte, esas historias se abordan con mayor claridad a medida que el equipo trabaja para dar los toques finales a varias funciones antes de que el código se congele.

2025 (6 meses hasta el Summit 2025)

Brian Stinson, ingeniero de software principal

"El último tramo de tiempo: Esa es la parte en la que las cosas se vuelven un poco más intensas para los equipos individuales, ya que no se trata solo de '¿Vamos a reforzar las funciones?' sino '¿pudimos abordar el resto de las tareas de habilitación de referencia que necesitábamos hacer como parte del lanzamiento?' ¿Todos mis paquetes están listos? ¿Logramos que obtuvieran la QE en el plazo adecuado? ¿Han buscado comentarios? De hecho, ese tipo de actividades aumentan bastante a medida que nos acercamos a la congelación del código".

Chris Wells, Director sénior, Marketing de productos, Unidad comercial de RHEL

"Sabía que debíamos tomar esta historia e intentar que fuera emocionante. Pero no íbamos a cambiar las funciones de esta versión, solo podíamos cambiar la forma en que podíamos hablar sobre ellas.

Así que celebré una reunión aquí en Columbus donde convoqué a Marty Loveless, quien era el gerente principal de marketing de productos en RHEL 10, y a Scott McCarty, que vive a solo una o dos horas en Akron. Manejó hasta acá para pasar el día. Nos encerramos en una sala de conferencias e hicimos una lluvia de ideas, "¿cuáles son los diferentes ángulos desde los que podríamos hablar sobre las cosas?" Tratar de ver algo nuevo y descubrir: ¿Había un ángulo diferente?".

Mayor Hayden, ingeniero de software principal sénior

"Otro representante de Red Hat y yo, del área de ingeniería, diseñábamos el código, así que nos dividíamos el trabajo. Nuestro desafío principal era la generación aumentada por recuperación (RAG). Asumimos que: Arrojas un montón de archivos PDF en un balde y listo. Eso no era correcto.

Gran parte del desafío surgió de: Fue la primera vez que muchos de nosotros lidiamos con vectores. Por ejemplo, estudié cálculo en la escuela, así que sé que los vectores son una línea en un plano cartesiano, pero eso es todo lo que sé. ¿Cómo se convierten estas oraciones en vectores? No tiene ningún sentido. Así que un día tuve que sentarme y volver a aprender algo de cálculo para descubrir qué hace esto realmente.

Luego, el mayor obstáculo que enfrentamos fue que no obteníamos resultados de calidad. 

Pero leímos una publicación de blog o un artículo donde alguien sugería pedirle al LLM (Large Language Model) que perfeccionara la pregunta del cliente. Finalmente, creamos este proceso de perfeccionamiento de preguntas en el que recibimos la consulta del cliente y la enviamos a un LLM; decimos: «Oye, es muy probable que esta pregunta sea sobre RHEL, sobre productos de Red Hat o sobre Linux». ¿Puedes tomar esta pregunta del cliente y convertirla en cinco preguntas más específicas con palabras clave que se ajusten a estos temas? Por lo tanto, un cliente podría decir algo como: «SSH no reinicia». Luego, el perfeccionamiento de las preguntas las haría más específicas y usaría frases con más probabilidades de aparecer en nuestro contenido de RAG (Retrieval-Augmented Generation). Entonces la búsqueda vectorial coincidiría con más documentos. De repente, empezamos a ver que obteníamos mejores resultados».

Wells

«Realmente poder tomar lo que creo que es el diferenciador único de Red Hat en el mercado —todo nuestro conocimiento y experiencia en torno a Linux para RHEL— y convertirlo en un producto para ofrecerlo como asistente a través de Lightspeed. Esto nos brindó una forma muy potente de hablar sobre RHEL 10».

Stef Walter, director sénior de Ingeniería de Linux

«Nuestros clientes en general —y hablamos de clientes de gran renombre— implementaban el modo de imagen antes de que fuera compatible. Decían: “Esto es tan bueno que no nos importa”. “Lo estamos implementando ahora mismo”».

Cuando realmente empezamos a darnos cuenta fue ante la sorpresa de: “Vaya, lo están implementando en producción y no nos están esperando”. Esto es tan valioso para ellos en su proceso de TI y para el cambio que intentan realizar, que no van a esperarnos. Y ahora tenemos que seguirles el ritmo».

Wells

«Teníamos una historia muy potente sobre el modo de imagen. Y dijimos: “Bueno, ¿y si hablamos del modo de imagen como una forma diferente de aplicar parches y actualizar tus sistemas?”». Durante el último año, hablamos del modo de imagen más como una forma de implementar nuevos sistemas, nuevas imágenes e implementaciones en el extremo de la red (edge). Todo lo cual es perfectamente válido y está bien. 

Pero dijimos: “Bueno, ¿y si lo lleváramos un paso más allá?” ¿Qué pasaría si en lugar de solo implementar esto en el edge, crearas literalmente una imagen de un servidor de producción, la hicieras inmutable y la implementaras de esa manera? Entonces, cada vez que necesitaras actualizar ese servidor, solo actualizarías la imagen y, básicamente, volverías a crear la imagen del sistema. Sería una forma diferente de implementar. Si lo hicieras, eliminarías uno de los grandes dolores de cabeza de la gestión de sistemas Linux: analizarlos y aplicarles parches. Si gestionas los parches mediante el modo de imagen, el proceso sería mucho más fácil, rápido y con menos riesgos que el método tradicional de paquetes.

Ya casi llegamos al lanzamiento de Red Hat Enterprise Linux 10 en el Summit 2026. Esa es la parte fácil, ¿no? ... ¡¿verdad?! Busca la próxima publicación en 2026; el equipo te explicará los mecanismos y procesos de lanzamiento reales.