D'Oh!

La oportunidad de Ubuntu TV

2012-01-22T13:34:00.001+01:00

En su día dejé a Ubuntu por Fedora, pero nunca hice ese cambio porque Ubuntu me pareciera mala distro (a diferencia de cuando dejé Debian), sino porque Fedora me parecía mejor. Con esto quiero decir que sigo considerando a Ubuntu la mejor distro Linux de escritorio en general, y a Canonical la Red Hat del escritorio.

Especialmente importante me parece el último punto, que Canonical sea como Red Hat. Como he defendido otras veces aquí, el éxito de Linux en el escritorio o en cualquier lado no puede basarse sólo en gente que contribuye en su tiempo libre. Es un crítico que existan empresas grandes, rentables y prósperas dispuesta a contratar a jornada completa a unos cuantos programadores, como Red Hat o Suse hicieron en servidores. Solo así es posible ser competitivos.

Y, en ese sentido, Ubuntu TV me parece una gran noticia, aunque técnicamente no esa "escritorio Linux".

Si, es cierto que sólo se ha presentado el software, y que ningún fabricante de televisiones se ha dignado a pasarse por allí para mostrar algún prototipo. También es cierto que Ubuntu TV podría quedarse en fracaso si no aparece ninguno. Y no es menos cierto que Ubuntu carece de lazos con las grandes multinacionales distribuidoras de contenidos (que en realidad es el mayor problema). Ah, y no olvidemos que Ubuntu es un objetivo potencial de los ataques monopolistas de las patentes de software.

Pero Ubuntu TV tiene una ventaja, y es que existe. Las "televisiones inteligentes" no son nuevas, tampoco lo son los tropecientos mil softwares y hardwares para Media Center. Sin embargo, se espera que haya un boom en el campo. Y el mero hecho de existir y estar ahí puede dar a Ubuntu TV la oportunidad de ser utilizado por un fabricante desesperado por no quedarse atrás, o uno que quiera probar varias opciones para saber cuál gusta más a sus clientes.

Cuando la aparición del iPhone hizo que los teléfonos táctiles se convirtieran en el estándar, el mero hecho de "estar ahí" fue fundamentalmente lo que acabó dando a Android el puesto de primer SO para smartphones. De haberse dado Microsoft más maña, hubieran sido ellos los ganadores. No sé hasta qué extremo llegará el tema de las televisiones inteligentes, ni cómo se acabará interactuando con ellas, ni si las distribuidoras de contenidos se han decidido ya a permitir a la gente pagar por contenidos o quieren seguir forzándoles a usar ~~Megaupload~~ descargas ilegales. Pero Ubuntu TV está ahí, y gracias a eso podrá tener una oportunidad.

Incluso si fracasa estrepitosamente y Ubuntu TV desaparece, el mero hecho de haber intentado anticiparse marca una diferencia fundamental con la que ha sido la tradición linuxera en la informática de consumo, que consistía en llegar mal y tarde a las novedades tecnológicas, y lloriquear porque las multinacionales privativas acaparaban todo.

Y si Ubuntu TV tiene algo de éxito, imagínense: podran ganar dinero y reinvertirlo. Quien sabe, incluso podrían hacer algo que contente a los críticos con Unity.

Windows y su nuevo sistema de archivos, ReFS

2012-01-17T22:16:00.003+01:00

Microsoft ha publicado algunos detalles sobre un nuevo sistema de archivos, ReFS, "Resilient filesystem". Resumiendo mucho, se trata de un "ZFS para Windows" (pero hay matices que comentaré en este post que, para cambiar un poco, es sobre una noticia de hoy). Es más, mirando fechas no hay que ser un genio para darse cuenta de que fue desarrollado tras la aparición de ZFS y con el propósito de imitarle.

Lo cual no viene más que a confirmar una vez más el enorme impacto que ha tenido y sigue teniendo ZFS. Si tenemos en cuenta que para desarrollar y estabilizar un sistema de archivos son necesarios unos cuantos años, lo que se ha vivido en los últimos 7 años que han pasado desde que apareció ZFS es en realidad una revolución repentina y violenta en el mundillo: ha obligado a todo el mundo a desechar miles de líneas de código de una de las partes más críticas que hay en un sistema operativo, y reimplementarlo de cero.

ReFS merece, sin embargo, algunos comentarios. Teniendo en cuenta lo poquísimo que se puede comentar sobre un sistema de archivos de Microsoft, de los que nunca se sabe casi nada. Ni tan siquiera existe buena documentación pública sobre NTFS.

· Si leen el blog de Microsoft, verán que se afirma que no es una reescritura completa de NTFS, sino una reescritura de su "motor de almacenamiento". Esta afirmación puede llevar a pensar que se ha reescrito sólo "la parte de NTFS que escribe cosas al disco". Mi opinión es que esta idea se trata de una confusión: La diferenciación conceptual clara entre "VFS" y "sistema de archivo" es una noción muy linuxera. En Linux el VFS implementa, por ejemplo, la gestión del caché, y todos los sistemas de archivos lo reutilizan. En NTFS (o en ZFS) el "sistema de archivos" suele implementar casi todo por su cuenta (nadie soporta tantos sistemas de archivos como Linux, así que no tienen tantos incentivos para generalizar y reusar esas partes). Por eso, lo que Microsoft llama "cambio del motor de almacenamiento", en Linux se llamaría "nuevo sistema de archivos".

· Al igual que Btrfs, parece que han escogido un espacio de direccionamiento de 64 bits, y no de 128 bits, como hizo ZFS. Que, en realidad es lo más lógico. Los 128 bits de ZFS son una exageración que quizás ZFS nunca llegue a necesitar. La verdad es que tampoco es tan importante, tanto 64 como 128 bits son una barbaridad.

· ReFS utiliza, como es de esperar en cualquier derivado de ZFS, técnicas de "copy-on-write" ("allocate-on-write", lo llaman ellos): Cuando se cambia algo, en lugar de escribir sobre los bloques que contienen los datos viejos, lo que se hace es escribir en bloques vacíos. Una vez escritos, las estructuras de datos que apuntaban a los datos viejos se modifican -también, a su vez, usando "copy-on-write"- para que apunten a los nuevos.

· Es curioso, sin embargo, que por defecto, cuando se utilice un sólo disco, ReFS no utilizará copy-on-write en los datos y, aparentemente, tampoco checksums, sólo en los metadatos. Se activarán por defecto sólamente con múltiples discos, en discos únicos habrá que hacerlo manualmente, en el formateo. Es decir, en configuraciones unidisco ReFS será, por defecto, equivalente a Btrfs montado con las opciones "nodatacow" y "nodatasum". Sin embargo, será posible activar ambas características manualmente para archivos y directorios determinados (Btrfs también permite desactivar esas características a nivel de archivo). Para ello, las aplicaciones, o los usuarios, tendrán que marcar un archivo como "integrity stream".

· Como ZFS, ReFS soporta "scrubbing", es decir, un proceso de validación de todos los checksums del sistema de archivos. Sin embargo, las aplicaciones podrán deshabilitar el scrubbing para un archivo determinado, del mismo modo que se desactiva el "integrity stream".

· ReFS utiliza una estructura de árbol, para representar en el disco todos los metadatos. Se utiliza la implementación del árbol lo mismo que un roto que para un descosido: un árbol puede almacenar un listado de directorios, otro puede almacenar la lista de extents de un archivo, y los nodos en los árboles que pueden apuntar a otros árboles.

