openSUSE ha anunciado la incorporación de systemd-boot como cargador de arranque opcional para Tumbleweed, el sistema operativo mutable y rolling release desarrollado por el proyecto comunitario del camaleón.

Los que sigan de cerca a openSUSE sabrán que el proyecto tiene la intención de sustituir GRUB por systemd-boot debido a que este último proporciona “simplicidad y eficiencia, especialmente cuando se maneja el cifrado completo de disco”. Dicho con otras palabras, el propósito es simplificar el soporte el torno al cargador de arranque, el cual se ha vuelto tanto complejo con GRUB.

openSUSE explica a través de su sección de noticias que “los cargadores de arranque tradicionales como GRUB requieren de la incorporación de código de descifrado y funciones de derivación de claves que pueden complicar el código del cargador de arranque y el proceso de arranque, lo que podría ralentizar el sistema en el inicio. Con systemd-boot, estas responsabilidades se delegan al kernel de Linux y al espacio del usuario, lo que ayuda a agilizar el proceso de arranque”.

Otra cosa importante es el soporte para acceder a las instantáneas de Btrfs a través del cargador arranque, sobre todo en Tumbleweed y MicroOS (en un futuro Aeon y Kalpa en el escritorio). Esta característica añade complejidad al propio proceso de arranque, por lo que desde el proyecto esperan mejorar en ese frente mediante la integración de systemd-boot con el sistema de administración de instantáneas, garantizando así que cada instantánea se inicie correctamente y que las actualizaciones del kernel sean bien gestionadas dentro un entorno que resulta bastante dinámico.

Para integrar la gestión de las versiones del kernel, las instantáneas y el propio arranque en systemd-boot, en openSUSE han empaquetado scripts y herramientas como sdbootutil, con el que el sistema creará nuevas entradas de arranque Type #1 en la partición de sistema EFI (ESP) para representar todas las opciones de arranque disponibles, las cuales copiarán desde la instantánea los nuevos kernels instalados en la partición, además de generar initdr para dichas instantáneas.

En caso de utilizar cifrado completo de disco, una característica cada vez más demandada para proteger los datos en dispositivos como portátiles y móviles principalmente, sdbootutil se encargará de llamar también “a los diferentes comandos que actualizarán las políticas necesarias para desbloquear automáticamente las nuevas instantáneas utilizando el dispositivo Trusted Platform Module 2.0 (TPM2) del sistema”.

El soporte para TPM es algo importante para los responsables de systemd, y es que el framework ha incorporado en los últimos años muchas cosas orientadas a soportar las características de seguridad que han sido implementadas en placas base UEFI durante el transcurso de la última década, a pesar de la impopularidad de UEFI y de algunas de sus características entre muchos usuarios de Linux.

El soporte de systemd-boot en openSUSE Tumbleweed todavía está en fase experimental, así que GRUB sigue siendo el cargador de arranque predeterminado. Sin embargo, que no quepa duda que desde el proyecto tienen la intención de llevar acabo la transición, pero se trata de un proceso que apunta a durar unos cuantos meses como mínimo.

A pesar de que systemd-boot existe desde hace tiempo, hay pocas distribuciones que lo usan a la hora de la verdad, siendo Pop!_OS una de ellas. Curiosamente en Fedora todavía no hay nada sólido en torno a la sustitución del cargador de arranque, y eso que systemd es un desarrollo que nació en las instalaciones de Red Hat.

Fuente: Muy Linux.

Tres meses después de adelantarlo, AMD ha publicado el código fuente de FidelityFX Super Resolution 3, más conocido como FSR 3, bajo el paraguas de GPUOpen y la licencia MIT. Aunque este es un acontecimiento importante, por ahora hay que tomárselo con cautela debido a algunas carencias importantes que esperemos sean subsanadas en un futuro.

FSR es la tecnología de reescalado de AMD, la cual compite con el DLSS de NVIDIA y el XeSS de Intel. Por ahí también anda el MetalFX de Apple, pero el gigante de la manzana mordida juega en su propia liga, más desde que sus ordenadores personales se basan en la arquitectura ARM, así que a partir de ahora ignoraremos a esta última debido a la falta de confrontación directa.

