El Geek Errante: transmisión #08

El tema del nuevo scheduler del kernel tiene además algo muy curioso. El parche del CFS de ingo molnar no solo añade ese nuevo scheduler, sino que crea una estructura modular para poder implemenetar CUALQUIER política de scheduling sobre las “clases” que se tienen en el API.

El CFS lo hizo Ingo Molnar en 66 horas y tenia 100k lineas de codigo. En cuanto tuvo una versión usable la anunció en la lista de desarrollo del kernel. Por eso las criticas de Kolivas de que no ha podido meter baza en el desarrollo son totalmente absurdas. Ha podido meter baza igual que el resto de gente que ha colaborado con parches y con criticas.

Además como digo, nada impide que Kolivas implemente su heuristica sobre la nueva estructura modular de scheduling del kernel que incluye el parche de Ingo, pero se ha negado en rotundo. El queria que su scheduler entrara “por narices” y no ha aceptado que una solución mucho más simple que la suya y que mejora sustancialmente la situación actual haya conseguido entrar en el kernel en unos pocos meses de desarrollo cuando el lleva bastante más con el desarrollo del suyo.

Es un problema de ego y de no aceptar que en un proyecto grande como el kernel (en cuanto a contribuidores), siempre hay esfuerzos que se quedan en nada. Lo que tenia que haber hecho es como ha pasado en otros casos con tecnologias que se han desechado… adaptarse y colaborar en lo que se haya elegido.

Y si Ingo ha metido a Kolivas en los agradecimientos ha sido por intentar evitar precisamente lo que ha pasado. Pero no ha servido de nada.

Hola Ramón,

como siempre, gracias por tus comentarios, siempre tan oportunos. A este paso vamos a pedirte que colabores con nosotros ;-)

Coincido contigo en que a Kolivas le ha podido el ego. Su reacción ha sido infantil, y espero que alguien se encargue de mantener DS, que me parece una opción interesante para servidores y enterprise. Me preocupa que en LKML haya gente que hable de forks, traiciones y conspiranoias, cuando desde siempre cada distro ha distribuído su propio kernel parcheado, teniendo cada usuario la libertad de elegir, que de eso se trata.

De todas formas, es el mismo Torvalds quien confiesa que la diplomacia le importa poco, y que lo que quiere es fomentar la competitividad y el “pique” entre sus mejores desarrolladores. Una manera bastante finladesa, por cierto. Esto puede funcionar cuando hay un grupo relativamente manejable de desarrolladores del kernel, pero a medida que Linux crece más y más, hay que volverse un poco más político para evitar que este tipo de situaciones se repitan. Este es el reto al que comienzan a enfrentarse Linux y Linus - ¿Sería algo así como la versión linuxera de Apache Foundation una solución? ¿Un comité elegido democráticamente entre los “top-developers”?

Un saludo,
MrSolo

MrSolo, ya existe un “comité”, pero de manera informal y se ha creado de forma natural por la relación de confianza… no creo que el desarrollo del kernel se pueda pasar a una estructura tipo Apache, porque precisamente la descentralización y el “forking y merging” es lo que hace que avance linux de la forma que lo hace.

No hay cosa mas democratica que el software gpl. Cualquiera puede hacer un fork para meter lo que quiera. Con licencias tipo BSD, el fork puede hacer mucho daño, pero con GPL, un fork exitoso siempre revierte en mejorar el proyecto original.

Además, ya hay una Linux Foundation que promueve el desarrollo del kernel en areas que responden a las necesidades empresariales y eso hace que unas cuantas empresas se pongan de acuerdo en colaborar.

Pero en general, creo que el modelo actual funciona, porque es el que ha habido siempre. Un desarrollador envia un correo a la lista con un parche para hacer tal cosa. Primero tiene que demostrar que el kernel necesita hacerlo, despues que su solucion es buena, reescribirlo para que se ajuste a las guias de desarrollo del kernel y que sea testeado y corregidos sus bugs. Y puede que durante ese tiempo surja otro que en menos tiempo haya dado una solución mejor, o mas simple, al problema que queria resolver y tu esfuerzo se quede en “nada”. (Ya ha pasado con cosas como EVMS)

Además, el kernel no es una democracia :), nadie ha elegido a Torvalds como el lider del proyecto de la rama oficial. Eso hay que aceptarlo si quieres que tu trabajo se incluya en la rama oficial del kernel.

Eso es otro de los asuntos a tener en cuenta, en linux no hay un centro común, todo son ramas, por eso el hecho de que alguien deje de desarrollar un parche simplemente porque no se ha incluido en el oficial, es una razón sin sentido. Vale que tu trabajo no llegará a tanta gente, pero si llegará a los que les resulte interesante. Digo yo :-P