OpenZFS 2.4.2 ya está disponible como rama estable y se presenta como una actualización más de infraestructura que de grandes titulares, pero con un impacto importante para quienes gestionan sistemas de almacenamiento serios. Aunque sobre el papel pueda parecer un lanzamiento discreto, las novedades en compatibilidad de kernel y en estabilidad interna lo convierten en un paso relevante para administradores de sistemas que trabajen con Linux o FreeBSD.

Este lanzamiento se centra en cerrar brechas de compatibilidad y pulir errores que se manifestaban en escenarios complejos: cambios de kernel, reconstrucciones de pools, uso de dRAID o sustitución de discos. No hay funciones espectaculares pensadas para titulares comerciales, pero sí muchas correcciones que reducen riesgos de corrupción de datos y mejoran la convivencia entre OpenZFS y las versiones más recientes del kernel de Linux.

Compatibilidad de OpenZFS 2.4.2 con kernels Linux y FreeBSD

El punto más visible de OpenZFS 2.4.2 es la compatibilidad oficial con el kernel Linux 7.0, algo especialmente relevante para quienes ya están probando o desplegando distribuciones que integran esta rama. Hasta ahora, la versión estable anterior solo llegaba formalmente hasta Linux 6.19, lo que generaba fricciones en instalaciones que se movían más rápido a nivel de kernel que de stack de almacenamiento.

Con esta actualización, el proyecto mantiene un amplio rango de soporte, que abarca desde Linux 4.18 hasta 7.0. Esta horquilla resulta muy útil en entornos mixtos europeos donde coexisten servidores con distribuciones antiguas de soporte prolongado, máquinas de pruebas con kernels recientes y sistemas de producción más conservadores. Disponer de una única rama de OpenZFS que cubra todo ese abanico reduce excepciones, despliegues especiales y dolores de cabeza en la planificación de actualizaciones.

En la parte de FreeBSD, OpenZFS 2.4.2 sigue funcionando correctamente con FreeBSD 13.3 y versiones posteriores, incluido el salto a las ramas más nuevas como la serie 14.x. Esto mantiene alineado el ecosistema BSD con la evolución del sistema de archivos, algo relevante para centros de datos europeos que combinan infraestructuras Linux y FreeBSD en servicios de almacenamiento, copias de seguridad o plataformas de virtualización.

Cierre de la brecha con Linux 7.0

El soporte formal de Linux 7.0 no es solo un detalle de documentación: ataja un problema real que ya se estaba viviendo en distribuciones de nueva generación. Había casos, como instalaciones basadas en Ubuntu en versiones de desarrollo con kernel 7.0.0-15 y OpenZFS 2.4.1, donde los registros del sistema advertían de un uso experimental y posible riesgo de pérdida de datos al combinar ese kernel con la versión previa del módulo.

En un escritorio doméstico esos avisos pueden parecer anecdóticos, pero en un servidor de almacenamiento en producción no son algo que se pueda ignorar solo porque todo parezca funcionar a simple vista. Con 2.4.2, OpenZFS declara explícitamente compatible el kernel 7.0, lo que aporta un marco más claro para administradores que deben cuadrar políticas de actualización de kernel y estabilidad de pools ZFS en centros de datos o nubes privadas.

Además, el proyecto ha introducido ajustes iniciales orientados a Linux 7.1, anticipando cambios internos del kernel que pueden afectar a módulos externos como OpenZFS. No se trata aún de un soporte cerrado para 7.1, pero sí de un trabajo preparatorio que reduce la probabilidad de sorpresas incómodas cuando estas versiones empiecen a llegar a distribuciones de referencia en Europa.

Correcciones en rutas de datos y fiabilidad

Más allá del soporte de kernel, buena parte de las novedades de OpenZFS 2.4.2 se centra en rutas de datos críticas donde un fallo puede traducirse en corrupción o comportamientos inesperados. Aunque estos problemas suelen aparecer en escenarios poco frecuentes, son precisamente los que marcan la diferencia entre un sistema de ficheros robusto y uno que genera dudas a largo plazo.

Entre las correcciones destacadas se encuentran arreglos para errores de checksum en casos muy raros tras procesos de reconstrucción, una cuestión especialmente sensible cuando se trabaja con grandes pools o con discos que se han degradado. También se han solucionado problemas en configuraciones dRAID después de reconstrucciones con unidades deterioradas, lo que mejora la confianza en despliegues que usan esta tecnología para grandes volúmenes de datos.

La versión incorpora además correcciones en los procesos de importación de pools después de sustituciones de discos, un posible race condition asociado a los árboles de rangos (range trees) y un fallo de uso después de liberación (UAF) en la función dmu_write_direct_done. A ello se suma la solución de un problema de corrupción de lectura tras operaciones de clonación de bloques y truncado, un tipo de bug especialmente delicado porque puede pasar desapercibido hasta que los datos se necesitan de verdad.

Todo este conjunto de parches no se traduce en nuevas funciones llamativas, pero sí en un comportamiento más previsible durante operaciones de mantenimiento habituales: reconstrucción de vdevs, gestión de discos sustituidos, uso intensivo de snapshots y clones, dRAID y pruebas de rendimiento. Para organizaciones europeas que usan OpenZFS en almacenamiento crítico, estos son los detalles que ayudan a dormir un poco más tranquilos antes de un fin de semana.

Ajustes en initramfs, montaje y sistema

OpenZFS 2.4.2 también introduce mejoras en componentes de arranque y montaje que, aunque menos visibles, resultan importantes para que el sistema se comporte de forma consistente en distintas distribuciones. Entre ellas se incluyen correcciones en los scripts de initramfs, que intervienen en las fases iniciales de arranque cuando el sistema necesita acceder a pools ZFS muy pronto.

La nueva versión incorpora soporte para POSIX_FADV_DONTNEED, una sugerencia al sistema de ficheros y al kernel sobre el tratamiento de datos en caché, lo que ayuda a optimizar determinados patrones de acceso en servidores. Además, se han realizado ajustes en las rutas de montaje específicas para Linux y en la lógica de análisis de los nuevos parámetros de montaje, reduciendo casos límite en los que la configuración podía comportarse de forma diferente a lo esperado.

En paralelo, el proyecto ha aprovechado esta versión para actualizar la infraestructura de integración continua (CI), reforzar el uso de identificadores de licencia SPDX y aplicar cambios específicos del código para Linux que alinean mejor el módulo con las evoluciones del kernel. Estas mejoras internas no se perciben directamente en el día a día, pero son la base para que futuras versiones puedan desarrollarse y probarse de forma más fiable.

Recomendaciones de actualización para entornos europeos

Aunque el contenido de OpenZFS 2.4.2 invita a considerarlo una actualización recomendable, no es prudente tratarla como un simple parche trivial. El propio enfoque del proyecto y la naturaleza del sistema de ficheros aconsejan un proceso de despliegue controlado, especialmente en organizaciones con pools grandes o servicios críticos.

Para entornos empresariales y administraciones públicas en España y otros países de la UE, la práctica razonable pasa por revisar primero el estado de los paquetes proporcionados por la distribución, comprobar la configuración de DKMS o módulos, validar las características activas de los pools (pool features) y preparar un entorno de pruebas que reproduzca el escenario de producción lo mejor posible.

Un paso sensato consiste en introducir OpenZFS 2.4.2 inicialmente en sistemas de staging o laboratorios, aplicando allí los mismos patrones de uso que en producción: importación y exportación de pools, simulación de fallos de discos, uso intensivo de snapshots, clones, dRAID y pruebas de rendimiento. Una vez verificado el comportamiento, la actualización en producción debería planificarse en ventanas de mantenimiento con copia de seguridad reciente y estrategias claras de reversión.

En definitiva, OpenZFS 2.4.2 se presenta como una versión sobria pero muy relevante para la estabilidad de sistemas Linux y FreeBSD, especialmente allí donde conviven kernels antiguos y muy recientes. El soporte oficial para Linux 7.0, las numerosas correcciones en rutas de datos, los ajustes en initramfs y montaje, y la disponibilidad paralela de 2.3.7 conforman un paquete pensado para reducir riesgos más que para lucirse en presentaciones. Para quienes gestionan datos con cierta responsabilidad, este tipo de lanzamientos, discretos pero sólidos, son los que marcan la diferencia entre un susto mayúsculo y una operación de mantenimiento rutinaria.

from Linux Adictos https://ift.tt/zjJUGtZ
via IFTTT

Fwupd 2.1.3 llega en un momento clave para el ecosistema de firmware en Linux, justo después de que Dell y Lenovo se consolidaran como patrocinadores destacados del Linux Vendor Firmware Service (LVFS). Este contexto refleja un interés creciente de los grandes fabricantes por facilitar procesos de actualización más seguros y centralizados en sistemas basados en GNU/Linux.

Con esta publicación, el desarrollador principal de LVFS y Fwupd, Richard Hughes desde Red Hat, refuerza el papel de la herramienta como estándar de facto para gestionar actualizaciones de firmware. La edición 2.1.3 introduce nuevas funciones, amplía el soporte de hardware y corrige diversos errores que afectaban a determinados dispositivos, lo que se traduce en una experiencia algo más pulida para usuarios y administradores.

Principales novedades de Fwupd 2.1.3

Uno de los cambios más relevantes de Fwupd 2.1.3 es la incorporación de autenticación Redfish mediante bearer token. Esta mejora resulta especialmente útil en entornos de servidores y centros de datos donde Redfish se utiliza como estándar para la gestión remota de hardware, ya que facilita una integración más segura y flexible en infraestructuras empresariales.

La actualización también añade compatibilidad con varios chips XMC SPI, un tipo de memoria ampliamente utilizado en placas y dispositivos donde se almacena el firmware. Al ampliar el número de chips soportados, Fwupd puede llegar a más equipos y escenarios de uso, reduciendo la dependencia de herramientas específicas del fabricante.

Otro punto técnico destacado es la capacidad de analizar archivos JCat directamente dentro de la biblioteca de Fwupd, sin necesidad de recurrir a la librería externa libjcat. Este cambio ayuda a simplificar la pila de dependencias, lo que puede facilitar tanto el empaquetado para distribuciones GNU/Linux como el mantenimiento a largo plazo del proyecto.

Además de las nuevas funciones, la versión 2.1.3 incluye un conjunto de correcciones de errores que afectan a distintos componentes de hardware y a problemas menores detectados en versiones anteriores. Aunque no se detalla la lista completa en la información publicada, el enfoque apunta a mejorar la estabilidad general de la herramienta y reducir fallos durante el proceso de actualización de firmware.

Soporte para nuevos dispositivos SHIFTphone

Una de las incorporaciones más llamativas de Fwupd 2.1.3 es el soporte para las actualizaciones de firmware de los dispositivos SHIFT6MQ y SHIFTphone 8. Estos teléfonos modulares, fabricados por la empresa alemana SHIFT, se caracterizan por su reparabilidad y por un enfoque más sostenible en comparación con buena parte del mercado de smartphones.

La compatibilidad con Fwupd supone que los usuarios de SHIFT6MQ y SHIFTphone 8 podrán gestionar actualizaciones de firmware de forma más estándar dentro de entornos Linux, algo especialmente interesante para perfiles técnicos y comunidades que valoran la transparencia y el control sobre el software de sus dispositivos.

