Por esta vez no voy a empezar con el rollo de "en 1992 un estudiante finlandés..." (el equipo-A me dejó más marcado de lo que yo pensaba); vosotros mismos.

Sin embargo, hay una cosa que me llama la atención acerca del famoso estudiante: su orientación científica (y de esta disquisición no os libráis). Por ejemplo, en el artículo de la wikipedia enlazado arriba Linus cita a Newton, y el aforismo de "Dado el suficiente número de ojos, todos los errores son poco profundos" suena a ley natural. Pero hay ejemplos más interesantes.

Si alguna vez habéis tenido que perfilar código Java en Linux sabréis que la famosa precisión de nanosegundos (milésimas de millonésima de segundo, o 10^-9 segundos) es completamente utilizable; cuando en otros sistemas operativos hasta los milisegundos son poco fiables. No hay en realidad ningún motivo para no disponer de esta información, ya que la inversa de un nanosegundo es, curiosamente, un GigaHerzio; por tanto, cualquier procesador que vaya a 1 GHz o más ya tiene la capacidad de contar nanosegundos, y sólo hay que preguntarle. Pero además resulta que la base primera de la ciencia es la medida; si tu instrumentación es pobre, tus conclusiones lo serán también. Y la tecnología no es otra cosa que las viejas artes de siempre a las que se les aplica un poco de ciencia.

ramas

Como parte de esta orientación científica veo yo la práctica de separar las ramas estable y de desarrollo, que no es muy común en la industria. Normalmente, las versiones van saliendo según están listas, y la rama de desarrollo es solamente la avanzadilla de la última versión.

Para los que no sois desarrolladores: una rama es un camino por el cual evoluciona el código de un programa, mientras que cada versión es una especie de instantánea del estado de un programa en un momento dado a lo largo de su rama. Puede haber varias ramas activas en un proyecto; por ejemplo, en Apache la rama 2.0 apareció hace tiempo ya y se ha adoptado en muchísimos entornos de producción; pero la rama 1.3 se sigue manteniendo ya que también sigue en uso activo.

En numerosos proyectos de software libre la versión en desarrollo se conoce como HEAD (testimonio de la terminología en cvs), o punto-equis. Como ejemplo, veamos cómo funciona en Audacity, ya que estoy suscrito a la lista de correo: el desarrollo que sigue a la versión 1.2 se llama 1.2.X, o sea que todo lo que hay en la 1.2.X acabará por aparecer en alguna versión de la rama 1.2: 1.2.1, 1.2.2... que son mejoras incrementales sobre el código de la 1.2. Poco después de que saliera la versión 1.2, se comenzó a trabajar en la rama 1.3: un sitio donde introducir las mejoras radicales y que pueden romper funcionalidades existentes. Mientras está abierta, los errores deben corregirse en ambas ramas, 1.2 y 1.3. Tan pronto como salga la versión 1.3.0, primera de la rama 1.3, probablemente alguien abra la rama 1.4; lo contrario querría decir que el programa ha alcanzado un estado satisfactorio para todo el mundo, y/o que ya hay poco interés por el desarrollo.

Por último, otro detalle que nos hace falta: las ramas (como 1.2) suelen tener número mayor (en este caso 1) y número menor (el 2 que va tras el punto). Las versiones pueden tener tres números (como 1.2.3); tienen número mayor y menor, y el tercer número no estoy seguro de cómo se llama; creo que puede ser número de revisión o de parches, dependiendo del desarrollador. Otra gente lleva la versionitis al máximo y le coloca hasta 5 números a las versiones, como Oracle 6.0.3.11.0; a veces se controlan las versiones de desarrollo por fecha (build date), como eclipse.org; y otras veces por número de build, como el infame "build 1381" de Windows NT 4.

pares o nones

Linux fue un poco especial para las versiones desde el principio; se declaró que las versiones con número menor par (como 2.2) serían estables, y aquéllas con número menor impar (como 2.3) pertenecerían a la rama de desarrollo. ¿Qué significa esto en la práctica? Pues que dentro de la rama de desarrollo habrá sucesivas versiones distintas, que irán incluyendo cada vez más funcionalidades, todas inestables. Sólo cuando la rama de desarrollo se estabilice lo suficiente, saldrá la versión estable (en nuestro ejemplo la 2.4.0); e inmediatamente se creará la nueva rama de desarrollo (2.5). La antigua rama inestable es subsumida completamente dentro de la nueva rama estable (2.3.99 -> 2.4.0 -> 2.4.1...). De hecho, como puede verse en su página de kernel.org, el kernel 2.3.51 pasó a convertirse en las distintas versiones 2.3.99-preX, hasta dar lugar por fin a la versión 2.4.0.