La principal característica de FSR frente a DLSS y XeSS es el hecho de ser la única tecnología destacada de su segmento que es publicada como código abierto, aunque sea a destiempo. De NVIDIA no hace decir nada sobre su predilección por lo privativo e Intel ha incumplido las expectativas que generó en su momento en lo que a aperturismo se refiere, lo que deja a FSR en una posición privilegiada entre los seguidores del código abierto.

Retomando el tema que realmente nos ocupa, FSR 3 destaca frente a las versiones anteriores por la inclusión de la generación de imágenes. Sobre el papel, la última versión de la tecnología de reescalado del gigante rojo representa una mejora importante, en especial en lo que respecta a la calidad de imagen para competir en mejores condiciones con el DLSS de NVIDIA, que se ha erigido como el gran referente del sector. Además, FSR es compatible con gráficas de Radeon y NVIDIA, mientras que DLSS solo funciona sobre GPU de la misma compañía que lo desarrolla.

Sin embargo, no todas son buenas noticias en torno a FSR 3, ya que el código fuente publicado solo soporta DirectX 12 y Unreal Engine 5, así que por ahora no hay nada de Vulkan ni de Linux (al menos en términos oficiales). La propia AMD ha anunciado que el soporte para Vulkan está en desarrollo, lo que debería facilitar su implementación en Linux debido a que esa es la API de referencia en lo que a videojuegos se refiere. Por otro lado, veremos si Valve toma cartas en el asunto por lo que le conviene.

En resumidas cuentas, FSR 3 ya es de código abierto, pero parece que habrá que esperar para que pueda ser empleada a través de Linux. Con unos videojuegos triple A cuyos requisitos de sistema han subido mucho en los últimos años, FSR puede terminar erigiéndose como una pieza clave para mantener viva a la Steam Deck, además de que el soporte multiplataforma que debería llegar en un futuro abriría la puerta a aprovechar sus virtudes en software como los emuladores.

​

Fuente: Muy Linux.

Nadie dijo que el camino hacia la digitalización fuese fácil, pero lo cierto es que es ineludible y no solo por motivo de competitividad: las ventajas son un hecho a todos los niveles, sin embargo, se trata a día de hoy de una cuestión de mera supervivencia. Ergo, lo que no puedes hacer solo, podrás conseguir hacerlo acompañado.

Si la digitalización de tu empresa se complica; si llevas tiempo intentándolo sin alcanzar a conseguirlo; si el papel sigue siendo tu pan de cada día… Es evidente que ha llegado el momento de buscar un apoyo sobre el que impulsarse para encarrilar la situación: una ayuda experta que sepa indicarte soluciones certeras a los problemas que enfrentas.

Problemas tales como:

• Accesibilidad: ¿tienes garantizado el acceso a los documentos que necesitas cuando y donde lo necesitas?
• Ahorro: ¿sigues imprimiendo documentos en papel, no a modo de copia de seguridad, sino para su uso cotidiano?
• Eficiencia: ¿ese documento en papel que acabas de encontrar… estás seguro de que es la última versión?
• Cumplimiento: ¿estás cumpliendo con todos los requisitos legales al almacenar la información confidencial de tus clientes?
• 
• Las ventajas de la digitalización son un hecho: tener acceso constante, desde cualquier dispositivo, a todos los datos referentes a las diversas áreas de negocio para tomar decisiones informadas; ahorro en gastos operativos; alza de la productividad y la eficiencia; una mejor comunicación con los clientes a través de múltiples canales digitales…

  Sin embargo, el camino hacia la digitalización total de una empresa puede resultar desafiante sin la guía y herramientas adecuadas. Cambiar el enfoque tradicional basado en papel y procesos físicos a uno completamente digital demanda la colaboración de expertos destacados y la implementación de las mejores prácticas disponibles en el mercado.

  Por suerte, existen soluciones que pueden ser de gran ayuda en el proceso de digitalización, de transformación digital de una empresa. ¿Quieres saber más? Descarga gratis el siguiente documento y descubre todas las claves.

Fuente: Muy Linux.

