31 de enero de 2009

El recurso anti-recesión de Microsoft: Windows 7

La crisis económica que está sufriendo el mundo está teniendo tambien su efecto en el mundo tecnológico. Microsoft no está siendo una excepción: Las ventas de su división de Clientes, en la que se incluyen los Windows de Escritorio, ha descendido un 8% en el trimestre anterior. Y estamos hablando del trimestre correspondiente a las fiestas navideñas, siempre generosas con el mundillo informático y gadgetiano.

Es obvio que se acercan tiempos duros para Microsoft, algo por otra parte normal teniendo en cuenta la economía actual. Además, está su modelo de negocio basado en licencias: En época de crisis la renovación de equipos y de licencias de software se pospone, a la espera de tiempos más propicios. No es casualidad que, casi simultaneamente con el anuncio de los datos mencionados, hayan anunciado nada menos que 5.000 despidos para reducir costes...

Sin embargo, no de todo se puede culpar a la crisis. Todo el mundo, incluso la propia Microsoft, reconoce que Vista no ha sido precisamente un éxito atronador. Hay muchas empresas que han declarado que van a saltar de XP a Windows 7. Quizás sea por ello que la división de Office, a diferencia de la de Windows, ha mantenido sus resultados: La gente actualiza Office, pero no quiere usar un Windows Vista que ha pasado a la historia como "Windows ME 2". Es bien sabido que debido a ello Microsoft está desarrollado Windows 7 lo más deprisa posible y con la vista en ser, a diferencia de Vista, lo menos disruptivo posible en cuestión de compatibilidad de software y de hardware.

Por ello, no resulta sorprendente enterarse de que van a saltarse la segunda Beta de Windows 7 y pasar directamente a la Release Candidate. Si ya de por si Microsoft tenía prisa por terminar Windows 7 para olvidarse del quebradero de cabeza que ha sido Vista, ahora tienen además la crisis y la disminución de ventas. Asi que, ante las buenas reacciones de todo el mundo respecto a la Beta 1 de Windows 7, se ve que su prioridad es dejarse de mejoras y directamente sacar Windows 7 lo antes posible. Si eso implica saltarse una Beta, se la saltan. La calidad de Windows 7 se resentirá por ello, y más que una nueva versión se trata de un Service Pack para Vista pero, ¿qué importa? La pasta es la pasta.

27 de enero de 2009

En contra de que la UE fuerze a preinstalar Firefox en Windows

Me opongo a la última idea de la UE: Forzar a Microsoft a incluir Firefox en Windows. No es un rumor: Es una posibilidad que cita Microsoft en su último informe trimestral al SEC (informes públicos que el gobierno de EEUU obliga hacer a las empresas para que los inversores puedan saber como va la empresa). Seguramente no llegue a materializarse, pero aun así, no deja de ser una idea estúpida.

Tan estúpida como lo fue el crear un Windows opcional sin Windows Media Player. Su fracaso fue portentoso. Francamente, no entiendo por qué nadie debería poner ninguna objeción a que Microsoft incluya en Windows por defecto lo que le de la santa gana. Ese no es el problema, el problema del WMP y de IE era que no se podían desinstalar. Y eso es lo que se debería haber exigido a Microsoft: Que las versiones europeas de Windows permitieran desinstalar esos componentes. Ni más, ni menos. Mientras se pueda hacer eso, ¿qué importa el resto?

Gracias a la Comisión, no se pudo conseguir desinstalar el WMP, y aparentemente tampoco lo conseguiremos del IE. Cuando se exigió a Microsoft que hiciera versiones alternativas sin WMP instalado por defecto, cometió multitud de errores. En primer lugar, tuvo que permitir que se siguiera vendiendo la versión con WMP, porque había gente -toda Europa- que quería el WMP. En segundo lugar, en esas versiones capadas, al instalar el WMP, no se podía volver desinstalar, con lo cual nos quedamos de nuevo sin poder desinstalar el WMP, a pesar de que técnicamente era posible (tan solo había que restaurar el estado del sistema antes de instalar el WMP). Tercero, esas medidas tan estúpidas e ineficaces ponen en duda el sentido de la existencia de la Comisión y sus futuras decisiones.