El tener que mantener una rama de desarrollo, con sus versiones y todo, es probablemente testimonio de lo crítico que es el código del núcleo: se supone que las mejoras que se introducen tardan un montón de tiempo en estabilizarse; cuando por fin están bien pulidas y se llevan bien con todas las nuevas modificaciones que se hayan introducido, pasan a la próxima versión estable. Como se ve en la rama 2.3, el proceso en ese tiempo tardó poco más de un año. Tiempo después, en noviembre de 2001, se creó la rama 2.5, que tardaría casi dos años en estabilizarse (hasta julio de 2003); más en realidad si tenemos en cuenta que la versión 2.6.0 no salió hasta diciembre de 2003. En este intervalo se pasó a la versión 2.6-test, puramente de estabilización.

¿Estamos ahora en un período de bonanza y mejoras graduales en 2.6.X, a lo que seguirá una nueva rama inestable 2.7; o ha cambiado algo fundamental?

revoluciones evolutivas

Tradicionalmente, se ve que Linus Torvalds era el encargado de guiar el desarrollo de la rama inestable; mientras que Marcelo Tosatti mantenía la rama estable. Ahora mismo ambos mantienen ramas estables, 2.4 y 2.6; sí hay un par de ramas colaterales mantenidas por Alan Cox y Andrew Morton, una especie de campo de pruebas para nuevos conceptos. Se conocen como "árboles" o trees: -ac el de Cox, -am el de Morton, y así. (Creo que hay una rama mantenida por Andrea Arcangeli, el árbol -aa, pero no lo siguen en la página de LWN.net.)

Se supone que, eventualmente, Linus creará una nueva rama inestable (la 2.7); probablemente cuando haya que meter cambios demasiado gordos para una rama estable. Sin embargo, el problema está en que dos años para estabilizar un nuevo desarrollo son demasiado. Además, Linus sigue introduciendo nuevos cambios en la rama 2.6 a buen ritmo, con alguna que otra pifia (como la version 2.6.8, que parece especialmente odiada). En principio, la gran ventaja es que los núcleos que se incluyen en las distribuciones no necesitan estar tan parcheados; en la práctica los distribuidores siguen metiendo cientos de parches a medida en sus núcleos.

Podría pensarse que esto siga así indefinidamente, con la rama estable 2.6 dando paso a una rama también estable 2.7; y la rama de Morton aceptando cambios importantes. Pero ya el mes pasado Andrew Morton avisó de que no: en cualquier momento llegará un cambio importante, que pueda potencialmente desestabilizar múltiples partes del núcleo e imposible por tanto de acomodar dentro de la rama 2.6; ni siquiera en el árbol -am.

ni del No-Do

Como curiosidad, la reacción de este imbécil, Paul Krill: llama bifurcación o fork a la creación de una rama inestable 2.7; y luego lo compara al fork que ocurrió entre versiones comerciales de Unix y llevó a su paulatino desmembramiento como mercado. Como respuesta se armó un cierto revuelo, difícil de creer si no se ve; hasta Morton respondió a las alegaciones diciendo que era parte del proceso normal de desarrollo del núcleo, y parece que los cuatro que habían picado se tranquilizaron.

que haya calma

Vamos, que todo esto es parte del desarrollo normal del kélmer de Sánex: hay que cambiarlo todo para que todo siga igual. A la mayoría de los usarios esto ni nos afecta; ya se encarga nuestra distribución de parchear el núcleo de kernel.org y presentárnoslo con un lacito. La mayoría de las veces no tendremos ni que preocuparnos de compilar algo en el kernel o dejarlo como módulo.

Esto es, en mi opinión, una buena cosa. A mí me sirve de poco el código hot-plug del núcleo 2.6; si no dispongo además del paquete discover de Debian que me auto-detecta los dispositivos nuevos al enchufarlos. En contra de lo que la mayoría de la gente se piensa, el núcleo de un sistema operativo no es tan importante; es más bien un área esotérica de infraestructura, y es muy curioso que en los sistemas GNU/Linux sea tan llamativo para los usuarios (entre los que por supuesto me incluyo).