· Sin embargo, no conocemos detalles de la implementación del B+Tree de ReFS. Btrfs utiliza una estructura de datos creada de un trabajador de IBM, que lo diseñó explícitamente para crear un sistema de archivos tipo ZFS (a quien le gusten las discusiones de estructuras de datos y algoritmos puede echarle un ojo). La verdad, no tengo ni idea de si la implementación de ReFS será mejor, peor, o incluso una copia disimulada. Y nunca lo sabremos, porque Microsoft nunca llegará a este nivel de detalle.

· Aunque parezca sorprendente, ReFS no parece implementar por si mismo ningún tipo de capacidad de replicación de datos o metadatos, ni de gestión de múltiples discos en forma de "pool". Quien lo implementará será "Storage Spaces", un gestor de volúmenes que verá la luz en Windows 8 y que implementará esas funciones tanto para NTFS tradicional como para ReFS.

· Por ello sospecho (aunque no puedo asegurar) que a diferencia de ZFS y Btrfs, que han reescrito de cero su propio gestor de volúmenes, Microsoft ha decidido extender su gestor de volúmenes para implementar nuevas características. No estoy seguro del alcance de esta decisión: en Linux también podrían haberse implementado algunas características de ZFS extendiendo Ext3 y LVM, y Btrfs podría haberse implementado sobre ese LVM mejorado. No se hizo así, pero Microsoft parece haber intentado esa vía.

· Probablemente como consecuencia de lo anterior, y a falta de más detalles, parece ser que ReFS es incapaz de duplicar metadatos dentro de una misma partición, como si hacen ZFS y Btrfs. Es más, no parece que a la hora de duplicar ReFS permitirá diferenciar entre replicación de datos y de metadatos. En una misma partición ReFS detectará corrupciones de metadatos gracias a los checksums, pero si los Storage Spaces no tienen configurados varios discos para mirroring no se podrá acceder a otra copia, y parte del sistema de archivos se volverá inservible (por esa razón ZFS y Btrfs duplican los metadatos incluso en una misma partición).

· Una característica curiosa de ReFS: Si gracias a los checksums se detecta corrupción en alguna parte del disco que no se puede corregir, bien por ausencia de copias, bien por corrupción que se ha expandido a todas las copias, se puede hacer un proceso llamado "salvage" ("salvamento"), que consiste en descartar las partes dañadas. Pongamos, por ejemplo, que el directorio C:/FOO está corrupto, pues el proceso de "salvage" se carga ese directorio dañado a lo bestia.

· Algunas características como enlaces duros no estarán disponibles. Pero no estarán disponibles no porque no les haya dado tiempo a implementarlas, sino por eleccion. La verdad, no entiendo el por qué.

· ReFS sólo estará disponible en Windows 8 Server, y no se podrá instalar Windows sobre él. Teniendo en cuenta que se sabe que Apple está diseñando un nuevo sistema de archivos que seguramente tendrá características de ZFS, añado a mis predicciones para 2012/13 que veremos un OS X con nuevo sistema de archivos y características de ZFS antes de que ReFS llegue a los Windows de escritorio.

FreeBSD 9.0 y el retorno de softupdates

2012-01-14T21:02:00.001+01:00

Ya ha salido FreeBSD 9.0, lo cual quiere decir que es un momento propicio para renovar mi gratuito e injustificado desdén linuxero hacia los BSDs.

Aunque en los foros los usuarios de FreeBSD suelen nombrar a ZFS como una ventaja de usar FreeBSD, y con razón, hay que recordar que desde el punto de vista de los desarrolladores la cosa cambia. La mayoría de ellos son militantes que creen que la licencia BSD es la mejor y sienten desprecio (cuando no odian abiertamente) la GPL. Es más, su plan para FreeBSD 10 es erradicar por completo cualquier línea de código GPL de la base del sistema. Por esta razón, no es sorprendente que no sientan un amor incondicional por ZFS, que está licenciado bajo la CDDL. Por muchas cualidades que tenga, se trata de un sistema de archivos no BSD.

Así que, lejos de adoptar ZFS como sistema de archivos definitivo, siguen mejorando su UFS. Y una de las mejoras más curiosas de 9.0 es una curiosa mezcla de softupdates + journaling.

Softupdates consiste en que toda escritura a disco se ordene previamente en memoria respecto a todas las pendientes, más las que vengan, de modo que siempre se mantenga la coherencia del sistema de archivos sin necesidad de fsck ni journaling. En teoría es una idea sencilla, en la práctica la implementación requiere una complejidad brutal. Se requiere introducir un sistema de mantenimiento de dependencias cuya complejidad no se puede abstraer tras una API, es esa clase de complejidad que se extiende como un vertido de petróleo a toda la implementación del sistema de archivos, requiriendo en cada operación lidiar manualmente con las clases de dependencia, sus estados, operaciones de "roll back" y "roll forward"...todo eso añadido a la complejidad del propio sistema de archivos, que no es poca. Si quieren, puede intentar leer este artículo de LWN sobre el tema, donde una mujer que trabajó en inventar ZFS reconoce su incapacidad para entenderlo por completo.

Y, tras lidiar con toda esta complejidad, resulta que softupdates no es capaz de acabar con todas las incoherencias que puedan ocurrir. Existen una serie de incoherencias benignas que no impiden el uso normal del sistema de archivos (bloques marcados como usados que en realidad están libres), pero requieren un fsck. El fsck se puede ejecutar "de fondo", sin necesidad de esperar a que termine para montar el sistema de archivos, pero el I/O y CPU necesarios para escanear todo el sistema de archivos no se los quita nadie.

Por eso no debe sorprender que al final mucha gente acabara pasando de este sistema y pidiera journaling. Como los BSDs son así, ni tan siquiera para añadir journaling se pusieron de acuerdo, así que FreeBSD añadió una cosa llamada "gjournal" (implementado a nivel de gestor de volúmenes, no del sistema de archivos - no me pregunten por qué) y NetBSD una cosa llamada WAPBL.

Pues bien, en FreeBSD 9.0 han decidido ir más allá. Se trata de un micro-journal que hace journaling de las pocas operaciones cuya coherencia softupdates no era capaz de garantizar. De ese modo, en pleno 2011, FreeBSD puede tener softupdates sin necesidad de fsck de fondo posterior, todo ello gracias a la implementación del mismo mecanismo que softupdates trataba de evitar. ¡Albricias! Todo esto para un sistema de archivos que no soporta ninguna de las características avanzadas de ZFS, y que no les quita de encima la necesidad de implementar un sistema de archivos de nueva generación con licencia BSD.

La próxima vez que vean un comentario BSDero hablando de lo chapuceros que son en Linux, acuérdense de esto.

Predicciones 2012

2012-01-09T16:21:00.005+01:00

La última vez que me arriesgué a hacer predicciones fue en 2010. Que, por cierto, no fueron todas desencaminadas. A ver qué da de si el 2012:

· La Gente Normal (tm) empezará a usar masivamente tabletas como sustitutos de portátiles y netbooks. "Cuando éramos jóvenes utilizábamos ratones".

·Aunque Android avanzará, el iPad seguirá siendo líder en cuota de mercado de tabletas (para que no digan que no me arriesgo).

·Hablando de Apple, veremos por fin la iTV. No es una predicción muy original, todo el mundo la está haciendo. La "televisión inteligente" se convertirá en el objeto tecnológico de consumo por excelencia a final de año.

· A pesar de las quejas y de los competidores, Ubuntu seguirá progresando como distribución Linux para emigrantes de Windows.

·Una que robo a LWN: las guerras de patentes de software en el mercado de los smartphones empeorarán y se recrudecerán. Todas ellas dirigidas a Android, por descontado.

· Las cifras de ventas de Nokia -no catastróficas, pero tampoco suficientes para mantener a un gigante- obligarán a la compañía a hacer enésimas rondas de despidos, vender patentes, divisiones, la empresa entera...

