D'Oh!

Red Hat piensa que XFS es mejor sistema de archivos que Ext4

2013-06-16T19:20:00.000+02:00

Hace cosa de un año escribí una entrada sobre el renacer de XFS. Hace unos días se supo que Red Hat no sólo va a soportar XFS en RHEL 7, sino que planea usarlo como sistema de archivos por defecto.

Retomando la cuestión, si dejamos a un lado los de última generación (ZFS/Btrfs), XFS es el mejor sistema de archivos. La razón por la que la familia Ext ha tenido mayor protagonismo en Linux es que, como se ha recalcado aquí, los sistemas de archivo son como los navegadores web: la calidad de la implementación importa mucho más que el formato o estándar a implementar. Hasta el punto de que un sistema de archivos obsoleto, como Ext4, es uno de los mejores por tener una buena implementación, mientras que Reiserfs v3 tienen un formato mejor, pero una implementación desfasada.

XFS tiene un buen diseño, y, en parte, una buena implementación. Su problema fue que al pasar de Irix a Linux, la implementación no encajó demasiado bien. Tardaron años en adaptarlo. Pero ese inconveniente ya está superado, se ha solucionado la lentitud del journaling con archivos pequeños, y por otra parte Ext4 tiene defectos de diseño que cada vez cuesta más superar, y que ni tan siquiera una buena implementación puede evitar. Ext4 ya no tiene la ventaja y no hay razones para no usar XFS.

Por otro lado tenemos a Btrfs. Es el futuro a largo plazo, pero recuerden que, en realidad, las principales novedades de estos sistemas de archivos de próxima generación no son mejoras para el rendimiento y la escalabilidad de operaciones cotidianas, sino mejoras en la gestión de almacenamiento: expansión a múltiples discos, snapshots, subvolumes, checksums (las mejoras puntuales del modelo copy-on-write y el RAID integrado son más bien una consecuencia de lo anterior). En materia de rendimiento y escalabilidad pura y dura, ni ZFS ni Btrfs dan miedo a XFS; de hecho a menudo tiene algunas ventajas sobre ellos. Hacer copias redundantes de los metadatos, por ejemplo, da seguridad, pero escribir al disco dos veces los mismos datos siempre va a ser más lento que no hacerlo, y para quienes llevan la capacidad de los discos al límite, eso importa.

De ahí que el panorama linuxero de sistemas de archivos esté evolucionando hacia una dualidad: XFS para servidores "serios" que necesitan el máximo rendimiento (bases de datos, virtualización, etc), Btrfs para lo demás, Ext4 como opción estable y segura. Y el peso de Red Hat tras esta decisión va a consolidar definitivamente este panorama.

Curiosidades de OS X 10.9 "Mavericks"

2013-06-15T22:17:00.003+02:00

No es ningún secreto que desde que Apple se centró en los dispositivos portáctiles, lo relacionado con el escritorio ha pasado a ser secundario. OS X ha pasado de ser el centro de atención de todo el desarrollo a ser un segundón que de vez en cuando recibe actualizaciones desarrolladas en iOS. Lo cual tiene sentido, al fin y al cabo todos sabemos con qué productos gana Apple casi todo su dinero.

Sin embargo, pasar a ser el sistema operativo de "camiones" post-pc tiene sus ventajas. Por ejemplo, pueden permitirse tratar a OS X como un sistema operativo más orientado hacia sectores profesionales, "camioneros informáticos". Aunque eso no libra a nadie de los feroces ataques del infantil departamento de marketing de Apple, si que añade cosas interesantes, como una página dedicada a "tecnologías avanzadas" y un enlace a un PDF titulado "OS X Mavericks Core Technologies overview".

"Timer coalescing"

La primera gran novedad que se anuncia es algo llamado "Timer coalescing", fusión de temporizadores (por cierto, la palabra coalescencia existe en español). Esta técnica tiene como objetivo mantener la CPU ociosa y que se mantenga en modos de ahorro de energía el máximo tiempo posible. Para ello, se minimiza el número de activaciones de temporizadores activados por las aplicaciones en el sistema. El modo de minimizarlo es agrupar los temporizadores no-críticos más cercanos en el tiempo. Por ejemplo, si hay 10 temporizadores fijados para activarse en el plazo de un mismo segundo, en lugar de sacar la CPU 10 veces del modo ocioso, se activan todos de una sola vez. Linux tiene algo similar desde hace más de 6 años.

Compresión de memoria

La segunda, la compresión de la memoria RAM de las aplicaciones menos utilizadas en caso de falta de memoria. Esta es una buena idea, en Linux hay planes para la incorporación de algo similar, aunque lo de Apple parece más completo y añade, de paso y prácticamente "gratis", compresión de swap (si tienes la memoria de un programa comprimida, ¿por qué no almacenarla en swap directamente en ese formato?). Ahora bien, Apple afirma varias veces que este sistema puede reducir el tamaño de una aplicación en memoria hasta en un 50%, lo cual es una falacia descomunal. El ratio de compresión siempre depende del tipo de datos que se quieran comprimir.

Me ha llamado la atención que en las imágenes de marketing de Apple que muestran las mejoras de rendimiento de esta compresión se vea, además de una barra de "respuesta bajo carga", otra que dice "Wake from Standby". Sorprende, porque la compresión no debería afectar de ningún modo al regreso del modo de suspensión-a-memoria. Seguramente tenga que ver con la hibernación implícita que los Mac hacen con cada suspensión.

App Nap

Otra curiosidad es algo llamado "App Nap". Consiste en que, cuando a una aplicación no es visible en el escritorio y no está reproduciendo sonido, se le reducen la prioridad de los temporizadores (es decir, el periodo de tiempo para hacer coalescencia de temporizadores es mayor que lo habitual), la del I/O de disco y la prioridad del proceso.

...en definitiva, ahorro de energía

Estas tres características tienen una cosa en común: Tienen como objeto principal el ahorro de energía. Es decir, no son demasiado útiles para los Mac de escritorio. Al menos las dos primeras tienen toda la pinta de haber sido desarrolladas para iOS e incorporadas posteriormente a OS X.

Otras características de ahorro de energía menos interesntes son que hará falta hacer click en contenido flash para poder verlo cuando el contenido no esté en el centro de la página, y aceleración por hardware en la reproducción de video.

Tags

Otra característica interesante es el uso de tags en los archivos. Lo interesante no son los tags en sí mismos (¿hace cuántos años los soporta KDE?) sino el cómo están implementados, ya que el tagging es el primer paso para quienes quieren librarse de la estructura jerárquica y la anidación excesiva de directorios. Y parece ser que están implementados como atributos extendidos. Es decir, no se han roto demasiado la cabeza - por el momento (se rumorea hace tiempo que Apple trabaja en un nuevo sistema de archivos).

OpenGL

Una de las características menos publicitadas de OS X Mavericks es la muy reivindicada actualización de su OpenGL. Pasan del OpenGL 3.2 de los OS X actuales, cuya especificación fue publicada en 2009 (!) a soportar OpenGL 4.1 (y algo de 4.2). Que fue publicado en 2010, pero al menos se trata de una versión 4.x, que tiene mejor soporte para hardware diseñado para Direct3D 11. Será interesante ver los resultados del cambio.

Conservadurismo unixero, versión anti-wayland

2013-06-10T21:55:00.002+02:00

Algunos desarrolladores de X.org/Wayland han escrito para Phoronix un buen artículo enumerando, una vez más, las razones por las que X.org es un artefacto espantoso y como Wayland lo soluciona. A pesar de ello, la reacción en algunos foros vuelven a ser los comentarios de gente que, en el mismo tono escéptico de siempre, vuelven a preguntarse sobre la necesidad de reemplazar una cosa tan sólida y funcional como X.org.

Mención especial merecen quienes siguen mencionando la transparencia de red como motivo fundamental para defender a X.org frente a Wayland. A pesar de que el artículo describe con elocuencia qué:
· X.org hoy en día no tiene verdadera transparencia de red (las extensiones modernas han distorsionado el concepto original)
· La que tiene es bastante deficiente (que hayan surgido empresas que hacen dinero mejorándola debería dar una pista)
· Wayland no sólo permitirá usar X.org dentro de Wayland, sino que tendrá soporte nativo de transparencia de red mejor que el de X.org (ya se ha incluido soporte de FreeRDP en Weston 1.1).

A pesar de ello, como digo, no hay manera de que en cada hilo de Wayland aparezcan inevitablemente esos comentarios. No es sólo que haya gente que no lee el artículo, es que se niegan a leer e intentar comprender a quienes les responden.

Llegados a este punto, los desarrolladores de Wayland probablemente pierden el tiempo escribiendo esas cosas. A estas alturas, está claro que estamos ante ejemplos de ultraconservadurismo unixero. Suelen abundar en estos casos las opiniones que, mostrando un considerable desfase respecto a la realidad tecnológica actual, defienden que el uso de "3D" en los escritorios es innecesario. Salgan de mi patio y no pisen mi cesped. Resumiendo, que no merecen demasiada atención.

Dramas de Windows 8

2013-05-18T21:44:00.002+02:00

A estas alturas no es ningún secreto que en el escritorio Windows 8 ha tenido bastante menos éxito que el que se presupone a un nuevo sistema operativo de Microsoft debería conseguir. Su cuota de uso en la web es peor que la de Vista, y Vista ya de por si no fue precisamente popular. Pero el caso de Windows 8 no se queda ahí, hay varias historias entrecruzadas rondando internet -no todas negativas- que dan para hablar largo y tendido.

Uno de mis favoritos son este o este, en los que se argumenta que la culpa de los malos resultados de Windows 8 la tienen los vendedores de PCs tradicionales, por querer seguir vendiendo....PCs tradicionales, y por no querer seguir las indicaciones de Microsoft. Lo cierto es que son hipótesis creíbles, teniendo en cuenta la existencia de Surface como supuesta muestra de lo que Windows 8 debería ser.

Uno de los últimos dramas ocurrió hace unos días, en un post del "Corporate Vice President of Corporate Communications" de Microsoft. Este responsable de comunicación decidió utilizar una técnica comunicativa muy común, consistente en acusar a los medios de comunicación de sensacionalismo. Es decir, echar balones fuera. Lo cómico es que esos medios sensacionalistas coinciden al señalar lo que todos sabemos: Imposibilidad de arrancar en el escritorio clásico, ausencia de botón de inicio. Pero está previsto que la próxima actualización de Windows, 8.1 "Blue", restaure precisamente ese funcionalidad. El responsable de "comunicaciones corporativas" puede decir lo que quiera, pero con los hechos Microsoft da la razón a los medios a quienes acusan de sensacionalistas.

Y, por supuesto, repite una y mil veces aquello de que ellos escuchan atentamente a sus clientes. Sin embargo, todos recordamos que la ausencia del botón de inicio y la imposibilidad de iniciar en el escritorio clásico fueron mencionados repetidamente en los análisis de todas las versiones preliminares de Windows 8. Surgieron varios programas para añadir de nuevo el botón de inicio, y en lugar de escuchar a los clientes, Microsoft intentó activamente hacer difícil la creación de esos programas.

Otro drama interesante es la curiosa persistencia de gente que sigue afirmando en serio que la(s) interfaz(ces) de Windows no tienen ningún problema, que es mejor que Windows 7 y que es cosa de acostumbrarse. Como ya mencioné, a la dualidad de interfaces de Windows 8 sólo cabe acostumbrarse como uno se acostumbra en Linux a las diferencias entre aplicaciones GNOME y KDE, es decir, educando al cerebro para que ignore los problemas.

Pero no todo es malo. Poca, muy poca gente menciona que Windows 8 está teniendo cierto éxito en las tabletas, pasando en un año de una cuota de mercado del 0% al 7.8%. Teniendo en cuenta que se trata de la entrada de un jugador nuevo en medio de una competencia feroz entre iPad y Android, me parecen cifras más que respetables. Puede que Windows 8 haya causado un lío tremendo en el escritorio con su mezcla de interfaces, pero está claro que obtienen un beneficio de todo eso, que es ser un buen sistema operativo para tabletas.

Las novedades de Linux 3.9

2013-05-03T21:53:00.004+02:00

(Si, si, perdón por el retraso).

