Otra piedrecita en el zapato de la FSF

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

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

Premio a la chapuza del año

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

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

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

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

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

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.

Curiosidades de Flash en Linux

No sólo el soporte de Flash en Linux está en vía muerta, sino que el que hay es difícil de usar. Como ejemplo, me encuentro con este vídeo, imposible de encontrar en otro lado, así que intento descargármelo.

Para ello intento buscar en la fuente de la página el enlace al vídeo en la página, pero el que supuestamente se usa como fuente no existe o no funciona. Dejo que se descargue entero y procedo a buscar el archivo del vídeo en el caché de Firefox, algo que solía funcionar. Pero en el caché de Firefox no hay nada, ni en el cache del disco ni el cache de la memoria. Parece que intentan hacer desaparecer los vídeos y evitar que la gente se los descargue (lo cual sorprende tratándose de una URL terminada en .ru).

Sin embargo, el vídeo está evidentemente en mi sistema: lo estoy viendo. En alguna parte debe estar. Como último recurso, recurro a echar un ojo a los descriptores de archivos del proceso aislado en el que Firefox pone al reproductor (/proc/PID/fd/). En él, encuentro que el proceso tiene el descriptor 20 apuntando a un archivo curioso:

20 -> /tmp/FlashXXsKXrQ0 (deleted)

El archivo asociado el descriptor, /tmp/FlashXXsKXrQ0, ha sido borrado, pero como es norma en sistemas Unix, los procesos que lo tenían abierto siguen podiendo acceder a él. Ese archivo ya no existe, no puedo acceder directamente a él, pero si que puedo hacerlo mediante /proc. Con un simple "cp /proc/PID/fd/20 ~/archivo" recupero el archivo y, efectivamente, es el vídeo que quería descargar.

Aparentemente, Adobe quería dificultar la descarga de vídeos, como una especie de DRM simplista. Para ello decidieron crear un archivo en /tmp/ y abrirlo, proceder inmediatamente después a borrarlo para que nadie lo viese, y seguir trabajando internamente con ese descriptor asociado a un archivo "oculto".

Por qué Haiku/BeOS es un sistema operativo desfasado

Es inevitable: cada cierto tiempo, se publica en alguna parte de Internet un artículo en el que se relata la eterna historia de BeOS y su reencarnación Haiku, el sistema operativo que nos rescatará de todos los quebraderos de cabeza que nos causan los sistemas operativos modernos. Es comprensible que los periodistas tecnológicos hacen sitio a cosas llamativas como estas, pero va siendo hora de enumerar los defectos, mitos y exageraciones varias sobre el utopismo de Haiku, que alguna vez han sido mencionadas en este blog pero que nunca han sido analizadas a fondo.

· Sistema operativo de escritorio: BeOS se hizo famoso en su día por la interactividad de su interfaz, rapidez en la respuesta a las acciones del teclado y ratón, y poder reproducir varios vídeos simultaneamente sin ningún problema. Algo que puede resultar poco sorprendente hoy en día, pero que entonces Windows, Linux, y Mac OS no podían hacer.

Sin embargo, trasladar el argumento al presente sería una locura y un olvido de la realidad de mediados-finales de los 90. En aquellos tiempos los sistemas operativos bien diseñados se encontraban en los servidores, los escritorios vivían en una realidad alternativa y eran, por lo general, bastante cutres. Los Windows de la época eran los 9x, ese engendro demoniaco que se iniciaba a partir de MS-DOS, y en el que un proceso cualquiera podía colgar el sistema. Mac OS no tuvo multitarea apropiativa ("preemptive") hasta la versión 9.0, sólo dos años antes de la aparición de OS X. Respecto a Linux, sus características de servidor eran sólidas, pero su implementación interna no era nada óptima para un escritorio. Estamos hablando de los tiempos de Linux 2.0, la primera versión que soportaba SMP y que, desde luego, no soportaba ninguna clase de "preemptitividad": Cuando un proceso hacía una llamada al sistema, el resto de procesos tenían que esperar a que terminara si ellos querían hacer otra. Para un sistema de escritorio algo así era monstruoso.

Que BeOS fuese un buen sistema de escritorio y otros muy malos no tiene nada de sorprendente, como tampoco lo tiene que los que fueron malos se hayan convertido a base de trabajo en buenos, mientras que BeOS y Haiku han ido empeorando debido a las exigencias elementales del hardware moderno: Haiku carece de capacidades elementales de gestión de energía y ni tan siquiera puede suspender a memoria, por ejemplo.

· Sistema gráfico: El subsistema gráfico de BeOS era excelente, pero fue diseñado para un mundo 2D, pre-GPU, donde las cosas eran muy diferentes a lo que son hoy. El soporte 3D sólo existió como algo experimental y, desde luego, no tomaba parte en los gráficos de la interfaz.

Todos los sistemas operativos llevan varios años rediseñando por entero sus subsistemas gráficos -arquitectura de los drivers del kernel, servidor gráfico, toolkits- para adaptarse a la nueva realidad de la potencia de las GPUs, y aunque ya se usa todo este trabajo en los toolkits para pantallas táctiles, aun no hemos empezado a ver de verdad los resultados visuales de todo esto (imagínense un escritorio donde los iconos no sean simples imágenes a los cuales el diseñador pinta un sombreado para dar sensación de profundidad, sino objetos 3D con sombra generada por la GPU y capaces de reaccionar con animaciones complejas, como en un juego).

Haiku lleva mucho retraso frente a los toolkits actuales. Aun no implementa la capacidad de "compositing" que les permitiría soñar con imitar los efectos que Compiz hacía hace años, no digamos ya frente a cosas como Wayland + QML.

· Multithreading: Una de las decisiones que hicieron los diseñadores de BeOS fue optimizar para ordenadores con múltiples procesadores: aunque su predicción se retrasó una década, está claro que acertaron en su visión.

Sin embargo, existe mucha mitificación al respecto de lo que BeOS llamó "Pervasive Multithreading". En realidad, se reducía a utilizar threads por doquier (una solución inferior a la de Grand Central Dispatch en iOS), sobre una base de código fundamentalmente en C++. En los 90, el soporte de threads en Linux era patético y lo de BeOS podía resultar llamativo, pero hoy en día no tiene nada de particular. De hecho, un escritorio Linux moderno utiliza bastantes threads: Mi firefox usa nada menos que 31, el lector de correo 3, el programa de música 12, el lector de feeds 2. A veces echo de menos que los programadores no aprovechen más otras CPUs, pero es una cuestión de vagancia, más que de incapacidad técnica.

Bien es cierto que BeOS tiene el mérito de haber usado threads como parte fundamental del diseño de las librerías básicas del sistema, y que varios objetos de la API de BeOS usan threads, de modo que las aplicaciones los utilizan automáticamente. Esto no es necesariamente malo, pero requerir a los programadores utilizar threads y usar bloqueos correctamente como parte normal de su rutina, y forzarles a ello no porque exista necesidad de paralelizar algo sino "por diseño", no tiene porque ser la mejor decisión del mundo.

En este post, un tipo cuenta como el toolkit gráfico java AWT fue diseñado en un principio como multihilo, al igual que BeOS, pero luego acabaron moviendose a un loop de eventos, porque complicaba las cosas, fomentaba la aparición de fallos y no era necesario. BeOS tenía problemas de estabilidad debido a los fallos derivados de la complejidad de su GUI multihilo, e incluso hubo empresas que paralizaron ports de aplicaciones por los problemas que esto causaba.

En esencia, Haiku no tiene nada especial que lo haga más apto para el aprovechamiento masivo de multiprocesadores. Más allá del soporte de SMP y de threads en el kernel, las capacidades de programación multihilo podrían ser, en todo caso, ser consideradas como una problema del lenguaje: usar threads en C++ viene a ser lo mismo tanto en BeOS como en Linux, y aprovechar las capacidades de concurrencia masiva de Erlang viene a ser lo mismo en ambos sistemas.