Canonical ha anunciado el lanzamiento de LXD 5.20, nueva versión del sistema de gestión de virtualización y contenedores, herramienta estándar de referencia para LXC, y la primera que ve la luz en su nueva casa, y es que estamos hablando de un proyecto que está al cargo de de la misma desarrolladora de Ubuntu, por supuesto, no sin polémica y movimientos encontrados.

Así, tras saberse que Linux Containers trasladaba la propiedad de LXD a Canonical comenzó la oposición comunitaria por parte, entre otros, de los mantenedores del mismo, que veían cómo Canonical cerraba las puertas a todo aquel que no fuese empleado de la compañía. La posibilidad de colaboración seguía -y sigue- ahí, pero pasando siempre por el aro de Canonical, algo con lo que no todo el mundo estaba de acuerdo.

O lo que es lo mismo, todo aquel que lo desee puede seguir colaborando con el desarrollo de LXD, pero aceptando las nuevas condiciones impuestas por Canonical, entre otras, la aceptación del Acuerdo de Licencia de Contribuidor (CLA) que tan poco suele gustar, algo de lo que ya se advirtió y que, en efecto, ha terminado sucediendo.

Las consecuencias no se hicieron esperar y una de las más destacadas fue la renuncia de Stéphane Graber, veterano desarrollador de Ubuntu y uno de los primeros responsables de LXD. De hecho, es cuando menos curiosa la posición de Graber, pues sigue trabajando para Canonical como desarrollador de Ubuntu Core, pero se apeó del mantenimiento de LXD tras el reciente cambio de marco… para encabezar el desarrollo de un fork.

«Seguiré siendo un usuario activo de LXD y probablemente seguiré reportando y solucionando problemas ocasionalmente. Sin embargo, no tengo la intención de firmar nunca el CLA de Canonical, por lo que si eso se convierte en una barrera para la contribución al proyecto, tendré que dejar de contribuir», señalaba Graber al darse el anuncio de un fork de LXD respaldado por Linux Containers. Sin duda, estas cosas solo pasan en el mundo del código abierto.

Ese fork, llamado Incus, lanzó su primera versión el pasado octubre y, según comentaba el propio Stéphane Graber, «es aproximadamente equivalente a LXD 5.18, pero con una serie de cambios importantes», incluyendo «muchas funciones no utilizadas o problemáticas de LXD. La mayoría de esos cambios son cosas que nos hubiera gustado hacer en LXD pero no pudimos debido a que teníamos fuertes garantías de compatibilidad con versiones anteriores».

Envuelto en semejante clima aparece LXD 5.20, un lanzamiento cuyas novedades técnicas están siendo eclipsadas por otras que apuntan hacia donde lo hacían las suspicacias de los colaboradores revueltos, que no solo. El cambio más destacado según recoge el anuncio oficial es el relicenciamiento del proyecto, cuyo código se distribuirá ahora bajo la licencia AGPLv3. Así lo explican:

«Canonical ha decidido cambiar las contribuciones predeterminadas al proyecto LXD a AGPLv3 para que estén alineadas con nuestra licencia estándar para código del lado del servidor. Todas las contribuciones de Canonical han sido relicenciadas y etsán ya bajo la AGPLv3. Las contribuciones de la comunidad se mantienen bajo la Apache 2.0. Seguimos la guía del Software Freedom Law Center en relación con esto. En el futuro, cualquier contribución a LXD se realizará bajo AGPLv3 de forma predeterminada. El autor de un cambio seguirá siendo el titular de los derechos de autor de su código, pero sin cesión de derechos de autor.

Es importante tener en cuenta que este cambio no impide que nuestros usuarios utilicen, modifiquen o proporcionen soluciones de software basadas en LXD, siempre que compartan el código fuente si lo modifican y lo pongan a disposición de otros. Las condiciones de la licencia están diseñadas para alentar a quienes buscan modificar el software a contribuir al proyecto y a la comunidad.»

En resumen, idependientemente de la licencia, los colaboradores pasados y futuros de LXD conservarán la autoría de sus contribuciones, pero sin cesión de derechos de autor. Lo normal en casi cualquier licencia de código abierto. En cuanto a las licencias, desde el punto de vista del modelo del código abierto la AGPLv3 está más indicada que la Apache 2.0 para fomentar el aprovechamiento de toda colaboración, que no la colaboración en sí.

