¡Aguante, Firefox!

Firefox supera el 24% de uso en Europa y su versión 2 casi iguala a Internet Explorer 7

Hay que seguir, seguir, seguir impulsando firefox. Si los gobiernos no hacen nada para controlar a las empresas que abusan de la libertad de mercado y la transforman en libertinaje, tendrá que hacerlo la gente.

A Linus le gusta la GPL3

La FSF ha sacado un nuevo borrador de la GPLv3, y esta vez a Linus parece gustarle, aunque el tema del DRM,que fue el que más ruido hizo, ya se había suavizado en el anterior borrador. Una de las novedades de este borrador es un clausula de proteccion contra casos como el de Novell.

A Linus podrá parecerle bien, pero a mi me sigue pareciendo absolutamente intolerable que todo el código licenciado bajo la GPLv2 vaya a relicenciarse bajo la GPLv3 automáticamente, sea cual sea su texto. Simplemente, la FSF no debería decidir esas cosas, aunque legalmente pueda hacerlo. La GPLv3 debería ser una licencia separada, y cada programador debería escoger libremente entre cambiar su código a GPLv3 o no.

En cualquier caso, que a Linus le guste significa que tiene cambios que agradarán a muchos de los que, como Linus, se oponían a la GPLv3; y eso es bueno, porque reduce el riesgo de forks. En ese sentido, la FSF se merrece una aplauso, por haber escuchado.

Intel da la campanada: gráficos integrados, controlador de memoria integrado, retorno de SMT

Practicamente he traducid o esta entrada de Jon Stokes en Ars Technica, aunque tambien puede informarse uno de lo mismo en The Register

Y en realidad el título lo dice todo: Intel va a 1) integrar el chip gráfico en el chip, 2) implementar un controlador integrado de memoria 3) implementar un competidor de HT llamado CSI (del que ya había noticias hace tiempo) 4) SMT, o lo que es lo mismo, el regreso de HT. Cuatro novedades impresionantes que van a hacer que las acciones de AMD bajen mañana. Ahora, un breve resumen con un posterior análisis de cada punto:

Lo que Intel propone es una nueva arquitectura para sustituir al Core 2. Parece raro que Intel quiera sustituir una arquitectura que a día de hoy bate a AMD en todos los frentes, pero Intel no quiere dormirse en el pasado, y tiene algunos fallos que corregir. La nueva arquitectura se llama Nehalem. Intel dice que es una arquitectura "escalable": Quieren poder hacer mezclas de varios cores - hasta 8 - con caches, chips gráficos y de memoria integrados que podrán incluirse o incluirse a gusto. El objetivo es poder cubrir todas las necesidades del mercado.

• Integración del chip gráfico en la CPU: Esto puede parecer una barbaridad y a mi me lo parecio un poco cuando lo anuncio AMD en su día, poco despues de comprar ATI (conspiranoia rápida: ¿sabía AMD esto de Intel y compró ATI para contraatacar?). Puede parecer, como digo, una barbaridad, pero puede que no lo sea tanto: Los gráficos cada vez están cobrando más relevancia, las interfaces gráficas ya no son simples dibujados de líneas 2D. Las gráficas de hoy son auténticas GPUs, es decir, unidades de proceso gráfico independientes de la CPU. Se especializan en lo que necesitan los juegos: manejo de texturas, cálculos de coma flotante.
  
  En primer lugar, se me ocurre que tiene sentido unificar el proceso de coma flotante de los procesadores y las gráficas. De hecho, hay un programa de Nvidia que permite utilizar la gráfica como unidad de cálculo de coma flotante para cálculo cientifico, y cosas así. En segundo lugar, al estar junto al controlador de memoria permitirá utilizar memoria normal como memoria gráfica. En tercer lugar, tiene sentido empezar a hablar de una conjunto de instrucciones gráficas frente a las gráficas actuales del mismo modo que antes cada máquina llevaba una CPU diferente y hoy se habla del conjunto de instrucciones x86. En cuarto lugar, ahorra mucha energía, por lo que es ideal para portátiles.



