Un desarrollador de Gnome ha hecho un ruido considerable con un post donde se queja de lo que el entiende como un decaimiento de la comunidad de Gnome por una serie de motivos. A riesgo de parecer arrogante, diré que parece que estén empezando a descubrir que la tierra es redonda. Incluso en este blog se habló de lo absurdo que es que en Gnome sigan a lo suyo, haciendo como que Unity es el shell por excelencia de los escritorios basados en Gnome.
Lo que me sorprende es que siga saliendo gente a desmentir todo esto basándose en que a ellos y a otra gente les gusta Gnome 3. No lo pongo en duda, pero que haya gente a la que le gusta Gnome 3 no quita para que haya mucha gente descontenta.
Mucho más me ha sorprendido la afirmación de que GTK sólo tiene a un programador trabajando a tiempo completo, que parece ser él. QT lo ha pasado mal con su compra por Nokia y posterior abandono y conversión en proyecto comunitario, pero sigue teniendo bastante más actividad que GTK (en parte, porque es bastante más que un toolkit gráfico).
28 de julio de 2012
22 de julio de 2012
Las novedades de Linux 3.5
Ya se ha anunciado la versión 3.5 del kernel Linux. Esta versión incluye soporte de checksums de los metadatos en Ext4, "sondas" de rendimiento en programas de espacio de usuario (uprobes), un mecanismo simple para construir sandboxes filtrando llamadas al sistema, un nuevo algoritmo de gestión de la cola de red diseñado para luchar contra el mal de las redes llamado "bufferbloat", soporte para detener y restaurar conexiones TCP, soporte del RFC 5827 ("TCP early retransmit"), soporte para la "suspensión del sistema oportunista" al estilo de Android, conteo de las estadísticas de fallos de E/S en Btrfs, y la capacidad de usar SCSI sobre Firewire y USB. También se han incluido drivers nuevos y muchas otras mejoras y pequeños cambios. La lista completa de cambios, en inglés, puede encontrarse aquí, como siempre.
· Checksums en los metadatos de Ext4: Los sistemas de archivo como ZFS y Btrfs han probado que asegurar la integridad del sistema de archivos mediante checksums es algo que merece la pena. Así que Ext4 ha añadido la capacidad de almacenar checksums para todos los metadatos del sistema de archivos (no cubre los datos, ni tiene capacidades de "auto-curación").
Cualquier sistema de archivos Ext4 puede ser actualizado para aprovechar esta nueva característica utilizando el comando "tune2fs -O metadata_csum", o "mkfs -O metadata_csum" cuando se crea. Una vez que esta característica sea activada, los kernels antiguos que no la soportan sólo podrán montar el archivo en modo de sólo lectura.
Respecto al rendimiento, no es notable en la mayoría de casos comunes, sólo en casos orientados exclusivamente al manejo de metadatos, que son muy poco comunes.
· uprobes ("sondas" en espacio de usuario): uprobes es la contraparte de kprobes en espacio de usuario. Este sistema permite colocar "sondas" en cualquier dirección de memoria de un programa, y coleccionar información para encontrar problemas de rendimiento o para hacer simples mediciones. Estas sondas pueden colocarse dinamicamente en cualquier proceso, no se necesita reiniciar el programa ni modificar los binarios. Las sondas normalmente son gestionadas con herramientas de instrumentación como "perf probe", systemtap o LTTng. Un ejemplo de uso de uprobes con perf podría ser medir el uso de las llamadas a malloc() en la libc:
Se ha colocado una sonda en la dirección de la función malloc. Ahora, vamos a grabar el uso global de malloc en todo el sistema durante un segundo:
$ perf record -e probe_libc:malloc -agR sleep 1
Ahora puedes ver los resultados con la interfaz TUI con el comando "$ perf report", o ver una salida en texto plano en la salida estándar con "$ perf report -g flat --stdio". Si no sabes qué función quieres sondear, puedes conseguir una lista de las funciones sondeables en librerías y ejecutables usando el parámetro -F, por ejemplo: "$ perf probe -F -x /lib64/libc.so.6" o "$ perf probe -F -x /bin/zsh". Se pueden utilizar múltiples sondas y mezclaras con kprobes y con los eventos PMU del hardware o los tracepoints del kernel.
El código de uprobes es uno de los parches que más tiempo lleva fuera del kernel. Se originó a partir de SystemTap, y se ha incluido durante años en los kernels de Red Hat y Fedora.
· Filtrado de llamadas al sistema basado en seccomp: seccomp (alias de "secure computing") es un sistema simple para sandboxear procesos que fue añadido en 2.6.12 y que permite que los procesos puedan cambiar a un estado en el que sólo pueden usar un conjunto de llamadas al sistema muy limitado (exit, sigreturn, y read y write para descriptores de archivo ya abiertos). Seccomp ha sido extendido, y ahora permite construir filtros arbitrarios de llamadas al sistema, lo cual permite implementar diferentes tipos de mecanismos de seguridad. Por ejemplo, el navegador Chromium soporta esta característica para ejecutar plugins en una sandbox.
El demonio de inicio de sistema SystemD ha añadido soporte para esta característica. Un archivo de una unidad puede usar SystemCallFilter para especificar una lista de las únicas llamadas al sistema que podrán ser utilizadas, por ejemplo:
· Lucha contra el bufferbloat: gestion de cola CoDel: CoDel (alias de "controlled delay") es un algoritmo de gestión de cola de red que ha sido diseñado para luchar contra los problemas de exceso de buffering a lo largo de toda una ruta de red, problemas conocidos como "bufferbloat". De acuerdo con Jim Gettys, que fue quien acuñó ese término, "este trabajo es la culminación de tres intentos para resolver los problemas de los algoritmos de gestión de colas durante los últimos 14 años".
· Reparación de conexiones TCP: Como parte de los esfuerzos para implementar el checkpointing/restauración de procesos, Linux añade soporte para parar una conexión TCP y reiniciarla en otro host. Las implementaciones de virtualización ligera de contenedores usan esto para migrar toda una conexión de un host a otro de forma transparente, sin que lo note la otra parte de la conexión. Esto se consigue poniendo al socket en un modo de "reparación" que permite conseguir la información necesaria para restaurar ese estado en un socket nuevo.
· TCP Early Retransmit (RFC 5827): Esta funcionalidad permite activar la "retransmisión rápida" de paquetes en ciertas condiciones, para reducir el número de ACKs duplicados. En otras palabras, las conexiones se recuperan de paquetes perdidos antes, lo cual mejora la latencia.
· Suspensión oportunista del sistema al estilo Android: El problema más controvertido en la inclusión de código de Android en Linux es la funcionalidad llamada "suspend blockers" o "wakelocks". Son parte de una aproximación a la gestión de energía consistente en suspender el sistema lo más posible. El estado natural del sistema es la suspensión, utilizando energía sólo para refrescar la memoria y para poder volver a despertar de nuevo. El sistema sólo se activa de verdad cuando tiene trabajo que hacer, y en cuanto termina, vuelve a suspenderse.
Esta es una buena idea, pero a los desarrolladores del kernel no les gustó la implementación de Android (se puede encontrar un análisis técnico del problema aquí). Ha habido muchos flames, y poco progreso, lo cual es un gran problema porque los drivers de Android usan las APIs de los "suspend blockers", y la ausencia de dichas APIs hacía imposible incluir el código en Linux. Pero en esta versión, el kernel incorpora una funcionalidad similar llamada "autosleep y wake locks". Se espera que pueda servir a Android y que la inclusión de drivers de él se acelere.
· Estadísticas de fallos de E/S en Btrfs y mejoras de latencia: Se ha añadido soporte para la recolección de estadísticas de fallos de E/S en Btrfs para cada unidad. El comando de Btrfs para recabar esa información, que será incluido en futuras versiones de btrfs-progs, es "btrfs device stats".
Esta versión de Btrfs también incluye cambios que hacen que Btrfs sea mucho más amigable con el reclamado de memoria, y reduce bastante las latencias para E/S síncrono.
· SCSI sobre Firewire y USB: Esta versión incluye un driver que permite usar una conexión Firewire como transporte SCSI. Esto permite exponer dispositivos SCSI a otros nodos en el bus Firewire: por ejemplo, discos duros. Es una funcionalidad similar al Target Disk mode de los ordenadores Apple.
Esta versión también incluye un driver usb-gadget que hace lo mismo con USB. El driver soporta dos protocoloes USB: BBB/BOT (Bulk Only Transport) y UAS (USB Attached SCSI).
Y eso es todo. La lista completa de cambios en inglés, aquí.
· Checksums en los metadatos de Ext4: Los sistemas de archivo como ZFS y Btrfs han probado que asegurar la integridad del sistema de archivos mediante checksums es algo que merece la pena. Así que Ext4 ha añadido la capacidad de almacenar checksums para todos los metadatos del sistema de archivos (no cubre los datos, ni tiene capacidades de "auto-curación").
Cualquier sistema de archivos Ext4 puede ser actualizado para aprovechar esta nueva característica utilizando el comando "tune2fs -O metadata_csum", o "mkfs -O metadata_csum" cuando se crea. Una vez que esta característica sea activada, los kernels antiguos que no la soportan sólo podrán montar el archivo en modo de sólo lectura.
Respecto al rendimiento, no es notable en la mayoría de casos comunes, sólo en casos orientados exclusivamente al manejo de metadatos, que son muy poco comunes.
· uprobes ("sondas" en espacio de usuario): uprobes es la contraparte de kprobes en espacio de usuario. Este sistema permite colocar "sondas" en cualquier dirección de memoria de un programa, y coleccionar información para encontrar problemas de rendimiento o para hacer simples mediciones. Estas sondas pueden colocarse dinamicamente en cualquier proceso, no se necesita reiniciar el programa ni modificar los binarios. Las sondas normalmente son gestionadas con herramientas de instrumentación como "perf probe", systemtap o LTTng. Un ejemplo de uso de uprobes con perf podría ser medir el uso de las llamadas a malloc() en la libc:
$ perf probe -x /lib64/libc.so.6 malloc Added new event: probe_libc:malloc (on 0x7eac0)
Se ha colocado una sonda en la dirección de la función malloc. Ahora, vamos a grabar el uso global de malloc en todo el sistema durante un segundo:
$ perf record -e probe_libc:malloc -agR sleep 1
Ahora puedes ver los resultados con la interfaz TUI con el comando "$ perf report", o ver una salida en texto plano en la salida estándar con "$ perf report -g flat --stdio". Si no sabes qué función quieres sondear, puedes conseguir una lista de las funciones sondeables en librerías y ejecutables usando el parámetro -F, por ejemplo: "$ perf probe -F -x /lib64/libc.so.6" o "$ perf probe -F -x /bin/zsh". Se pueden utilizar múltiples sondas y mezclaras con kprobes y con los eventos PMU del hardware o los tracepoints del kernel.
El código de uprobes es uno de los parches que más tiempo lleva fuera del kernel. Se originó a partir de SystemTap, y se ha incluido durante años en los kernels de Red Hat y Fedora.
· Filtrado de llamadas al sistema basado en seccomp: seccomp (alias de "secure computing") es un sistema simple para sandboxear procesos que fue añadido en 2.6.12 y que permite que los procesos puedan cambiar a un estado en el que sólo pueden usar un conjunto de llamadas al sistema muy limitado (exit, sigreturn, y read y write para descriptores de archivo ya abiertos). Seccomp ha sido extendido, y ahora permite construir filtros arbitrarios de llamadas al sistema, lo cual permite implementar diferentes tipos de mecanismos de seguridad. Por ejemplo, el navegador Chromium soporta esta característica para ejecutar plugins en una sandbox.
El demonio de inicio de sistema SystemD ha añadido soporte para esta característica. Un archivo de una unidad puede usar SystemCallFilter para especificar una lista de las únicas llamadas al sistema que podrán ser utilizadas, por ejemplo:
[Service] ExecStart=/bin/echo "I am in a sandbox" SystemCallFilter=brk mmap access open fstat close read fstat mprotect arch_prctl munmap write
· Lucha contra el bufferbloat: gestion de cola CoDel: CoDel (alias de "controlled delay") es un algoritmo de gestión de cola de red que ha sido diseñado para luchar contra los problemas de exceso de buffering a lo largo de toda una ruta de red, problemas conocidos como "bufferbloat". De acuerdo con Jim Gettys, que fue quien acuñó ese término, "este trabajo es la culminación de tres intentos para resolver los problemas de los algoritmos de gestión de colas durante los últimos 14 años".
· Reparación de conexiones TCP: Como parte de los esfuerzos para implementar el checkpointing/restauración de procesos, Linux añade soporte para parar una conexión TCP y reiniciarla en otro host. Las implementaciones de virtualización ligera de contenedores usan esto para migrar toda una conexión de un host a otro de forma transparente, sin que lo note la otra parte de la conexión. Esto se consigue poniendo al socket en un modo de "reparación" que permite conseguir la información necesaria para restaurar ese estado en un socket nuevo.
· TCP Early Retransmit (RFC 5827): Esta funcionalidad permite activar la "retransmisión rápida" de paquetes en ciertas condiciones, para reducir el número de ACKs duplicados. En otras palabras, las conexiones se recuperan de paquetes perdidos antes, lo cual mejora la latencia.
· Suspensión oportunista del sistema al estilo Android: El problema más controvertido en la inclusión de código de Android en Linux es la funcionalidad llamada "suspend blockers" o "wakelocks". Son parte de una aproximación a la gestión de energía consistente en suspender el sistema lo más posible. El estado natural del sistema es la suspensión, utilizando energía sólo para refrescar la memoria y para poder volver a despertar de nuevo. El sistema sólo se activa de verdad cuando tiene trabajo que hacer, y en cuanto termina, vuelve a suspenderse.
Esta es una buena idea, pero a los desarrolladores del kernel no les gustó la implementación de Android (se puede encontrar un análisis técnico del problema aquí). Ha habido muchos flames, y poco progreso, lo cual es un gran problema porque los drivers de Android usan las APIs de los "suspend blockers", y la ausencia de dichas APIs hacía imposible incluir el código en Linux. Pero en esta versión, el kernel incorpora una funcionalidad similar llamada "autosleep y wake locks". Se espera que pueda servir a Android y que la inclusión de drivers de él se acelere.
· Estadísticas de fallos de E/S en Btrfs y mejoras de latencia: Se ha añadido soporte para la recolección de estadísticas de fallos de E/S en Btrfs para cada unidad. El comando de Btrfs para recabar esa información, que será incluido en futuras versiones de btrfs-progs, es "btrfs device stats".
Esta versión de Btrfs también incluye cambios que hacen que Btrfs sea mucho más amigable con el reclamado de memoria, y reduce bastante las latencias para E/S síncrono.
· SCSI sobre Firewire y USB: Esta versión incluye un driver que permite usar una conexión Firewire como transporte SCSI. Esto permite exponer dispositivos SCSI a otros nodos en el bus Firewire: por ejemplo, discos duros. Es una funcionalidad similar al Target Disk mode de los ordenadores Apple.
Esta versión también incluye un driver usb-gadget que hace lo mismo con USB. El driver soporta dos protocoloes USB: BBB/BOT (Bulk Only Transport) y UAS (USB Attached SCSI).
Y eso es todo. La lista completa de cambios en inglés, aquí.
21 de julio de 2012
Steam y Mesa
Creo que soy una de las pocas personas del mundo Linux que no se ha emocionado demasiado tras anunciarse que Valve va a portar Steam a Linux. Aparte de algunas excepciones en Flash, los videojuegos no me atraen demasiado. Aunque desde luego es una gran noticia, los juegos son una de las últimas grandes funcionalidades genéricas que fuerza a mucha gente que empieza a usar Linux a rearrancar de vez en cuando Windows.
Sin embargo, saber que la gente de Valve se está reuniendo con programadores de Intel para mejorar aspectos concretos de sus drivers o de Mesa me ha parecido tremendamente importante, quizás porque además de a Steam, beneficiará enormemente al resto del ecosistema.
Y es que Linux sigue teniendo grandes problemas con la calidad de su implementación de OpenGL en Mesa. El estado actual no es nada envidiable: OpenGL 3.0 está, por fin, soportado en los drivers más importantes, pero se ha tardado una barbaridad. Para la 3.1 aun tienen que implementar el soporte de GSGL 1.40. De las versiones 4.x, prácticamente no se soporta nada. Bien es cierto que a Valve no le interesan tanto las últimas versiones, sino el soporte de calidad de las versiones más extendidas (la versión de "Left 4 Dead 2" para OS X usa OpenGL 3, es más, OS X tampoco soporta la versión 4), pero es que la calidad de la implementación de OpenGL 3 en los drivers abiertos, particularmente los Intel y AMD, también deja que desear, a pesar de que 3.0 es un estándar de hace cuatro años y a estas alturas la implementación debería estar bien madura.
¿Por qué Linux no tiene una implementación OpenGL de más calidad? Parte del problema está en la carencia de un ecosistema de juegos saludable, que deja a los programadores gráficos en minoría. Ante los problemas de calidad de Mesa suelen optar por atajar los problemas por la vía de las listas negras de hardware o directamente no utilizar las funciones avanzadas que causan problemas y conformarse con menos (véase: compositores de escritorio), o ignorar el hardware mal soportado, o directamente no soportar Linux. Los problemas se evitan en lugar de enfrentarse, los desarrolladores de drivers no tienen presiones para resolverlos, y todo el mundo se adapta y se siente más o menos cómodo dentro de esta mediocridad.
Lo bueno de la llegada de Steam es que se centran en algo muy concreto, en "Left 4 Dead 2", es decir, tratan de optimizar un caso de uso real, no un mero estándar de papel. Gracias a la colaboración con Intel, los programadores de los controladores tienen acceso al código fuente del juego, ven exactamente lo que ocurre, y pueden optimizar el driver para lo que realmente importa e implementar las cosas que verdaderamente son necesarias. Dado que la versión de Linux de Steam va a tener popularidad, la demanda de buen rendimiento para Left 4 Dead 2 se va a convertir en la prioridad principal para todos los desarrolladores de Mesa y de todos los drivers. Tal vez esto sea lo que Linux necesita para tener, por fin, buen rendimiento gráfico. Y claro, esto beneficiará a los compositores de escritorio y a toolkits como QT/QML (que es lo que a mi me interesa).
Sin embargo, saber que la gente de Valve se está reuniendo con programadores de Intel para mejorar aspectos concretos de sus drivers o de Mesa me ha parecido tremendamente importante, quizás porque además de a Steam, beneficiará enormemente al resto del ecosistema.
Y es que Linux sigue teniendo grandes problemas con la calidad de su implementación de OpenGL en Mesa. El estado actual no es nada envidiable: OpenGL 3.0 está, por fin, soportado en los drivers más importantes, pero se ha tardado una barbaridad. Para la 3.1 aun tienen que implementar el soporte de GSGL 1.40. De las versiones 4.x, prácticamente no se soporta nada. Bien es cierto que a Valve no le interesan tanto las últimas versiones, sino el soporte de calidad de las versiones más extendidas (la versión de "Left 4 Dead 2" para OS X usa OpenGL 3, es más, OS X tampoco soporta la versión 4), pero es que la calidad de la implementación de OpenGL 3 en los drivers abiertos, particularmente los Intel y AMD, también deja que desear, a pesar de que 3.0 es un estándar de hace cuatro años y a estas alturas la implementación debería estar bien madura.
¿Por qué Linux no tiene una implementación OpenGL de más calidad? Parte del problema está en la carencia de un ecosistema de juegos saludable, que deja a los programadores gráficos en minoría. Ante los problemas de calidad de Mesa suelen optar por atajar los problemas por la vía de las listas negras de hardware o directamente no utilizar las funciones avanzadas que causan problemas y conformarse con menos (véase: compositores de escritorio), o ignorar el hardware mal soportado, o directamente no soportar Linux. Los problemas se evitan en lugar de enfrentarse, los desarrolladores de drivers no tienen presiones para resolverlos, y todo el mundo se adapta y se siente más o menos cómodo dentro de esta mediocridad.
Lo bueno de la llegada de Steam es que se centran en algo muy concreto, en "Left 4 Dead 2", es decir, tratan de optimizar un caso de uso real, no un mero estándar de papel. Gracias a la colaboración con Intel, los programadores de los controladores tienen acceso al código fuente del juego, ven exactamente lo que ocurre, y pueden optimizar el driver para lo que realmente importa e implementar las cosas que verdaderamente son necesarias. Dado que la versión de Linux de Steam va a tener popularidad, la demanda de buen rendimiento para Left 4 Dead 2 se va a convertir en la prioridad principal para todos los desarrolladores de Mesa y de todos los drivers. Tal vez esto sea lo que Linux necesita para tener, por fin, buen rendimiento gráfico. Y claro, esto beneficiará a los compositores de escritorio y a toolkits como QT/QML (que es lo que a mi me interesa).
Suscribirse a:
Entradas (Atom)