· Windows Phone cumplirá sus expectativas, tendrá más éxito del que sus dueños le preveían, y de ese modo logrará consolidarse en un glorioso y merecido tercer puesto en cuota de mercado de sistemas operativos para smartphones.

· Windows 8 verá la luz, pero a nadie le importará gran cosa.

· Steve Ballmer dejará Microsoft.

. Mandriva conseguirá sobrevivir la quiebra.

· Firefox conseguirá frenar su deterioro. Las últimas versiones son buenas y no parece que vayan a dejar de pisar el acelerador.

· Google integrará Google+ en prácticamente todos los rincones de sus servicios.

· Youtube arreglará de una vez por todas el patético e intolerable fallo que supone el mostrar en la lista de sugerencias vídeos cuya valoración de los usuarios es clamorosamente negativa.

· Youtube se convertirá en alternativa seria a Netflix.

· Youtube + Chrome usará reproductor HTML5 por defecto.

· Y por último: Nacerá alguna distro Linux (no Android) orientada exclusivamente a dispositivos táctiles.

Las novedades de Linux 3.2

2012-01-05T02:12:00.000+01:00

Ya se ha anunciado la disponibilidad de la versión 3.2 del kernel Linux. Novedades: Soporte para tamaños de bloque de Ext4 mayores que 4KB y hasta 1MB. Btrfs realiza el proceso de scrubbing más rápido, hace copias de seguridad automáticas de metadatos críticos y añade capacidad de inspeccionar manualmente el sistema de archivos. El gestor de procesos ha añadido soporte para poner límites máximos al tiempo de CPU que pueden usar los progresos. La respuesta del escritorio en presencia de fuertes escrituras de disco ha mejorad. TCP incluye un algoritmo que mejora la recuperación de las conexiones tras pérdidas de paquetes. La herramienta de análisis "perf top" ha añadido soporte para inspección en vivo de procesos y librerías y explorar ensamblador con código anotado. El Device Mapper soporta "thin provisioning" de espacio de almacenamiento. Y se ha añadido soporte para una nueva arquitectura, el Hexagon DSP de Qualcomm. También se han incluido drivers nuevos y muchas otras mejoras y pequeños cambios. La lista completa de cambios, en inglés, puede encontrarse aquí, como siempre.

· Ext4: Tamaños de bloque mayores de 4KB y hasta 1MB: El tamaño máximo de un bloque del sistema de archivos siempre ha sido de 4KB en sistemas x86. Pero la capacidad de almacenamiento de los discos modernos es enorme y sigue creciendo a gran velocidad, y a medida que crece la sobrecarga de tener que dividir discos tan grandes en unidades tan pequeñas aumenta. Los bloques pequeños benefician a los usuarios que tienen archivos pequeños, porque el espacio se utilizará con más eficiencia, pero las personas que manejan grandes archivos se beneficiarían de tamaños de bloque más grandes.

Ext4 soporta ahora tamaños de bloque de hasta 1MB, lo cual disminuye considerablemente el tiempo que se tarda en hacer asignaciones de bloques, y se mejora la fragmentación. Estos nuevos tamaños de bloque pueden configurarse en tiempo de creación del sistema de archivos, utilizando la opción -C de mkfs (requiere e2fsprogs 1.42). Esta característica no es compatible hacia atrás con kernels antiguos.

· Btrfs: scrubbing más veloz, copia de seguridad automática de metadatos críticos, mensajes de corrupción detallados, inspección manual de los metadatos:

· Scrubbing más veloz: el proceso de scrubbing -comprobación de todos los checksums del sistema de archivos- es más veloz debido al uso de técnicas de "read-ahead". En un volumen de prueba, la utilización del ancho de banda del disco aumentó de 70% al 90%. En otro volumen, el tiempo para ejecutar una prueba de scrub pasó de 89 segundos a 43.

· Copia de seguridad automática de metadatos críticos: Btrfs almacena en el superbloque del sistema de archivos las raíces de los árboles "B-Tree" de los últimos cuatro commits (debido al diseño COW, varias de esas raíces cambian en cada commit). Se ha añadido una opción de montaje "-o recovery" para permitir que el usuario utilice esas copias de seguridad cuando el sistema de archivos no pueda leer las raíces por algún problema.

· Mensajes de corrupción detallados: Btrfs siempre ha tenido en sus estructuras internas "referencias inversas" que permiten hallar qué archivos o B-trees referencian a un bloque determinado, pero hasta ahora había que "caminar" esas referencias manualmente. En esta versión se ha añadido código, permitiendo como resultado la mejora de los mensajes de error de corrupción. Ahora, en lugar de decir que el bloque xxyyzz es erróneo, imprimirá esto:

btrfs: checksum error at logical 5085110272 on dev /dev/sde, sector 2474832, root 5, inode 32583, offset 0, length 4096, links 1 (path: default/kernel-0/Makefile)
· Inspección manual del sistema de archivos: Como parte de la característica anterior, se ha añadido código que permite la inspección manual del sistema de archivos desde espacio de usuario Para encontrar el archivo que pertenece al extent 5085110272, puedes ejecutar:

btrfs inspect logical 5085110272 /mnt

O, para encontrar el nombre de archivo perteneciente al inodo número 32583:

btrfs inspect inode 32583 /mnt

· Controlador de tiempo de CPU de procesos que permite poner límites máximos de CPU: El gestor de procesos divide la CPU disponible entre cada proceso si hay tiempo libre, porque se supone que todos los procesos desean tanto tiempo de CPU como sea posible. Pero en algunas compañías como Google esta asignación descontrolada de tiempo puede conducir a variaciones de utilización de CPU y latencia inaceptables.

El controlador de tiempo de CPU resuelve este problema permitiendo asignar un límite máximo de tiempo de CPU. El tiempo de CPU permitido para un grupo de procesos es especificado mediante una "cuota" y un "periodo". Durante cada "periodo" (en microsegundos), se permite a un grupo consumir la cantidad de microsegundos indicados en "cuota". Una vez superada la cuota, no se permite a los procesos que vuelvan a ejecutarse hasta el próximo periodo.

· Provisionamiento fraccionario ("thin provisioning") y snapshots recursivos en el Device Mapper: Habitualmente, provisionar espacio de almacenamiento para múltiples usuarios puede ser ineficiente. Por ejemplo, si 10 usuarios necesitan 10 GB cada uno, necesitarás provisionar 100 GB de almacenamiento en total. Esos usuarios, sin embargo, probablemente no utilizarán todo ese espacio. Vamos a suponer que, de media, utilicen sólo el 50% de su espacio asignado: sólo utilizarán 50GB, dejando otros 50GB sin utilizar.

El "thin provisioning" o provisionamiento fraccionario permite asignar a todos los usuarios más espacio del que realmente hay. En el caso anterior, podrías comprar sólo 50 GB de almacenamiento, permitir a cada usuario tener 10 GB de almacenamiento máximo teórico y no tener problemas, porque los 50GB que comprastes son suficientes para atender las demandas reales. Y si los usuarios incrementan la demanda de espacio, puedes añadir más capacidad. Gracias al provisionamiento fraccionario, se puedes optimizar la inversión en almacenamiento y evitar sobre-provisionar.

Linux 3.2 añade soporte experimental para provisionamiento dinámico en la capa de Device Mapper. Los usuarios podrán crear un pool de almacenamiento y crear múltiples volúmenes provisionados fraccionadamente. Otra gran característica incluído en este "DM target" de provisionamiento fraccionario es el soporte para snapshots con recursión de profundidad arbitraria, y que evitan la degradación con la profundidad.