• Controlador integrado de memoria: Cuando AMD sacó el Opterón, reconoció que el 15% de la mejora del rendimiento venía exclusivamente del controlador integrado de memoria. Un controlador de memopia integrado permite acceder a la memoria con una latencia mucho menor, algo que mejora el rendimiento una barbaridad. La mayoría de instrucciones que ejecutan los programas son instrucciones que operan leyendo o escribiendo sobre memoria. Las de lectura son especialmente sensibles a la latencia, y la latencia no ha disminuido mucho en los últimos años, hoy en día leer un dato que no esté en la cache L1/2 tarda algunos cientos de ciclos - de ahí vino la idea de HT. Intel aquí está ciertamente intentando cazar a AMD, pero a Intel el controlador integrado de memoria no le traerá tantas ventajas como se las trajo a AMD: El Core 2 se ha optimizado mucho para mejora la latencia de acceso a RAM e incorporó buenos predictores para ir pre-leyendo valores de memoria antes que la CPU los necesitara. Por eso, parte de la ganancia de los controladores integrados de memoria Intel la ha "recobrado" por otros medios, aunque ciertamente mejorará mucho el rendimiento.



• CSI es un competidor de HT, aquí Intel vuelve a intentar cazar a AMD; pero de nuevo, si Intel a díade hoy gana a AMD sin CSI, con CSI le ganará. De CSI basta con decir que es un sistema que elimina el bus de acceso centralizado de Netburst y que impide crear arquitecturas SMP escalables: Si varias CPUs intentan acceder a través de un solo bus, el bus se saturará cuando varias CPUs estén utilizandolo demasiado. En vez de eso, con CSI cada procesador accede a parte de la memopria, y para acceder a la memoria de otros procesadores se utiliza CSI, esto elimina el cuello de botella del bus central. Además, Intel usará CSI para crear servidores que permiten utilizar tanto Xeones como Itaniums en una misma placa con tan solo cambiar la BIOS.



• SMT, o lo que es lo mismo, dos threads por cada núcleo, tipo HT. HT era una buena idea, a pesar de lo que diga alguna gente. Ahora, con la moda multicore que provocará que se cree software multihilo orientado a entornos multiprocesador, SMT permitirá utilizar mejor el SMT.

¿Por qué las segundas descargas comienzan lentas?

Quizás con las conexiones modernas no se note demasiado, pero con un modem de 56k si que se sigue notando. Me refiero a la siguiente curiosidad que muchos sabrán y otros no y que me apetece contar: No estás utilizando la red y empiezas a bajarte algo, y la conexión pronto llega, si el servidor tiene el ancho de banda suficiente y la ruta entre él y tu equipo es adecuada, a su "tope". Sin embargo, si según te estás bajando ese archivo comienzas a bajarte otro, este segundo archivo comienza bajándose a un ancho de banda bajísimo, ridículo, que aumenta progresiva y lentamente al mismo tiempo que el ritmo de descarga del primer archivo disminuye. A veces, si la primera descarga baja muy rapido y/o la luna está en cuarto creciente, la segunda descarga empieza tan lento que simplemente no llega a empezar: Salta algún timeout en algún lado y se cierra la conexión. ¿Por qué ocurre todo esto?

La respuesta está en un control de congestión que se implementa en todas las pilas TCP/IP. Pero como tantas otras cosas, tiene su historia.

En los albores de internet, no existía ningún tipo de control de congestión verdadero. Simplemente se mandaban los paquetes a la máxima velocidad que daba de si la interfaz de red. Si la interfaz del receptor era muy lenta y no podía recibir todos los paquetes a esa velocidad, simplemente se perdían los paquetes (la red no es como un embudo: si metes más informacion de la que cabe no se "acumula", se pierde lo sobrante). El rápido emisor reenviaba lo perdido, y continuaba mandando más, hasta el proximo embotellamiento.

En los albores de internet esto funcionó bien, pero cuando creció internet este problema se hizo muy grande. Sospecho (no lo he confirmado, pero mi sentido arácnido me dice que mis sospechas son ciertas) que los orígenes del problema vinieron de la propia expansión de internet: En un inicio había pocos ordenadores conectados a internet, las redes eran financiadas por caros proyectos de investigación y siempre estaban a la última y tenían velocidades parecidas. Los embotellamientos no eran un gran problema. Pero cuando internet creció, las diferencias de capacidad entre unas redes y otras se acrecentaron. Y hubo que crear mayores redes de interconexión entre las principales redes, que a veces tenían menor ancho de banda que los equipos: Por mucho que un emisor y un receptor tuvieran una conexión de X KB/s, si entre ellas había una red con X/2 KB/s, la conexión solo iba poder ir a X/2 KB/s.

