Eliminando la mitad del driver de Intel

Via Phoronix, leo este recomendable post del blog de Keith Packards. En él explica los cambios radicales que ha sufrido el driver para chips gráficos Intel en los últimos tiempos, en los que se ha rediseñado casi por completo todo el "stack" gráfico de Linux. Sin embargo, parece que mantener el soporte de ambos sistemas, el viejo y el nuevo, ha causado problemas de estabilidad y rendimiento. Por ello han tomado la decisión de eliminar en las próximas versiones todo el soporte del antiguo sistema, lo cual parece ser que reducirá el tamaño del driver...¡en un 50% o más!

Gloria a los programadores de Intel.

¿bzip2, condenado a desaparecer?

Me he encontrado con este magnífico post sobre herramientas de compresión. Concretamente, gzip, bzip2 y lzma, el algoritmo que usa el cada vez más famoso 7-zip. Cuando se intenta conseguir la ḿaxima compresión, gzip es, como cabía esperar, el más veloz (lo cual es importante) y el que menos comprime, LZMA el más lento y el que más comprime, y bzip2 se queda en medio de los dos. Nada del otro mundo: A más esfuerzo, más compresión, lo que cabía esperar.

Sin embargo, las conclusiones sorprendentes vienen cuando se varían las opciones: LZMA en su modo de peor compresión es más rápido y comprime más que bzip2 en su modo de mayor compresión. Si se sube un solo punto a lzma, comprime bastante más que bzip2 en solo un poquito más de tiempo. Esto quita todo sentido a la existencia de bzip2...

Oracle + Sun = Dura competencia para Linux

Tras el fallido intento de IBM de comprar Sun, viene ahora la segunda parte: Oracle compra Sun. Esta vez no es un mero rumor, se ha confirmado oficialmente.

Las consecuencias de esta compra son muy diferentes de lo que pudieran haber sido si hubiese sido IBM el comprador. Oracle es, en gran medida, Larry Ellison (ya no manda tanto, pero al igual que Jobs en Apple, su personalidad parece confundirse con la compañía), un tipo muy agresivo y decidido a la hora de hacer negocios, muy estadounidense, de caracter reaganita. Su obsesión, declarada públicamente en reiteradas ocasiones, es acabar con Microsoft. "IBM es el pasado, Microsoft el presente, Oracle el futuro", decía hace tiempo. Odia el PC actual, quiere que pasen a ser clientes tontos conectados a la red y que ejecuten software en centros de datos. "El NC [networked client] es parte de nuestra estrategia para destronar a microsoft". Estas cosas las decía hace 10 años, asi que imagínense como debe estar de contento con la cosa de la Web 2.0 y las "clouds". Esas "nubes", esos centros de datos donde funcionaria el software real estarían, por supuesto dominadas por Oracle al igual que hoy los escritorios lo están por microsoft. Su intención ha sido siempre esa: cargarse a MS, ser más rico que Gates, y lo demás le importa un pimiento, y si bien ha apoyado muchísimo el software libre cuando le ha convenido, cuando se ha interpuesto en su camino ha cargado contra él como pocas empresas han hecho. Y basten un par de ejemplos para demostrarlo.

En 2005, el crecimiento de MySQL empezó a molestar a Oracle. Aunque esta base de datos libre está orientada a un mundo completamente distinto que el gigante de Oracle, no deja de ser una base de datos con mucha capacidad de evolución que forma parte del mismo universo que a Oracle le interesa controlar completamente. Ha ganado mucho uso como base de datos "gratuita" y/o barata (lo cual recorta los márgenes de Oracle en clientes que buscan cosas baratas). De la noche a la mañana, Oracle compró Innobase, el mejor "motor" existente para MySQL (y anteriormente habian comprado otro), con intenciones hacia MySQL que nadie interpretó como buenas, sino como un intento de ahogarles o como mínimo de tenerles bajo control; aunque no rompieron (ni han roto aun) el acuerdo que permitía a MySQL utilizar el producto. Pero como reacción, MySQL se vió forzada a comenzar a desarrollar de cero un motor propio, por si a Oracle les da por dejar de negociar el uso de InnoDB, o por si deja de añadirle mejoras en el futuro.