Pero no todo el mundo está contento con el cambio. Una vez más, Stéphane Graber advierte de problemas, derivados en este caso de la mezcla de licencias, compatibles entre sí a priori, pero no en todas direcciones, así como de la obligatoriedad de aceptar el CLA. Y aunque expone sus temores desde la perspectiva de Incus, lo cierto es que podrían darse situaciones de todo tipo.

Fuente: Muy Linux.

«Comenzaré con el hecho de que los paquetes Snap han tenido más de de un millón de descargas y con ese tipo de números, no pueden ser ignorados«. Y así es , en efecto, como comienza su presentación en Akademy 2023 Scarlett Moore, desarrolladora de Debian, KDE neon y mantenedora de los «KDE Snaps», los paquetes Snap con los que se distribuye oficialmente el software de KDE.

Scarlett Moore es, junto a Jonathan Riddell y Carlos De Maine, una de las tres personas responsables de mantener el software de KDE en formato Snap, accesible desde la Snap Store, la tienda de aplicaciones de Canonical. Y por software de KDE quiero decir aplicaciones y alguna biblioteca de las que estas dependen, no el escritorio y sus componentes. Todavía no estamos ahí y a saber si lo estaremos algún día. Quién sabe.

Sin embargo, parece fuera de toda duda la tracción que han conseguido las aplicaciones del proyecto KDE en formato Snap, como se encarga de recordar Moore en su exposición. Otras de las cosas de las que habla incluyen «su viaje en la creación de un montón de snaps», «los obstáculos que ha superado y lo que se debe hacer para mantener los paquetes Snap al día» y otros menesteres relacionados con el tema de marras.

Si te interesa ver la charla de Moore, tienes el vídeo en este enlace.

En cuanto al más de un millón de razones por las que los paquetes Snap son importantes, en este caso concreto, para KDE, ya está todo dicho: por su popularidad en la Snap Store, donde llegan a tanta gente. O lo que es lo mismo: ese más de un millón de razones derivan directamente del más de un millón de descargas de las aplicaciones. No tiene más misterio la cosa, aunque haya quien se empeñe en buscárselo.

Ahora bien, me resulta curiosa esta «noticia» por las contradicciones que refleja, de manera en cierto modo similar a la noticia -esta sin las comillas- del lanzamiento de LXD 5.20 que recogíamos hoy mismo y que, casualidad, también tiene a Canonical como protagonista. Al menos, en parte. Y es que si Canonical está generando controversia con LXD, lo acumulado por Snap hasta el momento está a otro nivel.

De sobra conocido es el rechazo que algunas distribuciones Linux, especialmente las grandes, tienen hacia Snap, al tiempo que apuestan por Flatpak, su alternativa en el ámbito del escritorio. Ejemplos hay unos cuantos y uno palmario es el de Linux Mint, sistema basado en Ubuntu que reniega de Snap como pocos. Sus razones tienen, claro, y de ellas hemos hablado en más de una ocasión; por no mencionar que lo de imponer Snap es peliagudo más allá del modelo de distribución.

Pero Snap no solo tiene detractores. Hay empresas que han apostado por el servicio de Canonical para traer sus aplicaciones al escritorio Linux, si no de manera prioritaria, sí decidida. E incluso hay proyectos de software libre que hacen lo propio. Véase KDE y, por extensión, KDE neon. En particular, Jonathan Riddell, otrora líder de Kubuntu. Un tipo que se quemó con Canonical, que levantó KDE neon como reemplazo de Kubuntu y que, sin embargo, da soporte a Snap…. aunque hay que reconocer que Canonical siempre ha tenido en valor el software de KDE.

Cabe recordar que KDE neon es una de las pocas distribuciones al margen de la familia oficial de Ubuntu, que ofrece soporte de paquetes Snap de manera predeterminada. Ojo: activado por defecto, a diferencia de Flatpak/Flathub, si bien no termina ahí la cosa, pues el número de aplicaciones de KDE en formato Snap mantenidas por miembros del proyecto como Moore, Riddell o De Maine es mucho mayor que las disponibles en formato Flatpak en iguales condiciones.

Fuente: Muy Linux.