Ya se ha anunciado la versión 3.9 del kernel Linux. Esta versión incluye soporte experimental en Btrfs para los modos RAID5/6 y mejor defragmentación en archivos compartidos por snapshots; soporte para el emulador "goldfish" usado por el SDK de Android; posibilidad de usar dispositivos SSD como dispositivos cache; dos nuevas arquitecturas: Synopsys ARC 700 y Meta Imagination; soporte de KVM en la arquitectura ARM; un driver de Intel que inyecta ciclos ociosos para mejorar en rendimiento-por-vatio, soporte para portátiles Chrome OS, un nuevo estado de suspensión energético, y la eliminación de la opción obsoleta CONFIG_EXPERIMENTAL. También se han incluido drivers nuevos y muchas otras mejoras y pequeños cambios. La lista completa de cambios, en inglés, puede encontrarse aquí, como siempre.

· Soporte experimental de RAID5/6 y defragmentación optimizada en presencia de snapshots:

· RAID5/6: Btrfs ha añadido soporte de RAID5 y RAID6. El soporte es aun experimental y no está preparado para gestionar cuelgues del sistema, por lo tanto sólo se recomienda su uso en pruebas.
· Defragmentación optimizada en presencia de snapshots: Debido al diseño copy-on-write de Btrfs, varios snapshots pueden compartir los mismos bloques de datos. Esta compartición de bloques podía deshacerse tras un proceso de defragmentación, ya que al intentar defragmentar parte de un archivo se activaba el proceso de copy-on-write, y quedaba un archivo fragmentado y otro defragmentado, y los datos de ambos duplicados y no compartidos. En esta versión el proceso de defragmentación tiene en cuenta la presencia de snapshots.

· Emulador "goldfish" de Android: El entorno de desarrollo de Android proporciona una plataforma de virtualización ARM basada en QEMU llamada "goldfish". Esta plataforma proporciona una CPU virtual y controladores para la batería, MMC, sonido, gráficos, etc. Esta versión de Linux incorpora el soporta para esta plataforma goldfish, lo cual hace más sencillo desarrollar para Android.

· Almacenamiento SSD como caché: El device-mapper ha añadido un target (dm-cache) que permite utilizar dispositivos veloces (por ejemplo, SSD) como cachés de dispositivos más lentos (como los discos tradicionaes). Este target soporta plugins que implementan diferentes políticas respecto al funcionamiento de caché. Soporta modos de escritura writeback y writethrough. Documentación: Documentation/device-mapper/cache.txt

· Nueva arquitectura: procesadores Synopsys ARC 700: Esta versión soporta la familia de procesadores ARC700 processor (750D y 770D) fabricados por Synopsys.

El ARC700 es un core RISC de 32 bits con MMU, altamente configurable y eficiente energéticamente. Está embebido en SoCs que se incluyen en televisiones, reproductores digitales, dispositivos de red. Hay más información sobre estos procesadores aquí. Más información sobre el proceso de porteo a Linux puede encontrarse en esta charla: ELCE-Barclone '12. La toolchain GNU, basada en GCC 4.4 + uClibc 0.9.30.3 está disponible en GitHub

· Nueva arquitectura: procesadores Meta Imagination: Esta versión incluye soporte para los procesadores Meta ATP (Meta 1) y Meta HTP (Meta 2) de Imagination Technologies.

Los procesadores Meta son procesadores de propósito general de 32 bits, con soporte de multihilo por hardware, y que también incluyen un conjunto de instrucciones DSP. Pueden encontrarse en muchas radios digitales. Pueden ejecutar diferentes sistemas operativos en diferentes hilos de hadware, por ejemplo, una radio digital podría ejecutar un RTOS para decodificar señales y audio en tres hilos de hardware, y ejecutar Linux en un cuarto hilo para gestionar la infertaz de usuario, red, etc. Los HTPs también son capaces de ejecutar Linux SMP en múltiples hilos hardware. El conjunto de instrucciones y la documentación sobre la arquitectura pueden encontrarse aquí.

· Soporte de KVM en ARM: La arquitectura ARM ahora soporta el sistema de virtualización KVM.

· Driver Intel PowerClamp para la inyección de ciclos ociosos para mejora del rendimiento energético: El driver Intel PowerClam permite inyectar ciclos "idle" a las CPUs. El objetivo es mantener el estado energético-C para un determinado conjunto de CPUs. Comparado con otros sistemas existentes en el kernel, como ACPI PAD (desactivar CPUs) y modulación de frecuencia, este sistema es a menudo más eficiente en términos de rendimiento/W. Documentación: Documentation/thermal/intel_powerclamp.txt

· Nuevo estado de suspensión "suspend-freeze": Esta versión introduce un nuevo modo de suspensión. Equivale a procesos congelados + dispositivos dormidos + procesadores ociosos. Este estado es útil para 1) plataformas que no soporta suspensión a memoria, o la que tienen está mal implementada 2) plataformas que tienen un estado energético ocioso extremadamente eficiente y que pueden ser utilizadas para reemplazar a la suspensión a memoria.

Comparado con la suspensió a memoria, suspend-freeze ahorra menos energía porque el sistema aun está en estado de ejecución, pero tiene menos latencia en la reanudación porque no toca la BIOS y los procesadores están en estado ocioso. Comparado con RTPM/estado ocioso, suspend-freeze ahorra más energía porque el procesador tiene más tiempo para dormir una vez que los procesos han sido congelados, y puede ahorra más energía de los dispositivos que no tienen buen soporte RTPM. Para activar este modo de suspensión, haga "echo freeze > /sys/power/state"

· Soporte de portátiles Chrome OS: Se ha añadido soporte para todos los dispositivos de los portátiles Chrome vendidos por varios fabricantes.

· Eliminación de CONFIG_EXPERIMENTAL: CONFIG_EXPERIMENTAL era una opción de configuración que tenía como objeto activar características experimentales que la gente normal no debía usar. Pero los cambios en el modelo de desarrollo y el directorio staging lo han convertido en obsoleto. Estos días casi todas las distros la activan por defecto, convirtiéndolo en algo inútil, por lo que ha sido eliminada. A partir de ahora, los desarrolladores añadirán el texto "(EXPERIMENTAL)" en el título de la opción de configuración para prevenir a los usuarios.

Y eso es todo. La lista completa de cambios en inglés, aquí

Baseline, el nuevo JIT javascript de Firefox (y de paso, la historia de los JITs de Firefox)

2013-04-07T14:02:00.000+02:00

Como colofón a la entrada anterior, hoy tengo la oportunidad de retomar la sana costumbre de proselitismo firefoxero, como se hacía en los tiempos del anuncio de dos páginas en el New York Times pagado con donaciones ("crowdfunding" que se diría ahora, en lugar del "fundraising" que se utilizó entonces), o los primeros 100 millones de descargas. Sin intención anti-blink, que conste (aunque quizás la entrada aparentara lo contrario, blink me parece el sucesor más fiel al espíritu del webkit original).

Firefox ha anunciado que acaba de introducir en sus builds nocturnas un nuevo JIT: Baseline. El anuncio es una lectura muy interesante que merece un post épico sobre la intrincada historia de los motores Javascript de Firefox y la evolución de sus JITs.

SpiderMonkey: intérprete a secas

En un principio, el motor Javascript de Firefox (llamado SpiderMonkey desde que Brendan Eich lo escribió mientras creaba el lenguaje) era simplemente un intérprete de bytecode. Por aquel entonces los JITs eran algo reservado a Java y similares. En Firefox 3.5 se introdujo el primer JIT, TraceMonkey. Por aquel entonces tanto el V8 de Chrome como el Squirrelfish de Apple del mundo Webkit ya tenían sus JITs.

TraceMonkey: tracing JIT

Este JIT de Mozilla, sin embargo, era algo diferente. Los motores de webkit eran JITs "whole-method", que quiere decir que compilaban a código nativo métodos enteros. Sin embargo, Javascript es un lenguaje con variables de tipado dinámico, es decir, el tipo de una variable pueden cambiar durante la ejecución, por lo que el tipo de muchas variables no puede determinarse durante la compilación. Por eso, las implementaciones de lenguajes de tipado dinámico tienen que implementar un sistema que vaya tomando nota del tipo de cada variable y pueda enfrentarse a cambios de tipos. Los JITs webkit generaban código nativo que incluía ese sistema, sistema que, como es de esperar, afecta notablemente al rendimiento.

TraceMonkey no generaba código nativo para métodos, lo generaba para "traces", que no son más que una ruta de código determinada. El intérprete empieza a interpretar el bytecode, y cuando el bytecode saltaba "hacia atrás" (caso típico de un loop), tomaba nota de ello. Cuando ese mismo salto ocurría varias veces, TraceMonkey generaba código nativo para esa porción de código.

La gran ventaja de este método era que al entrar en acción no para generar código genérico para una función, sino una ruta de código muy concreta ya ejecutada muchas veces, y conociendo el conjunto de tipos concreto utilizados por las variables en esas ejecuciones, TraceMonkey tenía la oportunidad de optimizar el código nativo para ese conjunto de tipos, sin incluir todo un sistema capaz de funcionar con tipos dinámicos (sólo comprobaciones de cambio de tipo), por lo que el código generado estaba más optimizado que el código de los JITs webkit. Las desventajas era que si una trace cambiaba los tipos asumidos, había que desecharla y volver al intérprete inicial. Y si una ruta de código con muchos "ifs" pasaba siempre por las mismas condiciones y de repente en una cambiaba de dirección, lo mismo.

TraceMonkey era bueno optimizando loops con tipos y rutas de código estables, pero para lo demás se volvía al (lento) intérprete. Los webkit generaban código nativo menos optimizado, por incluir toda la gestión de tipos, pero podían optimizar cualquier función, no una ruta concreta, y su optimización era válida en presencia de cambios de tipos y de rutas de código, y duraba para todo el programa.

JaegerMonkey: whole-method JIT, pero sin eliminar TraceMonkey

Aunque TraceMonkey era bueno en lo suyo, había espacios donde claramente no podía competir en todos los casos con los JITs webkit, así que Firefox 4 introdujo un JIT "whole-method" como los de ellos, llamado JaegerMonkey. Sin embargo, TraceMonkey seguía siendo el mejor para loops estables, por lo que se siguió recurriendo a él para esos casos.

JaegerMonkey + type inference: adios a TraceMonkey

Firefox 9 añadió a SpiderMonkey (el intérprete) inferencia de tipos. A grandes rasgos, la inferencia de tipos consiste en intentar averiguar lo máximo posible sobre los tipos de las variables y sus cambios en todo momento. Gracias a esa información JaegerMonkey pasó a poder hacer optimizaciones de tipos parecidas a las de TraceMonkey.

Dado que JaegerMonkey hacía más o menos el trabajo de TraceMonkey y la integración entre ambos era problemática (y, además, TraceMonkey se había convertido en un monstruo al que se había intentado forzar a hacer lo que no podía), se desactivó TraceMonkey por defecto en Firefox 10, y se eliminó por completo en Firefox 11.

IonMonkey: whole-method JIT + type inference + IR, pero también JaegerMonkey

Firefox 18 (publicado hace medio año) incluyó otro JIT, IonMonkey. Sus fundamentos vienen a ser los mismos que los de JaegerMonkey, excepto en un aspecto. Al compilar una función, JaegerMonkey lo hace traduciendo el bytecode a código máquina nativo más o menos directamente.

IonMonkey no hace esa traducción directa, traduce en primer lugar el código Javascript en primer lugar a unas estructuras de datos, una "representación intermedia" (IR), sobre la cual se pueden aplicar algoritmos de optimización mucho más complejos e infinitamente más eficientes. Es así, de hecho, como funcionan los grandes compiladores. Sólo hay un problema, y es que esta clase de compilación es compleja, lenta y usa muchos recursos. Se trata de la mejor optimización posible, pero sólo merece la pena en métodos que verdaderamente lo merezcan. Por lo que se siguió utilizando JaegerMonkey, que hacía optimizaciones regulares, pero rápidas.

Llegados a este punto, el esquema es:
· Se empieza con el intérprete SpiderMonkey (que es lento pero es la mejor opción para el código no crítico que casi no se ejecuta, ya que esos casos las compilaciones son más costosas que los beneficios potenciales)
· Si una función se llama bastante se hace una optimización simple pero rápida con JaegerMonkey.
· Si esa función sigue llamándose con mucha insistencia, se hace una optimización profunda pero lenta con IonMonkey.
· Si hay un cambio de tipos en una función en alguno de los dos JITs, se desechan las optimizaciones y se vuelve al intérprete (pero ocurre con menos frecuencia que en TraceMonkey)