A pesar de que Microsoft instala IE por defecto, Firefox no ha tenido grandes problemas para ganar una buena tajada de cuota de mercado. Cierto es que en un entorno verdaderamente competitivo los usuarios de IE serían una aberrante minoría. E Internet evolucionaría más rápidamente. Pero de solventar eso ya se está encargando el libre mercado. Y si no se está solventando más rápidamente es simplemente porque los usuarios no sienten grandes necesidades de dejar IE: a pesar de sus miserias técnicas, en IE se puede ver cualquiera página de la Web 2.0. Todos sabemos que Firefox, Chrome, Safari, son mejores, pero las diferencias no son tan radicales como para requerir el abandono de IE: su desuso tan solo es recomendable.

Quiero el éxito de Firefox, pero lo quiero sin trampas. Para las trampas, ya está Microsoft.

22 de enero de 2009

Citas

"As far as I'm concerned, digital cameras have been more useful than kernel dumps to kernel debugging" - Linus Torvalds

19 de enero de 2009

Los orígenes reales de Btrfs

En la entrada anterior alababa la rápida evolución de Btrfs, habiendo sido presentado en público como algo aun muy incompleto y con 10.500 líneas de código en Junio del 2007. Lo que no me había dado cuenta es que Chris Mason, su autor y principal desarrollador, ha conservado en su repositorio toda la historia del desarrollo desde literalmente el día 1 de la vida del proyecto.

De modo que al ser incluido en el repositorio de Linus, lo que aparece en log de commits no es un gran único commit de 1MB y pico que dice "Esto es Btrfs", sino toda la lista de cientos de commits que ha tenido el proyecto desde sus inicios, antes de que fuera anunciado al gran público. Además, Git conserva la fecha de creación de los commits (es decir, que si un commit fue creado por un programador en su repositorio local tal día de 2006, aunque se incluya posteriormente en otro repositorio la fecha de creación del commit sigue siendo la del 2006), lo cual permite echar un ojo a la fecha real de creación de Btrfs y la evolución de un proyecto como este a través del tiempo. En exclusiva para D'Oh, un pequeño viaje en el tiempo a los orígenes de Btrfs, una mirada rápida a la evolución de un sistema de archivos desde cero hasta que empieza a ser usable

El primer commit se hizo el 26 de Enero de 2007. Eso significa desde ese día hasta hoy han pasado casi exactamente dos años. El código de entonces no era un sistema de archivos, ni tan siquiera era algo que se ejecutaba en el kernel: Era un simple programa de 810 líneas, ejecutado en espacio de usuario, con su main() de toda la vida: ctree.c, una implementación de un B-tree al que se añaden 10 millones de nodos, despues se hacen unas búsquedas y despues se eliminan los nodos. Todo ello en memoria, sin tocar el disco duro para nada. Un ejercicio algorítmico que en principio podría estar destinado a cualquier cosa que necesite usar B-trees.

Exactamente una semana despues, el 2 de Febrero, se añade la capacidad de escribir el B-tree a un archivo, junto a una copia de la implementación del radix-tree del kernel (lib/radix-tree.{c,h}), utilizada en el caché de páginas, que en btrfs se compila, mediante una serie de "hacks", en espacio de usuario, y con el que aparentemente se intenta imitar una gestión de memoria básica, o al menos de las interfaces del kernel que la implementan.

El 20 de Febrero añade lo que parece ser un soporte preliminar de extents. Poco despues añade un mkfs. Posterirmente, algunos programas para ayudar a depurar el código.

El 2 de Marzo añade lo que parece ser el inicio del sistema de Copy-On-Write. El 13, se añade la base que permitirá el sistema de snapshots.