En el caso del SHIFTphone 8, se trata del modelo más reciente de la firma y el sucesor del SHIFT6MQ, que vio la luz en 2020. El nuevo terminal se encuentra en fase de reserva con un precio en torno a los 695 euros, reforzando la apuesta de SHIFT por un segmento de gama media-alta centrado en la durabilidad y la posibilidad de reparación.

Contexto: LVFS y el papel de los fabricantes

La llegada de Fwupd 2.1.3 se produce poco después de que Dell y Lenovo hayan reforzado su implicación con el Linux Vendor Firmware Service como patrocinadores de referencia. Este movimiento indica una apuesta más clara por ofrecer canales oficiales y centralizados para distribuir firmware, algo crucial en empresas y administraciones públicas que despliegan Linux a gran escala.

LVFS actúa como plataforma central para la distribución de firmware firmado y verificado en sistemas Linux, y Fwupd es la herramienta que se ejecuta en el lado del usuario o administrador para aplicar esas actualizaciones. A medida que más fabricantes de hardware se integran en este ecosistema, se reduce la necesidad de recurrir a utilidades específicas de cada marca o a sistemas operativos alternativos sólo para actualizar firmware.

En este escenario, la compatibilidad de nuevos dispositivos como los teléfonos de SHIFT ayuda a extender el modelo también al ámbito de la electrónica de consumo, no sólo a portátiles y servidores. Para la comunidad interesada en tecnología reparable y políticas de «derecho a reparar», este tipo de integraciones supone un paso más hacia dispositivos más abiertos y controlables por el usuario final.

La versión Fwupd 2.1.3 consolida la herramienta como pieza clave en la gestión de firmware en Linux, al combinar nuevas funciones técnicas como la autenticación Redfish por bearer token, un soporte de hardware más amplio que incluye chips XMC SPI y smartphones modulares como el SHIFTphone 8, y una serie de correcciones que buscan mejorar la estabilidad general. Junto con el impulso de fabricantes como Dell, Lenovo y compañías como SHIFT a través de LVFS, el ecosistema de actualización de firmware en Linux sigue avanzando hacia un entorno más homogéneo, transparente y manejable tanto para usuarios particulares como para organizaciones.

from Linux Adictos https://ift.tt/GrRkvnH
via IFTTT

Durante el Red Hat Summit de 2026 se ha presentado una de las apuestas más rompedoras dentro del ecosistema Fedora: Fedora Hummingbird, una distribución Linux rolling, basada en imágenes, pensada para agentes de IA y desarrolladores que viven en contenedores. No es “otra Fedora más”, sino un experimento muy serio para llevar el modelo distroless y las buenas prácticas de seguridad de los contenedores hasta el propio sistema operativo anfitrión.

Este nuevo sistema parte de un objetivo ambicioso: minimizar al máximo las vulnerabilidades (CVE) tanto en las imágenes de contenedores como en el sistema operativo, a la vez que ofrece una velocidad de actualización propia de Fedora Rawhide, pero empaquetada en forma de imágenes OCI, con actualizaciones atómicas, rollback integrado y un enfoque muy claro al mundo de la automatización y los agentes de IA.

Qué es Fedora Hummingbird y qué la hace diferente

Fedora Hummingbird es, en esencia, una distribución Linux de tipo rolling-release basada en imágenes. A diferencia de las Fedora tradicionales basadas en RPM instalados de forma clásica, aquí el sistema se construye y distribuye como si fuera un contenedor, pero con todo lo necesario para ser un host completo: kernel, espacio de usuario, servicios y herramientas básicas.

La idea de fondo es clara: unir el modelo distroless de Project Hummingbird con un sistema operativo completo que pueda usarse en máquinas virtuales, bare metal o incluso como host para otros contenedores. Así, se consigue un entorno coherente, fácil de actualizar y con una superficie de ataque más controlada, algo clave en entornos donde se despliegan múltiples runtimes y versiones de forma simultánea.

En el contexto de la comunidad Fedora, Hummingbird se plantea como un espacio de experimentación avanzado para sistemas de base de imagen, mantenidos de forma continua y orientados a un futuro donde los agentes de IA tengan un papel protagonista en el ciclo de vida del software. No sustituye a otras ediciones como Silverblue, Kinoite o Fedora CoreOS, pero sí abre la puerta a un modelo aún más integrado con pipelines automáticos y seguridad by design.

Project Hummingbird: el origen del enfoque distroless

Para entender Fedora Hummingbird hay que empezar por su raíz: Project Hummingbird, la iniciativa centrada en construir imágenes de contenedor minimalistas, endurecidas y con el objetivo explícito de acercarse a cero CVE. Todo el diseño de la arquitectura, desde el set de paquetes hasta las herramientas de construcción, está orientado a reducir la superficie de ataque y a automatizar la gestión de vulnerabilidades.

Lo más llamativo es la apuesta por imágenes “distroless”: no incluyen gestor de paquetes, ni shell, ni utilidades genéricas; contienen únicamente la aplicación y las dependencias estrictamente necesarias para ejecutarla. Esto evita que, al descargar una imagen de terceros, arrastres componentes innecesarios plagados de potenciales CVE que luego tienes que gestionar a mano.

La filosofía es que, cuando tiras de una imagen Hummingbird, el pipeline ya ha hecho el trabajo sucio: triage de CVE, aplicación de parches, reconstrucción y publicación de la nueva versión, de manera que te ahorras buena parte del infierno de vulnerabilidades típico de los contenedores. Además, el estado de CVE por imagen y variante se publica en tiempo casi real en el catálogo de Hummingbird, para que sepas en qué punto estás.

En estos meses de trabajo, el equipo ha montado un catálogo con 49 imágenes distroless únicas y 157 variantes, incluyendo builds FIPS y multi-arquitectura. Cubren runtimes de uso masivo como Python, Go, Node.js, Rust, Ruby, OpenJDK, .NET, además de servicios como PostgreSQL o nginx, entre otros muchos.

Catalina técnica: cómo se construyen las imágenes de Hummingbird

Detrás de este catálogo hay un pipeline basado en Konflux, diseñado para ofrecer compilaciones aisladas, reproducibles y fáciles de actualizar de manera incremental. El sistema trabaja con listas de paquetes fijadas (pinned), lo que permite reconstruir exactamente la misma imagen, controlar cambios y garantizar coherencia a largo plazo.

Para reducir el coste de las actualizaciones, el equipo ha desarrollado chunkah, una herramienta que permite descargar únicamente las partes modificadas de una imagen, evitando tener que volver a bajar el conjunto completo en cada actualización. Es un enfoque muy práctico en entornos donde se despliegan imágenes constantemente en clusters o nubes híbridas.

La seguridad es un pilar: las imágenes se escanean de forma continua con Syft y Grype, detectando vulnerabilidades en cuanto son reportadas y aplicando parches en cuanto están disponibles aguas arriba. En el momento en que un fix aterriza en el proyecto correspondiente, el pipeline desencadena el rebuild, ejecuta las pruebas y publica la nueva imagen.

Otra pieza clave es la relación con Fedora Rawhide: más del 95 % de los paquetes de cada imagen Hummingbird vienen directamente de Fedora Rawhide, sin modificar. Cuando Rawhide aún no incluye una versión lo bastante nueva, el sistema tira directamente de upstream, y el equipo colabora remontando cambios de vuelta a Fedora, cerrando el círculo entre la experimentación y la distribución base.

El llamado “Hummingbird factory” compila los paquetes de forma que cada uno tenga identidad propia, ciclo de vida independiente, política de parches diferenciada y su propio feed de vulnerabilidades, mantenido por el equipo de Product Security de Red Hat. Cada paquete va acompañado de datos de vulnerabilidad en formato legible por máquina que indican no solo qué CVE existen, sino cuáles afectan realmente a un workload concreto.

Del contenedor al sistema operativo: Fedora Hummingbird como OS en imagen

Las mismas dificultades de seguridad y mantenimiento que se han identificado en el espacio de usuario también aparecen en la capa de sistema operativo. Por eso, el siguiente paso lógico de Project Hummingbird ha sido aplicar este mismo enfoque al host: nace así Fedora Hummingbird como sistema operativo completo en forma de imagen OCI.

La imagen de Fedora Hummingbird está disponible públicamente en quay.io/hummingbird-community/bootc-os, y se construye con el mismo pipeline Konflux y el mismo bloqueo hermético de RPM que el resto del catálogo Hummingbird. A día de hoy ya soporta arquitecturas x86_64 y aarch64, lo que la hace válida tanto para servidores tradicionales como para nuevos entornos ARM.

El objetivo es que esta imagen pueda ejecutarse en contenedores, máquinas virtuales y despliegues bare metal, con un comportamiento consistente en todos los casos. Eso encaja con la iniciativa de Fedora de contenedores arrancables (bootable containers), que planteó que el propio sistema operativo se entregue como una imagen de contenedor más, con un modelo de actualización atómica y retroceso en caso de problemas.

En este diseño, la raíz del sistema de ficheros es de solo lectura, mientras que todo el estado modificable vive en /var y /etc, completamente separado del contenido de la imagen del sistema. Esta separación reduce la deriva de configuración, elimina estados de actualización parcial y hace que los rollbacks sean fiables.

El kernel ARK y la integración con el proyecto CKI

Bajo el capó, Fedora Hummingbird se apoya en ARK (Always Ready Kernel), procedente del proyecto CKI (Continuous Kernel Integration), que sigue de cerca el mainline de Linus Torvalds. Este kernel ya se utiliza hoy en Fedora, pero en Hummingbird toma un protagonismo clave como base de un sistema que se actualiza de forma continua.

El gran valor de CKI es que no solo ofrece una configuración de kernel cuidadosamente curada, sino todo un marco de ingeniería y pruebas alrededor de un flujo de kernel de alta velocidad. Esto permite adoptar rápidamente nuevas funcionalidades del kernel principal sin perder de vista la estabilidad, un equilibrio complicado cuando se apuesta por la velocidad de upstream.

Gracias a esta combinación, Fedora Hummingbird puede ofrecer un entorno siempre a la última en cuanto a kernel, pero con un nivel de testeo automatizado difícil de conseguir en modelos más manuales. Para los desarrolladores que dependen de nuevas capacidades del kernel (por ejemplo, en contenedores, redes, almacenamiento o soporte de hardware reciente), este enfoque resulta especialmente atractivo.

Fedora Hummingbird Linux: distribución rolling para agentes y desarrolladores de IA

Red Hat define Fedora Hummingbird Linux como un sistema operativo Linux rolling-release, nativo de contenedores, concebido para “builders” de la era agentic: desarrolladores humanos y agentes de IA que necesitan desplegar entornos de forma casi instantánea. La clave está en que evita los ciclos clásicos de lanzamiento y los bloqueos de seis meses o más, abrazando la actualización continua desde comunidades upstream.

Uno de los puntos más diferenciadores es que Hummingbird se diseña para que sean los propios agentes de IA quienes lo elijan en la fase de experimentación. En un escenario donde un agente debe levantar un entorno rápidamente, cualquier registro, formulario o verificación manual supone un atasco. Por eso, Fedora Hummingbird Linux se puede descargar sin registro, con pulls anónimos pensados para despliegues automatizados en nubes híbridas y entornos de laboratorio.