Baseline: adiós a JaegerMonkey

El esquema presente de los JITs de Firefox parece equilibrado, pero a través de tanto cambio ha acumulado deficiencias. El encargado de recoger información de los tipos es el intérprete SpiderMonkey, que se lo pasa a los JITs. Es por esa razón que si hay un cambio de tipos es necesario desechar el código nativo generado y volver al (lento) intérprete, para sea él quien recoja la información de los nuevos tipos.

Baseline es un reemplazo de JaegerMonkey, diseñado como él para generar código poco optimizado pero con rapidez, con la diferencia de que es capaz de analizar tipos por si mismo, y gracias a una optimización llamada "inline cache", si hay un cambio de tipos es capaz de adaptarse e incorporarlo a la optimización existente sin empezar de cero. Y toda la información de tipos es compartida con IonMonkey. De ese modo, un cambio de tipos en el código nunca supone el regreso al intérprete, sino a la optimización media de Baseline.

Es más, su gestión de tipos es mucho más avanzada que la del intérprete y permite mejores optimizaciones y consume menos memoria que Jaeger, sin que por ello deje de compilar con rapidez. Además, las llamadas entre código nativo optimizado por Ion y el optimizado por Baseline son más rápidas que con Jaeger. Baseline además comparte mucho código con IonMonkey, y por último, Baseline entrará a optimizar una función cuando se ejecuta 10 veces, mucho antes que JaegerMonkey, que lo hacía tras 40. Los benchmarks muestran una mejora notoria y plena competitividad con otros motores javascript (que, aunque no lo he mencionado, también han ido mejorando con el tiempo).

Y ese es el resumen de la evolución de los motores Javascript de Firefox...

Extra: OdinMonkey (asm.js)

...con una excepción: OdinMonkey, también conocido como asm.js, que es algo reciente. Es un experimento de Mozilla, y no tiene que ver con los motores javascript referidos anteriormente. Se trata de un subconjunto de Javascript legalmente válido, pero que renuncia a las funcionalidades más costosas del lenguaje, como el tipado dinámico o la gestión de memoria automática.

Este subconjunto de Javascript se ha diseñado con la idea -francamente revolucionaria- de permitir compilar código C/C++. Es decir, coger un programa C/C++ y compilarlo no a código x86, sino a este subconjunto de Javascript. Es decir, que este subconjunto de Javascript funcionaría como una especie de "representación intermedia", de pseudobytecode.

Lo gracioso está en que, al prescindir de las características complejas, es posible utilizar no un compilador JIT, sino uno "ahead-of-time", para generar código muy optimizado a partir de ese Javascript especial. Y por muy optimizado estamos hablando que es el doble de lento que los programas generados por compiladores como clang (y eso es ser muy, muy rápido). Ah, y con la seguridad de una máquina virtual.

De momento, asm.js supone la obsolescencia del Native Client de Google Chrome, pero los desarrolladores están planeando facilitar que asm.js pueda ser usado por lenguajes como Java o C#, con lo cual asm.js podría convertirse en una VM universal que compita con las de esos lenguajes.

Google anuncia Blink, un fork de Webkit, y a nadie debería sorprenderle

2013-04-04T00:22:00.003+02:00

Pues si, no es una broma retrasada del April Fools: Google ha decidido hacer un fork de Webkit. Se trata de una decisión tajante y las consecuencias son fáciles de adivinar, así que no hay mucho que decir al respecto, más allá de lo obvio: es una mala noticia y una prueba de que Google cada vez defiende más sus intereses sin permitirse sentimentalismos (igual que Apple). De hecho me apunto una predicción: aunque Google haga público el código de Blink, acabará haciendo el desarrollo en secreto, como ya hace con Android.

Sin embargo, no se dejen engañar: aunque no era muy conocido, los conflictos y problemas en Webkit existían y eran abundantes, y aunque quizás un fork quedaba lejos, hacía tiempo que había dejado de tener una dirección única. Permitanme citarles un par de blogs que permiten intuir los problemas del proyecto Webkit:

"WebKit has eight build systems, which cause perverse behavior. Peel back the covers and you’ll find tension about past code forks: V8 vs. Apple’s JavaScriptCore (“Nitro”), iOS (in a secret repository at apple.com for years, finally landing), various graphics back ends, several network stacks, two multi-process models (Chrome’s, stealth-developed for two years; and then Apple’s “WebKit2″ framework). Behind the technical clashes lie deep business conflicts."

Brendan Eich, "Why Mozilla Matters", escrito el pasado 14 de Febrero.

Y este otro:

"what’s not shared in WebKit ports:

Anything on the GPU
- 3D Transforms
- WebGL
- Video decoding
2D drawing to the screen
- Antialiasing approaches
- SVG and CSS gradient rendering
Text rendering and hyphenation
Network stack (SPDY, prerendering, WebSocket transport)
A JavaScript engine
- JavaScriptCore is in the WebKit repo. There are bindings in WebKit for both it and V8
Rendering of form controls
video and audio element behavior (and codec support)
Image decoding
Navigating back/forward
- The navigation parts of pushState()
SSL features like Strict Transport Security and Public Key Pins"

Paul Irish, "Webkit for developers"

En efecto, como se puede deducir de esos posts hace tiempo que Webkit estaba forkeado de facto, y lejos de ser ese motor de navegador minimalista y moderno que era en sus inicios, se había convertido -por culpa de Apple y Google- en un monstruo. Cada corporación intentaba plasmar sus intereses, y en las áreas más conflictivas en lugar de buscar un consenso técnico cada uno empotraba su solución particular. Parece ahora obvio que la comunidad estaba rota hace tiempo, y simplemente estamos asistiendo a su confirmación oficial.

Personalmente no me afecta demasiado, ya que siempre me negué a usar Chrome, un navegador que recoge datos privados de sus usuarios y que incluye publicidad del Chromebook (¿software de escritorio con adware incorporado? ¿estamos en 2001?). Hubo un tiempo en el que los problemas de rendimiento y memoria de Firefox me tentaron a usar Chromium, aunque no me gustaba demasiado su carácter de segundón, pero hace tiempo que Firefox eliminó (y mejoró con creces) esos problemas, y se trata de una fundación sin ánimo de lucro con un buen historial de respeto a la privacidad. Viendo el panorama me alegro de no haber cambiado, porque visto lo visto, Firefox va a seguir siendo el único gran navegador verdaderamente neutral.

Mis 2 mBTC sobre Bitcoin

2013-04-02T01:17:00.002+02:00

Como últimamente se habla mucho sobre Bitcoin, he decidido probarlo (subiéndome al tren el último, para variar), escribir sobre el tema, y, ya de paso, poner aquí, en mi blog, una dirección de bitcoin de pedigüeñeo descarado: 1HCP4dqRyr3GNMLWcCpvCnefKNZ1YQA8Lc , que pienso añadir al blog, porque es gratis y porque si. ¿A qué viene esto?, se preguntarán. ¿Acaso soy tan creído como para pensar que este blog es lo suficientemente bueno como para los que me leen que bañen en oro? ¿He bebido el kool-aid de los fieles de Bitcoin, la moneda-dios? Me temo que no, en ninguno de los dos casos.

De hecho, estoy bastante seguro de que no recibiré nada que no sea irrelevante, pero eso es lo de menos. A mi entender, lo interesante de bitcoin es que es tan sencillo e inofensivo que incluso si no se pudiesen convertir a €/$, daría igual, son lo suficientemente divertidos como para servir de entretenimiento por si mismos. De hecho, no tengo intención alguna convertir los míseros dólares que he conseguido, ni de emplear un mísero ciclo de mi GPU en minar nada, ni esperar a que se revaloricen con la esperanza de hacerme millonario. Me hace ilusión ver subir el balance y poder enviar a otros, no hay más.

En realidad, lo que más quería tratar sobre Bitcoin es lo difícil que resulta encontrar artículos de calidad sobre el tema. En la mayoría de artículos existen dos grandes corrientes de opinión sobre el Bitcoin: o es la moneda del futuro que va a derribar al dólar y al euro y a acabar con los bancos, o es una estafa piramidal que se derrumbará mañana mismo. Lo más probable es que las expectativas reales de Bitcoin no se encuentren en ningún extremo.

Respecto al fervor Bitcoin, toda o casi toda la comunidad de bitcoin sigue la creencia de que las monedas fiduciarias como el euro y el dólar son una estafa inflacionaria impuesta por gobiernos y poderes financieros a las sociedades modernas y están destinados al fracaso. Estas ideas están muy generalizadas en internet (incluido este blog, hace años) entre todo tipo de ideologías y ha sido popularizadas por la corriente liberal-austriaca. Sin embargo, la visión del mundo de esa escuela no es necesariamente correcta.

Un mundo en el que bitcoin fuese la moneda principal no impediría por si sola la acaparación usurera, ni la aparición de esquemas financieros sobre él (como ha ocurrido con el oro en el pasado). Eso no quiere decir que el bitcoin sea por si mismo un mal invento, al contrario, es un ingenio muy interesante. Pero el bitcoin no puede por si mismo no puede hacer buenos a quienes no quieren serlo, ni puede modificar todas las reglas del juego (si alguien cree que el Bitcoin por si sólo puede hacer surgir una economía mágica donde todo es utópico, nadie es pobre, todo es maravilloso y el Estado pasa a ser algo secundario, tengo unos cuantos puentes que venderle). Por otra parte, aunque el euro, el dólar y demás monedas fiduciarias son criticables, la idea de que van a derrumbarse inevitablemente mañana por el mero hecho de serlo, me temo que se sustenta más en fe que en otra cosa.

Respecto a los escépticos, están, para empezar, los defectos habituales que citan la mayoría de los artículos (ejemplo, el hecho de que si un ladrón logra acceder a tu cartera, es muy fácil hacer desaparecer su contenido sin que ningún cuerpo policial pueda recuperarlas jamás). Pero esos son defectos que, para los defensores de Bitcoin, son ventajas, y lo son desde ese punto de vista.

El argumento detractor típico que se suele escuchar es que el bitcoin es esencialmente una estafa piramidal especuladora. Ciertamente, existen razones para pensarlo: la utilidad del bitcoin debería estar en su uso como moneda, y si bien ese uso existe, si uno echa un ojo a las comunidades bitcoin, no predomina el intercambio de servicios y bienes, sino personas que acaparan esperando la revalorización infinita de su cartera. Suelen creerse más inteligentes que los críticos catastrofistas cierrabares, que para ellos son meros envidiosos que no supieron entrar a tiempo: una psicología bastante parecida a la de quienes invertían en pisos en España hace unos años.

Sin embargo, no todo es blanco o negro. Los "especuladores" del bitcoin pueden ganar mucho dinero en el proceso y muchos, de hecho, se han hecho ricos, lo cual no es ninguna estupidez ni tiene nada de irreal. Y si bien Bitcoin puede sufrir una corrección severa, es arriesgado predecir cuándo ocurriría. Podría tardar años y antes de ello llegar la cotización BTC/USD a niveles astronómicos. Recuerden que en la burbuja inmobiliaria española se estuvo hablando del encarecimiento de los pisos durante muchos años previos a la explosión.

Pero incluso se sufriera un crash catastrófico, eso no tendría por qué significar el fin de Bitcoin, podría ser simplemente la normalización de su demanda.

En mi opinión, la mayor influencia de Bitcoin en el mundo va a ser el ejemplo. Para empezar, hay que tener en cuenta que se trata de la primera criptomoneda p2p verdaderamente popular, pero no tiene por qué ser la última. Y, sobre todo, si Bitcoin se hiciera verdaderamente popular, no les quepa duda que el sistema financiero intentaría imitar algunas de sus ventajas. Los bancos centrales, por ejemplo, están tanteando con crear sus propias monedas electrónicas. Bitcoin es muy útil para esos esfuerzos. La digitalización del dinero, en general, es un tema muy interesante y que traerá muchos cambios, pero me cuesta creer que Bitcoin vaya a ser el destino final de los ahorros de todo el mundo para el resto de la historia. Quizás sea mejor pensar en Bitcoin como un prototipo; eso si, como un prototipo exitoso, y a día de hoy muy entretenido.