El 15 de Marzo añade el soporte de diferentes tipos de items, y el soporte inicial del tipo de item "directorio" (pero sin una implementación real de directorios), y ese mismo día añade el item "inodo" (pero sin una implementación real de inodos). Esta es una característica que comparte con ZFS y, supongo, con todos los sistemas de archivos basados en Copy-On-Write: En el nivel más profundo del sistema de archivos no existen archivos ni directorios ni metadatos ni inodos ni nada, todo son "objetos" genéricos que se distinguen en el exterior con un "identificador de objeto", identificador que es utilizado como parámetro para ordenarlos en el B-tree. A ese nivel es al que se implementa el mecanismo COW, la gestión de snapshots, de volúmenes, duplicación de datos, etc; gestionando siempre "objetos" abstractos. Despues, cada objeto puede ser de diferentes tipos: un inodo, un directorio, un extent, un bloque con checksums...o cualquier otra cosa. Por lo tanto, el sistema de archivos en si en realidad se implementa encima de esta "capa de gestión de objetos".

(Hasta ahora, todo esto sigue siendo un programa que se ejecuta en espacio de usuario, nada de kernel...como es natural, a medida que se van añadiendo estas cosas van surgiendo tambien cada vez más commits arreglando fallos, o añadiendo cosas menores)

El día 16 de Marzo se añade el principio del sistema de transacciones, el 20 se añade el tipo de item "extent" y "inode map"

El día 21 de Marzo se añade, por fin, el soporte para montar btrfs en el kernel: No llega a dos meses desde la creación de aquel programita simple, ctree.c. Al mismo tiempo que se añade ese soporte, se eliminan miles de líneas de código que se habían copiado del kernel para intentar imitar sus interfaces (radix-tree, etc).

El día siguiente, 22, se añade soporte de readdir() (o sea, de directorios). Poco a poco se van añadiendo las funciones necesarias que necesita el VFS para que un sistema de archivos funcione: El 23 se añade btrfs_create (crear nuevo inodo), btrfs_sync_fs (soporte de sync()), el 25 se añade soporte de la función del VFS unlink y otra llamada "delete_inode", el 26 se añade mkdir, y tambien se añade el primer soporte para escribir y leer archivos. Truncate y rmdir el 27...como se puede comprobar, el sistema de archivos es en realidad una implementación más o menos "sencilla" de las funciones del VFS sobre el "motor de gestión de objetos genéricos".

El 28 de Marzo se añade soporte de checksums para los metadatos, el 29 soporte para comprobarlos. El 4 de Abril, soporte para que los archivos de tamaño menor que un bloque sean incluidos dentro del B-Tree (algo que btrfs hace para que el acceso a archivos pequeños sea veloz). El 6 de Abril, soporte inicial para varios volúmenes, el 10 soporte mejorado de snapshots y soporte de subvolúmenes, el 11 soporte de múltiples dispositivos...con el tiempo se van añadiendo el resto de las cosas básicas que faltan: soporte de enlaces simbólicos y enlaces duros, archivos "sparse"...todo transcurre más o menos despacio hasta el día 12 de Junio, día en el que se añade la licencia GPLv2 a todos los archivos y se anuncia su existencia en público. El resto es historia conocida.

Es interesante ver como un programa de 810 líneas puede convertirse en un sistema de archivos...

15 de enero de 2009

Btrfs 0.17

Lo cual significa que ha habido dos versiones que me he saltado aquí desde la última vez que mencione Btrfs aquí. Un ejemplo de constancia, el mio. La novedad de esta última versión es soporte de compresión transparente, soporte de sistemas de archivos "semilla" (puedes tener un sistema de archivos de solo lectura, y todas las modificaciones que se hagan se harán en otro sistema de archivos diferente, sin tocar el inicial), soporte de fallocate() y muchas mejoras menores, aquí se pueden ver los cambios de las versiones anteriores.

Pero dejando de un lado el aspecto técnico, la principal novedad de esta versión es que ha sido incluido en el repositorio oficial de Linus Torvalds y por lo tanto será parte de Linux 2.6.29...otra novedad es que Chris Mason dice que, salvo fallos gravísimos, no están planeados más cambios en el formato de disco.

En otras palabras: Está empezando a madurar.

Francamente, es muy sorprendente lo rápido que ha evolucionado. Fue anunciado al mundo como una cosa bastante incompleta con 10.500 líneas de código en Junio del 2007. Año y medio despues, tiene 32.634 lineas de código (134 más y hubieran sido exactamente 2^15), y ya es casi totalmente funcional en lo que a equivalencia con Ext4 y demás sistemas de archivos tradicionales se refiere. El plan de desarrollo restante trata de características propias de btrfs/zfs relacionadas con snapshots, subvolúmenes...pero los aspectos básicos de leer, escribir, mmap, directorios, xattrs, etc, están completos. Si fuera estable tal y como está, se podrían ignorar las carencias "excentricas" y usarlo como sustituto de Ext4. Por comparar, Ext4 fue anunciado un año antes, en Junio de 2006, y muchas de sus características ya estaban disponibles previamente como extensiones de Ext3 (de hecho, la discusión sobre crear un Ext4 al margen de Ext3 surgió al solicitar la inclusión de uno de esos parches para la próxima versión estable de Linux de entonces). Por supuesto, btrfs es aun muy inestable, pero aun así ha evolucionado increiblemente rápido en mi opinión...

La carencia fundamental de Btrfs en estos momentos es la gestión de -ENOSPC, es decir, no es capaz de detectar correctamente cuando el sistema de archivos está lleno y no caben más datos. Es tan solo un problema del asignador de bloques, pero es complicado de solucionar en estos sistemas de archivos Copy-On-Write: Como cada vez que se modifica un archivo se hace una copia con los datos nuevos en un sitio vacío del disco, y esa copia se hace mediante delayed allocation, cuando el disco está lleno hay que saber de antemano si esa copia nueva va a tener espacio para poder hacerse. Anticipar esas situaciones es la única falta notable de la que adolece btrfs, y es en la que se están centrando en solucionar.

Curiosamente, y al margen de lo que le falte a btrfs, hasta puede darse una situación ligeramente paradójica: Si el disco duro está lleno pero tu no estás planteandote crear un archivo nuevo sino modificar un solo carácter de uno ya existente, un sistema de archivos tradicional en principio te lo permitiría sin problemas, pues a pesar de no haber espacio libre se reescribe el espacio ya utilizado, pero en un sistema de archivos COW se necesita explicitamente espacio para poder escribir el archivo nuevo (o al menos, un pequeño extent que direccione la parte del archivo modificada, más una copia de los metadatos que apuntan a los extents)

Volviendo a Btrfs, una vez solucionado lo de -ENOSPC y solucionados otros pocos puntos del plan de desarrollo, podrá lanzarse finalmente la versión 1.0.

14 de enero de 2009

QT LGPL: Tambien un cambio del modelo de desarrollo

Hay una cosa que se me ha escapado del anuncio de relicenciamiento de QT bajo la LGPL: En arstechnica hablan tambien de un cambio en el modelo de desarrollo: El repositorio oficial se migrará a Git y, lo más importante, se dejará de requerir la asignación de copyright (necesario antes para que Trolltech pudiera relicenciar QT bajo licencias libres y propietarias al mismo tiempo). Es obvio que pretenden crear una verdadera comunidad de desarrollo.

¿Hay alguien de Sun leyendo este tipo de noticias?

Nokia relicencia QT bajo la LGPL

Esta en todos los sitios de noticias: QT 4.5 será relicenciada bajo la LGPL. Nokia, que compró Trolltech y ha estado colaborando ampliamente en otros proyectos libres (UBIFS, el protocolo Phonet...), está demostrando un apoyo al software libre que va mucho más allá de las apariencias.