Otro caso: En 2006, Red Hat compró Jboss, una compañía/producto que Oracle tambien estaba intentado comprar, y que le interesaba mucho. La reacción cuando Red Hat se lo quitó de las manos sin que se dieran cuenta fue furibunda: cinco meses tras la compra, anunciaron una nueva distribución de Linux, que era un clon de Red Hat, un CentOS con logo de Oracle, llamada "unbreakable linux". Su propósito -y lo que dijo al anunciarlo lo dejó bastante claro- no era tanto dedicarse al negocio del soporte Linux, sino atacar el modelo de negocio de software libre de Red Hat para dañar a la empresa que le había quitado Jboss (con la intención de hacerla pasar un mal trago y quizás comprarla, o al menos evitar que prospere). Ellison creía que si Oracle sacaba una distro clonada de Red Hat y ofrecía soporte a precios más baratos que Red Hat, matarían su negocio, pues ningúna empresa querría comprar las caras suscripciones de soporte de Red Hat si podían conseguirlo soporte del mismo producto de mano de Oracle y por mucho menos dinero. Un 60% menos, concretó Ellison. El plan era tan descarado que dijeron que esperarían a que Red Hat sacara sus parches de seguridad y fallos graves, se bajarían el código fuente del FTP de Red Hat y la compilarían para su distro, para ser totalmente compatibles:

"I don't think Red Hat is going to be killed... I'm sure they are going to compete on quality of support. This is capitalism, we are competing. We are trying to offer a better product at a lower price. We expect them to improve their product and price."

Si este plan hubiera tenido éxito, habría demostrado que el software libre no es viable comercialmente, pues no existiría nada que empresas como Red Hat pudieran hacer para convencer a sus clientes de que les paguen dinero, eliminando de ese modo las inversiones en programadores que son absolutamente imprescindibles para que el software libre mejore. Afortunadamente, Ellison no entiende el modelo de negocio del software libre, y su distro no afectó económicamente a Red Hat lo más mínimo, pero este ataque al corazón del modelo de negocio del software libre es algo que ninguna compañía había intentado hasta entonces.

Sin embargo, Oracle al mismo tiempo se ha convertido en los últimos años en uno de los principales contribuidores de código a Linux: Btrfs, OCFS2, CRFS, RDS...pues le interesa el progreso de Linux frente a Microsoft.

Ahora Oracle se ha hecho con Sun, lo cual implica que se mete en el bolsillo MySQL, Solaris, Java, Openoffice.....respecto a MySQL, nadie se sabe que hará Oracle con ello. No descarten las opciones menos agradables. Respecto a Solaris, me parecería predecible que Oracle lo promocione y potencie como sistema operativo ideal para su base de datos, que entre en competencia con las distribuciones Linux y que cese completamente su apoyo a Linux, por mucho que digan ahora lo contrario. ¿Para qué gastar recursos en desarrollar mejoras que van a comercializar sus competidores? Pero por otra parte el progreso de Linux daña a algunos de sus enemigos, asi que quien sabe. De todos modos, en caso extremo de que abandonaran proyectos como btrfs, Chris Mason podría abandonar -si él quiere- su trabajo e irse a una compañía como Red Hat.

Respecto a Java, Oracle tiene muchos productos que usan ese lenguaje...pero IBM y Red Hat tambien. Java es un lenguaje muy importante en las empresas, y apostaría que alguien de IBM está dándose cabezazos contra la pared por haber perdido la oportunidad de conseguir el control de Java a manos de una empresa que ha pasado de vender una base de datos a vender todo un conjunto de productos -hardware, SO, lenguaje, software variado, base de datos- capaz de competir con ellos. Respecto a Openoffice...vaya usted a saber, pero Ellison odia a Microsoft y sabe que su fantasía de un mundo de "clientes tontos" pasa por matar a Office, la gallina de los huevos de oro de su archienemigo, asi que quizás tengamos sorpresas y apuesten por ello DE VERDAD (no como Sun), solo por el placer de matar a los ingresos de su enemigo.

En resumen: Esta compra significa malas noticias para Linux, y parcialmente negativas para el software libre. Oracle apoyará el software libre cuando le convenga, pero cuando no le convenga no se va a andar con chiquitas. Y su mundo ideal dominado por Oracle implica código cerrado y bien controlado.

Sobre Gnome 3.0

Una de las noticias más importantes que se han visto en estas últimas es la decisión oficial de desarrollar Gnome 3.0. Tras algunos años de quejas particulares, rumores varios y proyectos paralelos todos relacionados o relacionables con el futuro de Gnome, al final se han echado la manta a la cabeza.