¿Qué hay de Mir?

2013-03-14T20:40:00.002+01:00

Llevo unos días pensando en escribir algo sobre el servidor gráfico de Canonical y, la verdad, no se me ocurre demasiado. Lo único que se puede hacer es desbarrar un poco sobre lo esencial que ya se ha comentado en otros sitios: las alegaciones que hacen sobre la toma decisión de crear Mir por motivos técnicos son, a todas luces, un montón de malas excusas. Una cosa es que hayan querido escribir su propio servidor gráfico, y otro que hayan intentado convencernos de que no tenían elección: esto último es una gran falacia.

Para argumentar, la gente de Canonical se ha inventado argumentos claramente absurdos, del tipo "Weston no encajaba bien en nuestra suite de tests, hubiera sido difícil adaptarlos y los tests de Weston nos parecen inferiores". Ajá. Y por eso tomas la decisión alternativa de escribir un servidor gráfico de cero. Debe ser una suite de tests bastante buena para preferir reescribir el código a testar que adaptar los tests, o contribuir a los tests existentes en Weston (que hubiera beneficiado a todo el mundo).

O aquel de "Weston prácticamente no tenía gestión de dispositivos de entrada cuando tomamos la decisión". Ajá. ¿Y como Weston no tenía gestión de dispositivos de entrada, tomas la decisión de escribir un servidor gráfico de cero que requerirá escribir todo, incluyendo esa gestión de dispositivos de entrada de cuya ausencia te quejas? Al final, lo que ha ocurrido es que la comunidad ha añadido a Weston esa capacidad mucho antes de que Canonical anunciara Mir, con lo cual han hecho un ridículo espantoso mencionando en el wiki que la gestión de dispositivos de Weston no estaba a la altura, cuando resulta estar más avanzado que Mir: no habían vuelto a mirar Weston desde hace meses.

La realidad de esta historia es que Canonical se ha convertido en una organización bastante introvertida que está demasiado ocupada haciendo realidad su visión y no se entera bien ni se preocupa demasiado de lo que ocurre fuera. Lo más probable es que no hayan puesto demasiado empeño en Weston y simplemente hayan dado rienda suelta a la imaginación porque si, y cuando han venido las críticas han decidido construir el razonamiento "weston-no-estaba-preparado", argumento falaz teniendo en cuenta que, por muchas carencias que tenga Weston, empezar un servidor gráfico de cero, por definición, tendrá más y habrá menos gente trabajando en él.

Podrían haber resuelto muchas de sus dudas simplemente preguntando en las listas de correo si alguien estaba trabajando en tal punto, coordinándose con otros, algo de primero de comunidades de software libre, pero no se molestaron. Y si algo de Weston estuviera mal y no les gustase, o tuviesen alguna necesidad especial, podrían simplemente decirlo, pero no se han pasado por allí ni a decir buenos días.

Lo triste es que Canonical simplemente se está complicando la vida inútilmente, porque un servidor gráfico simplemente no es tan importante como para molestarse en hacer lo que están haciendo. Puedo entender lo de Unity, algo que el usuario ve y es vital para el uso de Ubuntu, pero el servidor gráfico es infraestructura y no añadirá nada de valor a Ubuntu, sólo deuda técnica acumulada y sueldos de programadores que se hagan cargo de ella. Podría perdonarse si tuviera alguna gran ventaja técnica (como los hechos se lo perdonaron a systemd respecto a upstart), pero no la tiene, de hecho es más que probable lo contrario.

Respecto al futuro de Wayland, no hay que tener ningún miedo, ya que está condenado a existir y progresar. Para que Mir pudiera desplazarlo, a Canonical tendría que importarle las necesidades y opiniones de otras personas que no sean ellos mismos, y eso no va a ocurrir. Wayland es un proyecto comunitario, y no me refiero a frikis, sino a que es un proyecto donde hay comunicación entre los programadores del servidor gráfico, los de Mesa, los de los drivers del kernel, los de los toolkits, gestores de ventanas, aplicaciones, distros. Mir es un servidor gráfico desarrollado a puerta cerrada, sin colaboración con nadie, diseñado por y para Unity, pasando absolutamente del resto del mundo. ¡Ah, y para contribuir en él se requiere cesión del copyright del código! Wayland está para quedarse, Mir mientras haya dinero detrás.

Google Glasses y el intento de generalizar la tecnología

2013-03-13T00:03:00.000+01:00

Frente a la información publicada sobre Google Glasses, hay dos clases de reacciones: la de quienes creen que es algo maravilloso, por lo que pagarían cantidades insospechadas de dinero, y los que no le ven gran interés e incluso lo están prohibiendo en sus establecimientos.

Yo soy más bien de estos últimos. Google Glasses me parece un invento genial para situaciones y usos específicos, pero que se convierta en un gadget de uso generalizado entre toda la población, como teléfonos móviles, me parece improbable.

Empecemos por el formato. Este servidor de ustedes no tiene una vista de piloto de aviones y usa gafas desde pequeño, pero últimamente sólo me las pongo para conducir porque cada vez me molestan más. Llevar unas gafas permanentemente sin necesidad alguna es algo que no estoy dispuesto a hacer bajo ninguna circunstancia, por muy maravillosas que sean, y para quienes nunca han llevado gafas tampoco va a ser cómodo. De gastarme dinero en algo, lo haría en una de esas operaciones láser, para dejar de utilizar gafas. Y aunque no soy un experto en estética y modas, la popularización masiva de las gafas me parece bastante improbable: guste o no, la mayoría de la gente va a querer ir por la vida sin llevarlas. Los smartphones, en cambio, son la mar de cómodos, se meten en el bolsillo y no molestan a nadie (si a Sergey Brin le molestan, debe estar usándolos mal).

En segundo lugar está el aspecto social, tan ignorado. Google ha creado varios vídeos-demostración, en uno de los vídeos (nota, este es una parodia), el portador acude a una cita con una chica, la cual desconoce claramente la funcionalidad de las gafas. A lo largo de la cena, el chico utiliza sus Google Glasses a escondidas para adivinar aspectos de la personalidad de la chica, fingir que tienen intereses compartidos y, en general, hacerse el interesante. Todo muy bonito.

El problema es que es una situación de ficción que sólo muestran el punto de vista del portador. En un mundo donde las Google Glasses estuviesen generalizadas, la chica conocería perfectamente la naturaleza de esas gafas, y el portador no podría disimular su uso. Sobre todo, la chica sabría que esas gafas tienen una cámara que puede grabarla en cualquier momento. Esta no se trata de las situaciones que se crean con un smartphone, en las que si alguien quiere grabar algo tiene que dejar clara sus intenciones de hacerlo, se trata de que habría una cámara apuntándote constantemente, y no sabrías si te están grabando o no. Imagínense que alguien les apuntara con la cámara de un smartphone toda una cena, ¿se sentirían cómodos?. Que la cámara sea pequeña y disimulada es secundario, un objetivo es un objetivo.

No sé ustedes, pero a mi me parece algo bastante inaceptable socialmente, no sólo pueden llevar Google Glasses un millonario en una demostración tecnológica, la gente desagradable también podría llevarlas, imagínense a absolutamente todo el mundo con ellas. En el vídeo ~~de Google~~, se muestra cómo el chico hace una foto disimulada al escote de la chica, si las mujeres supieran que todos los usuarios de Google Glasses pueden hacer cosas así, seguramente serían más suspicaces con quienes las llevan. ¿Se atreverían a mostrarse ante estas gafas del mismo modo que lo harían sin su presencia? No sorprendería que se exigieran regulaciones para que fuese obligatorio un led parpadeante en las gafas cuando graban. Que un bar haya prohibido las Google Glasses en su establecimiento no tiene porque ser sólo marketing. Lo más probable es que la mayoría de la gente acabe asumiendo que quien va por la vida apuntando con un objetivo continuamente a todo el mundo es o un aspirante a director de cine, o un tipo raro (valga la redundancia).

Tercero, y quizás más importante: Si se fijan, el verdadero protagonista de los vídeos de demostración de Google Glasses no son las Google Glasses en si, sino Google Now: la tecnología de reconocimiento de voz e interfaz natural de Google, es decir, el equivalente al Siri de Apple. En los vídeos se ve a un tipo que puede gestionar sus mensajes y contactos con la voz, lo verdaderamente emocionante es eso, el hecho de poder interaccionar con el ordenador con la voz, las gafas son secundarias (de hecho, los vídeos intentan vender prácticamente el mismo mensaje que los vídeos de promoción de Siri). No hace falta decir que esa tecnología de reconocimiento de voz puede funcionar igualmente en un smartphone.

No quiero decir con esto que las Google Glasses sean una chapuza, por supuesto. Sin dudan van a ser muy útiles para muchos trabajos en los que uno podría consultar cosas sin tener que moverse. Serían imprescindibles en aquellos casos en los que las manos estén ocupadas. Por descontado, serían útiles a los mancos. Y qué decir de los juegos, o de la Ley de Kerenski. ¿Pero un gadget generalizado entre la población? No lo veo.

(Por cierto, no sería de extrañar que el tan rumoreado Apple Watch fuese cierto y se tratase de un intento de facilitar el acceso directo al móvil y a las notificaciones y a Siri de un modo análogo a Google Glasses, pero sin colgar de las orejas todo el rato ni apuntar con una cámara a todo el mundo. Si así fuera, desde luego tendría mucho más sentido que Glasses)

Linux Apps: ¿Un paso hacia adelante?

2013-03-05T15:37:00.000+01:00

Estamos pasando por una época en la que los grandes cambios de la informática surgen en torno a los dispositivos portáctiles, y muchas cosas que se daban por hechas pasan a repensarse para encajar, de un modo u otro, con la mente puesta en los portáctiles. Los proyectos de software libre sacan de su bolsillo su teléfono Android y sienten, con cada movimiento de la yema del dedo, que los pixeles de la pantalla son dibujados por instrucciones de un software que no es el suyo.

Esto produce una frustración que, tarde o temprano, les lleva a ponerse manos a la obra e intentar hacer cosas para solucionarlo. Los puntos de vista y preocupaciones que predominaban cuando el escritorio tradicional era el rey desaparecen, sus problemas se dan por solucionados, y la atención se centra en los portáctiles y en lo que de una manera u otra lo rodea o se sincroniza con ello: interfaces táctiles, tiendas de aplicaciones.

GNOME, en particular, está muy afectado por esta manera de pensar. La interfaz de GNOME 3 se diseñó con esa mentalidad. Ahora, GNOME ha decidido aplicar ese punto de vista a otros aspectos de la infraestructura del proyecto: Javascript como lenguaje prioritario para aplicaciones, y aplicaciones confinadas.

Respecto a la elección de Javascript como lenguaje oficial para aplicaciones, sólo cabe aplaudir. GNOME lleva demasiados años de devaneo estéril sobre qué lenguaje no-C de alto nivel escoger como "oficial". Y se equivocan los que piensan que no tener un lenguaje oficial no es importante. La falta de un criterio oficial ha dispersado inútilmente los recursos, porque todos se dedicaron a intentar hacer valer el suyo: Sun hacía en Java aplicaciones para su Java Desktop que ya nadie recuerda, Icaza pretendió que se usara C# y sólo consiguió que la gente se devanara los sesos intentando librarse de Mono, reescribiendo aplicaciones C# en C++, o intentando crear un nuevo conjunto de aplicaciones en Vala. Resumiendo, conflictos y trabajo malgastado. Una elección oficial, aunque sea una decisión meramente política, incita a dejar de intentar luchar por el trono. Quien quiera usar otros lenguajes podrá seguir haciéndolo, pero serán decisiones pragmáticas, alejadas de las luchas ideológicas subterráneas.

Hay quien ha argumentado que Javascript es una mala elección, y que lo lógico, por tradición gnomera, hubiese sido Python. Aunque es una postura comprensible, yo creo que lo importante es que se hayan decidido por uno, sea el que sea. Además, recuerden que la inversión técnica ha logrado que los motores de los navegadores (GNOME usa el de Firefox en su GJS) sean por lo general bastante más rápidos que el interprete Python oficial.