· Microkernel: Hay gente que cree que BeOS era un microkernel. Lo cierto es que no lo fue, ni tampoco lo es Haiku. Los drivers, el sistema de archivos, el vfs, la pila de red...todos están en el mismo espacio de direcciones que el kernel. No entiendo de la gente de llamar a esto "microkernel híbrido" o cosas así: en realidad, en este punto BeOS y Haiku vienen a ser similares a Linux.

· Sistema de archivos de 64 bits, con journaling y base de datos: BFS era un buen sistema de archivos en su día, pero el journaling ha dejado de usarse en los sistemas de archivos de última generación, la amplitud del direccionamiento de datos de 64 bits no tiene nada de especial, y le falta la capacidad de comprobar checksums y la gestión de volúmenes integrado para estar al día con ZFS y Btrfs.

Respecto a los índices de atributos que lo convertían en una pseudo base de datos, me parece la característica más importante de BeOS y su innovación más relevante. Sin embargo, lo mismo se puede decir de otros sistemas de archivos que han intentado mezclar sistemas de archivo con bases de datos, como WinFS o Reiser4 (aunque estos fracasaron por aspirar a demasiado, a diferencia de BFS).

Lo cierto es que aunque los índices de atributos eran muy prácticos, no eran una solución completa para una búsqueda integral del sistema: por ejemplo, no podían buscar palabras dentro de un archivo de texto. Para implementar algo como Spotlight, los índices de atributos de Haiku serían útiles, pero no suficientes.



Resumiendo

Si, BeOS fue muy innovador, y si hubiera tenido éxito y se hubiese invertido en él, hubiese sido un gran sistema operativo. Desgraciadamente eso no ocurrió, y el desfase tecnológico pesa demasiado. No tengo nada en contra de Haiku, en contra, me parece interesante, pero de ahí a decir que el escritorio Linux es una castaña y que sólo nos salvaremos con la Segunda Venida de BeOS en forma de Haiku va una gran distancia.

Oracleización de Solaris

Cuando Oracle compró Sun, algunos temimos que la principal desgracia para Solaris iba a ser el proceso de oracleización, en el sentido de que Solaris iba a dejar de ser poco a poco un sistema operativo de propósito general, para convertirse en uno de un sólo propósito específico. Ese propósito específico sería, por supuesto, ejecutar la base de datos de Oracle y middleware de la misma compañía.

Sun, ya de por si, había convertido a Solaris en un "Oracle OS", pero en manos de Oracle cabe imaginar que el efecto se multiplicaría hasta convertirse en el principal factor de diseño. Algo que también funciona en el sentido contrario: cabía esperar que OracleDB acabara centrándose en Solaris e incluso dependiendo de él para funcionar bien. Hoy, en el anuncio de Solaris 11.1, se puede comprobar la existencia de esa tendencia:

"Improve Oracle Real Application Clusters lock latency by 17% by offloading lock management into the Oracle Solaris kernel"

Aunque no tengo detalles tećnicos (ni espero conseguirlos) sobre la implementación de esta característica, el transfondo está claro, como lo está el de otras cuantas características incluídas en esta versión que se han hecho para facilitar, de una u otra manera, la vida a OracleDB.

Pero una vez que los problemas de rendimiento de la base de datos se resuelven modificando el SO, es inevitable que se preste menos atención a los problemas de rendimiento en otros SOs que no tienen esas mismas características u optimizaciones, y que no se molesten en implementar en OracleDB cosas que si implementarían de no controlar directamente Solaris. Es más, en el anuncio de Solaris 11.1 usan esta frase como marketing: "Adds Unique Oracle Database Support". ¡Se sienten orgullosos de que OracleDB no funcione bien en otros SOs!

Poco a poco, sólo merecerá la pena usar OracleDB para ejecutarlo en Solaris, y sólo merecerá la pena usar Solaris para ejecutar OracleDB.

Las novedades de Linux 3.6

Ya se ha anunciado la versión 3.6 del kernel Linux. Esta versión incluye soporte de cuotas de espacio en subvolúmenes de Btrfs, así como grupos de cuota, diffs de snapshots, y mayor libertad para el uso de clones de archivos. También se soporta un modo suspensión híbrida en el que se suspende al disco y a la memoria al mismo tiempo, un modo de apertura rápida de conexiones para TCP, un sistema para límitar la longitud de las colas de TCP, soporte para swap seguro a través de NFS y NBD, soporte para el protocolo SMB v2, mejoras en el soporte de cuotas de Ext4, soporte para el estado energético D3cold en el bus PCIe, y VFIO, que permite el acceso directo y seguro a los dispositivos de hardware por parte de máquinas virtuales. 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. 

· Btrfs: cuotas en subvolúmenes, grupos de cuotas, diffs de snapshots, clones de archivo a través de subvolúmenes
  · Cuotas de subvolúmenes y grupos de cuotas: Se puede configurar un tamaño máximo para cada subvolumen. Una vez que el subvolumen llegue al límite, no será posible escribir más en él. Esta característica puede utilizarse como sustituto de las cuotas de disco tradicionales, asignando a cada cuenta de usuario un subvolumen y poniéndole un límite.

Sin embargo, gestionar las cuotas de cada subvolumen puede ser complicado si se tienen muchos archivos. Por ello, Btrfs soporta el concepto de grupos de cuota. Es posible crear un grupo de cuota e introducir en él varios subvolúmenes, para que se aplique un límite común a todos ellos.

  · Diffs de snapshots, también conocido como "send/receive": Btrfs puede compilar las diferencias entre dos snapshots y enviar las diferencias entre ambos a un archivo. Este archivo puede ser usado posteriormente para reconstruir esas diferencias. El principal, aunque no único, uso de esta característica, son las copias de seguridad.

  · Archivos clonados trans-subvolumen: El mecanismo de copy-on-write de Btrfs permite que varios archivos compartan los mismos datos. Esto permite copiar árboles de directorio enteros (cp --reflink) sin duplicar el espacio utilizado. Pero existía una limitación: No es posible clonar archivos a través de diferentes subvolúmenes. Esta limitación ha sido eliminada (aun es imposible clonar archivos que cruzan diferentes puntos de montaje)

· Suspensión híbrida al disco y a la memoria al mismo tiempo: En los equipos portátiles que usan batería, es útil que al suspender, se hagan dos suspensiones: una al disco, como si fuera una hibernación pero sin apagar el sistema, y despues de esa una suspensión en memoria. Si al equipo se le acaba la batería, es posible despertar el equipo desde la imagen de hibernación; si no, se despierta normalmente. Este sistema es utilizado por OS X y Windows. Para probarlo, puedes hacer "echo suspend > /sys/power/disk; echo disk > /sys/power/state".

· Soporte para el protocolo SMB v2: 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.

· TCP Fast Open: "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%. En esta versión sólo se incluye el soporte para cliente, el de servidor llegará en próximas versiones.

· Lucha contra el bufferbloat: TCP small queues: TCP "small queues" (colas pequeñas) es otro mecanismo diseñado para luchar contra el mal del bufferbloat. Su objetivo es reducir el número de paquetes en las colas de envio. Sin reducción nominal del ancho de banda, se consiguen grandes mejoras en la latencia

· Swap seguro sobre NFS/NBD: El Linux Terminal Server Project recomienda el uso de un dispositivo de bloque por red (NBD) para configurar el swap, de acuerdo con el manual. También hay documentación y tutoriales de como hacerlo en varios sitios, y el propio nbd-client documenta su uso para tales fines. A pesar de eso, una máquina usando NBD para swap podía colgarse en minutos si se usaba el swap intensivamente. Esta versión permite usar swap sobre NBD y también sobre NFS de forma totalmente segura.

· Mejor soporte de cuotas de disco en Ext4: Ext4 ha añadido soporte para cuotas como una característica de primera clase, lo cual significa que en lugar de ser archivos visibles en la jerarquía de directorios, los archivos de cuota se almacenarán en inodos ocultos al usuario, como metadatos del sistema de archivos, y serán gestionados directamente por e2fsprogs, y las cuotas serán activadas automáticamente tan pronto como el sistema de archivos sea montado.

· Soporte del estado de energía D3cold en PCIe: Esta versión añade soporte para el estado energético D3cold. D3cold es el estado energético más profundo en un dispositivo PCIe, ya que la energía se desconecta completamente para el dispositivo.

· VFIO: acceso seguro a dispositivo desde drivers de espacio de usuario: El driver VFIO es un framework que permite exponer directamente dispositivos a espacio de usuario de un modo seguro. En otras palabras, permite drivers en espacio de usuario totalmente seguros y no privilegiados. ¿Para qué quiere Linux algo así? Los sistemas de virtualización hacen uso frecuente del acceso directo a los dispositivos para lograr el máximo rendimiento. Desde un punto de vista del host y del dispositivo, esto simplemente convierte a la VM virtualizada en un driver de espacio de usuario, con el beneficio de latencia reducida, mayor ancho de banda, y acceso directo del driver. Algunas aplicaciones, particularmente las relacionadas con la computación de alto rendimiento, también se benefician del acceso directo a dispositivos desde el espacio de usuario,


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

Cuando hacer cosas útiles hace que la gente te odie

A Ubuntu le está cayendo una buena tormenta de críticas por hacer que Unity integre por defecto búsquedas en la tienda de Amazon. ¿La razón? Privacidad del usuario. Mark Shuttleworth ha salido a defenderlo, argumentando que no afecta a la privacidad porque las búsquedas no se hacen directamente a Amazon sino a través de los servidores de Canonical, tras filtrar los detalles de los usuarios; o que se puede eliminar esta funcionalidad eliminado un paquete, pero no le ha servido de mucho.

A mi esta tormenta me parece una reacción exagerada. Si están preocupados por su privacidad, creo que se han perdido una noticia bastante aterradora: Ubuntu utiliza Firefox con Google como buscador por defecto, a cambio de dinero por cada búsqueda. Si tienen remordimientos por enviar información personal a empresas, deberían preocuparse bastante más por Google que por unas búsquedas de Amazon anonimizadas de antemano. Y si no utilizan complementos como ghostery (firefox, chrome), directamente deberían ponerse a correr en círculos dando gritos.

Más allá de la cuestión de la privacidad, insertar estos resultados no me parece una una mala idea. En un mundo ideal, la gente debería poder comprar contenidos multimedia legalmente a golpe de click y sin demasiados mareos. Aunque esta funcionalidad no llega tan lejos, lo acerca considerablemente, y aunque a mucha gente "geek" no le guste, es la clase de cosas que a la gente "normal" -la mayoría de la población- si que puede gustarle. La idea de tener una especie de Google bien integrado en el sistema operativo para facilitar la vida a la gente es muy atractiva y abre la puerta a muchas posibilidades.

En resumen, que Ubuntu está intentando simplificar el acceso a contenidos y no ha empeorado la privacidad más de lo que ya lo hace, pero aun así no dejarán de caerle críticas. Estoy seguro que dentro de un año nadie se acordará de estas cosas.

Lo que no mató a Linux en el escritorio

Miguel de Icaza ha escrito un post, titulado "What killed the Linux Desktop", que ha hecho cierto ruido. Como me va la marcha, voy a comentarlo un poco.


El post comienza contando la instalación de un nuevo disco duro. Llegado al punto de conectar a los altavoces, Icaza piensa esto:

"[...] when I got to the speakers cable, I just skipped it. Why bother setting up the audio? It will likely break again and will force me to go on a hunting expedition to find out more than I ever wanted to know about the new audio system and the drivers technology we are using"

Tan autocríticos somos en el mundo del software libre, que no contentos con quejarnos de los problemas que tenemos, también nos quejamos de los problemas que sospechamos que podríamos tener. ¿No enchufar el cable de sonido sólo porque "probablemente" no funcionará?

La verdad es que nunca he entendido la obsesión que hay con el tema del sonido y su supuesta inestabilidad. Linux 2.6.0 incorporó ALSA hace ya casi 9 años, que además se proporcionaba compatibilidad con la anterior API, OSS. ¿Dónde está el infierno de cambios y reescrituras? Desde aquello el único gran cambio ha sido Pulseaudio, que causó cierto impacto, fundamentalmente por la baja calidad de drivers y de la implementación de sonido del plugin de Flash, que ya han sido resueltos. Pero de eso ya han pasado 4 años y medio. A día de hoy hay gente que usa cascos bluetooth en Linux sin muchos más problemas que los que sufren algunos usuarios de Windows cuando tienen que andar lidiando con software de bluetooth de escandalosamente baja calidad proporcionado por el fabricante. Pero sigamos:

"Linus, despite being a low-level kernel guy, set the tone for our community years ago when he dismissed binary compatibility for device drivers."

Este mito estúpido de que en el kernel la compatibilidad binaria no importa empieza a ser cansino. Linux mantiene la compatibilidad binaria en las llamadas al sistema. Que es, al fin y al cabo, lo que tiene que ofrecer todo sistema operativo al mundo, y que es lo que verdaderamente importa. Es más, no sólo la mantiene, sino que la mantiene mejor que las librerías. En todos estos años, Linux no ha cambiado la compatibilidad binaria de las llamadas al sistema ni una sola vez.

Existe cierta obsesión con que esto mismo debería aplicarse con los drivers, que son en realidad plugins del kernel, y no aplicaciones construidas encima de una libreria. La verdad, no entiendo por qué. Desdeñar la participación privativa en materia de drivers fue algo arriesgado, pero ha tenido éxito. Linux tiene un soporte de hardware de consumo muy bueno, hay varios fabricantes importantes que facilitan ellos mismos los drivers libres, y el hardware que no se soporta es minoría. ¿A alguien le parece razonable obsesionarse con facilitar el trabajo de los drivers propietarios para agradar a minorías, en lugar de apostar por el sistema que ha proporcionado mejores resultados hasta hoy? Eso por no mencionar las consecuencias para el kernel de limitar su capacidad de evolución interna.

"The attitude of our community was one of engineering excellence: we do not want deprecated code in our source trees, we do not want to keep broken designs around, we want pure and beautiful designs and we want to eliminate all traces of bad or poorly implemented ideas from our source code trees"

No deja de ser curioso que esto lo diga alguien que ha dedicado muchos años a implementar una tecnología que en el universo Microsoft representa exactamente ese espíritu de mandarlo todo a paseo y empezar de cero, como bien dijo Joel Spolski. ¿Recuerdan Silverlight y su intento de reinventar nada menos que la web, recuerdan como Mono lo copio con su Moonlight, y como ahora han tenido que dejar de darle soporte porque ni Microsoft apuesta por ello? Es una definición perfecta de reinventar por reinventar. Por no hablar de Windows Phone 7, que mandó a paseo gran parte del software disponible para Windows CE sólo para mayor gloria del imperio C#.

Pero respecto a Linux, al margen de que eso de que la compatibilidad se rompe constantemente y es imposible desarrollar nada está muy exagerada, lo cierto es que la búsqueda de la excelencia técnica fue, es y seguirá siendo una característica muy deseable, muchas veces por encima de la compatibilidad. Linux ha sido un sistema operativo retrasado técnicamente en lo que al escritorio se refiere, por lo que la mejora técnica a base de reescrituras puede dar sensación de inestabilidad, pero también lo es de evolución. En realidad nadie puede evitarlo, incluso Microsoft rompió la compatibilidad binaria de los drivers de tarjetas de vídeo para rediseñar de cero un nuevo subsistema gráfico.

Si se paran a pensar, se darán cuenta que muchas de esas "obsesiones técnicas" nos han proporcionado beneficios a largo plazo. ¿Dónde estarían KDE y GNOME de haber tenido que conservar la compatibilidad con sus versiones 1.0? Además, dado que en Linux casi todo es software abierto, romper la compatibilidad es mucho más sencillo, y si una aplicación deja de poder usarse porque nadie se molesta en portarla a nuevas APIs, se puede afirmar que hay muchas posibilidades de que esa aplicación no merezca la pena y esté completamente desmantenida. Icaza menciona que en Windows 8 será posible utilizar el Photoshop que se publicó hace 8 años, pero cabría preguntarse si tiene tanto sentido dar prioridad a los que quieren utilizar software de hace 8 años.

The second dimension to the problem is that no two Linux distributions agreed on which core components the system should use

Red Hat tampoco se ha puesto de acuerdo con nadie para decidir qué componentes usar, y no parece haberles afectado demasiado. Una vez que una distro se hace un hueco en su campo, los fabricantes de software privativo no tienen problema en prestarle atención. 

We alienated every third party developer in the process. The ecosystem that has sprung to life with Apple's OSX AppStore is just impossible to achieve with Linux today.

Quizás porque, en realidad, Linux nunca ha pretendido ser una plataforma donde el software propietario pudiese hacer su agosto, salvo excepciones. Siempre ha sido una plataforma en el que la prioridad la tiene el software libre. Si Linux ha de tener éxito entre desarrolladores de código propietario, no lo hará porque el ambiente de los proyectos libres sea tal o cual o la compatibilidad se rompa mucho o poco, lo hará gracias a que una empresa haga lo que Red Hat hizo en los servidores. Es decir, gracias a algo como Ubuntu/Canonical.




Y para terminar, hay que señalar que el post de Icaza habla en todo momento en un tono de "guerra perdida". Aun siendo una anécdota, el escritorio Linux nunca tuvo mejor posición que hoy, y el futuro es esperanzador. Ubuntu se ha convertido en una alternativa que la gente normal es capaz de usar e incluso disfrutar. Y aunque en materia de smartphones el software verdaderamente libre lo tiene de momento bastante negro, de cumplirse la analogía Jobsiana de los escritorios y los camiones, es previsible que las compañías comerciales se dediquen a los dispositivos móviles y que Linux empiece a campar por el escritorio con más comodidad.

El preocupante estado de ZFS-libre

Desde que se publicó el código de ZFS bajo la CDDL, hay unos cuantos sistemas operativos que lo han portado, desde FreeBSD y OS X al propio Linux. Esta portabilidad, por cierto, se debe a que ZFS, más que un sistema de archivos, es una implementación completamente independiente del sistema opeartivo de todo lo relacionado con todo lo que sea I/O. Todos estos usuarios han disfrutado de esta liberación de código, a algunos casi les ha servido de salvavidas (FreeBSD).

Y sin embargo, la compra de Sun por parte de Oracle podría amenazar a todos estos usuarios, al menos en cierta parte, y potencialmente en gran medida. ¿Cómo? Pues porque resulta que hace casi dos años que Oracle no publica el código que desarrolla en privado.

ZFS ha ido añadiendo pequeñas características y cambios de formato con el tiempo. El último código libre que Sun mostró al mundo de ZFS corresponde a la "versión de pool" 28. La última versión de pool disponible en Solaris es la 33. En esas cinco versiones se encuentran mejoras notorias, como el soporte de encriptación y mejoras de rendimiento, y en general dos años de trabajo, pero nada de eso ha llegado a los usuarios de las versiones libres, los cuales se limitan a seguir usando la misma versión de ZFS de hace casi dos años a la cual sólo se han añadido fundamentalmente parches de mantenimiento y mejoras en la integración del port.

En teoría, Oracle es consciente de la situación; aunque abandonaron el desarrollo de OpenSolaris como proyecto abierto se suponía que seguirían publicándo el código abiertamente, y se dice que prometieron cumplir y liberar el nuevo código algún día. Pero en estos dos años, lo más significativo que ha hecho Oracle respecto al software libre es intentar forzar la aplicación del copyright a las APIs de software, que manda narices. No es de extrañar que muchos pongan dudas de que vayan a cumplir su palabra.

Siempre podrían sorprendernos, claro. Pero permítanme explicarles porque tengo mis dudas. Una de las "startups" más exitosas enfocadas hacia el almacenamiento de datos últimamente es Nexenta, que se basa en gran medida en ZFS, y que tras la desaparición de OpenSolaris se encargó de liderar la formación de Illumos. Los ingresos de esta joven empresa crecieron en 2009 un 385%, en 2011 las ventas fueron ya de $300 millones anuales, y este año preveen aumentar sus ventas otro 350%, lo cual les colocaría alrededor de los 1.000$ millones anuales en ventas. Y recordemos que se trata de una empresa joven. Mientras tanto, las ventas de hardware de Oracle, herederas de la antigua Sun, y que no han dejado de caer desde la compra de la empresa, fueron en el primer trimestre de 2012 (ojo, sólo un trimestre) de $453 millones, con una caída interanual del 25%, colocándole en la sexta posición en ventas de servidores.

Ya ven lo que son las cosas: una startup basada en un solaris libre que podría superar en pocos años a las ventas de Sparc de la antigua Sun. ¿Creen ustedes que Larry Ellison va regalar por la cara a Nexenta y otras compañías el código necesario para que sigan haciéndose ricos a costa de la tecnología de la empresa por la que él pagó tanto dinero? Yo tampoco.

No hay duda de que a Nexenta no le debe hacer demasiada gracia ser una empresa de almacenamiento con tantas expectativas de futuro y seguir basándose en un sistema de archivos libre que lleva dos años abandonado a propósito. Tampoco les debe hacer gracia a otros sistemas operativos que usan el port libre. Así que se han unido todos ellos y, según cuentan los mentideros, han formado  -aunque el anuncio ya tiene un año de antiguedad- una lista privada con una especie de ZFS Working Group, en el que hacen planes para lo que, esencialmente, sería un fork de ZFS. De momento, ya han sustituido las "pool versions" por un sistema de versionamiento basado en características, al estilo de Ext4. El hecho de que varios programadores de ZFS en Oracle hayan desertado para ser recontratados por empresas que usan ZFS seguramente ayudará a esta operación que a la vista de la evolución de los acontecimientos se hace inevitable.

Pero aun están por dar la cara, demostrar que son capaces de liderar y desarrollar algo por su cuenta, y avanzar. Por el momento, el ZFS abierto sigue con sus dos años de retraso respecto al de Oracle.

Mejores noticias para Qt

Hace un año y unos meses me pareció una buena noticia que Nokia vendiera la rama de licencias comerciales y consultoría de Qt a Digia, uno de sus "partners" más comprometidos. Por eso me parece una noticia aun mejor que Nokia le venda a Digia el resto de Qt.

El optimismo de este servidor de ustedes no es infundado. En realidad, lo peor que le podía pasar a Qt es no ser vendida. Dado que Nokia ha renunciado por completo a ser una compañía importante en su sector, una que sea capaz de producir su propia plataforma de software en lugar de limitarse a usar la de otros, que Qt permaneciera en sus manos significaba permanecer en un limbo sin objetivo ni propósito existencial bien definido. En teoría, Qt aun tenía sentido para Nokia por su utilidad en Symbian, pero esta venta demuestra que hasta esa plataforma dan por muerta. Los planes de futuro de la compañía ya no preveen mantener a Qt en buen estado.

Digia, en cambio, es una compañía de software, no de hardware, por lo que el bienestar de Qt es muy importante para ellos, y además son conscientes de su potencial. No hay más que leer esta frase del anuncio en la que destacan sus prioridades inmediatas:

Following the acquisition, Digia plans to quickly enable Qt on Android, iOS and Windows 8 platforms.

O, en este otro blog: 

we will begin to explore how to introduce support for other mobile targets, Android and iOS, as fully supported platforms for Qt applications.

Y es que Qt podría utilizarse para construir aplicaciones que funcionen en varias plataformas de teléfonos y tabletas modernos utilizando una base de código casi enteramente común, una alternativa muy apetecible a atarse a una sola plataforma en concreto. Esta fue una ventaja incomprensiblemente despreciada por Nokia, pero que Digia, a quien le interesa que Qt sea portable en el sentido pleno de la palabra (para que muchas empresas contraten sus servicios de consultoría), capta a la perfección.

Aun quedan detalles por solventar. Podrían ocurrir cosas inesperadas, podrían toquetear en las licencias para limitar la flexibilidad de la LGPL introducida por Nokia, que tanto valor resta a sus licencias comerciales (ya han dicho que no lo harán, pero la tentación va a estar ahí). Podrían ofrecer complementos propietarios paralelamente al código abierto, al estilo de MySQL. Veremos. Pero de momento, parece que el futuro de Qt está asegurado (y desde luego seguirá habiendo más programadores y más inversión en este toolkit que en GTK/Glib). Pasemos página a la pesadilla de Nokia, y recordemos que Qt 5 está en desarrollo y debería ver la luz el mes que viene.

Mejorando el volcado de pilas

Una de las mejoras más sencillas y a la vez importantes que se desarrolló en Linux durante la versión 2.5 fue la característica llamada "kksymoops". Hasta entonces, cuando ocurría un "oops" y se hacía un volcado de pila con la lista de funciones que se había ido llamando en cadena hasta llegar al fallo, lo que se imprimía en pantalla no eran el nombre de las funciones, sino su dirección de memoria.

Como las direcciones de memoria varían de un kernel a otro, un volcado de pila con direcciones de memoria era inservible para los desarrolladores. Había que traducir las direcciones a funciones, tarea que hacía el programa ksymoops a partir del archivo System.map del kernel correspondiente, o lo hacía por ti el ya desaparecido demonio klogd si la máquina no se colgaba del todo. Para quienes reportaban bugs esto era un engorro considerable, ya que a menudo tocaba copiar a mano (las cámaras digitales no se habían popularizado) el texto de la pantalla para luego escribirlo en un archivo que ksymoops pudiera leer (algo que era difícil de hacer si no podías arrancar el sistema para ejecutar dicho programa). Para reportar un simple fallo había que molestarse demasiado, y había que explicar a los usuarios novatos vía email como usar el programa ksymoops, etc.

kksymoops, que fue enviado por Ingo Molnar, consistía básicamente en meter el System.map dentro del kernel, qué este podía usar para, en cada oops, traducir direcciones a nombres de funciones. Así, bastaba copiar la lista de funciones para saber qué parte del kernel había causado el problema. El programa ksymoops (y el demonio klogd) se volvieron obsoletos, y reportar fallos en el kernel se simplificó enormemente. El único inconveniente es que hay que emplear unos pocos cientos de KB de RAM en almacenar una tabla de símbolos que rara vez se llega a usar, pero es una minucia y la mayoría de la gente ni tan siquiera es consciente de su existencia.

Esta historieta de tiempos remotos viene a cuento por los volcados de pila de los programas normales de espacio de usuario. Ninguna distro importante compila hoy sus paquetes con la información de depuración activada por defecto, porque el tamaño de los paquetes y las instalaciones aumentaría brutalmente. De modo que el mundo de espacio de usuario está un poco como el kernel en días antiguos, con volcados de pila que son listas de direcciones de memoria poco útiles. Aunque las distros modernas proporcionan paquetes de depuración de instalación opcional pero sencilla, e incluso existen mecanismos de reporte de bugs (abrt) que descargan esos paquetes y crean volcados de pila legibles automáticamente.

Pues bien, todo esto va a cambiar. Un tipo que trabaja para Red Hat ha desarrollado una herramienta que comprime la información de depuración de los ejecutables, lo cual permite reducir su tamaño considerablemente. A pesar de esto sigue siendo un tamaño considerable, pero si además de comprimir se elimina la información de depuración excesiva y se deja tan sólo la necesaria para decodificar nombres de funciones, resulta que una distro puede incluir esta información de depuración básica y comprimida con un coste de espacio aceptable, y de ese modo tener mejores reportes de bug (tanto para la distro como para upstream). Esto será lo que haga Fedora 18, que ya está recompilando todos sus paquetes para compilarlos con esta información.

No hace falta mencionar que esto será utilísimo no sólo para tener mejores volcados de pila, sino para herramientas de análisis del sistema, como por ejemplo perf top.

Abismos

Un desarrollador de Gnome ha hecho un ruido considerable con un post donde se queja de lo que el entiende como un decaimiento de la comunidad de Gnome por una serie de motivos. A riesgo de parecer arrogante, diré que parece que estén empezando a descubrir que la tierra es redonda. Incluso en este blog se habló de lo absurdo que es que en Gnome sigan a lo suyo, haciendo como que Unity es el shell por excelencia de los escritorios basados en Gnome.

Lo que me sorprende es que siga saliendo gente a desmentir todo esto basándose en que a ellos y a otra gente les gusta Gnome 3. No lo pongo en duda, pero que haya gente a la que le gusta Gnome 3 no quita para que haya mucha gente descontenta.

Mucho más me ha sorprendido la afirmación de que GTK sólo tiene a un programador trabajando a tiempo completo, que parece ser él. QT lo ha pasado mal con su compra por Nokia y posterior abandono y conversión en proyecto comunitario, pero sigue teniendo bastante más actividad que GTK (en parte, porque es bastante más que un toolkit gráfico).

Las novedades de Linux 3.5

Ya se ha anunciado la versión 3.5 del kernel Linux. Esta versión incluye soporte de checksums de los metadatos en Ext4, "sondas" de rendimiento en programas de espacio de usuario (uprobes), un mecanismo simple para construir sandboxes filtrando llamadas al sistema, un nuevo algoritmo de gestión de la cola de red diseñado para luchar contra el mal de las redes llamado "bufferbloat", soporte para detener y restaurar conexiones TCP, soporte del RFC 5827 ("TCP early retransmit"), soporte para la "suspensión del sistema oportunista" al estilo de Android, conteo de las estadísticas de fallos de E/S en Btrfs, y la capacidad de usar SCSI sobre Firewire y USB. 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. 

· Checksums en los metadatos de Ext4: Los sistemas de archivo como ZFS y Btrfs han probado que asegurar la integridad del sistema de archivos mediante checksums es algo que merece la pena. Así que Ext4 ha añadido la capacidad de almacenar checksums para todos los metadatos del sistema de archivos (no cubre los datos, ni tiene capacidades de "auto-curación").

Cualquier sistema de archivos Ext4 puede ser actualizado para aprovechar esta nueva característica utilizando el comando "tune2fs -O metadata_csum", o "mkfs -O metadata_csum" cuando se crea. Una vez que esta característica sea activada, los kernels antiguos que no la soportan sólo podrán montar el archivo en modo de sólo lectura.

Respecto al rendimiento, no es notable en la mayoría de casos comunes, sólo en casos orientados exclusivamente al manejo de metadatos, que son muy poco comunes.

· uprobes ("sondas" en espacio de usuario): uprobes es la contraparte de kprobes en espacio de usuario. Este sistema permite colocar "sondas" en cualquier dirección de memoria de un programa, y coleccionar información para encontrar problemas de rendimiento o para hacer simples mediciones. Estas sondas pueden colocarse dinamicamente en cualquier proceso, no se necesita reiniciar el programa ni modificar los binarios. Las sondas normalmente son gestionadas con herramientas de instrumentación como "perf probe", systemtap o LTTng. Un ejemplo de uso de uprobes con perf podría ser medir el uso de las llamadas a malloc() en la libc:

$ perf probe -x /lib64/libc.so.6 malloc 
Added new event:
probe_libc:malloc    (on 0x7eac0)

Se ha colocado una sonda en la dirección de la función malloc. Ahora, vamos a grabar el uso global de malloc en todo el sistema durante un segundo:
 
$ perf record -e probe_libc:malloc -agR sleep 1

Ahora puedes ver los resultados con la interfaz TUI con el comando "$ perf report", o ver una salida en texto plano en la salida estándar con "$ perf report -g flat --stdio". Si no sabes qué función quieres sondear, puedes conseguir una lista de las funciones sondeables en librerías y ejecutables usando el parámetro -F, por ejemplo: "$ perf probe -F -x /lib64/libc.so.6" o "$ perf probe -F -x /bin/zsh". Se pueden utilizar múltiples sondas y mezclaras con kprobes y con los eventos PMU del hardware o los tracepoints del kernel.

El código de uprobes es uno de los parches que más tiempo lleva fuera del kernel. Se originó a partir de SystemTap, y se ha incluido durante años en los kernels de Red Hat y Fedora.

· Filtrado de llamadas al sistema basado en seccomp: seccomp (alias de "secure computing") es un sistema simple para sandboxear procesos que fue añadido en 2.6.12 y que permite que los procesos puedan cambiar a un estado en el que sólo pueden usar un conjunto de llamadas al sistema muy limitado (exit, sigreturn, y read y write para descriptores de archivo ya abiertos). Seccomp ha sido extendido, y ahora permite construir filtros arbitrarios de llamadas al sistema, lo cual permite implementar diferentes tipos de mecanismos de seguridad. Por ejemplo, el navegador Chromium soporta esta característica para ejecutar plugins en una sandbox.

El demonio de inicio de sistema SystemD ha añadido soporte para esta característica. Un archivo de una unidad puede usar SystemCallFilter para especificar una lista de las únicas llamadas al sistema que podrán ser utilizadas, por ejemplo:

[Service] 
ExecStart=/bin/echo "I am in a sandbox"
SystemCallFilter=brk mmap access open fstat close read fstat mprotect arch_prctl munmap write

· Lucha contra el bufferbloat: gestion de cola CoDel: CoDel (alias de "controlled delay") es un algoritmo de gestión de cola de red que ha sido diseñado para luchar contra los problemas de exceso de buffering a lo largo de toda una ruta de red, problemas conocidos como "bufferbloat". De acuerdo con Jim Gettys, que fue quien acuñó ese término, "este trabajo es la culminación de tres intentos para resolver los problemas de los algoritmos de gestión de colas durante los últimos 14 años".

· Reparación de conexiones TCP: Como parte de los esfuerzos para implementar el checkpointing/restauración de procesos, Linux añade soporte para parar una conexión TCP y reiniciarla en otro host. Las implementaciones de virtualización ligera de contenedores usan esto para migrar toda una conexión de un host a otro de forma transparente, sin que lo note la otra parte de la conexión. Esto se consigue poniendo al socket en un modo de "reparación" que permite conseguir la información necesaria para restaurar ese estado en un socket nuevo.

· TCP Early Retransmit (RFC 5827): Esta funcionalidad permite activar la "retransmisión rápida" de paquetes en ciertas condiciones, para reducir el número de ACKs duplicados. En otras palabras, las conexiones se recuperan de paquetes perdidos antes, lo cual mejora la latencia.

· Suspensión oportunista del sistema al estilo Android: El problema más controvertido en la inclusión de código de Android en Linux es la funcionalidad llamada "suspend blockers" o "wakelocks". Son parte de una aproximación a la gestión de energía consistente en suspender el sistema lo más posible. El estado natural del sistema es la suspensión, utilizando energía sólo para refrescar la memoria y para poder volver a despertar de nuevo. El sistema sólo se activa de verdad cuando tiene trabajo que hacer, y en cuanto termina, vuelve a suspenderse.

Esta es una buena idea, pero a los desarrolladores del kernel no les gustó la implementación de Android (se puede encontrar un análisis técnico del problema aquí). Ha habido muchos flames, y poco progreso, lo cual es un gran problema porque los drivers de Android usan las APIs de los "suspend blockers", y la ausencia de dichas APIs hacía imposible incluir el código en Linux. Pero en esta versión, el kernel incorpora una funcionalidad similar llamada "autosleep y wake locks". Se espera que pueda servir a Android y que la inclusión de drivers de él se acelere.

· Estadísticas de fallos de E/S en Btrfs y mejoras de latencia: Se ha añadido soporte para la recolección de estadísticas de fallos de E/S en Btrfs para cada unidad. El comando de Btrfs para recabar esa información, que será incluido en futuras versiones de btrfs-progs, es "btrfs device stats".

Esta versión de Btrfs también incluye cambios que hacen que Btrfs sea mucho más amigable con el reclamado de memoria, y reduce bastante las latencias para E/S síncrono.

· SCSI sobre Firewire y USB: Esta versión incluye un driver que permite usar una conexión Firewire como transporte SCSI. Esto permite exponer dispositivos SCSI a otros nodos en el bus Firewire: por ejemplo, discos duros. Es una funcionalidad similar al Target Disk mode de los ordenadores Apple.

Esta versión también incluye un driver usb-gadget que hace lo mismo con USB. El driver soporta dos protocoloes USB: BBB/BOT (Bulk Only Transport) y UAS (USB Attached SCSI).

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

Steam y Mesa

Creo que soy una de las pocas personas del mundo Linux que no se ha emocionado demasiado tras anunciarse que Valve va a portar Steam a Linux. Aparte de algunas excepciones en Flash, los videojuegos no me atraen demasiado. Aunque desde luego es una gran noticia, los juegos son una de las últimas grandes funcionalidades genéricas que fuerza a mucha gente que empieza a usar Linux a rearrancar de vez en cuando Windows.

Sin embargo, saber que la gente de Valve se está reuniendo con programadores de Intel para mejorar aspectos concretos de sus drivers o de Mesa me ha parecido tremendamente importante, quizás porque además de a Steam, beneficiará enormemente al resto del ecosistema.

Y es que Linux sigue teniendo grandes problemas con la calidad de su implementación de OpenGL en Mesa. El estado actual no es nada envidiable:  OpenGL 3.0 está, por fin, soportado en los drivers más importantes, pero se ha tardado una barbaridad. Para la 3.1 aun tienen que implementar el soporte de GSGL 1.40. De las versiones 4.x, prácticamente no se soporta nada. Bien es cierto que a Valve no le interesan tanto las últimas versiones, sino el soporte de calidad de las versiones más extendidas (la versión de "Left 4 Dead 2" para OS X usa OpenGL 3, es más, OS X tampoco soporta la versión 4), pero es que la calidad de la implementación de OpenGL 3 en los drivers abiertos, particularmente los Intel y AMD, también deja que desear, a pesar de que 3.0 es un estándar de hace cuatro años y a estas alturas la implementación debería estar bien madura.

¿Por qué Linux no tiene una implementación OpenGL de más calidad? Parte del problema está en la carencia de un ecosistema de juegos saludable, que deja a los programadores gráficos en minoría. Ante los problemas de calidad de Mesa suelen optar por atajar los problemas por la vía de las listas negras de hardware o directamente no utilizar las funciones avanzadas que causan problemas y conformarse con menos (véase: compositores de escritorio), o ignorar el hardware mal soportado, o directamente no soportar Linux. Los problemas se evitan en lugar de enfrentarse, los desarrolladores de drivers no tienen presiones para resolverlos, y todo el mundo se adapta y se siente más o menos cómodo dentro de esta mediocridad.

Lo bueno de la llegada de Steam es que se centran en algo muy concreto, en "Left 4 Dead 2", es decir, tratan de optimizar un caso de uso real, no un mero estándar de papel. Gracias a la colaboración con Intel, los programadores de los controladores tienen acceso al código fuente del juego, ven exactamente lo que ocurre, y pueden optimizar el driver para lo que realmente importa e implementar las cosas que verdaderamente son necesarias. Dado que la versión de Linux de Steam va a tener popularidad, la demanda de buen rendimiento para Left 4 Dead 2 se va a convertir en la prioridad principal para todos los desarrolladores de Mesa y de todos los drivers. Tal vez esto sea lo que Linux necesita para tener, por fin, buen rendimiento gráfico. Y claro, esto beneficiará a los compositores de escritorio y a toolkits como QT/QML (que es lo que a mi me interesa).

¿Meego está muerto, o está muy vivo?

Me ha sorprendido encontrarme hoy con está noticia sobre una nueva empresa que tiene el propósito declarado de fabricar teléfonos basados en derivados de Meego. Lo que hace relevante a esta empresa es que al parecer está formada por algún ex trabajador de Nokia que trabajó en productos Meego. En concreto, su fundador fue en Nokia el "Principal Engineer" de productos Meego desde 2006 hasta hace poco.

A estas alturas, hay que dejar claro que no hay ninguna esperanza para Meego -o para cualquier otro aspirante- como competidor de Android o iOS: la guerra fría de patentes de software garantiza por si sola que ningún pequeño jugador pueda entrar a competir. Sin embargo, eso no excluye la viabilidad de ciertos nichos. Creo que el monopolio de pocas empresas relevantes de software (Microsoft y un raquítico Apple en los 90) es una anomalía histórica de un sector muy nuevo con barreras de entrada -implementar un SO completo- enorme, pero el software libre ha bajado la barrera, y eso debería permitir la viabilidad de nichos.

Ahora bien, tampoco hay que precipitarse. Esta nueva compañía -Jolla- por no tener no tiene ni página web, sólo un twitter y un Linkedin. Le queda mucho para dejar de ser vaporware, pero el hecho de estar formado por gente que creó Meego le da más credibilidad: no se trata de alguien advenedizo con ilusiones de grandeza, sino alguien con un producto terminado en su currículum.

Pero lo que me llama la atención de todo esto es que a pesar de que el Meego oficial es un proyecto muerto y bien muerto tras haber sido abandonado por Intel y por Nokia, no está desapareciendo con el silencio que se le supone a los cadáveres. Al contrario, este muerto hace bastante ruido. Está Tizen, que aunque sigue sin oler bien, Samsung ha anunciado recientemente -por fin- un futuro teléfono basado en él. Está el proyecto Mer, que es una especie de Tizen pero gestionado abiertamente por la comunidad -es el que utilizará Jolla- y que ha sido capaz de crear builds de Mer para varios dispositivos. Está Vivaldi, la tableta basada en Mer creada por desarrolladores de KDE. Está cloudberrytec, una compañía creada también hace poco por ex desarrolladores de Meego, que se han marchado de Nokia tras publicar la última actualización del N9. Y está Jolla.

En definitiva, existe una serie de proyectos o empresas empeñadas en hacer todo lo posible por crear un sistema operativo móvil derivado de Meego. Individualmente, esas iniciativas nunca me parecieron esperanzadoras -algunas siguen sin parecermelo-; por si sola una empresa de ex trabajadores de Meego empeñada en resucitar un producto muerto y con escasas probabilidades de éxito parece algo más nostálgico que esperanzador. Pero la variedad de empresas comprometidas con los mismos "ideales técnicos", por llamarlos de algún modo, es una confirmación de que el futuro de los descendientes de Meego, haber, tiene que haber. Tanto empeño empleado en lo mismo al final ha de dar algún fruto.

Steve Ballmer y el futuro de su pequeño imperio

Cuando Microsoft dijo que se jugaba el futuro de la compañía a la carta de Internet, mucho creíamos que eran sinceros. Cuando empezó a enfrentarse a Google en serio, mucho creíamos que era verdaderamente en serio, y que aunque Google llevaba las de ganar, veríamos una pelea encarnizada. Veía como inevitable la aparición de algún servicio web revolucionario de mano de Redmond, algo que les metiera en la competición. La realidad en estos últimos años ha sido que no sólo no han cumplido mis expectativas, sino que han logrado perder las fortalezas que tenían anteriormente. Las excepciones están contadas.

Habría que empezar señalando que Microsoft era la compañía mejor situada para ser dueña y señora de Internet. Hubo un tiempo en el que Messenger era (con el perdón de AIM) poderoso; una de las preguntas inevitables que hacía todo nuevo usuarios de Linux era dónde encontrar algo comparable al Messenger. En cuando a correo web, Hotmail tenía una posición muy sólida. Ambos atributos eran útiles para intentar competir con Facebook, Twitter u otros servicios, de haberlo intentado en serio; algo que no hicieron.

El cliente de Messenger fue dejado de lado y ha acabado perdiendo su base de usuarios y convirtiéndose en un chiste. A pesar de estar gastándose cientos de millones en su "estrategia online", pensaron que Messenger debía dar dinero y en lugar de mejorarlo se centraron en meterle publicidad por todos los rincones, para luego intentar convertirlo, ya tarde, en un engendro de pseudo red social. A día de hoy sigue existiendo esa pseudo red en el cliente (horroroso) y en live.com, tan pobre que debería producir sonrojo. Respecto a Hotmail, parece ser que Gmail ya le ha pasado en número de usuarios, lo cual no es sorprendente. Soapbox, un competidor de Youtube, acabó siendo cerrando. Microsoft Spaces, su servicio de blogging, fue cerrado y se dio a los usuarios opción de migrar a wordpress. Respecto a la versión web de Office que hay en Skydrive, no tiene frente a Google Docs que tiene Office en el escritorio contra el resto de suites ofimáticas. ¿Este es el panorama de una compañía que quiere ser fuerte en la web? Y mejor no recordar ese asuntillo llamado Silverlight...

Bing merece mención especial. Durante un tiempo hizo mucho ruido, y las noticias contaban la mucha cuota de uso que estaba ganando en Estados Unidos. Incluso hoy en día siguen viéndose noticias sobre esas subidas. Sin embargo, ¿en qué se queda el balance de tres años de vida de Bing? Cuando se anunció, Google tenía un 64% de cuota de mercado global. Hoy, tiene un 65%. Ha parado el ascenso de Google, que hasta podría parecer meritorio si no fuese porque Bing es el motor de búsqueda por defecto del navegador web por defecto del sistema operativo utilizado por defecto en prácticamente todos los PCs del mundo. Mucho bombo y pandereta, pero mientras que en este tiempo Google ha añadido "universal search" y "instant search", bing no ha cambiado sustancialmente. Y ahora que Chrome es o está cerca de convertirse en el navegador más usado del mundo, y los productos Apple podría venderse más que los PCs windows, las ventajas de ser el buscador-por-defecto se debilitan.

A pesar de que su trayectoria no ha sido precisamente una estela de éxitos,, la división interna que se ocupa de todo esto, "online services" (que clasifiquen lo "online" como un ente aparte dice más de lo que parece), ha devorado capital a espuertas. Concretamente, en sus últimos resultados trimestrales, perdió 479$ millones. Si tenemos en cuenta que los ingresos fueron de 707$ millones, nos salen unos gastos de entre 12 y 13 millones al día, es decir, aproximadamente medio millón a la hora. ¿En qué demonios gastan todo ese dinero? Sin duda, no en proyectos web. Probablemente se haya gastado casi todo en montar Azure, su "nube".

No todo les va mal, claro. Mientras que su posición web es pobre y el imperio Windows es atacado por iOS y Android, sus divisiones "Server and Tools" y "Bussiness" son cada vez más exitosas y se han convertido, de hecho, en las más importantes y las que más dinero generan. Es previsible que, poco a poco, Microsoft se convierta en una empresa dedicada a dar servicios empresariales y gubernamentales. De la web, mejor olvidarse. Ni Windows 8 ni la tableta Surface ni el enésimo envoltorio puesto a .NET harán desaparecer a Google y a Facebook.

¿Que hay debajo de la "Superficie"?

Microsoft ha anunciado la tableta Surface, y el día del anuncio la prensa y toda la gente no dejaba de ponerlo por las nubes, algo comprensible que lo hagan porque parece un buen aparato. Sin embargo, se hace obvio que no es especialmente rompedor. Su gran aportación al mercado es un teclado de 3mm que por su finura puede integrarse en la propia funda, de modo que puede transportarse y utilizarse como portátil en cualquier lado

Es un buen invento, no cabe duda. Pero los chinos ya lo venden por 39€ con gastos de envío gratuitos para el iPad2, que de paso protege contra golpes, y les hay más baratos. Vale, el de Microsoft es mejor, pero quiero decir que tampoco es una algo revolucionario. Pero seamos justos, el hecho de ser una tableta convencional tampoco supone un fracaso. De hecho, el Surface parece una magnífica tableta convencional, capaz de venderse bien. Además, hay mucha gente que no conoce la existencia de los fundateclados opcionales, y debido a ello han seguido utilizando sus portátiles habitualmente. Creo que no me equivoco si pienso que a Apple le hubiera gustado ser el primero en vender algo así.

El asunto interesante es lo que esta tableta implica en el negocio de Microsoft, una compañía que solía dedicarse a hacer software que los fabricantes y ensambladores de hardware preinstalaban. Es obvio que a esa gente no les hace ni puñetera gracia que Microsoft intente competir contra ellos en su propio terreno. Ser "partner" de Microsoft implica algo más que usar sus productos y conseguir descuentos, también incluye colaboración plena a la hora de desarrollar nuevas versiones de Windows. Con el Surface, sin embargo, parece que Microsoft ni tan siquiera les ha avisado de su existencia y presentación.

Esta ocultación plantea unas cuantas incógnitas. Bien podría ser, como sugiere el artículo anteriormente enlazado, una especie de aviso a sus partners para que se pongan las pilas, una forma disimulada de decirles con arrogancia "esto es lo que tenéis que fabricar, merluzos". Es una posibilidad, aunque me parece muy poco probable que Microsoft tenga que recurrir a esto para comunicarse con ellos. Hay otra, que es la que más se ha mencionado, y es que Microsoft se está planteando en serio convertirse en un vendedor de hardware más.

Esta opción es particularmente interesante, porque significaría que eso de una empresa haciendo software y otra integrando hardware se ha acabado, nos estaríamos adentrando en una nueva era en el que las únicas empresas relevantes son las que saben juntar hardware y software. En otras palabras, significaría que el modelo de Apple de integrar hardware y software ha pasado de ser una excepción en la informática de consumo, de la que se hablaba hace no tantos años como una reliquia histórica destinada a desaparecer, a convertirse en el modelo a seguir.

Si esa es la intención de Microsoft, no cabe duda que nos esperan tiempos interesantes en el sector. Un sector donde el protagonista no es el hardware, sino el software y cómo se integra ese software con el hardware, con la nube, con otros equipos con el mismo software, y con las necesidades e intereses de los desarrolladores de aplicaciones. El hardware ha pasado a ser una función residual externalizada a Asia, y precisamente por ser algo residual y fácil de contratar, sólo las empresas con software y programadores capaces de darle vida podrían tener éxito en él. Si queremos un "año del escritorio Linux" antes de irnos a la tumba, quizás deberíamos prestar atención a estas tendencias.

El renacer de XFS

La vida de XFS da para muchas curiosidades. La publicación de su código con licencia GPL y port fue uno de los hitos fundamentales de la historia de Linux, uno de esos cambios cruciales que permitieron a Linux empezar a ser tomado muy en serio. XFS puede considerarse como el mejor sistema de archivos hasta la aparición de ZFS.

Sin embargo, la relación entre XFS y la comunidad linuxera han tenido varios altibajos. Nunca fue capaz de reemplazar a los Ext como sistema de archivos por defecto, tal y como cabría esperar en un principio. Su uso en los instaladores siempre estuvo considerado como algo alternativo, no ya respecto a la familia Ext sino incluso respecto a Reiserfs. A este confinamiento a un papel secundario contribuía mucho, en mi opinión, la falta de apoyo de un comunidad muy importante, la del kernel.

Y es que durante mucho tiempo, SGI intentaba mantener sincronizadas las bases de código de Linux e Irix, lo cual impedía una transición completa y hacía que XFS fuese un "ciudadano incómodo" que no se integraba muy bien con Linux. Estos problemas han sido solucionados poco a poco hasta quedar bien resueltos, pero el otro gran problema era que si bien XFS era muy bueno "con archivos grandes", como se solía decir, no lo era para otras cosas.

En concreto, XFS era verdaderamente malo con cualquier uso extensivo de metadatos. Pero malo, malo. Ext4 puede ser 20-50 veces más rápido en operaciones con metadatos, una descompresión de un .tar que en Ext4 toma 3 ó 4 segundos, en XFS tarda 60, según palabras de los desarrolladores de XFS. Y si bien mucha gente utilizó XFS para su ordenador de escritorio creyendo (erróneamente) que era más rápido, la gente del kernel no se dejaba engañar, ni tampoco los mantenedores de las distribuciones.

Para entender por qué XFS era tan lento, hay que recordar algo que se ha repetido aquí varias veces: al igual que hay navegadores lentos y rápidos para ejecutar el mismo código javascript, en un sistema de archivos lo fundamental es su implementación, mucho más que su formato de disco. El código de Ext3 y 4 tienen una optimización que permite unir varias transacciones que estén en memoria antes de ser escritas a disco en una sola, de modo que son registradas en el journal y posteriormente al disco simultáneamente. Al descomprimir un .tar se crean miles de archivos, cada uno de los cuales es internamente una transacción, y Ext4 las unifica de modo que se convierte en una sola.

XFS no tenía esa clase de optimizaciones, pero finalmente la han implementado. Y además, unas cuantas mejoras más de escalabilidad y rendimiento, todo ello sin haber modificado el formato del disco (que sigue siendo excelente). El resultado de todo este trabajo sitúa a XFS en un lugar muy interesante: un sistema de archivos de mejor diseño que Ext4, un código de igual o mejor calidad, un rendimiento igual o superior en cualquier situación (muy superior, cuando hablamos de muchos discos y CPUs), igual de bien integrado con el resto del kernel que Ext4, y tan bien mantenido como Ext4 (Red Hat ha contratado a varios desarrolladores históricos de XFS)...la conclusión obvia parece ser: ¿para qué seguir usando Ext4?

Esa es la atrevida propuesta que hace un desarrollador de XFS en este vídeo (que es la motivación de este post), y que viene a resumirse en que el futuro de los sistemas de archivos en Linux será usar Btrfs por defecto, y XFS para quien necesite rendimiento y escalabilidad extra. Esta última distinción, que indica una discapacidad de Btrfs, puede sorprender, pero tiene algo de cierto: XFS no duplica los metadatos por defecto, ni los comprime, ni provoca fragmentación masivama debido a copy-on-write, lo cual le permite ser más escalable en situaciones extremas, y por tanto le permite tener un futuro sólido en grandes servidores, a pesar de no ser un sistema de archivos "de última generación". Además, están planeando un cambio de formato de disco en el cual piensan incluir checksums de metadatos, añadir información extra para facilitar la tarea del fsck, e implementar la capacidad de hacer un "scrubbing" online; es decir, intentarán implementar algunas de las ventajas de Btrfs, todo ello con vistas a seguir siendo un buen sistema de archivos en el futuro, algo que Ext4 no podrá hacer con facilidad.

Mi veredicto personal es que probablemente tiene razón, y que a medida que Btrfs reemplace a Ext4 como sistema de archivos por defecto, XFS lo acabará superando también como sistema de archivos alternativo.