Esto hizo que en el 86 y en adelante empezaran a detectarse auténticos colapsos de internet, pérdida masiva de paquetes. Era imposible enviar datos a ciertos sitios y era imposible descargarse emacs de una vez, había que bajarselo en trocitos. En aquellos tiempos las grandes interconexiones de backbones de Internet iban a 56 Kbps. Cundió la duda: ¿Era TCP incapaz de escalar a mayores velocidades? ¿Había que rehacer toda la tecnología? ¿Dónde estaba el fallo? La solución se dió en la reunión USENIX de 1989. Se presentó una charla titulada "Congestión Avoidance and Control", que presentaba una serie de algoritmos, que fueron implementados en forma de parche en los sistemas operativos que controlaban los grandes núcleos de internet - BSDs. Se hizo un RFC que ordenaba literalmente implementar este sistema de congestión de control. Una de las personas que había escrito ese documento se llamaba Van Jacobson. Ha trabajado toda la vida en TCP/IP, ha escrito importantes documentos y ha colaborado tambien en varios RFCs. Los que hayan utilizado alguna vez un modem, ¿han oido alguna vez manejando pppd de una compresión de cabeceras IP apodada "VJ compression"? Pues las iniciales VJ pertenecen, efectivamente, a Van Jacobson. Por cierto: Este tipo aun trabaja en asuntos de TCP/IP, utiliza mucho con Linux, dice que Linux tiene la pila TCP/IP más rápida y mejor del planeta -esto va por los que dicen que Linux es un SO de juguete-, e incluso presentó una charla sobre una proposición de diseño de la pila tcp/ip para aprovechar las capacidades del hardware del futuro.

Pero me desvio. ¿En que consistía el sistema de control de congestión? Es un sistema simple: La técnica se apodaba "slow-start". Se empezaba mandando un paquete. Si el paquete llegaba correctamente -según el protocolo TCP, el receptor debe confirmar con un ACK la llegada del paquete-, la próxima vez se enviaban dos paquetes: Uno por el paquete por el que llegó el ACK, y otro más que se añade. Si esos dos llegaban bien, la siguiente vez se mandaban cuatro: dos por los ACKs, y otros dos que se añaden, uno por ACK. Etc. Cada conexión guarda en una variable el número de paquetes enviados, para saber cuantos necesitaba enviar la próxima vez. Asi, se comienza la conexión progresivamente, hasta llegar al límite de la conexión entre los dos equipos. Cuando se llegaba al límite -dejaban de llegar paquetes correctamente al receptor-, entraba en juego el control de congestión: en vez de incrementarse tan rápido se incrementaba más lentamente. ¿Y como se detecta la congestión? Pues cuando ocurre un timeout (no llega un ACK para un paquete en un tiempo limitado), se anota en una variable ssthresh (independiente para cada conexión) la mitad de la otra variable, la que controla el numero de paquetes que se envian, y se resetea la cantidad de paquetes que puede enviar la conexión a uno, desde el principio. Mientras la cantidad de paquetes sea menor que sshtresh, se sigue haciendo "slow-start", cuando llega a sshtresh -la mitad del ancho de banda que nos hizo llegar a un timeout anteriormente- se comienza a incrementar lentamente: control de congestión.

Es decir, aunque matemáticamente sea algo más dificil de entender, hace lo obvio: Manda paquetes hasta que ve que la conexión no da mas -se detecta un timeoput- y entonces empieza a enviar menos y a dejar de aumentar rapidamente el ritmo. A día de hoy existen algoritmos mucho más complejos y muy diferentes, optimizados para diferentes situaciones -en redes wireless hay muchas pérdidas de paquetes por razones distintas al ancho de banda, y con el slow-start el rendimiento es subóptimo- pero todos tienen algo en común con éste: El control de congestión.