Este modelo convierte a Hummingbird en una especie de “sistema operativo por defecto” para agentes cuyo único objetivo es poner en marcha un entorno de pruebas lo antes posible. Desde ahí, la ruta natural apunta hacia entornos de producción gobernados sobre Red Hat Enterprise Linux y OpenShift Virtualization, donde ya entra en juego el soporte empresarial clásico.

En palabras de la propia Red Hat, el mercado Linux se ha bifurcado: los equipos de operaciones necesitan la estabilidad a décadas de RHEL, mientras que los creadores (humanos y agentes) piden velocidad de upstream y flujos de trabajo basados en imágenes. Fedora Hummingbird Linux se sitúa precisamente en ese segundo extremo, como plataforma de referencia para el software que construirá el futuro empresarial.

Una fábrica de software “lights out” potenciada por agentes de IA

Una de las novedades más llamativas es que gran parte del mantenimiento y la integración de nuevas funcionalidades en Fedora Hummingbird Linux se realiza mediante agentes de IA, con supervisión humana. Red Hat describe el proceso como una “software factory” de tipo lights out, es decir, altamente automatizada y capaz de funcionar prácticamente sin intervención directa.

Esto permite que la distribución avance al ritmo del ecosistema de IA, algo imposible de igualar con empaquetado manual tradicional. La combinación de agentes que automatizan tareas repetitivas (triage de CVE, generación de parches, integración de nuevas versiones) y revisiones humanas en puntos críticos busca equilibrar velocidad y seguridad.

Desde un punto de vista de seguridad, Hummingbird se apoya en la misma infraestructura automatizada y los pipelines Konflux que sustentan las Red Hat Hardened Images. Esto significa que los lenguajes, runtimes, bases de datos y herramientas que se sirven desde estas imágenes vienen libres de CVE conocidos y acompañados de completas SBOM (Software Bill of Materials), algo muy valorado en auditorías de cadena de suministro.

Onboarding sin fricción y ruta hacia la producción empresarial

En la llamada “era agentic”, la primera decisión sobre qué sistema operativo usar ya no la toma siempre una persona: un agente de IA puede elegir la distribución durante la fase de prueba de un proyecto. Si ese agente se topa con registros, licencias o muros de acceso, se frena la innovación. Fedora Hummingbird Linux nace para esquivar esos frenos.

Por eso, la distribución permite pulls anónimos y soporte para despliegues ultra rápidos, eliminando las paredes de registro que suelen frenar a los agentes y a los flujos CI/CD muy automatizados. De esta forma, se convierte en una opción tremendamente cómoda para laboratorios, prototipos y pruebas de concepto en la nube.

Red Hat, no obstante, no se queda solo en el experimento: planea ofrecer un modelo de Cooperative Community Support asociado a la suscripción de Red Hat, de modo que los usuarios de Hummingbird puedan encontrar y aprovechar con rapidez los recursos de la comunidad y, al mismo tiempo, conectar con el ecosistema de soporte empresarial.

La visión a medio plazo es que Hummingbird actúe como puerta de entrada “sin peajes” desde el portátil del desarrollador hasta las pruebas serias en la nube, y de ahí, sin necesidad de migraciones traumáticas, al mundo RHEL y OpenShift para cargas de trabajo de producción. Así, se cubre todo el trayecto: experimentación libre, consolidación y, finalmente, despliegue gobernado.

Diferencias entre Fedora Hummingbird Linux y Red Hat Desktop orientado a IA

Durante el mismo Red Hat Summit se presentaron dos propuestas de escritorio Linux diferentes para el mundo de la IA: el nuevo Red Hat Desktop, centrado en desarrolladores con un entorno gobernado, y Fedora Hummingbird Linux como opción libre y rolling para builders y agentes. Aunque se complementan, juegan papeles distintos.

El nuevo Red Hat Desktop se basa en la build de Red Hat de Podman Desktop, con el objetivo de facilitar la creación, gestión y despliegue de contenedores en Linux, macOS y Windows. Está construido sobre Red Hat Hardened Images y Red Hat Trusted Libraries, ofreciendo un enfoque muy fuerte en seguridad y en alineación con entornos OpenShift.

En ese escritorio, OpenShift Dev Spaces proporciona un marco extensible para integrar asistentes de IA directamente en el IDE en la nube. Incluye un avance técnico del asistente de código AWS Kiro, además de integraciones con Microsoft Copilot, Claude CLI, Cline, Continue, Roo y otros. El mensaje es claro: desarrollar con el asistente que prefieras, ya sea propietario u open source.

Otro elemento interesante es Kaiden, una solución open source para aislar agentes de IA en sandboxes. Esto permite probar agentes y sus acciones en el propio equipo local minimizando el riesgo de que una decisión errónea de un agente acabe desbaratando el sistema anfitrión. Para quienes experimentan mucho con agentes autónomos, es un salvavidas.

Red Hat Advanced Developer Suite incorpora además capacidades de inteligencia de exploits impulsadas por IA, que ayudan a entender si una vulnerabilidad conocida en el código generado por IA afecta realmente a un entorno de ejecución concreto. Así, se puede priorizar la corrección y mitigación en función del riesgo real, no solo de la existencia del CVE.

Mientras tanto, Fedora Hummingbird Linux se posiciona como una distribución gratuita, “free as in beer y free as in freedom”, rolling-release, pensada como sistema operativo por defecto para agentes y flujos de trabajo automatizados. No se rige por ciclos de lanzamiento congelados, sino que entrega actualizaciones desde upstream en cuanto están listas.

Red Hat planea además que Fedora Hummingbird Linux se ofrezca como opción por defecto en proveedores de nube centrados en desarrolladores, esos entornos típicos donde se inician pequeños proyectos personales o pruebas de concepto. Red Hat Desktop, por su parte, actúa como el entorno de desarrollo gobernado que refleja mejor la producción sobre RHEL y el resto de la familia Red Hat AI.

Relación con Fedora, Fedora CoreOS y la comunidad

Fedora Hummingbird no nace aislada: múltiples miembros del equipo Hummingbird ya son contribuidores y mantenedores de paquetes en Fedora, incluyendo piezas fundamentales como Podman y otras herramientas de contenedores críticas para el ecosistema Linux, además de parte del equipo detrás de Fedora CoreOS.

Los trabajos en contenedores arrancables de Fedora (bootable containers) sentaron las bases técnicas de Fedora Hummingbird. Muchas de las personas implicadas en esa iniciativa siguen ahora empujando el proyecto Hummingbird, pero con una visión más amplia: consolidar un sistema operativo completo entregado como imagen.

La intención declarada es integrar Hummingbird dentro del Proyecto Fedora para que pueda crecer y beneficiarse del mismo ecosistema comunitario. De hecho, el pipeline de Hummingbird ya construye y publica un conjunto de imágenes basadas íntegramente en Fedora Rawhide en quay.io/organization/hummingbird-rawhide, lo que refuerza la conexión.

Parte del trabajo actual se centra en reducir la mezcla entre RPM construidos por Hummingbird y paquetes estándar de Fedora dentro de la imagen, para alinear completamente la base tecnológica. Es justo en este punto donde la colaboración de la comunidad resulta más valiosa, tanto para pulir el modelo como para extenderlo a nuevos escenarios.

Además, el equipo ya está llevando de vuelta a Fedora optimizaciones específicas para contenedores, correcciones encontradas en archivos .spec y mejoras que benefician al conjunto de la distribución. El feed de vulnerabilidades que acompaña a los paquetes Hummingbird también se considera una posible aportación interesante al resto del ecosistema Fedora.

Estado actual, prototipos y ecosistema alrededor de Hummingbird

La imagen Fedora Hummingbird bootc OS ya arranca hoy y puede probarse sin necesidad de registros, suscripciones ni herramientas de gestión de licencias como subscription-manager. El código está público, el pipeline está activo y el equipo anima a que más gente se suba al carro para someter el sistema a prueba real.

Existen ya prototipos de escritorios y bases estilo CoreOS sobre Hummingbird, impulsados por parte de la comunidad y por desarrolladores ligados a proyectos como Universal Blue. Se han creado imágenes base tipo “CoreOS Desktop” montadas en un día a partir de RPM de Fedora, que arrancan correctamente y sirven como prueba de que el enfoque es viable y está más cerca de la realidad de lo que parece.

En este contexto, se han explicado cambios de planes en proyectos comunitarios, como el abandono de esquemas de ramas stable→testing→next en favor de ramas de testing puntuales y un foco más decidido en imágenes selladas y Hummingbird. La idea es que este nuevo ecosistema atraerá a un perfil de contribuidor entusiasta por experimentar con modelos de sistema operativo de nueva generación.

La comunidad ya discute activamente estas ideas en hilos específicos, grupos de interés especial (SIG) y canales de conversación abiertos. El ambiente es el habitual de Fedora: mucha experimentación, debate técnico y una invitación explícita a que cualquiera con ganas se involucre, ya sea probando imágenes, reportando bugs o contribuyendo código.

Cómo empezar a probar Fedora Hummingbird hoy

Para quienes quieran trastear desde ya, el equipo propone un flujo de arranque rápido en máquina virtual usando Podman, bootc-image-builder y virt-install, aprovechando la imagen disponible en Quay.

Los pasos generales consisten en tirar de la imagen bootc OS de Hummingbird desde quay.io usando podman, ejecutar a continuación el contenedor de bootc-image-builder con los volúmenes adecuados para que genere una imagen qcow2 con sistema de ficheros ext4, y colocar esa imagen en la ruta de almacenamiento de libvirt.

Después, renombrando el fichero disk.qcow2 a un nombre más descriptivo y usando virt-install con parámetros sencillos (memoria, vCPUs, disco, red y gráficos VNC), se puede levantar rápidamente una máquina virtual Fedora Hummingbird. No es un instalador tradicional; básicamente estás arrancando directamente una imagen ya ensamblada.

A partir de ahí, se anima a probar el sistema, revisar su comportamiento, validar actualizaciones y reportar cualquier comportamiento extraño. El feedback es especialmente valioso en estas primeras fases, cuando aún se afina la integración entre el mundo Fedora tradicional y el de las imágenes Hummingbird.

Participar, contribuir y futuro del proyecto

Quien se anime a ir más allá de la simple prueba puede abrir issues, sugerir mejoras o enviar contribuciones directamente en el repositorio del proyecto, que hoy vive en gitlab.com/redhat/hummingbird/containers. Uno de los próximos pasos previstos es precisamente migrar y asentar el proyecto dentro de la propia infraestructura de Fedora.

Además, existen sesiones de iniciación y encuentros impulsados por el SIG relacionado con Hummingbird, donde se explica el modelo técnico, se resuelven dudas sobre el pipeline, la seguridad o la integración con herramientas como Podman, y se coordinan esfuerzos entre Red Hat y la comunidad Fedora.

A nivel de visión, se espera que Fedora Hummingbird se convierta en el laboratorio donde la comunidad prueba nuevos modelos de sistemas de base de imagen y mantenimiento continuo, antes de que esas ideas acaben influyendo en el resto del ecosistema Linux. Fedora siempre ha jugado ese papel de “banco de pruebas” de tecnologías que luego acaban dominando el panorama empresarial.

En conjunto, Fedora Hummingbird y su ecosistema asociado dibujan un futuro en el que los sistemas operativos se construyen y mantienen igual que los contenedores modernos: imágenes minimalistas, pipelines automáticos, seguridad integrada y ciclos de actualización que siguen el ritmo frenético del software de hoy, tanto para desarrolladores como para agentes de IA que necesitan entornos listos al vuelo.

