Lo publicábamos ayer en MC, pero vale la pena recogerlo aquí también, y es que la nueva versión del gestor de contraseñas KeePassXC llega con novedades reseñables. Pocas, apenas tres, pero solo por una ya merece la pena dedicarle el hueco: soporte para Passkey.

Hacía tiempo que nos nos hacíamos eco de un lanzamiento de KeePassXC, uno de los gestores de contraseñas más recomendables a día de hoy, a pesar de no seguir la tónica dominante del software como servicio. KeePassXC, por el contrario, es una aplicación local en la que tú te lo guisas, tú te lo comes con sus ventajas e inconvenientes; con un matiz importante: tiene casi todas las opciones que le puedes pedir a una herramienta de su categoría.

Para más datos en el caso de que los necesites, descubre por qué KeePassXC es el nuevo tótem de las contraseñas -hablando siempre en clave de software libre, aclaro- y, ya que el artículo cubre lo principal, pero está desactualizado, aquí puedes repasar las novedades que hemos ido recogiendo en los últimos años de los lanzamientos más destacados de la aplicación. Las novedades previas a la versión que nos ocupa, obviamente, y conste que la cobertura se remonta tiempo ha.

Ahora sí, vamos con KeePassXC 2.7.7 y sus novedades, que al margen de las habituales correcciones son tres: soporte de Passkey, mejoras en la importación de datos y acceso simplificado. Comenzando por el primero, novedad estelar donde las haya, un aviso a navegantes, por si acaso alguien no está familiarizado con el término, aun cuando ed un tiempo a esta parte se lleva implementando a lo grande en la industria, impulsado por el W3C y la Alianza FIDO.​:

La autenticación con Passkey, también conocida como autenticación de contraseña de un solo uso (OTP), es un método de verificación que utiliza una contraseña que es válida solo para una única sesión de inicio de sesión o transacción. En lugar de utilizar una contraseña estática, se genera una temporal que se envía al usuario a través de un medio seguro, como un mensaje de texto o un correo electrónico.

En resumen, las Passkeys o claves de acceso son un método de autenticación que intenta facilitar el proceso de identificación, así como mejorar su seguridad, prescindiendo en lo posible del uso de contraseñas como siempre se ha hecho: en fechas recientes, compañías como Google, Microsoft, Meta, Amazon y otras han ido implementándolo para todos sus usuarios de manera más o menos activa. ¿Cómo funciona en KeePassXC? En la documentación se explica, aunque no es complicado.

Por otro lado, KeePassXC 2.7.7 mejora el asistente de importación, que ha ampliado sus capacidades para con las nuevas versiones de las bases de datos de 1Password y Bitwarden, así como mejora la gestión de archivos CSV, comunes para exportar contraseñas; y ha simplificado la interfaz de desbloqueo de la aplicación, que además reconoce ahora de manera automática si hay llaves Yubikey o OnlyKey conectadas. Para descargar KeePassXC, entra en ese enlace y elige el medio que más interese.

Fuente: Muy Linux.

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.