· Mejora de la función de writeback de la VM: "writeback" es el proceso de escribir datos de la RAM al disco. Una parte crítica del proceso de "writeback" es decidir cuántos datos sin escribir puede mantener un proceso en la RAM. En este kernel, los algoritmos para tomar esa decisión han sido reescritos. Como resultado, los movimientos de brazo del disco duro y el uso de CPU se han reducido, los usuarios notarán un comportamiento más suave en cargas que utilizan write() en un loop, y también en NFS, JBOD y dd's concurrentes. La contención de bloqueos y el "cache bouncing" en cargas concurrentes ha mejorado.

· TCP Proportional Rate Reduction: TCP intenta alcanzar el máximo ancho de banda en una conexión incrementando el ratio de transferencia hasta que empieza a perder paquetes. Cuando un paquete se pierde, TCP enlentece la conexión y la aumenta poco a poco de nuevo.

Este sistema funciona bien, pero hay algunos casos en los que se pierden paquetes, se tarda demasiado tiempo en recobrar la máxima velocidad. Google ha desarrollado un algoritmo de recuperación mucho mejor, llamado "Proporcional Rate Reduction", que mejora la latencia y el tiempo de recuperación en esos casos.

· Mejora de la herramienta de análisis "perf top": La herramienta de análisis en vivo "perf top" ha sido reescrita y mejorado. Más allá de las mejoras visuales, también ha adquirido la capacidad de navegar mientas la captura de datos está ocurriendo, y puede hacer zoom a librerías y procesos particulares, así como ver, incluso, el ensamblador con anotaciones de código, todo ello en vivo.

· Cross Memory Attach: "Cross Memory Attach" añade dos llamadas al sistema -process_vm_readv, process_vm_writev-, que permiten leer/escribir de/a el espacio de dirección de otro proceso. La idea detrás de este mecanismo es facilitar la función de los programas MPI.

· Nueva arquitectura: Hexagon: El procesador Hexagon es un procesador DSP de propósito general diseñado para alto rendimiento y bajo consumo. Mezcla el soporte numérico, paralelismo y capacidades de un procesador DSP, con la arquitectura avanzada de los procesadores modernos.

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

¿Cuánto se invierte en Btrfs comparado con Ext4?

2012-01-05T00:30:00.000+01:00

En este PDF está la respuesta, que compara el trabajo de todo un año, medido en Octubre (nota: la segunda columna son "desarrolladores con más de 10 commits"):

Y la respuesta es la que todo aficionado al software libre desearía oír: Se está invirtiendo más trabajo en Btrfs más que en cualquier otro sistema de archivos linuxero. Y es sorprendente comprobar que XFS tiene más actividad que Ext4 (ha tenido un resurgimiento últimamente).

Lo cual no es obstáculo para afirmar que Btrfs agradecería más apoyo, de esos "11 desarrolladores con más de 10 commits en un año" (una medida bastante generosa) seguramente no trabajen a tiempo completo en Btrfs ni la mitad, y no es que falte trabajo por hacer. Pero en ese aspecto, en Linux las cosas siempre han sido así.

El obstáculo de las distribuciones regionales

2011-12-27T23:49:00.003+01:00

En general, aplaudo cuando un gobernante defiende el uso de software libre en las administraciones: al fin y al cabo, todos sabemos a qué bolsillos van los ingresos de Microsoft u Oracle, y a nadie le gusta que un país tenga un déficit tecnológico horroroso. Y cuando se utiliza software libre en las clases de informática de los institutos, mi alegría se torna en éxtasis: ya he defendido aquí que el modelo actual por el que se dan clases de informática pagando licencias de Windows y Office es, sencillamente, una estafa. La educación pública se convierte así (y permítanme la diatriba) en un centro de formación de productos de empresas privadas financiado con dinero público, y del que se benefician, sobre todo, los accionistas de multinacionales extranjeras. Ya que se beneficiarán de que los alumnos sean educados para usar sus productos, como mínimo deberían regalar todas las licencias a los institutos, pero ni eso les exigen los gobernantes.

Dejando al lado este asunto, hay algo que cada vez me huele peor en el tema de las distribuciones regionales. Me refiero a esas distribuciones que tanto abundan en España. Y lo que huele mal es, precisamente, que haya tantas.

Es evidente que con semejante fragmentación, esto no avanza hacia ningún sitio. Hay gente que, por ejemplo, pretende en serio que los vendedores de ordenadores preinstalen Linex, la distribución de Extremadura, una región de poco más de 1 millón de habitantes. Si ya de por si resulta difícil que compañías como Dell lo hagan con Ubuntu para un mercado mundial, imagínense con Linex.

Otro argumento muy común a favor de estas distribuciones es que gracias al software libre se pueden contratar programadores y compañías locales, en lugar de depender de los de la multinacional de turno. Si bien esto es cierto (y es una de las mayores ventajas del software libre), es obvio que la fragmentación juega muy en contra de la estandarización. Ejemplo, pongamos que es usted un programador y crea un magnífico programa que por alguna razón la administración quiere comprar, pues si quiere extenderse a administraciones de más allá de su terruño tendrá que soportar todas distribuciones. Que puede merecer la pena económicamente, pero es un obstáculo más. Otro ejemplo: Trisquel, la distro de Galicia, tiene la particularidad de estar dirigidas por fanáticos del FSF que eliminan todo software que no cumpla las cuatro sagradas reglas de Stallman. Y olvidémonos de soporte comercial para el mercado de usuarios de escritorio.

Existe un espacio donde tal vez las distribuciones regionales tengan sentido, y es en la administración de sistemas de la administración (valga la redundancia). Los gobiernos regionales tienen sistemas informáticos propios lo suficientemente extensos y complejos como para poder beneficiarse de tener todo bajo control, sin embargo, este es un uso a nivel interno que a los ciudadanos no importa.

Más allá de este caso, ¿de verdad necesitan las escuelas de cada región una distribución educativa distinta?

Diría que hemos llegado a un punto en el que las distribuciones regionales, más que un beneficio están suponiendo un obstáculo para el progreso del software libre. En lugar de crear y mantener distribuciones onanistas, las administraciones deberían optar por cosas como debianedu, edubuntu, o directamente Ubuntu, o cosas así. No se trata de eliminar su inversión en software libre, sino de dirigirlo a proyectos más grandes, donde se pueda aunar esfuerzos con muchas otras personas, con muchas otras administraciones. Entre ayuntamientos, provincias, regiones y estados hay en Europa unas 200.000 administraciones, algo en común se podrá tener.

Trapos sucios de Unix: readdir()

2011-12-03T17:10:00.001+01:00

Una de las cosas más curiosas de los sistemas Unix es cómo han ido cambiando su propia imagen a lo largo de los años. Hoy Unix se entiende como sinónimo de fiable, eficiente, buen diseño, profesional, etc; a pesar de que Unix era un sistema operativo muy simplista, con importantes fallos y carencias que tuvieron que arreglarse o añadirse posteriormente, a menudo no de la mejor manera. Un buen ejemplo de ello es la historia de readdir(), una función que devuelve la lista de archivos y/o subdirectorios presentes dentro de un directorio.

Uno de los principios fundamentales de la filosofía Unix es el de "Todo es un archivo", es decir, la unificación de toda clase de I/O sobre un sistema de archivos jerárquico en el que los archivos, además de archivos, pueden representar a dispositivos de hardware. Tal fuerza dogmática tiene este principio que cuando se diseñó Unix se decidió, o se asumió de manera natural, que los directorios también eran archivos normales y corrientes. Así que las primeras versiones de Unix no tenían llamadas al sistema para algo tan común como listar un directorio.