from Linux Adictos https://ift.tt/JtUBV4g
via IFTTT

Google ha decidido dar un giro de calado a su estrategia en ordenadores portátiles con la llegada de Googlebook, una nueva categoría de dispositivos diseñada alrededor de la inteligencia artificial Gemini. Tras más de una década apostando por los Chromebook y por un modelo centrado en la nube, la compañía plantea ahora un salto hacia equipos que combinan Android, Chrome y una capa de IA omnipresente.

Lejos de ser un simple lavado de cara de ChromeOS, Googlebook se presenta como un cambio de paradigma: del clásico “sistema operativo” a lo que la empresa describe como un “sistema de inteligencia”. La idea es que el portátil deje de girar únicamente en torno al navegador y las apps para pasar a estar continuamente interpretado por Gemini, que sugerirá acciones, organizará información y conectará el portátil con el móvil de forma mucho más profunda.

Del Chromebook al Googlebook: una nueva etapa para el portátil de Google

Quince años después del lanzamiento de los primeros Chromebook, Google ha decidido abrir una nueva línea con Googlebook como heredero tecnológico y, a medio plazo, probable relevo estratégico. La compañía insiste en que no se trata de una sustitución inmediata: los Chromebook actuales, especialmente los modelos recientes y los Chromebook Plus, seguirán recibiendo soporte y se seguirán vendiendo, en particular en educación y gamas más asequibles.

Aun así, el mensaje de fondo es claro: Googlebook nace para cubrir un segmento más ambicioso y de gama alta, con materiales prémium, un diseño diferenciado y hardware más cuidado. Google habla de una transición progresiva en la que ChromeOS convivirá durante años con la nueva plataforma, pero todo apunta a que el foco de innovación se desplazará poco a poco hacia estos nuevos portátiles.

La propia Google ha explicado que Googlebook recoge “lo mejor de dos mundos”: la potencia de las apps Android y el peso del navegador Chrome, sobre una base técnica unificada y pensada desde el principio para la era de Gemini. Donde Chromebook apostaba por la simplicidad y el bajo coste, Googlebook se orienta a usuarios que buscan productividad avanzada, experiencias de IA y una mayor integración entre dispositivos.

AluminiumOS, Android 17 y el salto a un “sistema de inteligencia”

Uno de los aspectos más relevantes de esta nueva categoría es el software. Internamente, el sistema que mueve estos portátiles se conoce como AluminiumOS, una plataforma basada en Android 17 adaptada al escritorio. Google no ha confirmado todavía el nombre comercial definitivo, pero sí ha dejado claro que Android será la base sobre la que se construirá toda la experiencia.

En la práctica, esto significa que Googlebook utilizará la pila tecnológica de Android para ejecutar aplicaciones, servicios y funciones de IA, al tiempo que ofrecerá un navegador Chrome completo y una interfaz que recuerda bastante a ChromeOS: escritorio tradicional, barra de tareas, cajón de apps, sistema de ventanas, escritorios virtuales y un panel de notificaciones adaptado al formato de portátil.

Google lleva tiempo hablando de una base técnica común para móviles, tablets y ordenadores, y Googlebook es el paso más claro en esa dirección. La idea es aprovechar la madurez del ecosistema Android —su catálogo de apps, su eficiencia energética y la familiaridad de la interfaz— para plantar cara a Windows y macOS en el terreno del PC, pero con una capa de inteligencia artificial mucho más integrada que en el pasado.

Gemini en el centro: del asistente puntual a la capa principal de interacción

Si hay un elemento que define a Googlebook es la apuesta por una IA que deja de ser un simple asistente en segundo plano para convertirse en la auténtica interfaz del sistema. Google no se conforma con añadir un chatbot en una esquina del escritorio: quiere que Gemini interprete de forma continua lo que hay en pantalla y lo que hace el usuario.

La función más llamativa en este sentido es Magic Pointer o Magic Cursor, un “puntero inteligente” desarrollado junto a Google DeepMind. Al agitar ligeramente el cursor del ratón sobre un elemento, Gemini analiza el contenido y propone acciones contextuales: si se pasa por encima de una fecha en un correo, sugiere crear una reunión en el calendario; si se seleccionan dos imágenes —por ejemplo, una sala de estar y un sofá—, puede generar una composición que muestra cómo quedaría el mueble en esa habitación.

Google describe esta herramienta como una forma de convertir el ratón en una puerta directa a las capacidades de Gemini. La premisa es que el usuario deje de ir “a buscar” la IA en una aplicación separada y, en su lugar, sea el sistema el que vaya a él con sugerencias rápidas basadas en lo que ve en pantalla, desde tareas de organización hasta ayuda visual o edición de contenido.

Además del cursor inteligente, Googlebook incorpora Create your Widget (Crear tu Widget), una función que genera widgets personalizados mediante lenguaje natural. El usuario puede pedir, por ejemplo, un panel para un viaje y la IA se encarga de reunir en el escritorio vuelos, reservas de hotel, recomendaciones de restaurantes y una cuenta atrás hasta la fecha de salida, tirando de datos de Gmail, Google Calendar y otros servicios. La idea es que el escritorio se convierta en un panel vivo, construido a la carta y actualizado en tiempo real.

Integración profunda con el móvil Android

Otro de los pilares de Googlebook es la continuidad entre el portátil y el smartphone. Google quiere que el salto entre pantallas sea casi invisible, y para ello ha preparado varias funciones que recuerdan a los esfuerzos de Microsoft con Windows 11 o de Apple con macOS, pero extendidas al ecosistema Android. Una de las más destacadas es Cast My Apps (o Mostrar mis Apps), que permite usar en el portátil las aplicaciones instaladas en el móvil sin necesidad de volver a instalarlas ni abrir el teléfono.

Esta característica se complementa con Quick Access o Acceso rápido, un sistema que integra el almacenamiento del móvil directamente en el explorador de archivos del Googlebook. De este modo, fotos, documentos y vídeos guardados en el smartphone aparecen en el portátil como si fueran carpetas locales, listas para copiar, mover o compartir, incluso en sentido inverso del portátil al teléfono.

Google ya había experimentado con este tipo de integración en ChromeOS a partir de 2023, pero reconoce que aquella implementación era más limitada y menos fluida. Con Googlebook y la base Android, la compañía promete una experiencia mucho más cercana a la de un mismo sistema extendido por varios dispositivos, con portapapeles compartido, notificaciones sincronizadas y funciones de continuidad pensadas tanto para trabajo como para ocio.

Diseño y hardware: socios de siempre, pero con ambición prémium

Aunque Google se guarda aún muchos detalles, sí ha dejado trazado el perfil de hardware que acompañará a Googlebook. La empresa ha confirmado que trabajará con socios clásicos del ecosistema Chromebook: Acer, ASUS, Dell, HP y Lenovo, que serán los primeros fabricantes en lanzar modelos al mercado. La ventana de lanzamiento se sitúa en otoño, con especial atención a mercados clave de Europa y Norteamérica.

En cuanto a procesadores, la propuesta será heterogénea. Google ha adelantado que los Googlebook serán compatibles tanto con chips ARM como con plataformas x86. En el lado ARM, se mencionan socios habituales como Qualcomm y MediaTek, ya presentes en portátiles ligeros y Chromebook recientes, y nuevos SoC ARM como el N1x.

Dentro del catálogo de Intel, algunos analistas señalan que la familia Wildcat Lake, con configuraciones de seis núcleos y gráficas integradas Intel Arc Xe3 de bajo consumo, encaja muy bien con el tipo de portátil que Google plantea: equipos silenciosos, con buena autonomía y suficientes recursos gráficos para experiencias de IA y tareas multimedia, aunque conviene revisar informes sobre problemas con GPUs Intel en ciertos escenarios.

Las especificaciones detalladas —memoria, almacenamiento, resoluciones de pantalla o precios— también siguen sin confirmarse, pero las imágenes promocionales y las filtraciones dejan entrever portátiles relativamente delgados, con lector de huellas dactilares integrado, puertos como HDMI y un diseño cuidado. No parece que Google quiera repetir la imagen de “ordenadores baratos”. La autonomía será clave, por lo que convendrá optimizar la batería en estos equipos.

Glowbar: la firma visual de los nuevos Googlebook

Más allá de la ficha técnica, Google ha querido que Googlebook cuente con una seña de identidad visual muy marcada. Todos los modelos incorporarán lo que la compañía denomina Glowbar, una barra luminosa en la tapa o el cuerpo del portátil con los colores clásicos de Google. Este elemento, que en algunas imágenes aparece como una tira LED multicolor, servirá no solo como detalle estético, sino también como componente funcional.

Por ahora, Google ha explicado que la Glowbar será “funcional y bonita”, pero sin entrar en demasiados detalles. La interpretación más extendida es que actuará como sistema de notificaciones y estado: podría indicar visualmente si hay avisos pendientes, si Gemini está procesando una tarea, si el equipo está cargando o incluso reflejar estados de concentración o silencios programados, de forma similar a la luz de estado tradicional de algunos portátiles profesionales.

Este tipo de elemento busca, además, diferenciar a Googlebook en un mercado saturado de portátiles muy parecidos entre sí. En un contexto en el que cada vez cuesta más distinguir un modelo de otro a simple vista, una barra de luz con funciones concretas puede ayudar a reforzar la marca y crear un lenguaje de diseño reconocible para futuras generaciones de dispositivos.

Productividad de escritorio con alma de móvil

Con Googlebook, la compañía quiere convencer a quienes llevan años trabajando con Windows o macOS de que Android también puede ser un sistema de escritorio plenamente capaz. Para ello, AluminiumOS incorpora funciones orientadas a la productividad que se alejan del concepto de “móvil ampliado” y se acercan más a lo que se espera de un PC tradicional; la apuesta también busca competir con portátiles ultraligeros del mercado.

Entre estas funciones destacan un gestor de ventanas y escritorios virtuales pensado para organizar distintos flujos de trabajo, soporte nativo para carpetas en el escritorio, un administrador de tareas que permite controlar procesos y consumo de recursos con cierto detalle, y atajos de teclado y gestos de touchpad avanzados para moverse por la interfaz sin depender tanto del ratón.

Al mismo tiempo, el sistema respeta elementos clave del diseño móvil de Android, como un panel de notificaciones y ajustes rápidos adaptado al formato horizontal, o la integración profunda con Google Play para descargar aplicaciones optimizadas. El reto aquí será que desarrolladores y grandes proveedores de software adapten sus interfaces al uso con teclado y ratón, algo que, por ahora, sigue siendo una asignatura pendiente para muchas apps populares.

Educación y empresas: dónde encaja Googlebook

La presencia de Chromebook se había consolidado sobre todo en centros educativos y proyectos de digitalización escolar, donde el bajo coste y la gestión centralizada eran factores decisivos. Con Googlebook, Google apunta a un segmento diferente: usuarios que necesitan más potencia, mejor integración con el móvil, mayor capacidad de personalización y un aparato capaz de competir con ultrabooks de Windows y MacBook de Apple.