Pero el anuncio estrella es el de crear una nueva manera de distribuir y ejecutar aplicaciones, a imitación de las App Stores existentes. Básicamente, las aplicaciones se suministrarán en un archivo-imagen. Este archivo-imagen se montará y se ejecutará en una jaula, construida con infraestructura del kernel, en la que sólo tendrá acceso a sus archivos y a las librerías del sistema que haya declarado previamente en una especie de dependencias de alto nivel ("system" para una aplicación que use librerías básicas como libc, "gnome-platform-1.0" para librerías GNOME, etc. Dado que cada proceso está aislado del mundo exterior, la comunicación entre procesos sucederá a través de una imitación de los Intents de Android que funcionarán sobre el IPC al estilo DBUS que se espera que se incluya en el kernel.

En principio, este sistema no es exclusivo de GNOME, KDE y cualquier otro escritorio podrían usarlo también. De ahí que hayan dado en llamarlo "Linux Apps", y no "GNOME Apps", aunque hayan sido las aplicaciones de GNOME las que les han llevado a poner manos a la obra.

Lo interesante de esta propuesta es que rompe radicalmente con el modelo de distribución de aplicaciones en Linux. En realidad, lo que están intentando es crear lo que mucha gente lleva deseando desde hace muchos años: un entorno de desarrollo y distribución de aplicaciones uniforme entre diferentes distros Linux. Teóricamente, esta uniformización facilitaría a las empresas la programación de software para Linux, al poder olvidarse de .deb, .rpm, o de librerías exóticas. Las distribuciones se limitarían a ocuparse de la infraestructura del sistema operativo y de software no-de-usuario, las aplicaciones del usuario serían una cosa aparte.

La consecuencia lógica de esta clase de aplicaciones tendría que ser alguna clase de "App Store" al margen de las distros, aunque que aun no se ha hablado de eso, y existe la opción de incluir imágenes de Linux Apps en paquetes tradicionales. En su contra, está el hecho de que el modelo de ejecución de aplicaciones en jaulas no tiene por qué ser el mejor del mundo, aunque cabe esperar que permitan la creación de Linux Apps que especifiquen su deseo de ser ejecutadas fuera de la jaula. Todavía es pronto para ver en qué acaba esto, pero es una propuesta que podría llegar a ser muy útil.

Las novedades de Linux 3.8

2013-02-19T20:21:00.001+01:00

Ya se ha anunciado la versión 3.8 del kernel Linux. Esta versión incluye soporte en Ext4 para empotrar pequeños archivos dentro del inodo, que mejora el rendimiento para esos archivos y permite ahorrar algo de espacio. Hay también una nueva característica de Btrfs que permite el reemplazado rápido de un disco por otro, un nuevo sistema de archivos F2FS optimizado para SSDs, soporte de diferentes espacios de nombre para procesos ejecutados por usuarios sin privilegios, contabilidad de la memoria de pila y del slab en el controlador de recurso de memoria, checksums en el journal de XFS, un rediseño de las políticas para arquitecturas NUMA y, por supuesto, el muy mencionado fin de soporte de los procesadores 386. También se han incluido drivers nuevos y muchas otras mejoras y pequeños cambios. La lista completa de cambios, en inglés, puede encontrarse aquí, como siempre.

Ext4 empotra los archivos pequeños en el inodo: Cada archivo en Ext4 tiene su correspondiente inodo que almacena información variada -tamaño, fecha de creación, propietario, etc- sobre el archivo (puede verse esa información con el comando stat(1)). Pero el inodo no almacena los datos del archivo, sólo información sobre dónde encontrarlos.

El tamaño utilizado por cada inodo queda predeterminado a la hora de crear el sistema de archivos con mkfs.ext4(8), y por defecto son 256 bytes. Pero ese espacio no se utiliza siempre del todo (a pesar de que los atributos extendidos pequeños hacen uso de él), y hay millones de inodos en un sistema de archivos típico, así que se pierde un poco de espacio. Al mismo tiempo, cada archivo de datos necesita asignarse al menos un bloque (por defecto de 4KB de tamaño), incluso si el archivo sólo va a usar unos pocos bytes. Y se producen movimientos del brazo del disco para leer esos pocos bytes, porque los bloques de datos no se ubican contiguos a los inodos.

Ext4 ha añadido el soporte para almacenar archivos muy pequeños en el espacio sin utilizar de los inodos. Con esta característica se utiliza el espacio sin usar de los inodos, no se asigna un bloque de 4KB para los datos del archivo, y leer esos archivos es más rápido, porque una vez que se lee el inodo también están disponibles los datos, sin necesidad de movimientos del brazo de disco. Algunas pruebas simples muestran que con las fuentes de un Linux 3.0, el nuevo sistema puede ahorrar más de un 1% del espacio de disco. En un directorio /usr de prueba, se ahorró más del 3% del espacio. El rendimiento para los archivos pequeños también se ha incrementado. Los archivos que pueden ser empotrados pueden configurarse indirectamente incrementando el tamaño del inodo (opción -I de mkfs.ext4(8)) - cuando más grande sea el inodo, más grandes los archivos que pueden empotrarse (pero si la carga utilizada no hace uso extensivo de pequeños archivos, ese espacio se gastará).
Btrfs: reemplazo rápido de dispositivos: Como sistema de archivos capaz de expandirse sobre múltiples discos, Btrfs puede eliminar un disco fácilmente, ya sea porque quieres reducir el tamaño de tu pool de almacenamiento, o simplemente porque el disco está fallando y quieres sustituirle:

   # btrfs device add new_disk

   # btrfs device delete old_disk

Pero este proceso no es tan rápido como podría ser. Btrfs ha añadido una operación para reemplazar un disco, que es mucho más rápida:

    # btrfs replace mountpoint old_disk new_disk

La copia normalmente procede al 90% de la velocidad del disco, mientras no haya otras operaciones simultáneamente. La operación puede llevarse a cabo en un sistema en funcionamiento, no requiere desmontar el sistema de archivos o detener procesos, y no es un problema que se apague el ordenador por corte de energía durante la operación; el proceso continuará en el próximo montaje. Es posible usar el comando btrfs replace status para comprobar la evolución de la operación, o btrfs replace cancel para cancelarla.
F2FS, un sistema de archivos para SSDs: F2FS es un sistema de archivos experimental, aportado por Samsung, que está optimizado para dispositivos de almacenamiento basados en memoria flash. Linux ya tiene varios sistemas de archivo -logfs, ubifs, jffs2- para memoria flash, pero están diseñados para dispositivos flash "nativos" que exponen la memoria flash directamente al ordenador. Gran parte de los dispositivos de memoria flash que existen en el mercado no son "nativos", sino que tienen un firmware que emula una interfaz de bloques (FTL), como la de los dispositivos tradicionales, lo cual permite utilizar los sistemas de almacenamiento y sistemas de archivo tradicionales. Estos sistemas de archivo tienen algunas optimizaciones para estos SSDs, pero el sistema de archivos y su formato es el mismo de siempre.

F2FS es un sistema de archivos diseñado para SSDs que tiene en cuenta la existencia de una capa de traducción a bloques e intenta hacer el mejor uso posible de ella. Para más información se recomienda este artículo: An f2fs teardown.
Completado el soporte de espacios de nombres para usuarios sin privilegios: Los espacios de nombre para cada proceso permiten tener espacios de nombre diferentes para varios recursos. Por ejemplo, un proceso puede ver una serie de puntos de montaje, números de PID y estado de la pila de red, y un proceso en otro espacio de nombres podría ver otros. El soporte para espacios de nombres para cada proceso ha estado en desarrollo desde hace años: El comando unshare(1), disponible en distribuciones de Linux modernas, permite iniciar un proceso con los espacios de nombres de puntos de montaje , UTS, IPC o pila de red "no compartidos" con su padre; y systemd utiliza espacios de nombre de los puntos de montaje para las opciones de configuracion de unidades ReadWriteDirectories, ReadOnlyDirectories o InaccessibleDirectories; y para systemd-nspawn. Pero el uso de espacios de nombres estaba limitado a root.

Esta versión añade la capacidad de usar espacios de nombres para cada proceso por usuarios sin privilegios, con seguridad. Los recursos con espacios de nombres disponibles son los puntos de montaje, UTS, IPC, PIDs, y pila de red. Para más detalles sobre los espacios de nombres en Linux, qué son, cómo funcionan, detalles sobre la API y programas de ejemplo, es recomendable leer estos artículos: Namespaces in operation, part 1: namespaces overview, part 2: the namespaces API, part 3: PID namespaces, part 4: more on PID namespaces
Checksums en el journal de XFS: XFS está planeando añadir checksums de metadatos en el futuro. Como parte de esa iniciativa, esta versión añade soporte de checksums en el journal.
"Página cero" para las páginas de memoria gigantescas: Las páginas gigantes son un tipo de páginas proporcionadas por la CPU, y son mucho más grandes de lo normal. Suelen ser usadas por grandes bases de datos y aplicaciones que usan grandes porciones de memoria. Por otro lado, la "página cero" es una página de memoria llena de ceros. Esta página es utilizada por el kernel para ahorrar memoria: algunas aplicaciones asignan grandes porciones de memoria llenas de ceros pero no escriben en toda esa memoria, así que en lugar de asignar toda esa memoria, el kernel hace que toda esa memoria apunte a una sola página llena de ceros. La página cero estaba disponible solamente para tamaños de página de memoria normales (4KB en x86), esta versión añade una página cero gigante para aplicaciones que usan páginas gigantes.
El controlador de memoria soporta la contabilidad de memoria del kernel: El controlador de memoria de Linux es un control group que puede limitar, contabilizar e isolar el uso de memoria para grupos arbitrarios de procesos. En esta versión, el controlador de memoria tiene soporte para contabilizar dos tipos de memoria de kernel: la pila, y el uso de slabs. Estos límites pueden utilizarse para cosas como para bombas fork.
Balanceo de NUMA automático: Muchas máquinas modernas son de arquitectura "non uniform memory access" (NUMA), es decir, acceso de memoria no uniforme: tienen controladores de memoria en cada procesador, y acceder a la memoria del procesador local es mucho más rápido que acceder a la memoria de un procesador remoto, de modo que la ubicación de la memoria en el mismo nodo donde se ejecute el proceso que la referencie es crítico para el rendimiento. Esto es especialmente cierto en grandes servidores con docenas o centenas de procesadores.

La implementación NUMA de Linux tenía algunas deficiencias. En esta versión se incluye una nueva fundación para NUMA que permitirá construir políticas NUMA más inteligentes y que proporcionen mejor rendimiento. Para más detalles, NUMA in a hurry,
Eliminación del soporte de 386: Tal y como se ha comentado en muchos sitios, esta versión de Linux deja de soportar por primera vez el procesador Intel 386 (el 486, sin embargo, aun se soporta)

Y eso es todo. La lista completa de cambios en inglés, aquí

KDE 4.10

2013-02-08T17:34:00.000+01:00

Normalmente las nuevas versiones de KDE no me llaman la atención en exceso: tienen mejoras interesantes, pero esas mejoras son como las de las nuevas versiones de Chrome y Firefox, que por ser relativamente frecuentes e incorporar menos cambios fundamentales, llaman menos la atención. La recién publicada versión 4.10 me parece, sin embargo, interesante de comentar:

ADVERTENCIA: ¡IMÁGENES MOSTRANDO OPCIONES DE CONFIGURACIÓN!

Proteja a sus hijos de esta página si lo cree conveniente

Los menús de las aplicaciones se pueden mover a un botón situado en la barra de la ventana, como Office y Firefox en Windows, o a un menú tipo OS X.

Scripts opcionales descargables para el gestor de ventanas (ej. efectos visuales). Desgraciadamente, los desarrolladores de KDE no han logrado implementar una página web de extensiones que requiere un plugin en el navegador para funcionar, como hacen otros escritorios que presumen de usabilidad, sino que han tenido que conformarse con una ventana que descarga las cosas transparentemente a golpe de clic:

El sistema de búsqueda global, nepomuk, ha sustituido el indexador de archivos que solían utilizar -Strigi- por una solución propia que aunque por el momento es inferior a Strigi, es más conveniente a largo plazo. Además, han modificado el proceso de escaneado de archivos en dos partes, por primera vez he podido usarlo sin notar cómo afecta al rendimiento.

También han modificado la forma de configurar la exclusión de archivos a configurar, en lugar de extensiones se pueden seleccionar cómodamente tipos mime

También han añadido un kioslave para tags de archivo. Con cosas así, es difícil tener envidia de BeOS. Nepomuk ha dado quebraderos de cabeza a mucha gente, pero poco a poco se está convirtiendo en algo sólido.

Fondos de pantalla animados. La gracia no está en el fondo animado en sí, algo que ha estado disponible en todos los escritorios desde siempre de una manera u otra (¡Active Desktop! ¡mplayer a pantalla completa forzado a mostrarse por debajo de todas las ventanas!), sino que está basado en QML. Eso permite bastante libertad, como bajar imágenes ascii de un sitio web y mostrarlas en el escritorio, o coger unas burbujas SVG y ponerlas un fondo de color cambiante. Gnome 3.4 tiene un escritorio animado, pero se limita a imágenes que un archivo .xml especifica cuando se deben cambiar.

Dolphin es mucho más rápido abriendo directorios con muchos archivos, gracias a la utilización de múltiples cores.
PD - se me olvidaba: después de tantas modificaciones en tantas versiones, el notificador de eventos en el systray por fin empieza a tener un comportamiento normal.

Hay muchos otros cambios, por supuesto, pero estos me interesaban especialmente.

Mientras haya dinero...

2013-02-05T20:53:00.001+01:00

Hace dos años que Microsoft "convenció" a Nokia para atar su futuro al de Windows Phone. Con el trato, Nokia conseguía una plataforma de software...y unos cuantos millones por el detalle de dar oportunidad a Microsoft de tener algún futuro en la telefonía portátil. Dicho de otro modo, Microsoft compró con dinero la oportunidad que no había sabido aprovechar.

Hoy, Microsoft ha dado un préstamo de 2.000$ millones para que Dell salga de la bolsa y quede en manos de su dueño, sin tener que dar cuenta a los inversores. Si meterse en la fabricación de hardware con el Surface -que no está siendo un éxito de ventas- ya le causó roces con los fabricantes de PCs, no creo que aproximarse amistosamente a Dell vaya a mejorar esas relaciones. Aunque tampoco se sabe muy bien qué pretende Dell. ¿Seguir afianzándose en entornos empresariales, volver a intentar vender pantallas táctiles portátiles? Una de las motivaciones para salir de los mercados es no tener que dar explicaciones públicas a nadie. Por sus productos les conoceremos.

Cabe preguntarse si hay algún paralelismo entre ambos casos, un intento de ganarse el apoyo de empresas a golpe de talón. Se hace difícil pensar que Microsoft haya decidido prestar 2.000$ millones a alguien para que le sea infiel. Los demás fabricantes de PCs, en cambio, tienen bien claro que en su objetivo vital de seguir vendiendo PCs e intentar pillar, si pueden, un trozo de tarta portáctil, no va a haber fidelidad a ningún software.

Y no limitan sus infidelidades a Android. Acer, por ejemplo, ha decidido probar con chromebooks. Y, para sorpresa de todos, incluidos este servidor de ustedes, y los linuxeros que están cansados de los chistes de "the year of the linux desktop", resulta que los chromebooks han copado el 5-10% de sus ventas a EE.UU. Es una miseria, pero sorprendente. HP por su parte acaba de presentar su chromebook, Lenovo lo va a probar orientándolo al mercado gubernamental-escolar, y los que ya lo habían adoptado, como el omnipresente Samsung, se están encontrando en el puesto número 1 de portátiles más vendidos en Amazon, por delante de los Macbook.

Como cuentan en ZDNet, esta fiebre por los chromebooks no es una novedad: no se trata más que la reedición de la fiebre de notebooks baratos con linux de hace algunos años. En aquel entonces, Microsoft actuó con rapidez, reanimando XP como sistema operativo con bajo uso de recursos, con mucho éxito. Ahora tendrá que hacer una jugada parecida. Windows 8 no es la catástrofe técnica que fue Vista, pero su polémica interfaz (o el precio de las licencias) están siendo un obstáculo. Pero algo tendrán que hacer: que Microsoft no tenga éxito con los portáctiles y que Windows 8 esté teniendo peor acogida que Vista es un problema, pero que Linux tenga el atrevimiento de empezar quitar cuota de mercado a Windows en su feudo sería como para hacer saltar todas las alarmas.

Tecnología y capital

2013-01-28T23:16:00.002+01:00

Cuando se habla de ordenadores, muchas veces se olvida que se trata de un campo fundamentalmente estadounidense, y que por tanto la política interna de ese país tiene una gran influencia en el sector.

Uno de los aspectos de esa política interna frecuentemente discutidos por gente como la de Occupy Wall Street es el del aumento de la desigualdad entre ricos y pobres y el enriquecimiento indiscriminado de las multinacionales. Sea legítimo o no ese enriquecimiento, basta echar una ojeada a la lista de multinacionales estadounidenses con más dinero en la caja fuerte (una mas larga, pero menos actualizada, aquí) para darse cuenta de un detalle: las multinacionales tecnológicas dominan claramente el panorama. De las cinco primeras, cuatro son tecnológicas: Apple, Microsoft, Cisco y Google; y más adelante hay otras como Oracle o Intel.

Apple merece mención especial: terminó el año 2012 con 137.100$ millones en el bolsillo, el doble que el siguiente de la lista, Microsoft (cabría preguntarse por qué Apple no reduce el margen de beneficios y baja el precio de sus productos para competir mejor).

¿Qué demonios van a hacer estas compañías con todo ese dinero? Quizás parte se lo den a los inversores, quizás parte lo usen para financiar una transición en caso de decadencia. Pero parte de ello lo usarán, sin duda, en investigar y comprar pequeñas empresas con ideas rompedoras. Es decir, para que el sector tecnológico siga sorprendiéndonos -y perdónenme el tono de profetilla- con nuevas y maravillosas invenciones.

Pero lo que venía a querer decir en este post es que me parece posible que esas "invenciones" tengan lugar en un espectro de la industria más amplio del que cabría esperar hoy, dado que parece haber una tendencia a que las fronteras de la "tecnología" se difuminen cada vez más. El sector informático ha estado relativamente contenido en sí mismo durante mucho tiempo, pero la progresiva reducción del tamaño de los componentes está logrando introducir pequeños ordenadores en todo aquel producto tradicional que pueda beneficiarse de software. Lo hemos visto con los teléfonos, se está empezando a ver con la televisión. ¿Por qué no en la automoción, por qué no en otros sectores industriales? No será por falta de dinero...

El menos preocupante estado de ZFS libre

2013-01-17T01:26:00.003+01:00

El pasado Agosto escribí este artículo sobre la decadencia de ZFS-libre. El resumen es que la versión de ZFS usada en proyectos libres como FreeBSD está basada en el código presente hace dos años en OpenSolaris, antes de que Sun fuese comprada, y que Oracle ha dejado de publicar nuevo código de las últimas versiones de Solaris.

El código libre disponible de ZFS queda por tanto anticuado, atascado en la versión de pool 28, mientras que Oracle utiliza la 33, con características ya incompatibles con las versiones viejas, sin contar aquellas que tenga en desarrollo. La única salida, contaba entonces, era que los sistemas operativos libres hicieran un fork.

La buena noticia es que, como podemos ver en estas diapositivas, procedentes del ZFS day, ese fork ya existe en firme y parece tener cierto movimiento. En el PDF detallan varias mejoras hechas al fork, que han dado en llamar "Open ZFS". Lo cual me hace recordar lo ridículo que fue aquel marketing que vendía ZFS como el sistema de archivos universal y definitivo.

Para ser sinceros, las mejoras no son como para tirar cohetes y la actividad aun es escasa (¿implementarán el "bp rewrite", o se darán por vencidos vistos los problemas?). Y la actividad en el resto del kernel Illumos es aun más escasa. Pero al menos los sistemas operativos de código libre que dependen de ZFS ya no están en el limbo en el que han estado en estos dos años.

Predicciones 2013

2013-01-03T01:08:00.004+01:00

No puedo quejarme de las predicciones que hice para el 2012: El netbook está muriendose y las tabletas van camino de superar a los portátiles (demostrando que las críticas unánimes al iPad eran absurdas). Apple sigue siendo líder (ajustado) de cuota de mercado de esas tabletas, el arrebato androidero que se predecía, análogo al del sector smartphone, está ocurriendo, pero con más lentitud. Ubuntu sigue siendo la distribución linuxera de referencia para nuevos usuarios, Google+ está en todos los rincones de Google y Nokia ha caído con la mediocridad esperada (que, por otra parte, todo el mundo menos ellos veía venir). Aunque la predicción que más me gusta es la de "Windows 8 verá la luz, pero a nadie le importará gran cosa", algo que está sucediendo con más intensidad de la que se esperaba. Por otro lado, la "televisión inteligente" sigue sin hacer demasiada aparición, Steve Ballmer sigue en Microsoft, Windows Phone sigue sin arrancar, y Firefox, a pesar de su enorme mejora, no ha detenido su caída.

Procedo entonces a las predicciones de este año. Algunas son renovadas del año pasado:

· Aparecerá la "Apple TV", y habrá movimiento en las televisiones inteligentes.

· Firefox frenará su caída.

· Ballmer se irá de Microsoft.

· Windows 8 tendrá cierto éxito con algunos teléfonos y/o tabletas.

· Microsoft lanzará algún parche oficial para usar Windows 8 con escritorio tradicional y menú de inicio.

· Steam en Linux tendrá gran acogida entre aficionados a los juegos.

· KDE y Gnome se meterán, en serio, a diseñar una versión optimizada para interfaces táctiles.

· Los desarrolladores de Illumos se atreverán a sacar una versión de ZFS con mejoras en el formato de disco.

· Facebook meterá la pata en alguna cosa y como consecuencia Google+ crecerá.

· Algún otro proyecto se saldrá de GNU por discrepancias con la FSF.

· Lennart Poettering buscará otra pieza crítica de infraestructura para reescribir de cero.

· Btrfs será usado como sistema de archivos por defecto en más de una gran distribución.

· Modelo rolling release en Fedora, y potencialmente en Debian.

· Este rumor de un teléfono Tizen hecho por Samsung se quedará en nada.

· Añadido tarde, el 16 de Febrero: las distros empezarán a huir de grub2.

Otra piedrecita en el zapato de la FSF

2012-12-23T22:08:00.001+01:00

Aunque en este blog alguna vez se ha criticado a la FSF y a Stallman, en realidad mi opinión personal sobre el asunto está algo entre mezclada. Comparto sus objetivos de fomentar el software libre, valoro que Stallman dedique su vida a patear el mundo dando charlas, aplaudo el trabajo de asesoramiento legal, me arrodillo ante la lucha contra el incumplimiento de la GPL, y soy consciente de que su tendencia a pensar lo peor de las multinacionales acaba teniendo muchos aciertos (se empeñan en darle la razón). Pero por otra parte se trata de un tipo que mantiene opiniones extremas y a menudo toma decisiones que a mi me parecen francamente estúpidas y que muestran una relación con la realidad un tanto especial.

Esto viene a cuento porque el mantenedor de GNU sed ha renunciado a su puesto. En el anuncio de versión detalla sus razones. No se trata de una ruptura confrontada ni de odios personales, simplemente disconformidades con la forma de gestionar el proyecto GNU. Además, en el propio anuncio nos enteramos de que el mantenedor de GnuTLS está moviendo el proyecto fuera de GNU, por razones parecidas: creen en la causa del software libre, pero están de desacuerdo con la gestión y las decisiones que se toman.

A mi me parece que esto no hace más que confirmar y fomentar la deriva e irrelevancia de GNU tal y como se pretendía plantear originalmente, que era como un proyecto de sistema operativo, y no el repositorio de proyectos variados que es hoy. Por mucho que se empeñen en seguir fomentando el uso del palabro "GNU/Linux", como si las distribuciones Linux fuesen, en cuanto a proyectos, seguidoras en algo de GNU, lo cierto es que la porción de software GNU incluido en una distribución moderna es más bien pequeña.

Las noticias de conflictos entre la FSF y desarrolladores de proyectos GNU no son nuevas, y sospecho que no serán las últimas. En los conflictos de GNU suelen haber un patrón que se repite: los programadores y mantenedores que aportan la mayoría del código se encuentran un día con decisiones o prácticas con las que ellos no están del todo acuerdo. Solucionar esos problemas internos no parece imposible, claro. Pero no hay que esperar milagros, recordemos que el éxito de LLVM (que acaba de anunciar su versión 3.2) se debe en buena parte a la politización de las decisiones técnicas de GCC. GCC siempre fue la joya de la corona, pero ahora que la gente puede pasar olímpicamente de GCC (aunque la muerte de GCC está muy exagerada), su valor se reduce, y con él el de GNU como proyecto. Aunque el software libre sale ganando, claro.

QT 5.0

2012-12-19T23:30:00.002+01:00

Hoy toca versionitis de QT 5.0: anuncio y vídeo

Premio a la chapuza del año

2012-12-17T22:23:00.000+01:00

En Samsung a algún genio se le ha ocurrido incluir un dispositivo en /dev que permite acceso a toda la memoria del sistema en sus dispositivos Android. ¿Permisos de dicho dispositivo? ¡Abierto para todo el mundo! ¡Lectura y escritura! Ha habido otros problemas de seguridad, pero el absurdo que supone algo así no puede describirse con palabras. Es como volver a los tiempos de MS-DOS, sin protección de memoria ni multiusuario ni nada.

Por si esto no fuese bastante, han tenido la magnífica idea de hacer que varias librerías utilicen este dispositivo directamente, tal y como hacía X.org hace años, cuando accedía directamente a memoria para leer el bus PCI, lo cual hace complicado solucionar el problema. Y como remate final, el dispositivo incluye ioctls para sincronizar las caches L1 y L2 de la CPU (¿por qué una aplicación requiere acceso a algo así? Ni idea). Ni tan siquiera se les ha ocurrido usar el /dev/mem que viene de serie en cualquier kernel, se han tomado la molestia de reimplementar la cosa a mano.

Btrfs y colisiones de hash

2012-12-16T21:33:00.000+01:00

A estas alturas habrán leído titulares en muchos sitios de Internet sobre un fallo de seguridad/ataque de denegación en Btrfs, provocando colisiones de hash desvelado por este blog. Como suele ocurrir con las cosas técnicas, la información ha oscilado entre la ausencia y la confusión, de ahí esta entrada.

La mayor confusión es que al mencionar la palabra "hash" junto con "btrfs", mucha gente ha asociado esto con la capacidad de Btrfs o ZFS de hacer checksums de todos los datos del disco, pero no tiene nada que ver. De lo que trata el ataque es del hash de los nombres de los archivos. Organizar el contenido de los directorios con un hash puede sorprender, pero es un método estándar utilizado por todos los sistemas de archivo modernos: Ext3/4, XFS, Reiserfs v3, JFS, ZFS, etc. Los checksums para asegurar la integridad del sistema de archivos son otro asunto.

Para calcular el hash de los nombres de archivo, Btrfs utiliza el algoritmo crc-32c. Como ha demostrado el artículo del blog citado anteriormente, se trata de un algoritmo débil frente a ataques de colisiones; es decir, es relativamente fácil generar a propósito un nombre de archivo cuyo hash crc32c sea idéntico al de otro con un nombre diferente. No pueden existir dos nombres con el mismo hash, por lo tanto se puede imposibilitar la creación de un archivo determinado creando otro que tenga el mismo hash.

El principal problema de Btrfs es que no se gestionan correctamente esas colisiones de hash. Una colisión por si misma no es ningún problema: se detecta fácilmente, se prohíbe la creación del archivo con hash duplicado, se devuelve error, y punto. No poder crear el archivo por la colisión es una molestia pero que se puede gestionar sin problemas, sin embargo, Btrfs parece entrar en un loop infinito para el proceso que encuentra la colisión, y eso es un fallo. Sobre su solución, hace poco que Btrfs ha añadido verdadera gestión de errores (Linux 3.4), y parece que había algunos parches en SuSE relacionados con ello que solucionan el problema de la colisión que aun no están en mainline - o quizás algunos fallos que hacen que el sistema de archivos se remonte en modo de solo lectura (el asunto no está del todo claro aun). En breve se enviarán los parches para 3.8 y para -stable, y Btrfs gestionará el problema normalmente, sin entrar en loops infinitos ni sufrir errores extraños. Hasta aquí el problema en la gestión de colisiones.

El otro asunto es la discusión sobre si el algoritmo de hash utilizado por Btrfs es demasiado débil. Este asunto es un poco más sutil. Lo cierto es que, aunque es cierto que el algoritmo es débil frente a colisiones, no es nada nuevo. El autor de Btrfs ya ha dicho que nunca esperó que crc-32c fuese capaz de resistir ataques colisiones. Seguramente tampoco resistan los de reiserfs, ni Ext4, ni XFS, si se intenta. Incluso ZFS usa CRC-64, que es más fuerte, pero no inquebrantable.

Lo cierto es que los algoritmos de hash utilizados habitualmente para ordenar directorios no se escogen pensando en resistir ataques extremos - de ser así, de entrada no usarían algoritmos como CRC. Esos algoritmos no se escogen pensando en resistir pruebas extremas de seguridad sino más bien en evitar coincidencias casuales y asegurar la integridad de datos (por ejemplo, en archivos comprimidos). Al fin y al cabo, se asume que si alguien permite a cualquier persona crear archivos en un directorio de su propiedad, es su problema (podrían hacerse otra clase de ataques DoS, como simplemente crear el máximo número de archivos posible que permita el sistema de archivos en un directorio).

Además, en los sistemas de archivo se tiene muy en cuenta que el algoritmo sea de cálculo sencillo, para afectar lo menos posible al rendimiento. Una de las razones por las que Btrfs utiliza crc-32c es que las CPUs Intel modernas con soporte SSE4.2 tienen una instrucción crc32c que permite usar ese algoritmo prácticamente "gratis". No parece que el autor de Btrfs tenga intención de cambiar el algoritmo por defecto (aunque quizás acepte otros alternativos para quienes quieran usarlos), simplemente solucionará el problema de gestión correcta de colisiones. Aun así, Btrfs un tiene espacio de 64 bits para almacenar el hash de los elementos de un directorio, por lo que añadir soporte para otro (u otros cuantos) algoritmos no sería especialmente difícil.

Las novedades de Linux 3.7

2012-12-11T14:58:00.002+01:00

Ya se ha anunciado la versión 3.7 del kernel Linux. Esta versión incluye soporte para la nueva arquitectura de 64 bits de ARM, soporte ARM para multiplataforma - la habilidad de arrancar diferentes sistemas ARM con un mismo kernel-, soporte para la firma criptográfica de módulos del kernel, fsync() más veloz en Btrfs y soporte en éste para desactivar copy-on-write para cada archivo utilizando la herramienta chattr, una nueva herramienta "perf trace" que intenta imitar a strace, soporte completo para la característica TCP Fast Open, soporte experimental del protocolo SMBv2 usado por sistemas Windows modernos, soporte estable de NFS 4.1 y pNFS, un protocolo de tunelación que permite transferir paquetes ethernet de la Capa 2 a través de UDP, y soporte para la característica de seguridad de procesadores Intel "SMAP". También se han incluido drivers nuevos y muchas otras mejoras y pequeños cambios. La lista completa de cambios, en inglés, puede encontrarse aquí, como siempre.

· Soporte de ARM multiplataforma: Una distribución Linux típica puede arrancar y funcionar en cientos de modelos diferentes (diferentes CPUs, GPUs, placas madre, chipsets, etc) de un mismo CD. Esta capacidad de arrancar en diferentes configuraciones de hardware es algo habitual en el mundo PC, pero no existía en el mundo ARM Linux. En esta versión, Linux ha añadido soporte para esta capacidad. Esto hará mucho más sencillo el soporte de sistemas ARM por parte de las distros

· Soporte de la arquitectura de 64 bits de ARM: Los modelos más modernos de ARM, ARMv8, añaden por primera vez soporte de direccionamiento de memoria de 64 bits. Estas CPUs pueden ejecutar código de 32 bits, pero el conjunto de instrucciones de 64 bits es muy diferente, no tan solo una extensión de las de 32 bits, así que el soporte de Linux ha sido añadido como una arquitectura completamente nueva - arm64.

· Módulos del kernel firmados criptográficamente: Esta versión añade soporte para firmar módulos del kernel. De ese modo, el kernel puede prohibir la carga de módulos que no estén firmados con la clave correcta - incluso si lo intenta el usuario root. Esta característica es útil para propósitos de seguridad, ya que un atacante que ganase privilegios de root no podría instalar un rootkit utilizando la carga de módulos.

· Mejoras en Btrfs:
* Mejoras de rendimiento de fsync(): La llamada al sistema fsync() escribe los datos modificados de un archivo al disco. El rendimiento de fsync() es importante para software como dpkg/rpm, Firefox, qemu, etc. El rendimiento de fsync() ha sido bastante malo históricamente, pero en esta versión es varias veces más rápido.

* Soporte para desactivar copy-on-write para cada archivo usando chattr: Btrfs puede desactivar copy-on-write para los datos de una archivo usando la opción de montaje "nodatacow". En esta versión es posible desactivar copy-on-write individualmente para cada archivo utilizando el comando "chattr +C archivo" (requiere un e2fsprogs reciente).

Copy-on-write no es beneficios para todo el mundo, y algunas aplicaciones quieren desactivarlo para conseguir mejor rendimiento y menor fragmentación. Nota: Para desactivar copy-on-write es necesario usar chattr en un archivo vacío, no funcionará en uno que ya tenga datos (en ese caso se puede crear un archivo temporal vacío, desactivar copy-on-write en él, copiar los datos de uno a otro y renombrar el archivo). Nota2: Desactivar copy-on-write desactivará también los checksums. Nota 3: Es posible usar chattr +C en un directorio, de modo que los nuevos archivos creados dentro de ese directorio heredarán la desactivación de copy-on-write

* Eliminación del límite de enlaces duros dentro de un sólo directorio: Btrfs no permitía la creación de más de 20 enlaces duros dentro de un mismo directorio. Se ha hecho una modificación del formato del disco para añadir un nuevo tipo de "referencias a inodo" que eleva el límite por directorio a 65K.

* Hole punching: "Hole punching" es la habilidad para desasignar un rango de espacio dentro de un archivo (usando la llamada al sistema fallocate() con el modo FALLOC_FL_PUNCH_HOLE). Btrfs ha añadido soporte para esta característica

· perf trace, una alternativa a strace: El subsistema de trazado perf ha añadido una nueva herramienta: perf trace. Esta herramienta debería parecerse a la venerable herramienta strace, pero en lugar de usar la llamada de systema ptrace(), utiliza la infraestructura de trazado de Linux. Su propósito es hacer el uso de las características de trazado más sencillo a los usuarios. Esta herramienta está en sus primeras versiones, pero mejorará con el tiempo.

· TCP Fast Open (lado del servidor): Linux ya añadió soporte para TCP Fast Open ("apertura rápida") para clientes en Linux 3.6. En esta versión se ha añadido soporte para el lado del servidor, completando de ese modo el soporte.

"Fast Open" es una optimización al proceso de establecimiento de una conexión TCP que permite eliminar un round time trip (RTT) de ciertas conexiones. Fast Open puede mejorar la carga de páginas entre un 4 y un 41%.

· Soporte experimental del protocolo SMBv2: ¡Nota! La lista de cambios de la versión anterior del kernel, ya mencionó esta característica, pero fue un error. El soporte no estaba disponible en esa versión, fue desactivado a última hora y sólo ha sido completado en esta versión.

El sistema de red cifs ha añadido soporte para la versión 2 del protocolo SMB. El protocolo SMB2 es el sucesor de los populares CIFS y SMB, y es el protocolo de invercambio de archivos por defecto en sistemas Windows desde Windows Vista en 2006. SMB2 eventualmente permitirá mejor rendimiento y seguridad y características que no eran posible con anteriores versiones del protocolo.

· NFS v4.1 ya no se considera experimental: El soporte para NFS v4.1 ([http://tools.ietf.org/html/rfc5661 RFC 5661]) ha estado en desarrollo durante mucho tiempo, y en esta versión se ha librado por primera vez de la etiqueta "experimental". La principal característica de NFS v4.1 es pNFS, es decir, "parallel NFS". pNFS permite tomar ventaja de clusters de servidores, permitiendo promorcionar acceso en paralelo escalable a archivos individuales o sistemas de archivos distribuidos entre varios servidores. Un sólo sistema de archivos puede estar repartido entre varios servidores, tanto a nivel de archivo como a nivel de bloque.

· Protocolo de tunelización vxlan "Virtual extensible LAN": Linux ha añadido soporte para vxlan, un protocolo de tunelización que permite transmitir paquetes ethernet de la Capa 2 sobre UDP. vxlan es usado con frecuencia para tunelizar redes en entornos de virtualización. El protocolo vxlan en si mismo es un [http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-02 borrador de RFC] que está diseñado para solventar el problema de número límitado de VLANs (4096), con vxlan el identificador se expande a 24 bits. El protocolo se ejecuta sobre UDP usando un sólo puerto de destino. A diferencia de otros túneles, una vxlan es una red de 1 a N destinos, no sólo punto a punto. Hay una implementación de vxlan para Openvswitch.

· Soporte para la característica SMAP de Intel: El "Supervisor Mode Access Prevention (SMAP)" es una característica que estará disponible en futuras CPUs Intel. Prohíbe al kernel el acceso a páginas de memoria usadas por el espacio de usuario. Esto permite detener ciertos tipos de exploits.

Y eso es todo. La lista completa de cambios en inglés, aquí.

Google añade cadenas a Android

2012-11-16T00:22:00.000+01:00

Que Android tiene algunos problemas de fragmentación no es a estas alturas una noticia. Es más, ni tan siquiera es sorprendente, o evitable. Si permites que cualquier hijo de vecino ponga Android a cualquier cacharro chino, como mínimo tienes que empezar por aceptar la existencia de diferencias inevitables de rendimiento y capacidades entre unos cacharros y otros, que pueden llegar a afectar a los desarrolladores. La fragmentación de Android es algo con lo que hay que reconciliarse y saber convivir.

Aun así, es lógico que Google intente corregir o al menos desincentivar la fragmentación. Puestos a elegir entre fragmentación y no fragmentación de una plataforma, todos preferimos la no fragmentación. Que sea inevitable no quiere decir que haya que aplaudirla y darle facilidades.

Pero hay muchos tipos de fragmentación, y formas y formas de luchar contra ella. Y la que acaba de escoger Google no huele nada bien. Concretamente, Google ha decidido actualizar las condiciones del SDK de Android para el desarrollo de aplicaciones, añadiendo la siguiente línea:

3.4 You agree that you will not take any actions that may cause or result in the fragmentation of Android, including but not limited to distributing, participating in the creation of, or promoting in any way a software development kit derived from the SDK.

Muy bienintencionado, pero esa prohibición entra en conflicto filosófico con las libertades esenciales del software libre. Un ciudadano debería tener libertad plena incluso para crear un SDK alternativo, que fragmente a Android o no, es secundario y hasta irrelevante. Y estas nuevas condiciones no sólo está prohibiendo eso, sino incluso el mero hecho de "participating in the creation of, or promoting".

Naturalmente, nadie está obligado a escribir programas para Android, pero eso no es obstáculo para preocuparse por que Android esté evolucionando hacia una plataforma que no se puede llamar "libre" con propiedad.

Desde un punto de vista histórico, preocupa que Android esté empezando a reproducir los comportamientos de su padre. Android es una plataforma Java y, recuerden que Java es una plataforma que su creador Sun Microsystems promocionaba como abierta -existe un comité donde los grandes participantes acordaban los cambios en común, etc-, pero en la práctica Sun exhibía con frecuencia cierta paranoia ante la posibilidad de un fork, hablando de lo buena que es la uniformidad y de la fatalidad cósmica que sería que alguien la rompiese. Cuando Android vió la luz, todo fueron palabras bonitas, pero no fueron capaces de conseguir que Android comprara licencias y se uniera al mundo Java oficial.

Ante la insistencia de Google de ir por su cuenta, se pusieron serios. Google reaccionó en plan: hey, tan sólo estamos jugando con partes de Java y tratando de crear really cool gadgets, ¿por qué odias la innovación? De ahí surgió, posteriormente a la compra de Sun, el caso de Oracle vs Google por infringir patentes en Android - un intento desesperado de mantener el control de Java a golpe de sentencia, y que nos deparó ese entrañable momento en el que Oracle intentó defender que se pudiera aplicar copyright a una API.

Ironías de la vida, ahora es Google quien empieza a ver con malos ojos que alguien intente romper la uniformidad que tanto despreciaban. ¿Hasta que punto estarán dispuestos a llegar para defender la de Android? ¿Que valora Google más, o valorará dentro de unos años, los principios y la libertad del software o las enormes cantidades de dinero e inversión técnica depositadas en Android?

Windows 8

2012-11-12T21:39:00.001+01:00

Hace tantos años que se viene deseando el fin del monopolio Windows, que parece mentira que haya llegado un punto que parezca que su caída esté, al menos, dentro de las posibilidades. Hasta el propio Steve Ballmer lo admite.

Como es bien sabido, los dispositivos portátiles y táctiles requieren un tipo de interfaces de usuario que difieren en muchos aspectos del conocido esquema WIMP. En el sistema operativo inaugurador del sector, iOS, la nueva interfaz fue introducida a través del "kit" de Cococa UIKit, mientras que el tradicional AppKit de OS X no está disponible en dispositivos portáctiles (portables+táctiles). Por su parte, Android no tenía pasado alguno, así que fue implementado exclusivamente para dispositivos portáctiles.

Windows 8 ha optado por una vía alternativa, consistente en permitir ambas interfaces, la tradicional de Windows y la nueva, para portáctiles, apodada Metro (nombre que Microsoft ha pedido que no se use, pero que usaré de todos modos porque hay que tener mala leche popularizar un término y luego tratar de eliminar su uso). Sin embargo, la capacidad de usar ambos tipos de interfaz se reduce a usarlas dentro del mismo sistema operativo, porque visualmente están prácticamente divorciadas: existen dos escritorios, el escritorio tradicional y el escritorio Metro, y cada tipo de aplicación se ejecuta en su escritorio, y se puede cambiar de un escritorio a otro.

Por esa razón, la sensación de cambiar de un escritorio a otro es parecida a la de cambiar entre diferences máquinas virtuales en un programa de virtualización. Y no es una sensación sólo visual. Cada aplicación Metro se ejecuta dentro de una "sandbox", y esa sandbox no es un entorno libre donde el programador puede hacer lo que quiera, como se hacía en los programas de toda la vida, sino WinRT, una especie de runtime/librería/API (el artículo enlazado es muy recomendable) formada con pedazos de varias tecnologías de Microsoft, que por el momento está orientada a dispositivos portáctiles y a propósitos muy específicos (se permite el uso de Direct3D para crear juegos, pero curiosamente no hay acceso completo a una API tan básica como la API de sockets Berkeley que utilizan todos los sistemas operativos para comunicarse en Internet).

Esta separación de ambos tipos de aplicaciones llega a extremos francamente ridículos. Por ejemplo, la tienda de aplicaciones sólo está permitida para aplicaciones que usen WinRT, con lo cual gran parte de las aplicaciones del escritorio tradicional de Windows están excluidas. ¿Por qué esa limitación, porque no extender la tienda de aplicaciones a todo tipo de aplicaciones? Las aplicaciones WinRT están tan aisladas que ni tan siquiera han facilitado la comunicación con las aplicaciones del escritorio tradicional: No sólo es que sea técnicamente se hayan prohibido deliberadamente ciertos mecanismos de IPC, es que las propias reglas de la tienda de aplicaciones lo prohiben expresamente.

Usar un sistema operativo que está divorciado de este modo consigo mismo es bastante fustrante. Por una parte, se mantiene la compatibilidad con el universo tradicional Windows, pero complican deliberada e innecesariamente su uso habitual a quienes no están interesados en Metro. El escritorio por defecto es siempre el escritorio Metro, hay varias acciones que sacan al usuario forzosamente del escritorio tradicional cuando se encuentra en él, y se elimina el botón "start" y su menú. Estas decisiones son completamente "políticas", no técnicas, y son el principal origen de quejas. La gente no entiende por qué no hay ninguna opción, o siquiera clave de registro, que permita establecer el escritorio tradicional como escritorio por defecto, y la recuperación del botón de inicio (hay que recurrir a aplicaciones de terceros). ¿Es que Windows ha sido invadido por desarrolladores como los de Gnome 3?

Tal vez en parte, pero existe una razón más importante, y es que es obvio que Windows 8 ha sido diseñado fundamentalmente para dispositivos portáctiles. Al fin y al cabo, es ese sector en el que Microsoft está necesitado de ganar cuota de mercado y relevancia. Seguramente preveen que la mayor parte de escritorios va a quedarse con Windows 7 y no les importa, lo que quieren es plantar cara a Apple y a Android.

¿Y qué tal es Windows 8 en ese campo, qué tal es el escritorio táctil Metro? No he tenido la oportunidad de probarlo en tableta, pero dado que el escritorio Metro está diseñado para poder ser usado con teclado y ratón, es fácil hacerse una idea. Y lo cierto es que en muchos aspectos es francamente bueno: los gráficos son muy fluidos, y el estilo de las aplicaciones Metro tiene su sitio. La pantalla inicial Metro, con sus "tiles" dinámicos, es en principio una buena idea, aunque han simplificado el concepto demasiado. En resumen, se puede decir que Microsoft ya no tiene carencias como plataforma portáctil. Pero eso no basta: se nota la falta de madurez y la desventaja de su tienda de aplicaciones frente a iOS y Android.

Esa desventaja parece insuperable a día de hoy, pero sólo el tiempo dirá lo que ocurre. Lo cierto es que aunque en el mundo de los smartphones está difícil, Windows 8 tiene algunas posibilidades en el mercado de las tabletas. Es sabido que Android no ha tenido en las tabletas el mismo éxito arrollador que tuvo en smartphones. Matthew Yglesias contó que esto se debía a razones puramente económicas: el negocio telefónico está dominado por empresas de telecomunicaciones que están incentivadas a ofrecer teléfonos con Android porque ganan más dinero con ello, pero a los centros comerciales y tiendas artículos electrónicos no les importa vender una tableta iPad o Android siempre y cuando vendan uno, por lo que la competencia está más igualada. Aunque Android está avanzando en este mercado rápidamente, que el aun líder del mercado haya lanzado el iPad mini demuestra que es un mercado menos establecido. Windows 8 puede encontrar ahí un hueco.

Por lo demás, Windows 8 es un sistema operativo rápido y ligero. Los tiempos de arranque son buenos (utilizan una técnica muy curiosa, consistente en hibernar una sesión del sistema justo hasta el punto en el que comienza la sesión del usuario, y resumir esa imagen en cada arranque), la interfaz -tanto la Metro como la tradicional- es rápida. De no ser por el asunto de Metro, sería un sustituto indiscutible de Windows 7, pero la marginación del escritorio tradicional y el forzado de una interfaz táctil lo convertirá en una oveja negra para mucha gente.

AMD se da por vencida, Intel y ARM no

2012-10-30T15:48:00.003+01:00

Del mismo modo que Intel es un ejemplo de multinacional letalmente competitiva, capaz de cometer errores mastodónticos y corregirlos sin perder el liderazgo, AMD ha acabado convirtiéndose en ejemplo de lo contrario. El único buen momento de AMD en la última década fue el Opteron, una joya que no supieron capitalizar y que se ha convertido en una excepción en su historia. Hoy, en un mundo en el que la eficiencia de un procesador importa a veces más que su rendimiento bruto, han decidido no enfrentarse al mundo y pasar a usar ARM en servidores.

Que AMD recurra a procesadores ARM para algo es equivalente a reconocer que no son capaces de crear procesadores x86 de bajo consumo equivalentes. Es más, probablemente una de las razones que les ha impulsado a tomar esta decisión es que ARM iba a acabar comiéndose parte de su mercado de servidores, y han preferido unirse a otro bando antes que perder la guerra x86 vs ARM. Intel, por su parte, ha empezado con desventaja, pero al menos tienen intención de presentar batalla y ganarla.

Tras esta reorganización de bandos en el campo de procesadores de bajo consumo, prácticamente todos los competidores de Intel en el campo de semiconductores se han unido en el lado de ARM, e incluso algunos aliados tradicionales en otros campos, como Microsoft, han declarado su neutralidad. La pelea será cruel.