Ideas de genios

Ingo Molnar tiene problemas con el driver de fb de radeon al regresar de la suspension por software. Puesto que en ese punto aun no esta funcionando el sistema y un sysrq no va a funcionar. Pero la pila tcp/ip funciona y responde al ping. ¿Metodo de depuración que ha decidido probar? Insertar un dump_stack() (volcado de pila) en la funcion que se encarga de responder al ping. Al hacer ping a la maquina se mostrara el volcado de la pila.

Al final no ha funcionado por vaya a saber usted que razon (ausencia de netconsole en funcionamiento). Pero el método y la idea son curiosos, al menos. O a mi me lo parece.

El futuro de GTK

En este enlace han publicado un resumen de una conferencia en el que discuten sobre el futuro de GTK. Aunque normalmente deseo la muerte de GTK, sus desarrolladores y sus usuarios, me encanta observar que hay movimiento para cambiar las cosas. El mejor proyecto no es aquel que es mejor técnicamente, sino el que más rápido avanza y se adapta a las nuevas necesidades y el que mejores ideas tiene cuando avanza (por eso Linux dejó a los BSD en la cuneta).

Soy un optimista, este mensaje me devuelve la esperanza de poder disfrutar de un escritorio gnome con soporte de miniaturas en el diálogo de abrir archivos por el 2010 o así. Por fin podré escoger directamente los archivos desde el diálogo de abrir archivos, en vez de tener abierta una ventana del nautilus, buscar la imagen que quiero seleccionar en el diálogo, mirar el nombre que tiene, y volver al diálogo de abrir/cerrar archivos y buscar el nombre.

KVM vs XEN: 1 - 0

Supongo que mucha gente habrá escuchado acerca de Xen, la solución de virtualización libre de referencia, portada incluso en sistemas como NetBSD o Plan9. Quizaś no sepan, o quizás si, que XEN aun no está incluido en el kernel, y que 2.6.20 incluye KVM y una interfaz de paravirtualización. Bien. Pues ZDNet ha escrito un interesante artículo titulado "KVM roba atención a XEN". Como es un artículo de periodismo, trata de la reciente aparición de KVM pero entrevistando a representantes de XEN, VMWare, para que expongan su opinión y contrasten posturas y resumir todo de manera objetiva. A mi como la objetividad me importa un pimiento, escribo un artículo diciendo porque KVM va a arrasar con los demás en el territorio Linux.

¿Y que pasa con XEN, dirán algunos ahora? Pues en primer lugar, varias personas del entorno Linux no lo encuentran precisamente la solución "perfecta". XEN es en si un "hypervisor", y tiene su propio gestor de procesos y de yo que se que más, y a la gente no le gusta. KVM, en cambio, utiliza toda la infraestructura de Linux, no es un hypervisor completo como XEN. XEN es en si un sistema operativo completo que soporta Linux, FreeBSD, Plan9, etc; y muchas de sus partes jamás serán incluidas en el kernel, y todo esto no es por oposición de la gente del kernel o porque yo me lo invente, sino porque la propia gente de XEN lo dice. Es decir, la propia gente de XEN no tiene intención de incluir todo su código del hypervisor en el kernel.

Todo esto junto con unas interesantes reflexiónes ha sido publicado por Ulrich Drepper -mantenedor de la libc desde hace años-. Despues de leer ese artículo queda bien claro por qué KVM va a ganar. XEN tiene su propia implementación de un sistema de seguridad, KVM utiliza selinux. XEN tiene su propio gestor de procesos, KVM utiliza el de Linux, que es muy eficiente. Soporte de NUMA y gestión de memoria...KVM tiene todo eso disponible.

KVM tiene alrededor de 6 meses de vida y eso es criticado en el artículo de CNET por la gente de XEN por la falta de una serie de características que a ellos les ha tomado años implementar, argumentando que a KVM le tomará años implementarlo. Pero como Ulrich explica, nada más lejos de la realidad. Mientras que es cierto que a KVM le faltan muchas cosas, el estilo de desarrollo y lo mencionado en el anterior párrafo -y el apoyo de gente como Red Hat, que tiene buenos técnicos que han recomendado que KVM es mejor a largo plazo-. Por ejemplo, en el artículo se crítica a KVM la carencia de paravirtualización, la falta de soporte de guests de 64 bit, de soporte SMP, de migración en vivo. Y cuando hicieron el artículo tal vez era cierto, pero ya no lo es, y KVM ya tiene implementaciónes de esas cosas en fase de pruebas. La versión que se ha incluido en 2.6.20 es una versión cutre, pero en 2.6.21 ya se incluye soporte de añadidura/eliminación de CPUs en caliente y de suspensión de hosts KVM. En otras palabras, el desarrollo va sorprendetemente rápido. Ingo Molnar ya ha implementado un controlador de red que utiliza paravirtualización que consigue velocidades sorprendentes, y su implementación de paravirtualización en general tambien es muy rápida.

De ahí viene mi predicción. KVM va a convertirse en la solución de virtualización de facto para Linux simplemente porque está más integrado con el kernel, porque es la que van a utilizar otros hackers del kernel para probar otros kernels. XEN será siempre un addon, y su exceso de complejidad juega en su contra a la hora de tener que evolucionar para competir. Simplemente comparando lo poco que se ha tardado en implementar ciertas cosas para KVM, y lo que tardó el soporte equivalente en XEN. Y el hecho de que en cuanto KVM sea comparable en características a KVM, las distribuciones van a dejar de utilizar XEN porque KVM ya viene incluido por la cara en el kernel. Espero que este caótico y desestructurado artículo sirva para que quienes lo lean sepan de que lado sopla el viento y no les pille desprevenidos el futuro.