¿Cómo averiguaba entonces un programa, como por ejemplo ls, los contenidos de un directorio? Pues tratándolos literalmente como archivos. Se abría el directorio con fopen() y se leía el contenido con fread(). El contenido de los archivos de tipo directorio era simplemente una lista consecutiva de parejas nombre/número de inodo, cada una representando un archivo y/o subdirectorio. Y el programa tenía que echar un ojo a esas estructuras e interpretarlas él mismo para saber qué había dentro del directorio, no existía ninguna llamada al sistema que lo hiciera por ti.

Por esa razón, la primera función readdir() no fue una llamada al sistema, sino una función implementada dentro de los programas que lo necesitaban. Si no lo creen, pueden verlo ustedes mismos en la función readdir() del ls.c de Unix Version 7, de 1979. Cuando los diferentes sistemas Unix fueron incorporando características que hacían de esta manera de trabajar con directorios un inconveniente, acabaron añadiendo llamadas al sistema (getdents()) que sirvieran de ayuda para implementar readdir(), la cual se acabaría incorporando a la libc.

Como prueba de esta herencia, han quedado ciertos retazos en algunos sistemas Unix (por ejemplo, FreeBSD), en los que el comando cat directorio es un comando válido, que se ejecuta sin errores, e imprime en la pantalla algo que parece "basura" sin formato del tipo de /dev/random pero que, en realidad, es el contenido del directorio, tal y como ocurría en los Unix originales (en Linux esto no ocurre, se ha asumido que los directorios son directorios, y tratar de leer un directorio como archivo devuelve el error EISDIR).

Pero no se acaba aquí esta historia. Que el diseño original de Unix tuviera estos entresijos acabaría teniendo consecuencias que se heredaron con el tiempo, hasta llegar a hoy.

El hecho de que los directorios originales de Unix fueran simples concatenaciones lineales de parejas nombre/númerodeinodo hizo que las interfaces asumieran que el contenido de un directorio sería siempre lineal. De ese modo surgieron APIs como telldir(), la cual obtiene la posición de un elemento dentro del listado de un directorio. Esta posición puede utilizarse en seekdir() para mover un listado a una posición determinada del directorio. Es decir, se trata a un directorio como un archivo en el que un programa puede moverse de un lado a otro sin problemas.

Esto causó un gran problema con el advenimiento de los sistemas de archivos modernos, basados en estructuras de árbol. Las estructuras de árbol utilizadas en sistemas de archivo (B-Tree y similares) tienen como una de sus características fundamentales el rebalanceo para redistribuir los nodos del árbol a medida que se crean o eliminan archivos. Este rebalanceo puede cambiar el orden en el que un determinado elemento aparece en un listado de directorio, es decir, no se garantiza que usar seekdir() en una posición determinada dos veces consecutivas nos lleve al mismo elemento.

¿Que han hecho los sistemas de archivo Unix basados en B-Trees para lidiar con este problema? Esencialmente, tratar de parchear el problema (resolverlo no es posible, siempre habrá que mantener la compatibilidad con la tradición Unix). Por ejemplo, JFS tiene un B-Tree extra exclusivamente dedicado a mantener una doble indexación que permita satisfacer las garantías de readdir() y compañía. Btrfs, un sistema de archivos de última generación, también mantiene una doble indexación, por cada elemento añadido a un directorio se crean dos items: uno ordenado por hash y otro ordenado secuencialmente. Ext3/4 por su parte sólo ordena los elementos por hash, pero trata de mantener la secuencialidad leyendo los contenidos del directorio por el orden de hash.

Estas técnicas suponen, por supuesto, un trabajo y E/S extra que tiene un impacto en el rendimiento. ¡Ah, y por supuesto, la concepción lineal de los directorios implica que listarlos con readdir() y operar con ellos puede tener una complejidad algorítmica lineal! Así que resulta que Unix, culmen del buen diseño de sistemas operativos, implementa los directorios de una forma verdaderamente patética, y nos hacer pagar sus errores con impacto en el rendimiento (hay software que usa diferentes trucos para evitar acumular miles de archivos en un mismo directorio).

La lección de toda esta historia es que por muy genial que sea el diseño de tu software, obsesionarse con abstracciones perfectas e intentar imponerlas bajo la creencia de que su pureza es la única forma decente de hacer las cosas puede llegar a ser un gran error.

Estupidez artificial

2011-11-27T21:37:00.001+01:00

En los últimos meses se han visto un par de cosas muy interesantes hechas con ordenadores que a mi juicio tienen una gran importancia. Me refiero a la victoria del ordenador de IBM "Watson" en un concurso de Jeopardy, y "Siri", el asistente de voz del iPhone.

Y si, sé que, además del tradicional reconocimiento de voz, existen programas como las acciones de voz de Android y aplicaciones análogas. Pero les desafío a encontrar alguien que diga en serio que Siri no está bastante más refinado, basta echar un ojo a los vídeos donde se comparan a ambos. Siri no sólo reconoce lo dicho sino que capta el contexto de las conversaciones y las intenciones con una calidad envidiable, y está perfectamente integrado con el resto del sistema. Para la gente no interesada en la tecnología, poder decir a un teléfono "recuerdame que tengo que comprar leche cuando salga del trabajo" es muy llamativo, y para bien o para mal Apple va a ser considerado por el público como la primera compañía que fue capaz de hacer semejantes operaciones con cierta dignidad y sin instalar ningún extra. Fanboysmo no, gracias.

La relevancia de Watson y Siri es que, en el espacio de unos pocos meses, han mostrado al mundo que comunicarse a los ordenadores mediante voz ha dejado de ser una cosa de ciencia ficción o de programas de reconocimiento de voz, la charla puede ser un medio habitual para comunicarse con ordenadores. Ejemplo, búsqueda. Aunque la afirmación que se ha leído por ahí sobre que Siri es un "google killer" es una clara exageración, no excluye la realidad de que buscar mediante voz -entender lo que se pregunta, no simplemente sintetizar la búsqueda en texto- va a ser algo cada vez más importante para los motores de búsqueda. Wolfram Alpha -utilizado por Siri para responder algunas preguntas- parece cada vez más interesante.

Todo lo dicho en este artículo es obvio y lo habrán leído ya en otros lados. Sin embargo, en este humilde blog he decidido ponerme mi sombrero futurista e intentar ir más allá. Watson usa 2.880 Power7, 16 TB de RAM y 4 TB de almacenamiento. ¿Que ocurrirá el día en el que el progreso del hardware y la mejora y "comoditización" de esta clase de software ponga esa misma capacidad de procesamiento en un puñetero teléfono móvil? Quizás lleguemos a descargarnos toda la literatura médica vigente hasta la fecha y la base de datos de Wikipedia, y podremos obtener diagnósticos médicos preliminares -Watson ya está en ello- o información de cualquier concepto histórico. ¿Por qué no? De hecho, llegaríamos a tener cosas así en la nube antes de que los móviles lleguen a ese punto.

También es interesante plantearse los retos que este tipo de juguetes planteará a los programadores. Tradicionalmente, los programadores se relacionan con sus usuarios mediante interfaces de usuario. Pero visto lo visto, no es ninguna quimera plantearse un mundo en el que los usuarios quieran usar programas hablando.

Lo más curioso de esto es que la sociedad mitificó durante años la "inteligencia artificial". En realidad no necesitamos inteligencia, nos basta con un cierto nivel de estupidez artificial que sea capaz de buscar dentro de bases de datos y entender órdenes simples, algo así ya sobra para causar una revolución social. Piensen en puestos de asistencia al cliente, ciertas clases de funcionarios. ¿Cuánto tardaremos en ver Siris y Watsons por las esquinas?

Glamor, el nuevo Glucose