¿Como se refleja esto en nuestras descargas, que es lo que motivó esta entrada? Fácil: Cuando empezamos a descargar un solo archivo, la velocidad aumenta rápidamente. Pero si estamos descargando un archivo y empezamos a descargar otro, la situación es distinta: La conexión ya está aproximadamente en su máximo. Eso provoca que la segunda conexión empiece a perder paquetes al no caber más datos en la conexión. El servidor que envia el segundo archivo, al detectar los timeouts provocados por las pérdidas, baja la velocidad de la conexión para adaptarse, y la aumenta lentamente, para controlar lo que él cree que es "congestión". Al mismo tiempo la primera descarga, ante este pequeño incremento de ancho de banda por parte de la segunda descarga, empieza a perder paquetes, con lo cual el servidor del primer archivo baja un poco la velocidad de envio. Y así es como más o menos las dos descargas empiezan a equilibrarse. A veces no llegan a equilibrarse, todo depende de mil factores, pero el sistema básico es este.

(Otra) Entrevista a Linus

Informationweek acaba de publicar esta minientrevista a Linus donde le preguntan por qué le gusta tanto la GPL v2. He aquí un extracto soberbio que resume lo que muchos pensamos sobre el software libre:

"Finally, the real basic issue is that I think the Free Software Foundation simply doesn't have goals that I can personally sign up to. For example, the FSF considers proprietary software to be something evil and immoral. Me, I just don't care about proprietary software. It's not "evil" or "immoral," it just doesn't matter. I think that Open Source can do better, and I'm willing to put my money where my mouth is by working on Open Source, but it's not a crusade -- it's just a superior way of working together and generating code."

Noticias flash

Fujitsu ofrecerá una opción para tener discos flash, en portátiles. 700$ por 16 GB y 1200$ por 32G.

Es carísimo, por supuesto, pero tambien ofrece más rendimiento en muchas tareas que un servidor con unos discos duros que hayan costado ese mismo precio.

Magnífica maniobra comercial...contra Google y Firefox

Microsoft ha renunciado a atraer clientes con un buen producto. Van a ofrecer descuentos (es decir: pagarán) a las empresas que cambien a utilizar su buscador. Puede llegar a pagar entre 2 y 10 dólares por ordenador, más 25.000 por meterse en el programa. Las empresas que se gastan cientos de miles de dólares en productos Microsoft encontrarán, evidentemente, la oferta muy atractiva.

Hay un problema con esta aproximación: la gente utilizará live search por dinero, no por su calidad. Me recuerda a la política económica de Chávez, que en lugar de crear un pais donde la gente pueda ganar el suficiente dinero como para cubrir todas sus necesidades si ayudas, les paga todo. En vez de crear algo que genere dinero, regala el que tienes, mientras lo tengas. Tengo una sugerencia para Microsoft: Que hagan un buen buscador, y la gente lo utilizará. La gente no utiliza masivamente Google precisamente por la misma razón por la que utiliza Windows. Todo el mundo puede dejar de usar google mañana mismo, y microsoft ha metido en Windows todo tipo de sugerencias anti-google en messenger y Windows, y ya ves. Por cierto, el número de equipos incluidos en el programa se controla por un ActiveX -esa tecnología del siglo XXI- en el IE que manda los datos a Microsoft. Eso significa que ya de paso, atacan a Firefox en el entorno corporativo.

Pero me descentro: me parece absurdo pagar para que utilizen tu producto. Desde luego que convence a la gente, pero no necesariamente construye futuro. Lo más cómico del programa de Microsoft son los "programas" que han diseñado para "educar" a los trabjadores. Hay diferentes niveles: bajo, medio y alto. El alto y el medio incluyen, además de formación para saber sacar lo mejor de Live Search, instrucción para enseñar a los trabajadores como quitar barras del navegador (incluida la de google, claro), y como poner live search como página por defecto en el navegador.

Red Hat 5

Hoy se acaba de presentar Red Hat 5. Espero que sea un éxito, puesto que como ya he recalcado aquí múltiples veces, Red Hat mantiene en gran medida muchas de las piezas mas básicas de Linux: son los mayores contribuidores al kernel, la libc, gcc, herramientas de enlazado y derivados, etc. Además, colaboran muy activamente en GTK/GNOME, o X.org, por poner un ejemplo. Sin Red Hat, el éxito de Linux sería incomprensible.

