21 de diciembre de 2009

¡ADSL!

Si, hamijos, yo todavía era usuario de módems de 56 KB: es decir, de 5 KB/s. Por fin ha llegado a mi casa el ADSL. Naturalmente, ya había probado el ADSL en otros sitios, y sabía lo que era, pero nunca lo había podido tener en mi ordenador personal.

Usar una línea de 56 KB a día de hoy acaba desarrollándote una serie de manías, o más bien técnicas de supervivencia. Por ejemplo, para conectarte a una red MSN -lo cual tomaba más de medio minuto, a diferencia de las redes Jabber, cuyo login es instantáneo- tenía que paralizar el resto de tráfico de red: Descargas, actualizaciones, cargas de página, etc. Y cuando volvías a reiniciar las descargas, no era raro que te desconectaras automáticamente por dios vaya a saber qué timeout. Para navegar por Internet en general los 56 KB eran suficientes, pero hay que evitar imágenes -pulsando Escape- y flash pesado para que así puedan terminar de cargarse otras. Y mientras se cargaban, tenías que paralizar las descargas si querías verlas en tiempo razonable o si no querías que llegara algún timeout. Todo esto crea una serie de manías y hábitos, arranques y paradas constantes de todo tipo de programas-. Por supuesto, poco, muy poco youtube. Y casi nada de P2P. Y las actualizaciones de las distros podían tardar semanas de ser grandes (entre parada y rearranque de la descarga se perdía mucho tiempo).

El cambio a ADSL, a pesar de llevar solo unas horas, está provocando que redescubra Internet. De repente, puedo escuchar radio por internet, descubrir qué es eso de los podcasts, tener un programa de P2P abierto con el que robar a George Lucas mientras hago cualquier otra cosa, permitir que Kopete se conecte automáticamente sin tener que preocuparme de si hay algo abierto o no. Acostumbrado como está uno a la paciencia que se desarrolla con los 56 KB, el ADSL le excita a uno excesivamente los sentidos. Pero hasta eso lo puede solucionar uno fácilmente visitando Youtube y viendo cualquier video de Serrat, que tiene la virtud de serenar a la gente.

Asi que si son ustedes pacededores de los 56 KB -según Google analytics, 141 visitaron este blog en el último mes- les sugiero que tengan paciencia y confien en el FSM, pero no esperen que siga compartiendo su sufrimiento.

18 de diciembre de 2009

El culebrón MySQL

El asunto de la compra de Sun y el entorpecimiento de la transacción por parte de la Comisión Europea ha dado lugar a una pequeña telenovela que, aunque está a puntito de acabarse, ha dado mucho juego. Los dos últimos capítulos han sido la petición pública de 'Monty', uno de los creadores de MySQL para impedir la adquisición por poner el futuro de la base de datos en duda (aun teniendo en cuenta la posibilidad de forks), y el compromiso posterior anunciado por Oracle de seguir mejorando MySQL (que no contenta al tal Monty, pero muy probablemente contente a la CE).

Yo ya afirme aquí que las reticencias de la CE ante la compra era absurdas, que el hecho de que MySQL sea software libre impide que pueda ser asesinada. Cierto que pueden crear dificultades, pero ¿impedir que MySQL siga existiendo de una u otra forma? Nunca. Sin embargo, eso no impide que esté tan ciego para no comprender los miedos del tal Monty y de la CE.

Oracle es una empresa que en gran medida basa su negocio en vender licencias de su base de datos propietaria. Es obvio que Oracle no va a tener ningún interés en regalar gratis algo que compita con su gallina de los huevos de oro, mientras que la anterior MySQL y Sun si que lo tenían. No esperen que Oracle ponga muchas ganas para matarse a sí misma. Hay empresarios estúpidos que han asesinado empresas debido a su incompetencia, pero Ellison no es de los que se dejan matar, sino de los que matan. De momento, tengan muy en cuenta que todas esas promesas que ha hecho Oracle incluyen al final del texto, como quien no quiere la cosa, que solo son válidos durante cinco años. Ya veríamos que es lo que pasa tras esos cinco años.

Pero es que ni tan siquiera durante ellos me fiaría en absoluto de Oracle, veremos lo que queda de la promesa una vez que la EC de visto bueno y se haya llevado a cabo la transacción y los ojos de los reguladores fijen su vista en otros asuntos. Es muy posible que hagan un gran trabajo con Java y OpenSolaris, pero con MySQL yo no tengo ninguna razón para creer que vayan a permitir que evolucione rápidamente. Mírense en el espejo y pregúntense, ¿que harían ustedes en lugar de Oracle? Reconózcanlo: aprovechar el control del proyecto para dificultar su evolución, con un control mucho mayor del que hubiera tenido si no hubieran comprado Sun. Si no harían eso es que, al igual que a mi, no les queda bien el traje de tiburón empresarial .

Y no me contento con eso de que MySQL y Oracle son dos mundos totalmente diferentes. Aunque ciertamente es un hecho muy popular e indiscutible que como base de datos MySQL está a años luz de Oracle, eso no significa que no pueda haber competencia. Hace nueve años e incluso menos, Linux era -hoy podemos decirlo bien alto ;)- una puñetera mierda, un kernel cutre, lento e inestable, incluso frente a NT, que la gente usaba solo porque era gratis o muy friki. A día de hoy, ha asesinado por la espalda a casi todos los Unix, se codea en la cima con los pocos que quedan (prácticamente solo Solaris y AIX) e incluso a estos los supera ampliamente en ventas y velocidad de evolución. MySQL puede ser cutre hoy, pero evolucionaba (aun evoluciona) rápidamente y puede plantear problemas más que serios a Oracle.

Incluso hoy se los presente. Se dice de que MySQL no quita mercado a Oracle, que su mercado es otro, por ejemplo, las miles y miles de bases de datos de webs simples esparcidas por todo Internet, pero no es cierto. Si todas esas miles y miles bases de datos no están en manos de Oracle no es porque ese no sea "su mercado", sino porque MySQL se lo ha arrebatado antes de que pudiera hacer algo. El tal Monty tambien asegura que hay gente que algunas personas que se han pasado de Oracle a MySQL, y no hay razón para creer que no haya gente con necesidades particulares -en las que las excelencias de Oracle no sean un requisito- que efectivamente lo haya hecho. No olvidemos, sobre todo el factor precio: Si para una aplicación hipotética de una empresa hipotética MySQL es un 30% más lento que trabajando con Oracle, pero el coste de las licencias de Oracle es el doble, la empresa podría decantase por MySQL. La mera existencia de MySQL hace que el mercado fuerce a Oracle a poner precios a la baja en ciertos segmentos. ¿Cuanto dinero pierde Oracle por ofrecer gratuitamente su Express Edition? ¿Para qué existe esa versión, si no es para competir con cosas como MySQL?

Resumiendo: En mi opinión, es necesario un fork de MySQL (como MariaDB, del tal Monty), al margen de lo que Oracle haga o prometa hacer. Es necesaria una versión que se desarrolle en un entorno verdaderamente libre. De hecho, creo que hubiera sido mejor que la CE no hubiera puesto trabas a Oracle, porque hubiera facilitado la creación y prosperidad de ese fork, mientras que con las nuevas condiciones quizás tengamos que esperar cinco años de incertidumbre.

16 de diciembre de 2009

Recomendación: Gráficos QT

Si están interesados en QT -y, aunque no lo estén, si están interesados en el subuniverso gráfico libre-, les recomiendo que se paren a leer este larguísimo pero magnífico post sobre los gráficos de QT.

13 de diciembre de 2009

libdispatch en el kernel

Resulta curioso que a veces una misma idea florezca con diferentes formas al mismo tiempo sin que entre cada aparición haya aparentemente ninguna relación. Digo esto porque en la próxima versión de Linux va a añadirse un curioso sistema con ideas similares a las del sistema Grand Central Dispatch de OS X pero aplicado exclusivamente al kernel, y no parece que haya ninguna relación entre ambos.

En realidad, la idea -llamada workqueues- existe desde hace muchos años. Conceptualmente se trata de algo similar a GCD -lo que viene siendo un pool de threads-: Un subsistema (por darle un nombre) al que diferentes partes del kernel pueden enviar "trabajos" que se completarán posteriormente. Generalmente, los "trabajos" son creados drivers que tras gestionar una interrupción y recibir los datos pertinentes, envían al subsistema de workqueues un puntero de una función y otro de unos datos para que el resto del trabajo, menos urgente que la gestión de la interrupción, se vaya ejecutando según se pueda, mientras que el driver queda libre para recibir nuevas interrupciones. El kernel ejecuta este trabajo desde los threads del kernel events/N (uno para cada CPU). La novedad en esta versión, y lo que hace que recuerde el sistema de GCD, es una óptima gestión en múltiples CPUs.

Y es que cada driver tiene workqueue al que envían múltiples trabajos, y en el sistema actual todos los trabajos de un mismo workqueue se envian a una sola CPU. Eso implica que si un driver produce una gran cantidad de trabajos, el sistema actual lo ejecutará en una sola CPU, mientras que el resto de CPUs podría estar libre y desaprovechándose. La similitud del nuevo sistema que se incluirá en 2.6.23 con GCD es que es capaz de distribuir los trabajos entre múltiples CPUs según se necesite.

(Aunque, siendo escrupulosos, hay que resaltar que las workqueues no son utilizadas solamente por drivers. Tambien pueden utilizarse por otras partes del kernel, por ejemplo Btrfs para descomprimir los datos; a día de hoy utiliza una cosa rara basada en zlib para que se utilicen todas las CPUs, pero lo previsible es que acabe pasándose a workqueues, ahora que el sistema ya expande el trabajo entre varias CPUs él mismo)

3 de diciembre de 2009

Lo que trae Linux 2.6.32

Resumen de las novedades más importantes del kernel Linux v2.6.32, que acaba de salir hoy: Reescritura de la parte de la VM encargada de enviar los datos al disco, considerables mejoras de Btrfs, muchas mejoras en los drivers gráficos, KSM (deduplicación de memoria en sistemas virtualizados), límites blandos en el controlador de memoria, soporte de la arquitectura S+Core, mejoras en la herramienta perf y otras muchas cosas. La lista completa, aquí, como siempre.