Esto no significa que Googlebook vaya a ignorar por completo el sector educativo o el uso profesional. De hecho, las funciones de IA para organizar información, generar widgets específicos y facilitar la colaboración pueden resultar especialmente útiles en entornos de estudio, trabajo remoto o empresas que ya dependen intensivamente de Google Workspace. La diferencia clave será el precio y la orientación: Googlebook se posiciona como un equipo más sofisticado y, previsiblemente, con un coste superior al de muchos Chromebook estándar, por lo que conviene valorar cómo elegir un portátil según necesidades.

En el plano empresarial, la apuesta de Google llega en un momento en el que la conversación en torno al “PC con IA” está en pleno auge. Microsoft impulsa los Copilot+ PC con Windows, mientras que Apple prepara la integración de Apple Intelligence en sus Mac. Googlebook pretende colocarse en esa misma liga, pero con un enfoque que parte directamente de Android y de la experiencia móvil, algo que podría encajar bien en compañías donde el teléfono Android es ya la herramienta principal del día a día.

Un ecosistema todavía lleno de incógnitas

Pese a todos los anuncios, Googlebook sigue envuelto en muchas preguntas abiertas. La compañía no ha confirmado el nombre final del sistema operativo ni ha detallado cómo se articulará la compatibilidad con aplicaciones antiguas de Android que no están optimizadas para teclado y ratón. Tampoco está claro cómo se posicionarán estos portátiles en precio frente a otros equipos con Windows, macOS o incluso frente a los propios Chromebook Plus.

Además, el historial de Google con sus plataformas de hardware y software genera cierta prudencia entre usuarios y fabricantes. Proyectos como Stadia, Hangouts o incluso algunas iteraciones de ChromeOS y Fuchsia mostraron ambición inicial pero acabaron desdibujándose con el tiempo. Para que Googlebook se consolide, la compañía tendrá que demostrar que esta vez la apuesta es de largo recorrido y que el soporte se mantendrá durante años, algo clave para escuelas, empresas y administraciones públicas.

A pesar de estas dudas, el movimiento de Google llega en un momento en el que la informática personal está entrando en una nueva fase marcada por la IA integrada en el propio sistema. Microsoft, Apple y ahora Google coinciden en que el portátil del futuro no se definirá solo por el sistema operativo, sino por la capa de inteligencia que lo acompaña de forma constante. Googlebook representa la versión más agresiva de esa idea dentro del ecosistema Android.

Con fabricantes como Acer, ASUS, Dell, HP, Lenovo e Intel ya subidos al carro, soporte para chips ARM y x86, y una integración profunda de Gemini en cada rincón de la experiencia, Googlebook aspira a ser mucho más que un simple sucesor del Chromebook. Queda por ver si el mercado acogerán esta propuesta como una alternativa real a los portátiles tradicionales o si se quedará en un experimento más dentro de la larga lista de proyectos de Google, pero la dirección marcada es clara: el portátil empieza a girar menos en torno al sistema operativo y más alrededor de la inteligencia que lo acompaña cada segundo.

from Linux Adictos https://ift.tt/e6SH7Ro
via IFTTT

Android 17 ya es oficial y llega con una hoja de ruta clara: dejar de ser solo una plataforma para aplicaciones y convertirse en una capa inteligente que trabaje por el usuario. Google ha aprovechado el Android Show: I/O Edition 2026 para detallar una actualización en la que la inteligencia artificial, la seguridad y la integración entre dispositivos pesan tanto como los cambios visuales.

Con esta versión, el sistema de Google da un salto hacia un entorno más conectado, en el que móvil, coche, reloj, portátil e incluso futuras gafas comparten funciones y contexto, apoyado por la convergencia del kernel. Aunque muchas de las novedades se desplegarán de forma gradual y primero en móviles Pixel y Samsung Galaxy, el objetivo final es que todo el ecosistema Android se beneficie de esta nueva capa de automatización.

Gemini Intelligence, la nueva capa que manda en Android 17

La gran protagonista del anuncio es Gemini Intelligence, el paraguas bajo el que Google agrupa todas las funciones de IA avanzada que se integran directamente en Android 17. No se trata solo de responder preguntas, sino de permitir que el asistente actúe dentro de las aplicaciones para completar tareas que hasta ahora exigían varios pasos manuales.

Gracias al marco de trabajo conocido como AppFunctions, las apps pueden exponer determinadas acciones para que Gemini las ejecute con instrucciones en lenguaje natural. Así es posible, por ejemplo, preparar una compra online a partir de una lista escrita en notas o incluso de una fotografía, buscar un viaje a partir de una imagen o rescatar datos concretos de Gmail para utilizarlos en otra aplicación sin ir copiando y pegando.

Google insiste en que el control sigue en manos del usuario. Las tareas iniciadas por Gemini muestran un progreso visible en la pantalla y necesitan confirmación antes de ejecutar operaciones sensibles como pagos, reservas o publicaciones. Al menos en su primera fase, el despliegue de Gemini Intelligence llegará primero a los Pixel más recientes y a los últimos Galaxy, para extenderse después a otros dispositivos y categorías como relojes, coches o portátiles.

Buena parte de estas capacidades también se integran en Chrome para Android. Desde el icono de Gemini en el navegador será posible resumir páginas web, pedir explicaciones sobre un contenido concreto o lanzar consultas relacionadas con lo que aparece en pantalla, sin abandonar el sitio que se está visitando. Esta función aterrizará primero en algunos mercados y en teléfonos con Android 12 o superior.

Además, Chrome incorpora una herramienta de automatización llamada auto browse, pensada para encargarse de procesos repetitivos como reservar aparcamiento, gestionar pedidos sencillos o completar formularios usando información contextual del propio usuario. Como en el resto del sistema, Google promete avisos claros y confirmaciones adicionales antes de cualquier operación de compra o acción delicada.

Rambler, widgets generados por IA y una pantalla de inicio más inteligente

Android 17 también lleva Gemini al teclado y a la pantalla de inicio. En Gboard aparece Rambler, una función diseñada para transformar mensajes de voz en texto de una forma más limpia de lo habitual. No se limita a transcribir palabra por palabra: elimina repeticiones, titubeos y pausas innecesarias para producir mensajes más coherentes y legibles.

La compañía explica que el audio se utiliza solo para la transcripción en tiempo real y no se almacena de forma permanente, un punto importante de cara a la privacidad, especialmente en Europa, donde estas cuestiones suelen estar bajo mayor escrutinio regulatorio.

Otro frente donde la IA toma protagonismo es la creación de widgets. Con la función Create My Widget, Android 17 permite describir con lenguaje natural qué tipo de información se quiere tener a mano en la pantalla principal, y es Gemini quien se encarga de construir un widget funcional con datos relevantes.

Durante la presentación se mostraron ejemplos muy variados, desde paneles con recetas semanales y listas de tareas hasta widgets de clima extremadamente detallado o módulos de productividad con diferentes fuentes de información combinadas. La idea es que el usuario no tenga que ir probando plantillas una a una, sino que el propio sistema genere una solución a medida.

Todo este conjunto de funciones se complementa con nuevas capacidades de automatización de tareas en apps de transporte, compras o comida a domicilio. Android 17 puede, por ejemplo, tomar una lista de la compra guardada en notas o en una foto para preparar un pedido online en segundo plano, reduciendo al mínimo la interacción necesaria para completar procesos cotidianos.

Android Auto y el coche: nueva interfaz, más IA y mejoras multimedia

El coche es uno de los escenarios donde Android 17 más se deja notar. Google ha preparado una de las mayores renovaciones recientes de Android Auto, tanto a nivel visual como funcional, apostando por una interfaz que se adapta mejor a distintos formatos de pantalla y que integra más información sin saturar al conductor.

La nueva versión se basa por completo en el lenguaje de diseño Material 3 Expressive, introduciendo paneles más claros, nuevos widgets visibles durante la navegación y una actualización profunda de Google Maps en el salpicadero. Esta modalidad, llamada en algunos casos Immersive Navigation, añade vistas en 3D con edificios, carriles diferenciados, semáforos y señales de stop, algo que desde la propia empresa consideran uno de los mayores cambios en Maps dentro del coche en la última década.

Android Auto también se refuerza en el apartado multimedia con reproducción de vídeo en Full HD a 60 fps cuando el vehículo está aparcado o cargando, con cambio automático a audio si el coche se pone en marcha en aplicaciones compatibles. A esto se suma un mejor tratamiento del sonido espacial, con soporte para tecnologías como Dolby Atmos en sistemas adecuados.

Gemini se integra además en la experiencia a bordo para gestionar mensajes con más contexto, consultar datos del calendario o del correo y, en determinados mercados, preparar pedidos en servicios asociados mientras el usuario se centra en la conducción. En paralelo, los coches con Google integrado de fábrica amplían catálogo de aplicaciones, funciones de videoconferencia y opciones ligadas directamente al vehículo.

De esta manera, Android 17 no solo se juega su papel en el móvil, sino también en el coche conectado, un ámbito donde el mercado europeo es especialmente relevante y donde la competencia con otros sistemas de infoentretenimiento es cada vez mayor, hasta el punto de que algunos fabricantes exploran la sustitución por HarmonyOS en sus dispositivos.

Rendimiento, gaming y cambios en la instalación de APKs

Más allá de la inteligencia artificial y del coche, Android 17 incorpora un conjunto de mejoras de rendimiento invisibles a simple vista pero importantes en el día a día. El kernel es capaz de aprender de los perfiles de ejecución de las aplicaciones para reducir tirones en la interfaz y acelerar la apertura, una tecnología conocida internamente como AutoFDO.

Para los juegos, el sistema añade soporte nativo para el remapeo de botones de mandos de Xbox o PlayStation, así como un modo de mando virtual que traduce los toques de pantalla en señales físicas. Esto permite usar controladores físicos en títulos pensados únicamente para controles táctiles, algo que puede interesar a quienes utilizan monitores externos o accesorios específicos.

La memoria RAM también entra en escena con más protagonismo. Android 17 introduce límites de uso de RAM por aplicación en función de la cantidad disponible en cada dispositivo. Si una app intenta consumir más de lo razonable, el sistema puede cerrarla para evitar bloqueos generales y preservar la fluidez. Es un ajuste especialmente relevante para móviles con especificaciones más modestas, todavía muy presentes en buena parte de Europa.

Uno de los puntos más delicados de esta versión tiene que ver con la instalación de APKs fuera de la tienda oficial. Google endurece los requisitos y exigirá que los desarrolladores verifiquen su identidad para que sus archivos APK puedan instalarse, incluso aunque se distribuyan desde repositorios ajenos a la Play Store. Este movimiento se encuadra dentro de un proceso interno conocido como Advanced Flow.

La medida se justifica bajo el paraguas de la seguridad, pero supone un golpe a la histórica libertad de Android a la hora de instalar software de fuentes alternativas. Parte de la comunidad de usuarios avanzados y proyectos de software libre ve con preocupación el impacto que pueda tener en tiendas independientes y desarrolladores que tradicionalmente han operado sin pasar por el circuito oficial.

Seguridad, privacidad y protección frente a fraudes

Android 17 dedica un bloque amplio a la seguridad, un apartado especialmente sensible en regiones como la Unión Europea, donde las normativas de protección del usuario son cada vez más estrictas. Google refuerza Live Threat Detection para identificar en tiempo real comportamientos sospechosos en aplicaciones, como desvío de SMS, abuso de servicios de accesibilidad o cambios extraños en iconos y lanzadores.