En realidad, no parece haber ninguna intención de rehacer el escritorio de cara al usuario por completo, sino hacer en gran medida como hizo KDE: rehacer parte del shell (el panel, gestor de ventanas, etc) y reorganizar las librerias para eliminar el desbarajuste que inevitablemente va surgiendo en un proyecto tan grande cuando está forzado a no romper el ABI, además de mejorar algunos aspectos de GTK/GLib (incluyendo introspección para GObject- OMG!), además de estar aparentemente interesados en llevar el tema de las animaciones 3D más allá del gestor de ventanas.

Respecto al shell proponen sustituirlo con Gnome Shell, que unifica parte del panel y el gestor de ventanas en una sola cosa. La idea no parece ser mala -unificar todo lo que es el shell de un escritorio en una sola aplicación no es ningún sacrilegio-, pero aun está por ver si será una mejora radical, o se quedará en algo que reemplace el shell actual sin añadir nada interesante que lo haga más atractivo que éste. Un detalle interesante es que está hecho con clutter, una librería de "animación" al estilo de Core Animation cuyas capacidades se contemplan mejor en este video (que es la interfaz gráfica de moblin, la distribución "móvil" creada por Intel). Aparte de esto, no parecen tener intención de retocar más aspectos del shell como los programas que gestionan el fondo de pantalla (aunque, insisto, el desarrollo será largo y nadie sabe todo lo que se acabará haciendo).

Otra propuesta, y no tan interesante como la anterior, es Gnome Zeitgeist, al que yo no le veo un gran futuro. Y es que los desarrolladores de esta cosa son los programadores número 8218321095435643232 que han decidido, por inspiración del espíritu santo, que los sistemas de archivo jerárquicos, o sea, los directorios y los archivos, son malos, y hay que acabar con todos ellos en el Nombre De La Sagrada Usabilidad. Para lograrlo, ellos, los Caballeros del Sagrado Código, se sacarán de la manga un nuevo framework que dejará atrás ese infiel concepto de los directorios y nos traerá como sustitución algo que estará centrado alrededor de lo que verdaderamente importa: El Documento (tm). El pequeño problema de esta idea es que entre los bravos caballeros que ya cabalgaron por esta senda se incluyen WinFS y Reiser4, y mi opinión es que el destino que aguarda a Zeitgeist es el mismo que a ellos, por muchas razones. Los sistemas de archivo jerárquicos no son una mierda, son terriblemente prácticos e intuitivos, de ahí que sean el estándar en todos los SO que importan. El éxito del simplísimo indexador spothlight frente al intento de rehacer el mundo que fue WinFS debería servir de ejemplo...

Aparte de esto, y de la intención de usar más clutter, no parece haber muchos más planes (tampoco los hubo en kde 4) además de los propios de un evento así: Renovación del aspecto externo (themes, iconos), aproximación hacia otras plataformas (Mobile) o Windows, mayor uso de cosas como dbus, cosas anteriormente opcionales como Webkit que se vuelven un requisito y debido a ello se empiezan a utilizar más...

Uno de los aspectos más polémicos de Gnome, y uno de los que no veo cuestionar, es la cuestión de "la plataforma", es decir, la famosa discusión sobre seguir solo con C en la base, o centrarse en C#/Java. Esa discusión no parece que vaya a evolucionar en ningún sentido: Gnome 3.0 será C puro, y ofrecerá bindings a otros lenguajes, como siempre. Sin embargo, hay una novedad muy interesante en este campo, que es Vala. Vala es un clon de C#, pero que no es un lenguaje completo, sino que lo que se escribe con él se traduce a C, usando GObject como recurso para implementar los objetos. Se trata de un hack horrible...pero a pesar de sus defectos es algo muy práctico para Gnome: Permite resolver el problema de utilizar un lenguaje de más-alto-nivel, y al mismo tiempo soluciona el dilema de dejar de usar C en la plataforma base, pues los objetos creados en Vala son accesibles automáticamente a otras aplicaciones en C con GObject, y por tanto a todos los demás bindings. Yo creo que es inevitable que con el paso del tiempo Vala se convierta en EL lenguaje para crear aplicaciones Gnome, porque todos los dilemas y flames que existen sobre estos temas son como una masa de agua tempestuosa encerrada en una piscina sin posibilidad de escapar, y Vala es el único agujero por donde pueden escaparse las aguas.

Mucho, mucho ruido sobre Ext4...