2011-11-19T00:41:00.000+01:00

En 2006, Zack Russin, trabajador en QT en el área de gráficos, hizo unos parches muy interesantes llamados "Glucose", que consistían en una nueva arquitectura alternativa para X.org en la que todas las operaciones gráficas del servidor (desde las más básicas a las de la extensión Xrender) se realizaban vía OpenGL. Su objetivo era que los drivers de X.org desaparecieran, y fueran sustituidos por una especie de driver único OpenGL. De ese modo todos los flujos de código se unificarían en una sola ruta gráfica, y la hierba verde brillaría bajo los rayos del Sol. Desgraciadamente, Glucose no llegó a ningún lado (al igual que Xgl, con el cual estaba relacionado, y que desapareció para dar paso a AIXGL).

En las últimas semanas se ha oído hablar, vía Phoronix, de Glamor, un proyecto de gente de Intel para hacer algo esencialmente similar a Glucose.

A primera vista, esto podría parecerles un buen paso. Pero eso sería porque no conocen a fondo el maravilloso mundo gráfico linuxero, que a pesar de los grandes cambios logrados en los últimos años sigue en continua batalla consigo mismo:

· Intel está trabajando en una nueva arquitectura de aceleración para su driver optimizada para plataformas SandyBridge y posteriores. De tener éxito, Glamor haría que todo ese trabajo fuera obsoleto.

· Intel no está interesado en Gallium3D. Siguen trabajando con su modelo Mesa de-toda-la-vida porque opinan que reescribir el driver de nuevo daría mucho trabajo.

· Pero hay un driver Gallium3D para chips Intel no oficial, desarrollado por VMWare, Google y otras compañías interesadas en ello.

Con lo cual, el plan de Glamor consistiría, en un principio, en cambiar el driver X.org actual de Intel, ya sea con la arquitectura de aceleración normal o con la nueva optimizada para Sandybridge, por un modelo OpenGL, pero no con un driver Gallium3D, que se supone que es el futuro de Mesa, sino con el tradicional soportado por Intel. O con el de Gallium3D, si a alguna distro le parece más bonito.

Y si lo anterior les resulta complicado, recuerden que las GPUs programables modernas, a pesar de todo su poderío, no siempre son rápidas con operaciones 2D tradicionales, lo cual quiere decir que aunque mover todo el flujo de operaciones gráficas a OpenGL acelerará muchas cosas, habrá operaciones en los que no será tan competitivo, y menos con el modelo de dibujado no-QML + X11/Xrender.

Lo que quiero decir con todo esto es que espero que un día Wayland venga, arrase con todo, y todo rastro de existencias pasadas quede erradicada de la faz de Internet.

Y ahora, syslog

2011-11-18T19:44:00.001+01:00

A Lennart Poettering y Kay Sievers les ha dado por reinventar syslog. El invento se llama "journal", almacena los datos en formato binario y forma parte de systemd.

Aunque parece que no intentará "ocupar" las APIs propias de syslog() (syslog será una fuente de información, pero journal tendrá sus propias APIs), no cabe duda que Lennart acaba de garantizarse una vez más el odio eterno del conservadurismo unixero (¡no almacena la información en texto plano, a la hoguera!)

Canonical se pone serio

2011-11-05T00:06:00.000+01:00

En los últimos tiempos se ha hablado mucho de esta magnífica noticia: Ubuntu quiere estar presente en teléfonos de última generación, tabletas y televisiones inteligentes.

No está nada mal que una de las grandes distros Linux asuma que la sobremesa no lo es todo: el mundo post-PC, como lo llamó Steve Jobs (que pueden criticarle lo que quieran, pero tenía más razón que un santo), es cada vez más real. Hasta los hackers de software libre más renombrados están usando smartphones en los que las distros convencionales tienen un papel casi nulo: ¿por qué tendría que conformarse alguien al mando de una compañía Linux, como Shuttleworth, con Android?

La impasibilidad del mundo linuxero ante las nuevas costumbres tecnológicas ha sido bastante sangrante. Cuando el iPad vio la luz, el comentario generalizado fue predecir su rotundo fracaso, ahora todo el mundo se preocupa de los bloqueos fronterizos de Apple relacionados (por cierto, se están ganando a pulso una imagen pública horrible). Y es triste, porque el software libre tiene muchas ventajas que explotar en un mundo en el que cada persona pueda tener 2 ó 3 dispositivos y no hay nadie en la familia que no los tenga. Me refiero a "integración": eso que al software libre se le da tan mal a pesar de qué, en teoría, debido a la posibilidad de modificar cualquier parte del sistema, debería ser sencillo. A los linuxeros debería sonrojarnos que Microsoft tenga cosas como el nuevo Homegroup de Windows 7 (digno de aplauso, dicho totalmente en serio) o que Apple tenga cosas como AirDrop mientras que la comunicación entre distros Linux es tan...sin comentarios.

Queda por saber con qué fabricante pretende aliarse Shuttleworth y qué nivel de compromiso y cuota de mercado pretende alcanzar. En esto de las tabletas y smartphones, la integración entre hardware y software es un requisito, y estando ya casi todo el pescado vendido a favor de Apple y Android (y Nokia&Microsoft gastando millonadas para ocupar cualquier resquicio restante), resulta poco creíble que ni Ubuntu ni nadie pueda tener posibilidad de éxito notable. Sin embargo, da una pista: "From the industry viewpoint, Google acquisition Of Motorola Mobility has shook up the hardware vendors, so some of them are looking for non-Android alternatives".

Que es una manera de decir: "Estamos trabajando con un fabricante de hardware rebotado por el tema de Motorola, pero de momento no podemos decir quien para que no se enfaden". Es decir, espero que se refiera a eso. Porque si está diseñando un SO para ese tipo de dispositivos sin tener en dónde instalarlo, lo lleva claro. En cualquier caso, seguro que le va mejor que MeeGo/Tizen.

Por cierto, ¿saben qué nueva información hay de Tizen? Nada: la única información disponible sigue siendo el (único) post de blog del anuncio inaugural. Sólo hay una empresa llamada Nomovok montando un summit bastante poco sugerente, y publicando noticias cortas de Tizen. Se dedicaban a ofrecer servicios a empresas de hardware que quisieran usar Meego y ahora pretenden lo mismo con Tizen, por desgracia con aparente poco éxito tras la desbandada de Intel y Nokia. Más allá delo que Nokia haga con el N9, MeeGo parece estar completamente muerto.

ARM v8

2011-10-28T17:41:00.002+02:00

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

2011-10-27T16:02:00.001+02:00

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

2011-10-24T15:55:00.000+02:00

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

2011-10-23T17:39:00.002+02:00

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

2011-10-01T23:01:00.001+02:00

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.

Android en MeeGo

2011-09-22T21:20:00.003+02:00

Está claro que a estas alturas no soy muy optimista sobre el futuro de MeeGo, pero uno no puede dejar de asombrarse ante noticias como esta: una compañía ha añadido a MeeGo la capacidad de ejecutar aplicaciones Android perfectamente integradas con el resto de entorno MeeGo.

Si Nokia había perdido la esperanza de poder tener una plataforma de desarrollo propia, puestos a subirse en el carro de una plataforma ajena podría haber optado por centrarse en MeeGo, añadir a una actualización este juguetito de la noticia, y sus usuarios tendrían tropecientas mil aplicaciones. Y lo más importante, podrían comprar y usarlo hoy mismo, sin necesidad de esperar. Pero en su lugar han optado por Windows Phone, una plataforma de la que el propio Steve Ballmer confiesa que llegar a tener el tercer puesto en cuota de mercado sería algo magnífico.