Este pequeño cambio supone una revolución para los escritorios libres. Hasta ahora, la licencia libre disponible para usar QT era la GPL. Eso significaba que todos los programas libres construidos sobre QT debían ser compatibles con la GPL. Si querías hacer un programa privativo, , tenías que recurrir a la licencia privativa de QT, que requería pagar una licencia...

Históricamente eso ha empujado a mucha gente, incluidas compañías como Red Hat, a usar Gnome, que está licenciado bajo la LGPL: Una empresa como Red Hat no podía permitirse el lujo de obligar a sus clientes a que las licencias de sus aplicaciones GUI tengan una licencia determinada y tengan que mostrar el código. Del mismo modo que la libc es LGPL y permite crear programas propietarios basados en ello, era para las empresas un requisito permitir lo mismo en entornos GUI...no es ningún secreto que esta es una de las razones principales por las que muchas distros usan Gnome.

Pero siendo QT LGPL, y gracias a que KDE ya licencia sus APIs públicas bajo esa misma licencia, ya podemos tener un entorno QT+KDE completamente LGPL. Esto puede suponer un cambio en los escritorios libres: Las empresas ya no tendrían problema en usar QT y KDE como escritorio por defecto. Se podrá evaluar KDE olvidándose de la licencia y centrándose en su faceta técnica, campo en el que puede presentar batalla sin problemas, especialmente cuando salga KDE 4.2 (o, como algunos lo llaman, KDE 4.0).

12 de enero de 2009

Historias repetidas: El error de no tener un fsck

Una de los objetivos de los creadores de ZFS fue no hacer un fsck para su nuevo sistema de archivos. La justificación oficial: "ZFS no necesita fsck"...es decir, que ZFS ha sido diseñado explicitamente para no necesitar fsck. ¿Se puede decir varios años despues que ha sido una buena decisión no tener un fsck? Para justificar un "no" como respuesta he escrito este post, asi que sigan leyendo...

Una de las características principales de ZFS es que la estructura en el disco del sistema de archivos se mantiene siempre, siempre, siempre válida. Da igual en qué momento quites el cable de la luz al ordenador mientras lo usas: ZFS te garantiza que, escojas el momento que escojas para tirar del cable, la estructura del sistema de archivos será siempre válida. Es técnicamente imposible encontrar un momento en el que sea posible tirar del cable y encontrar algún problema. No se trata de journaling: Un sistema de archivos con journaling si que deja el sistema de archivos en estados inconsistentes, pero deja un "journal" de operaciones no finalizadas que permite reparar esas inconsistencias en pocos segundos. ZFS jamás puede llegar a un estado de inconsistencia, por eso no usa journaling: no lo necesita (y se gana algo de rendimiento con ello).

ZFS consigue que sea así porque los cambios al sistema de archivos se hacen de forma transaccional: Cuando modificas un archivo, a diferencia de un sistema de archivos tradicional, que trata de reescribir los datos antiguos, lo que se hace es escribir el archivo modificado a una parte del disco que no esté siendo utilizada, y una vez que está escrito ese archivo, se modifica de forma atómica el "puntero" que apuntaba al viejo archivo hacia el nuevo. Esa modificación o se lleva a cabo o no, nunca se queda a la mitad, Por eso, escojas el momento que escojas para tirar del cable, el sistema de archivos se quedará apuntando al viejo archivo o al nuevo, pero no habrá inconsistencias. Por eso, jamás se reescriben los bloques utilizados por el archivo viejo, se escriben siempre en un sitio nuevo y vacío (algo que, por cierto, implica fragmentación).

Si unimos esto el checksumming que se mantienen de todas las estructuras de datos del disco y el Raid-Z con autocuración, se entiende por qué se asegura que ZFS "no necesita fsck". En una configuración Raid-Z todo el sistema de archivos está duplicado en más de un sistema de archivos -incluso puede activarse la duplicación dentro de un mismo sistema de archivos-, y si se encuentra un fallo al comprobar el checksum, se sabe que ha ocurrido un error y se corrige con una de las copias. Si por pura paranoia se necesita comprobar si el sistema de archivos está limpio se recurre al scrubbing, es decir, comprobación de todos los checksums.

Gracias a estos sistemas, y a las horripilantes torturas a las que han sometido al código (por lo visto tienen una suite de tests magnífica), los diseñadores de ZFS afirman que "no necesita fsck", era uno de sus propósitos librarse de lo que para ellos es una reliquia innecesaria para un sistema de archivos decente. Los fallos de hardware se detectan gracias al checksum y se solucionan usando una de las copias...los fallos de software se excluyen como posibilidad porque se asumen unos altos estándares de calidad y porque de todos modos, de haber uno, será detectado gracias a los checksums, solucionado rápidamente y suministrado a los canales de actualización de software, lo cual garantiza que a largo plazo se solucionarán todos...los fallos "lógicos" tambien están excluidos por lo mencionado al principio....y las meteduras de pata por parte del usuario no son problema suyo: Conclusión, no se necesita fsck. Pero....

El mundo real es muy perro. Como era de esperar, han aparecido algunos casos de corrupción de sistemas de archivos ZFS. Casos que sin duda serán raros, rarísimos de encontrar, y mucho más de padecer. Pero ahí están.

Y, ¿qué pueden hacer esos usuarios con su sistema de archivos ZFS corrupto?...Nada. No pueden hacer nada: Puesto que los diseñadores de ZFS han llegado a la conclusión de que la corrupción es Algo Que No Puede Ocurrir (tm), al encontrarse con una no tienen ninguna manera de darle solución. La única opción que tiene el usuario es reformatear y usar una copia de seguridad, si fuistes lo suficientemente precavido como para tenerla (que deberías serlo), y si fuistes tan inocente como para usar los snapshots de ZFS como copias de seguridad ya puedes darte por jodido. Como no hay fsck, esos usuarios no pueden reparar sus sistemas de archivos, ni tan siquiera pueden tratar de extraer los datos (que es otra de las funciones del fsck). No se pueden leer los datos, ni tan siquiera los no corruptos, porque ni tan siquiera pueden montar el sistema de archivos. No pueden construir como auxilio de emergencia una herramienta que trate de leer el formato ZFS por la simple razón de que el formato se ha corrompido y la herramienta no podrá leerlo - si no, el sistema de archivos hubiera podido montarlo.

Y aun ignorando estos fallos en configuraciones normales, hay que tener en cuenta que los checksums de ZFS son desactivables, y que aunque es posible activar la replicación de datos en un mismo sistema de archivos mucha gente no lo va a hacer porque reduce la capacidad a la mitad, y por tanto se detectarán los fallos pero al no haber copias no se podrán solucionar...hay configuraciones válidas en las que se puede prescindir de lo que protege a ZFS de no necesitar, teóricamente, un fsck. La conclusión es que el precio de no necesitar fsck, tan solo teóricamente, es, de entrada, reducir a la mitad el espacio de almacenamiento para duplicar todas las estructuras del sistema de archivos. Y aun si las duplicas, como se ha visto, puede pasarte tambien...

Quizás digan algunos que esos son "casos extremos". Si, lo son. La mayoría de la gente no tenía grandes problemas de corrupción ni tan siquiera con FAT en Win9x. En el resto de sistemas de archivo que si tienen fsck la necesidad de utilizarlo es muy remota, solo en "casos extremos". Y aunque ZFS puede tener fallos en "casos extremos", es obvio que los checksums y la duplicación con autocuración reducen en gran medida la posibilidad de que esos casos ocurran. Pero no los eliminan....y cuando ocurren, un usuario esperará siempre un buen fsck que pueda lograr algo.

El título del post menciona a una historia repetida. La historia es la de otro sistema de archivos que, al ser estrenado, los equipos de marketing lo vendieron como un sistema de archivos que "no necesita fsck": al fin y al cabo, los sistemas de archivos con journaling tambien mantienen siempre la consistencia del disco y teóricamente no necesitan fsck. Ese sistema de archivos era XFS. Pero frente a los casos teóricos, se impuso la cruda y dura realidad: A veces, se necesita un fsck. A veces, es imprescindible un fsck. SGI se vió obligada a crear un fsck, y con él, a comerse su propio marketing. Tarde o temprano, Sun tambien se verá obligado a lo mismo. Al fin y al cabo, ¿pondrían ustedes sus datos en manos de un sistema de archivos que, como recurso extremo, solo puede responderte un "vaya, eso no debería haber ocurrido", "vaya, debería haber utilizado la mitad de su espacio de almacenamiento para duplicar todas las estructuras del sistema de archivos"... o en manos de uno que te ofrece un fsck, aunque sea malo?

(Como nota final, señalar que btrfs, la copia de ZFS para Linux, tiene como uno de sus principales objetivos no solamente crear un fsck, sino hacerlo extremadamente potente)

9 de enero de 2009

Modesetting

Si en Linux 2.6.28 vio la luz GEM, el gestor de memoria para GPUs, en 2.6.29 ve la luz "modesetting", es decir, el código encargado de configurar el "modo" (resolución, profundidad del color) de funcionamiento de la tarjeta gráfica.

Aunque a los que no tenemos mucha idea de gráficos nos parece que eso tiene pinta de ser sencillo (especialmente con varias salidas de video y hotplugging de monitores), los que lo han hecho aseguran que es algo tremendamente complicado -era imprescindible, para empezar, que estuviera basado en un gestor de memoria, lo cual obligó a esperar la inclusion de GEM-, razón por la cual se han tardado tantos años en llegar a este punto.

En Linux la situación actual ya era de por si aun más complicada, pues el catastrófico diseño de los gráficos obliga a compartir el mismo hardware entre varios drivers. Eso implica que cuando se pasa de las X a una VT (Control + Alt + F1), las X guardan el estado de la tarjeta, se resetea la tarjeta, y se deja que el driver de la VT (radeonfb, por ejemplo) configure de nuevo la tarjeta de cero. Para volver a las X, el proceso inverso. Por eso hay esa pequeña y molesta pausa, y dependiendo del driver que uses, directamente puede colgarse el sistema si el driver se olvidó de reiniciar alguna cosa. Y al recuperar un sistema suspendido o hibernado, es necesario a veces un programa en espacio de usuario que restablezca el estado de la gráfica. Si ese programa falla, la pantalla se queda en negro...

Con modesetting, todo se centraliza en un solo driver dentro del kernel, y parte de ese código se comparte entre varios drivers. De entrada, eso significa que una barbaridad de código en varias partes del sistema pasa a mejor vida, lo cual implica mayor robustez. La suspensión e hibernación es más sólida. Las X ya no necesitan saber configurar esa parte de la tarjeta gráfica, su labor se centra en dibujar cosas y mandárselas al hardware. Cambiar de las X a las VT y viceversa es prácticamente instantáneo. Pero no acaba la cosa ahí:

[ 12.601149] allocated 1280x1024 fb: 0x007df000, bo ffff88003c4086c0
[ 12.601270] fb0: inteldrmfb frame buffer device
[ 12.601272] registered panic notifier
[ 12.601277] [drm] Initialized i915 1.6.0 20080730 on minor 0

Es decir, el driver -el driver drm, nada que ver con el de fb- te crea un dispositivo framebuffer tradicional pero basado en modesetting y GEM. Y además, te añade un "panic notifier": Es decir, si el kernel se cuelga, te mostrará el panic en la pantalla....aunque estés en las X.

Lo único malo es que la opción del kernel "activar modesetting por defecto" -que es la que activa el fb basado en modesetting- no puede activarse si no tienes unas X con drivers que soporten modesetting para tu gráfica....

8 de enero de 2009

Calendario de eventos de software libre del 2008

Como cada año, LWN hace una magnífica lista de eventos sucedidos durante el 2008 que sucedieron dentro del mundillo de Linux y el software libre. Enlace recomendado.

5 de enero de 2009

¡Predicciones!

Las predicciones son esas cosas que cada año digo que es de estúpidos hacer, pero que acabo haciendo yo tambien por aquello de que puedes hacerte el listo sin que, cuando la realidad aplaste una de ellas, nadie te lo eche en cara, porque ya nadie se acordará de ello.

Es descorazonador y deprimente que no haya acertado ninguna de las que hize el año pasado. He acertado en lo de que Firefox 3 iba a ser un éxito, aunque esa era una apuesta segura. Tambien en parte en lo de Sun y en lo de Vista. He tenido un éxito rotundo en una predicción separada en la que afirmé que a nadie, excepto a cuatro ricachones excéntricos -como Bill Gates-, le iba a dar por instalar un "Surface" de Microsoft en las paredes de su casa, y mantengo esa predicción para el año que viene y para el infinito. En lo demás no he dado ni una, pero eso no va a evitar que empieze a ensuciar el recien estrenado 2009 con nuevas y absurdas predicciones...

  • En general, creo que sera un año menos movido que el anterior: La crisis económica mundial y la reducción de gastos ya presente harán que las empresas recorten gastos, centren sus focos en los productos más rentables y corten la cabeza a los menos rentables, entre los cuales se suelen encontrar los "experimentales".
  • Por esa misma razón, el software propietario verá aumentada su competencia. Los presupuestos se recortaran y por ello las empresas serán más proclives a usar software libre mantenido por ellos mismos allá donde encuentren un programa libre competitivo con los propietarios (ej: OpenOffice).
  • El "Web 2.0", es decir, el modelo de aplicaciones desarrolladas en las "nubes" y ejecutadas en un cliente ligero con navegador verá como se revienta su faceta de vendedor de humo (que es la más conocida) y se centrará allá donde pueda reducir gastos mediante cosas como Exchange Online, es decir, se centrará en hacer dinero. Dejaremos de ver nacer redes sociales como hongos, y se cerrará más de una ya existente.
  • Windows 7 será un gran éxito que recuperara la imagen y liderazgo de Microsoft: Vista ha sido etiquetado para el resto de su existencia como "Windows ME 2", y su largo y anormal periodo de desarrollo de cinco años permitió a Apple y Linux, especialmente al primero, abrirse un hueco considerable en un mercado tan monopolizado. Sin embargo, todos los análisis y opiniones sobre Windows 7 parecen mostrar opiniones muy positivas, y todo indica que será adoptado masivamente por todos aquellos que han pospuesto la adaptación de sus infraestructuras informáticas empresariales y la actualización del ordenador de casa para este sistema operativo. No es que Apple y Linux vayan a dejar de crecer, pero ya no tendrán a su favor el "factor Vista".
  • Apple sacará un nuevo modelo de iPhone, no para sustituir al actual sino para complementarlo. La inclusión de OpenCL de serie en OS X 10.6 verá sus frutos en forma de algunas aplicaciones que utilizen toda esa potencia disponible.
  • Visto lo visto, será el año de Android.
  • Los móviles nuevos serán casi todos copias del iPhone.
  • Los Gnomitas hablarán más y más de Gnome 3.0, pero no concretarán nada.
  • KDE 4 se estabilizará y completará por fin con KDE 4.2 y 4.3.
  • Publicarán E17 y no le importará un carajo a nadie.
  • La renovación del subsistema gráfico de Linux se afianzará, que junto a los drivers libres de ATI, Intel y Vía dejarán en el olvido las historias de horror del pasado.
  • La comunidad Linuxera de Openoffice.org hara un fork completo y definitivo hacia el proyecto go-ooo.org si el proyecto madre no renuncia a seguir controlando a los desarrolladores.