Habrán leido desde hace unas semanas un montón de artículos sobre un supuesto problema de Ext4. En la mayoría de sitios la cosa ha degenerado hasta el punto de hablar de corrupción de datos. Y se ha oido decir eso de que Ext4 es aun muy nuevo, y lo de que yo me quedo de momento con Ext3 que es más seguro. Pues aquí voy a contar un par de cosas sobre este divertido asunto.

En el Mundo Real (tm), todos los sistemas operativos retrasan las escrituras por cuestion de rendimiento. Eso quiere decir que cuando un programa usa write(), o llama a close(), y la llamada retorna, el SO no garantiza que se haya escrito nada en el disco. Los datos están en memoria y se escribirán físicamente más o menos tarde, pero si antes de eso hay un corte de luz los datos se pierden y punto.

Así es como funcionan todos los SO. El journaling y las técnicas usadas por ZFS y btrfs y demás compañía están orientadas solo a garantizar la integridad del sistema de archivos, no que los datos hayan llegado al disco o no. De hecho, todos los sistemas de archivos modernos, como Ext4, XFS, ZFS o btrfs, utilizan "Delayed Allocation", lo cual significa que retrasan la escritura de datos al disco muchísimo más de lo normal, incluso minutos. Si una aplicación quiere tener una garantía inequívoca de que los datos están en el disco -y a la mayoría de aplicaciones no le importa-, POSIX dice que ha de utilizar fsync() (o la función sync_file_range() en Linux, que es mucho más potente). Cuando esa llamada al sistema finaliza, entonces si que se tiene la garantía de que los datos están en el disco (y solo cuando finaliza, pues si se va la luz mientras se está ejecutando, tambien se pueden perder datos)

El problema principal ha surgido a partir de algo que suelen hacer muchos programas para actualizar un archivo. Leen el archivo, modifican los datos, escriben los nuevos datos a un archivo aparte, y finalmente hacen un rename("archivo_con_datos_modificados", "archivo"), y de ese modo actualizan el archivo de configuración "atomicamente". Pero al renombrar el archivo se crea un nuevo inodo, que no tiene bloques de datos asociados -están en la memoria-, por lo tanto si antes de escribirse los datos se va la luz, el archivo aparecerá con 0 bytes, es decir, vacío. Esto es especialmente notable con Ext4 y todos los sistemas de archivo que utilizan delayed allocation, pero tambien existe el riesgo con Ext3, aunque el riesgo es mucho menor porque cada 5 segundos se sincronizan los datos de la memoria con el disco.

La solución "correcta" es usar fsync(). Pero la presión de los desarrolladores y de la enorme cantidad de programas que no usan fsync() y de Linus -que se ha puesto de su parte, diciendo al estilo británico que para bien o para mal las costumbres han de ser ley- ha forzado a añadir a Ext4 un hack que consiste en hacer un fsync() implícito cuando un programa usa rename() o truncate() (otro de los casos problemáticos). Así, los programas que no hacen fsync() no dejarán archivos de tamaño cero por ahí. Pero esto tambien hará que los programas que ejecutan esas funciones frecuentemente, como rsync, pierdan rendimiento. Pero como es lo que la gente ha pedido, toca fastidiarse. Eso si, otros SO no usan este truco, asi que esas aplicaciones tendrán problemas en esos otros sistemas.

Como se puede ver, no es que Ext4 "corrompa datos", sino un comportamiento de las aplicaciones que Ext4 tan solo ha puesto de manifiesto. Muy cierto es, sin embargo, que de cara al usuario, lo que se encuentra ante un reinicio son archivos sin datos, y eso es un problema muy grave del que se libra en gran medida usando Ext3 y su sync() implícito cada 5 segundos, y no es menos cierto que para Ext4 ese hack es la solución más práctica al problema. Pero de ahí a los titulares que se han leido de corrupcion de datos por ahí va un mundo. De hecho, a pesar de este asunto, Ext4 es mucho más seguro que Ext3, debido a que activa las "barreras" por defecto. Y eso es otro asunto muy interesante....

Al igual que el sistema cachea las escrituras en RAM, el disco retrasa en su propio cache (16-32 MB en los más modernos) las escrituras. Además no necesariamente escribe los datos en orden de llegada. Los sistemas de archivo a menudo envían al disco peticiones de escritura con caracter síncrono, es decir, que cuando la funcion retorne se tenga la garantía de que los datos están en el disco. Pero cuando no utilizan barreras -que es una especie de fsync() interno del kernel, solo que a nivel de bloques y peticiones al disco en vez de a nivel de descriptores de archivo-, tan solo creen tener esa garantía, y continuan mandado datos a pesar de todo. En caso de corte de luz, esos datos pueden llegar a perderse, o escribirse en diferente orden, y generar corrupción. En cambio, con barreras se utilizan unos comandos especiales del disco para asegurarse de que los datos fueron grabados físicamente, y por tanto en caso de corte de luz no hay posibilidad de sorpresas.