Chrome para Android añade una capa de revisión adicional cuando se descargan archivos APK desde el navegador. Si el usuario tiene Safe Browsing activado, el navegador analiza las aplicaciones descargadas para detectar malware conocido antes de que lleguen a instalarse en el dispositivo, reduciendo el riesgo de infecciones derivadas de descargas casuales.

El modo Advanced Protection también gana alcance en esta edición, con restricciones más severas para las apps que no se han adaptado a las últimas recomendaciones de accesibilidad, limitaciones adicionales en determinadas funciones de desbloqueo entre dispositivos y mecanismos para mitigar ataques dirigidos. Son ajustes que se notarán más en usuarios que opten por los modos de protección avanzados, pero ayudan a construir una capa de seguridad más sólida.

En respuesta al incremento de robos y estafas, Android 17 incorpora nuevas barreras contra el robo físico del terminal. La función de marcado como perdido podrá exigir autenticación biométrica para volver a desbloquear el teléfono, incluso si alguien conoce el PIN. Se refuerzan además medidas como ocultar ajustes rápidos en situaciones de riesgo y bloquear ciertas conexiones nuevas que puedan usarse para extraer datos.

Google amplía el despliegue global de protecciones antirrobo como Remote Lock o Theft Detection Lock en móviles nuevos o actualizados a Android 17, con la intención de que estas herramientas lleguen a más países europeos sin necesidad de configuraciones complejas. En paralelo, el sistema incorpora una verificación específica para llamadas bancarias: en colaboración con determinadas entidades financieras, Android puede analizar si una llamada que parece provenir del banco ha sido suplantada y, en caso de detectar anomalías, cortar la comunicación automáticamente.

Nuevos controles de privacidad, OTP más seguros y cambios en el día a día

La privacidad es otro de los pilares de Android 17. El sistema introduce un botón de localización temporal que permite compartir ubicación precisa solo mientras una app concreta está abierta, evitando permisos permanentes para tareas puntuales. Además, se muestra un indicador claro cuando una aplicación accede a la localización, junto con un panel reciente donde revisar qué servicios la han utilizado.

Los permisos de contactos también se vuelven más finos. Las aplicaciones pueden solicitar acceso únicamente a contactos específicos o a determinados campos, en lugar de abarcar toda la agenda. Este enfoque, similar a lo que ya se había visto en otros sistemas, encaja con la tendencia regulatoria europea de limitar el acceso masivo a datos personales.

Para los códigos de verificación enviados por SMS, Android 17 incorpora nuevas protecciones para los OTP, endureciendo su acceso y dificultando que aplicaciones maliciosas puedan leerlos de forma silenciosa. En determinados escenarios, el sistema puede retrasar o restringir el uso de estos mensajes para apps de terceros, un movimiento dirigido a frenar fraudes bancarios y ataques que se aprovechan de la verificación en dos pasos.

En el plano de la conectividad se recupera algo que muchos usuarios llevaban tiempo reclamando: la separación de los controles de WiFi y datos móviles en los ajustes rápidos. Es un cambio menor sobre el papel, pero facilita la gestión del consumo de datos, especialmente para quienes combinan tarifas móviles y redes inalámbricas en su día a día.

Entre los ajustes pensados para el bienestar digital aparece Pause Point, una opción que introduce una pequeña pausa antes de abrir aquellas aplicaciones marcadas como potencialmente distractoras, como redes sociales o juegos. No bloquea el acceso, pero añade un paso intermedio que puede ayudar a reducir aperturas impulsivas y a ganar algo de control sobre el tiempo que se pasa en el móvil.

Por último, Google ha renovado por completo su colección de emojis, con más de 4.000 iconos que adoptan un aspecto algo más tridimensional, con mayor profundidad y detalle respecto a versiones anteriores más planas. Estas novedades gráficas empezarán a llegar primero a los terminales Pixel y, posteriormente, al resto de fabricantes a medida que integren Android 17 en sus capas.

Experiencia entre dispositivos, portapapeles universal y creación de contenido

Uno de los objetivos clave de Android 17 es mejorar la interoperabilidad entre dispositivos, un área en la que Google quiere competir de tú a tú con otros ecosistemas bien integrados. La llegada del portapapeles universal permite copiar texto o contenido en el móvil y pegarlo en el ordenador, y viceversa, sin procesos intermedios complicados, algo que hasta ahora estaba más asociado a otros fabricantes.

La compatibilidad ampliada de Quick Share con AirDrop va en la misma línea. A lo largo del año, el sistema de envío rápido de archivos de Google se abrirá al intercambio con dispositivos de la competencia, haciendo más sencillo pasar fotos, documentos o enlaces entre móviles Android, ordenadores y otros equipos, sin depender tanto de cables o aplicaciones de terceros.

Android 17 también incorpora mejoras en las herramientas de creación de contenido. En los Pixel se estrena Screen Reactions, una función que permite grabar simultáneamente la pantalla y la cámara frontal, pensada para vídeos de reacción, tutoriales o contenido educativo. Google, además, está trabajando con plataformas como Instagram para aprovechar mejor las capacidades de los móviles más avanzados: Ultra HDR, estabilización reforzada o modos nocturnos optimizados.

En el terreno de la edición, la aplicación Edits suma opciones como mejoras automáticas de imagen y separación de audio por pistas, mientras que herramientas profesionales como Adobe Premiere están previstas para llegar de forma nativa al ecosistema Android. El objetivo es que el teléfono pueda cubrir no solo la captura, sino también buena parte del proceso de edición y publicación.

Todo esto se enmarca en una visión en la que Android quiere dejar de depender tanto de la intervención manual del usuario para tareas simples y convertir a la inteligencia artificial en un componente estructural del sistema. A medida que el despliegue se vaya extendiendo por Europa y el resto de regiones, serán los propios usuarios quienes comprueben hasta qué punto estas novedades encajan con su día a día y con las exigencias regulatorias de cada mercado.

Con la presentación oficial de Android 17, Google dibuja un escenario en el que Gemini Intelligence, las mejoras de rendimiento, las nuevas capas de seguridad y la interoperabilidad entre dispositivos se combinan para ofrecer un sistema más proactivo, más protegido y mejor integrado, pero también algo más controlado en lo que respecta a la instalación de software externo, marcando un punto de inflexión en la evolución de la plataforma.

from Linux Adictos https://ift.tt/zfIUHBK
via IFTTT

La irrupción de OpenAI Daybreak marca un nuevo movimiento en la carrera por dominar la ciberseguridad con inteligencia artificial. Mientras empresas y administraciones públicas lidian con un aumento constante de ataques informáticos, OpenAI ha decidido dar un paso más allá de los chatbots y entrar de lleno en el terreno de la defensa digital automatizada.

Lejos de ser un simple modelo más de la familia GPT, Daybreak se presenta como una iniciativa integral de ciberdefensa que combina modelos avanzados de OpenAI, agentes especializados de Codex Security y la colaboración de socios expertos en seguridad. Su objetivo: detectar, analizar y parchear vulnerabilidades en código y sistemas antes de que los atacantes puedan explotarlas.

Qué es OpenAI Daybreak y qué problema quiere resolver

OpenAI describe Daybreak como una plataforma de ciberseguridad impulsada por IA, diseñada para que desarrolladores, equipos de seguridad corporativos e instituciones públicas puedan encontrar y corregir fallos en el software en fases muy tempranas del ciclo de vida. La idea es pasar de una seguridad reactiva, basada en apagar fuegos, a un enfoque claramente preventivo.

En la práctica, Daybreak actúa como un analista de seguridad senior automatizado que vive dentro del propio entorno de desarrollo. Analiza bases de código, revisa dependencias, modela posibles rutas de ataque, clasifica vulnerabilidades por criticidad y propone (o incluso aplica) parches en cuestión de segundos, reduciendo al mínimo el tiempo entre el descubrimiento de un fallo y su solución.

Esta iniciativa llega en un contexto en el que la digitalización total de datos y procesos ha convertido la ciberseguridad en un asunto crítico. Documentos sensibles, infraestructura cloud, aplicaciones internas y servicios públicos dependen de sistemas conectados. Un solo agujero en el código puede comprometer información corporativa, datos personales protegidos por el GDPR o incluso servicios esenciales.

OpenAI enmarca Daybreak en una estrategia más amplia de “software resiliente por diseño”, donde la seguridad se integra desde la primera línea de código y no se limita a auditorías finales o a herramientas clásicas como antivirus y firewalls.

Cómo funciona Daybreak: agentes de IA al servicio de la ciberdefensa

El corazón técnico de la propuesta es Codex Security, un agente de IA orientado a programación que OpenAI ha potenciado específicamente para tareas de seguridad. En el marco de Daybreak, este agente se encarga de generar modelos de amenazas adaptados al código de cada organización y de automatizar gran parte del trabajo que tradicionalmente recaería en un equipo de seguridad experimentado.

Según lo descrito por la compañía, Daybreak es capaz de lanzar múltiples subagentes de Codex Security en paralelo para revisar un repositorio de código. Estos subagentes analizan dependencias, detectan vulnerabilidades relevantes, proponen correcciones, validan los parches aplicados e incluso añaden pruebas de regresión para reducir el riesgo de romper funcionalidades existentes.

En demostraciones internas, OpenAI muestra cómo el sistema pasa en muy poco tiempo de identificar un fallo a sugerir y validar una solución. La promesa es que el proceso completo, desde la detección de la vulnerabilidad hasta su remediación, se acelere drásticamente frente a los flujos habituales, donde pueden pasar días o semanas.

Además de la detección de bugs, Daybreak puede clasificar problemas por nivel de riesgo, priorizar los que suponen una mayor exposición, documentar las vulnerabilidades encontradas e integrarse en los pull requests para que los agentes de IA ayuden a corregir el código antes de que llegue a producción. La herramienta encaja, por tanto, con prácticas DevSecOps en las que desarrollo, operaciones y seguridad trabajan de forma continua y coordinada.

Otro elemento clave es el uso de versiones especializadas de los modelos generales de OpenAI, como GPT‑5.5 con Trusted Access y variantes centradas en ciberseguridad (caso de GPT‑5.5‑Cyber). Estos modelos aportan capacidad de razonamiento avanzado sobre sistemas desconocidos, análisis de configuraciones complejas y generación de informes técnicos que facilitan la labor de los responsables de seguridad.

La carrera Daybreak vs Claude Mythos: IA defensiva frente a IA ofensiva

El lanzamiento de Daybreak se entiende mejor en el contexto de la competencia directa entre OpenAI y Anthropic. Esta última sorprendió recientemente al sector con Claude Mythos, un modelo orientado a seguridad que ha demostrado ser capaz de localizar cientos de vulnerabilidades que los equipos humanos y las herramientas tradicionales pasaban por alto.

Claude Mythos ha sido descrito como una especie de “arma de doble filo”: tremendamente eficaz para encontrar bugs en software crítico, pero potencialmente muy peligroso si se utiliza con fines ofensivos para diseñar intrusiones, malware o espionaje. Por ese motivo, Anthropic ha optado por un despliegue muy limitado, restringido a un pequeño grupo de organizaciones, principalmente estadounidenses.