Ya sé que soy muy pesado con lo de Nokia y MeeGo, pero es que me asombra su capacidad de hundir un imperio en tiempo record. El N9, a pesar de que es una primera versión y de que no va estar disponible en países importantísimos, ha sido alabado por muchos y se ha vendido razonablemente bien en algunos sitios, pero por lo visto Nokia prefiere no vender teléfonos, e incitar a la gente a comprar cosas de la competencia diciéndoles que algún día sacarán algo con Windows Phone; el cual supuestamente va a gustar muchísimo a la gente a pesar de que, hasta hoy, no lo ha hecho.

C++11

2011-09-21T19:01:00.001+02:00

He de admitir que nunca fui un gran fan de C++, pero hay que reconocer que con C++11 se ha puesto bastante interesante. Material sobre la nueva especificación hay a patadas, pero a mi me ha gustado este vídeo titulado "Writing modern C++ code", de alrededor de 1 hora (y si, de Microsoft), que compara los viejos hábitos con la nueva manera de hacer las cosas.

MeeGo, venta o muerte

2011-09-15T16:45:00.004+02:00

Nos guste o no, la noticia de que Intel se ha aliado con Google para hacer que Android funcione perfectamente en su hardware es un acta de defunción para MeeGo. Por mucho que digan que seguirán soportando MeeGo junto a Android, es muy difícil creérselo, tan difícil como creer que a Nokia le importará QT una vez se hayan librado por completo de Symbian. MeeGo era una plataforma que para tener éxito necesitaba un apoyo al 100% de compañías como Nokia e Intel, y la situación actual está años luz de eso. Y recordemos que, al fin y al cabo, a Intel sólo le interesa vender procesadores y ganar su lucha particular con ARM, sea con el software que sea.

Todo esto podría dar la razón a los numerosos rumores sobre la posible "venta" de MeeGo a Samsung o HTC. Y, francamente, ojalá sea así. Es lo mejor que le podía pasar a MeeGo: Ser adquirido por un fabricante de hardware que ponga a la venta, de una puñetera vez, aparatos con MeeGo a cascoporro, que quiera aspirar a ser algo más que un mero distribuidor de Android, y quiera diferenciarse de todos (e imitar a Apple) con su propia plataforma. Aunque me parece más ciencia ficción que realidad, no deja de ser una posibilidad.

Pero cuando se habla, y hablamos, de "vender MeeGo", hay que tener en cuenta que, por ser un proyecto de software libre, está sujeto a muchas más variaciones que una venta normal. Si Samsung y HTC quisieran distinguirse utilizando MeeGo, podrían haberlo hecho hace tiempo, sin comprar nada a Intel. Podría referirse a comprar el copyright del código, las marcas comerciales, el sitio y los desarrolladores, pero por otra parte, cuando Intel dice que va a colaborar con Google para optimizar Android para sus productos, es muy posible que quiera decir "utilizaremos a nuestros expertos en Linux" (e Intel tiene en nómina a una cantidad de gente importante nada despreciable) "para optimizar Android". Es decir, mandar a los actuales desarrolladores de MeeGo a Android.

Nada está claro en esta historia, excepto que no es nada descartable que MeeGo muera, porque no interesa. Por "morir" no me refiero a que se deje de usar, por supuesto (hay pequeños fabricantes y gente aficionada que lo mantendrían vivo), sino a que muera para el esquema de las grandes cosas, y se limite a ser un capricho para un grupo muy reducido de gente.

Más de Google+

2011-09-04T21:55:00.000+02:00

Tras unas semanas usando Google+, tengo la sensación de que la entrada que le dedique se queda muy, muy corta. Así que he aquí una continuación. Por cierto, qué bonito el nuevo Blogger. Ya era hora.

Empezaré haciendo notar que en Google+ existe una actividad notable. Muchos no la perciben porque todo el mundo sigue usando Facebook, y aunque Google+ puede suplirlo, si uno pretende usarlo para contactar con sus amigos sufrirá, mientras no haya una hipotética migración en masa desde FB (que, de ocurrir, tardaría su tiempo), una decepción, al no tener a nadie que agregar, ni nada que hacer. Pero en Google+ se puede "seguir" a gente al estilo twitter, leer sus posts abiertos al público, y comentar en ellos (comentarios de verdad, en forma de hilo), así que la mayor parte de la gente parece dedicarse a ello: es decir, lo usan como una especie de sustituto de twitter/blogger.

En cuanto al modelo de privacidad y sus implicaciones, no dejo de verle ventajas. Dependiendo de con quien lo compartas, un mensaje de Google+ puede ser blog/twitter/notificaciónfacebook/miniforo de personas aficionadas a un tema...o incluso email. Uno de los usos más sorprendentes que me he encontrado es el envío de mensajes privados: se comparte un mensaje con una sola persona (en Google+ no hay "muros", solo mensajes que se comparten con personas), y cada uno va añadiendo comentarios, como una especie de IM asíncrono (había usado los mensajes privados de FB en el pasado, pero ni de lejos eran tan cómodos).

Otra de las cosas que me ha sorprendido es el número notable de hackers de Linux y software libre que se han apuntado...y que lo usan activamente: Linus Torvalds, Ingo Molnar, David Miller (redes), Lennart Poettering (systemd), Theodore Ts'o (ext4). Esto conduce a situaciones curiosas, como ver a Linus Torvalds, con su habitual estilo, opinando sobre el papel de los grupos ultraderechistas en la matanza de Noruega, leer a Ingo Molnar un blog-ladrillo sobre teoría monetaria y Bitcoin, enterarse antes que nadie de la existencia de un backend llvm para sparse, o leer un relato corto de Ricardo Gallir, el tipo de meneame.net.

En resumen, que el futuro de Google+ lo veo brillante: ya hoy, permite cierto tipo interacciones muy curiosas. Aunque sólo sea por comodidad, una red social que es capaz de imitar a otras es bastante interesante, poder escoger el modelo de red social a imitar en cada mensaje con un par de clicks es una "killer feature". Aunque tengo la impresión de que con perspectivas al futuro, Google+ pretende convertirse no tanto en algo específicamente diseñado para matar a FB, sino en un gigantesco generador y agregador de contenidos de todo tipo, especialmente de los servicios de Google: Eso, más que otra cosa, será lo que arrebate los usuarios a FB, me temo.

Ah, y enlace a mi perfil. No es muy útil, casi no hablo públicamente en él y cuando lo hago rara vez es de informática, pero alimenta mi ego.

La nube y la guerra

2011-08-31T00:32:00.011+02:00

Que la progresiva centralización de Internet en grandes centros de datos o "nubes" no trae sólo cosas buenas es algo sabido, sabemos que Google está obligada por las leyes antiterroristas de EEUU a proporcionar a las agencias de inteligencia las peticiones de información que se les requiera, sabemos que puede haber fallos de seguridad -fallos de seguridad que quizás aun no sean públicos- que permitan acceder a datos personales de cualquier persona...sabemos que existen las barreras de seguridad que existen en las nubes se saltan de modos muy variopintos. Pero de momento, al menos que yo sepa, no se han dado casos de ataques militares que tengan como objetivos centros de datos, una posibilidad bastante inquietante.

Las guerras y golpes de estado suelen centrarse en los puntos estratégicos. Una de las cosas que se suelen hacer hoy en día es tomar las sedes de televisiones y radios, el control de la propaganda es importante. ¿Que tienen las nubes de valor estratégico? Es difícil de concretar, porque la cantidad de datos que van acumulando las nubes es cada vez mayor y cada año se inventan cosas nuevas. Pero un mundo donde la utopía de hacer absolutamente todo a través del navegador se haga realidad, la toma de centros de datos bien podría convertirse en un objetivo tan valuable como las mismas televisiones y radios.

