Ya se ha anunciado la versión 4.0 de Linux. Esta versión añade soporte para parchear el kernel en vivo, con el objetivo principal de corregir fallos de seguridad sin reiniciar; también se añade DAX, un sistema para evitar utilizar el cache del kernel cuando los sistemas de archivo funcionan en sistemas con almacenamiento de memoria persistente; kasan, un detector de errores de memoria de use-after-free y out-of-bounds; lazytime, una alternativa a relatime, que provoca que las modificaciones a los metadatos de archivos como atime se hagan sólo en cache y se escriban al disco de modo oportunista para mejorar el rendimiento; overlayfs añade soporte para tener múltiples capas inferiores; se añade soporte de Parallel NFS; y dm-crypt tiene importantes mejoras de escalabilidad. 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.
· Cambio de versión completamente abitrario
Esta versión incrementa la versión a 4.0. Esta cambio de 3.x a 4.0 no tiene ningún significado particular y no debe ser asociado con ningún cambio técnico de relevancia en el kernel. Esta versión podía haber sido la 3.20, pero Linus Torvalds se cansó del numero 3, hizo una encuesta, y lo cambio. Si, es frívolo. Cuanto menos piense sobre ello, mejor.
· Parcheado en vivo
Esta versión incluye "livepatch", una caraterística que permite parchear el código del kernel en tiempo de ejecución, y que está orientada fundamentalmente a aquellas personas que quieran tener actualizaciones de seguridad sin necesidad de reiniciar. Esta característica nació como resultado de la fusión de kgraft y kpatch, dos intentos de SuSE y Red Hat que fueron iniciados para reemplazar el ahora propietario ksplice. Es relativamente simple y minimalista, y hace uso extensivo de infraestructura ya existente en el kernel (ftrace). El código está contenido en su propio directorio y no necesita "enganches" en el resto de subsystemas.
En esta versión livepatch no está completo, pero ya proporciona soporte para parchear funciones, incluye una API para los módulos del kernel que contengan los parches, y una API/ABI para espacio de usuario que permite operar los parches (ver cuáles están activos, activarlos, desactivarlos, etc). La mayoría de los CVEs pueden aplicarse de este modo. En esta versión sólo se soporta la arquitectura x86, otras llegarán en futuras versiones.
· DAX, acceso directo para sistemas con almacenamiento de memoria persistente
Antes de que sean leídos por los programas, los archivos se copian primero a los caches del kernel, que se encuentran en la memoria RAM. Pero es posible que en los próximos años se popularicen los sistemas basados en la llamada "memoria persistente", que proporcionan enormes cantidades de almacenamiento con velocidades de acceso equivalentes a la memoria RAM y mantendrían los contenidos a pesar de cortes de energía. En estos sistemas, no habría una separación RAM-disco, sino que la memoria persistente es al mismo tiempo memoria RAM y espacio de almacenamiento. En una arquitectura así, los caches del kernel son redundantes.
Linux ha tenido cierto soporte para este tipo de sistemas desde 2.6.13. Pero el código no estaba siendo mantenido y sólo soportaba ext2. En esta versión, Linux añade una nueva implementación llamada DAX. DAX elimina la copia extra de los caches haciendo que las lecturas y escrituras se hagan directamente almacenamiento de memoria persistente. En esta versión se añade soporte para ext4.
· kasan, detector de errores de gestión de memoria en el código
Kernel Address sanitizer (KASan) es un detector de errores que detecta bugs use-after-free y out-of-bounds bugs. Linux ya tiene kmemcheck, pero a diferencia de kmemcheck, KASan utiliza instrumentación en tiempo de compilado, lo cual lo hace significativamente más rápido que kmemcheck.
La idea principal de KASan es almacenar información sobre la seguridad de acceder cada byte de memoria o no, y usar la instrumentación del compilador para comprobar esa información en cada acceso de memoria. KASan utiliza 1/8 de la memoria direccionable por el kernel para mantener esta información.
· lazytime para una actualización de los tiempos de un archivo más eficiente
Los sistemas Unix mantienen información variada sobre los archivos, tal y como la última vez que un archivo fue accedido o modificado. Mantener esta información es costoso, especialmente la información sobre cuándo fue accedido un archivo por última vez ("atime"), que animó a mucha gente durante mucho tiempo a desactivar la actualización de ese campo con la opción "noatime". Para aliviar este problema se añadió la opción "relatime", que sólo modificaba el campo atime si el archivo había sido modificado hace más de 24 horas. Este comportamiento, sin embargo, provoca errores en ciertos programas que requieren una actualización precisa de atime, y además va en contra del estándar POSIX.
En esta versión, Linux añade otra alternativa, "lazytime". Lazytime hace que los tiempos de acceso, modificación y cambio se hagan sólo al cache. Los tiempos serán sólo escritos al disco si el inodo es actualizado por otra razón, o si se utilizan llamadas al sistema como fsync(), syncfs() o sync(), o antes de que el caché del inodo vaya a eliminarse de la memoria. Esta manera de funcionar está de acuerdo con POSIX, hace funcionar a los programas que rompía "relatime", y, además, mejora el rendimiento.
· Múltiples capas inferiores en overlayfs
En overlayfs, ahora es posible especificar múltiples capas inferiores. Para hacerlo, se puede utilizar los dos puntos (":") como separador entre los diferentes directorios. Por ejemplo:
mount -t overlay overlay -olowerdir=/lower1:/lower2:/lower3 /merged
Los directorios inferiores especificados se apilarán uno encima del otro desde el de la derecha al de la izquierda. En el ejemplo anterior lower1 estará arriba del todo, lower2 en el medio y lower3 abajo. "upperdir" y "workdir" pueden omitirse, aunque en ese caso el overlay será de sólo lectura.
· Soporte de servidor de Parallel NFS, NFS v4.2 por defecto
Parallel NFS (pNFS) es parte del estándar NFS v4.1 que permite a los clientes acceder a dispositivos de almacenamiento directamente y en paralelo. La arquitectura pNFS elimina los problemas de escalabilidad y rendimiento asociados con los servidores NFS hoy. Esto se logra mediante la separación de datos y metadatos, y moviento los servidores de metadatos fuera de la ruta principal de acceso a los datos.
Esta versión añade soporte para tener un servidor pNFS en Linux, y se proporcionan drivers para el layout "block", junto con el soporte para utilizar ese layout en sistemas de archivo XFS. También se añade el layout "flexfiles".
Además, en esta versión la versión por defecto del servidor NFS será NFS v4.2.
· Mejoras de escalabilidad de dm-crypt
Esta versión incrementa significativamente el rendimiento y escalabilidad de CPU de dm-crypt, gracias a unos cambios que permiten un uso más efectivo de todas las CPUs. Los resultados de una serie de tests y benchmarks pueden encontrarse aquí.
Y eso es todo. La lista completa de cambios en inglés, aquí.
2 de mayo de 2015
21 de marzo de 2015
La revolución de Docker
El otro día hablaba de Snappy, el nuevo sistema de paquetes de Ubuntu. La verdad es que este nuevo sistema forma parte de toda una sorprendente ola-moda de virtualización a nivel de sistema de operativo, generalmente de mano de Docker, un software que en muy poco tiempo se ha hecho omnipresente en todas las fiestas. ¿Por qué demonios de repente la virtualización a nivel de sistema operativo de mano de Docker está tan de moda?
En principio, la virtualización a nivel de sistema operativo no es demasiado nueva. Durante muchos años, se ha oído a FreeBSD presumir de sus jails, y a OpenSolaris de sus zones. En el caso de FreeBSD, sus jaulas existen desde al menos FreeBSD 4.0, publicado en el año 2000, y durante muchos años, esa característica ha sido una de las razones por las que la gente usaba FreeBSD. Linux carecía de soporte de algo equivalente, y aunque existían parches extraoficiales de Linux-VServer desde 2001, sólo atraía la atención de casos particulares: La gente no huía masivamente de Linux por no tener estas capacidades integradas.
Con el tiempo -más de una década- el Linux oficial ha ido añadiendo diversos espacios de nombres, que son las columnas que permiten implementar este tipo de virtualización. Pero incluso cuando se implementó, tampoco parece que se le diera más importancia de la que se daba anteriormente a VServer y OpenVZ. Hasta que llegó Docker.
Docker. Docker por un lado, Docker por otro, Docker para todo y en todos sitios. Si leen sitios de noticias sobre software libre o programación ya se habrán acostumbrado a (y quizás cansado de) leer noticias relacionadas con Docker. Y es que Docker se ha extendido a gran velocidad. Su código fuente fue publicado en Marzo de 2013. Dos años después, ya es una plataforma soportada en Amazon EC2, Google Cloud y Microsoft Azure. La compañía líder en Linux, Red Hat, anunció un proyecto específico para Docker ya en Abril de 2014, "Atomic Host", y la primera versión estable se publicó a principios de este mes. Y nada menos que Microsoft ya ha anunciado que va a añadir soporte de Docker en la próxima versión de Windows Server. También VMware, que en principio podría parecer un rival, se apunta a Docker.
A un software que tenga la capacidad de alcanzar semejante estatus en tan sólo dos años no hay más remedio que describirlo como revolucionario. Y si en dos años ha tenido el efecto que ha tenido, cabe esperar que en los próximos años la expansión de Docker tenga muchas ramificaciones. Pero eso no responde a la pregunta de ¿por qué de repente hay tanta moda de virtualización de sistema operativo?
En realidad, no creo que haya un gran interés en esta clase de virtualización. Lo que hace a Docker interesante no es tanto su gestión de contenedores, habilidad en la que Docker no es superior a otras herramientas, sino su capacidad para facilitar la gestión de la implementación de "aplicaciones". El registro público de imágenes es una App Store más. No importa tanto el tipo de virtualización sobre el que se ejecuta una imagen (tal y como prueba el hecho de que Microsoft y VMware quieran portar Docker a sus plataformas), lo que importa es poder acceder a la App Store de turno. Del mismo modo que lo que hace relevante a un teléfono hoy es acceder a las tienda de aplicaciones de Android o iOS, existe la posibilidad de que estemos avanzando hacia una situación en la que un sistema que no tenga acceso a la "tienda de aplicaciones Docker", si bien estaría muy lejos de ser un sistema inutil, quedaría marginado por no poder acceder a las aplicaciones de moda.
La revolución de Docker no sería por tanto "la revolución de Docker", sino un capítulo más de la revolución de las tiendas de aplicaciones.
Por otro lado, esto no haría más que reafirmar la tendencia de cambio hacia un modelo en el que los repositorios Linux tradicionales quedan obsoletos como sistema para distribuir aplicaciones, y por tanto ponen en duda la esencia de muchas grandes distribuciones Linux. Ubuntu, con su Snappy, es de las primeras grandes distribuciones en prestar atención a este fenómeno, pero está por ver que otras hagan lo mismo. Será interesante observar lo que pase en los próximos años.
En principio, la virtualización a nivel de sistema operativo no es demasiado nueva. Durante muchos años, se ha oído a FreeBSD presumir de sus jails, y a OpenSolaris de sus zones. En el caso de FreeBSD, sus jaulas existen desde al menos FreeBSD 4.0, publicado en el año 2000, y durante muchos años, esa característica ha sido una de las razones por las que la gente usaba FreeBSD. Linux carecía de soporte de algo equivalente, y aunque existían parches extraoficiales de Linux-VServer desde 2001, sólo atraía la atención de casos particulares: La gente no huía masivamente de Linux por no tener estas capacidades integradas.
Con el tiempo -más de una década- el Linux oficial ha ido añadiendo diversos espacios de nombres, que son las columnas que permiten implementar este tipo de virtualización. Pero incluso cuando se implementó, tampoco parece que se le diera más importancia de la que se daba anteriormente a VServer y OpenVZ. Hasta que llegó Docker.
Docker. Docker por un lado, Docker por otro, Docker para todo y en todos sitios. Si leen sitios de noticias sobre software libre o programación ya se habrán acostumbrado a (y quizás cansado de) leer noticias relacionadas con Docker. Y es que Docker se ha extendido a gran velocidad. Su código fuente fue publicado en Marzo de 2013. Dos años después, ya es una plataforma soportada en Amazon EC2, Google Cloud y Microsoft Azure. La compañía líder en Linux, Red Hat, anunció un proyecto específico para Docker ya en Abril de 2014, "Atomic Host", y la primera versión estable se publicó a principios de este mes. Y nada menos que Microsoft ya ha anunciado que va a añadir soporte de Docker en la próxima versión de Windows Server. También VMware, que en principio podría parecer un rival, se apunta a Docker.
A un software que tenga la capacidad de alcanzar semejante estatus en tan sólo dos años no hay más remedio que describirlo como revolucionario. Y si en dos años ha tenido el efecto que ha tenido, cabe esperar que en los próximos años la expansión de Docker tenga muchas ramificaciones. Pero eso no responde a la pregunta de ¿por qué de repente hay tanta moda de virtualización de sistema operativo?
En realidad, no creo que haya un gran interés en esta clase de virtualización. Lo que hace a Docker interesante no es tanto su gestión de contenedores, habilidad en la que Docker no es superior a otras herramientas, sino su capacidad para facilitar la gestión de la implementación de "aplicaciones". El registro público de imágenes es una App Store más. No importa tanto el tipo de virtualización sobre el que se ejecuta una imagen (tal y como prueba el hecho de que Microsoft y VMware quieran portar Docker a sus plataformas), lo que importa es poder acceder a la App Store de turno. Del mismo modo que lo que hace relevante a un teléfono hoy es acceder a las tienda de aplicaciones de Android o iOS, existe la posibilidad de que estemos avanzando hacia una situación en la que un sistema que no tenga acceso a la "tienda de aplicaciones Docker", si bien estaría muy lejos de ser un sistema inutil, quedaría marginado por no poder acceder a las aplicaciones de moda.
La revolución de Docker no sería por tanto "la revolución de Docker", sino un capítulo más de la revolución de las tiendas de aplicaciones.
Por otro lado, esto no haría más que reafirmar la tendencia de cambio hacia un modelo en el que los repositorios Linux tradicionales quedan obsoletos como sistema para distribuir aplicaciones, y por tanto ponen en duda la esencia de muchas grandes distribuciones Linux. Ubuntu, con su Snappy, es de las primeras grandes distribuciones en prestar atención a este fenómeno, pero está por ver que otras hagan lo mismo. Será interesante observar lo que pase en los próximos años.
24 de febrero de 2015
KDE Frameworks 5: un ejemplo
Hace 9 días escribí un post sobre KDE Frameworks 5, hoy encontré este buen ejemplo de cómo una aplicación Qt puede aprovechar una librería de KDE Frameworks (KIO) con facilidad.
22 de febrero de 2015
Snappy Ubuntu Core, una manera diferente de gestionar paquetes
Ubuntu anunció hace un tiempo otra versión de Ubuntu: Snappy Ubuntu Core, una especie de equivalente al sistema base de Debian que presenta un nuevo sistema de gestión de software. Su objetivo inicial era presentarlo como plataforma para la nube, más concretamente como plataforma para usar el célebre Docker y así reaccionar frente a CoreOS, que se ha puesto de moda como distro favorita para usar Docker.
Hace alrededor de un mes, Canonical anunció que también promocionarían Snappy Ubuntu Core para la "internet de las cosas" (horripilante expresión que, como ya habrán notado, está de moda), es decir, para sistemas del estilo de Raspberry Pi. La reducción del tamaño, consumo energético y coste de estos sistemas hacen posible empotrar estos sistemas en casi cualquier cosa, y como la flexibilidad de un sistema operativo complejo es infinitamente mayor que el firmware de los circuitos integrados, se prevé que en pocos años empecemos a encontrar estos sistemas en todos lados.
Lo diferente e interesante de Ubuntu Snappy, desde el punto de vista del ecosistema linuxero, es que se deshace por completo del sistema de gestión de paquetes APT. Con toda la literalidad de la expresión. El sistema de gestión de software es el corazón de la identidad de una distro, por lo que estamos ante un cambio importantísimo, y para mi sorpresa muy poco comentado. El cambio es hacia Snappy, un nuevo sistema de gestión de paquetes muy curioso. Snappy es, en concepto, parece ser una imitación y evolución del "updateservicectl" de CoreOS. Técnicamente, es una confluencia de varias tendencias tecnológicas, desde APT al aislamiento de aplicaciones de los teléfonos.
Snappy
Al igual que APT, Snappy (invocado mediante el comando "snappy") consta de repositorios de software. A diferencia de APT, los paquetes no son tal como solemos concebir los paquetes. Existe un paquete llamado "ubuntu-core" que contiene, literalmente, todo el sistema de Snappy Ubuntu Core. Todo. Nada de cientos de paquetes separados, sólo uno para todo el sistema base (es decir, la dirección opuesta a la fisión en infinidad de paquetes que vemos en Debian). Tras el sistema base, existen los "frameworks". Uno de los frameworks posibles es "docker", y es fácil imaginar a "gtk", "qt" o "kde" como ejemplos de otros frameworks que se añadan en el futuro. La finalidad de los frameworks es extender el sistema base.
Luego tenemos las aplicaciones. La diferencia fundamental entre frameworks y aplicaciones es que las aplicaciones están aisladas entre si mediante virtualización con contenedores, y tienen restringido el acceso al sistema de archivos, a la red, a listados de procesos que muestren otros procesos. Una de las consecuencias inmediatas de esta organización es que desaparece el concepto de dependencias al que estamos acostumbrados. Nada de cientos, miles de paquetes, cada uno con una librería, cada uno con su versión, cada uno con sub-dependencias. En Snappy Ubuntu Core, el paquete de sistema y los paquetes de framework son sólo un paquete cada uno, y las aplicaciones sólo pueden depender de frameworks.
La última gran diferencia de este sistema es el carácter transaccional y reversible de las actualizaciones, especialmente las del sistema. Gracias a un extraño sistema con dos particiones, copiado de CoreOS, las actualizaciones de paquetes del sistema se hacen a la partición que no se está utilizando en ese momento, y al arrancar se utiliza la partición con el sistema nuevo. Con "snappy rollback" se puede volver a utilizar la versión anterior del sistema. En el caso de las aplicaciones, se instalan varias aplicaciones en /app/nombredelaapp/1.2.3, y hay un enlace simbólico en /app/nombredelaapp/current a la versión que se desea utilizar.
Por último, destacar el enrevesado proceso de ensamblado de las particiones al arrancar. Las particiones que contienen el sistema son de sólo lectura, no se permite su modificación. Eso hace que sea necesario dedicar una partición extra en la que se almacenan las modificaciones o añadidos a /var o /etc. Es también en esa partición donde se instalan las aplicaciones, y donde se crean los directorios de usuario. Naturalmente, esos juegos de particiones no resultan en un sistema funcional por sí solos, de ahí que al arrancar el sistema tenga que hacer un total de 28 montajes bind de la partición modificable a varias rutas en /etc y /var del sistema principal no modificable.
Consecuencias de Snappy
Snappy es muy interesante porque logra mezclar la muy razonable decisión de ejecutar todas las aplicaciones en entornos aislados, con los repositorios tradicionales linuxeros, al mismo tiempo que añade funciones que deberían ser estándar, y no meras opciones, en cualquier sistema de paquetes moderno (revertido de actualizaciones) y elimina aspectos de los repositorios linuxeros (miles de paquetes y laberintos de dependencias) que quizás deberíamos empezar a cuestionar.
El dilema que puede surgir frente a snappy es que Snappy puede considerarse como algo bueno. Y no sólo bueno: podría incluso considerarse una evolución de los sistemas de paquetes en Linux, algo superior. Y si Snappy es superior, y logra ser mejor que los sistemas de paquetes tradicionales, la evolución lógica sería que Canonical llegase a sustituir en un futuro (futuro no inmediato) a APT por Snappy, con consecuencias impredecibles. Es difícil prever qué pasará exactamente en el futuro (porque hay varios proyectos compitiendo por hacer lo mismo, como Gnome Apps), pero existe la posibilidad de que haya verdaderas revoluciones en las herramientas de gestión de software en el mundo Linux en los próximos años. Snappy bien puede ser sólo el comienzo de una nueva ola.
Hace alrededor de un mes, Canonical anunció que también promocionarían Snappy Ubuntu Core para la "internet de las cosas" (horripilante expresión que, como ya habrán notado, está de moda), es decir, para sistemas del estilo de Raspberry Pi. La reducción del tamaño, consumo energético y coste de estos sistemas hacen posible empotrar estos sistemas en casi cualquier cosa, y como la flexibilidad de un sistema operativo complejo es infinitamente mayor que el firmware de los circuitos integrados, se prevé que en pocos años empecemos a encontrar estos sistemas en todos lados.
Lo diferente e interesante de Ubuntu Snappy, desde el punto de vista del ecosistema linuxero, es que se deshace por completo del sistema de gestión de paquetes APT. Con toda la literalidad de la expresión. El sistema de gestión de software es el corazón de la identidad de una distro, por lo que estamos ante un cambio importantísimo, y para mi sorpresa muy poco comentado. El cambio es hacia Snappy, un nuevo sistema de gestión de paquetes muy curioso. Snappy es, en concepto, parece ser una imitación y evolución del "updateservicectl" de CoreOS. Técnicamente, es una confluencia de varias tendencias tecnológicas, desde APT al aislamiento de aplicaciones de los teléfonos.
Snappy
Al igual que APT, Snappy (invocado mediante el comando "snappy") consta de repositorios de software. A diferencia de APT, los paquetes no son tal como solemos concebir los paquetes. Existe un paquete llamado "ubuntu-core" que contiene, literalmente, todo el sistema de Snappy Ubuntu Core. Todo. Nada de cientos de paquetes separados, sólo uno para todo el sistema base (es decir, la dirección opuesta a la fisión en infinidad de paquetes que vemos en Debian). Tras el sistema base, existen los "frameworks". Uno de los frameworks posibles es "docker", y es fácil imaginar a "gtk", "qt" o "kde" como ejemplos de otros frameworks que se añadan en el futuro. La finalidad de los frameworks es extender el sistema base.
Luego tenemos las aplicaciones. La diferencia fundamental entre frameworks y aplicaciones es que las aplicaciones están aisladas entre si mediante virtualización con contenedores, y tienen restringido el acceso al sistema de archivos, a la red, a listados de procesos que muestren otros procesos. Una de las consecuencias inmediatas de esta organización es que desaparece el concepto de dependencias al que estamos acostumbrados. Nada de cientos, miles de paquetes, cada uno con una librería, cada uno con su versión, cada uno con sub-dependencias. En Snappy Ubuntu Core, el paquete de sistema y los paquetes de framework son sólo un paquete cada uno, y las aplicaciones sólo pueden depender de frameworks.
La última gran diferencia de este sistema es el carácter transaccional y reversible de las actualizaciones, especialmente las del sistema. Gracias a un extraño sistema con dos particiones, copiado de CoreOS, las actualizaciones de paquetes del sistema se hacen a la partición que no se está utilizando en ese momento, y al arrancar se utiliza la partición con el sistema nuevo. Con "snappy rollback" se puede volver a utilizar la versión anterior del sistema. En el caso de las aplicaciones, se instalan varias aplicaciones en /app/nombredelaapp/1.2.3, y hay un enlace simbólico en /app/nombredelaapp/current a la versión que se desea utilizar.
Por último, destacar el enrevesado proceso de ensamblado de las particiones al arrancar. Las particiones que contienen el sistema son de sólo lectura, no se permite su modificación. Eso hace que sea necesario dedicar una partición extra en la que se almacenan las modificaciones o añadidos a /var o /etc. Es también en esa partición donde se instalan las aplicaciones, y donde se crean los directorios de usuario. Naturalmente, esos juegos de particiones no resultan en un sistema funcional por sí solos, de ahí que al arrancar el sistema tenga que hacer un total de 28 montajes bind de la partición modificable a varias rutas en /etc y /var del sistema principal no modificable.
Consecuencias de Snappy
Snappy es muy interesante porque logra mezclar la muy razonable decisión de ejecutar todas las aplicaciones en entornos aislados, con los repositorios tradicionales linuxeros, al mismo tiempo que añade funciones que deberían ser estándar, y no meras opciones, en cualquier sistema de paquetes moderno (revertido de actualizaciones) y elimina aspectos de los repositorios linuxeros (miles de paquetes y laberintos de dependencias) que quizás deberíamos empezar a cuestionar.
El dilema que puede surgir frente a snappy es que Snappy puede considerarse como algo bueno. Y no sólo bueno: podría incluso considerarse una evolución de los sistemas de paquetes en Linux, algo superior. Y si Snappy es superior, y logra ser mejor que los sistemas de paquetes tradicionales, la evolución lógica sería que Canonical llegase a sustituir en un futuro (futuro no inmediato) a APT por Snappy, con consecuencias impredecibles. Es difícil prever qué pasará exactamente en el futuro (porque hay varios proyectos compitiendo por hacer lo mismo, como Gnome Apps), pero existe la posibilidad de que haya verdaderas revoluciones en las herramientas de gestión de software en el mundo Linux en los próximos años. Snappy bien puede ser sólo el comienzo de una nueva ola.
15 de febrero de 2015
Los frutos de la modularidad en KDE 5
El desarrollo de KDE 5 está siendo bastante caótico de cara al público, mucha gente no sabe bien que se está haciendo. Por eso el anuncio de hoy, publicando KDE Frameworks 5.7.0, no dirá mucho a la gente, ni sabrán si esa publicación acerca, o no, a la publicación de un "KDE 5.0". No les culpo, KDE no ha sabido explicar bien sus intenciones, y yo no tengo intención de hacerlo hoy. Pero merece la pena hablar de KDE Frameworks 5, y de los buenos resultados que está teniendo.
La intención de KDE Frameworks 5 es hacer honor a su nombre en el sentido más amplio de la palabra: uno de los principales objetivos ha sido que los usuarios de Qt puedan usar partes de las librerías básicas de KDE, sin tener que usar KDE. Para ello, KDE Frameworks 5 ha dividido la gran masa de código "kdelibs" en 60 pequeñas librerías que ofrecen diferentes funcionalidades, desde KArchive para gestionar archivos comprimidos, KI18n para la internacionalización, KConfig para la gestión de archivos de configuración, o Kemoticons para mostrar emoticonos en lugar de ";)".
Las dependencias que estas librerías tienen entre sí mismas se distinguen con diferentes "tier". Las que no dependen sólo de Qt forman el "Tier 1", el "Tier 2" lo forman las librerías que dependen del "Tier 1", y el "Tier 3" las librerías con dependencias de las anteriores dos. Las dependencias de librerías y funcionalidades externas, no relacionadas con KDE Frameworks, se gestionan dividiendo las librerías en las que no requieren dependencias ("funcional"), las que requieren alguna para la integración en el sistema ("integration"), o las que tienen otras dependencias variadas ("solution").
La consecuencia de esta modularización masiva es que KDE Frameworks pasa a ser, en buena medida, una extensión de funcionalidad para Qt, un verdadero framework que pasa a ser desarrollado independientemente de Plasma y las aplicaciones finales de KDE, y que permite crear aplicaciones Qt que utilicen librerías de KDE Frameworks sin tener que forzar a los usuarios a instalar medio KDE.
Como KDE Frameworks pasa a ser un proyecto complementario de Qt, no debería sorprender que algunas de las librerías de KDE Frameworks hayan sido movidas a Qt: QMimeType proviene de KMimeType, QTemporaryDir de KTempDir, QStandardPaths de KStandardDirs. También se han mejorado otras clases ya existentes, y cuando es posible y recomendable los programadores de KDE intentan mejorar cosas de QT, en lugar de reimplementar cosas por su cuenta.
El broche final como ejemplo de los beneficios de toda esta modularización se puede comprobar con la publicación de LXQt 0.9, un escritorio ligero basado en Qt, fusión de LXDE y razor-qt. En esa versión anunciaron que empezarían a usar un componente de KDE Frameworks, KWindowSystem, para gestionar la interacción con el sistema de ventanas. Reutilizarán un código mejor probado y mantenido por otros, y no sólo se libran de tener la implementación de la misma funcionalidad que hacían por su cuenta, sino que todos los esfuerzos que están haciendo en KDE para que KWindowSystem funcione con Wayland redundarán en su beneficio.
Resumiendo, la modularización de KDE Frameworks 5 supone un gran paso para KDE y el ecosistema Qt. Y aunque no haya un "KDE 5.0", se puede comprobar que el proyecto sigue trabajando mucho y muy bien.
La intención de KDE Frameworks 5 es hacer honor a su nombre en el sentido más amplio de la palabra: uno de los principales objetivos ha sido que los usuarios de Qt puedan usar partes de las librerías básicas de KDE, sin tener que usar KDE. Para ello, KDE Frameworks 5 ha dividido la gran masa de código "kdelibs" en 60 pequeñas librerías que ofrecen diferentes funcionalidades, desde KArchive para gestionar archivos comprimidos, KI18n para la internacionalización, KConfig para la gestión de archivos de configuración, o Kemoticons para mostrar emoticonos en lugar de ";)".
Las dependencias que estas librerías tienen entre sí mismas se distinguen con diferentes "tier". Las que no dependen sólo de Qt forman el "Tier 1", el "Tier 2" lo forman las librerías que dependen del "Tier 1", y el "Tier 3" las librerías con dependencias de las anteriores dos. Las dependencias de librerías y funcionalidades externas, no relacionadas con KDE Frameworks, se gestionan dividiendo las librerías en las que no requieren dependencias ("funcional"), las que requieren alguna para la integración en el sistema ("integration"), o las que tienen otras dependencias variadas ("solution").
La consecuencia de esta modularización masiva es que KDE Frameworks pasa a ser, en buena medida, una extensión de funcionalidad para Qt, un verdadero framework que pasa a ser desarrollado independientemente de Plasma y las aplicaciones finales de KDE, y que permite crear aplicaciones Qt que utilicen librerías de KDE Frameworks sin tener que forzar a los usuarios a instalar medio KDE.
Como KDE Frameworks pasa a ser un proyecto complementario de Qt, no debería sorprender que algunas de las librerías de KDE Frameworks hayan sido movidas a Qt: QMimeType proviene de KMimeType, QTemporaryDir de KTempDir, QStandardPaths de KStandardDirs. También se han mejorado otras clases ya existentes, y cuando es posible y recomendable los programadores de KDE intentan mejorar cosas de QT, en lugar de reimplementar cosas por su cuenta.
El broche final como ejemplo de los beneficios de toda esta modularización se puede comprobar con la publicación de LXQt 0.9, un escritorio ligero basado en Qt, fusión de LXDE y razor-qt. En esa versión anunciaron que empezarían a usar un componente de KDE Frameworks, KWindowSystem, para gestionar la interacción con el sistema de ventanas. Reutilizarán un código mejor probado y mantenido por otros, y no sólo se libran de tener la implementación de la misma funcionalidad que hacían por su cuenta, sino que todos los esfuerzos que están haciendo en KDE para que KWindowSystem funcione con Wayland redundarán en su beneficio.
Resumiendo, la modularización de KDE Frameworks 5 supone un gran paso para KDE y el ecosistema Qt. Y aunque no haya un "KDE 5.0", se puede comprobar que el proyecto sigue trabajando mucho y muy bien.
12 de febrero de 2015
Las novedades de Linux 3.19
Ya se ha anunciado la versión 3.19 de Linux. Esta versión añade soporte en Btrfs para sustitución rápida de dispositivos y scrubbing en RAID 5 y 6, soporte para las extensiones de protección de memoria de Intel, que ayudan a parar la explotación de desbordamientos de búfer, soporte para la arquitectura AMD HSA, soporte para el sistema de depuración ARM Coresight, soporte para la arquitectura Altera Nios II, soporte para la descarga de las funciones de switchs y routers en chips de hardware, soporte para la preasignación y el borrado de partes de archivos, y el sistema IPC de Android, binder, sale de "staging" y se considera estable. 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: Soporte de scrubbing y sustitución rápida de dispositivos con RAID5&6
Btrfs añadió soporte para la sustitución rápida de discos en Linux 3.8, un método para reemplazar un disco por otro más rápido, en un sólo comando (ver btrfs-replace(8)), que hacerlo añadiendo y eliminando manualmente los discos por separado (ver btrfs-device(8)). Esta característica no podía utilizarse en sistemas de archivos que estuviesen utilizando RAID 5 ó 6. En esta versión se ha eliminado esa limitación.
El proceso de hacer scrubbing a un sistema de archivos Btrfs (ver btrfs-scrub(8)) tampoco era posible en sistemas de archivo que usasen RAID 5 ó 6; esta limitación también se ha eliminado.
· Soporte para las extensiones de Protección de Memoria de Intel
Las extensiones MPX de Intel (Memory Protection Extension) son un conjunto de instrucciones de CPU que ayudan a proporcionar fiabilidad al software evitando que las referencias de punteros puedan ser usurpadas maliciosamente por desbordamientos de búfer. Intel MPX introduce nuevos registros y nuevas instrucciones que operan en esos registros. Con compiladores, librerías y kernels modificados, es posible hacer uso de esas instrucciones para que el hardware MPX prevenga la explotación de desbordamientos de búfer. Esta versión de Linux añade soporte para Intel MPX en el kernel. Nota: las CPUs con soporte de MPX aun no están en el mercado y serán introducidas en las microarquitecturas Intel Skylake y Goldmont.
Artículo LWN recomendado: Supporting Intel MPX in Linux.
Artículo de Intel recomendado: Introduction to Intel Memory Protection Extensions
· Controlador HSA para GPUs AMD
HSA ("Heterogeneous System Architecture") es una arquitectura que integra CPUs y GPUs en el mismo bus. HSA permite que varios tipos de procesador (CPUs, DSPs, GPUs, etc) compartan recursos del sistema con mayor efectividad mediante características del hardware como memoria compartida y paginable, colas de trabajos accesibles desde espacio de usuario, etc.
Esta versión incluye soporte de HSA para la familia de procesadores Radeon, y ofrece una API que es utiliza por una librería de software libre desarrollada por AMD, Para más detalles sobre HSA y sobre las posibilidades que HSA ofrece a las aplicaciones de espacio de usuario, ver el anterior enlace.
· Android binder movido a "stable"
El código del "binder" de Android (un IPC específico para Android) ha estado durante años en el área "staging" del kernel, destinado a código que aun no está preparado para ser utilizado por el público. El código en cuestión, sin embargo, es estable ha sido distribuido en todos los millones de teléfonos Android que se han vendido en todos estos años. Hay reticencias sobre binder, pero no importa lo que pase, Linux va a tener que soportar esta API de todos modos, lo cual ha motivado que pase a estar considerado como código estable.
· Soporte de ARM Coresight
Coresight es un paraguas de tecnologías que permiten la depuración en SoCs ARM. ARM ha desarrollado una solución de trazado de software asistido por hardware, compuesta de diferentes partes, cada una de las cuales está destinada a una necesidad de trazado específica.
El framework Coresight de Linux proporciona una interfaz para los drivers que soportan las diferentes partes de Coresight. Ofrece una vista topológica de los componentes de Coresight y configura los diferentes componentes cuando se activa una fuente de trazado. Para más detalles sobre el framework ver Documentation/trace/coresight.txt , para más detalles sobre ARM Coresight ver http://www.arm.com/products/system-ip/debug-trace/
· Nueva arquitectura: Procesadores Altera Nios II
Esta versión añade soporte para los procesadores Altera Nios II. Nios II es una arquitectura de procesadores embebidos de 32 bits, diseñados específicamente para la familia de FPGAs Altera. El procesador Nios II ofrece varias mejoras sobre la arquitectura original Nios, haciéndolo ideal para un amplio rango de aplicaciones embebidas, desde DSPs a sistemas de control. Para más información sobre los procesadores Nios II, ver http://www.altera.com/literature/lit-nio2.jsp
· Device Tree Overlays
El "Device Tree" es una estructura de datos para describir el hardware, esta estructura de datos se pasa al kernel al arrancar, una solución más flexible que tener que incluir cada detalle de los dispositivos en el sistema operativo. Se usa sobre todo en arquitecturas como PowerPC y ARM. El Device Tree está diseñado para sistemas estáticos, y tiene problemas para extenderse a buses de expansión como los que se encuentran en sistemas de consumo como el BeagleBone o Raspberry Pi.
Esta versión introduce soporte para overlays ("superposiciones") en el Device Tree. Los overlays son un método para modificar dinámicamente partes del Device Tree y hacer cambios. Esto hace más sencillo soportar sistemas como los anteriormente citados. Para más información, leer: Device tree overlays.
· Redes: Soporte para descargar el procesado de routers y switchs
Esta versión incluye una infraestructura para soportar chips de switchs y otras operaciones de red. De ese modo, el procesado de esas funciones puede hacerse en el hardware, y así evitar tener que hacerlo en software.
También se incluye el primer driver que utiliza esta infraestructura, un driver "rocker" para el chip de switch emulado en qemu.
· Soporte de preasignación y "hole punching" en NFSv4.2
Esta versión añade soporte para la preasignación de archivos y "hole punching" (eliminación de porciones grandes de un archivo) en NFSv4.2
Y eso es todo. La lista completa de cambios en inglés, aquí.
· Btrfs: Soporte de scrubbing y sustitución rápida de dispositivos con RAID5&6
Btrfs añadió soporte para la sustitución rápida de discos en Linux 3.8, un método para reemplazar un disco por otro más rápido, en un sólo comando (ver btrfs-replace(8)), que hacerlo añadiendo y eliminando manualmente los discos por separado (ver btrfs-device(8)). Esta característica no podía utilizarse en sistemas de archivos que estuviesen utilizando RAID 5 ó 6. En esta versión se ha eliminado esa limitación.
El proceso de hacer scrubbing a un sistema de archivos Btrfs (ver btrfs-scrub(8)) tampoco era posible en sistemas de archivo que usasen RAID 5 ó 6; esta limitación también se ha eliminado.
· Soporte para las extensiones de Protección de Memoria de Intel
Las extensiones MPX de Intel (Memory Protection Extension) son un conjunto de instrucciones de CPU que ayudan a proporcionar fiabilidad al software evitando que las referencias de punteros puedan ser usurpadas maliciosamente por desbordamientos de búfer. Intel MPX introduce nuevos registros y nuevas instrucciones que operan en esos registros. Con compiladores, librerías y kernels modificados, es posible hacer uso de esas instrucciones para que el hardware MPX prevenga la explotación de desbordamientos de búfer. Esta versión de Linux añade soporte para Intel MPX en el kernel. Nota: las CPUs con soporte de MPX aun no están en el mercado y serán introducidas en las microarquitecturas Intel Skylake y Goldmont.
Artículo LWN recomendado: Supporting Intel MPX in Linux.
Artículo de Intel recomendado: Introduction to Intel Memory Protection Extensions
· Controlador HSA para GPUs AMD
HSA ("Heterogeneous System Architecture") es una arquitectura que integra CPUs y GPUs en el mismo bus. HSA permite que varios tipos de procesador (CPUs, DSPs, GPUs, etc) compartan recursos del sistema con mayor efectividad mediante características del hardware como memoria compartida y paginable, colas de trabajos accesibles desde espacio de usuario, etc.
Esta versión incluye soporte de HSA para la familia de procesadores Radeon, y ofrece una API que es utiliza por una librería de software libre desarrollada por AMD, Para más detalles sobre HSA y sobre las posibilidades que HSA ofrece a las aplicaciones de espacio de usuario, ver el anterior enlace.
· Android binder movido a "stable"
El código del "binder" de Android (un IPC específico para Android) ha estado durante años en el área "staging" del kernel, destinado a código que aun no está preparado para ser utilizado por el público. El código en cuestión, sin embargo, es estable ha sido distribuido en todos los millones de teléfonos Android que se han vendido en todos estos años. Hay reticencias sobre binder, pero no importa lo que pase, Linux va a tener que soportar esta API de todos modos, lo cual ha motivado que pase a estar considerado como código estable.
· Soporte de ARM Coresight
Coresight es un paraguas de tecnologías que permiten la depuración en SoCs ARM. ARM ha desarrollado una solución de trazado de software asistido por hardware, compuesta de diferentes partes, cada una de las cuales está destinada a una necesidad de trazado específica.
El framework Coresight de Linux proporciona una interfaz para los drivers que soportan las diferentes partes de Coresight. Ofrece una vista topológica de los componentes de Coresight y configura los diferentes componentes cuando se activa una fuente de trazado. Para más detalles sobre el framework ver Documentation/trace/coresight.txt , para más detalles sobre ARM Coresight ver http://www.arm.com/products/system-ip/debug-trace/
· Nueva arquitectura: Procesadores Altera Nios II
Esta versión añade soporte para los procesadores Altera Nios II. Nios II es una arquitectura de procesadores embebidos de 32 bits, diseñados específicamente para la familia de FPGAs Altera. El procesador Nios II ofrece varias mejoras sobre la arquitectura original Nios, haciéndolo ideal para un amplio rango de aplicaciones embebidas, desde DSPs a sistemas de control. Para más información sobre los procesadores Nios II, ver http://www.altera.com/literature/lit-nio2.jsp
· Device Tree Overlays
El "Device Tree" es una estructura de datos para describir el hardware, esta estructura de datos se pasa al kernel al arrancar, una solución más flexible que tener que incluir cada detalle de los dispositivos en el sistema operativo. Se usa sobre todo en arquitecturas como PowerPC y ARM. El Device Tree está diseñado para sistemas estáticos, y tiene problemas para extenderse a buses de expansión como los que se encuentran en sistemas de consumo como el BeagleBone o Raspberry Pi.
Esta versión introduce soporte para overlays ("superposiciones") en el Device Tree. Los overlays son un método para modificar dinámicamente partes del Device Tree y hacer cambios. Esto hace más sencillo soportar sistemas como los anteriormente citados. Para más información, leer: Device tree overlays.
· Redes: Soporte para descargar el procesado de routers y switchs
Esta versión incluye una infraestructura para soportar chips de switchs y otras operaciones de red. De ese modo, el procesado de esas funciones puede hacerse en el hardware, y así evitar tener que hacerlo en software.
También se incluye el primer driver que utiliza esta infraestructura, un driver "rocker" para el chip de switch emulado en qemu.
· Soporte de preasignación y "hole punching" en NFSv4.2
Esta versión añade soporte para la preasignación de archivos y "hole punching" (eliminación de porciones grandes de un archivo) en NFSv4.2
Y eso es todo. La lista completa de cambios en inglés, aquí.
Suscribirse a:
Entradas (Atom)