Daybreak adopta un enfoque complementario. Aunque también identifica vulnerabilidades, su énfasis está en la defensa proactiva: usar el conocimiento “hacker” del sistema para tapar agujeros antes de que se conviertan en un problema real. Donde Mythos pone el foco en un escaneo masivo de fallos, OpenAI quiere que Daybreak se incruste en el ciclo de desarrollo y parchee en tiempo real.

La propia OpenAI reconoce que las capacidades que hacen fuerte a Daybreak en el ámbito defensivo pueden ser aprovechadas con malas intenciones. Por eso, la empresa insiste en salvaguardas, verificación y controles de acceso, dentro de un despliegue iterativo y supervisado con socios de la industria y administraciones públicas.

En este pulso entre compañías, se está configurando un escenario de “IA contra IA” en ciberseguridad: modelos que buscan agujeros frente a modelos que intentan cerrarlos incluso antes de que se exploten. Un ciclo de innovación rápida que tiene implicaciones tanto técnicas como regulatorias.

Acceso, socios y despliegue inicial de Daybreak

Daybreak no está pensado como un producto de consumo masivo. OpenAI indica que su público objetivo incluye desarrolladores, equipos de seguridad corporativos, investigadores y defensores vinculados al sector público que necesiten detectar, validar y corregir vulnerabilidades en software desde etapas tempranas.

El acceso estará mediado por programas como Trusted Access for Cyber, a través de los cuales OpenAI evaluará qué organizaciones pueden utilizar las capacidades más avanzadas de sus modelos de ciberseguridad. En los primeros compases, se prevé un despliegue limitado a cientos de clientes, con ampliaciones progresivas conforme se pulan aspectos técnicos y de gobernanza.

La compañía destaca, además, una amplia red de socios tecnológicos que colaboran en el ecosistema Daybreak, incluyendo proveedores de infraestructura, empresas de seguridad y actores especializados en análisis de vulnerabilidades y distros de seguridad. Este entramado pretende reforzar la integración con herramientas existentes de monitorización, escaneo y respuesta a incidentes.

Al mismo tiempo, OpenAI ha habilitado mecanismos para que empresas de distintos tamaños puedan solicitar el uso de Daybreak, enviando información básica sobre su perfil y necesidades. En función de esa evaluación y del riesgo asociado, la compañía decide si concede acceso y en qué condiciones, manteniendo cierto control sobre los despliegues iniciales.

En paralelo, la firma trabaja con gobiernos y organismos reguladores para definir cómo encajan estas capacidades de IA avanzada en los marcos legales y de seguridad nacional, un punto especialmente delicado en territorios como la Unión Europea, donde la regulación tecnológica se está endureciendo.

Impacto para empresas: seguridad «by design» y cumplimiento normativo

Daybreak puede convertirse en una herramienta relevante si consigue democratizar el acceso a capacidades de ciberdefensa de nivel corporativo sin exigir grandes equipos internos de seguridad.

Las compañías que desarrollan software, manejan datos sensibles o dependen de la nube se enfrentan a un doble reto: por un lado, protegerse frente a ataques cada vez más sofisticados; por otro, cumplir con normativas estrictas como el GDPR en materia de protección de datos, o la Directiva NIS2 en seguridad de redes y sistemas de información.

Daybreak ofrece, en teoría, varias ventajas alineadas con estas exigencias. Su capacidad para documentar automáticamente vulnerabilidades detectadas y parches aplicados podría facilitar auditorías y procesos de cumplimiento, aportando trazabilidad sobre qué se ha corregido, cuándo y con qué criterios.

El enfoque de “seguridad desde el diseño” también encaja con las demandas regulatorias europeas, que empujan a las organizaciones a incorporar ciberresiliencia en todas las fases del desarrollo y no solo a parchear después de un incidente. Integrar Daybreak en pipelines DevSecOps permitiría filtrar código inseguro desde el arranque y reducir el coste de arreglar fallos a posteriori.

Ahora bien, el acceso restringido y el hecho de que OpenAI no haya hecho públicos todos los detalles sobre costes, niveles de servicio y compatibilidad con stacks existentes significa que, al menos en el corto plazo, las startups tendrán que valorar cuidadosamente el retorno de inversión frente a alternativas open source o soluciones ya implantadas.

Riesgos, salvaguardas y cambio de modelo en la ciberseguridad

El avance de iniciativas como Daybreak se produce en un momento en el que las propias herramientas de IA son vistas como un vector de riesgo. Investigadores y organismos públicos han advertido de que modelos avanzados pueden facilitar la automatización del reconocimiento de vulnerabilidades, la generación de malware y el diseño de campañas de phishing más creíbles.

OpenAI intenta responder a estas preocupaciones subrayando que Daybreak incorporará mecanismos de confianza y verificación, así como salvaguardas proporcionales y políticas estrictas de uso. La empresa ya ha realizado campañas de limpieza de cuentas y endurecimiento de normas para evitar abusos, especialmente cuando se detectan patrones sospechosos o uso automatizado no autorizado.

Aun con estas medidas, la adopción de IA en ciberseguridad plantea retos de gobernanza y supervisión humana. Un exceso de confianza en sistemas automatizados puede generar puntos ciegos, mientras que un diseño deficiente de alertas podría saturar a los equipos o, en el peor de los casos, pasar por alto intrusiones críticas.

El enfoque de despliegue iterativo que plantea OpenAI, apoyándose en socios industriales y gubernamentales, busca precisamente ajustar las capacidades técnicas al nivel de riesgo aceptable. La experiencia acumulada con programas como su Safety Bug Bounty o iniciativas de formación en seguridad de IA apunta a que la compañía quiere construir un ecosistema defensivo más amplio, no solo lanzar una herramienta aislada.

En cualquier caso, el movimiento contribuye a acelerar un cambio de paradigma: la ciberseguridad deja de apoyarse únicamente en firmas estáticas, reglas manuales o revisiones puntuales, y se desplaza hacia sistemas que razonan sobre el código y los entornos en tiempo real, aprendiendo y adaptándose a medida que evolucionan las amenazas.

La aparición de OpenAI Daybreak, en plena carrera con propuestas como Claude Mythos, confirma que la próxima gran batalla de la IA se librará en el terreno de la defensa digital. Para empresas, instituciones y desarrolladores, el reto será saber aprovechar estas capacidades sin perder de vista los requisitos regulatorios, la transparencia y la necesidad de mantener el control humano sobre decisiones críticas de seguridad.

from Linux Adictos https://ift.tt/Z3IQ7Ye
via IFTTT

La llegada de GStreamer 1.28.3 marca un nuevo paso en la evolución de uno de los frameworks multimedia libres y multiplaforma más utilizados en el sector audiovisual y de las comunicaciones en tiempo real. Esta versión se presenta como una actualización de mantenimiento de la rama 1.28, pero incluye cambios técnicos que pueden tener un impacto relevante en proyectos que dependen de la aceleración de vídeo, la transmisión web y la integración con gráficos.

Aunque la actualización está orientada principalmente a pulir y reforzar la estabilidad del conjunto, GStreamer 1.28.3 incorpora también nuevas capacidades que interesan especialmente a desarrolladores que trabajan con dispositivos embebidos, soluciones de streaming profesional o aplicaciones WebRTC. Las mejoras llegan tanto a nivel de codificación de vídeo como de gestión interna de colas de datos y soporte avanzado para OpenGL.

Nueva actualización de la serie GStreamer 1.28

La versión 1.28.3 se sitúa como la tercera entrega de mantenimiento dentro de la serie 1.28 de GStreamer, una rama que busca combinar estabilidad con funciones avanzadas para aplicaciones multimedia modernas. Esta publicación se produce aproximadamente un mes después de GStreamer 1.28.2, lo que muestra un ciclo de revisión relativamente ágil, orientado a corregir fallos y a introducir pequeños incrementos funcionales sin romper la compatibilidad.

GStreamer sigue siendo una opción clave en entornos Linux, Windows y macOS, así como en sistemas embebidos que se utilizan de forma habitual para cartelería digital, videoconferencia, sistemas de infoentretenimiento y soluciones IoT. La serie 1.28 se considera actualmente la línea recomendada para integraciones que necesitan mantenerse actualizadas sin arriesgar la estabilidad del entorno de producción.

Soporte H.265 acelerado por hardware en NXP i.MX 8M Plus

Uno de los cambios más llamativos de esta versión es la incorporación de soporte de codificación H.265 con aceleración por hardware para el procesador NXP i.MX 8M Plus dentro del elemento webrtcsink. Este componente es ampliamente utilizado para enviar contenidos de vídeo a través de WebRTC, una tecnología muy extendida en soluciones de transmisión en directo y videollamadas.

El procesador NXP i.MX 8M Plus está muy presente en el mercado de dispositivos embebidos, utilizado en proyectos industriales, sistemas de visión artificial, dispositivos de videovigilancia y equipos de borde. Que GStreamer 1.28.3 aproveche la codificación H.265 (HEVC) por hardware significa menor consumo de CPU, mejor eficiencia energética y reducción de latencia en pipelines de vídeo complejos, algo especialmente relevante en entornos donde se prioriza la respuesta en tiempo real.

Para equipos de desarrollo en España y otros países de la UE que trabajen con plataformas basadas en NXP, esta novedad facilita desplegar servicios de streaming y comunicación interactiva con calidad de imagen elevada y tasas de compresión más eficientes. En muchos escenarios, eso se traduce en menor uso de ancho de banda y en la posibilidad de ofrecer vídeo de alta resolución en redes con recursos limitados.

Mejoras en los elementos basados en dataqueue

La actualización de GStreamer introduce un nuevo modo «leaky» en los elementos basados en dataqueue, el sistema interno que controla cómo se encolan y gestionan los buffers de datos dentro de una tubería multimedia. El modo leaky permite descartar información cuando la cola se encuentra bajo presión, evitando bloqueos o acumulaciones excesivas que puedan degradar el rendimiento general.

En la práctica, este enfoque resulta útil en aplicaciones de streaming en directo o videovigilancia, donde es preferible perder algunos fotogramas antes que incrementar la latencia de forma constante. Para desarrolladores y administradores de sistemas que operan servicios multimedia en infraestructuras, disponer de más control sobre el comportamiento de las colas puede ayudar a ajustar mejor la calidad de servicio a las condiciones reales de red.

Además, la incorporación de este modo leaky en los elementos basados en dataqueue permite que las pipelines se adapten de forma más flexible a distintos perfiles de uso, desde entornos domésticos con conexiones variables hasta plataformas profesionales que priorizan la inmediatez de la señal frente a la integridad absoluta de todos los fotogramas.

Nuevas propiedades en el elemento fallbacksrc

Otro punto destacado de GStreamer 1.28.3 es la adición de las propiedades fallback-source y enable-dummy al elemento fallbacksrc. Este componente está pensado para manejar fuentes de entrada alternativas cuando la fuente principal falla o deja de estar disponible, una función crucial en sistemas que necesitan garantizar continuidad de servicio.

Con la propiedad fallback-source, los desarrolladores pueden definir de forma más precisa qué fuente secundaria se utilizará en caso de interrupción, lo que simplifica el diseño de pipelines robustas. Por su parte, enable-dummy permite activar una fuente ficticia cuando no hay contenidos reales disponibles, evitando cortes bruscos y manteniendo la estructura de la tubería operativa.