· Reescritura de la parte de la gestión de memoria encargada de escribir los datos al disco ("per-backing-device based writeback"): En el contexto de Linux, "writeback" puede definirse como el proceso de escribir la memoria "sucia" (memoria perteneciente a archivos modificados) del caché de páginas al disco. La cantidad de datos que pueden necesitarse escribir de una vez puede ser inmensa -cientos de MB, o incluso GB-, y el encargado de hacer el trabajo es un thread del kernel con el nombre de "pdflush", que inicia su actividad cuando se alcanzan los límites definidos en /proc/sys/vm/* o como reacción a ciertas condiciones. Sin embargo, el actual sistema, pdflush, tiene varias desventajas, que lo hacen ineficiente en máquinas con múltiples discos y cuando se necesitan escribir grandes cantidades de datos. Jens Axboe (Oracle) ha diseñado un nuevo sistema que se basa en la idea de tener un thread de kernel dedicado a cada dispositivo y que maneja otro tipo de estructuras de datos que le permiten tomar mejores decisiones. Los threads "pdflush" son reemplazados con otros llamados "flush-MAJOR" (Major es el id "major" del dispositivo), que se crean cuando se escribe algo al disco y desaparecen automáticamente si no hay nada que hacer.

Este sistema tiene mejor rendimiento en muchos tipos de carga. En un benchmark de dos procesos haciendo escrituras secuenciales en un archivo de 32 GB ubicado en un volumen LVM con 5 discos "stripped", XFS fue un 40% más rápido, y Btrfs 26% más rápido. Una carga basada en el benchmark ffsb que hace escrituras aleatorias fue un 8% más rápido sobre una sola unidad SATA típica. En un test en discos SSD sobre XFS fue un 20% más rápido, con un ratio de transferencia que se mantiene estable en 1GB/segundo, mientras que pdflush solo conseguía hacer 750 MB/s y con continua fluctuación de la velocidad. Las escrituras aleatorias a múltiples archivos tambien han mejorado, asi como las escrituras aleatorias mediante mmap(). En un test de un proceso escribiendo secuencialmente vs otro haciéndolo aleatoriamente pasó de unos pocos MB/s a 120 MB/s. Resumiendo, que el rendimiento mejora en muchos campos.

· Mejoras de Btrfs: En esta versión hay mejoras considerables en Btrfs:

· -ENOSPC: Hasta ahora, Btrfs no ha tenido verdadera capacidad de gestionar correctamente las situaciones en que el sistema se queda sin espacio libre (error -ENOSPC en varias funciones POSIX), debido a que estas situaciones son más dificiles de manejar en un sistema de archivos basado en técnicas COW que en uno tradicional donde simplemente se reescriben los bloques. En esta versión, Josef Bacik (Red Hat) ha añadido la infraestructura necesaria para solucionar ese problema. Nota: El sistema de archivos podría llenarse y, aun así, mostrar una cantidad considerable de espacio libre. Ese espacio viene de chunks de metadatos/datos que no pueden terminarse de llenar porque no hay espacio para crear su equivalente chunk de datos/metadatos. Este problema no tiene que ver con la gestión correcta de -ENOSPC, y será solucionada en futuras versiones

· Soporte adecuado de eliminación de snapshots y subvolúmenes: Usando la última versión de btrfs-progs se pueden encontrar herramientas para eliminar y renombrar snapshots y subvolúmenes sin tener que recurrir a rm -r. Este sistema es mucho más rápido, porque se hace la eliminación "caminando" el Btree. La implementación viene de manos de Yan Zheng (Oracle).

· Mejoras de rendimiento: Las escrituras secuenciales en hardware veloz se quedaban limitadas por el uso de CPU sobre los 400 MB/s, Chris Mason (Oracle) ha mejorado el código de manera que ahora es capaz de llegar a 1GB/s con la misma utilización de CPU que XFS (descontando los checksums). Hay tambien mejoras de velocidad en la escritura de grandes extents, y tambien en muchas otras cargas. Las configuraciones con múltiples dispositivos son tambien mucho más rápidas debido a los cambios en el sistema de writeback. La velocidad de fsync() tambien se ha mejorado considerablemente (soluciona un problema de lentitud de yum en Fedora 11)

· KSM (Kernel Samepage Merging), deduplicación de memoria en sistemas virtualizados: En los sistemas virtualizados, cada copia VM consume su memoria independientemente de las demás, y no puede compartirse a pesar de que una parte muy considerable es la misma en todas las instancias de un mismo SO. KSM es un sistema para compartir esa memoria. El thread del kernel ksmd escanea periódicamente areas de memoria, trata de identificar las que son idénticas, elimina las copias y solo conserva una. No toda la memoria es escaneada, solo las áreas especificadas por las utilidades de espacio de usuario mediante la llamada del sistema madvise(2) con el flag MADV_MERGEABLE.

El resultado es un dramático descenso de la memoria utilizada. En una prueba en un servidor de virtualización con KSM y 16 GB de RAM, Red Hat llegó a hacer funcionar 52 VMs con Windows XP y 1GB de memoria cada una. Este sistema fue diseñado para KVM, pero es agnóstico y puede utilizarse con cualquier otro sistema de virtualización, o incluso sin virtualización, por ejemplo en aplicaciones que por alguna extraña razón tengan varios procesos usando cada uno grandes cantidades de memoria que puede ser compartida en gran medida.

· Mejoras al subsistema gráfico: El aterrizaje de GEM y KMS en anteriores versiones ha marcado el inicio de una necesitada renovación en los drivers gráficos de Linux. En esta versión se añaden varias mejoras.

· Radeon: Soporte de KMS y aceleración 3D en r600/r700: Se Basado en las especificaciones liberadas por AMD (¡gracias!). El rendimiento 3D está lejos de ser óptimo, pero funciona lo suficientemente bien como para ser utilizado en el típico escritorio con efectos, puede tener problemas con los juegos. Con este driver incluso las últimas gráficas de AMD/ATI están soportadas, lo que significa que son las gráficas más rapidas que disponen de un driver libre. Solo Nvidia requiere aun un driver binario (algo que esperemos que solucione pronto Nouveau)

· Radeon: Soporte inicial de Salida de TV

· Radeon: Comprobador de comandos en rn50/r100/r200 (mejora la seguridad)

· Intel: Reseteo automático de la GPU en i965: La GPU es reseteada automáticamente cuando el driver detecta que ha habido un cuelgue de la misma.

· Intel: Compresión del framebuffer: Ahorra 0.5W cuando el sistema no está haciendo nada

· Intel: Control dinámico de la frecuencia del reloj: Cuando los gráficos no están haciendo gran cosa, el ratio de refresco LVDS y el de la GPU puede reducirse, y el autorefresco de la memoria puede ser inducido a un estado de energía menor.

· Intel: Mejorar la respuesta del sistema bajo presión de memoria: Cuando el sistema se está quedando sin memoria, el driver puede liberar algunos de sus buffers.

· VGA Arbitration: En sistemas multiseat (varios usuarios accediendo a un mismo servidor que tiene múltiples tarjetas gráficas y múltiples monitores) no existe un sistema para arbitrar el acceso concurrente entre múltiples procesos, el "árbitro VGA" soluciona ese problema.

· Modo de baja latencia en CFQ: En esta versión, el IO scheduler CFQ (el que se utiliza por defecto) tiene una nueva característica que lo ayuda a limitar en gran medida el impacto que un proceso escribiendo puede tener en la interactividad del sistema. El resultado final es que la experiencia en el escritorio debería estar menos impactada por el IO del sistema, pero puede causar problemas de rendimiento en los servidores, asi que la gente a la que solo la importa el rendimiento (servidores) pueden probar a desactivarla -está activada por defecto- escribiendo un 0 a /sys/class/block//queue/iosched/low_latency.

· Mejoras en perf, perf tracepoints, perf timechart, perf sched: La herramienta perf está recibiendo mucha atención y muchos parches. En los últimos meses ha sobrepasado su carácter inicial de sistema de contador de registros de rendimiento de hardware, y se ha convertido en una herramienta mucho más genérica para la enumeración, reporte, logeo, monitorización y análisis de eventos, asi que la herramienta ha sido renombrada de "Contadores de rendimiento" a "Eventos de rendimiento"

· Trapoints: En esta versión se incluye soporte para "probear" los puntos de traceado estáticos (para entendernos: una especie de printk()s ocultos con nombre y que se pueden activar y desactivar individualmente) que han sido añadidos a muchos subsistemas del kernel (tambien se pueden analizar desde systemtap). Ahora es posible analizar cargas mucho más fácilmente. Cuando debugfs está montado, perf list muestra una sección con todos los puntos de trazado disponibles en el sistema, de modo que puedes hacer cosas como perf record -e i915:i915_gem_request_wait_begin -c 1 -g para conseguir una traza inversa de las llamadas que causan una pausa en las GPUs Intel, o perf stat -a -e ext4:* --repeat 10 ./somebenchmark para tener unas estadísticas media de todos los puntos de trazado de Ext4 a lo largo de 10 ejecuciones de algún benchmark. Tambien puedes analizar llamadas de sistema, por ejemplo puedes hacer perf stat -e syscalls:sys_enter_blah, lo cual sería una especie de strace, pero con unas características adicionales que lo hacen aun más potente que éste. Puedes leer [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/trace/tracepoint-analysis.txt;h=5eb4e487e667d1396bcede6af11e0bd5c60f0711;hb=bb72222086260695d71afe60fa105649c1ea9463 Documentation/trace/tracepoint-analysis.txt] para tener un howto de como hacer análisis de rendimiento con puntos de trazado.

· Timechart: "perf timechart" es una herramienta basada en perf diseñada para ser un mejor analizador del arranque que bootchart. Genera un gran archivo SVG al que, a diferencia de bootchart, puede hacérsele zoom para tener un gran detalle de los eventos recogidos. En [http://blog.fenrus.org/?p=5 esta entrada de blog] puede encontrarse mucha más información sobre esta herramienta.

· perf sched: Una nueva herramienta ha sido añadida para trazar/medir propiedades del gestor de procesos.

· Nuevos tracepoints: En esta versión se han añadido tracepoints para llamadas al sistema, carga/descarga de módulos, asignación y uso de skb's (socket buffer), KVM, los algoritmos de gestión de memoria, los temporizadores, el driver i915, ciertas partes de Ext4 y JBD2, y soporte de perf en SPARC.

· Límites blandos en el controlador de memoria: Los grupos de control son una especie de contenedores virtuales que se crean como directorios en un sistema de archivos virtual especial (normalmente, con la ayuda de [http://libcg.sourceforge.net/ herramientas]), y puedes añadir una cantidad arbitraria de procesos a ese grupo de control y configurarlo para que tenga una serie de características ó límites determinados de CPU y memoria para los procesos que contiene. En esta versión se añaden soporte para límites "blandos" (o tolerantes) de memoria: El proceso puede sobrepasar el límite blando mientras haya memoria (y no excedan su límite "duro"), pero si el sistema necesita memoria, extraerá memoria de los grupos que sobrepasaron su límite blando.

· Suspensión de dispositivos en tiempo de ejecución: Esta característica permite que cada dispositivo sea puesto en modo de bajo consumo o que sea "suspendido" individualmente tras un periodo de inactividad, algo que antes se hacía solamente al suspenderse el sistema. Cuando se vuelve a registrar actividad, se reactivan. Por lo general, se requiere soporte de hardware para que esta característica funcione, y los diferentes tipos de bus son quienes realmente se encargan de gestionar las peticiones de suspensión de cada dispositivo.

· Soporte de la arquitectura S+core: Esta versión añade soporte para una nueva arquitectura, [http://w3.sunplus.com/products/S%2Bcore.asp S+core]. El conjunto de instrucciones de Score soporte instrucciones de 16bits, 32bits y 64bits. Los SOCs de Score han sido utilizados en máquinas de juegos y televisores LCD.

· Soporte de Intel Moorestown y SFI (Simple Firmware Interface) y ACPI 4.0: SFI es un método para exportar tablas estáticas del firmware de una plataforma al SO - algo análogo ACPI, pero como suele hacerse en otras arquitecturas, como PPC. Se utiliza en los dispositivos MID basados en la segunda generación de la plataforma Intel Atom, cuyo nombre código es Moorestown. SFI se utiliza en esas arquitecturas porque es más simple y ligero. Para más información, ver [http://simplefirmware.org este sitio web] Al mismo tiempo, esta versión añade soporte para Moorestown, la plataforma Moblin basada en la arquitectura de bajo consumo de Intel. Moorestown consiste de dos chips: Lincroft (CPU, gráficos y controlador de memoria) y Langwell IOH. A diferencia de los PCs x86 standard, Moorestown no tiene muchos dispositivos "legacy" e.g. Moorestown no tiene i8259, i8254, HPET, legacy BIOS, ni la mayoría de puertos IO.

Tambien se ha añadido cierto soporte inicial para ACPI 4.0 (Linux es la primera plataforma en soportarlo

21 de noviembre de 2009

Fedora, yo te saludo

Para que vean que este blog tiene dignidad, voy a renunciar a hablar de la nueva distro de cierto buscador para escribir en su lugar de mi paso a Fedora. Hace 3 años casi exactos que me pasé de Debian a Ubuntu, y ahora repito la historia con otro nombre. No mencionaré el fugaz paso del tiempo, prefiero regocijarme en el avance del progreso.

¿Por qué cambiar? Llevaba ya algún tiempo con la intención. En Fedora colaboran muchos de los trabajadores de Red Hat (y los que no colaboran la usan activamente y mandan parches a través de sus colegas), lo cual significa que varios de los más importantes programadores de software libre mantienen en ella paquetes de su propio software. Ubuntu no es que carezca de personalidades que hagan cosas importantes (pensemos, por ejemplo, en el magnífico upstart), pero no hay tantos como en Red Hat/Fedora, ni de lejos.

Eso marca diferencias. Fedora suele usar versiones muy nuevas de software e incluye features que nadie ha incluido antes; a veces incluyen cosas antes de que sean incluidas en upstream (por ejemplo, mejoras de rendimiento de qemu/kvm que me apetecía mucho probar), pero el mantenedor que te está metiendo esas cosas es el mismo programador que mantiene el código en el proyecto original. Quiero decir que no es lo mismo que usar Debian unstable, donde lo hay una serie de empaquetadores que toman snapshots de un repositorio, y que si se encuentran con un bug serio tienen que esperar a que aparezca un parche en upstream. En Fedora hay menos intermediarios, por decirlo de alguna forma, y como los Red Hateros que colaboran en el proyecto trabajan a sueldo la distro está muy, muy bien atendida y las versiones estables no son en realidad menos estables que cualquiera de Ubuntu, a juzgar por lo que estoy viendo. Aunque hay un detalle importante en esto: Fedora suele centrarse más en el software "base": kernel, gcc, libc, etc; mientras que Ubuntu se centra más en el software del escritorio.

Una vez explicados los motivos, vayamos a las experiencias.

En primer lugar, he aprovechado para pasarme a Btrfs, uno no puede pasarse el santo día hablando de algo y no tragárselo él mismo. Solo mantengo /home y /boot en Ext4, asi que excepto en caso de actualizaciones y uso cotidiano de /tmp/ y /var mi sistema Btrfs se dedica solo a leer datos, que es una función sobradamente sólida para ser usada a diario, y aun si lo usara tambien para /home dudo que tuviera problemas porque está empezando a estar maduro (en 2.6.33 va a ser considerado suficientemente estable para empezar a adoptarlo).

En general, Fedora da la impresión -y digo impresión, porque no se como describir la sensación- de tener peor integración final que Ubuntu, algo comprensible ya que Canonical pone todo su empeño en facilitar las cosas fundamentalmente a los usuarios sin muchos conocimientos, mientras que Fedora parece estar más orientada, por decirlo así, al usuario de Linux que no quiere complicarse la vida pero sabe por dónde se anda. Haciendo analogías con hardware, Fedora es una distro "workstation" -se nota que está hecho por gente que trabaja fundamentalmente en servidores- mientras que Ubuntu es "desktop".

Estas diferencias se notan en cosas puntuales como el acceso a privilegios de root. Fedora sigue teniendo el usuario root con contraseña propia. ¡Y los usuarios normales no pueden utilizar sudo por defecto! Puede que sea apropiado para servidores, pero para el escritorio de una persona creo que el modo de hacer de Ubuntu es suficiente y es mucho más comodo.

Otro aspecto es en la gestión de software: La eterna rivalidad deb vs rpm. Aunque en un principio he notado muchas diferencias, a la hora de la verdad uno se da cuenta de que son meros detallitos, los principios básicos son los mismos. Eso si, yum consume demasiados recursos y, en general, APT y sus repositorios parecen estar mejor organizados. Una cosa que me gustó mucho en Fedora, y quizás sea el segundo factor que más me impulso a cambiar a Fedora, fue la descarga "diferencial" de paquetes (Presto), activada por defecto en esta versión. Nada más instalarlo tenía ya unas cuantas actualizaciones, pero Presto me redujo su tamaño drásticamente, véase este mensaje informativo: "Presto reduced the update size by 84% (from 54 M to 8.9 M)".

Lo que más problemas me dió fue SELinux. Decidí usar mi ex sistema Ubuntu como /home. Mi antiguo $HOME quedaba por tanto en /home/home/usuario/, y, para usarlo cómodamente tambien en Fedora, decidí hacer un enlace simbólico de /home/usuario a /home/home/usuario, así si tenía que volver a Ubuntu por alguna razón, podía hacerlo con tan solo cambiar un parámetro en grub y borrar el enlace simbólico. Esto, que en apariencia parece algo sencillito, resultó ser lo más complicado de hacer, casi un infierno. A pesar de estar los permisos correctos y el enlace simbólico funcionar sin problemas, y a pesar de haber usado chmod -R para cambiar la id de propietario de todos los archivos, resulta que las cosas no tenían el "contexto adecuado", y a pesar de que el enlace era correctísimo, KDM no tenía permiso para acceder al directorio. Sabía cual era el problema, me prefiguraba en la mente como tenían que quedar las cosas una vez solucionadas, pero llegar a dar con los pasos necesarios para arreglarlo fue costosísimo. Me sentí como un novato que llega a Unix por primera vez. Lo peor es que, en realidad, SELinux no es tan complicado: lo peor fue la falta de documentación clara, la ausencia de mensajes de error en comandos que fallaban, y cosas así.

Tuve tentaciones de rearrancar con el parametro "selinux=off", que me hubiera solucionado todos los problemas, pero no lo hice y me alegro, he de decir que estoy encantado con el sistema: cada vez que se produce una falta aparece un popup en el escritorio informandome con detalle del problema y de las posibles soluciones. Pero es cierto que SELinux tiene la gran desventaja de que uno no puede usar un sistema con ello y olvidarse. No es algo transparente, que funcione al margen sin meterse con nadie, al contrario, está presente, se pone en medio a veces, y tienes que convivir con ello, conocer las herramientas más o menos tan bien como los comandos típicos de Unix, y enfrentarte a algún problema de vez en cuando y saber arreglarlo.

La última queja que tengo sobre Fedora es el legal. Bien es sabido que ni Fedora ni Red Hat compilan soporte de NTFS, ni Wine, ni MP3, ni DVD, ni muchos codecs de video, por el riesgo de ser denunciados por infracción de patentes. Son muy estrictos con este tema, y, en mi opinión, hacen bien. Sin embargo, una de estas restricciones afecta a freetype, la librería que hace el antialiasing de las fuentes, varias de las técnicas que se necesitan para renderizar decentemente las fuentes están patentadas, y Fedora las desabilita. En consecuencia, las fuentes en fedora son por defecto horribles. Inusables. Me fastidió mucho que no se ofreciera una solución fácil, o algún paquete alternativo, en Ubuntu se ha facilitado mucho el instalar software propietario e incluso semi-ilegal, y los usuarios lo agradecen, en Fedora no hacen ningún esfuerzo para facilitar nada. Ni tan siquiera tienenmucha documentación para resolverlo. Uno se encuentra con que Amarok empieza a saltar de canción en canción a toda velocidad, sin emitir ningún sonido por los altavoces, y al principio te preguntas si será algún problema de sonido o qué carajo pasará, hasta que recuerdas -porque ya lo sabías antes, sino de qué- el tema de las patentes y googleas hasta dar con una solución. La solución es recurrir a los magníficos repositorios rpmfusion, donde tienen soporte de MP3, DVD e infinidad de codecs, y, por supuesto, una versión de freetype sin las restricciones que tiene Fedora, que mejora la calidad del escritorio una auténtica barbaridad. Más incluso que en Ubuntu, jamás he tenido unas fuentes de tanta calidad en un sistema Linux con tamaños tan grandes (consejo: si quieren hacerse un favor suban un par de puntos el tamaño de sus fuentes y pásense así varios días, comprobarán que las fuentes grandes son agradabilísimas y muy recomendables y que las pequeñas son inaguantables)

Creo que aparte de estas no tengo más quejas, el resto va fenomenal: por alguna razón incluyen un driver Intel notoriamente más veloz que el que tenía en Ubuntu, Btrfs vuela e incluso hace que el disco duro tenga un sonido distinto al habitual y que parece más agradable (caprichos de músico). Se podría decir que en general Fedora es una distro que requiere algunos retoques nada más instalarla pero, una vez hechos, lo cierto es que el resultado me agrada más que mi antigua Ubuntu.

17 de noviembre de 2009

Linux no es tierra para FatELF

El tiempo que pasó entre su anuncio y su desaparición fue tan corto que los trolls casi no tuvieron tiempo de pensar argumentos para las discusiones. A pesar de recordar prematuramente al Titanic, FatELF, la idea de juntar los binarios para varias arquitecturas en uno solo, recorrió todos los blogs y sitios de noticias como la pólvora. Pero al final el barco se ha hundido. No diré que me alegro, porque tampoco es de buenos ateos ser puntilloso, pero este hundimiento se veía venir. Y es que francamente este invento tenía, en la práctica, poco de útil.

Hay muchas cosas que Linux puede copiar de Mac OS X u otros sistemas operativos, pero en lo que se refiere a saber convivir con varias arquitecturas, me parece que es más bien al contrario, que es Linux quien puede enseñar un par de cosas. No se suele oir mucho, pero a día de hoy Linux es el SO con más soporte de arquitecturas, por encima de NetBSD. Además, las soporta además desde hace mucho, desde 1995, asi que desde muy pronto se tuvo que lidiar con los problemas que originaban.

Por ejemplo, los sistemas de archivos de algunos SOs están habituados a funcionar en una sola arquitectura, y si mueves el disco de, por ejemplo, un sistema de archivos UFS creado en un SPARC a un x86, no puede leerse, porque la versión para SPARC escribe los datos en formato big-endian y x86 los lee esperando que sean little-endian, es decir, no puede leerlos. En cambio, los sistemas de archivos de Linux estan diseñados para que un disco pueda intercambiarse entre sistemas diferentes sin problemas: El código está adaptado para transformar desde/hacia un tipo de formato a otro en todas las rutas del código que lean o escriban datos al disco, y los datos siempre se escriben en un solo formato (little endian, generalmente).

Cuando se crearon los sistemas de paquetes en Linux, se diseñaron con soporte de varias arquitecturas. Y el principal argumento en contra de FatELF es este: Que el tema de las arquitecturas ya está perfectamente solucionado en Linux desde mucho antes que a Steve Jobs se le ocurriera cambiar PPC por x86. Para Mac OS X los binarios universales les van bien, claro: su modelo para distribuir aplicaciones no es mediante repositorios, y en el switch de arquitectura fue necesario usar aquel truco del viejo Nextstep para facilitar la transición. Pero en Linux la cosa cambia. Los repositorios se ocupan del problema

Aun quedan los programas "de terceros", ¿qué sería de ellos? ¿No les vendría bien FatELF? Pues dudosamente, empezando con que cualquier programador "de terceros" debería, en principio, hacerlo mediante paquetes, que siempre serán varios debido a la fragmentación linuxera. Ignorando ese punto, tendrían que decidir para cuantas arquitecturas van a compilar: x86-32, x86-64, PPC, IA64, SPARC...puede que no sea necesario preocuparse de muchas de esas arquitecturas por su escasa relevancia, claro, pero ahí está el asunto: ¿de cuales te preocupas, y de cuales no? En Apple está todo claro, porque además de software hacen hardware y se sabe a qué hay que atenerse, pero en Linux todo está muy indefinido.

En el caso de que en Linux necesitaramos distribuir algo con soporte de varias arquitecturas en un solo archivo, resultaría mucho más fácil y lógico (y así se lo he indicado al tipo creador de FatElf en un flamewar, sin recibir respuesta) añadir soporte a RPM/DEB para poder crear meta-paquetes que tengan dentro todos los paquetes de las diversas arquitecturas. El instalador (dpkg/rpm) escogería el adecuado para el equipo en el que se instala y voilá, ya tienes distribución multi-arquitectura en un solo archivo...y sin tocar una sola línea de código del kernel, y evitando tener binarios gigantescos en el sistema para una arquitectura que no se utiliza. No es además nada dificil implementarlo: básicamente se trataría -quizás literalmente- de un archivo tar con varios paquetes dentro.

Si nadie lo implementa es por la simple razón de que a nadie le hace falta. FatELF es una idea en infructuosa búsqueda de un problema que resolver.

6 de noviembre de 2009

Los absurdos escrúpulos de la Comisión Europea

El retraso de la adquisición de Sun por parte de Oracle por parte de la Comisión Europea, para detectar posibles riesgos de monopolio, cada vez me parece más estúpido. No es que un servidor sea de los que creen que a las multinacionales no hay que vigilarlas, pero la vigilancia actual probablemente podría mejorarse.

Entiendo que el trabajo de una comisión antimonopolio no debe ser fácil: tienen que controlar a las multinacionales en una sociedad donde las multinacionales son aceptadas y dominan buena parte de la economía y tienen permitido hacer casi de todo. Los límites de lo que pueden y no pueden hacer son tremendamente difusos, la repercusión mediática es considerable, las presiones deben ser numerosas...

La comisión ha logrado grandes beneficios para la sociedad, como forzar a Microsoft a proporcionar documentación a Samba (que, ojo, está haciendo enormes progresos pasito a pasito), pero en otros aspectos deja que desear. Por ejemplo, forzó a Microsoft a tener una versión de Windows sin Windows Media Player, cuando lo que hacía falta era poder desinstalarlo. El resultado fue que de la versión sin WMP se vendió prácticamente ninguna copia y Microsoft no hizo nada para permitir la desinstalación. Recientemente hemos visto a la Comisión hacer caso de las peticiones de Opera sobre el monopolio IE. Cualquier persona con dos dedos de frente puede deducir, mirando las estadísticas de Firefox, que un navegador puede tener éxito si se lo propone y es bueno. A pesar de que el fracaso de Opera es responsabilidad suya, consiguieron que la Comisión obligara a Microsoft a plantearse lo de aquella ridícula "Ballot Screen"...pero no forzaron a Microsoft a permitir la desinstalación de IE.

Quiero decir con todo esto que me parece muy bien que se aprieten las tuercas a las multinacionales, pero hay que apretarselo en el sentido adecuado, no en el de aflojar. Hacer una versión sin WMP no ayudó a debilitar su predominancia monopolística. Casi nadie quiere usar Opera, por mucho que lo ofrezcan en una pantalla (si lo quisieran ya tendría una cuota decente, como Firefox). Es obvio que la Comisión no tiene ni idea de informática, que no tienen expertos que les aconsejen los caminos idoneos. O les tienen y no les escuchan. Parecen guiarse por términos económicos, "este producto es un monopolio y si hacemos esto la competencia tendrá oportunidades", pero las multinacionales les marean y se marean ellos mismos, y acaban aprobándose soluciones absurdas.

Ahora tenemos el caso de la adquisición de Sun. La Comisión se preocupa, y hace bien, es su trabajo, de cómo puede afectar la compra de la mayor base de datos de software libre por parte de la mayor base de datos propietaria. Hace bien la Comisión al preguntarse si Oracle carecerá de incentivos para mejorar MySQL para hacerse competencia a si mismo.

Pero MySQL es software libre. Como han señalado muchos, Oracle no puede parar MySQL, porque si intentan sabotearla, consciente o inconscientemente, otra empresa -ya han surgido algunas- correrán a llenar el vacío. Los trabajadores de MySQL pueden incluso dejar Oracle y meterse a trabajar en exactamente el mismo código en otra empresa. El software libre no permite crear monopolios (una de las grandes razones por la que muchos capitalistas e inversores no confían en él). No hay, por tanto, miedo de que Oracle acabe con MySQL. No se confundan, es obvio que sería mucho mejor para todos si volviera a ser una pequeña empresa independiente, simplemente no veo razón para creer que la compra pueda derivar en una muerte del proyecto que de pie a un mayor monopolio.

En cualquier caso el proceso regulatorio es lentísimo, lo cual perjudica a todos al retrasarse la decisión final, y sus cada vez impredecibles decisiones dan pie a pensar a los norteamericanos que tenemos manía y miedo a sus empresas. A día de hoy la Comisión es una ruleta ante la cual todo comprador no sabe seguro cual va a ser el resultado, esto no beneficia a Europa en nada. Para decir a Oracle que deben escindir MySQL y convertirlo en empresa independiente no debería necesitarse tanto tiempo.

4 de noviembre de 2009

Upstart

Una pequeña nota para enlazar a este magnífico artículo sobre upstart. Es uno de esos cambios que se ha hecho poquito a poco y sin que la mayoría de gente nos enteremos de qué es y como funciona; en ese artículo lo explican con maestría.

2 de noviembre de 2009

Tiendas de aplicaciones: El panorama linuxero

Despues de escribir sobre la posible generalización de las tiendas de aplicaciones en todas las plataformas debido a sus ventajas económicas, solo queda examinar cómo se enfrente Linux a este fenómeno.

Mucha gente ha dicho, yo tambien, que las App Stores son una imitación de los sistemas de gestión de paquetes de Linux como APT y Yum. Hay que reconocer que, en gran medida, son exactamente eso. Ubuntu lleva ya un tiempo con una aplicación gráfica donde el usuario puede instalar miles y miles de aplicaciones a golpe de click.

Al ser, además, parte integral del sistema, tambien gestionan las actualizaciones no solo de las aplicaciones sino del software del propio sistema. Eso hace, entre otras cosas, que las actualizaciones entre versiones de una distro sean -en mi opinión- mucho más fiables que en otras plataformas, que sin bien pueden actualizar entre versiones sin demasiados problemas, lo hacen a ciegas, blandiendo la espada y dejando que Dios reconozca a los suyos. En una actualización importante de una distro Linux puedes tener un problema de dependencias debido, por ejemplo, a algún paquete instalado a mano. O a un paquete rebelde de algún repositorio no prioritario. O cualquier otro problema. Pero eso tambien forma parte del concepto de fiabilidad: Hay un problema y el sistema te lo señala claramente, y te dificulta y hasta prohibe actualizar hasta que no lo resuelvas; intenta, en resumen, impedir que el sistema entre en un estado indefinido, trata de evitar el problema antes de que ocurra. Hay gente que maldice los gestores de paquetes de Linux y su sistema de dependencias, pero no se dan cuenta de los problemas posteriores que evitan.

Hay muchas razones para amar nuestros gestores de paquetes; suponen un adelanto de 10 años (apt 0.0.1 nació el 31 de Marzo de 1998) al App Store de Apple. Durante este tiempo han supuesto un inconveniente para la distribución de software a base de programas individuales, pero si el modelo de los repositorios se generalizara, sería algo del pasado. Seríamos, por tanto, unos pioneros en el tema.

Sin embargo, no todo es tan bonito. El App Store es algo más que un mero repositorio. Como decía en el artículo anterior, en realidad es un supermercado que permite ejercer los mecanismos de oferta y demanda. Es un lugar virtual para ofrecer productos y pagar cómodamente por ellos. Los sistemas como APT son ajenos a eso, no se pueden comprar ni vender aplicaciones, no son un mercado, y por lo tanto los programadores no tendrán ningún incentivo para poner programas de pago en ellos, tendrían que construirse su sistema anticopia y de cobro online.

La cuestión, claro, es si Linux quiere o debe crear un mercado de aplicaciones. Choca frontalmente con el concepto de software libre. Desde ese punto de vista, APT no necesita ni permitir cobrar ni permitir vender aplicaciones. Además, aunque se permitiera la existencia de ofertas comerciales, la orientación del software libre tiende a reemplazar toda oferta comercial con alternativas libre, asi que quedarían pocos resquicios para construir aplicaciones por las que la gente esté dispuesta a pagar dinero. Asi que Linux en principio no necesita tal sistema...para pagar por aplicaciones.

Otra cuestión es la de pagar por otros servicios, como video, música, o cualquier otra cosa. Si la compraventa tiene dificultades en Internet, y si la solución es crear un sistema que permita a la gente pagar/cobrar dinero de/a su cuenta fácilmente, la ausencia de tal sistema para Linux supone una desventaja que solo una empresa basada en web 2.0 y protocolos abiertos, como google, podría suplir.

Un detalle importante que Linux puede aprender de las tiendas de aplicaciones es la barrera de entrada. En la App Store, un desarrollador puede registrarse, pagar su cuota de 99$ y subir su aplicación en relativamente poco tiempo; tras una revisión, Apple decide si la incluye, si hay algún problema serio con ella no la acepta o la borra cuando lo detecta. El proceso es relativamente sencillo. Sin embargo, para poder incluir una aplicación en un repositorio como los de Ubuntu o Debian hay que convertirse en desarrollador de la distro y atravesar un intrincado laberinto de burocracia. No se diferencian a los mantenedores de la distro y a los que quieren subir y mantener una pequeña aplicación, aunque ésta sea libre. Esto desalienta que, por ejemplo, alguien de Facebook suba y mantenga un programa para acceder a su página, o que un desarrollador de cierta aplicación libre suba y mantenga su aplicación en los repositorios de Ubuntu o Debian: siempre hay que esperar a que lo haga un mantenedor.

Tal vez fuera útil que las distros como Ubuntu y Debian concibieran una nueva clase de colaborador, un colaborador que no pretende ser desarrollador de la distro sino mero mantenedor de un pequeño programa, que pueda empezar a hacerlo fácil, casi automáticamente, que todo lo que haga no pueda afectar más que a su paquete, que haya un sistema para borrar su aplicación si su programa comete alguna infracción. Los repositorios PPA de Ubuntu son un gran paso en ese sentido, pero quizás haga falta algo más.

29 de octubre de 2009

Tiendas de aplicaciones: "¡Es la economía, imbécil!" (dos de tres)

En el post anterior decía que debía ser muy ventajoso para los programadores de iPhone disponer de algo como el App Store que les alivie la carga de la distribución y el cobro de sus programas. Aunque registrarse como desarrollador de iPhone cuesta 99$ por año -que no es poco-, el darlo todo hecho ha facilitado que hordas de desarrolladores se hayan animado a unirse a la tienda. Si esos mismos programadores tuvieran que molestarse en mantener por ellos mismos todo lo que la App Store les da hecho quizás no programarían nada. Muy pocas personas se molestarían en dar su número de tarjeta de crédito en una web perdida para comprar una mísera aplicación de, pongamos, 3.99$. Pero en el iPhone es mucho más fácil conseguir compradores, y eso anima a muchos programadores -que, recordemos, también pueden ser empresas- a probar suerte.

La sociedad siempre acude en masa al mercado en el que se puede ofrecer y demandar cosas tranquilamente; nada puede evitar que los compradores hagan ofertas por las cosas que desean poseer, y siempre habrá productores que intentarán satisfacerlos para enriquecerse. En Internet sin embargo hay una serie de barreras que impiden que los consumidores puedan ofrecer cómodamente su dinero, y pedirlo los productores. Existe el cobro contra reembolso, existe el cobro a una tarjeta de crédito, existe el pago previo a una cuenta bancaria, pero excepto en casos particulares y cosas como Paypal, ninguna ha calado como verdadera alternativa virtual de intercambio de bienes y servicios por dinero.

Se oye con frecuencia que en Internet las cosas son gratis, y que así es como seguirá siendo, porque es lo que pide la gente, y a cada idea útil de pago le saldrá siempre una alternativa gratuita que la echará abajo. Que las cosas han de financiarse como mucho con anuncios. Se trata de afirmaciones cuya falsedad será demostrada -en mi opinión, y para bien o para mal- con el tiempo. Internet no es menos propicio para los negocios que la tienda de la esquina, más bien se trata de que aun no disponemos de un sistema cómodo para hacer transacciones comerciales, y recurrimos a los anuncios como alternativa-para-todo.

Mucha gente aun se sorprende de que los usuarios de iTunes/iPod paguen por la...¡música!, que a pesar del aumento de la velocidad de las líneas de conexión y disminución proporcional del tiempo necesario para bajarse un álbum (la discografía de Joan Manuel Serrat completa, que son una cantidad horripilante de discos, ocupa 2.54 GB, la mitad que un DVD), de las mejoras alucinantes en tecnología P2P y de la expansión de los sitios de descarga directa, las ventas de esa tienda no hayan sino aumentado. No se debe más que a la creación de un mercado, a que Apple ha facilitado, en la medida de lo posible, el pago por Internet. Una vez introducida la información de la cuenta bancaria, el usuario pasa a tener una interfaz donde se le ofrecen varias cosas, se informa de su precio y se permite comprarla a golpe de clic.

Los usuarios de iTunes -o de otras tiendas- que compran música no lo hacen porque Steve Jobs les haya lavado la cabeza o porque sean unos ricachones, lo hacen porque pueden, porque se les hace una oferta y se les ha facilitado poder responder a ella. Y si gran parte del resto de Internet no paga ni un céntimo por su música -o por las noticias de su periódico- no es porque deseen que "todo sea gratis" -¡obviamente, todos querríamos que todo en este mundo fuera gratis!-, sino porque nadie les ha dado oportunidad de hacer una pequeña oferta por conseguirlo a cambio de algo. Quieren disfrutar de las ventajas de bajarse música por Internet, pero se les ha dificultado enormemente pagar por ello, se les incita a recurrir al intercambio P2P (que por otra parte no tiene nada de malo, en mi opinión).

En el caso de App Store, no solo se facilita al usuario la compra, sino que se le facilita al programador la venta. El App Store es un gran centro comercial, y no metafóricamente sino en el sentido literal, en el que la oferta y la demanda reinan con casi absoluta libertad. Los programadores colocan sus aplicaciones en los estantes, suben o bajan los precios durante un par de semanas para observar si las variaciones en la demanda mejoran las ganancias, algunos de quienes no sean capaces de obtener más del 99$ por año que cuesta la suscripción probablemente acaben retirándose de su estante, los consumidores gastan el dinero a su antojo. Un verdadero centro comercial, de comercio de aplicaciones por las que la gente está dispuesta a pagar determinados precios.

Gran parte de la explosión de actividad en la App Store se origina por estos motivos (no toda obviamente: hay muchísimas aplicaciones gratuitas). Al mismo tiempo, esto convierte a Apple en el poseedor de una de las bases de datos más codiciables de Internet. No existe ninguna otra empresa que posea una lista de clientes y sus cuentas de banco más extensa, ni un centro comercial mejor acondicionado que iTunes. Lejos de la imagen de vendedor de hardware, Apple posee uno de los grandes valores de Internet. A día de hoy venden música, películas, y ofrecen estantes a los programadores de aplicaciones para iPhone, pero eventualmente puede ser extendido a la compraventa de cualquier producto digital. ¿Por qué no iba a ser el próximo paso la compraventa de aplicaciones para toda la gama Mac? Creo firmemente que eventualmente Apple lo hará. "Yo también sé jugarme la boca".

El próximo y último artículo sobre tiendas de aplicaciones se titulará: "Tiendas de Aplicaciones: El panorama linuxero".

26 de octubre de 2009

Tiendas de aplicaciones: próximamente en sus escritorios (uno de tres)

La App Store del iPhone es todo un fenómeno que cada vez me llama más la atención. Todos la están imitando, y esas cosas no ocurren sin que haya una poderosa razón para ello. Amenaza incluso con extenderse a todos los escritorios y convertirse en algo imprescindible y en la manera de distribuir software. Y para que vean que a este blog le queda mucha cuerda, he acumulado verborrea suficiente como para hacer tres post sobre el tema.

A primera vista la razón de su éxito está en lo cómoda que es para los usuarios, pero como me han señalado aquí alguna vez (Google dice que Javi Santana, que por lo visto conoce el campo), una gran parte está en lo fácil que se lo pone al desarrollador para crear aplicaciones. Sin esa facilidad, no habría tantas aplicaciones, sería como entrar en un supermercado y ver casi todas las estanterías vacías. Y la App Store tiene las estanterías repletas (a pesar de su puritanismo, que ha retirado más de una aplicación de los estantes).

Tambien debe ser un factor muy importante lo fácil que lo tiene el programador para distribuirlas. No hay que tener una página web para que los usuarios descarguen nada (aunque es muchos lo hacen incluyendo un enlace a la página de la aplicación en itunes), con el ahorro del tedioso trabajo que esas cosas siempre implican. Y no olvidemos la enorme facilidad para cobrar. No tienes que pedir un número de tarjeta de cŕedito a nadie, ni enredar con paypal, ni con divisas (las tiendas online no aceptan cualquier tipo de moneda), ni nada parecido, el desarrollador da su número de cuenta a Apple y ellos se encargan de cobrar al cliente y meterte el dinero en el bolsillo. Estas dos cosas, que parecen caprichosas, son más importantes de lo que parecen.

Resumiendo, Apple pretende que los programadores se ocupen de programar -que no es poco- y el resto tratan de resolvertelo ellos.

La App Store parece acertar tan bien a conjugar necesidades de usuarios y desarrolladores, que se me hace imposible concebir que Apple no esté considerando extenderla al escritorio. ¿Por qué no? ¿Por qué no distribuir aplicaciones de escritorio a través de una App Store, incluso las gordas y de pago, como Photoshop? Por supuesto, se trata de un planteamiento distinto al iPhone, los Mac de sobremesa no están -afortunadamente- bloqueados para prohibir la instalación de cualquier tipo de aplicaciones. El crackeo de software de pago sería inevitable, pero ¿es que acaso no lo es tambien ahora? Quien quiere crackear un programa de pago lo va a hacer igualmente; una App Store al menos incentiva la compra.

Creo que las "tiendas de aplicaciones", tanto en su lado atractivo para el usuario como en su comodidad para los desarrolladores, son algo destinado a imponerse poco a poco en todos los ámbitos, se tratan de "un paso más" en la oferta de las plataformas de la que a largo plazo nadie querrá carecer.

¿Que hará Microsoft? Al igual que resto de SOs móviles, tienen su tienda "Skymarket" crecida a la sombra de App Store. Lo curioso es que Microsoft tiene tambien ¡una tienda online para escritorios! Pero es solo para productos propios. Venden cosas como...Windows (lo que todo usuario de Windows quiere, comprar otra copia de Windows). Nada que ver con lo que andamos hablando. Es muy curioso: Microsoft debe gran parte de su fortuna a lo fácil que ha puesto siempre el desarrollo de aplicaciones a partners y los famosos "3rd party". Lo de "Developers, developers, developers" es algo más que un chiste, es una religión en esa empresa. Win9x debe mucho de su éxito a haber sido una gran plataforma sobre la que crear aplicaciones que funcionaban -siguen funcionando- en millones de ordenadores. Lo lógico sería que siendo uno de sus distintivos, vieramos en Microsoft más ímpetu por adelantarse, por ser los primeros en ofrecer, como siempre han ofrecido, la mejor alternativa para los programadores.

Pero no, la obsesión por atender a los programadores parece cosa del pasado, de la antigua Microsoft. La nueva Microsoft, encabezada por Ballmer, está demasiado ocupada añadiendo búsquedas en Twitter a Bing, o anunciando la enésima soplapollez basada en .NET, de esas que son inútiles para el 99% de desarrolladores y aplicaciones existentes. Demasiado ocupados intentando ser las reinas del Web 2.0, están descuidando su (innegable) corona actual como mejor plataforma para desarrollar. Mientras tanto, Apple ha descubierto que una App Store puede desafiar a la aparentemente inevitable tendencia Web 2.0 y conseguir reactivar el desarrollo de aplicaciones en código nativo, justo cuando nadie daba un duro por ellas. Pero de eso más en el siguiente post, que si las musas no cambian de opinión se titulará: "Tiendas de aplicaciones: ¡Es la economía, imbécil!"

14 de octubre de 2009

¿Reusar o reescribir?

La lectura del informe trimestral sobre el estado de FreeBSD me ha dejado unas dudas. Para empezar ahí se describen tareas absurdas para ese proyecto, como dedicarse a reescribir con licencia BSD utilidades Unix típicas de GNU. Me dirán que en Linux se ha hecho lo opuesto varias veces, y tendría que darles la razón. Pero se supone que los Linuxeros y los GNUeros somos los zealots, mientras que el sentido práctico siempre fue más característico de los BSDeros.

Luego tenemos la tarea de utilizar Clang en lugar de GCC. Clang es un frontend equivalente a GCC pero basado en LLVM, que está licenciado con licencia BSD. El mundo BSD lleva tiempo librarse de uno de los iconos del mundo Linux, gracias a LLVM su sueño está a punto de hacerse realidad. Aunque se muevan por el mismo deseo de librarse de la GPL, en este caso puede decirse que no se trata de una decisión del todo estúpida, puesto que tienen ciertas ventajas.

En última instancia, encontramos el port de ZFS. Aunque ha sido aceptado sin problemas, me consta que entre los más radicales BSDeros hay varios a los que no les gusta demasiado. No porque no les guste ZFS, sino porque no tiene licencia BSD, y si el tema de la licencia causa sarpullidos cuando se trata de herramientas de espacio de usuario, imaginen en algo que forma parte del kernel. Y aun peor, porque no se trata de un drivercillo ni una herramienta de depuración y análisis como Dtrace, sino un sistema de archivos, que es una pieza clave de todo sistema operativo y en especial de Unix.

A los problemas de licencia hay que añadir otro, más grave en mi opinión. He visto a BSDeros glorificarse ante los usuarios de Linux el disponer de ZFS y Dtrace. Técnicamente su orgullo está plenamente justificado, pero creo que a quien realmente glorifican, sin darse cuenta, es a OpenSolaris. ¿Qué es FreeBSD? ¿Que lo distingue del resto de SOs? Fundamentalmente, un kernel y unas herramientas y documentación y APIs de bajo nivel, bien empaquetados como un solo SO, el resto de software -apache, mysql, python, gnome, x.org- no es distinto de lo que uno puede encontrar en Linux o incluso en Windows en muchos casos. Si apartamos ponemos ZFS a FreeBSD tenemos algo que objetivamente es mucho mejor, pero ya no tenemos FreeBSD, sino OpenSolaris.

Y este es el gran problema de FreeBSD: la debilitación y progresiva pérdida de las señales de identidad que le distinguen en el mundo. Usando ZFS en vez de UFS, usando Dtrace, al final lo que estamos usando es a apache, mysql, python, gnome, x.org, sobre algo que forma parte de OpenSolaris, asi que lo más lógico es que la gente acabe usando el OpenSolaris original en lugar de un SO que se ha convertido en un mero clon suyo.

En mi humilde opinión, FreeBSD como proyecto debería centrarse en tratar de mejorar -"reescribir"- las facetas que lo hacen único, y no perder tiempo en el resto -"reusar"-. Ahora está haciendo lo contrario: reusar en su core el código de otros, y reescribir herramientas básicas que no le distinguen de nadie. Lo mejor es que no necesitan empezar de cero: pueden partir de Hammer, el sistema de archivos de DragonflyBSD (que por sus lazos no puede considerarse un SO totalmente distinto de el, y por tanto considero que no puede hablarse de "reutilización"). Quizás no esté tan preparado para sustituir a UFS (en realidad Hammer es un sistema de archivos orientado estríctamente a servidores), pero al menos lo distinguen del resto. De no hacerlo, corren, a largo plazo, serio riesgo de desnaturalización, si los biólogos me permiten el mal uso del término utilizado para designar el proceso de pérdida de estructura de las proteinas.

1 de octubre de 2009

Nokia se encadena a QT

Lo que se preveía y se rumoreaba ha acabado siendo cierto: Tras dormir un buen rato sobre la fria losa de la realidad Nokia ha decidido escuchar a los desarrolladores, que están diciendo que "developing for Nokia platforms sucks". Y en ese artículo enlazado se esclarece la solución que Nokia propone a sus desarrolladores: usar Qt. Si, la misma Qt que usa KDE.

Esto implica que, a largo plazo, Symbian está tan vivo como la carrera política de Francisco Camps (nula, para los que viven al otro lado del Atlántico y no saben quien es ese personaje). Nokia liga así su plataforma de software a Qt y se desliga de la batalla perdida de los sistemas operativos. Puesto que Qt permite desarrollar aplicaciones multiplataforma con facilidad, los desarrolladores deberían (en teoría, ya saben como son estas cosas en la práctica) poder diseñar aplicaciones que puedan funcionar tanto en Maemo como en Windows CE o incluso iPhone. O, al menos, debería ser posible hacerlas funcionar optimamente en cada plataforma con relativamente poco trabajo.

Queda por ver si Nokia es capaz de crear una plataforma de desarrollo y de distribución y compra de aplicaciones tan bien montada e integrada como la de Apple, pero de momento para empezar ya tienen un buen toolkit (que visto por encima sin duda es mas "limpio" que lo de Android y Palm, y visto por debajo dudo mucho que Android y Palm puedan acercarse ni tan siquiera remotamente a la amplitud de funciones de QT)

Las consecuencias para el software libre pueden ser más que considerables. En primer lugar, queda clarísimo cual es el futuro de Qt, que había quedado en entredicho tras la adquisición de Trolltech. Se dudaba de si iban a continuar invirtiendo en mejorar el toolkit. Con esta noticia se puede asegurar que no solo van a continuar invirtiendo, sino que van a invertir muchísimo más que antes, al pasar a ser Qt un elemento clave en el negocio de Nokia, que es una multinacional con mucho interés en recuperar su puesto dominante en el sector.

Los beneficios para KDE y Linux son obvios: Hay muy buena relación entre QT y KDE, de hecho bastantes programadores de QT han sido captados por su trabajo en KDE, aun siguen manteniendo partes del proyecto, en algunos casos son importantes mantenedores. No es sorpresa que ciertas mejoras en QT se hagan a veces pensando en KDE. Y en Nokia no ignoran las posibilidades que este escritorio ofrece, un buen ejemplo es este visor de documentos para maemo, basado en Koffice 2. Vaticino una edad de oro para los fieles de la K. Pero no solo para los KDEeros; recordemos que QT se puede usar tambien para aplicaciones de consola, aunque no haya tantas como podría haber, debido a la restricción de licencias que aplicaba Trolltech y que, recordemos, Nokia ya ha eliminado, relicenciando el toolkit entero bajo la LGPL, la misma licencia que usa GTK.

No se a ustedes, pero a mi una de las cosas que más me disgusta de Linux como plataforma de desarrollo es que para juntar una aplicación haya que recurrir a veces a varias librerías distintas, cada una con diferentes estilos de programación, diferentes lenguajes, bindings, diferente documentacion, diferentes fechas de estabilización, diferentes maneras de gestionar el proyecto, los bugs reportados, herramientas de desarrollo, etc. Ni falta hace decir que a cualquier programador venido de Windows o Apple, el desarrollo para Linux suele parecerle un caos. Siempre admiré a OS X por tener en Cocoa una solución unificada "para casi todo", ni tan siquiera Windows está tan unificado ahora que Microsoft ha dividido (estúpidamente) su imperio en dos con .NET. Nokia querrá hacer de Qt su propio Cocoa, y conseguirá al mismo tiempo que Linux tenga un buen competidor de Cocoa, de ese modo Qt podría convertirse en una gran plataforma para desarrollar aplicaciones Linux, la plataforma de desarrollo que siempre se ha dicho que nos faltaba para atraer la atención de otros programadores.

(Ya se que este post apesta a excesivo optimismo, pero seguramente ustedes no sean tan malvados como para reprocharme el ser optimista, ¿verdad?)

28 de septiembre de 2009

Haciendo dinero con Linux

¿Cuántas veces no se ha afirmado que con el software libre no se puede hacer negocio? Aun se pasa algún despistado por aquí afirmandolo en los comentarios. Me pregunto como se explicarán estos resultados de Red Hat: Un aumento de las ventas del 11% y de los beneficios del 36.9%. En plena crisis. Para ser un negocio del que es imposible sacar dinero, no está nada mal.

¿Cómo es posible que en plena crisis la gente siga insistiendo en gastarse dinero en Linux, y mucho menos en Red Hat, que no se conforman precisamente cuatro duros? Quizás la mejor explicación la haya dado hoy Michael Tiemann, fundador de Cygnus, la empresa especializada en GCC que Red Hat compró en 1999: "Todo se reduce a mi creencia en que los mercados libres son el mejor modo de hacer funcionar una economía, y si sabes hacer algo de una manera mejor, debe ser posible conseguir hacerlo rentable y exitoso". Un corolario a esta frase es que si Red Hat está mejorando sus resultados, es porque sabe hacer algo mejor que los demás.

Es muy significativo que de los 30 contratos que dicen haber firmado en el trimestre anterior, 23 incluyan virtualización, a pesar de que hacer poquísimo que anunciaron la primera versión con soporte de KVM, RHEL 5.4. Aquí Red Hat tiene una gran ventaja, y es que puede ofrecer KVM como parte dentro de un contrato más amplio que incluya otras cosas. VMware es el rey de la virtualización, pero no tienen un SO. Si uno echa un ojo de vez en cuando, comprobará que los del sombrero rojo están poniendo toda la carne en el asador en lo que concierte a cosas relacionadas con la virtualización, asi que cabe esperar grandes alegrías y esperemos que mucho dinero para Red Hat, Novell y compañía.

Parece que el tal Jim Whitehurst, el CEO de Red Hat, está montándoselo bastante bien.

Como curiosidad al margen de este post, me han pasado el enlace a esta fantástica página: inudge.net, donde se pueden hacer melodías simples y compartirlas en plan 2.0. Para que no se quejen de que este blog es aburrido, aquí pueden escuchar una melodía psicodélica de un servidor, en la que comprobarán los destrozos que puede ocasionar ser fan acérrimo de Mike Oldfield (silenciando todos los instrumentos excepto el primero, el azul, suena remotamente a música de videojuego). De lo más entretenido que he visto en muchísimo tiempo.

24 de septiembre de 2009

Btrfs: Una jungla de B-Trees

Este artículo describe la estructura interna de Btrfs, enfocado en su B-Tree y en como ha sido combinado en muchas y variadas formas para llegar a implementar la funcionalidad completa de un sistema de archivos de última generación. El texto es largo, pero bastante completo.

Introducción

Btrfs es un alias de "B-tree filesystem". La referencia a los B-trees podría parecer poco importante, los sistemas de archivos (en adelante SdA) y bases de datos los utilizan desde hace décadas. Pero no es casual que Btrfs tenga ese nombre, su estructura está muy influenciada por este concepto y, en realidad, es la característica que mejor lo define y diferencia de otros SdA, incluso de ZFS.

Siendo más concretos, Btrfs no implementa un B-tree tradicional, ya que son poco apropiados para técnicas de COW y snapshots y requerimientos de escalabilidad. ZFS optó, debido a ello, por una técnica inspirada en el slab. Btrfs no ha ido por el mismo camino, escogió otro a raiz de una conferencia para desarrolladores de SdA Linux celebrada en Febrero del 2007. Allí, un tal Ohad Rodeh, trabajador de IBM en sus laboratorios de I+D en Israel, presentó un nuevo tipo de B-tree optimizado para técnicas de COW y snapshots con escalabilidad y snapshots muy eficientes -tanto en términos de tiempo como de espacio-. De hecho presentó sus algoritmos como una ayuda para aquellos interesados en crear algo equivalente a ZFS/WAFL en Linux. Chris Mason, que había trabajado en Reiserfsv3, tomó nota y e implementó esa técnica, y de ahí el código evolucionó hasta convertirse en Btrfs. Queda claro que para comprender cómo funciona Btrfs hay que comprender cómo funciona su B-tree.

El B-tree: nodos e ítems

Los B-trees utilizados en SdA solamente almacenan datos en las hojas del extremo del árbol, concretamente en los ítems. Cada hoja puede contener varios ítems. El resto de nodos solo se utilizan para crear rutas hacia los ítems. Todos los B-trees se ordenan respecto a una clave, la que el programador decida, en el caso de Btrfs es esta:

struct btrfs_key {
u64 objectid;
u8 type;
u64 offset;
}

El primer campo, objectid, de 64 bits, es un identificador de objecto, único para cada objeto (pero un objeto puede estar compuesto por varios ítems, asi que puede haber varios ítems con el mismo objectid). Luego tenemos type, de 8 bits, que indica el tipo de item, es decir, el tipo de datos que contiene. offset indica una posición dentro del SdA (su uso concreto depende del tipo de ítem).

Tanto los ítems como los nodos tiene esta clave, sin embargo, ya se dijo que los nodos solo crean rutas hacia los ítems, por lo que a la clave solo añaden un puntero de 64 bits que indica dónde se encuentra el siguiente nodo/ítem en la estructura. Los ítems por su parte a la clave añaden alguna cosa más:

struct btrfs_item {
struct btrfs_key key;
u32 offset;
u32 size;
}
La clave tan solo identifica al ítem, no es el ítem en sí. En esta estructura se indica, en offset, la localización del ítem en la hoja del B-Tree, y en size su tamaño. Este offset es distinto del offset de la clave, que indicaba una posición absoluta en el SdA. Así es como se agrupan en una hoja los ítems:

[Struct Item0 | Struct Item1 | Struct Item2 | ... |Item2    |Item1 |Item0          ]

El espacio entre paréntesis representa una hoja del árbol. Como se ve, las estructuras que describen los ítems (struct btrfs_item) se agrupan al principio del bloque, y el item de verdad, cuyo tamaño varía dependiendo del tipo de objeto, se encuentra al final, esa localización es la que indica el offset de la estructura btrfs_item. Esta organización responde a motivos de eficiencia. Un detalle curioso es que en el caso de archivos pequeños, los ítems correspondientes al archivo almacenan los datos directamente en el ítem (idea derivada del "tail packaging del reiser v3), permitiendo así un acceso rápido a archivos pequeños.

Esta es una descripción quizás más detallada de lo necesario. Como resumen, lo único que hay que tener presente por encima de todo es que se trata de un B-Tree cuyos ítems se identifican con un identificador de objeto objectid de 64 bits y cuyo formato es especificado por el campo type.

Btrfs utiliza este B-Tree para almacenar todo tipo de cosas en forma de ítems: inodos, atributos extendidos, directorios, snapshots...cada elemento con un objectid independiente y un type que indique lo que son. Esto simplifica la implementación del SdA, pues cualquier operación termina siendo una búsqueda, inserción, modificación o eliminación de ítems de un B-Tree. El código se encuentra en el archivo fs/btrfs/ctree.c, y se encarga de hacer todas las modificaciones de bajo nivel, de rebalancear el árbol cuando es necesario, de aplicar COW, etc, todo automáticamente, sin que las otras capas del SdA tengan que preocuparse de ello.

Un bosque de B-trees: Root B-Tree

Una vez que se conoce el B-Tree, entender el funcionamiento de Btrfs es relativamente simple, solo hay que comprender las ramificaciones y combinaciones de sus conceptos básicos.

Todo SdA tiene un superbloque, es la primera estructura que se lee y la que describe las ubicaciones de todas las demás. Es tambien la única que tiene una localización fija en el disco, todas las demás pueden estar en cualquier parte. El superbloque tiene el formato de la estructura struct btrfs_super_block, que no se muestra aquí debido a su extensión. De sus campos destacaremos csum, que al igual que el csum de struct btrfs_header sirve para detectar corrupción. Y los mas importantes: root y chunk_root, de 64 bits, que indican la localización de dos B-Trees.

¿Dos B-Trees? Si, Btrfs tiene varios. De hecho, el B-Tree root es en realidad la raiz de raices, un árbol que almacena punteros a otros árboles. Actua, por así decirlo, como una especie de directorio de B-Trees.

Una gran ayuda para entender más visualmente Btrfs es la herramienta btrfs-debug-tree, que muestra la estructura del árbol. En el caso de Root tree la salida de btrfs-debug-tree correspondiente es:

root tree
leaf 29364224 items 9 free space 2349 generation 7 owner 1
fs uuid 56650d3d-a7bf-463c-a59f-fc87a454d47e
chunk uuid e7457d2d-b783-4cb1-9f43-aa4843ab02fd
  item 0 key (EXTENT_TREE ROOT_ITEM 0) itemoff 3756 itemsize 239
      root data bytenr 29368320 level 0 dirid 0 refs 1
  item 1 key (DEV_TREE ROOT_ITEM 0) itemoff 3517 itemsize 239
      root data bytenr 29372416 level 0 dirid 0 refs 1
En la primera línea se indica que es el Root tree, la segunda indica el comienzo de una hoja, el número total de ítems que contiene y el espacio libre que le queda para albergar más, y otros datos irrelevantes. La tercera y la cuarta indican las UUIDs del SdA y del Chunk tree (hablaremos de él más adelante). Tras ellos, los ítems. Los datos de la clave son los que están entre paréntesis, y a continuación de éste, el tamaño del ítem y su offset dentro de la hoja. Centrándonos en la clave, presentada en formato (objectid, type, offset), vemos que ambos ítems son de tipo ROOT_ITEM (un tipo de ítems que almacenan información sobre la ubicación de otros B-Trees), y sus objectid indican el tipo de árbol, Extent tree y Device tree respectivamente. Esos objectids presentados en forma de constantes pertenecen a unos rangos reservados. El offset, como vemos, no se utiliza. En la segunda línea de cada item, vemos el texto "root data bytenr", que quiere decir "byte donde se encuentra el inicio del B-Tree". El resto de datos se pueden obviar.

Device Tree

Btrfs no utiliza todo el espacio de un dispositivo tras añadirlo al SdA, sino que utiliza una parte y, según va requiriéndolo, recurre al resto. El Device tree, escogido a propósito del ejemplo anterior, sirve para almacenar información sobre qué partes del dispositivo están siendo utilizadas. Por razones que veremos más adelante, este espacio utilizado no se describe como un solo rango, se divide en varios rangos más pequeños, uno trás de otro. Estos son los ítems.

device tree key (DEV_TREE ROOT_ITEM 0)
leaf 29372416 items 7 free space 3484 generation 5 owner 4
fs uuid 56650d3d-a7bf-463c-a59f-fc87a454d47e
chunk uuid e7457d2d-b783-4cb1-9f43-aa4843ab02fd
  item 0 key (1 DEV_EXTENT 0) itemoff 3947 itemsize 48
      dev extent chunk_tree 3
      chunk objectid 256 chunk offset 0 length 4194304
  item 1 key (1 DEV_EXTENT 4194304) itemoff 3899 itemsize 48
      dev extent chunk_tree 3
      chunk objectid 256 chunk offset 4194304 length 8388608
  item 2 key (1 DEV_EXTENT 12582912) itemoff 3851 itemsize 48
      dev extent chunk_tree 3
      chunk objectid 256 chunk offset 12582912 length 8388608

Los ítems tienen claves con el type DEV_EXTENT (alias de "extent de dispositivo", o sea, rango continuo de bloques en un dispositivo). Su objectid es el identificador de dispositivo al que se hace referencia, que es 1 para el primer dispositivo. Este extraño uso del objectid clarifica cómo usa Btrfs sus diversos B-Trees: Cada uno se utiliza de una forma distinta, o más bien, cada árbol utiliza solo unos tipos concretos de ítems relacionados con su función. El offset indica la parte del disco que se quiere describir, y en los datos del item se indica el tamaño que abarcará esa parte (length), además de repetirse el offset(chunk offset). La primera línea tras cada ítem puede pasarse por alto.

Chunk Tree

El Chunk tree ya se mencionó antes, era aquel cuya posición está especificada en el campo chunk_root del superbloque. Su función es traducir entre el direccionamiento lógico del SdA y el direccionamiento físico del disco. Esto es necesario y se hace en todos los SdA: consideremos un SdA creado en una partición que se encuentra en la mitad del disco, su byte cero podría ser el byte 100.000.000 del disco. En Btrfs esa diferenciación es aun más necesaria, ya que un SdA se expande a varios discos simultaneamente, cada uno con su propio direccionamiento físico.

Es debido a esta función de traducción de direcciones lógicas a físicas que la ubicación del Chunk tree se encuentre en el propio superbloque: para encontrar la ubicación física del Root tree es necesario leer primero el Chunk tree. ¿Y la dirección del propio Chunk tree? Tambien se expresa en direcciones lógicas, asi que el superbloque duplica en su estructura una pequeña parte de información para poder encontrarlo.

Decíamos que el Chunk tree mantiene esas equivalencias lógico<->físicas no en forma de un solo gran rango, sino dividido en trozos (chunks, en inglés). Esos chunks suelen tener entre 256MB y varios GB. ¿De dónde se saca información sobre las direcciones físicas de los dispositivos? Del Device tree, naturalmente. Ya dijimos que ese B-Tree tampoco se definía en un solo gran rango, sino en varios. Y es que el principio y el final de los chunks coinciden exactamente con el principio y fin de los rangos del Device Tree. Un chunk es, por tanto, la representación lógica de una porción de disco.

En este árbol los ítems tienen el type CHUNK_ITEM, que indica que es un ítem con información sobre un chunk. El objectid siempre se asigna al valor de FIRST_CHUNK_TREE (se podría decir que en este caso no se utiliza). El offset indica la dirección lógica inicial del rango con el que se pretende tener una equivalencia física. En el ítem se indica el dispositivo donde éste se encuentra y el comienzo de su dirección física.

FS Tree

Este B-Tree se encarga de almacenar lo que se definiría tradicionalmente como metadatos: Nombres de los archivos y de los directorios, los inodos, información de los atributos extendidos, extents; se trata de la concepción más cercana que la gente tiene del interior de un SdA.

Los ítems de este árbol son algo complejos y de muchos tipos. En Unix, como es sabido, cada archivo tiene su correspondiente inodo, en el FS tree cada archivo tiene varios items, todos con el objectid de su inodo: uno del tipo INODE_ITEM que describe el tamaño y los permisos de acceso de ese archivo, otro de tipo INODE_REF que describe el nombre y número de inodo del directorio en el que se halla, otro EXTENT_DATA que describe la ubicación de los datos del archivo, en el caso de tenerlos. Los directorios, por su parte, tienen tambien varios ítems con el objectid de su inodo, uno de tipo INODE_ITEM, otro de tipo INODE_REF y, por cada archivo que haya dentro del directorio, dos items, uno del tipo DIR_ITEM y otro del tipo DIR_INDEX, ambos conteniendo el nombre y número de inodo de cada archivo correspondiente (la razón de que haya dos ítems por cada archivo se debe a la deficiencia de ciertas APIs de Unix, otros SdA han tenido que hacer cosas similares)

Los items del tipo EXTENT_DATA son los que informan de la ubicación de los datos de los archivos, es decir extents. Contienen en su interior la dirección lógica donde empiezan los datos del archivo, la extensión del extent, si el extent está comprimido, etc.

Extent Allocation Tree

Este es una especie de gestor de espacio libre de Btrfs. Es equivalente a los free space map de otros SdA. En realidad el nombre correcto de este árbol debería ser "used space tree", guarda información sobre las partes de los chunks que están usadas usadas. Se podría decir que su nombre despista un poco.

Este árbol no se toca para nada cuando se leen archivos. El proceso de lectura de un archivo consiste en buscar el archivo en el FS tree, y los ítems indicarán la dirección del disco en la que se encuentran los datos. Btrfs entonces solo tiene que mirar al Chunk tree para saber en qué dispositivo y en qué dirección física tiene que empezar a leer. Solo cuando se añaden, modifican o borran datos es necesario marcar en el Extent tree las partes de espacio que se van a usar, o a liberar las que estaban usadas.

Aparte de esa información, en éste árbol se forman una especie de "grupos de bloques" lógicos, que hacen referencia a grandes extents lógicos de los chunks. El objeto de estos "grupos de bloques" es subdividir el espacio disponible en partes que pueden ser dedicadas a los datos o a los metadatos. Esto se utiliza para poder agrupar separar los datos y los metadatos en chunks distintos.

Checksum tree

Este es el último B-tree. Como su nombre indica, almacena los checksums. Cada item, de type EXTENT_CSUM, contiene el número del byte de cada extent y su checksum.

Subvolúmenes y snapshots

Antes de hablar de estos conceptos, hay que definirlos y diferenciarlos. El snapshot es bien conocido, se trata de una copia idéntica del SdA en el momento en que se toma y que se mantiene inalterado con el tiempo. El subvolumen es un concepto menos conocido: se trata de una especie de nuevo SdA, pero un SdA nuevo de acuerdo con la gestión el espacio en forma de pool. Es decir, no un SdA literalmente aparte, sino uno obtenido del pool.

Un subvolumen vacío no tiene nada dentro, solo los directorios "." y "..". Puede montarse en cualquier directorio. De hecho, existe un subvolumen en todo SdA nuevo llamado "default", que es el que se crea y usa por defecto. Un subvolumen puede tener configurado un límite de espacio, de modo que puede utilizarse como un sustituto de las tradicionales quotas, creando en /home un subvolumen para cada usuario con un límite de espacio determinado.

Sin embargo, internamente subvolúmenes y snapshots son la misma cosa: un FS tree. Uno por cada subvolumen o snapshot. Se diferencian en que el subvolumen es un FS tree vacío, sin archivos ni directorios, mientras que el snapshot tiene ya un montón de archivos y directorios. En realidad los snapshots inicialmente comparten su FS tree con el subvolumen en que se toma, solo se deja una "marca" en nodos e ítems afectados, de modo que cuando cualquiera intente hacer una modificación de su FS tree compartido, el mecanismo COW duplicará las partes modificadas del B-Tree. Puesto que hasta que no sean modificados los ítems que hacen referencia a extents son los mismos para ámbos árboles, los extents que contienen los datos de los archivos se comparten inicialmente, con lo que todo nuevo snapshot comparte todos sus extents de datos y no ocupa prácticamente nada de espacio adicional, solo cuando se modifica un archivo se crea un nuevo extent al que apunta el FS tree que lo haya modificado.

La lista de todos los snapshots y subvolúmenes del SdA se almacena en la raiz de raices, el Root tree. Se almacenan como directorios: literalmente. Cada snapshot o subvolumen tiene un nombre, y en el Root tree se almacena un item de tipo directorio con el nombre e información para encontrar la raiz del FS tree correspondiente.

Mirroring y stripping: regreso al Chunk Tree

El lector sagaz tal vez se haya dado cuenta de hasta ahora no se han mencionado nada sobre la replicación de datos entre varios dispositivos de almacenamiento, ni sobre la capacidad de reescribir, a partir de una réplica, un bloque cuyo checksum erroneo indique corrupción.

Todo se hace en el Chunk tree. Cada item de ese árbol almacenaba equivalencias entre un rango físico de un disco y uno lógico del SdA. Lo que no se mencionó entonces es que cada chunk, además de almacenar información del rango del dispositivo al que quiere representar lógicamente, puede tambien almacenar información sobre más de un dispositivo, e indicar si se quiere que sobre ellos se haga mirroring (copia exacta de los datos) o stripping ("repartir", o dividir los datos del chunk en varios dispositivos).

Esto significa que toda la cuestión de mirroring y stripping se hace a nivel de chunk, cada uno se puede configurar independientemente. Este sistema es muy flexible. Ya dijimos que cada chunk se puede dedicar, por medio del Extent tree, a almacenar solo datos o metadatos. Así es que se pueden configurar los chunks de metadatos con mirroring y los de datos con stripping, por ejemplo. De hecho, esta es la configuración que se utiliza por defecto, se replican los metadatos -esto ocurre incluso dentro de un SdA compuesto por un solo dispositivo- para que las estructuras más importantes del SdA estén salvaguardadas, y los datos se reparten entre varios dispositivos, de haber varios disponibles.

Back references

Esto no tiene nada que ver con B-Trees, pero de todos modos es muy interesante, porque es una característica única de Btrfs. Se trata de una idea extraida de chunkfs, un proyecto creado para resolver la "reparabilidad" de los SdA actuales y que propone una serie de ideas que permitirían crear lo que ellos llaman un SdA "diseñado para ser reparado". Btrfs incorpora buena parte de esas ideas (el nombre "chunk" probablemente derive de chunkfs) , y una de ellas son las "back references", o referencias inversas.

Un ítem de un Fs tree apunta al extent del Extent tree donde se guardan sus datos. Una referencia inversa sería un puntero del extent hacia el ítem del FS tree que lo apuntó. Mantener estas referencias tiene cierto coste, por eso pueden desactivarse, pero aun así se activan por defecto.

Es una información muy preciada que aunque parezca algo paranoica, puede ser muy útil: desde servir para encontrar el ítem que apuntaba a un extent tras descubrirse que éste está corrupto, a poder escanear el disco en busca de extents y poder identificar los que forman parte de un solo archivo fijándose en que los que tienen una misma referencia inversa. Tambien permite reducir el tamaño del SdA, de una forma sencilla, segura y rápida, algo que los SdA tradicionales suelen implementar tarde y mal (por ejemplo, ZFS aun no lo soporta).

Resumiendo...

Se puede sopesar ahora hasta que punto es acertado que el nombre "Btrfs" sea un alias de "B-Tree filesystem". En otros SdA, se crean unas estructuras de datos y se utilizan B-Trees para organizar alguna o algunas de ellas. En Btrfs es al reves, el B-Tree es la estructura de datos fundamental, todas las demás se implementan sobre él. Cada árbol listado en este texto es una especie de instancia del B-Tree modelo.

Toda esta maraña de árboles -más bien jungla- quizás parezca compleja. Incluso podría ser que este texto diera a algunas personas la sensación de que un B-Tree es una estructura demasiado pesada y complicada, y quizás les lleve a pensar que podría haberse ganado en simplicidad no utilizándo tanto árbol excepto en los casos verdaderamente necesarios. Si es así, me temo que mi escritura no es capaz de reflejar la sencillez y limpieza del diseño de Btrfs, en realidad un B-Tree es algo liviano, y es bastante rápido incluso cuando contiene muchos items. Juega a su favor el hecho de que esté preparado para ser escalable en máquinas multicore; diseñar un SdA con las estructuras de datos aptas para ser escalables sería más complicado. La utilización de un B-Tree común que ya ha resuelto esos problemas libra a los programadores de gran parte (pero no todo) ese trabajo.

En cuanto a complejidad, en realidad es sorprendente lo fácil que es comprender todo el diseño a partir de unos pocos conceptos. Una vez que se tienen en la cabeza, cualquiera puede lanzarse a leer gran parte del código y entenderlo sin muchas complicaciones. Hay que hacer notar la limpieza con la que se abstraen ciertos conceptos de otras capas y estructuras. Como comparación, ZFS tambien tiene diferentes niveles bien separados, pero en las estructuras esa diferencia no es tan radical; por ejemplo la estructura encargada de apuntar a un objeto (blockptr_t) contiene el checksum y tres campos de 32+64 bits cada uno en los que se almacena el identificador de dispositivo+desplazamiento de tres copias alternativas, para recurrir a ellas en caso de corrupción. En Btrfs esa información se mantiene separada en el Chunk tree (y una sola vez, no duplicada en cada puntero) y en el Checksum tree , ambos relacionados con los extents del Extent tree por simples rangos de bytes. Podrían añadirse nuevos B-Trees para vaya-a-saber-usted-qué sin que el código ni las estructuras existentes notaran cambio alguno.

En definitiva, Btrfs es un sistema de archivos moderno, con fundaciones muy sólidas y conceptos renovadores que lo harán durar muchos años. Por sus capacidades está muy preparado para sustituir al veterano (pero aun enérgico) Ext4, en cuanto alcance la categoría de estable. Pero tambien sustituirá a reiserfs (v3 o v4), XFS y JFS, lo cual centrará sobre él una mayor atención colectiva de la que Ext4 tiene hoy, que es mucha. En estos momentos su estado de desarrollo podría considerarse como de las últimas versiones alpha; las distros ya empiezan a ofrecer opción experimental en las instalaciones nuevas. Es de suponer que la versión 1.0 vea la luz en la primera parte del año que viene y que pase a usarse como SdA por defecto en las distros a lo largo del 2011.

(Notas: -todo lo referente al Extent Tree y parte del FS Tree han sido revisados desde su redacción original debido a un error conceptual, -se ha eliminado la información sobre la cabecera de cada bloque del btree, no viene mucho a cuento, -se ha simplificado la explicación del B-Tree, -la explicación de los ítems de cada árbol se ha reescrito para ser más visual)

23 de septiembre de 2009

Citas

"I really enjoy arguing, a big part of my life are these occasional flame threads that I love getting into and telling people they are idiots" - Linus Torvalds

17 de septiembre de 2009

ARMándose

En este blog ya he citado más de una vez aquella frase de Linus Torvals que decía que si había una arquitectura con alguna posibilidad de acabar con el predominio de x86, era ARM. Posibilidad remota, remotísima, claro, pero posibilidad. Tambien he enlazado aquí a muchos artículos que hablan sobre la guerra declarada por Intel a esta arquitectura en lo que vienen a ser los netbooks y ese otro sector de dispositivos que pueden ser clasificados de forma vaga como "Cosas-Parecidas-al-iPhone".

Hoy se han publicado en los medios noticias sobre la presentación del Cortex A9 que parecen confirmar que ARM se toma su guerra en serio (de la que ya teníamos noticias por sus propuestas de crear netbooks ARM) y que ha decidido presentar batalla. Y, al parecer, pretende presentarla no solo en netbooks y cosas-parecidas-al-iPhone, sino incluso ¡en servidores! Se referirá, obviamente, a grandes clusters de mini-ordenadores ARM para cálculo científico, clouds, y cosas así.

Y es que los ARM son, a día de hoy, mucho más eficientes que cualquier oferta de Intel, lo cual implica ser superior en rendimiento en cualquier cosa que use baterías (pueden crear una CPU que tenga un consumo idéntico que el del competidor, pero con mejor rendimiento), lo cual es muy comprensible si, como dice en el enlace, el tamaño del Cortex A9 es 1/3 del de un Atom. Para que nos vamos a engañar, esa gente sabe hacer procesadores. Sus características técnicas parecen decentes; Jon Stokes dice que espera que sea "extremadamente competitivo" contra sus rivales de Intel en cuanto a rendimiento/Watio.

No todo es bonito, claro. Uno de los problemas de ARM, si tomamos sus planes imperiales en serio, es que es una plataforma de 32 bits. Eso no le supondrá un gran problema en términos de rendimiento, ARM no es tan mala plataforma de 32 bits como lo eran los x86 (en particular su patética escasez de registros, que según cuentan en ciertos programas obligaba a pasarse porcentajes de tiempo de dos cifras moviendo datos de los registros a la memoria y viceversa para "hacer hueco") pero si que les limita en su supuesta pretensión de atacar en el escritorio y en los servidores, 4GB de RAM no son tan raros hoy. Aunque por otra parte ARM podría sacarse un equivalente al PAE de x86...y sacar versiones de 64-bits, por supuesto.

Otro problema es la falta de soporte de Windows NT. El artículo cita estas palabras de un ejecutivo de ARM: "Hemos estado hablando con Microsoft y ya puede usted imaginarse sobre qué". Claro que nos lo imaginamos: Portar Windows 7 a ARM, un Windows de verdad. Ya dije aquí en el pasado que uno de los problemas de Microsoft hoy es no tener un verdadero port de Windows 7 a ARM para poder usarlo en una Cosa-Parecida-al-iPhone, eso les está dejando en desventaja respecto a Apple y Android/Palm. ¿Estaría dispuesto Microsoft a portar Windows 7 a ARM? ¿Y pedir a sus partners y a todos los desarrolladores Windows que recompilen y se adapten a ese port (o, mejor aun, que usen .NET)? Pues la verdad, no sería raro. ¿No portaron acaso Windows XP, un SO de escritorio, a Itanium? Apostar por la muerte de ARM a manos de Intel parece demasiado prematuro: No se sabe si acabará ocurriendo, si de ocurrir será una aniquilación o un arrinconamiento, y de ocurrir sería algo que tardaría mucho tiempo, del mismo modo que tardó una década y más en acabar con las grandes CPUs RISC propietarias (y no acabó con todas). En ese tiempo, no soportar ARM podría suponer un zarpazo mortal para los de Redmond. Si tuviera que apostar por ello apostaría que si, que se decidirán a portar Windows 7 (o 8, o el que venga) a ARM. Hay que arriesgarse, demonios.

Mientras tanto, pueden usar Linux. No soporta las aplicaciones que la gente quiere, se critica a Linux, pero por otra parte en un Windows portado a ARM tampoco habría montones de aplicaciones, como todas aquellas no soportadas, asi que yo tampoco veo que sea un gran problema. Pero ya sabemos como es de rara la gente...

Pongamos que se alinean los planetas, que Microsoft porta Windows a ARM, que tiene un éxito tremendo en los netbooks -probablemente lo tendrá, teniendo en cuenta que aumenta drásticamente la vida de la batería, algo fundamental en esos trastos-, que tiene cierto éxito en los servidores -clusters baratos y con un consumo ínfimo-, tal vez entonces ARM tendría una remota -remota- posibilidad de ir más allá de todo eso y plantearse la posibilidad de acabar con la dominancia de x86. No creo que ocurra, pero es divertido imaginarlo.