Las novedades de Linux 3.18

Ya se ha anunciado la versión 3.18 de Linux. Esta versión añade soporte para overlayfs, que permite combinar dos sistemas de archivos en un sólo punto de montaje, se añade soporte para mapear memoria de espacio de usuario en la memoria de vídeo en los drivers Radeon, se añade una llamada de sistema bpf() que permite la ejecución de programas en bytecode al estilo de BPF; se añade también un algoritmo de congestión de tráfico TCP optimizado para centros de datos, un protocolo de encapsulado optimizado para virtualización, soporte para incrustar protocolos IP en paquetes UDP, y soporte de la capa de bloques multi-cola en la implementación SCSI. 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.


· Overlayfs
El sistema de archivos overlayfs permite combinar dos sistemas de archivos, uno "superior" y otro "inferior", en un sólo punto de montaje. Las modificaciones a ese sistema de archivos mezclado se hacen en el sistema de archivos superior. Este sistema tiene muchos usos, pero es conocido sobre todo por ser utilizado en los live-CD, en los que se monta una imagen del sistema operativo como sistema de archivos inferior, y un sistema de archivos en RAM, en el que se hacen las modificaciones, como superior; de ese modo se puede utilizar el live-CD como un sistema real. Overlayfs se diferencia de otros mecanismos de unión de sistemas de archivos en que tras abrirse un archivo todas las operaciones van a los sistemas de archivos inferiores o superiores, lo cual simplifica la implementación y permite tener rendimiento nativo.

Es posible que ambos arboles de directorio estén en el mismo sistema de archivos. El sistema de archivos inferior puede ser cualquier sistema de archivos soportado por Linux y no necesita permisos de escritura. El sistema de archivos inferior puede ser otro overlayfs. El sistema superior será normalmente escribible y si lo es debe permitir la creación de atributos extendidos trusted.*, y debe retornar un d_type válido en readdir(), de modo que NFS no está permitido.

· Radeon: mapeado de espacio de usuario en la memoria de vídeo
Linux 3.16 añadió la posibilidad de mapear direcciones de espacio de usuario en la memoria de vídeo para chips Intel. En esta versión, también se ha incorporado en el driver Radeon soporte de esta característica, que permite utilizar datos de la aplicación como fuente para texturas o incluso como destinación de un proceso de renderizado (dependiendo de las capacidades del chipset). Esto tiene usos útiles, tales como descargas de memoria a la GPU sin copias y mejoras de rendimiento en varios casos. Esta capacidad tiene consecuencias extensas, desde renderizado por software más veloz (chromium) o mitigación de pausas en ciertos casos en firefox.

· Llamada al sistema bpf() para programas de máquina virtual eBPF

La llamada al sistema bpf() es un multiplexador para una serie de operaciones en eBPF que pueden ser descritas como "máquina virtual universal en el kernel". eBPF es similar al Berkeley Packet Filter que se usa para filtrar paquetes de red. eBPF "extiende" el BPF clásico de múltiples maneras incluyendo la capacidad de hacer llamadas a funciones de ayuda en el kernel y acceso a estructuras de datos compartidas. Los programas pueden ser escritos en un C restringido que se compila a bytecode eBPF y se ejecuta en la máquina virtual eBPF o se convierte en instrucciones nativas con un JIT.

Los programas eBPF son similares a módulos de kernel. Los carga un proceso de usuario y se descargan automáticamente cuando el proceso sale. Cada programa eBPF es un conjunto de instrucciones seguro. El verificador eBPF determina estáticamente que el programa termina y es seguro de ejecutar. Los programas pueden estar conectados a diferentes eventos. Estos eventos pueden ser paquetes o eventos de trazado. Más allá de almacenar datos los programas pueden llamar a funciones de ayuda del kernel que podrían, por ejemplo, volcar la pila, invocar trace_printk u otras ayudas para la depuración del kernel.

· TCP: algoritmo de congestión Data Center TCP
Esta versión añade el algoritmo de control de congestión Data Center TCP (DCTCP). Se trata de un algoritmo diseñado para optimizar el rendimiento de las redes de centros de datos, centrándose en proporcionar: alta resistencia a las ráfagas de tráfico alto, baja latencia y alto rendimiento.

· Geneve: Protocolo de encapsulación para virtualización
El advenimiento de las redes virtualizadas ha provocado un aumento del interés y de la creación de nuevos protocolos. Los protocolos de túneles existentes han intentado resolver diferentes aspectos de los nuevos requerimientos de las redes virtualizadas, pero pronto quedaban desfasados. Linux 3.18 añade Geneve, un protocolo que intenta evitar esos problemas proporcionando un protocolo para túneles que proporciona redes de nivel 2 sobre redes de nivel 3.

· Mejora del rendimiento de red: agrupación del procesamiento de la cola de envío
Esta versión añade soporte para retrasar el procesado de SKBs (buffers de sockets). Procesar la cola de envíos del driver de la tarjeta de red es costoso, de modo que es posible compartir ese coste acumulando varios búfers y procesándolos al mismo tiempo. Varios drivers han incorporado esta característica: i40e, igb, ixgbe, mlx4, virtio_net, se añadirán más en futuras versiones.

· Soporte para foo-sobre-UDP
Esta versión añade soporte para encapsular cualquier protocolo IP sobre UDP incluyendo túneles (IPIP, GRE, SIT).

La motivación para esta funcionalidad es que el hardware y software de red existente están optimizados para UDP y pueden utilizarse para proporcionar un mejor servicio. En esta versión se ha añadido soporte para usar foo-sobre-UDP en GRE, IPIP, y SIT. Se ha añadido un nuevo comando "ip fou" en las nuevas versiones de ip para usar esta característica.

· Soporte de SCSI multicola opcional
Linux 3.13 añadió un nuevo diseño para la capa de bloques que permitía procesar múltiples colas IOs en paralelo. Esta característica, sin embargo, no era transparente y requería adaptación de los drivers. En esta versión, se ha añadido soporte para esta capa multi-cola en la capa SCSI (usada por los drives ATA y SATA) como una opción

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

Android 5, una versión para olvidar las anteriores

Ayer flaseé Android 5.0 a mi Nexus 4 -un modelo que ya tiene dos años-, y he podido comprobar como todas las cosas buenas que se dicen sobre esta nueva versión son ciertas. La interfaz es mejor, el uso ingente de animaciones por doquier no me resulta molesto porque se utilizan para explicar visualmente las transiciones de los elementos de la interfaz, el uso de batería ha mejorado enormemente, y mejorará más a medida que las aplicaciones hagan uso de las nuevas APIs, las notificaciones, runtime ART, etc. Me he topado ya con un par de crashes de aplicaciones del sistema, pero nada que se salga de lo habitual en una version .0.

Lo paradójico de Android 5.0 es que las mejoras son tan buenas, que ponen en evidencia una verdad impopular: Android 4.x era una castaña.

Seguramente muchos hayan leído alguna vez el mote burlesco "lagdroid", referente a la lentitud y falta de respuesta de la interfaz de Android. ¿Cuántas veces han escuchado a fans de Android decir que en esta nueva subversión, en este nuevo teléfono último modelo, el "lag" pasaba a ser historia? Pues no, el lag seguía ahí. Cierto, la respuesta de la interfaz mejoró mucho en las últimas versiones (especialmente con las mejoras de 4.3). Pero no dejó de existir.

La notable mejora de rendimiento del nuevo runtime java ART -que estaba en 4.4, pero sólo opcional en el menú para desarrolladores- es la mejor prueba de que hasta ahora, usar Android era usar un sistema lento. El propio Google cita, como característica de ART en 5.0, una interfaz con mejor respuesta. Y en esta versión se incorpora también un proceso dedicado a hacer las animaciones, para que sean siempre fluidas. Y hay que tener en cuenta que el salto de Dalvik a ART sea tan grande no implica necesariamente que ART tenga un rendimiento sobresaliente. Mientras tanto, los usuarios de iPhone y Windows Phone han disfrutado de una interfaz con buena respuesta desde el primer día.

Lo mismo se puede decir del uso de batería: Las mejoras de 5.0 son brutales (en gran parte, por el cambio a ART), y no responden a un paso adelante respecto a otros sistemas, sino a una puesta al día de Android.

Digo todo esto porque existe un intenso fenómeno de fandroidismo en Internet y un desprecio hacia Apple y a sus productos, que se venden a precio de oro a pesar de ser menos versátiles y menos capaces; y también hacia Windows Phone. Está muy bien usar Android -yo también lo uso-, pero el elitismo fandroidero sobra. Vistos los defectos de anteriores versiones de Android, comprar un iPhone o Windows Phone estaba plenamente justificado, y probablemente lo siga estando en muchas facetas. Aunque gracias a Android 5, eso si, en muchas menos.

Apple Pay, un ejemplo del valor de la integración

El pasado lunes 20 de Octubre empezó a funcionar Apple Pay, el sistema de pagos NFC para el iPhone 6. Es difícil predecir si va a tener éxito en EE.UU., donde Android es, también allí, mayoría; pero hay optimismo. Sin embargo, muchas reacciones en Internet han sido recordar que los pagos NFC ya están inventados, que Google Wallet existe desde 2011, y que si Apple Pay tiene éxito será debido al marketing, ese mago oculto al que Apple parece deber el no estar en la bancarrota. Se equivocan, Apple Pay no sólo es interesante, sino que es un buen ejemplo del estilo de trabajo de integración vertical de Apple.

Hay que empezar diciendo que hay mucha confusión sobre qué son exactamente los pagos móviles vía NFC. Muchos -Apple la primera- se empeñan en describirlo como algo de ciencia ficción, vanguardia tecnológica que casi debería hacernos llorar de emoción al usarla. Hay que dejarse de tanto humo: esto no es más que pagar las cosas, pero de otra manera. Pagar cosas no es emocionante, y no lo será nunca. En rigor, Apple Pay no es más que una manera de automatizar el uso de tarjetas de crédito, y el grandioso progreso que puede traer a la vida diaria es el de no cargar en el bolsillo con tarjetitas de plástico y/o dinero en efectivo: algo más bien poco importante. Los pagos NFC son una mejora marginal, una pequeña comodidad añadida, no una revolución.

Respecto a la fama de inventor, puede que los pagos NFC ya estén inventados, pero aparte del este asiático y otros países anecdóticos, apenas están extendidos, y desde luego estamos lejísimos de ver un país en el que una generación de niños crezca sin saber qué es una moneda. EE.UU., el imperio del consumo, no es una excepción. Quien popularice el uso de pagos telefónicos vía NFC será considerado allí como su inventor, guste o no.

Yendo al grano: ¿Qué tiene Apple Pay de interesante? Lo que más destaca es su seguridad y anonimato. En el mundo actual las empresas hay robos de millones de tarjetas que pueden usarse para fraude (especialmente en EE.UU., donde aun usan tarjetas de banda magnética). Para solucionar ese y otros problemas Apple Pay usa algo llamado "tokenización" (que también utiliza Google Wallet). Al activar una tarjeta, la red de tarjetas genera un número aleatorio, el "token". Este token se utiliza como identificador para hacer transacciones en lugar del número de tarjeta, evitando que las empresas tengan los números de tarjeta de sus clientes, e impidiendo así que alguien pueda robarlos y cargar gastos a la tarjeta.

Naturalmente, la mejora no está tan sólo en cambiar un número de tarjeta por uno de token, de ser así los atacantes pasarían a cargar pagos al token. La mejora está en que no es posible hacer una transacción sólo con el token, es necesario también un código específico llamado criptograma. Este criptograma, que posteriormente es cifrado con claves públicas proporcionadas por la red de pagos, incluye varios datos, entre ellos uno que identifique al dispositivo que usa el token. Pero además, cada criptograma sólo es válido para una transacción. El objetivo es que cada token sólo pueda usarse con una tarjeta determinada y con un dispositivo determinado para una transacción determinada. Los ataques a las bases de datos de las empresas pasan a ser inútiles, los datos extraídos de ahí no valen para nada, la única manera de cargar pagos ilícitos es atacar el teléfono de los usuarios e intentar conseguir el token y las claves asociadas, que ya de por si no es fácil. Atacar a millones de usuarios pasará a ser prácticamente imposible.

La implementación de todo este sistema en el iPhone se hace en gran medida en dos chips de hardware, uno de ellos el Secure Element, un chip para hacer pagos seguros utilizado en muchos dispositivos, como sensores NFC. Este chip almacena la información del token de las tarjetas de crédito y las claves de las redes de pago. El otro chip es el Security Enclave, específico de Apple (y que curiosamente funciona con un microkernel L4), dedicado a almacenar y procesar información crítica, como la identificación de las huellas dactilares de Touch ID. El encargado de hacer la transacción, a través del sensor NFC, es el Secure Element, pero sólo permite hacer pagos si lo confirma el Security Enclave, algo que hace tras comprobar que la huella dactilar del Touch ID se corresponde con las que tiene almacenadas. Todo el proceso del pago se hace por hardware, la CPU del iPhone jamás procesa datos sobre tokens o claves de ningún tipo, lo cual dificulta conseguir esos datos fácilmente mediante vulnerabilidades en iOS (el Secure Element no se puede acceder directamente).

¿Dónde están las ventajas sobre Google Wallet? Una de las más importantes es que muchas multinacionales de telecomunicaciones han vetado el chip Secure Element de los teléfonos que venden: quieren que el chip esté en la tarjeta SIM y así abusar de su posición para crear sus propias plataformas de pagos y controlar el sector . Esto no es culpa de Google, pero es consecuencia del modelo de Android, y Google Wallet se ha visto obligado a incorporar una implementación de un Secure Element virtual por software que puede conectarse a un Secure Element "real" que está en la nube de Google Wallet. Este ha sido uno de los principales obstáculos de Google Wallet. Apple, en cambio, controla su hardware, así que añade un chip Secure Element y punto, sin que nadie rechiste.

Aparte de esto, ¿dónde están la ventaja de Apple Pay? ¿No tiene Google Wallet también tokenización? Si, pero Apple Pay tiene aquí otra ventaja: la privacidad. En Apple Pay el número de tarjeta de crédito o los detalles completos de la transacción no están disponibles ni en el iPhone ni en los servidores de Apple Pay, ni se utilizan en ningún momento a lo largo de una transacción, ni Apple sabe ni puede saber nada de lo que compras en ningún momento. Con Google Wallet, Google tiene acceso a tus números de tus tarjetas de crédito -puedes verlas en la web- y a todas tus transacciones: datos que Google accederá sin complejos para personalizar anuncios. A grandes rasgos, Apple Pay sólo es un wrapper del sistema financiero actual, proporciona lo necesario para que las tarjetas de crédito hagan pagos NFC, pero más allá de facilitar el pago no se mete ni mete las narices. Google Wallet en cambio intenta ser un intermediario, gestionando los pagos por si mismo. Incluso te proporciona una tarjeta virtual creada por la misma Google, a la que puedes cargar pagos que posteriormente sean cargados a tus tarjetas reales. ¡Incluso puedes tener un balance en tu cuenta de Google Wallet y almacenar dinero, prácticamente equivalente a una pequeña cuenta de banco!

Estos últimos detalles no son irrelevantes y no tienen sólo que ver con la privacidad. La consecuencia del modelo elegido por Google es que los bancos y las redes de tarjetas no tienen grandes incentivos para apoyarlo, cuando no a verlo como un competidor directo. No ha habido grandes bancos asociados a Google Wallet, ninguno está desesperado por su falta de popularización.

Apple ha sabido comprender que el sistema financiero sólo aceptaría una solución para pagos con teléfono móvil que les incluya, y no pretenda quitarles del medio o ignorarles. Visa ha tenido alrededor de mil personas trabajando en Apple Pay y en la adaptación al modelo de tokenización, y el banco JPMorgan 300. Es más, las redes de tarjetas y los bancos de EE.UU están poniendo anuncios en la televisión para animar a la gente a usar Apple Pay con ellos. Literalmente, están haciendo publicidad, ¡gratis!, a Apple, y además están facilitando a las empresas la renovación de terminales de pago que incluyan soporte NFC.

En resumidas cuentas, Apple Pay parece haber atajado el importantísimo problema circular que tienen los pagos NFC: no pueden usarse masivamente por escasez de terminales NFC en el mundo real, y al mismo tiempo hay una escasez de terminales NFC debido a la escasez de gente interesada en usarlo. Han sabido diseñar un buen sistema de pagos y, al mismo tiempo, han sido capaces de colaborar con el sistema financiero y encontrar una solución que haga que la adopción masiva de Apple Pay sea beneficiosa para todas las partes. Todo ello sin dejarse chantajear por las operadoras, tan interesadas en controlar todo lo que circula por sus redes, y con una interfaz sencilla. Digan lo que digan, es un producto bien hecho, y es muy posible que sea el detonante que haga avanzar los pagos NFC, incluso en España. Y entonces la gente dirá que Apple ha inventado los pagos NFC, guste o no.

Las novedades de Linux 3.17

Ya se ha anunciado la versión 3.17 de Linux. Entre las novedades de esta versión se encuentra el soporte para compartir dispositivos USB vía IP, soporte para los controladores de la Xbox One, soporte para el Thunderbolt de Apple, una nueva API que restringe las operaciones en archivos de memoria compartida para hacer la vida más fácil a los desarrolladores, soporte para el traceado de fallos de páginas en perf trace, soporte para que kexec sólo pueda arrancar kernels firmados, y una nueva llamada al sistema getrandom() para una generación de números aleatorios más segura. 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.


· Compartición de dispositivos USB vía IP

USB/IP es un proyecto que proporciona un sistema de compartición de dispositivos USB a través de la red. Para compartir dispositivos USB entre ordenadores con su funcionalidad completa, USB/IP encapsula los mensajes de E/S USB en paquetes TCP/IP. Los controladores y aplicaciones pueden usarse en dispositivos USB remotos sin ninguna modificación, permitiendo usarlos como si fueran dispositivos locales.

Este proyecto ha estado durante mucho tiempo en el área "staging" para código inestable. En esta versión pasa a considerarse estable. Las herramientas de espacio de usuario pueden encontrase en tools/usb/usbip

· 'Sellado de archivos' para facilitar el uso de la memoria compartida

Cuando varios procesos se comunican entre ellos mediante memoria compartida, tienen que ser cuidadosos y sincronizarse, porque cualquier proceso puede modificar los contenidos de la memoria compartida en cualquier momento, o cambiar el tamaño del buffer. Esto hace que la comunicación de procesos mediante memoria compartida sea frágil, requiera mucho cuidado por parte de los programadores, incentive a hacer copias privadas de la memoria compartida, y haga imposible las operaciones zero-copy si no se puede confiar en los procesos con quien se comparte la memoria.

Esta versión incluye el concepto de "sellado de archivos". Los archivos de shmfs podrán ser "sellados" con fcntl(2) para restringir ciertos comportamientos: ampliar o reducir el tamaño del archivo, escribir en él, o aplicar nuevos "sellos"
El sellado permite compartir archivos de shmfs sin ninguna relación de confianza. Esto es reforzado por el hecho de que se rechazan modificaciones de sellados si no se posee una referencia exclusiva al archivo. De modo que si un proceso posee un descriptor de archivo, puede estar seguro de que nadie excepto él puede modificar los sellos de ese archivo. Esto permite mapear archivos compartidos de procesos en los que no se confía sin miedo de que te vayan a truncar el archivo o de que un atacante lo vaya a modificar.

Esta característica tiene muchas utilidades. Un servidor gráfico -Wayland, por ejemplo- podría querer rechazar descriptores de archivos que no tengan el sello SEAL_SHRINK. De ese modo, se garantiza que la memoria estará accesible (mientras al mismo tiempo se permite ampliar el buffer). Otro ejemplo sería la construcción de un sistema de IPC genérico, como dbus. Con los sellados, es posible hacer zero-copy fácilmente compartiendo un descriptor de archivo que tenga los sellos SEAL_SHRINK | SEAL_GROW | SEAL_WRITE. De este modo, la fuente puede almacenar datos en el archivo, sellarlo y entonces pasárselo al destinatario. El destinatario puede verificar que esos sellos están puestos y entonces parsear los datos del archivo directamente, o incluso hacer multicasts del mensaje y permitir a todos los receptores parsear con zero-copy el mismo archivo. Artículo de LWN recomendado: Sealed files, artículo de blog recomendado: memfd_create(2)

· "Render nodes" activado por defecto

"Render nodes" es una característica incluída en Linux 3.12. Permite crear diferentes nodos de dispositivo en /dev para la GPU y para la salida de vídeo, de modo que las aplicaciones puedan usar la GPU directamente para renderizar cosas en la memoria hablando directamente al nodo de dispositivo de la GPU.