Algún desinformado dice que no se la puede bajar, y que por eso Red Hat ya no es libre. Esta creencia, ampliamente extendida tanto en el mundo Windows como en el mundo Linux -especialmente desde que dejó de producir la Red Hat de antes, que tuvo su fin con Red Hat 9- no tiene ningún sentido. Aquí están las fuentes completas de Red Hat Enterprise Linux: No te proporcionan imagen iso, te proporcionan las fuentes, que es lo que la GPL exige. Los desarrolladores de software libre quieren los parches correspondientes a su proyecto, no otra distro, que ya tienen la suya propia. A partir de esas fuentes puedes compilar y hacerte tu imagen iso; eso si, la marca Red Hat está protegida, no se puede redistribuir libremente su marca, por lo que debes eliminar los logotipos de Red Hat en los logos o donde sea. Que es lo que hacen -busca en google, no voy a andar dando siempre todos los enlaces- en centos y whitebox linux.

Y eso es todo. Espero Que Red Hat Tenga Mucho Éxito Con Este Nuevo Producto (TM). RHEL 5 está basada en linux 2.6.18, glibc 2.4 y gcc 4.1, una mezcla explosiva que disparará sus índices de productividad con la misma fuerza con la que hacen disminuir sus costes. ¿A Qué Está Esperando? (TM)

Discos flash de Intel: Bye bye, discos duros

Ramón Rey me ha pasado un enlace donde se anuncia que Intel sacará discos duros Flash. Como ya he dicho alguna vez, cuando escribí "El fin de los discos duros" (un artículo horriblemente redactado, dicho sea de paso), nunca pensé que esto iría tan rápido.

Intel anuncia una unidad Flash de 1 a 8 GB con una velocidad de 28 MB/s conectable por una interfaz USB. El tipo que ha escrito el artículo lo compara con las unidades de disco duro "low end", pero miente, o al menos es inexacto. En primer lugar, esos 28 MB/s son continuos, no les afecta la necesidad de mover el "brazo" del disco duro, porque simplemente no hay brazo. Las velocidades de los discos duros mecánicos de hoy son pura propaganda: Alcanzan esas velocidades, pero en benchmarks sintéticos que siempre son secuenciales. En el mundo real casi nunca las cosas son secuenciales. Mi disco duro SATA de hace unos años y 120 GB no pasa de 1 MB/s en un test de varios threads simultaneos de tiobench que acabo de pasar. La memoria flash no tiene brazos, por lo que las velocidades son muchísimo más estables. La realidad es que esta "mierdecilla" de disco flash es capaz de batir a tu, a mi disco duro en una carga pesada de bases de datos.

Segundo: esta es la primera versión de esta tecnología. Habrá que ver a que velocidad aumentan las futuras unidades, porque la verdad: Las unidades de disco duro mecánicas no han avanzado demasiado en estas últimas décadas. Aqui no tienen que subir las rpm y buscar maneras de que el brazo se mueva mas rapido, solo tienen que mejorar los componentes electronicos, que como bien sabemos mejoran muy rápido.

Por si fuera poco, Intel garantiza que el principal inconveniente de las memorias persistentes flash, que es que dejen de funcionar despues de un numero de reescrituras, está solucionado: el tiempo medio entre fallos esta en 5 millones de horas. Y mejorará con los años porque toda la industria está inviertiendo y anunciando nuevos tipos de memorias flash persistentes.

Y como final, el detalle comercial que quizás algunos alguno no hayan percibido: Este disco duro es el primer disco duro de Intel. El mercado de los discos duros no se a cuanto asciende, pero fijo que son muchísimos millones, juzgando el número de empresas que viven de ello. Eso significa que Intel quiere convertirse en un vendedor líder de discos, probablemente de sistemas AMD incluidos. Los discos duros están pasando de ser algo "mecánico", en lo que intel no está especializado, a algo basado en chips. Y en ese campo Intel tiene ventaja, tanto por experiencia como por fábricas, adquisición de materiales, canales de distribución. Intel se acaba de tirar a la yugular de las compañías de discos duros con este producto que para mas inri, consume menos energía de la que es necesaria para mantener un disco duro girando a 7.200-10.000 rpm, algo que esta muy de moda. Algunos directivos no dormirán bien esta noche.

Hans Reiser, culpable de asesinato

