Del mismo modo que Intel es un ejemplo de multinacional letalmente competitiva, capaz de cometer errores mastodónticos y corregirlos sin perder el liderazgo, AMD ha acabado convirtiéndose en ejemplo de lo contrario. El único buen momento de AMD en la última década fue el Opteron, una joya que no supieron capitalizar y que se ha convertido en una excepción en su historia. Hoy, en un mundo en el que la eficiencia de un procesador importa a veces más que su rendimiento bruto, han decidido no enfrentarse al mundo y pasar a usar ARM en servidores.
Que AMD recurra a procesadores ARM para algo es equivalente a reconocer que no son capaces de crear procesadores x86 de bajo consumo equivalentes. Es más, probablemente una de las razones que les ha impulsado a tomar esta decisión es que ARM iba a acabar comiéndose parte de su mercado de servidores, y han preferido unirse a otro bando antes que perder la guerra x86 vs ARM. Intel, por su parte, ha empezado con desventaja, pero al menos tienen intención de presentar batalla y ganarla.
Tras esta reorganización de bandos en el campo de procesadores de bajo consumo, prácticamente todos los competidores de Intel en el campo de semiconductores se han unido en el lado de ARM, e incluso algunos aliados tradicionales en otros campos, como Microsoft, han declarado su neutralidad. La pelea será cruel.
30 de octubre de 2012
23 de octubre de 2012
Curiosidades de Flash en Linux
No sólo el soporte de Flash en Linux está en vía muerta, sino que el que hay es difícil de usar. Como ejemplo, me encuentro con este vídeo, imposible de encontrar en otro lado, así que intento descargármelo.
Para ello intento buscar en la fuente de la página el enlace al vídeo en la página, pero el que supuestamente se usa como fuente no existe o no funciona. Dejo que se descargue entero y procedo a buscar el archivo del vídeo en el caché de Firefox, algo que solía funcionar. Pero en el caché de Firefox no hay nada, ni en el cache del disco ni el cache de la memoria. Parece que intentan hacer desaparecer los vídeos y evitar que la gente se los descargue (lo cual sorprende tratándose de una URL terminada en .ru).
Sin embargo, el vídeo está evidentemente en mi sistema: lo estoy viendo. En alguna parte debe estar. Como último recurso, recurro a echar un ojo a los descriptores de archivos del proceso aislado en el que Firefox pone al reproductor (/proc/PID/fd/). En él, encuentro que el proceso tiene el descriptor 20 apuntando a un archivo curioso:
20 -> /tmp/FlashXXsKXrQ0 (deleted)
El archivo asociado el descriptor, /tmp/FlashXXsKXrQ0, ha sido borrado, pero como es norma en sistemas Unix, los procesos que lo tenían abierto siguen podiendo acceder a él. Ese archivo ya no existe, no puedo acceder directamente a él, pero si que puedo hacerlo mediante /proc. Con un simple "cp /proc/PID/fd/20 ~/archivo" recupero el archivo y, efectivamente, es el vídeo que quería descargar.
Aparentemente, Adobe quería dificultar la descarga de vídeos, como una especie de DRM simplista. Para ello decidieron crear un archivo en /tmp/ y abrirlo, proceder inmediatamente después a borrarlo para que nadie lo viese, y seguir trabajando internamente con ese descriptor asociado a un archivo "oculto".
Para ello intento buscar en la fuente de la página el enlace al vídeo en la página, pero el que supuestamente se usa como fuente no existe o no funciona. Dejo que se descargue entero y procedo a buscar el archivo del vídeo en el caché de Firefox, algo que solía funcionar. Pero en el caché de Firefox no hay nada, ni en el cache del disco ni el cache de la memoria. Parece que intentan hacer desaparecer los vídeos y evitar que la gente se los descargue (lo cual sorprende tratándose de una URL terminada en .ru).
Sin embargo, el vídeo está evidentemente en mi sistema: lo estoy viendo. En alguna parte debe estar. Como último recurso, recurro a echar un ojo a los descriptores de archivos del proceso aislado en el que Firefox pone al reproductor (/proc/PID/fd/). En él, encuentro que el proceso tiene el descriptor 20 apuntando a un archivo curioso:
20 -> /tmp/FlashXXsKXrQ0 (deleted)
El archivo asociado el descriptor, /tmp/FlashXXsKXrQ0, ha sido borrado, pero como es norma en sistemas Unix, los procesos que lo tenían abierto siguen podiendo acceder a él. Ese archivo ya no existe, no puedo acceder directamente a él, pero si que puedo hacerlo mediante /proc. Con un simple "cp /proc/PID/fd/20 ~/archivo" recupero el archivo y, efectivamente, es el vídeo que quería descargar.
Aparentemente, Adobe quería dificultar la descarga de vídeos, como una especie de DRM simplista. Para ello decidieron crear un archivo en /tmp/ y abrirlo, proceder inmediatamente después a borrarlo para que nadie lo viese, y seguir trabajando internamente con ese descriptor asociado a un archivo "oculto".
16 de octubre de 2012
Por qué Haiku/BeOS es un sistema operativo desfasado
Es inevitable: cada cierto tiempo, se publica en alguna parte de Internet un artículo en el que se relata la eterna historia de BeOS y su reencarnación Haiku, el sistema operativo que nos rescatará de todos los quebraderos de cabeza que nos causan los sistemas operativos modernos. Es comprensible que los periodistas tecnológicos hacen sitio a cosas llamativas como estas, pero va siendo hora de enumerar los defectos, mitos y exageraciones varias sobre el utopismo de Haiku, que alguna vez han sido mencionadas en este blog pero que nunca han sido analizadas a fondo.
· Sistema operativo de escritorio: BeOS se hizo famoso en su día por la interactividad de su interfaz, rapidez en la respuesta a las acciones del teclado y ratón, y poder reproducir varios vídeos simultaneamente sin ningún problema. Algo que puede resultar poco sorprendente hoy en día, pero que entonces Windows, Linux, y Mac OS no podían hacer.
Sin embargo, trasladar el argumento al presente sería una locura y un olvido de la realidad de mediados-finales de los 90. En aquellos tiempos los sistemas operativos bien diseñados se encontraban en los servidores, los escritorios vivían en una realidad alternativa y eran, por lo general, bastante cutres. Los Windows de la época eran los 9x, ese engendro demoniaco que se iniciaba a partir de MS-DOS, y en el que un proceso cualquiera podía colgar el sistema. Mac OS no tuvo multitarea apropiativa ("preemptive") hasta la versión 9.0, sólo dos años antes de la aparición de OS X. Respecto a Linux, sus características de servidor eran sólidas, pero su implementación interna no era nada óptima para un escritorio. Estamos hablando de los tiempos de Linux 2.0, la primera versión que soportaba SMP y que, desde luego, no soportaba ninguna clase de "preemptitividad": Cuando un proceso hacía una llamada al sistema, el resto de procesos tenían que esperar a que terminara si ellos querían hacer otra. Para un sistema de escritorio algo así era monstruoso.
Que BeOS fuese un buen sistema de escritorio y otros muy malos no tiene nada de sorprendente, como tampoco lo tiene que los que fueron malos se hayan convertido a base de trabajo en buenos, mientras que BeOS y Haiku han ido empeorando debido a las exigencias elementales del hardware moderno: Haiku carece de capacidades elementales de gestión de energía y ni tan siquiera puede suspender a memoria, por ejemplo.
· Sistema gráfico: El subsistema gráfico de BeOS era excelente, pero fue diseñado para un mundo 2D, pre-GPU, donde las cosas eran muy diferentes a lo que son hoy. El soporte 3D sólo existió como algo experimental y, desde luego, no tomaba parte en los gráficos de la interfaz.
Todos los sistemas operativos llevan varios años rediseñando por entero sus subsistemas gráficos -arquitectura de los drivers del kernel, servidor gráfico, toolkits- para adaptarse a la nueva realidad de la potencia de las GPUs, y aunque ya se usa todo este trabajo en los toolkits para pantallas táctiles, aun no hemos empezado a ver de verdad los resultados visuales de todo esto (imagínense un escritorio donde los iconos no sean simples imágenes a los cuales el diseñador pinta un sombreado para dar sensación de profundidad, sino objetos 3D con sombra generada por la GPU y capaces de reaccionar con animaciones complejas, como en un juego).
Haiku lleva mucho retraso frente a los toolkits actuales. Aun no implementa la capacidad de "compositing" que les permitiría soñar con imitar los efectos que Compiz hacía hace años, no digamos ya frente a cosas como Wayland + QML.
· Multithreading: Una de las decisiones que hicieron los diseñadores de BeOS fue optimizar para ordenadores con múltiples procesadores: aunque su predicción se retrasó una década, está claro que acertaron en su visión.
Sin embargo, existe mucha mitificación al respecto de lo que BeOS llamó "Pervasive Multithreading". En realidad, se reducía a utilizar threads por doquier (una solución inferior a la de Grand Central Dispatch en iOS), sobre una base de código fundamentalmente en C++. En los 90, el soporte de threads en Linux era patético y lo de BeOS podía resultar llamativo, pero hoy en día no tiene nada de particular. De hecho, un escritorio Linux moderno utiliza bastantes threads: Mi firefox usa nada menos que 31, el lector de correo 3, el programa de música 12, el lector de feeds 2. A veces echo de menos que los programadores no aprovechen más otras CPUs, pero es una cuestión de vagancia, más que de incapacidad técnica.
Bien es cierto que BeOS tiene el mérito de haber usado threads como parte fundamental del diseño de las librerías básicas del sistema, y que varios objetos de la API de BeOS usan threads, de modo que las aplicaciones los utilizan automáticamente. Esto no es necesariamente malo, pero requerir a los programadores utilizar threads y usar bloqueos correctamente como parte normal de su rutina, y forzarles a ello no porque exista necesidad de paralelizar algo sino "por diseño", no tiene porque ser la mejor decisión del mundo.
En este post, un tipo cuenta como el toolkit gráfico java AWT fue diseñado en un principio como multihilo, al igual que BeOS, pero luego acabaron moviendose a un loop de eventos, porque complicaba las cosas, fomentaba la aparición de fallos y no era necesario. BeOS tenía problemas de estabilidad debido a los fallos derivados de la complejidad de su GUI multihilo, e incluso hubo empresas que paralizaron ports de aplicaciones por los problemas que esto causaba.
En esencia, Haiku no tiene nada especial que lo haga más apto para el aprovechamiento masivo de multiprocesadores. Más allá del soporte de SMP y de threads en el kernel, las capacidades de programación multihilo podrían ser, en todo caso, ser consideradas como una problema del lenguaje: usar threads en C++ viene a ser lo mismo tanto en BeOS como en Linux, y aprovechar las capacidades de concurrencia masiva de Erlang viene a ser lo mismo en ambos sistemas.
· Microkernel: Hay gente que cree que BeOS era un microkernel. Lo cierto es que no lo fue, ni tampoco lo es Haiku. Los drivers, el sistema de archivos, el vfs, la pila de red...todos están en el mismo espacio de direcciones que el kernel. No entiendo de la gente de llamar a esto "microkernel híbrido" o cosas así: en realidad, en este punto BeOS y Haiku vienen a ser similares a Linux.
· Sistema de archivos de 64 bits, con journaling y base de datos: BFS era un buen sistema de archivos en su día, pero el journaling ha dejado de usarse en los sistemas de archivos de última generación, la amplitud del direccionamiento de datos de 64 bits no tiene nada de especial, y le falta la capacidad de comprobar checksums y la gestión de volúmenes integrado para estar al día con ZFS y Btrfs.
Respecto a los índices de atributos que lo convertían en una pseudo base de datos, me parece la característica más importante de BeOS y su innovación más relevante. Sin embargo, lo mismo se puede decir de otros sistemas de archivos que han intentado mezclar sistemas de archivo con bases de datos, como WinFS o Reiser4 (aunque estos fracasaron por aspirar a demasiado, a diferencia de BFS).
Lo cierto es que aunque los índices de atributos eran muy prácticos, no eran una solución completa para una búsqueda integral del sistema: por ejemplo, no podían buscar palabras dentro de un archivo de texto. Para implementar algo como Spotlight, los índices de atributos de Haiku serían útiles, pero no suficientes.
Resumiendo
Si, BeOS fue muy innovador, y si hubiera tenido éxito y se hubiese invertido en él, hubiese sido un gran sistema operativo. Desgraciadamente eso no ocurrió, y el desfase tecnológico pesa demasiado. No tengo nada en contra de Haiku, en contra, me parece interesante, pero de ahí a decir que el escritorio Linux es una castaña y que sólo nos salvaremos con la Segunda Venida de BeOS en forma de Haiku va una gran distancia.
· Sistema operativo de escritorio: BeOS se hizo famoso en su día por la interactividad de su interfaz, rapidez en la respuesta a las acciones del teclado y ratón, y poder reproducir varios vídeos simultaneamente sin ningún problema. Algo que puede resultar poco sorprendente hoy en día, pero que entonces Windows, Linux, y Mac OS no podían hacer.
Sin embargo, trasladar el argumento al presente sería una locura y un olvido de la realidad de mediados-finales de los 90. En aquellos tiempos los sistemas operativos bien diseñados se encontraban en los servidores, los escritorios vivían en una realidad alternativa y eran, por lo general, bastante cutres. Los Windows de la época eran los 9x, ese engendro demoniaco que se iniciaba a partir de MS-DOS, y en el que un proceso cualquiera podía colgar el sistema. Mac OS no tuvo multitarea apropiativa ("preemptive") hasta la versión 9.0, sólo dos años antes de la aparición de OS X. Respecto a Linux, sus características de servidor eran sólidas, pero su implementación interna no era nada óptima para un escritorio. Estamos hablando de los tiempos de Linux 2.0, la primera versión que soportaba SMP y que, desde luego, no soportaba ninguna clase de "preemptitividad": Cuando un proceso hacía una llamada al sistema, el resto de procesos tenían que esperar a que terminara si ellos querían hacer otra. Para un sistema de escritorio algo así era monstruoso.
Que BeOS fuese un buen sistema de escritorio y otros muy malos no tiene nada de sorprendente, como tampoco lo tiene que los que fueron malos se hayan convertido a base de trabajo en buenos, mientras que BeOS y Haiku han ido empeorando debido a las exigencias elementales del hardware moderno: Haiku carece de capacidades elementales de gestión de energía y ni tan siquiera puede suspender a memoria, por ejemplo.
· Sistema gráfico: El subsistema gráfico de BeOS era excelente, pero fue diseñado para un mundo 2D, pre-GPU, donde las cosas eran muy diferentes a lo que son hoy. El soporte 3D sólo existió como algo experimental y, desde luego, no tomaba parte en los gráficos de la interfaz.
Todos los sistemas operativos llevan varios años rediseñando por entero sus subsistemas gráficos -arquitectura de los drivers del kernel, servidor gráfico, toolkits- para adaptarse a la nueva realidad de la potencia de las GPUs, y aunque ya se usa todo este trabajo en los toolkits para pantallas táctiles, aun no hemos empezado a ver de verdad los resultados visuales de todo esto (imagínense un escritorio donde los iconos no sean simples imágenes a los cuales el diseñador pinta un sombreado para dar sensación de profundidad, sino objetos 3D con sombra generada por la GPU y capaces de reaccionar con animaciones complejas, como en un juego).
Haiku lleva mucho retraso frente a los toolkits actuales. Aun no implementa la capacidad de "compositing" que les permitiría soñar con imitar los efectos que Compiz hacía hace años, no digamos ya frente a cosas como Wayland + QML.
· Multithreading: Una de las decisiones que hicieron los diseñadores de BeOS fue optimizar para ordenadores con múltiples procesadores: aunque su predicción se retrasó una década, está claro que acertaron en su visión.
Sin embargo, existe mucha mitificación al respecto de lo que BeOS llamó "Pervasive Multithreading". En realidad, se reducía a utilizar threads por doquier (una solución inferior a la de Grand Central Dispatch en iOS), sobre una base de código fundamentalmente en C++. En los 90, el soporte de threads en Linux era patético y lo de BeOS podía resultar llamativo, pero hoy en día no tiene nada de particular. De hecho, un escritorio Linux moderno utiliza bastantes threads: Mi firefox usa nada menos que 31, el lector de correo 3, el programa de música 12, el lector de feeds 2. A veces echo de menos que los programadores no aprovechen más otras CPUs, pero es una cuestión de vagancia, más que de incapacidad técnica.
Bien es cierto que BeOS tiene el mérito de haber usado threads como parte fundamental del diseño de las librerías básicas del sistema, y que varios objetos de la API de BeOS usan threads, de modo que las aplicaciones los utilizan automáticamente. Esto no es necesariamente malo, pero requerir a los programadores utilizar threads y usar bloqueos correctamente como parte normal de su rutina, y forzarles a ello no porque exista necesidad de paralelizar algo sino "por diseño", no tiene porque ser la mejor decisión del mundo.
En este post, un tipo cuenta como el toolkit gráfico java AWT fue diseñado en un principio como multihilo, al igual que BeOS, pero luego acabaron moviendose a un loop de eventos, porque complicaba las cosas, fomentaba la aparición de fallos y no era necesario. BeOS tenía problemas de estabilidad debido a los fallos derivados de la complejidad de su GUI multihilo, e incluso hubo empresas que paralizaron ports de aplicaciones por los problemas que esto causaba.
En esencia, Haiku no tiene nada especial que lo haga más apto para el aprovechamiento masivo de multiprocesadores. Más allá del soporte de SMP y de threads en el kernel, las capacidades de programación multihilo podrían ser, en todo caso, ser consideradas como una problema del lenguaje: usar threads en C++ viene a ser lo mismo tanto en BeOS como en Linux, y aprovechar las capacidades de concurrencia masiva de Erlang viene a ser lo mismo en ambos sistemas.
· Microkernel: Hay gente que cree que BeOS era un microkernel. Lo cierto es que no lo fue, ni tampoco lo es Haiku. Los drivers, el sistema de archivos, el vfs, la pila de red...todos están en el mismo espacio de direcciones que el kernel. No entiendo de la gente de llamar a esto "microkernel híbrido" o cosas así: en realidad, en este punto BeOS y Haiku vienen a ser similares a Linux.
· Sistema de archivos de 64 bits, con journaling y base de datos: BFS era un buen sistema de archivos en su día, pero el journaling ha dejado de usarse en los sistemas de archivos de última generación, la amplitud del direccionamiento de datos de 64 bits no tiene nada de especial, y le falta la capacidad de comprobar checksums y la gestión de volúmenes integrado para estar al día con ZFS y Btrfs.
Respecto a los índices de atributos que lo convertían en una pseudo base de datos, me parece la característica más importante de BeOS y su innovación más relevante. Sin embargo, lo mismo se puede decir de otros sistemas de archivos que han intentado mezclar sistemas de archivo con bases de datos, como WinFS o Reiser4 (aunque estos fracasaron por aspirar a demasiado, a diferencia de BFS).
Lo cierto es que aunque los índices de atributos eran muy prácticos, no eran una solución completa para una búsqueda integral del sistema: por ejemplo, no podían buscar palabras dentro de un archivo de texto. Para implementar algo como Spotlight, los índices de atributos de Haiku serían útiles, pero no suficientes.
Resumiendo
Si, BeOS fue muy innovador, y si hubiera tenido éxito y se hubiese invertido en él, hubiese sido un gran sistema operativo. Desgraciadamente eso no ocurrió, y el desfase tecnológico pesa demasiado. No tengo nada en contra de Haiku, en contra, me parece interesante, pero de ahí a decir que el escritorio Linux es una castaña y que sólo nos salvaremos con la Segunda Venida de BeOS en forma de Haiku va una gran distancia.
5 de octubre de 2012
Oracleización de Solaris
Cuando Oracle compró Sun, algunos temimos que la principal desgracia para Solaris iba a ser el proceso de oracleización, en el sentido de que Solaris iba a dejar de ser poco a poco un sistema operativo de propósito general, para convertirse en uno de un sólo propósito específico. Ese propósito específico sería, por supuesto, ejecutar la base de datos de Oracle y middleware de la misma compañía.
Sun, ya de por si, había convertido a Solaris en un "Oracle OS", pero en manos de Oracle cabe imaginar que el efecto se multiplicaría hasta convertirse en el principal factor de diseño. Algo que también funciona en el sentido contrario: cabía esperar que OracleDB acabara centrándose en Solaris e incluso dependiendo de él para funcionar bien. Hoy, en el anuncio de Solaris 11.1, se puede comprobar la existencia de esa tendencia:
Aunque no tengo detalles tećnicos (ni espero conseguirlos) sobre la implementación de esta característica, el transfondo está claro, como lo está el de otras cuantas características incluídas en esta versión que se han hecho para facilitar, de una u otra manera, la vida a OracleDB.
Pero una vez que los problemas de rendimiento de la base de datos se resuelven modificando el SO, es inevitable que se preste menos atención a los problemas de rendimiento en otros SOs que no tienen esas mismas características u optimizaciones, y que no se molesten en implementar en OracleDB cosas que si implementarían de no controlar directamente Solaris. Es más, en el anuncio de Solaris 11.1 usan esta frase como marketing: "Adds Unique Oracle Database Support". ¡Se sienten orgullosos de que OracleDB no funcione bien en otros SOs!
Poco a poco, sólo merecerá la pena usar OracleDB para ejecutarlo en Solaris, y sólo merecerá la pena usar Solaris para ejecutar OracleDB.
Sun, ya de por si, había convertido a Solaris en un "Oracle OS", pero en manos de Oracle cabe imaginar que el efecto se multiplicaría hasta convertirse en el principal factor de diseño. Algo que también funciona en el sentido contrario: cabía esperar que OracleDB acabara centrándose en Solaris e incluso dependiendo de él para funcionar bien. Hoy, en el anuncio de Solaris 11.1, se puede comprobar la existencia de esa tendencia:
"Improve Oracle Real Application Clusters lock latency by 17% by offloading lock management into the Oracle Solaris kernel"
Aunque no tengo detalles tećnicos (ni espero conseguirlos) sobre la implementación de esta característica, el transfondo está claro, como lo está el de otras cuantas características incluídas en esta versión que se han hecho para facilitar, de una u otra manera, la vida a OracleDB.
Pero una vez que los problemas de rendimiento de la base de datos se resuelven modificando el SO, es inevitable que se preste menos atención a los problemas de rendimiento en otros SOs que no tienen esas mismas características u optimizaciones, y que no se molesten en implementar en OracleDB cosas que si implementarían de no controlar directamente Solaris. Es más, en el anuncio de Solaris 11.1 usan esta frase como marketing: "Adds Unique Oracle Database Support". ¡Se sienten orgullosos de que OracleDB no funcione bien en otros SOs!
Poco a poco, sólo merecerá la pena usar OracleDB para ejecutarlo en Solaris, y sólo merecerá la pena usar Solaris para ejecutar OracleDB.
2 de octubre de 2012
Las novedades de Linux 3.6
Ya se ha anunciado la
versión 3.6 del kernel Linux. Esta versión incluye soporte de cuotas de espacio en subvolúmenes de Btrfs, así como grupos de cuota, diffs de snapshots, y mayor libertad para el uso de clones de archivos. También se soporta un modo suspensión híbrida en el que se suspende al disco y a la memoria al mismo tiempo, un modo de apertura rápida de conexiones para TCP, un sistema para límitar la longitud de las colas de TCP, soporte para swap seguro a través de NFS y NBD, soporte para el protocolo SMB v2, mejoras en el soporte de cuotas de Ext4, soporte para el estado energético D3cold en el bus PCIe, y VFIO, que permite el acceso directo y seguro a los dispositivos de hardware por parte de máquinas virtuales. 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.
· Btrfs: cuotas en subvolúmenes, grupos de cuotas, diffs de snapshots, clones de archivo a través de subvolúmenes
· Cuotas de subvolúmenes y grupos de cuotas: Se puede configurar un tamaño máximo para cada subvolumen. Una vez que el subvolumen llegue al límite, no será posible escribir más en él. Esta característica puede utilizarse como sustituto de las cuotas de disco tradicionales, asignando a cada cuenta de usuario un subvolumen y poniéndole un límite.
Sin embargo, gestionar las cuotas de cada subvolumen puede ser complicado si se tienen muchos archivos. Por ello, Btrfs soporta el concepto de grupos de cuota. Es posible crear un grupo de cuota e introducir en él varios subvolúmenes, para que se aplique un límite común a todos ellos.
· Diffs de snapshots, también conocido como "send/receive": Btrfs puede compilar las diferencias entre dos snapshots y enviar las diferencias entre ambos a un archivo. Este archivo puede ser usado posteriormente para reconstruir esas diferencias. El principal, aunque no único, uso de esta característica, son las copias de seguridad.
· Archivos clonados trans-subvolumen: El mecanismo de copy-on-write de Btrfs permite que varios archivos compartan los mismos datos. Esto permite copiar árboles de directorio enteros (cp --reflink) sin duplicar el espacio utilizado. Pero existía una limitación: No es posible clonar archivos a través de diferentes subvolúmenes. Esta limitación ha sido eliminada (aun es imposible clonar archivos que cruzan diferentes puntos de montaje)
· Suspensión híbrida al disco y a la memoria al mismo tiempo: En los equipos portátiles que usan batería, es útil que al suspender, se hagan dos suspensiones: una al disco, como si fuera una hibernación pero sin apagar el sistema, y despues de esa una suspensión en memoria. Si al equipo se le acaba la batería, es posible despertar el equipo desde la imagen de hibernación; si no, se despierta normalmente. Este sistema es utilizado por OS X y Windows. Para probarlo, puedes hacer "echo suspend > /sys/power/disk; echo disk > /sys/power/state".
· Soporte para el protocolo SMB v2: El sistema de red cifs ha añadido soporte para la versión 2 del protocolo SMB. El protocolo SMB2 es el sucesor de los populares CIFS y SMB, y es el protocolo de invercambio de archivos por defecto en sistemas Windows desde Windows Vista en 2006. SMB2 eventualmente permitirá mejor rendimiento y seguridad y características que no eran posible con anteriores versiones del protocolo.
· TCP Fast Open: "Fast Open" es una optimización al proceso de establecimiento de una conexión TCP que permite eliminar un round time trip (RTT) de ciertas conexiones. Fast Open puede mejorar la carga de páginas entre un 4 y un 41%. En esta versión sólo se incluye el soporte para cliente, el de servidor llegará en próximas versiones.
· Lucha contra el bufferbloat: TCP small queues: TCP "small queues" (colas pequeñas) es otro mecanismo diseñado para luchar contra el mal del bufferbloat. Su objetivo es reducir el número de paquetes en las colas de envio. Sin reducción nominal del ancho de banda, se consiguen grandes mejoras en la latencia
· Swap seguro sobre NFS/NBD: El Linux Terminal Server Project recomienda el uso de un dispositivo de bloque por red (NBD) para configurar el swap, de acuerdo con el manual. También hay documentación y tutoriales de como hacerlo en varios sitios, y el propio nbd-client documenta su uso para tales fines. A pesar de eso, una máquina usando NBD para swap podía colgarse en minutos si se usaba el swap intensivamente. Esta versión permite usar swap sobre NBD y también sobre NFS de forma totalmente segura.
· Mejor soporte de cuotas de disco en Ext4: Ext4 ha añadido soporte para cuotas como una característica de primera clase, lo cual significa que en lugar de ser archivos visibles en la jerarquía de directorios, los archivos de cuota se almacenarán en inodos ocultos al usuario, como metadatos del sistema de archivos, y serán gestionados directamente por e2fsprogs, y las cuotas serán activadas automáticamente tan pronto como el sistema de archivos sea montado.
· Soporte del estado de energía D3cold en PCIe: Esta versión añade soporte para el estado energético D3cold. D3cold es el estado energético más profundo en un dispositivo PCIe, ya que la energía se desconecta completamente para el dispositivo.
· VFIO: acceso seguro a dispositivo desde drivers de espacio de usuario: El driver VFIO es un framework que permite exponer directamente dispositivos a espacio de usuario de un modo seguro. En otras palabras, permite drivers en espacio de usuario totalmente seguros y no privilegiados. ¿Para qué quiere Linux algo así? Los sistemas de virtualización hacen uso frecuente del acceso directo a los dispositivos para lograr el máximo rendimiento. Desde un punto de vista del host y del dispositivo, esto simplemente convierte a la VM virtualizada en un driver de espacio de usuario, con el beneficio de latencia reducida, mayor ancho de banda, y acceso directo del driver. Algunas aplicaciones, particularmente las relacionadas con la computación de alto rendimiento, también se benefician del acceso directo a dispositivos desde el espacio de usuario,
Y eso es todo. La lista completa de cambios en inglés, aquí.
· Btrfs: cuotas en subvolúmenes, grupos de cuotas, diffs de snapshots, clones de archivo a través de subvolúmenes
· Cuotas de subvolúmenes y grupos de cuotas: Se puede configurar un tamaño máximo para cada subvolumen. Una vez que el subvolumen llegue al límite, no será posible escribir más en él. Esta característica puede utilizarse como sustituto de las cuotas de disco tradicionales, asignando a cada cuenta de usuario un subvolumen y poniéndole un límite.
Sin embargo, gestionar las cuotas de cada subvolumen puede ser complicado si se tienen muchos archivos. Por ello, Btrfs soporta el concepto de grupos de cuota. Es posible crear un grupo de cuota e introducir en él varios subvolúmenes, para que se aplique un límite común a todos ellos.
· Diffs de snapshots, también conocido como "send/receive": Btrfs puede compilar las diferencias entre dos snapshots y enviar las diferencias entre ambos a un archivo. Este archivo puede ser usado posteriormente para reconstruir esas diferencias. El principal, aunque no único, uso de esta característica, son las copias de seguridad.
· Archivos clonados trans-subvolumen: El mecanismo de copy-on-write de Btrfs permite que varios archivos compartan los mismos datos. Esto permite copiar árboles de directorio enteros (cp --reflink) sin duplicar el espacio utilizado. Pero existía una limitación: No es posible clonar archivos a través de diferentes subvolúmenes. Esta limitación ha sido eliminada (aun es imposible clonar archivos que cruzan diferentes puntos de montaje)
· Suspensión híbrida al disco y a la memoria al mismo tiempo: En los equipos portátiles que usan batería, es útil que al suspender, se hagan dos suspensiones: una al disco, como si fuera una hibernación pero sin apagar el sistema, y despues de esa una suspensión en memoria. Si al equipo se le acaba la batería, es posible despertar el equipo desde la imagen de hibernación; si no, se despierta normalmente. Este sistema es utilizado por OS X y Windows. Para probarlo, puedes hacer "echo suspend > /sys/power/disk; echo disk > /sys/power/state".
· Soporte para el protocolo SMB v2: El sistema de red cifs ha añadido soporte para la versión 2 del protocolo SMB. El protocolo SMB2 es el sucesor de los populares CIFS y SMB, y es el protocolo de invercambio de archivos por defecto en sistemas Windows desde Windows Vista en 2006. SMB2 eventualmente permitirá mejor rendimiento y seguridad y características que no eran posible con anteriores versiones del protocolo.
· TCP Fast Open: "Fast Open" es una optimización al proceso de establecimiento de una conexión TCP que permite eliminar un round time trip (RTT) de ciertas conexiones. Fast Open puede mejorar la carga de páginas entre un 4 y un 41%. En esta versión sólo se incluye el soporte para cliente, el de servidor llegará en próximas versiones.
· Lucha contra el bufferbloat: TCP small queues: TCP "small queues" (colas pequeñas) es otro mecanismo diseñado para luchar contra el mal del bufferbloat. Su objetivo es reducir el número de paquetes en las colas de envio. Sin reducción nominal del ancho de banda, se consiguen grandes mejoras en la latencia
· Swap seguro sobre NFS/NBD: El Linux Terminal Server Project recomienda el uso de un dispositivo de bloque por red (NBD) para configurar el swap, de acuerdo con el manual. También hay documentación y tutoriales de como hacerlo en varios sitios, y el propio nbd-client documenta su uso para tales fines. A pesar de eso, una máquina usando NBD para swap podía colgarse en minutos si se usaba el swap intensivamente. Esta versión permite usar swap sobre NBD y también sobre NFS de forma totalmente segura.
· Mejor soporte de cuotas de disco en Ext4: Ext4 ha añadido soporte para cuotas como una característica de primera clase, lo cual significa que en lugar de ser archivos visibles en la jerarquía de directorios, los archivos de cuota se almacenarán en inodos ocultos al usuario, como metadatos del sistema de archivos, y serán gestionados directamente por e2fsprogs, y las cuotas serán activadas automáticamente tan pronto como el sistema de archivos sea montado.
· Soporte del estado de energía D3cold en PCIe: Esta versión añade soporte para el estado energético D3cold. D3cold es el estado energético más profundo en un dispositivo PCIe, ya que la energía se desconecta completamente para el dispositivo.
· VFIO: acceso seguro a dispositivo desde drivers de espacio de usuario: El driver VFIO es un framework que permite exponer directamente dispositivos a espacio de usuario de un modo seguro. En otras palabras, permite drivers en espacio de usuario totalmente seguros y no privilegiados. ¿Para qué quiere Linux algo así? Los sistemas de virtualización hacen uso frecuente del acceso directo a los dispositivos para lograr el máximo rendimiento. Desde un punto de vista del host y del dispositivo, esto simplemente convierte a la VM virtualizada en un driver de espacio de usuario, con el beneficio de latencia reducida, mayor ancho de banda, y acceso directo del driver. Algunas aplicaciones, particularmente las relacionadas con la computación de alto rendimiento, también se benefician del acceso directo a dispositivos desde el espacio de usuario,
Y eso es todo. La lista completa de cambios en inglés, aquí.
Suscribirse a:
Entradas (Atom)