Cómo Google utiliza Linux

En LWN.net cubrieron la 2009 Linux Kernel Summit, y presentaron un resumen de la presentación realizada por los ingenieros de Google sobre la forma en que utilizan Linux. Según el artículo, un equipo de 30 ingenieros de Google se remonta al núcleo principal cada 17 meses, poniendo en ejecución 1208 parches para el núcleo 2.6.26 y la inserción de casi 300.000 líneas de código; aproximadamente el 25% de los parches son backports de nuevas características.

No existe ninguna otra organización que utilice más extendidamente sistemas Linux que Google. Sin embargo, la comunidad de desarrollo del kernel sabe poco acerca de cómo Google utiliza Linux y qué tipo de problemas se encuentran allí. Mike Waychison de Google viajó a Tokio para ayudar a dar algo de luz sobre esta situación y el resultado fue una interesante perspectiva sobre lo que se necesita para ejecutar Linux en este entorno sumamente exigente.

Mike empezó la charla contando a los desarrolladores un chiste: parece que Google gestiona su código del kernel con Perforce (un sistema comercial de control de versiones para gestionar proyectos experimentales que todavía no están listos). Se disculpó por ello. Existe un solo árbol que compromete a todos los desarrolladores. Aproximadamente cada 17 meses, Google monta su trabajo a una publicación de línea de desarrollo principal, lo que sigue es una larga lucha para que todo funcione de nuevo. Una vez hecho esto, las «característica» internas se liberan cada seis meses.

Esta manera de hacer las cosas dista mucho de ser ideal, significa que Google está muy por detrás de la línea de desarrollo principal y tiene dificultades para hablar con la comunidad de desarrollo del kernel sobre sus problemas.

Hay alrededor de 30 ingenieros que trabajan en el kernel de Google. En la actualidad tienden a revisar sus cambios en el árbol, y luego se olvidan de ellos por los próximos 18 meses. Esto lleva a algunos problemas de mantenimiento; los desarrolladores a menudo tienen una pequeña idea de lo que realmente está en el árbol de Google hasta que se rompe.

Y hay mucho en ese árbol. Google comenzó con el kernel 2.4.18 – en el que parcharon más de 2000 archivos, insertando 492.000 líneas de código. Entre otras cosas, ellos portaron el soporte de 64 bits dentro del núcleo. Más tarde se movieron al núcleo 2.6.11, principalmente porque necesitaban el soporte SATA. Cotinuaron con un kernel basado en la versión 2.6.18, y ahora están trabajando en la preparación de un kernel 2.6.26 para un desarrollo futuro. Están actualmente llevando 1208 parches al núcleo 2.6.26, insertando cerca de 300.000 líneas de código. Aproximadamente el 25% de los parches, según estimaciones de Mike, se tratan de backports de nuevas características.

Hay planes para cambiar todo esto, el grupo del núcleo de Google está tratando de llegar a un punto en el que puedan trabajar mejor con la comunidad del núcleo. Se están moviendo a git para la gestión del código fuente, y los desarrolladores podrán mantener sus cambios en sus propios árboles. Esos árboles se montarán al desarrollo del núcleo principal cada trimestre, lo que debería motivar a los desarrolladores hacer su código más fácil de mantener y más en consonancia con el flujo de desarrollo del núcleo.

Linus le preguntó: ¿por qué no son estos parches presentados? ¿Es porque Google se siente avergonzado por ellos, o se trata de material secreto que no quiere revelar, o es una cuestión de problemas en el proceso interno? La respuesta fue simplemente «sí». Algunos de estos códigos son algo «feos» que se han llevado adelante desde el núcleo 2.4.18. También hay dudas internas acerca de cómo gran parte de este material será realmente útil para el resto del mundo. Pero, tal vez, cerca de la mitad de este código podría ser de incluido en el desarrollo eventualmente.

Más de 3/4 del código de Google consiste en cambios al núcleo central, el soporte a dispositivo es relativamente una pequeña parte del total.

Google tiene una serie de «puntos de dolor» («pain points») que hacen que trabajar con la comunidad sea más difícil. Mantenerse al día con el flujo de desarrollo del núcleo es difícil -simplemente se mueve demasiado rápido. También hay un problema real con los desarrolladores publicando un parche, a continuación, se pide volver a trabajar de una manera que lo convierte en un proyecto mucho más grande. Alan Cox tenía una respuesta simple para que ellos: la gente siempre pide más, pero a veces lo que hay que hacer es simplemente decirles «no».

Puedes ver el artículo completo en LWN.

Enlaces: