ARM v8

Una de las consecuencias más importantes, pero menos mencionadas, de la desaparición de MeeGo es que a Intel le ha salido por la culata su plan de luchar contra ARM en cacharros portables, plan en el que Nokia ocupaba, sin ninguna duda, un lugar importante. Tanto como el que ocupa para Microsoft hoy.

La batalla ARM vs x86 acaba de calentarse de nuevo tras la aparición de ARM v8. Si ya de por si ARM estaba empezando a hacerse un pequeño hueco en el universo de los servidores (resulta que la misma eficiencia que les da dominio en dispositivos móviles puede ayudar a reducir la factura de la electricidad en datacenters), el hecho de que hayan (¡por fin!) diseñado una arquitectura con soporte de 64 bits se lo va a poner más fácil. Es para destacar que la primera plataforma basada en ARMv8 sea una plataforma para servidores, y no para teléfonos móviles o routers.

(Por cierto, adivinen qué famoso sistema operativo propietario para servidores no tiene soporte de ARM ni piensa añadirlo)

Han hecho un documento con los detalles de la nueva arquitectura que merece la pena comentar. Recordemos que cuando AMD creó x86-64 el número de registros de propósito general aumentó de los ridículos 8...¡a 16! (los procesador RISC de los 90 ya solían tener 32). ARM sigue sin ser x86, y eso quiere decir que son algo menos chapuceros, así que ya que han creado un nuevo conjunto de instrucciones, han decidido incrementar el número de registros de propósito general a 31 (antes tenía un número parecido pero sólo se podían acceder a 15 al mismo tiempo). Respecto a SIMD, tendrá 32 registros de 128 bits (SSE4 sólo tiene 16; aunque todo sea dicho, en AVX se han ampliado a 256 bits).

Y no es que tener más registros les haga más veloces, pero un servidor recuerda haber leído algún documento que tras un análisis concluía que en en plataformas x86-32, con sus ridículos 8 registros de propósito general, el código se pasaba un 20% del tiempo reubicando datos de registros a un lado y a otro para hacer sitio. Seguramente ARM no llegue a utilizar los 31 registros la mayor parte del tiempo, pero es una de esas cosas que nunca está de más tener, por si a algún compilador le da por sentirse inspirado.

En fin, habrá que ver como evoluciona ARM, a ver si de verdad consigue arrodillar Intel, o es Intel el que consigue expandir x86 a otro sector.

Nokia y WP7

Con tanto proselitismo de MeeGo y tanta crítica a Nokia, podría parecer que creo ciegamente que se van a hundir irremediablemente. Pero ahora que ya ha salido a la venta su primer teléfono con WP7, me gustaría aclarar con una nota rápida que personalmente creo que se venderá como rosquillas.

Sin embargo, de venderse bien a rivalizar con Android hay una gran diferencia. Y no por falta calidad (en realidad, poco a poco Microsoft está convirtiéndo WP7 en un SO atractivo), sino por algo parecido a lo que Apple sufría (y sigue sufriendo) en el mercado de ordenadores escritorio: Por muy superior que fuera OS X frente a Microsoft (recordemos los días oscuros de Windows Vista, cuando se vieron forzados a reiniciar el desarrollo del SO a mitad del proyecto), Windows simplemente era el estándar y no había (ni hay) sitio para otro SO de escritorio.

En los smartphones Android es el estándar, y por mucho que mejore Windows Phone eso no va a cambiar. Y Android tampoco es, ni mucho menos, Windows. Aun.

Las novedades de Linux 3.1

Ya se ha anunciado la disponibilidad de la versión 3.1 del kernel Linux. Novedades: soporte para el procesador de software libre OpenRISC, mejor rendimiento del proceso de escritura de memoria a disco, mayor velocidad del asignador de memoria "slab", una nueva implementación de iSCSI, soporte para chips NFD "Near-Field Communication" para pagos mediante teléfonos, gestión de bloques estropeados en la capa de RAID por software, barreras activadas por defecto en Ext3, un controlador para el Wii Remote, una herramienta "cpupowerutils" para la gestión de energía, y muchos otros drivers y pequeños cambios. La lista completa de cambios, en inglés, puede encontrarse aquí, como siempre.

· Nueva arquitectura: OpenRISC: OpenRISC es una CPU de "código abierto" que es parte del proyecto OpenCores. El objetivo es crear una plataforma de computación completamente libre y disponible bajo licencia (L)GPL, así como un conjunto completo de herramientas de desarrollo, librerías, soporte de sistemas operativos y aplicaciones igualmente libres. La implementación incluida en esta versión es la familia de procesadores de 32 bits OpenRISC 1000 (or1k). Hay más detalles sobre este procesador en esta página.

· Regulación dinámica del writeback: "Writeback" es el proceso de escribir datos de la RAM al disco, y regular en este contexto significa bloquear procesos temporalmente para evitar que creen nuevos datos que escribir, hasta que los datos actuales hayan sido escritos en el disco. El código de writeback era subóptimo, porque en ciertas situaciones forzaba a varios procesos a escribir sus datos al disco simultáneamente, lo cual creaba patrones de escritura aleatoria que no son buenos para el rendimiento. El nuevo código evita esas situaciones, lo cual ayuda a crear patrones de escritura más lineales. El nuevo código también intenta detectar el ancho de banda del disco, un dato que es utilizado para mejorar las heurísticas que deciden qué procesos deben ser bloqueados. El acoplamiento entre sistemas de archivo y el sistema de writeback también ha sido mejorado, y se ha solucionado un problema de escalabilidad.

· Barreras activadas por defecto en Ext3: Los discos duros tienen un buffer de memoria donde se almacenan las instrucciones y datos enviados por el SO. El software interno de los discos modernos cambia el orden de las instrucciones para mejorar el rendimiento, lo cual significa que las instrucciones pueden o no pueden escribirse al disco en el mismo orden en el que el SO las envió. Esto rompe las reglas que el SO necesita para implementar cosas como journaling o COW, de manera que los discos proporcionan una instrucción "vaciado de cache" que no puede ser reordenada y que ordena escribir el buffer a disco. En el mundo de Linux, cuando un sistema de archivos envía esa instrucción, se le llama "barrera". Sistemas de archivos como Ext4, XFS o Btrfs activan el uso de barreras por defecto; Ext3 las soporta pero hasta esta versión no han sido activadas por defecto: las garantías de seguridad de los datos son más altas, pero el impacto en el rendimiento de Ext3 es muy notorio, y se consideró que era una regresión de rendimiento inaceptable para muchos usuarios. Sin embargo, distribuciones como Red Hat activan el uso de barreras en Ext3 desde hace mucho tiempo, y ahora el valor por defecto para Linux también ha sido cambiado.


En otras palabras: Si usas Ext3 y notas una regresión en el rendimiento con esta nueva versión, intenta desactivar las barreras (opción de montaje "barriers=0").

· Soporte de chips NFC (Near-Field Communication): Los chips Near-field communication permiten comunicación inalámbrica simple entre dos dispositivos situados a unos pocos centímetros de distancia. Fueron coinventados por NXP Semiconductors y Sony en 2002, y pueden encontrarse en varios teléfonos ya disponibles en el mercado, y muchos otros están planeando añadir soporte.

Se espera que los chips NFC se conviertan en el sistema de pago por teléfono más utilizado en EEUU en los próximos años: los compradores que tienen la información de su tarjeta de crédito almacenada en sus teléfonos NFC pueden pagar pasando sus teléfonos cerca del lector, en lugar de utilizar la tarjeta de crédito. Un teléfono con NFC podría servir como DNI o tarjeta de identificación. Podría pasarse el teléfono cerca de un chip NFC para conseguir información en un museo, o en una tienda. También puede utilizarse para compartir vídeos, canciones, o fotos.

Esta versión de Linux añade un subsistema NFC y la familia de sockets NFC.

· Mejoras de rendimiento en el asignador de memoria slab: En esta versión, el asignador de memoria slab utilizado por defecto ("slub") utilizará operaciones sin bloqueos en ciertas rutas en las arquitecturas que soporten la instrucción cmpxchg. En particular, ha mejorado considerablemente el rendimiento de la parte de slub que se encarga de liberar memoria de los slabs

· Mejoras de escalabilidad en el VFS: Al igual que en versiones anteriores, hay una nueva ronda de mejoras de escalabilidad:

 · El contador inode_stat.nr_unused se ha convertido a variables per-cpu.

 · La lista global LRU de inodos no usados se ha convertido a una lista por cada superbloque.
 · Como consecuencia del punto anterior, se elimina el semáforo iprune_sem.
 · Se elimina el semáforo i_alloc_sem y se reemplaza su funcionalidad con un sistema más simple.
 · Escalabilidad en el montaje de sistemas de archivos que no tienen punto de montaje (sockfs y pipefs)
 · Evitar tomar el cerrojo inode_hash_locken tuberías y sockets

· Nueva implementación iSCSI: La anterior implementación iSCSI del kernel, SCST, queda obsoleta ante la inclusión del "target" SCSI de Linux-iSCSI.org, una implementación de iSCSI (RFC-3720). Más información aquí.

· cpupowerutils: cpupowerutils es un nuevo proyecto derivado de cpufrequtils y extendido con otras características, como una herramienta de monitorización de hardware. ¿Por qué una nueva herramienta? Así lo justifica el anuncio:

"El tuneado en las CPUs del consumo de energía vs rendimiento ya no consiste en cambiar de frecuencia. Características como los estados de sueño profundo, el cambio de frecuencia tradicional, y las frecuencias "turbo" ocultas dependen íntimamente las unas de las otras. Las dos primeras sólo existen en arquitecturas como PPC, Itanium y ARM, la otra sólo en x86. En x86 la APU (CPU+GPU) sólo funcionará del modo más eficiente si ambos tienen una gestión energética adecuada. Los usuarios y desarrolladores quieren tener una sola herramienta para observar su sistema y monitorizar y depurar los problemas de gestión de energía". cpupowerutils es esa herramienta.

· Raid por Software: gestión de bloques estropeados: La capa MD ("Múltiples Dispositivos", también conocida como "raid por software") tiene en esta versión capacidad de gestionar bloques estropeados: los bloques estropeados se añadirán a una lista, y el sistema intentará no utilizarlos. Esta característica necesitará una versión de mdadm actualizada.

· Personalidad para reportar números de versión 2.6.x: Algunos programas dejaron de funcionar con Linux 3.0. Algunos de ellos son binarios sin fuentes (por ejemplo, programas de gestión de software de cierto vendedor de impresoras). La variable sys.platform en Python también devuelve "linux3" en 3.0, lo cual rompe las cosas que estaban comprobando sys.platform=="linux2". Para solucionar este problema, se ha añadido una personalidad UNAME26 que reporta versiones 2.6.x.

· Soporte de controlador de Wii: Se ha añadido un driver para el Wii Remote.

Estas son las novedades principales de este kernel. Como siempre, pueden encontrar la lista completa, y en inglés, en esta página.

Perdiendo el miedo a Akonadi

Al actualizarme a Fedora 16 Beta he tenido que enfrentarme a uno de los retos que como usuario de Kmail temía: El paso a "Kmail 2", también conocido como "Kmail basado en Akonadi".

Akonadi es uno de los mayores problemas-capricho que mucha gente tiene a día de hoy con KDE. Por problema-capricho hemos de entender no un "problema" en si, sino más bien uno de esos caprichos tecno-estéticos que la gente tiene a veces (yo el primero) con el software: No se trata de que Akonadi les impida usar KDE, sino de que no les gusta, no les da la impresión de que sirva para nada, y consideran que la existencia de una instancia de mysql en un escritorio es un error intolerable que debería ser corregido.

No voy a discutir la razón de ser de Akonadi (porque hace años que tengo un borrador a medio escribir que toca el tema y quiero terminarlo algún día), pero podría simplificarlo en que todos tienen una pequeña parte de razón: si, tener una base de datos en el escritorio es algo recargado, pero también es cierto que poder programar un cliente de correo simple en 10 minutos es síntoma de que hay algo que se está haciendo bien.

En anteriores ocasiones mi experiencia con Akonadi había sido bastante negativa. Entendía la enorme utilidad de lo que querían hacer, pero el resultado final era tan desesperante que uno se lo tomaba como una empresa quijotesca sin futuro: El miedo natural a la idea de guardar todos mis correos y datos de escritorio en una base de datos mysql, unido a los fallos constantes que veía en Akonadi, me hacía huir de todo ello como la peste. Sobre todo, en lo referente a mi sagrado archivo de correos en formato maildir. No entendía porque tenía que renunciar a maildir. Tal vez para un usuario de formato mailbox sea más fácil.

Esto se debía a que no tenía ni puñetera idea. Akonadi no consiste en eso. Los correos no se guardan en mysql, siguen guardándose en formato maildir. ¿Qué demonios hace Akonadi, entonces? Podría decirse que es una especie de "cache": kmail accede a los correos a través de las interfaces de Akonadi, y es Akonadi quien lee el formato maildir y crea cachés (que se guardan en bases de datos mysql) de esas peticiones. La cuentas de correo pasan a ser parte de la configuración de Akonadi, y el proceso de bajar el correo nuevo consiste en que el recurso de akonadi pop3 descarga el correo, actualiza los caches de Akonadi y el recurso maildir sincroniza a Akonadi con mi archivo de correos, añadiendo el correo descargado. Los caches de Akonadi se van creando y destruyendo dinámicamente, pero son sólo eso, caches, pueden borrarse por completo y no pasa nada, Akonadi simplemente los reconstruirá.

El resultado final ha sido es que mi migración a Kmail2/Akonadi ha sido completamente inofensiva y ha desterrado todos mis miedos. Mi único problema fue con la migración, algo que resolví prescindiendo de la herramienta de migración (increíblemente lenta) y creando las cuentas pop3 en Akonadi de cero, y una de maildir que apuntara a mi archivo actual. La primera actualización del caché de Akonadi tardó un montón, pero una vez completada me he olvidado de todo esto. Akonadi es muy sólido, y no he tenido problemas de fiabilidad ningún tipo.

El único problema es la lentitud. Abrir una carpeta no cacheada es demasiado lento, muchas operaciones que consistan en copiar, mover o cambiar el estatus de los mensajes son lentas. A veces, el simple hecho de leer un mensaje muestra un "espere, por favor..." debido a que por alguna razón hay otras operaciones simultaneas (¿las copias de seguridad automáticas que he configurado en Akonadi?) que bloquean a las demás. Creyendo que el problema era que mysql era demasiado pesado cambié el "backend" de Akonadi a sqlite, pensando que la ligereza de sqlite era ideal para Akonadi, pero la realidad es que su rendimiento es peor (mucho peor: mysql existe por algo). No sé hasta que punto influirá el hecho de que utilizo btrfs: el fsync() en btrfs es aun algo lento, y la fragmentación de las bases de datos debido al COW es muy notoria.

Por otra parte, la operación normal de leer correos sin hacer cosas raras es instantánea. Sólo he notado lentitud y problemas al hacer cosas atípicas (copiar muchos correos de una carpeta a otra), y mi archivo de correo maildir está seguro. Está claro que Akonadi y Kmail2 son muy nuevos y tienen que mejorar, pero son perfectamente usables. Y no olvidemos que Akonadi no sólo sirve para correos, también sirve para notas, calendarios, mensajes de IM, etc.

PD: El cambio de apariencia del blog era necesario para poder usar las nuevas plantillas de blogger.

Tizen y Meltemi, dos nuevas plataformas Linux

Supongo que algunos de ustedes andarán preguntándose qué pasa con la evolución de MeeGo en Tizen. Yo también me lo pregunto. La verdad es que todo esto no da ninguna impresión de solidez, y todo apunta a que lo único que se conseguirá será reforzar el dominio de Android. Pero no adelantemos acontecimientos.

Empecemos con las buenas noticias: En el anuncio oficial se habla de que Tizen estará desarrollado por Intel y Samsung. Yo dudo mucho de las intenciones de Intel, al fin y al cabo su interés está en Android, pero lo de Samsung es muy alentador: a diferencia de Intel ellos si ensamblan teléfonos móviles. A falta de la posibilidad de instalar SOs con la libertad con la que se hace en los PCs, un SO para móviles requiere el apoyo de un gran fabricante, y Samsung lo es. Parece ser por tanto que veremos móviles basados en este Tizen.

Este repentino apoyo de Samsung no es, desde luego, casualidad. Se rumorea que Samsung y Google no se llevan bien, y ha firmado un pacto con Microsoft para vender Windows Phone 7 y para poder vender Android tranquilamente. Todas estas guerras de alianzas no tienen ningún sentido, y no tienen ningún sentido porque son producto de algo ilógico como las patentes de software. No es más que una guerra fría por intentar controlar el mercado de los teléfonos móviles con tácticas anticompetitivas, Apple y Microsoft están dispuestos a usar sus patentes para detener la comercialización de productos (Apple) o cobrar suculentas licencias (Microsoft). Ningún fabricante de móviles puede meterse en el mercado seriamente sin ser atacado por ellos, aunque la base legal sea absurda. Tras la compra de Motorola, parecía que Google iba a ser el chico bueno que protegiera a todos de ese peligro, pero por alguna razón Samsung o no se fía o ha optado por otra estrategia.

(Por cierto, quien nos lo hubiera dicho hace años. Gracias al chollo de las licencias de patentes para distribuidores de Android, es decir, gracias a una plataforma basada en Linux, Microsoft se embolsará 444$ millones en 2012).

Lo más chocante (y por chocante quiero decir "deprimente") de Tizen es el aspecto técnico. Uno pensaría que Samsung simplemente renombraría MeeGo a Tizen y se liaría a vender móviles basados en QT lo más pronto posible. Pero en el anuncio se habla de crear una plataforma de desarrollo nueva, algo inexplicable que retrasará la salida de los primeros productos hasta mediados del año que viene. La nueva plataforma estará basada en un engendro basado en HTML5 llamado WAC. WAC es algo que la mayoría de ustedes no conocerá (yo tampoco), pero que está apoyado por 48 compañías de telecomunicaciones y tiene detrás una organización con CEO y todo. Es decir, tiene toda la pinta de ser una carta de los reyes magos por parte de los directivos de las telecos para intentar crear un entorno multiplataforma que haga frente a iPhone/android. Otra manera de describirlo sería "intento desesperado de las operadoras por no perder el control sobre la plataformas de desarrollo". Yo dudo mucho que tenga futuro alguno, pero como en el mundo de la programación casi todo se puede echar a andar a base de sudor, sangre, juramentos, hacks a tutiplen y reescrituras, pues nunca se sabe.

¿Y dónde queda QT en todo esto? Pues se dice que se permitirá, pero vaya a saber usted en qué situación. En realidad no se sabe demasiado aun.

Por si todo esto no fuera ya de por si extraño, resulta que se ha sabido que Nokia, si, Nokia, está preparando un SO basado en Linux para sustituir a Symbian en teléfonos de bajo coste. Después de haberse vendido a Microsoft y haber desechado MeeGo, deben haberse dado cuenta de que Android ya se está comiendo el mercado de bajo coste del tercer mundo. Y he aquí una cosa divertida: resulta que Windows Phone, el SO en el que se van a jugar todo, sólo soporta una plataforma ARM, a diferencia de Linux, que soporta de todo. Mi teoría es que al no poder usar Windows Phone en teléfonos baratos y al estar Symbian al borde de la muerte, se están viendo obligados a recurrir a adaptar Maemo/MeeGo a toda prisa para teléfonos baratos. Pero lo hacen por su cuenta, sin tener relación con Tizen, MeeGo o nada que se le parezca, a pesar de que no hace tanto que teóricamente era el mismo SO. Otro absurdo más en la larga colección de acciones absurdas cometidas en la apresurada carrera por evitar ser aplastados por Android/iPhone.