Este tipo de capacidades son especialmente interesantes para servicios de streaming implantados, como plataformas de formación online, medios de comunicación o soluciones de señalización digital en transporte público y espacios comerciales. Al mejorar la lógica de reserva, se reducen los tiempos de caída percibidos por el usuario final y se facilita la gestión automática de errores sin intervención manual constante.

Soporte GBRA swizzle en OpenGL

GStreamer 1.28.3 incorpora también soporte para GBRA swizzle en OpenGL, una característica técnica que amplía las opciones de manipulación de los canales de color en pipelines que combinan vídeo y gráficos acelerados por GPU. El «swizzle» hace referencia al reordenamiento de los componentes de color, y el soporte de GBRA ofrece más flexibilidad a la hora de adaptar diferentes formatos y flujos.

Esta mejora cobra importancia en aplicaciones que integran efectos gráficos, overlays o composiciones avanzadas, como pueden ser plataformas de emisión en directo, mezcladores de vídeo software o soluciones de cartelería interactiva. Donde la industria audiovisual y de broadcast apuesta cada vez más por flujos IP y software definidos, contar con un soporte más completo en OpenGL ayuda a simplificar la integración entre motores gráficos y GStreamer.

Al permitir un manejo más fino de formatos de píxel y canales de color, se abre la puerta a optimizaciones internas y a una gestión más coherente de contenidos procedentes de distintas fuentes, algo habitual cuando se combinan cámaras, capturadoras, gráficos generados en tiempo real y contenido pregrabado en una misma pipeline.

Impacto para desarrolladores y proyectos

La suma de estas novedades en GStreamer 1.28.3, aunque presentada como una actualización de mantenimiento, tiene implicaciones prácticas en muchos proyectos que se desarrollan y despliegan en todo el mundo. Desde integradores de sistemas hasta empresas de software especializadas en vídeo, las mejoras en codificación, gestión de colas y soporte gráfico pueden traducirse en soluciones más estables y eficientes.

En entornos donde se utilizan chips NXP i.MX 8M Plus para procesamiento en el borde, la posibilidad de aprovechar la codificación H.265 acelerada por hardware dentro de flujos WebRTC facilita el diseño de dispositivos conectados que envían vídeo en alta calidad con un consumo energético moderado. A su vez, las nuevas opciones de fallback y el modo leaky en dataqueue reducen el riesgo de interrupciones graves en servicios de streaming continuo.

Para equipos técnicos que ya trabajan con la rama 1.28, adoptar la versión 1.28.3 supone mantenerse al día con las últimas correcciones y ajustes, incorporando al mismo tiempo funcionalidades que pueden marcar la diferencia en situaciones de producción. Aunque no se trata de una gran revisión de la API, la combinación de pequeños cambios bien orientados refuerza el papel de GStreamer como base para productos y servicios multimedia en el mercado.

La actualización de GStreamer 1.28.3 demuestra que, incluso en lanzamientos considerados de mantenimiento, pueden introducirse mejoras técnicas relevantes para el ecosistema multimedia profesional y embebido. Con un mejor soporte para H.265 en hardware específico, nuevas herramientas para gestionar fuentes de vídeo y colas de datos, y capacidades ampliadas en OpenGL, esta versión apunta directamente a reforzar la fiabilidad y la flexibilidad de las pipelines que sostienen buena parte de las soluciones audiovisuales actuales.

from Linux Adictos https://ift.tt/Aw1eftr
via IFTTT

PeaZip 11.1 ya está disponible como nueva versión del conocido gestor de archivos comprimidos multiplataforma. Esta actualización incorpora importantes correcciones de seguridad, mejoras internas y una actualización del backend 7z, reforzando la estabilidad y compatibilidad de una de las alternativas más populares a WinRAR y 7-Zip en Linux y Windows. Esta versión ha llegado un mes después de la v11.0.

El proyecto continúa evolucionando con un fuerte enfoque en la seguridad y la compatibilidad con múltiples formatos de compresión. Además de las correcciones técnicas, PeaZip 11.1 también introduce pequeños ajustes en la interfaz y optimizaciones destinadas a mejorar el rendimiento general durante la extracción y creación de archivos comprimidos. La aplicación mantiene además su compatibilidad con más de 200 formatos diferentes.

PeaZip 11.1 mejora la seguridad y actualiza el motor 7z

Uno de los cambios más importantes de PeaZip 11.1 es la actualización de su backend 7z a una versión más reciente, incorporando nuevas mejoras de rendimiento y compatibilidad para archivos comprimidos. Gracias a ello, la aplicación puede manejar distintos formatos de forma más eficiente y segura, especialmente en tareas de compresión avanzada y cifrado.

La actualización también corrige varios problemas de seguridad detectados en versiones anteriores. Aunque no se trata de vulnerabilidades críticas ampliamente explotadas, el equipo de desarrollo ha reforzado distintos componentes internos para reducir posibles riesgos relacionados con la gestión de archivos comprimidos malformados o dañados.

PeaZip 11.1 incluye además mejoras en la navegación por archivos, pequeños ajustes visuales y optimizaciones relacionadas con la integración del sistema. Estas mejoras buscan ofrecer una experiencia más fluida tanto en Linux como en Windows, donde PeaZip sigue ganando popularidad como alternativa gratuita y de código abierto frente a otras soluciones más conocidas.

Otro aspecto destacado es que PeaZip continúa apostando por herramientas avanzadas de seguridad y privacidad. La aplicación permite cifrado AES-256, autenticación de doble factor mediante archivos clave y funciones de borrado seguro, características especialmente valoradas por usuarios avanzados y entornos profesionales.

La nueva versión también mejora la compatibilidad con sistemas modernos y mantiene soporte para arquitecturas y escritorios variados dentro del ecosistema Linux. Gracias a ello, PeaZip sigue posicionándose como una de las herramientas de compresión más completas y versátiles disponibles actualmente en software libre.

Con PeaZip 11.1, el proyecto continúa consolidándose como una alternativa potente para usuarios que buscan un gestor de archivos comprimidos rápido, seguro y compatible con una enorme variedad de formatos sin depender de soluciones propietarias.

from Linux Adictos https://ift.tt/BA6RUqM
via IFTTT

SparkyLinux 8.3 ya está disponible como nueva actualización de mantenimiento para esta distribución basada en Debian Stable. La nueva versión incorpora entornos de escritorio actualizados, múltiples correcciones y mejoras generales enfocadas en mantener una experiencia ligera, estable y moderna para distintos tipos de usuarios. Esta entrega llega menos de tres meses después de la anterior.

La distribución continúa apostando por ofrecer varias ediciones adaptadas a diferentes necesidades, desde escritorios completos y visualmente modernos hasta opciones minimalistas para equipos modestos. Con este nuevo lanzamiento, SparkyLinux actualiza componentes importantes del sistema y mejora la integración de sus principales sabores oficiales basados en Plasma, LXQt, Xfce y MATE.

SparkyLinux 8.3 actualiza Plasma, LXQt, Xfce y MATE sobre Debian 12

Uno de los cambios más importantes de SparkyLinux 8.3 es la actualización de sus principales entornos de escritorio. La edición Plasma incorpora KDE Plasma 5.27, mientras que LXQt, Xfce y MATE también reciben versiones más recientes junto a mejoras de estabilidad y rendimiento.

La distribución sigue basada en Debian 12 “Bookworm”, utilizando paquetes actualizados desde los repositorios estables y de seguridad de Debian. Gracias a ello, SparkyLinux mantiene uno de sus principales objetivos: combinar estabilidad a largo plazo con software relativamente moderno.

Además de los cambios visuales, SparkyLinux 8.3 incluye un kernel Linux actualizado, nuevas versiones de aplicaciones preinstaladas y mejoras internas en el instalador y las herramientas propias del proyecto. Todo ello busca facilitar tanto nuevas instalaciones como actualizaciones desde versiones anteriores.

Otro aspecto destacado es que SparkyLinux continúa ofreciendo ediciones especializadas como MinimalGUI y MinimalCLI, pensadas para usuarios que prefieren construir su sistema desde una base ligera o utilizar hardware con recursos limitados. La distribución mantiene así uno de sus puntos fuertes frente a otras alternativas más pesadas dentro del ecosistema Linux.

La actualización también mejora la compatibilidad general del sistema y corrige errores detectados en versiones anteriores. Como es habitual en este tipo de lanzamientos de mantenimiento, buena parte del trabajo se centra en pulir la experiencia diaria y asegurar una mayor estabilidad general.

SparkyLinux sigue consolidándose como una de las distribuciones derivadas de Debian más versátiles para usuarios que buscan equilibrio entre rendimiento, ligereza y facilidad de uso, especialmente en equipos donde otras opciones más exigentes pueden resultar demasiado pesadas.

from Linux Adictos https://ift.tt/TeROrkd
via IFTTT

SteamOS 3.7.24 ya está disponible junto a una nueva actualización estable del cliente de Steam, incorporando múltiples correcciones relacionadas con Steam Controller, mejoras de estabilidad y diversos ajustes para Steam Deck y equipos compatibles con SteamOS.

Valve continúa refinando su ecosistema Linux con una actualización centrada especialmente en la experiencia de juego portátil y el soporte de periféricos. Aunque no se trata de una gran actualización repleta de funciones inéditas, sí introduce cambios importantes que solucionan problemas reportados por usuarios y mejoran la integración del nuevo Steam Controller en el sistema.

SteamOS 3.7.24 corrige errores y mejora la compatibilidad con Steam Controller

Uno de los puntos más destacados de SteamOS 3.7.24 y el nuevo cliente de Steam es la mejora del soporte para Steam Controller. La nueva versión añade notificaciones cuando un mando se conecta o desconecta, además de nuevas opciones para controlar los avisos relacionados con la batería del dispositivo. También se han realizado cambios en la interfaz de emparejamiento y configuración de mandos para facilitar su uso.

Valve también ha solucionado diversos problemas relacionados con la configuración del nuevo Steam Controller, incluyendo errores que impedían guardar correctamente ciertos perfiles o incidencias con el trackpad izquierdo en modo inalámbrico. Algunos de estos fallos habían sido muy comentados por la comunidad tras el lanzamiento reciente del mando.

La actualización estable del cliente de Steam incorpora además mejoras para Big Picture Mode, reorganizando algunas opciones del menú de energía para evitar suspensiones accidentales del sistema. También se han corregido pequeños fallos visuales relacionados con iconos y elementos de interfaz.

En sistemas macOS, Valve afirma haber optimizado el rendimiento del overlay de Steam en juegos que utilizan Metal, mientras que SteamVR recibe una corrección para evitar problemas de reconexión en sesiones de Steam Link VR.

Por otro lado, SteamOS sigue avanzando en paralelo hacia futuras versiones más ambiciosas. Durante las últimas semanas Valve también ha estado preparando SteamOS 3.8 con mejoras para Steam Machine, nuevos controladores y optimizaciones de rendimiento orientadas tanto a Steam Deck como a otros dispositivos compatibles.

Aunque SteamOS 3.7.24 es principalmente una actualización correctiva, demuestra que Valve continúa manteniendo un ritmo constante de mejoras para su ecosistema Linux y sus dispositivos gaming portátiles. La compañía parece especialmente centrada en pulir la experiencia del nuevo Steam Controller antes de ampliar todavía más el soporte de SteamOS fuera de Steam Deck.

from Linux Adictos https://ift.tt/pLbaB6N
via IFTTT