Esta característica ha sido considerada experimental desde el principio y sólo podía ser activada con el parámetro "drm.rnodes=1". En esta versión, ha sido activada por defecto. Para más detalles, ver este blog

· Mejora de la gestión energética en más GPUs Radeon

La característica de gestión de energía "dpm" ha sido reactivada por defecto para las GPUs cayman y BTC.


También se ha añadido un nuevo parámetro de módulo (radeon.bapm=1) para permitir la característica (bapm, incluída en la anterior versión de Linux) en las APUs en las que esté desactivada por defecto debido a problemas de estabilidad.

· Soporte de Thunderbolt

Thunderbolt es una interfaz de hardware que combina PCI Express y Displayport en una señal en serie junto con una conexión de corriente continua, todo en un mismo cable. Un conector soporta hasta seis periféricos en diferentes topologías. Co-desarrollado por Intel y Apple, es utilizado sobre todo en dispositivos Apple. En esta versión, se añade soporte para Linux.

· Soporte para los controladores de la Xbox One
Esta versión añade soporte para los controladores de la Xbox One.

·Generación de números aleatorios más segura mediante la llamada al sistema getrandom()
Los sistemas Linux generalmente consiguen sus números alteatorios de /dev/[u]random. Esta interfaz, sin embargo, es vulnerable a ataques de exahustación de descriptores de archivo, en los que el atacante consume todos los descriptores de archivo que puede hasta llegar al límite. Además, es inconveniente para los contenedores. La llamada al sistema getrandom(2), análoga a la getentropy(2) de OpenBSD, solventa esos problemas. Artículo recomendado de LWN: A system call for random numbers: getrandom()

· Soporte para el traceado de fallos de página en perf trace
En esta versión se incluye soporte para tracear los fallos de página en "perf trace"- Utilizando la opción -F/--pf el usuario puede especificar si quiere tracear los eventos de fallos de páginas menores, mayores o todos ellos.

· perf timechart añade un modo de ES

Además de grabar información de eventos sobre el gestor de procesos y la CPU (cambios de tarea, tiempos de ejecución, estados energéticos de la CPU, etc) esta versión añade un modo E/S que hace posible grabar información de actividad de E/S. En este modo, "perf timechart" generará un SVG con gráficos de E/S (lecturas, escrituras, tx, rx, polls).

· Kernels firmados para kexec

Kexec es una característica de Linux que permite ejecutar un kernel desde un kernel Linux ya existente. Se utiliza para el reinicio rápido, o incluso para ejecutar automáticamente un nuevo kernel tras un crash. Sin embargo, los sistemas con  "arranque seguro" UEFI no deberían poder ejecutar sistemas operativos no firmados. Kexec permite ejecutar la protección del "arranque seguro de UEFI" haciendo kexec a un kernel no firmado desde dentro de un kernel firmado. Para solventar ese problema, esta versión incorpora soporte para que los sistemas con "arranque seguro" sólo puedan arrancar con kexec kernels que también estén firmados. Artículo LWN recomendado: Reworking kexec for signatures

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

Las novedades de Linux 3.16

Hace ya más de un mes que Linus Torvalds anunció la versión 3.16 de Linux. Con mucho retraso procedo a resumir las principales novedades de esta versión, entre las que se encuentra la mejora de rendimiento en algunas tarjetas gráficas Nvidia, gracias al soporte para alterar la frecuencia de funcionamiento de la GPU; se añade soporte para mapear memoria de espacio de usuario en la GPU en GPUs Intel; se ha añadido un btree de inodos libres a XFS para mejorar el rendimiento en la asignación de inodos, los kernels de ARM64 pueden ser utilizados como aplicación EFI, se ha añadido soporte de IPv6 a la funcionalidad TCP Fast Open , algunas tarjetas graficas AMD Radeon tiene mejor rendimiento gracias a la mejora de la gestión energética, se ha añadido soporte para las GPUs de Intel Cherryview, y los control groups han añadido un modo de jerarquía unificada. 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.


· Mejoras en el rendimiento gráfico de tarjetas Nvidia, soporte inicial de GK20A y GK110B
Nouveau, el controlador libre para GPUs Nvidia, ha añadido soporte para cambiar la frecuencia de funcionamiento de la GPU. Esta característica (que por ahora tiene que ser activada manualmente) mejora el rendimiento notablemente. Las GPUs Nvidia que soportan esta funcionalidad son las que tienen relojes de tipos nv40, nvaa, y nve0.

Esta versión también añade soporte inicial (pero incompleto) para GPUs Nvidia GK20A, que se encuentran en los SoCs Tegra K1 SoC; y también para los GK110B.


· El driver para GPUs Intel permite mapear memoria de espacio de usuario en la memoria de vídeo
Al permitir mapear direcciones de espacio de usuario en la memoria de video, es posible utilizar datos de la aplicación como fuente para texturas o incluso como destinación de un proceso de renderizado (dependiendo de las capacidades del chipset). Esto tiene usos útiles, tales como descargas de memoria a la GPU sin copias y mejoras de rendimiento en varios casos. Esta capacidad tiene consecuencias extensas, desde renderizado por software más veloz (chromium) o mitigación de pausas en ciertos casos en firefox.

 
· Jerarquía unificada en los control groups
Los control groups permiten crear grupos arbitrarios de procesos y aplicarl restricciones de CPU, disco o memoria a esos procesos. La implementación actual permite crear varias jerarquías y aplicar diferentes restricciones a cada jerarquía. Por varias razones, detalladas en este artículo de LWN (en inglés), esta manera de funcionar no está considerada apropiada, y se ha estado trabajando para migrar hacia una implementación en la que sólo exista una jerarquía. Esta versión incluye por primera vez esta jerarquía unificada para los control groups (opcional por ahora)

· btree de inodos libres en XFS, para mejorar el rendimiento de la asignación de inodos

En esta versión, XFS ha añadido un btree que almacena información sobre los inodos libres. El propósito es mejorar la búsqueda de inodos libres durante la asignación de inodos.

Esta característica no modifica las estructuras de disco existentes, pero añade una nueva que debe permanecer consistente con el btree de inodos asignados; por esta razón kernels anteriores sólo podrán montar sistemas de archivos que soporten esta nueva característica en modo de sólo lectura.

· Permitir arrancar kernels ARM64 como aplicaciones EFI

Esta versión permite arrancar un kernel Linux compilado para ARM64 como una aplicación EFI en sistemas que tengan firmware UEFI, sin que sea necesario un cargador de arranque.

· Soporte de TCP Fast Open con IPv6

TCP Fast Open es una característica de TCP diseñada para que las conexiones TCP sean más rápidas. El primer soporte fue añadido en Linux 3.6 para clientes, en 3.7 se añadió soporte para servidores y en 3.13 Fast Open fue activado por defecto. Esta versión añade soporte de Fast Open en servidores IPv6

· Soporte de gráficos Intel Cherryview

Esta versión añade soporte para GPUs Broadwell que se encuentran en SoCs Cherryview.

· Mejora de rendimiento en APUs AMD Radeon

Se ha implementado para algunas APUs un modo con una mejor gestión energética, "bapm" o "bidirectional application power management". Es una característica que consiste en que la GPU y la CPU comparten el TDP, lo cual permite ofrecer rendimiento extra en la GPU cuando hay margen disponible en la CPU. En esta versión, se ha activado bpam por defecto, pero sólo en unos pocos dispositivos y casos. En el futuro se mejorará el soporte para bapm.

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

X.Org Server 1.16: Ahora empezaba a ponerse interesante

No deja de ser paradójico que, ahora que Wayland se está consolidando, nos vengan con una nueva versión del servidor gráfico de X.org, la 1.16, que incorpora unas novedades que, de no existir Wayland, causarían muchísimo más ruido del que hemos visto.

Me refiero, por supuesto, a la inclusión de Glamor. Se trata de un proyecto con ya unos añitos de edad, consistente en utilizar OpenGL en todas las APIs 2D de X.org. Las ventajas son múltiples: por una parte, se aprovechan las capacidades de aceleración del hardware moderno, por otra, ofrece la oportunidad de consolidar la forma de acelerar esas APIs en una sola solución para todas las GPUs que elimine optimizaciones particulares para cada GPU, y de ese modo establecer una arquitectura de aceleración definitiva que resuelva los problemas de rendimiento de la extensión Render que las anteriores arquitecturas nunca resolvieron del todo.

El problema de Glamor y la razón por la que esto no se hizo antes es que que, como es sabido, las impresionantes capacidades del hardware gráfico moderno no son siempre capaces de implementar con buen rendimiento las tradicionales y aparentemente estúpidas operaciones "2D". Sin embargo, parece ser que a base de trabajo duro (Keith Packard ha escrito bastante sobre ello: 1, 2, 3, 4) han conseguido una solución decente.

Y lo curioso es que un titular como "los gráficos de Linux pasarán a estar completamente acelerados vía OpenGL" hubiese causado sensación hace sólo unos años. Pero hoy la gente está más interesada en Wayland, que ofrece eso y más.

Lo mismo pasa con otra de las novedades: integración con systemd-logind, que no sólo permite a X.org funcionar mejor como servicio de sistema, permite ejecutar el servidor de X.org sin privilegios root.

Esta versión del servidor de X.org es, sin duda, una de las más importantes en mucho tiempo. Pero el hecho de que su otra gran novedad sea la inclusión de XWayland, da una pista de por dónde van los tiros.

Avanzando a golpe de actualizaciones de systemd

El debate frenético que generó la adopción debianera de systemd, seguida de la consecuente adopción ubuntera, ha consumido los flamewars sobre sistemas de inicio. No es que haya desaparecido: el tema sigue viéndose, y se discute -y más que se discutirá-, pero se trata de una discusión aislada y repetitiva, desapegada de los eventos del mundo del software libre, que ya ha pasado página. Systemd ha ganado, y el ruido de la oposición no se ha transformado en proyectos capaces de sustituirlo (y por capaces no me refiero a openrc), , lo cual es un indicativo fiable de que, en realidad, systemd es una mejora bienvenida por la mayoría.

Tenemos, por tanto, un mundo Linux que, en su gran mayoría, usa systemd o lo usará en próximas versiones. Las consecuencias de este cambio son muy importantes y son, de hecho, la que probablemente es la mayor ventaja de systemd, y la menos discutida: la unificación del sistema base de la mayoría de las distros en un mismo proyecto, una utopía soñada que existía literalmente desde el nacimiento de las primeras distros, y que sólo systemd ha logrado materializar.

Y esta es una ventaja que Lennart Poettering tiene toda la intención de utilizar. Sin ningún complejo, hace tiempo que proclama a los cuatro vientos que systemd ya no sólo un sistema de inicio y de gestión de servicios, sino una plataforma, e incluso el pegamento que une a las aplicaciones con el kernel. Casi nada. Entre sus últimas novedades y sus planes de futuro se encuentran un pequeño sustituto de network-manager, de ntpd, una implementación simple de containers, sandboxing de aplicaciones y servicios, gestión de servicios de todas las instancias de un proyecto albergado en la nube o de todos los containers que estén siendo ejecutados en el sistema...características que la práctica totalidad del mundo Linux conseguirá con una simple actualización. Y esto es lo verdaderamente novedoso: que el sistema base de Linux pueda evolucionar con una simple actualización.

Como ejemplo de esto último están las últimas novedades que están trabajando. Consiste en convertir a todo sistema que use systemd en un sistema "sin estado", un concepto que consiste en esencia en hacer lo necesario para que todo el software de la distribución se instale en /usr, y que en /etc y /var se almacene exclusivamente la configuración y datos generados por el usuario - el "estado" del sistema. Esto permite características curiosas, como un "reseteo del sistema": bastará vaciar el contenido de /etc y /var, y el sistema regresará al mismo estado inmaculado que tendría tras haber reinstalado la distro de cero. Es decir, se eliminará la necesidad de reinstalar la distro, bastará utilizar esta función de reseteo. También ayudará a la implementación de instaladores que distribuyan un sistema reseteado como método de instalación. Y como /usr pasa a consolidarse como el lugar donde reside el software de la distribución y donde normalmente nunca se escribe nada, se podrán crear instaladores que consistan simplemente en actualizar /usr, y tener varios snapshots de /usr, y garantizar mediante cifrado la integridad de /usr.

Antes de systemd, cosas así eran difíciles de ver. Cada distribución se lo hubiese montado a su manera, con sus propios scripts, sin fuerza agregada suficiente como para forzar a programas upstream a adoptar los cambios necesarios que las hiciesen posible. Pero systemd si tiene la fuerza necesaria para implementar estos cambios, y para animar a upstream a incorporar cambios que harán más fácil la adopción de estas características en todas las distros. Se trata de un círculo virtuoso que hace más fácil hacer cambios revolucionarios con cada vez menor coste para las distros. Sólo hay un precio a pagar: vender el alma a systemd.

Noticias Wayland (III)

Como continuación de los dos posts anteriores (1, 2) sobre noticias de Wayland, he aquí lo sucedido desde el último post (ocho meses):

• Wayland/Weston 1.4 (24 Enero): Wayland: Aparte de mejoras de fiabilidad, el único cambio importante en Wayland es que se ha incluido en su repositorio la característica "sub-superficies", lo cual lo eleva al rango de API oficial y estable. Las sub-superficies permiten que una ventana pueda estar compuesta diferentes "superficies" (porciones de la pantalla en las que se dibujan cosas y que reciben eventos). La gracia está en que las diferentes superficies que componen una ventana son visibles para el compositor, lo cual permite ceder al compositor la tarea de mezclarlas y dibujarlas como crea conveniente en lugar de obligar a ello a la aplicación. Esto permite que el compositor pueda explotar las capacidades de aceleración de hardware al máximo.
• En Weston 1.4, por su parte, destaca el inicio de la implementación de xdg-shell. xdg-shell es un protocolo utilizado para las funciones de un shell de escritorio,. También se ha iniciado implementación de un protocolo experimental para extender y recortar superficies (que una vez estabilizado se moverá a wayland), se ha mejorado el soporte para interacción táctil, se usa logind (lo cual permitirá usar weston sin permisos de root), se permite que un compositor anidado dentro de otro pase sus buffers al compositor principal, y otra serie de mejoras menores.
• Wayland/Weston 1.5 (20 Mayo): Wayland apenas tuvo cambios relevantes. En Weston la principal novedad es la inclusión de soporte para XWayland (que será incluido en Xorg 1.16), lo cual permitirá a las aplicaciones X11 funcionar bajo Weston. La otra gran novedad es que se siguió mejorando la implementación de xdg-shell, con la esperanza de completarla en 1.6, coincidiendo con la publicación de Gnome 3.14. También se ha añadido soporte para que una aplicación pueda mostrase a pantalla completa, algunas animaciones y soporte de diferentes formatos de color.

Eso por parte de Wayland y Weston. Aunque pueda parecer (erróneamente)poca cosa quisiera insistir en que Wayland y Weston están en gran medida preparados, y que la principal medida de progreso de estos proyectos no es Wayland ni Weston -que tan sólo pretende ser un compositor de referencia-, sino la creación de compositores alternativos y el portado de toolkits, librerías y aplicaciones gráficas a APIs de wayland. En este sentido, estas han sido las principales noticias sobre Wayland en todo este tiempo:

• Se publicó Gnome 3.12, con soporte muy mejorado de Wayland. Esencialmente, mejoras en mutter (el gestor de ventanas/compositor wayland), en GTK y la implementación de xdg-shell, pero tengan en cuenta que, aunque parezca una sola cosa, dentro de xdg-shell se encuentran multitud de características que son las que implementan un escritorio completamente funcional.
• XWayland ha sido incluido en el repositorio principal de X.org y será publicado en X.org 1.16. En el proceso, ha sido rediseñado, e incluye soporte de DRI3 y utilizará la arquitectura de aceleración glamor.
• WebKitGTK+ mejoró el soporte para Wayland.
• XMBC ha incluido el soporte para Wayland en el repositorio del proyecto.
• Un emulador de OpenRISC añade soporte para ejecutar Wayland dentro del emulador.
• El compositor Wayland "Green Island", parte del escritorio Hawaii para Wayland, basado en QT5, tuvo una nueva versión.
• Posteriormente, ese escritorio Hawaii publicó su versión 0.2, y anunció sus planes para la versión 0.3.
• Parches experimentales para el soporte de DRI PRIME en Wayland.
• Trabajadores de Intel publicaron una primera versión (experimental) del navegador Chrome con soporte de Wayland. Posteriormente el port a Wayland ha ido incorporando más características, unos meses después presentaron un vídeo mostrando una versión bastante completa, y continuaron publicando más versiones.
• Samsung anunció que Tizen 3.0 cambiará de X a Wayland.
• Parches para implementar un alternador de aplicaciones ALT+Tab en Weston.
• Bindings de Wayland para Perl.
• Jolla empezó a vender su primer teléfono, que usa Wayland.
• El proyecto Enlightenment publicó la versión 1.8 de sus librerías EFL, con soporte muy mejorado para Wayland.
• Parches para que Wayland tenga soporte de red a través de RDP.
• Apareció Termistor, un terminal para Wayland basado en QT 5.
• El principal mantenedor de Kwin anunció que, tras trabajar en kwin para QT5, se centraría en mejorar el soporte de Wayland en los próximos meses. El resultado empezó a verse pronto, la Alpha 2 de KDE Frameworks 5 estuvo centrada en el soporte de Wayland, muchas aplicaciones importantes de KDE funcionan ya bajo Wayland sin grandes problemas. Sin embargo, también se anunció que a pesar del progreso en otras áreas de KDE, las primeras versiones del shell Plasma de KDE 5 no se centrarán en soportar Wayland.
• Parches para el soporte de "DMA-BUF" en Wayland.
• El desarrollo de Enlightenment 19 se ha centrado en gran medida en mejorar el soporte de Wayland.
• Publicación de swc, una librería que tiene el objetivo de permitir crear compositores Wayland. Está por ver si algún otro proyecto se anima a usarla.
• Versión 0.1 de Orbital, un shell implementado como plugin de Weston.
• Soporte de Wayland en GStreamer 1.4.
• El escritorio MATE, fork de Gnome 2, está trabajando en ser portado a Wayland.
• La especificación EGL 1.5 incluyó "extensiones de plataforma" para varias plataformas gráficas, incluida Wayland.
• Nvidia dejó bien claro que están trabajando en soportar Wayland.
• Se anunció Maynard, un shell Wayland específico para la Raspberry Pi.
• Fedora aprobó la incorporación de soporte para sesiones GNOME Wayland en Fedora 21, aunque el soporte no será completo.
• Apareció Motorcar, un compositor Wayland para el Oculus Rift.
• Primeras versiones experimentales de Firefox portado a GTK3 y funcionando en Weston.

Eso es todo.

Lo que se espera de un sistemas de archivos moderno

Recientemente ha corrido por internet este post de un tipo que ha perdido 28 archivos de un total de 15264 debido a corrupción en el disco duro en el que guarda una de las copias de seguridad. El post, sin embargo, está dedicado casi íntegramente a quejarse de lo malo y viejo que es HFS+. Y no deja de ser curioso, porque en este caso HFS+ no tiene la culpa de nada.

En realidad, el autor lo ha reconocido a posteriori en una edición al final del artículo, reconociendo lo obvio: que la corrupción es debida a fallos en el disco duro, no a una corrupción causada por HFS+. Pero eso no es suficiente para esconder la tendencia del artículo, que queda bien patente en la frase "HFS+ lost a total of 28 files over the course of 6 years", resaltada en negrita. Es errónea, HFS+ no ha "perdido" nada, ha sido la corrupción del disco duro. Si hubiese utilizado ZFS hubiera recibido advertencias de la corrupción, pero sin tener configurada algún modo de duplicación de datos, las corrupciones hubiesen sido igualmente irrecuperables.

Aun así, el autor podría tener algo de razón destacando que la culpa es de HFS+, ya que al carecer HFS+ de checksum de datos, si se corrompe un archivo esa corrupción se puede extender a las copias de seguridad sin que nadie lo note. Es cierto, pero resulta un tanto dramático. Windows, que está infinitamente más extendido que OS X, tampoco tiene ningún tipo de checksums ni para datos ni para metadatos (sólo el raid integrado de storage spaces), y hay millones de personas que hacen copias de seguridad en sistemas Windows (bueno, quizás no tantas...), y sin duda debe haber personas a las que los discos duros les corrompen algún archivo. Si la gente en Windows está acostumbrada a esta realidad, debe ser a que han logrado acostumbrarse a ello, o que los programas de copia de seguridad utilizan checksums por su cuenta.

Pero dejando este dilema de lado, lo que destacaría es el efecto que ha tenido ZFS: la gente acepta como algo natural exigir que su sistema de archivos sea capaz de detectar y gestionar correctamente la corrupción. Hace unos años esto no pasaba.

Las novedades de Linux 3.15

Ya se ha anunciado la versión 3.15 de Linux. Entre las novedades de esta versión destacan que los sistemas con discos duros reanudan el sistema más rápido tras la suspensión, destaca también la capacidad para el renombrado cruzado y atómico de archivos, añade dos nuevos modos en fallocate(2) que permiten eliminar porciones de archivo o reescribirlas con ceros, el sistema de gestión de memoria se adapta mejor al tamaño de la carga de memoria del sistema, mejora el rendimiento de escritura de FUSE, se añade soporte para el algoritmo LZ4 en el sistema de compresión de memoria zram, kernels de 64 bits pueden cargarse desde firmwares EFI de 32 bits y se añade soporte para las instrucciones vectoriales AVX-512 que serán incluidas en futuras CPUs Intel. 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.


· Reanudación de la suspensión más rápida en sistemas con discos duros
La reanudación de la suspensión tardaba más de lo necesario en sistemas con discos duros tradicionales, porque el sistema se pausaba hasta que el disco duro terminara de encenderse. En esta versión, los comandos enviados al disco se envían asincrónicamente, de modo que el sistema no necesita pausarse para esperar al disco duro. El resultado es que los sistemas con discos duros reanudarán el proceso de suspensión varios segundos más rápido. Para más detalles, lea este blog.
 
· Mejora de la detección del tamaño de la memoria de trabajo
Cuando no hay suficiente espacio para toda la memoria en RAM, el kernel tiene la responsabilidad de decidir qué partes de la memoria deben permanecer en RAM y cuáles deben enviarse a swap o ser descartadas. Para poder tomar buenas decisiones en esa tarea, es necesario tomar nota de qué memoria es la más usada y merece permanecer en RAM y cuál puede ser evacuada. El modo en que el kernel Linux hace esto es manteniendo una lista de memoria "activa" e "inactiva", de modo que cuando unos datos son movidos a la memoria RAM su memoria es marcada como activa. A medida que se va usando más y más memoria, la lista activa se llena y la memoria menos usada se mueve a la lista inactiva.

El problema central de este algoritmo está en determinar cuál debe ser el tamaño de cada lista. Linux tiene una política de no permitir que la lista activa pueda crecer más que la inactiva, pero esta aproximación causa problemas. En esta versión, Linux toma nota con más detalle del uso de memoria y puede determinar con más fiabilidad el tamaño adecuado de las listas, lo cual hace que Linux funcione mejor en determinadas cargas, y que se adapte mejor a los cambios de carga, además de crear una fundación sólida que permitirá implementar políticas más eficaces en el futuro. Para más detalles, lea el artículo: Better active/inactive list balancing

· Los kernels EFI 64 bit pueden arrancar desde firmware de 32 bits
La mayoría de las CPUs x86 a día de hoy son de 64 bits, pero muchos sistemas modernos utilizan firmware EFI de 32 bits. Esto impedía cargar un kernel para sistemas de EFI de 64 bits desde ese firmware de 32 bits, pero esa limitación ha sido eliminada en esav versión (nótese que no es posible arrancar un kernel desde un stub EFI, es necesario un cargador que siga un protocolo determinado)

· Nuevo sistema de bloqueo de archivos: bloqueos privados de archivos
Debido a una historia desafortunada, los bloqueos de archivos POSIX tienen semánticas muy extrañas y poco útiles: los bloqueos son abandonados si el proceso cierra algún descriptor de archivo asociado con el inodo, y los bloqueos tomados por diferentes hilos del mismo proceso no se afectan entre si, lo cuál hace a este sistema inútil para el bloqueo de archivos entre hilos.

Esta versión añade un nuevo tipo de bloqueo que pretende solventar esos problemas. Estos nuevos bloqueos se afectan entre si con los bloqueos clásicos POSIX, pero tienen semánticas más similares a los bloqueos BSD respecto a la herencia y el comportamiento en el cierre del archivo. Para más documentación sobre la nueva API, lea el artículo: File-private POSIX locks

· Borrado y puesta a cero de partes de archivo más veloz
Esta versión de Linux incorpora dos nuevas flags de modo a fallocate(2):

  · FALLOC_FL_COLLAPSE_RANGE: Permite eliminar una porción de un archivo sin dejar agujeros, mejorando el rendimiento de operaciones que antes tenían que hacerse con atajos más costosos.

 · FALLOC_FL_ZERO_RANGE: Permite reescribir con ceros una porción de un archivo con más velocidad de lo que tomaría hacerlo manualmente (esta característica estaba disponible previamente en XFS con la ioctl XFS_IOC_ZERO_RANGE)

En esta versión, sólo XFS y ext4 tienen soporte para esas flags. Para más detalles, lea el artículo: Finding the proper scope of a file collapse operation

· Soporte para el renombrado cruzado de archivos
Esta versión añade soporte para el renombre cruzado, una variedad del renombrado de archivos en el cual dos archivos intercambian su nombre. Esta característica permite casos de usos interesantes que no eran posible antes, como por ejemplo reemplazar atómicamente un directorio con un enlace simbólico. También permite que sistemas de archivo como overlayfs operen en medio de whiteouts atómicamente. Para más detalles, lea el artículo Exchanging two files

· zram: soporte de compresión LZ4, rendimiento mejorado
Zram es un sistema de compresión de memoria utilizado por Android, Cyanogenmod, Chrome OS, Lubuntu y otros proyectos, y que fue añadido en Linux 3.14. En esta versión zram incorpora soporte para el algoritmo de compresión LZ4, que es mejor que el algoritmo actual LZO en algunos casos.

Esta versión también incorpora mejoras de rendimiento para la compresión concurrente de varios streams de compresión, y la habilidad para cambiar el algoritmo de compresión en vivo en /sys/block/zram0/comp_algorithm

· Soporte de las instrucciones vectoriales de Intel AVX-512
Las instrucciones AVX-512 son extensiones de 512 bits a las instrucciones SIMD de 256 bits "Advanced Vector Extensions" para x86. Han sido propuestas por Intel, y se espera que sean soportadas en 2015 en los procesadores Intel Knights Landing. Para más información sobre estas extensiones, lea la documentación.

· Mejora del rendimiento de la escritura de FUSE
En esta versión FUSE ha añadido la capacidad de usar el cache de escritura, lo cual mejora el rendimiento de las operaciones de escritura.

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

Firefox 29, una actualización diferente

Desde que Firefox adoptó el calendario de publicación de nuevas versión "Rapid Release", las nuevas versiones de Firefox se han sucedido una tras otra cada seis semanas. Desde que se adoptó el actualizador automático silencioso, la gente ni tan siquiera se entera de cuando se publican. Por eso me resulta curioso que haya una versión que haya dado tanto que hablar, incluso antes de ser publicada: Firefox 29, la versión que incorpora Australis, la nueva interfaz.

Los cambios de interfaz suelen despertar los instintos más conservadores de la gente. Es sabido que páginas como Facebook reciben un volumen enorme de críticas cada vez que hacen un cambio sustancial, críticas que a las dos semanas desaparecen. En otros casos, como el de Windows 8, no desaparecen y se acaban corrigiendo los fallos. ¿Qué clase de cambio será Firefox 29?

A favor del primer caso tiene el llevar en desarrollo cinco años y múltiples retrasos por razones de estabilidad, un tiempo en el que han tenido tiempo de dejar la interfaz como deseaban. Se oyen críticas, pero la de inestabilidad no es la más común. Por otra parte, se acusa al diseño de parecerse a Chrome, pero es que el diseño de Chrome no es precisamente un fracaso. Y hay que tener muy en cuenta que el Classic Theme Restorer va a ser una válvula de escape muy importante.

A favor del último caso tiene, sin embargo, los síntomas de Windows 8 y otros grandes rediseños de interfaz polémicos: gente quejándose durante meses y meses, desarrolladores que afirman escuchar a esa gente pero sin que eso se materialice en algo más que palabras, decisiones aparentemente absurdas para muchos, partes de la interfaz que dejan de ser configurables...y, sobre todo, hay una minoría que tenía configuraciones de la interfaz muy específicas y en varios casos Australis rompe completamente con sus hábitos. Romper con los hábitos de la gente siempre crea problemas, incluso con aquellos a quienes les gusta la nueva interfaz.

Creo que al final la interfaz Australis acabará siendo aceptada. Quizás haga falta esperar a mejoras próximas -sacar una versión cada 6 semanas tiene sus ventajas- para corregir algunos problemas y al desarrollo de extensiones que satisfagan todas las necesidades, pero dudo que veamos un apocalipsis de Firefox, especialmente cuando las alternativas viables son Chrome e IE, opciones aun peores para la clase de usuario que odia Australis.

Baloo, o Nepomuk 2.0

Se ha publicado KDE 4.13 hace unos días, y como la mayor parte de programadores están trabajando en KDE 5 en esta versión la principal novedad ha sido lo que el anuncio llama "nueva búsqueda semántica". Lo de "búsqueda semántica" no es más que un término complicado para describir un intento de construir escritorios que trasciendan la filosofía de archivos y directorios y estén basados en alguna clase de base de datos que permitan almacenar metadatos relacionados con los archivos (remitente, URL de origen, comentarios, valoración de 0 a 5 estrellitas, indexado del texto de archivos al estilo spotlight, etc etc) y también metadatos no relacionados con archivos que están relacionados con otros metadatos.

Como se puede intuir, el nivel de abstracción y ofuscación que reina alrededor de estos conceptos es muy notorio, y es de la clase de cosas que "huele" a complejidad innecesaria. Y ciertamente ese también parece ser el problema que ha rodeado a Nepomuk, la funcionalidad de escritorio semántico de KDE, especialmente cuando funciona conjuntamente con Akonadi, la parte del escritorio semántico que se encarga de suministrar información semántica de aplicaciones como kmail, kaddressbook o kontact a Nepomuk y al mismo tiempo funciona como "proxy" entre esas aplicaciones.

Mucha gente no entenderá qué acabo de escribir, yo mismo he tenido que leer esto para recordar las diferencias entre ambos, sintetizar las ideas con las que se justifica este software es casi imposible. Lo que mucha gente si sabe, sin embargo, es que al arrancar KDE se encuentran con diversas partes de nepomuk y akonadi que consumen memoria, especialmente la instancia mysql de Akonadi, algo que para mucha gente es bloatware incompatible con la idea de un escritorio bien diseñado (algunos asumen, erróneamente, que akonadi almacena tu correo en mysql, lo cual no es cierto, la instancia mysql sólo almacena un caché del directorio maildir local). Desactivar Akonadi y Nepomuk es la rutina de muchos usuarios de KDE. Además, mucha gente ha dejado de usar aplicaciones como kmail debido a la percepción de lentitud incorporada desde la migración a akonadi.

Nada de esto es sorprendente y, sin embargo, como usuario de kmail siempre he mantenido la fe en la mejora a largo plazo de akonadi. Intentar ir más allá de la metáfora de archivos/directorios es inevitable. Es más, creo haber recalcado en este blog que tiene muchísimo mérito que un proyecto como KDE, con tan pocos recursos, haya decidido investigar en este tipo de escritorios. Ningún otro escritorio, libre o privado, se ha atrevido a ir tan lejos. WinFS fue el intento de Microsoft de construir algo similar y ya saben como acabó, y spotlight de OS X es simplemente búsqueda. Aunque con dificultades y quejas, KDE ha llegado donde multinacionales del sector no se han atrevido, y eso tiene su mérito.

Y quizá como recompensa de su esfuerzo y constancia, en KDE 4.13 se recogen algunos frutos. Nepomuk almacenaba sus datos en RDF, un formato estandarizado por la W3C para  la "semantic web". Los desarrolladores han tomado nota durante estos años que hay tres casos principales de uso de nepomuk, y se han dado cuenta de que precisamente por ser RDF tan genérico y obtuso, resultaba difícil optimizar para esos casos. En lugar de intentar usar un sólo formato y una sola base de datos para todo, se han dado cuenta que podían prescindir de RDF y su enorme complejidad de "ontologías" añadida. En su lugar, se utilizan diferentes "backends" con bases de datos diferentes y optimizadas para cada caso. Baloo -el nombre de este nuevo reemplazamiento de nepomuk- se encarga de acceder a cada una de ellas cuando sea necesario.

Una de las ventajas más notorias es que ahora Akonadi se convierte en un simple backend de Baloo: Antes, Nepomuk necesitaba indexar los contenidos de Akonadi, lo cual implicaba que parte de los datos de aplicaciones de KDE PIM tenían que estar duplicados en ambas bases de datos (!!), de hecho había un proceso dedicado exclusivamente a sincronizar la replicación de datos entre ambas bases de datos (!!!!). Ahora sólo existe la base de datos de Akonadi, y Baloo simplemente accede a ella. Puede parecer una mejora de sentido común, pero sin la persistencia de KDE y los desarrolladores de nepomuk no se hubiera alcanzado.

La otra gran ventaja es que ha mejorado el rendimiento. En mi caso, he comprobado que la búsqueda integrada Ctrl+F de dolphin es sorprendentemente rápida incluso con búsquedas que devuelven decenas de miles de resultados, lo cual me hace plantearme seriamente usarlo a diario. También he notado que algunas operaciones de kmail que solían ser lentas, como las búsquedas, se han vuelto prácticamente instantáneas. En general el rendimiento parece haber mejorado drásticamente (aunque, desgraciadamente, no he visto ningún benchmark), y es de esperar que mejore aun más en próximas versiones, a medida que se consolide. Tan seguros están los desarrolladores de las mejoras que han rediseñado el módulo de configuración de nepomuk y han eliminado -no sin polémica- la opción gráfica para desactivarlo.

Resumiendo, todo el trabajo y dificultades acumuladas en nepomuk y en el concepto de escritorio semántico no ha sido en balde.

Las novedades de Linux 3.14

Ya se ha anunciado la versión 3.14 de Linux. Entre las novedades de esta versión destacan un planificador de procesos para tareas que tengan requisitos de tiempo real, la estabilización de un sistema de compresión de memoria, un port del validador de bloqueos a espacio de usuario, la habilidad para almacenar propiedades en inodos en Btrfs, soporte para ejecutar comandos tras un evento en la infraestructura de trazado, aleatorización del espacio de direcciones del kernel, fusión automática de paquetes en cierta clase de conexiones TCP, y un nuevo planificador de paquetes de red para luchar contra el bufferbloat. 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.

· Planificador de procesos "deadline" para planificación de tiempo real
Normalmente los sistemas operativos proporcionan prioridades en el planificador de procesos, cuanta más prioridad tiene un proceso, más tiempo de ejecución puede conseguir ese proceso respecto a otros con prioridades menores. En Linux, los usuarios configuran las prioridades con valores de -20 a 19 utilizando la herramienta nice(2). Adicionalmente, Linux soporta la noción de "clases de planificación", en cada clase hay una política de planificación diferente, por ejemplo, hay una clase SCHED_FIFO con una política FIFO "el primero que entra, el primero que sale", y una política round-robin en  SCHED_RR.

Este sistema de prioridades no es, sin embargo, el más apropiado para tareas que requieren tiempo real. En esta versión Linux implementa una alternativa que está diseñada sobre ideas que parten de la investigación en sistemas de tiempo real: planificación "deadline" ("plazos" de tiempo), que ha sido implementada como una nueva política de planificación, SCHED_DEADLINE.

La planificación "deadline" deja atrás la noción de prioridades. En su lugar, los procesos proporcionan tres parámetros: tiempo de ejecución, periodo y plazo. A una tarea que esté planificada bajo la política SCHED_DEADLINE, se la garantiza que obtendrá "tiempo de ejecución" microsegundos de ejecución cada "periodo" microsegundos, y ese "tiempo de ejecución" estará disponible dentro de "plazo" microsegundos desde el inicio del periodo. El planificador de tareas utiliza esa información para ejecutar el proceso con el plazo más cercano al momento actual, un comportamiento más cercano a los requerimientos de los sistemas de tiempo real. Para más detalles sobre los algoritmos de planificación, ver la documentación.

· zram: compresión de memoria considerada estable
zram crea dispositivos de bloques en la memoria RAM. Todo lo que escrito a esos dispositivos de bloques es comprimido. Si los dispositivos de bloque zram son utilizados como espacio de intercambio, cuando el sistema intente mover liberar memoria enviando porciones al espacio de intercambio, en realidad lo estará moviendo de una zona de la memoria a otra, excepto que los datos movidos habrán sido comprimidos antes de ser copiados a su destino. Esto funciona en la práctica como un sistema de compresión de memoria capaz de mejorar la respuesta en sistemas con cantidades de memoria limitadas. Zram está siendo utilizado por compañías de TV, Android 4.4, Cyanogenmod, Chrome OS, Lubuntu...

Zram ha estado en "staging" desde Linux 2.6.33. En esta versión, zram ha sido movido fuera de staging, a drivers/block/zram.

· Btrfs: Propiedades de inodo
Esta versión añade infraestructura para añadir parejas nombre/valor como xattrs a los inodos en Btrfs. El propósito de estas parejas es almacenar propiedades para los inodos, tales como la compresión. Estas propiedades pueden heredarse; esto significa que cuando el inodo de un directorio tiene la propiedad compresión activada, todos los inodos que sean creados en ese directorio serán también comprimidos. Los subvolúmenes pueden tener también propiedades asociadas, y pueden hederarse del subvolumen padre. Esta versión añade una implementación de propiedades, llamada "compresión", cuyos valores pueden ser "lzo" o "zlib".

· Soporte para ejecutar comandos en los eventos de trazado
La infraestructura de trazado en Linux permite registrar sondas en las funciones del código como eventos (para más detalles, ver Documentation/trace/events.txt). Esta versión permite que estos eventos desencadenen la ejecución de comandos. Estos comandos pueden tener varias formas, por ejemplo podrían activar o desactivar otros eventos o invocar el volcado de pila. Cualquier comando puede tener incorporado además un filtro de eventos, de ese modo el comando será invocado solamente si el evento pasa por el filtro asociado

Por ejemplo, este comando causa el volcado de pila las primeras cinco veces que hay una petición de kmalloc que pide >= 64KB de memorua: # echo 'stacktrace:5 if bytes_req >= 65536' > \ /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger

Para más detalles, ver Sección 6 de Documentation/trace/events.txt

· Las sondas de espacio de usuario tienen acceso a todos los argumentos
Las sondas de espacio de usuario son una característica de Linux 3.5 que permite activar sondas en programas de espacio de usuario. Esta versión permite que las sondas de espacio de usuario (uprobes) tengan acceso a todo tipo de argumentos en las funciones de los programas: pila de memoria, deference, bitfield, retval y offset de archivo. Para más detalles, aquí.

· Validador de bloqueos en espacio de usuario
El kernel Linux ha tenido (desde 2.6.18) un validador de bloqueos que permite encontrar fallos en la programación de los bloqueos en tiempo de ejecución. Esta versión permite ejecutar el validador de bloqueos de Linux en espacio de usuario, haciendo posible depurar problemas de bloqueo en espacio de usuario.

· Espacio de direcciones del kernel aleatoria
Esta versión permite aleatorizar la dirección física y virtual en la que se descomprime la imagen del kernel, lo cual ayuda a bloquear ciertos tipos de exploits que confían en conocer la localización de las direcciones del kernel.

· TCP automatic corking
Cuando las aplicaciones hacen llamadas pequeñas y consecutivas a write()/sendmsg(), el kernel intenta fusionarlas, para disminuir el número de paquetes enviados en total, esta característica se llama "automatic corking". Las aplicaciones aun pueden usar TCP_CORK para conseguir un comportamiento óptimo cuando sepan cómo o cuando tengan que "uncork" sus sockets. Se añade una nueva sysctl (/proc/sys/net/ipv4/tcp_autocorking), que por defecto está activada. Para benchmarks y más detalles, ver commit

· Antibufferbloat: planificador de paquetes "Proportional Integrarl controller Enhanced"
Bufferbloat es un fenómeno consistente en la creación de demasiados búffers en la red, lo cual causa excesiva latencia y fluctuaciones. A medida que más aplicaciones interactivas (VoIP, streaming de vídeo, transacciones financieras) funcionan sobre Internet, esos defectos empeoran el rendimiento de la aplicación. Ha habido varias mejoras y características en las últimas versiones de Linux que tratan de frenar ese problema.

Esta versión añade un nuevo planificador de paquetes: PIE(Proportional Integral controller Enhanced), que puede controlar la latencia media de la cola a un valor determinado. Los resultados han demostrado que PIE puede asegurar latencia baja  y conseguir una utilización alta de los enlaces en situaciones de congestión. El diseño añade una sobrecarga mínima. Para más información, ver este papel técnico sobre PIEo este borrador del IETF. Todo el código, documentación y scripts y resultados puede encontrarse en ftp://ftpeng.cisco.com/pie/


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

¿Qué pasó en Windows 8?

Pocas veces en mi vida me he sentido tan desorientado e inútil frente a un ordenador como cuando probé por primera vez una versión previa de Windows 8. No fui el único, durante todo el tiempo que se tardó en desarrollar la versión final las quejas sobre la nueva interfaz metro fueron continuas, con especial énfasis en la imposibilidad de configurar el escritorio tradicional como escritorio por defecto y poder volver a usar el menú de inicio.

A pesar de ello, la reacción de Microsoft fue la de justificar con datos y estadísticas -todos ellos muy razonables sobre el papel- por qué las decisiones que habían tomado eran las mejores. En lugar de intentar comprender que había muchas quejas, y que si las había debía ser por algo, parecían esforzarse en intentar demostrar que las críticas eran irrelevantes. Ni tan siquiera añadieron algún tipo de guía o ayuda que explicase Metro a los nuevos usuarios, a pesar de que es algo que se reclamó constantemente. Naturalmente, pensaron que una interfaz bien diseñada era intuitiva por si misma y no necesitaba de esas cosas, y Metro sin duda era buena: afirmaron que la gente se adaptaría a Windows 8 en dos semanas. Y llegó el día, y Windows 8 vio la luz, y ya sabe todo el mundo como fue el recibimiento. Ni dos semanas, ni dos meses.

Como consecuencia, en la actualización 8.1 tuvieron que enmendarse y permitir la configuración de varios aspectos: el escritorio tradicional puede ser el escritorio por defecto, los charms son opcionales, se reincorpora el icono del menú de inicio (aunque no el menú), ciertas ayudas para guiar a los nuevos usuarios. En la próxima "Spring update", se arrancará por defecto en el escritorio tradicional en equipos no táctiles, además de otros cambios sustanciales en la interfaz, como permitir usar la barra de tareas dentro de Metro, o añadir iconos en la pantalla de inicio de metro para apagar o buscar. Ya no se espera que la gente se adapte, y no sólo se asume que hay gente que no se adaptará, sino que se construyen alternativas mixtas que rompen con la visión original. Sorprende como se justifica estas marchas atrás (negrita mía):

"Some of those touch affordances weren’t really tuned as well as we could do for those mouse and keyboard users. We found people weren’t aware of where they should look in the UI. Those are the things we’ve really started to improve for this update coming this spring"

El equipo de usabilidad de Microsoft debe ser, por necesidad, de los mejores del mundo, y es una locura sugerir que no son profesionales. Cabría preguntarse, por tanto, cómo es posible que ese equipo no viese con antelación en las pruebas lo que para casi todo el mundo era una obviedad, y que sólo ahora se hayan percatado de que "people aren’t aware of where they should look in the UI". Parte de ello se debe, sin duda, a cierto talibanismo en el que los mejores expertos pueden caer: "mi solución es la mejor y sin duda a la gente le encantará".

Una respuesta incompleta podemos encontrarla en este famoso post de un diseñador de Microsoft en reddit, donde nos revela la concepción que hay detrás de la nueva interfaz: Metro es una interfaz diseñada para los usuarios menos expertos en mente, mientras que el escritorio tradicional se reserva para los "power users". Metro es para consumidores de contenido, el escritorio para los creadores de contenido. Hay varios hechos que ponen contra las cuerdas esta concepción: la evidencia de que Metro ha sido diseñada no directamente para una clase de usuarios sino para una clase de hardware (táctil), la realidad de que muchos "consumidores de contenido" no se sienten a gusto en Metro (esta contestación al post anterior, citando casos de usuarios que tienen más problemas con Windows 8 que con 7, es un ejemplo claro), el hecho de que se mantengan dos interfaces para una misma clase de usuario en un mismo equipo...

Aun a riesgo de ser atrevido, sospecho que tras esas explicaciones se esconde el deseo de Microsoft de racionalizar y crear teorías para justificarse ante si mismos su falta de adaptación a las nuevas tecnologías. La realidad es que Metro no es una interfaz creada por expertos de usabilidad dedicados tranquilamente a ello aislados del mundo: es una creación apresurada de una compañía que se enfrentaba al terror de estarse volviendo irrelevante. La explicación más probable de los problemas de Windows 8 es que las prisas por tener algo tangible les ha llevado a pasar por alto demasiadas cosas. Como consecuencia se ven ahora obligados a centrar las siguientes actualizaciones en corregir lo que no hicieron bien en un principio, con la esperanza de paliar el rechazo existente, que les ha llevado en la misma dirección que pretendían evitar.

La sombras de sysvinit

La burocracia debianera ha elegido finalmente systemd, y como consecuencia de ello Ubuntu abandona upstart. Como dice el refranero, para este viaje no hacían falta alforjas. Quizás lo más destacable de todo es una de las ventajas menos comentadas, que es la unificación del sistema de inicio a lo largo y ancho de la mayor parte de distribuciones.

Es buen momento para recordar que la defensa del actual sysvinit como supuesta encarnación de un ideal Unix no tiene fundamentos sólidos. Cada vez es más rechinante la obsesión con considerar "esencia Unix" una especie de nihilismo informático en el que la regla principal es diseñar todo a base de comandos comunicados por tuberías, incluso cuando los programas resultantes son horribles. Como ya conté aquí, esa manera de pensar es un lastre cultural que ignora que la concatenación de comandos comunicados por tuberías era literalmente la única manera de hacer cosas complejas en Unix, en aquel entonces no había otros sistemas de IPC.

Hace tiempo que los sistemas Unix se dieron cuenta de esas limitaciones y adoptaron el concepto de librerías compartidas, ausente en sus inicios. Llevamos décadas apuñalando por la espalda la idea de comandos simples + tuberías. Ningún sistema Unix moderno se construye únicamente así, ni lo hará en el futuro. Hoy en día las librerías compartidas predominan como manera de crear programas locales complejos a partir de elementos más simples.

Eso no quiere decir que el shell esté obsoleto, o que no sea útil. Pero proponerlo como fundamento para crear un sistema complejo como systemd o upstart no tiene por qué ser la mejor idea.  SysVinit es más bien un manojo de herramientas pegadas con celo que suelen funcionar la mayor parte de las veces, otras simplemente explotan por los aires, como podemos ver en este PDF de los programadores de upstart, en el que citan una serie de bugs típicos de sysvinit.

Sin embargo, la principal característica de systemd no está resultando tener que ver tanto con su implementación, sino con el modo de integrar diferentes partes del sistema. systemd requiere kernels compilados con una serie de opciones del kernel (cgroups, inotify, seccomp...), va a requerir en breve kdbus, proporciona un sistema de logging propio, proporcional logind, una alternativa a xinetd, deja obsoletos varios comandos de gestión del sistema, proporciona un sistema de gestion de sesiones de usuario que reemplaza a cosas como gnome-session...todo ello con el objetivo de que todo sistema que adopte systemd tenga una serie de funcionalidades y de manera de integrar servicios básicos del sistema estandarizados. Aunque muchas de esas funcionalidades son configurables y se pueden desactivar o dejar de lado, es obvio que quien adopta systemd lo hace generalmente para activarlas.

Esto es, en realidad, lo que más rechazo genera contra systemd. Pero en este blog se ha destacado en el pasado la importantísima y frecuentemente denostada función de la integración de diferentes partes de software: aunque haya quien se queje de que systemd impone, fuerza o anima a hacer cosas que no a todos podrían gustarle, también hay que tratar de ver el valor que proporciona toda esa integración y uniformidad. Como cuentan en este blog, systemd ha ganado porque se ha preocupado por los usuarios más que nadie.

Ese es un aspecto en el que los sistemas basados en shell no pueden alcanzar a systemd: obsesionados con supuestos espíritus que han distorsionado o que en realidad no existen, se han olvidado que la prioridad es crear sistemas útiles. No se trata sólo de cómo crear las cosas, sino en qué cosas deben crearse. Paradójicamente, el dejar de lado una visión "top-down" de las cosas les ha llevado posteriormente a hacer mal las cosas. El mejor ejemplo de esto último lo he visto en una historia que Lennart Poettering contaba sobre como algo en apariencia tan simple como el proceso de matar todos los procesos y apagar el sistema es mucho más complejo de lo que parece, y como, de hecho, systemd es el único sistema de inicio que apaga el sistema de manera total y absolutamente segura. El OpenRC en Gentoo, que se ha erigido en bastión de resistencia contraria a la adopción de systemd, no hace las cosas ni la mitad de bien, ni en ese aspecto ni en otros: eso si, lo hace en shell, que para sus desarrolladores es la principal medida de éxito.

¿Por qué kdbus?

De entre todas las polémicas sobre Systemd sigue sobresaliendo la relacionada con Debian, pero últimamente se ha hablado de la integración de dbus en el kernel bajo el nombre de kdbus. Y junto con kdbus, ha surgido la inevitable discusión sobre la barbaridad que es meter dbus en el kernel, que dbus es una cosa maloliente de escritorio, Linux se está alejando de Los Sagrados Principios Unix, etc etc.

Pero son discusiones sin sentido: kdbus no es una mala idea.

Empezaré reconociendo que, en sus inicios, yo también fui de los que odió la proliferación de dbus, por tener ese olor a software redundante del que podríamos librarnos si se hicieran las cosas como es debido. Sin embargo basta informarse un poco (este vídeo/diapositivas de una charla de Lennart Poettering es muy recomendable) para comprender que su propósito es necesario, se trata de un tipo de IPC de alto nivel disponible en muchos otros sistemas operativos -algunos de ellos microkernels- que no puede ser sustituido por los mecanismos de IPC tradicionales.

Para suplir esa carencia nació dbus, que surgió como un intento de Gnome de librarse de Bonobo e imitar el DCOP de KDE, y que finalmente incluso KDE acabó usando en KDE 4. ¿Pero por qué incluir kdbus en el kernel, en lugar de seguir usando dbus el demonio dbus en espacio de usuario?

En parte, la respuesta es que dbus es bastante ineficiente: Un mensaje dbus de una aplicación a otra requiere copiar los datos y cambiar de contexto de la aplicación al demonio dbus, y este a su vez ha de hacer lo mismo con la otra aplicación. Tampoco es posible tener comunicación dbus desde el arranque del sistema, hay que esperar a que se arranque el servicio, y no está bien integrado con los mecanismos de seguridad del kernel.

En realidad, el kernel es el sitio donde se deben implementar esta clase de cosas: tuberías, FIFOs, sockets Unix, pila TCP/IP, IPC de System V, etc; todos están implementados en el kernel, y en muchos casos lo están por la simple razón de que son muy utilizados y es conveniente hacerlo así. Podría mantenerse dbus en espacio de usuario, pero también se puede implementar la pila TCP/IP en espacio de usuario, y hay razones para no hacerlo. Hay que hacer notar que incluso algunos microkernels implementan sistemas IPC similares dentro del kernel, precisamente porque el IPC entre procesos es su fundamento. Así que creo que las alarmas por kdbus están injustificadas.

Las novedades de Linux 3.13

Ya se ha anunciado la versión 3.13 de Linux. Entre las novedades de esta versión destacan nftables, el sucesor de iptables, un rediseño de la capa de bloques optimizado para SSDs de alto rendimiento, un framework para establecer límites de consumo energético en dispositivos Intel RAPL, mejora del rendimiento de squashfs, gestión energética en dispositivos AMD Radeon activada por defecto, mejor rendimiento en sistemas NUMA, mejor rendimiento en cargas donde se utilicen "hugepages", TCP Fast Open activado por defecto, soporte para pagos NFC y soporte para el protocolo High-availability Seamless Redundancy. 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.


· Capa de bloques escalable, diseñada para dispositivos SSD de alto rendimiento
Durante décadas, los discos duros tradicionales han determinado el diseño de las partes de los sistemas operativos que comunican a las aplicaciones con los dispositivos de almacenamiento. Con las nuevas generaciones de discos de estado sólido, SSD, esos requisitos antiguos ya no tienen validez. La capa de bloques de Linux estaba diseñada con un sólo bloqueo que protegía la cola de peticiones de ES, este diseño puede conseguir un ratio de 800.000 operaciones de ES por segundo, al margen de cuántos cores se utilizasen para hacer ES. Esto era más que suficiente para los discos magnéticos tradicionales, cuyo ratio en accesos aleatorios no pasa de varios cientos de ES/s, pero no es suficiente para los discos SSD más modernos, que alcanzan un ratio de 1 millón, y mejoran con rapidez en cada nueva generación. Tampoco es un diseño apropiado para el mundo multicore actual.

Esta versión incluye un rediseño de la capa de bloques de Linux, que pasa a estar basada en dos niveles de colas: Un nivel de colas por-cada-CPU para enviar ES, que posteriormente pasan a un segundo nivel de colas de envío hacia el hardware. El mapeado entre las colas de envío y las colas de hardware puede ser 1:1 o M:N, dependiendo del hardware y la configuración. La experimentación ha demostrado que este diseño puede alcanzar varios millones de operaciones ES/s, pudiendo de este modo aprovechar las nuevas capacidades de los dispositivos SSD NVM-Express o PCI-E, y también las CPUs multicore, al mismo tiempo que se mantienen la interfaz y ventajas de una capa de bloques.

· nftables, el sucesor de iptables
iptables tiene una serie de limitaciones tanto a nivel funcional como de diseño: problemas con la actualización de reglas o duplicación de código, que causan problemas al mantenimiento del código y a los usuarios. nftables es un nuevo sistema de filtrado de paquetes que resuelve esos problemas, manteniendo al mismo tiempo compatibilidad para los usuarios de iptables.

El núcleo del diseño de nftables es una pseudo-máquina virtual simple inspirada en BPF. Una nueva utilidad interpreta las reglas proporcionadas por el usuario, las compila a un pseudo-bytecode y transfiere el resultado al kernel. Este sistema puede reemplazar miles de líneas de código, ya que el conjunto de instrucciones del bytecode permite expresar los selectores de paquetes para todos los protocolos. Dado que la utilidad en espacio de usuario interpreta los protocolos y los traduce a ese bytecode, ya no es necesario incorporar en el kernel extensiones específicas para nuevos protocolos, lo cual significa que los usuarios no tendrán que actualizar el kernel para conseguir soporte para nuevos protocolos y matches, sólo será necesario actualizar la utilidad. Hay también una nueva librería para las utilidades que necesiten interactuar con el cortafuegos.

nftables proporciona compatibilidad con iptables. Hay nuevas utilidades iptables/iptables que traducen reglas de iptables al nuevo bytecode, y es posible también usar e introducir nuevos módulos xtables. Como bonus, estas nuevas utilidades proporcionan características que eran imposibles con el antiguo diseño: notificaciones para cambios en las tablas y cadenas, mejor soporte para actualizaciones incrementales de reglas, y la habilidad para activar/desactivar cadenas de cada tabla. Hay un una pequeña guía de la nueva utilidad y su sintaxis aquí. Página del poyecto: http://netfilter.org/projects/nftables/


· Radeon: soporte de gestión energética activado por defecto, cambio automático de GPU, soporte de Radeon R9 290X 'Hawaii'
 · Gestión energética activada por defecto: Linux 3.11 añadió soporte de gestión energética para dispositivos AMD Radeon. La gestión energética mejora el consumo energético, que es crítico para los dispositivos alimentados por baterías, pero es también un requisito para conseguir alto rendimiento, ya que permite reprogramar la velocidad de reloj a estados más potentes en algunas GPUs y APUs que se inician por defecto en estados menos potentes.

Este soporte tenía que activarse con un parámetro en el módulo. En esta versión, la gestión energética está activada por defecto para buena parte del hardware AMD Radeon: BTC asics, SI asics, SUMO/PALM APUs, evergreen asics, r7xx asics y hawaii.

 · Cambio automático de GPU: El soporte para cambio automático de GPUs se introdujo en Linux 3.12. Esta versión añade soporte para esta característica en hardware AMD Radeon.

 · Soporte de R9290X 'Hawaii': Esta versión añade soporte para los dispositivos R9 290X "Hawaii"

· Framework para la limitación de consumo energética
Esta versión añade un framework que permite configurar límites de consumo de energía en los dispositivos que soporten esa funcionalidad. Ha sido diseñado pensando en el mecanismo Intel RAPL (Running Average Power Limit), disponible en los últimos procesadores de Intel (Sandy Bridge y posteriores, otros muchos dispositivos añadirán soporte posteriormente). Este framework proporciona una interfaz consistente entre el kernel y el espacio de usuario para exponer sus mecanismos de configuración con uniformidad.

· Soporte para la arquitectura Intel Many Integrated Core
Esta versión añade soporte para la arquitectura Intel Many Integrated Core o MIC, una arquitectura que incorpora parte del trabajo realizado anteriormente en la arquitectura Larrabee, el proyecto Teraflops Research Chip, y el procesadorIntel Single-chip Cloud Computer. El superordenador más potente del mundo, el Tianhe-2 del Centro Nacional de Supercomputación en Guangzhou, China, utiliza esta arquitectura para conseguir 33.86 PetaFLOPS.

La familia MIC de coprocesadores en formato PCIe ejecuta un sistema operativo Linux de 64 bits. El driver gestiona el estado del sistema operativo en la tarjeta y establece comunicación entre el equipo y la tarjeta. Más información sobre la familia de dispositivos Intel Mic y sobre el sistema operativo y herramientas para MIC están disponibles aquí. Esta versión soporta los dispositivos Intel MIC X100, e incluye un demonio en espacio de usuario de ejemplo.

· Mejora del rendimiento en sistemas NUMA
Los sistemas multiprocesador modernos (ejemplo, x86) suelen tener sistemas de memoria NUMA ("non-uniform memory access"). En estos sistemas, el rendimiento de un proceso puede ser diferente dependiendo de si el rango de memoria al que accede está conectado a la CPU local o a otra CPU. Dado que el rendimiento depende de la localidad de los accesos a la memoria, es importante que el sistema operativo programe un proceso para que se ejecute en la misma CPU donde está conectada la memoria a la que accederá.

La manera que Linux tenía de tratar estas situaciones era deficiente. En Linux 3.8 se incluyó una nueva fundación para el soporte de NUMA que permitiría añadir políticas NUMA más inteligentes en el futuro. Esta versión incluye varias de esas políticas, y puede gestionar casos tales como los de procesos que comparten páginas de memoria, o los que utilizan hugepages transparentes. Se han añadido nuevas sysctls para activar o desactivar y configurar este soporte (ver documentación aquí).

· Mejora de la escalabilidad del acceso a la tabla de páginas en cargas con hugepage
Linux mantiene información sobre cada página de memoria en una estructura de datos llamada tabla de páginas. En las situaciones en que se utilizan hugepages, el bloqueo utilizado para proteger algunas partes de la tabla se ha convertido en un punto de contención. Esta versión incluye bloqueos más eficientes para esas partes de la estructura, mejorando la escalabilidad del acceso a la tabla de páginas en las cargas con hugepage y muchos procesos.

· Mejora del rendimiento de squashfs
Squashfs, el sistema de sólo lectura utilizado por la mayoría de distribuciones live, instaladores y algunas distros embebidas, ha incorporado mejoras que aumentan notablemente el rendimiento en cargas donde estén envueltas varias lecturas paralelas. Uno de ellas es la descompresión directa de los datos en el caché de páginas, lo cual evita una copia de los datos y elimina el bloqueo utilizado para proteger al búfer intermedio. El otro es el soporte de la descompresión multihilo.

· TCP Fast Open activado por defecto
TCP Fast Open es una optimización del proceso de establecimiento una conexión TCP que permite eliminar un viaje de ida y vuelta de ciertos tipos de conversaciones TCP, lo cual puede mejorar el tiempo de carga de páginas web. En Linux 3.6 y Linux 3.7 se añadió soporte para esta característica, que requiere soporte de espacio de usuario. En esta versión, el soporte de TCP Fast Open está activado por defecto.

· Soporte de pagos NFC
Esta versión añade soporte para el Secure Element. Una API netlink permite activar, desactivar y descubrir los elementos seguros NFC. Con ayuda de espacio de usuario, esto permite soportar pagos NFC, que son útiles para implementar transacciones financieras. Sólo el driver pn544 soporta esta API de momento.

· Soporte para el protocolo High-Availability Seamless Redundancy
El protocolo High-availability Seamless Redundancy (HSR) es un protocolo de redundancia para Ethernet. Proporcional redundancia y tolerancia a fallos para dichas redes. Requiere una topología de red especial donde todos los nodos estén conectados a un anillo (y cada nodo tenga dos interfaces de red físicas). Está orientado a aplicaciones que requieren alta disponibilidad y tiempo de reacción muy corto.

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