Muchos probablemente ya sabían que Hans Reiser, progamador principal de reiserfs y reiser 4, había sido detenido y acusado de asesinato de su ex-esposa, Nina Reiser. Pues bien, el juicio ya ha terminado o está a puntito de hacerlo, y la sentencia le considera culpable. El artículo que he enlazado, menciona que Hans Reiser compró, justito despues de la desaparición de su esposa, libros con títulos como "Masterpieces of Murder" o "Homicide: A Year on the Killing Streets". Podría ser que Hans fuera aficionado a la literatura de temática policiaca, pero al parecer esa afición surgió justito despues de la desaparición de su esposa.

Claro que el hecho de haber encontrado restos de sangre de Nina Reiser en el coche de Hans, la misteriosa desaparición del asiento del pasajero cuando la policía fue a registrarlo, la cinta aislante y bolsas de la basura que encontraron en el coche, las señales de haber lavado las alfombrillas del coche recientemente, el testimonio del hijo común de ambos que aseguró que había oido a ambos discutir y que despues cambio su declaración, el que se le viera salir de su casa a la hora estimada del asesinato, y el que fuera vox populi que se llevaba con su ex como perro y gato, no han ayudado mucho en defensa.

He leido muchos correos de Hans Reiser en la del kernel, incluso he intercambiado alguno. En los últimos tiempos, cuando Hans pedía la inclusión de Reiser 4 y se le indicaban por qué aun no estaba preparado, se le notaba un tono muy radical con casi todo el mundo: Si lo llego a saber me voy a BSD, etc. Tambien lei algún correo en el que contaba que Namesys, su empresa creadora de reiserfs, las estaba pasando canutas en temas de dinero, que hacía años que tenía deudas, y que la actitud de la comunidad linux tiraba piedras contra su propio tejado no incluyendo reiser 4, que era un paso necesario para que Namesys pudiera empezar a ganar más clientes. Su modelo de negocio era vender plugins para su sistema de archivos basado en plugins, un modelo absurdo en mi opinión. Lo que hacía Reiser era investigación, lo cual está muy bien pero no da beneficios. Lo ideal es que hubiera intentado ser comprar por una distro (quizás lo intentó) que financiara sus esfuerzos.

Tambien he criticado aqui Reiser 4 y reiserfs (que no es que mi opinión cuente demasiado). Sin embargo Hans Reiser merece su reconocimiento. Su implementación de Reiser 4 es demasiado opuesta a los gustos de la mayoría de hackers del kernel, pero la idea de la que partía era legítima.

Hans Reiser intentó hacer evolucionar los sistemas de archivos a algo nuevo, que solucionara los problemas que hay en los sistemas de hoy. Una de sus frases que más me gusta es: "el que existan bases de datos es un síntoma de que hay algo mal", o algo así. Tomemos por ejemplo el Spotlight de Apple, Beagle o "Google desktop search". Todos ellos buscadores de escritorio. ¿Cual es su objetivo? Básicamente e ignorando el problema de los formatos, hacer "grep" en tus datos. Para poder hacerlo, ¿que se hace? Se construye un indice en un archivo. Es decir, se hace un índice de los datos que ya tienes en el sistema de archivos. Y las bases de datos, ¿qué son? En esencia, sistemas de archivos: tienen un espacio, y en el organizan datos y los devuelven cuando se les pide con una interfaz diferente a los jerárquicos. Para mas inri, normalmente las bases de datos tienen sus archivos en otro sistema de archivos: Es decir, para atender una búsqueda tienen que manejar las estructuras de su sistema de archivos y despues hacer peticiones a otro sistema de archivos.

Hans Reiser tenía una visión: Un sistema de archivos 'genérico' capaz de funcionar como sistema de archivos jerárquico, como base de datos, y que fuera capaz de hacer búsquedas como las que hace spotligth, pero sin tener que indexar nada: Los datos están en el sistema de archivos, ergo el sistema de archivos debería saber buscar mejor que nadie la informacion sin necesidad de hacer un índice adicional de esos mismos datos. Idem para las bases de datos. Quería buscar una interfaz genérica capaz de hacer todo tipo de consultas. No se puede negar: Puede que reiser4 no fuera la implementación adecuada de esa idea (entre otras razones, por ser de los primeros sistemas de archivos que lo implementan y estar avanzando en territorio desconocido), pero la idea era (es) genial.

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.