Desde que se publicó el código de ZFS bajo la CDDL, hay unos cuantos sistemas operativos que lo han portado, desde FreeBSD y OS X al propio Linux. Esta portabilidad, por cierto, se debe a que ZFS, más que un sistema de archivos, es una implementación completamente independiente del sistema opeartivo de todo lo relacionado con todo lo que sea I/O. Todos estos usuarios han disfrutado de esta liberación de código, a algunos casi les ha servido de salvavidas (FreeBSD).
Y sin embargo, la compra de Sun por parte de Oracle podría amenazar a todos estos usuarios, al menos en cierta parte, y potencialmente en gran medida. ¿Cómo? Pues porque resulta que hace casi dos años que Oracle no publica el código que desarrolla en privado.
ZFS ha ido añadiendo pequeñas características y cambios de formato con el tiempo. El último código libre que Sun mostró al mundo de ZFS corresponde a la "versión de pool" 28. La última versión de pool disponible en Solaris es la 33. En esas cinco versiones se encuentran mejoras notorias, como el soporte de encriptación y mejoras de rendimiento, y en general dos años de trabajo, pero nada de eso ha llegado a los usuarios de las versiones libres, los cuales se limitan a seguir usando la misma versión de ZFS de hace casi dos años a la cual sólo se han añadido fundamentalmente parches de mantenimiento y mejoras en la integración del port.
En teoría, Oracle es consciente de la situación; aunque abandonaron el desarrollo de OpenSolaris como proyecto abierto se suponía que seguirían publicándo el código abiertamente, y se dice que prometieron cumplir y liberar el nuevo código algún día. Pero en estos dos años, lo más significativo que ha hecho Oracle respecto al software libre es intentar forzar la aplicación del copyright a las APIs de software, que manda narices. No es de extrañar que muchos pongan dudas de que vayan a cumplir su palabra.
Siempre podrían sorprendernos, claro. Pero permítanme explicarles porque tengo mis dudas. Una de las "startups" más exitosas enfocadas hacia el almacenamiento de datos últimamente es Nexenta, que se basa en gran medida en ZFS, y que tras la desaparición de OpenSolaris se encargó de liderar la formación de Illumos. Los ingresos de esta joven empresa crecieron en 2009 un 385%, en 2011 las ventas fueron ya de $300 millones anuales, y este año preveen aumentar sus ventas otro 350%, lo cual les colocaría alrededor de los 1.000$ millones anuales en ventas. Y recordemos que se trata de una empresa joven. Mientras tanto, las ventas de hardware de Oracle, herederas de la antigua Sun, y que no han dejado de caer desde la compra de la empresa, fueron en el primer trimestre de 2012 (ojo, sólo un trimestre) de $453 millones, con una caída interanual del 25%, colocándole en la sexta posición en ventas de servidores.
Ya ven lo que son las cosas: una startup basada en un solaris libre que podría superar en pocos años a las ventas de Sparc de la antigua Sun. ¿Creen ustedes que Larry Ellison va regalar por la cara a Nexenta y otras compañías el código necesario para que sigan haciéndose ricos a costa de la tecnología de la empresa por la que él pagó tanto dinero? Yo tampoco.
No hay duda de que a Nexenta no le debe hacer demasiada gracia ser una empresa de almacenamiento con tantas expectativas de futuro y seguir basándose en un sistema de archivos libre que lleva dos años abandonado a propósito. Tampoco les debe hacer gracia a otros sistemas operativos que usan el port libre. Así que se han unido todos ellos y, según cuentan los mentideros, han formado -aunque el anuncio ya tiene un año de antiguedad- una lista privada con una especie de ZFS Working Group, en el que hacen planes para lo que, esencialmente, sería un fork de ZFS. De momento, ya han sustituido las "pool versions" por un sistema de versionamiento basado en características, al estilo de Ext4. El hecho de que varios programadores de ZFS en Oracle hayan desertado para ser recontratados por empresas que usan ZFS seguramente ayudará a esta operación que a la vista de la evolución de los acontecimientos se hace inevitable.
Pero aun están por dar la cara, demostrar que son capaces de liderar y desarrollar algo por su cuenta, y avanzar. Por el momento, el ZFS abierto sigue con sus dos años de retraso respecto al de Oracle.
25 de agosto de 2012
9 de agosto de 2012
Mejores noticias para Qt
Hace un año y unos meses me pareció una buena noticia que Nokia vendiera la rama de licencias comerciales y consultoría de Qt a Digia, uno de sus "partners" más comprometidos. Por eso me parece una noticia aun mejor que Nokia le venda a Digia el resto de Qt.
El optimismo de este servidor de ustedes no es infundado. En realidad, lo peor que le podía pasar a Qt es no ser vendida. Dado que Nokia ha renunciado por completo a ser una compañía importante en su sector, una que sea capaz de producir su propia plataforma de software en lugar de limitarse a usar la de otros, que Qt permaneciera en sus manos significaba permanecer en un limbo sin objetivo ni propósito existencial bien definido. En teoría, Qt aun tenía sentido para Nokia por su utilidad en Symbian, pero esta venta demuestra que hasta esa plataforma dan por muerta. Los planes de futuro de la compañía ya no preveen mantener a Qt en buen estado.
Digia, en cambio, es una compañía de software, no de hardware, por lo que el bienestar de Qt es muy importante para ellos, y además son conscientes de su potencial. No hay más que leer esta frase del anuncio en la que destacan sus prioridades inmediatas:
Following the acquisition, Digia plans to quickly enable Qt on Android, iOS and Windows 8 platforms.
O, en este otro blog:
we will begin to explore how to introduce support for other mobile targets, Android and iOS, as fully supported platforms for Qt applications.
Y es que Qt podría utilizarse para construir aplicaciones que funcionen en varias plataformas de teléfonos y tabletas modernos utilizando una base de código casi enteramente común, una alternativa muy apetecible a atarse a una sola plataforma en concreto. Esta fue una ventaja incomprensiblemente despreciada por Nokia, pero que Digia, a quien le interesa que Qt sea portable en el sentido pleno de la palabra (para que muchas empresas contraten sus servicios de consultoría), capta a la perfección.
Aun quedan detalles por solventar. Podrían ocurrir cosas inesperadas, podrían toquetear en las licencias para limitar la flexibilidad de la LGPL introducida por Nokia, que tanto valor resta a sus licencias comerciales (ya han dicho que no lo harán, pero la tentación va a estar ahí). Podrían ofrecer complementos propietarios paralelamente al código abierto, al estilo de MySQL. Veremos. Pero de momento, parece que el futuro de Qt está asegurado (y desde luego seguirá habiendo más programadores y más inversión en este toolkit que en GTK/Glib). Pasemos página a la pesadilla de Nokia, y recordemos que Qt 5 está en desarrollo y debería ver la luz el mes que viene.
El optimismo de este servidor de ustedes no es infundado. En realidad, lo peor que le podía pasar a Qt es no ser vendida. Dado que Nokia ha renunciado por completo a ser una compañía importante en su sector, una que sea capaz de producir su propia plataforma de software en lugar de limitarse a usar la de otros, que Qt permaneciera en sus manos significaba permanecer en un limbo sin objetivo ni propósito existencial bien definido. En teoría, Qt aun tenía sentido para Nokia por su utilidad en Symbian, pero esta venta demuestra que hasta esa plataforma dan por muerta. Los planes de futuro de la compañía ya no preveen mantener a Qt en buen estado.
Digia, en cambio, es una compañía de software, no de hardware, por lo que el bienestar de Qt es muy importante para ellos, y además son conscientes de su potencial. No hay más que leer esta frase del anuncio en la que destacan sus prioridades inmediatas:
Following the acquisition, Digia plans to quickly enable Qt on Android, iOS and Windows 8 platforms.
O, en este otro blog:
we will begin to explore how to introduce support for other mobile targets, Android and iOS, as fully supported platforms for Qt applications.
Y es que Qt podría utilizarse para construir aplicaciones que funcionen en varias plataformas de teléfonos y tabletas modernos utilizando una base de código casi enteramente común, una alternativa muy apetecible a atarse a una sola plataforma en concreto. Esta fue una ventaja incomprensiblemente despreciada por Nokia, pero que Digia, a quien le interesa que Qt sea portable en el sentido pleno de la palabra (para que muchas empresas contraten sus servicios de consultoría), capta a la perfección.
Aun quedan detalles por solventar. Podrían ocurrir cosas inesperadas, podrían toquetear en las licencias para limitar la flexibilidad de la LGPL introducida por Nokia, que tanto valor resta a sus licencias comerciales (ya han dicho que no lo harán, pero la tentación va a estar ahí). Podrían ofrecer complementos propietarios paralelamente al código abierto, al estilo de MySQL. Veremos. Pero de momento, parece que el futuro de Qt está asegurado (y desde luego seguirá habiendo más programadores y más inversión en este toolkit que en GTK/Glib). Pasemos página a la pesadilla de Nokia, y recordemos que Qt 5 está en desarrollo y debería ver la luz el mes que viene.
5 de agosto de 2012
Mejorando el volcado de pilas
Una de las mejoras más sencillas y a la vez importantes que se desarrolló en Linux durante la versión 2.5 fue la característica llamada "kksymoops". Hasta entonces, cuando ocurría un "oops" y se hacía un volcado de pila con la lista de funciones que se había ido llamando en cadena hasta llegar al fallo, lo que se imprimía en pantalla no eran el nombre de las funciones, sino su dirección de memoria.
Como las direcciones de memoria varían de un kernel a otro, un volcado de pila con direcciones de memoria era inservible para los desarrolladores. Había que traducir las direcciones a funciones, tarea que hacía el programa ksymoops a partir del archivo System.map del kernel correspondiente, o lo hacía por ti el ya desaparecido demonio klogd si la máquina no se colgaba del todo. Para quienes reportaban bugs esto era un engorro considerable, ya que a menudo tocaba copiar a mano (las cámaras digitales no se habían popularizado) el texto de la pantalla para luego escribirlo en un archivo que ksymoops pudiera leer (algo que era difícil de hacer si no podías arrancar el sistema para ejecutar dicho programa). Para reportar un simple fallo había que molestarse demasiado, y había que explicar a los usuarios novatos vía email como usar el programa ksymoops, etc.
kksymoops, que fue enviado por Ingo Molnar, consistía básicamente en meter el System.map dentro del kernel, qué este podía usar para, en cada oops, traducir direcciones a nombres de funciones. Así, bastaba copiar la lista de funciones para saber qué parte del kernel había causado el problema. El programa ksymoops (y el demonio klogd) se volvieron obsoletos, y reportar fallos en el kernel se simplificó enormemente. El único inconveniente es que hay que emplear unos pocos cientos de KB de RAM en almacenar una tabla de símbolos que rara vez se llega a usar, pero es una minucia y la mayoría de la gente ni tan siquiera es consciente de su existencia.
Esta historieta de tiempos remotos viene a cuento por los volcados de pila de los programas normales de espacio de usuario. Ninguna distro importante compila hoy sus paquetes con la información de depuración activada por defecto, porque el tamaño de los paquetes y las instalaciones aumentaría brutalmente. De modo que el mundo de espacio de usuario está un poco como el kernel en días antiguos, con volcados de pila que son listas de direcciones de memoria poco útiles. Aunque las distros modernas proporcionan paquetes de depuración de instalación opcional pero sencilla, e incluso existen mecanismos de reporte de bugs (abrt) que descargan esos paquetes y crean volcados de pila legibles automáticamente.
Pues bien, todo esto va a cambiar. Un tipo que trabaja para Red Hat ha desarrollado una herramienta que comprime la información de depuración de los ejecutables, lo cual permite reducir su tamaño considerablemente. A pesar de esto sigue siendo un tamaño considerable, pero si además de comprimir se elimina la información de depuración excesiva y se deja tan sólo la necesaria para decodificar nombres de funciones, resulta que una distro puede incluir esta información de depuración básica y comprimida con un coste de espacio aceptable, y de ese modo tener mejores reportes de bug (tanto para la distro como para upstream). Esto será lo que haga Fedora 18, que ya está recompilando todos sus paquetes para compilarlos con esta información.
No hace falta mencionar que esto será utilísimo no sólo para tener mejores volcados de pila, sino para herramientas de análisis del sistema, como por ejemplo perf top.
Como las direcciones de memoria varían de un kernel a otro, un volcado de pila con direcciones de memoria era inservible para los desarrolladores. Había que traducir las direcciones a funciones, tarea que hacía el programa ksymoops a partir del archivo System.map del kernel correspondiente, o lo hacía por ti el ya desaparecido demonio klogd si la máquina no se colgaba del todo. Para quienes reportaban bugs esto era un engorro considerable, ya que a menudo tocaba copiar a mano (las cámaras digitales no se habían popularizado) el texto de la pantalla para luego escribirlo en un archivo que ksymoops pudiera leer (algo que era difícil de hacer si no podías arrancar el sistema para ejecutar dicho programa). Para reportar un simple fallo había que molestarse demasiado, y había que explicar a los usuarios novatos vía email como usar el programa ksymoops, etc.
kksymoops, que fue enviado por Ingo Molnar, consistía básicamente en meter el System.map dentro del kernel, qué este podía usar para, en cada oops, traducir direcciones a nombres de funciones. Así, bastaba copiar la lista de funciones para saber qué parte del kernel había causado el problema. El programa ksymoops (y el demonio klogd) se volvieron obsoletos, y reportar fallos en el kernel se simplificó enormemente. El único inconveniente es que hay que emplear unos pocos cientos de KB de RAM en almacenar una tabla de símbolos que rara vez se llega a usar, pero es una minucia y la mayoría de la gente ni tan siquiera es consciente de su existencia.
Esta historieta de tiempos remotos viene a cuento por los volcados de pila de los programas normales de espacio de usuario. Ninguna distro importante compila hoy sus paquetes con la información de depuración activada por defecto, porque el tamaño de los paquetes y las instalaciones aumentaría brutalmente. De modo que el mundo de espacio de usuario está un poco como el kernel en días antiguos, con volcados de pila que son listas de direcciones de memoria poco útiles. Aunque las distros modernas proporcionan paquetes de depuración de instalación opcional pero sencilla, e incluso existen mecanismos de reporte de bugs (abrt) que descargan esos paquetes y crean volcados de pila legibles automáticamente.
Pues bien, todo esto va a cambiar. Un tipo que trabaja para Red Hat ha desarrollado una herramienta que comprime la información de depuración de los ejecutables, lo cual permite reducir su tamaño considerablemente. A pesar de esto sigue siendo un tamaño considerable, pero si además de comprimir se elimina la información de depuración excesiva y se deja tan sólo la necesaria para decodificar nombres de funciones, resulta que una distro puede incluir esta información de depuración básica y comprimida con un coste de espacio aceptable, y de ese modo tener mejores reportes de bug (tanto para la distro como para upstream). Esto será lo que haga Fedora 18, que ya está recompilando todos sus paquetes para compilarlos con esta información.
No hace falta mencionar que esto será utilísimo no sólo para tener mejores volcados de pila, sino para herramientas de análisis del sistema, como por ejemplo perf top.
Suscribirse a:
Entradas (Atom)