Pues bien, como Ext3 por defecto no usa barreras (fundamentalmente, porque afectan una barbaridad al rendimiento) un corte luz puede corromper el sistema de archivos, a pesar del journaling. Se trata de un margen de posibilidad muy pequeño, prácticamente despreciable, pero existente. De hecho, varias personas de Red Hat, Suse, etc, han manifestado en reiteradas ocasiones que activar las barreras por defecto ha supuesto para sus empresas una reducción notable de "casos extraños de corrupción". Ext4 sin embargo activa el soporte de barreras por defecto (sin afectar demasiado al rendimiento). Esto, sin embargo, no ha salido a relucir en ninguno de esos artículos y comentarios que acusaban a Ext4 de corromper datos y que recomiendan Ext3 como opción sólida.

SGI quiebra y es comprada por Rackable Systems (y no es una broma)

SGI ha declarado el "estado de quiebra", y ha sido comprada instantaneamente por Rackable Systems. No, no puede ser una broma del 1 de abril, los reguladores meterían en la cárcel a quien manipulara el mercado de esta manera.

Personalmente, creo que a SGI siempre le faltó una orientación adecuada y algo de suerte. En primer lugar, se obsesionaron demasiado con supercomputadores king-size hechos a medida de agencias gubernamentales como la NASA. Eso daba dinero, pero los gobiernos necesitados de la capacidad de cálculo de esos monstruos ni son tantos, ni andan comprandose uno cada poco tiempo. Precisamente ahora se está viendo un aumento considerable de inversiones en "clouds", es decir, clusters compuestos por equipos más o menos normalitos y dedicados específicamente a dar pie a la cancamusa. SGI podría haber extendido sus actividades a vender esos clusters y haberlo hecho antes que nadie, pero no lo hicieron, se empeñaron en seguir exclusivamente el modelo una-máquina-gigante-que-hace-cálculos y dejaron siempre de lado el bastante más utilizado varias-máquinas-pequeñas-arrejuntadas-que-hacen-pequeños-cálculos-cada-una. Se quedaron en un nicho muy jugoso pero que no ha sido suficiente para salvar la empresa.

En segundo lugar, apostaron mucho por Itanium, que ha demostrado ser en gran parte vapor-hardware (vale, no del todo vapor, ha visto la luz, pero está claro que aparte de algunos nichos muy específicos -que ni tan siquiera son suficientes para pagar la inversión que se mantiene en la arquitectura-, nadie está interesado en el Itanic). No cabe duda que eso les cerró muchas puertas, excluyendo así a todos aquellos que no fueran agencias de investigación gubernamentales con presupuestos bestiales, que son a quienes menos les puede importar invertir dinero en una arquitectura tan rara. Yo creo que algo tuvo que echarles Intel en las bebidas para que no se decidieran más por x86-64, que es la arquitectura más usada en la lista top500 de supercomputadores (en su faceta de cluster, pero son supercomputadores igualmente). Precisamente en estos momentos estaban dando ese paso, preparándose para vender supercomputadores basados en x86-64, pero el remedio ha llegado tarde.

Esta noticia es triste para el mundo Linux porque en los últimos años SGI contribuyó mucho software libre, especialmente al kernel (aunque creo que tambien a GCC), y especialmente mejoras de escalabilidad (la última, incluida en la última versión estable, soporte de 4096 CPUs en x86), y por supuesto XFS y la parte GLX de X.org.

¿Qué pasará ahora? Es posible que Rackable Systems mantenga a los programadores encargados de estas mejoras e incluso que aumente la plantilla y las contribuciones de código, pero tambien puede que no lo haga. Este blog estará atento a eso. Pero tengamos en cuenta que si deciden recortar las contribuciones a Linux y les ponen a trabajar en otras cosas, es muy probable que los hackers se autodespidan y busquen trabajo en empresas que contratan programadores de software libre como Red Hat, Novell o IBM, y de ese modo el software libre no perderá esos talentos. Que por cierto, es otra ventaja del software libre, esa gente puede dejar una empresa e irse a otra donde trabajen en exactamente la misma base de código, algo que no podría hacer un programador de Windows. Estén atentos...