The moon is low tonight

El otro día me puse a compilar mi proyecto de fin de carrera y me encontré con que Affix no compila con el kernel 2.6.10 que trae la ubuntu que tengo instalada.

Cuando lo desarrollé, lo hice basándome en un núcleo 2.6.7. Parece ser que desde entonces han cambiado un par de cosillas en el kernel de Linux.

El nuevo ciclo de desarrollo del núcleo es de locos. Dentro de una rama supuestamente estable hay cambios de API día sí y día también. Los únicos cambios permitidos deberían ser aquellos que son imprescindibles para añadir nueva funcionalidad. Sin embargo, muchos cambios son realmente estúpidos como los que eliminan partes del núcleo, o incluso el prototipo de una función en una cabecera.

Los problemas que me he encontrado son:

• Se han cepillado un campo en la estructura sock. En concreto el puntero que asocia a un socket con su pareja.
• La mayoría de las funciones del API de drivers tty tienen ahora un argumento menos.
• La llamada al sistema close ya no está disponible al incluir la versión de unistd.h del kernel.

Aquí dejo unos parches que hacen que Affix compile (y funcione). Aplican sobre affix-kernel-3.0.0 y affix_kernel-3.2.0. Los he mandado también a la lista de desarrollo de Affix, así que supongo que no tardarán mucho en incorporarlos.

Cuando el creador de BitKeeper decidió dar por terminado el desarrollo de la versión gratis (no libre) de dicho sitema de gestión de configuración, Linus tomó la determinación de dejar de utilizarlo.

Como manejar a mano un repositorio de código como el de Linux es inabordable, es necesario una herramienta temporal hasta que exista una alternativa que ofrezca la funcionalidad de bitkeeper.

Ha sido tal la cantidad de mails en la lista del kernel sugierendo el uso de subversión que han tenido que poner un comunicado oficial en la página de subversion enumerando las razones por las que no es adecuado para el desarrollo de Linux y pidiendo que cesen esos comentarios.

Tras evaluar algunas de las opciones disponibles y comprobar lo ineficientes que eran al manejar un reposiorio del tamaño de Linux, Linus ha decido crear su propia herramienta llamada git. Su prioridad a lo hora de realizar el diseño ha sido la eficiencia. El coste de proceso y de accesos a discos es lineal, O(n), respecto al tamaño de un cambio, pero independiente del tamaño del repositorio.

Sin embargo tiene sus inconventientes, lo que era de esperar, teniendo en cuenta que es una herramienta provisional:

• No es una herramienta de gestión de configuración propiemante dicha. Linus prefiere describirlo como un sistema de archivos con gestión de versiones.
• Necesita una gran sobrecarga de metadatos. Aunque después se ha conseguido mejorar, las primeras versiones requerían de alrededor de 1 Mb de espacio para un cambio sencillo de un par de ficheros.
• La mezcla de cambios procedentes de distintas fuentes se complica. BitKeeper posee un algoritmo muy elaborado que es capaz de resolver automáticamente casi cualquier conflicto. El método que utiliza git es el comando de unix merge(1). En palabras de Linus, volvemos a los tiempos de 1980.