Y una vez tomado, saltarse las barreras de seguridad y acceder a todo tipo de información resulta tremendamente fácil. No sé qué barreras de seguridad internas tendrán compañías como Google, pero ya se sabe que ante un acceso físico, salvo de mediar un buen cifrado, todo es posible. Se sabe que Google tiene programas automatizados que leen nuestros datos para generar anuncios personalizados, asi que ha de ser posible sustituir ese programa por otro que busque la información requerida, es especialmente posible si apuntan al que sabe hacerlo con un fusil a la cabeza. ¿Se imaginan la infraestructura de Google empleada para buscar información sobre enemigos?

Si uno quiere pistas para localizar a un fugitivo, por ejemplo, es buena idea consultar la información asociada a perfil, leer sus emails, sus conversaciones, los últimos logins. Si uno quiere tener a mano una lista de personas que podrían conocer a un sujeto determinado, nada tan sencillo como aprovecharse del taggeo automático para localizar a todas las personas que salgan a su lado en cualquier foto (y si alguien tiene desactivado el taggeo automático no importa: se puede activar por fuerza). O simplemente por si sale su escondite en algún momento, y alguien le saca en el fondo de una foto sin querer. Y si un dictador paranoico quiere simplemente saber el nombre de todo sujeto que haya alabado a un partido enemigo, puede conseguirlo fácilmente. Y, por descontado, cualquier video, fotografía o texto desagradable puede eliminarse. Puede modificarse la función de autotagging para intentar reconocer logos del partido opuesto en las fotos. O se puede insertar en cada página web generada un logo del partido afin. En toda acción militar que pretenda controlar a la gente, los centros de datos son un objetivo muy interesante.

Todo esto no importa demasiado hoy, ya que la mayoría de centros de datos parecen estar en países civilizados, muchos de ellos en EEUU, y tomar militarmente un país donde mucha gente tiene un arma en casa no es sencillo, y por otra parte todos hacemos como que no nos enteramos del preocupante número de medidas que permiten allí vigilar al ciudadano con la excusa del terrorismo ya que presuponemos que verdaderamente sólo se usa con esa intención. Pero esto de los servicios web cada vez se extiende más, y poco a poco penetrará hasta en los países más ridículos como Corea del Norte. Y, por otro lado, nadie nos ha garantizado un futuro sin guerras.

Cómo pasar una tarde entretenida

2011-08-16T22:42:00.005+02:00

· Baja un ejecutable dudoso en Windows.
· Pásale el antivirus de Microsoft, actualizado. No detecta nada.
· Ejecuta el programa. ¡El antivirus de Microsoft detecta un nuevo virus!
· Al puñetero virus le da por infectar algún archivo relacionado con la red (parece ser que para redirigir las búsquedas de Google y lanzar popups). El antivirus procede a eliminarlo.
· Durante el proceso de eliminación, que incluye un reinicio, el antivirus parece tocar algo relacionado con ipsec .
· Los logs indican que los servicios básicos de red, empezando por IPsec y los que dependen de él, no arrancan: la conexión wireless se conecta al router pero no hay red, el navegador no funciona. Ya no hay virus, está eliminado, pero el antivirus ha roto algo. Las herramientas de sysinternals no dan pistas sobre el qué.

Tras un par de horas, me doy por vencido: reinstalación. Estoy seguro que hay gente capaz de limpiar esta basura, pero no les envidio.

PD: Por los comentarios del hilo, parece que algún alma despistada parece no darse cuenta que el virus no ha dado mayores problemas -las instrucciones para eliminarlo manualmente no pueden ser más sencillas-, ha sido el antivirus de Microsoft el que ha fastidiado el sistema.

¿Telefonos preparados para el software libre?

2011-08-16T18:07:00.004+02:00

A estas alturas todo el mundo estará enterado del notición bomba de la compra de Motorola Mobility por parte de Google. Como todo el mundo está opinando, yo no voy a ser menos. No me hice un blog para estar callado.

En primer lugar, creo que hay que dejar claro que esta compra es un noticia mala, pésima, para la industria del software. No por si misma, sino por lo que la motiva. Partamos de que, como ha señalado todo el mundo, el objeto de Google es poseer las 17.000 patentes + 7.000 pendientes de Motorola para proteger a Android contra ataques legales (no es sólo que resulte poco creíble que quieran pagar 12.500$ millones para vender hardware, es que lo resaltan ellos en el propio anuncio). Esto significa que Google se ha visto obligada a gastarse 12.500$ millones en actividades absurdas e improductivas como las patentes de software, unos vastísimos recursos monetarios que de otro modo se habrían utilizado en inversión productiva (o en recompensar la innovación con casinos y furcias). El talento de Google y el progreso de la informática hacen posible sobreponerse a estas penalizaciones, pero no es ni mucho menos una situación ideal. Esta industria podría progresar aun más rápido con una regulación adecuada.

Eso si, si aceptamos el juego de las patentes y pasamos por alto lo mucho que apesta, los dos Steve, Jobs y Ballmer, deben estar poco contentos. Ambos tenían montañas de millones con vocación de adquisiciones estratégicas grandiosas como la de Nortel, y ambos han dejado que su principal competidor en teléfonos se compre un magnífico escudo a prueba de patentes.

Pero intentemos ver el lado positivo: A partir de ahora Google fabricará móviles propios, y es muy posible que esto conlleve una mayor apertura en las relaciones entre hardware y software libre. Es cierto que aunque Google tiene una forma muy particular de entender el software libre, y que los fabricantes de teléfonos android tienen a veces sus cosas, las cosas no estan tan mal, pero se puede mejorar. El estado de los drivers libres de hardware Android (por no hablar de su inclusión en Linux) es mejorable, y aquí los futuros teléfonos de Google/Motorola pueden ayudar. Eso facilitaría a otras plataformas libres alternativas no-Android, o a personalizaciones variopintas de Android, producir ROMs con facilidad para estos teléfonos.

Por cierto, que una vez más no entiendo a los mercados. 12.500$ millones es una cifra obscena, dificil de apoquinar hasta para Google, que no van a recuperar a corto plazo y posiblemente ni siquiera a largo, por muchos teléfonos que vendan. Es una compra para beneficiar principalmente a terceros, pero los inversores no parecen estar furiosos, lo cual confirma que la valoración en bolsa de Google es más cuestión de fe que de otra cosa. La verdad, no me extraña que Warren Buffet no quiera invierta ni un dólar en compañías de un sector tan extravagante.

Usar Linux ya no es lo que era

2011-08-04T20:02:00.002+02:00

Mientras leo la lista de cambios a una actualización de la BIOS de una placa base de Intel (si, Intel también fabrica placas base, y no, por desgracia no es la mia) me encuentro con esto:

· Fixed issue where S3 resume fails in Linux

Para quienes conozcan los detalles del infierno de las BIOS, esto es algo así como la gloria celestial. ¡Programadores de BIOS que prueban Linux y corrigen bugs! Si a eso le unimos que los gráficos integrados de los procesadores Sandy Bridge están bien soportados, y que su rendimiento ha mejorado considerablemente respecto a anteriores generaciones (al menos para los que pasamos olímpicamente de los juegos), comprenderán por qué algunos solemos comprar Intel.

Pero si prefieren AMD, resulta que sus gráficos integrados, Fusion, también están muy bien soportados. Y, por si eso fuera poco, soportan y colaboran con Coreboot.

Por otra parte, Linux monopoliza los 500 superordenadores más grandes del planeta, y al mismo tiempo está camino de dominar ampliamente los teléfonos.

Definitivamente, usar Linux ya no es lo que era.