Member
Victorhck#openSUSE Tumbleweed revisión de la semana 36 de 2026
Tumbleweed es una distribución de GNU/Linux «Rolling Release» o de actualización contínua. Aquí puedes estar al tanto de las últimas novedades.
openSUSE Tumbleweed es la versión «rolling release» o de actualización continua de la distribución de GNU/Linux openSUSE.
Hagamos un repaso a las novedades que han llegado hasta los repositorios esta semana.
Y recuerda que puedes estar al tanto de las nuevas publicaciones de snapshots en esta web:
El anuncio original lo puedes leer en el blog de Dominique Leuenberger, publicado bajo licencia CC-by-sa, en este este enlace:
Esta semana se han publicado 6 Snapshots (0827, 0828, 0829, 0830, 0901, y 0902)
Estas son las actualizaciones en más detalle de esta semana:
- chrony 4.9
- emacs 31.1
- flatpak 1.18.2
- glibc 2.44
- harfbuzz 14.4.0
- icewm 4.1.0
- libjpeg-turbo 3.2.0
- Linux Kernel 7.2.2
- llvm23 23.1.0
- nautilus 50.3
- pcre2 10.48
- python-numpy 2.5.2
- qemu 11.1.0
- rust 1.98
- wpa_supplicant 2.12
- xwaylandvideobridge 0.5.2
Y para próximas snapshots, ya se están preparando las siguientes actualizaciones:
- Linux Kernel 7.2.3
- Mesa 26.2.2
- LibreOffice 26.8.0/RC3
- fontconfig 2.18.3
- Swig 4.5.0
- libnettle 4.0.0
Si quieres estar a la última con software actualizado y probado utiliza openSUSE Tumbleweed la opción rolling release de la distribución de GNU/Linux openSUSE.
Mantente actualizado y ya sabes: Have a lot of fun!!
Enlaces de interés
- ¿Por qué deberías utilizar openSUSE Tumbleweed?
- zypper dup en Tumbleweed hace todo el trabajo al actualizar
- ¿Cual es el mejor comando para actualizar Tumbleweed?
- ¿Qué es el test openQA?
- http://download.opensuse.org/tumbleweed/iso/
- https://es.opensuse.org/Portal:Tumbleweed
——————————–
Tumbleweed – Review of the week 2026/36
Dear Tumbleweed users and hackers,
This week saw the release of 6 snapshots (0827, 0828, 0829, 0830, 0901, and 0902).
It was an exceptionally productive week of updates, headlined by major transitions in our core toolchains. The base system has been elevated with the arrival of glibc 2.44, which brings foundational performance and security enhancements, including standard C23 library features, Intel/AMD shadow stack support, and optimized memory routines. Close on its heels came the system default transitions to Rust 1.98 and LLVM 23.1.0, giving developers access to the latest compiler features and optimizations.
On the core system front, the stable update of Linux Kernel 7.2.2 was delivered to maintain top-tier hardware compatibility. Virtualization hosts received a major update to QEMU 11.1.0, introducing substantial emulation improvements. Wireless network security was bolstered with the release of wpa_supplicant 2.12, and scientific workflows were updated with python-numpy 2.5.2. Finally, on the desktop side, we saw upgrades to pcre2 10.48 and xwaylandvideobridge 0.5.2.
These 6 snapshots delivered the following updates:
- chrony 4.9
- emacs 31.1
- flatpak 1.18.2
- glibc 2.44
- harfbuzz 14.4.0
- icewm 4.1.0
- libjpeg-turbo 3.2.0
- Linux Kernel 7.2.2
- llvm23 23.1.0
- nautilus 50.3
- pcre2 10.48
- python-numpy 2.5.2
- qemu 11.1.0
- rust 1.98
- wpa_supplicant 2.12
- xwaylandvideobridge 0.5.2
With these significant milestones checked off, it is time to turn our gaze forward to see what is currently brewing in our staging areas:
- Linux Kernel 7.2.3
- Mesa 26.2.2
- LibreOffice 26.8.0/RC3
- fontconfig 2.18.3: Currently held up as it breaks the AppStream test suite.
- Swig 4.5.0: Received a few fixes, but some YaST-related integration issues remain to be addressed.
- libnettle 4.0.0: Currently excluded from main staging runs while developers work on resolving test suite breakages in libzypp.
Best Linux Distros for New Laptops in 2026
Planet News Roundup
This is a roundup of articles from the openSUSE community listed on planet.opensuse.org. This community blog feed aggregator lists the featured highlights below from August 28 to Sept. 3.
This week highlights the SUSE security review that uncovers a local root exploits and a Polkit bypass in the LACT GPU tool, an update on expanding Intel AI stack with NPU and OpenVINO support, a translation of the U.S. government placing a label on an Italian collective for offering digital infrastructure to groups of activists, the August Tumbleweed monthly update and week 2026/35 review, and a wave of KDE Gear 26.08 application features alongside the monthly KDE Linux progress report.
Here is a summary and links for each post:
MultiCortex AI Intel Accelerated: CPU, GPU, and Intel NPU ready for Artificial Intelligence
Alessandro presents an Intel-accelerated Linux platform that bundles oneAPI, Level Zero, OpenVINO, Intel Arc and NPU drivers into a ready-to-use AI environment. The post details how a signed-integer overflow in the NPU driver’s ResourceCleaner thread triggered SIGABRT crashes, and how the fix submitted upstream via Pull Request #142 restored NPU availability for OpenVINO applications.
GSoC 2026, Event-Driven Automation for Uyuni via MQTT and Node-RED
The openSUSE News blog shares a Google Summer of Code student’s account of adding an MQTT publisher to Uyuni’s Java core so server events can push out in real time. On the consumer side, a custom set of Node-RED nodes lets users wire together workflows like “a minion registers, apply this state, then post to Slack” without touching the API, and the post reflects on lessons learned about transaction boundaries and deployment debugging.
This Month in KDE Linux: August 2026
The KDE Blog summarizes a monthly progress report on KDE Linux, the community’s upcoming distribution. Highlights include automatic Btrfs snapshots with a new kio-snapshot feature in Dolphin for restoring file versions, preinstalled CJKV text input, default Docker socket access removal for the wheel group, and several boot and installer refinements.
Defend the Autistici/Inventati Collective and the Right to Build Resilient Communication
Victorhck blogs about the U.S. Treasury designating the Italian digital-infrastructure collective Autistici/Inventati as Specially Designated Global Terrorists. The post translates parts of the collective’s open letter and raises concerns about treating privacy-preserving hosting infrastructure as “material support” for terrorism.
What’s New in Konsole of KDE Gear 26.08, the “Enjoy Shiny Stuff” Edition
The KDE Blog covers the Konsole improvements in KDE Gear 26.08. The terminal now supports holding Alt and dragging underlined filenames, and can also drag links, email addresses and color terms to other applications, opening pages, downloading HTML or filling layers in Krita.
Using syslog-ng with Elasticsearch 9.5
Peter Czanik writes about installing Elasticsearch 9.5 with Kibana to verify claims that using Elasticsearch has become more difficult, testing how syslog-ng works with it. The post runs through the setup and configuration needed to make the combination work smoothly.
Tumbleweed Monthly Update - August 2026
The openSUSE News blog recaps an August that delivered 23 Tumbleweed snapshots across 31 days. The month brought KDE Plasma 6.7.4, KDE Frameworks 6.29.0 and KDE Gear 26.08.0, plus GNOME Shell 50.4, Firefox 154.0 with over 40 security fixes, the Linux kernel 7.2.0, and a steady stream of CVE-driven updates.
Reverse Dependencies as a zypper Plugin
Zoltán revisits his rdepends hackweek tool now that zypper natively gained reverse-dependency support via the –requires-pkg flag. He explains how the built-in feature changed the project and what the updated plugin approach looks like today.
Mobile Linux Hackday #8: Record Turnout in SUSE’s New Prague Office
The openSUSE News blog recounts a record-attendance Mobile Linux Hackday #8 held in SUSE’s renovated Prague office. Attendees split into freeform working groups on AI tools, BengalOS and Qualcomm Snapdragon 845 kernel hacking, and shared feedback on how the Czech Linux community discovers such events.
100,000 Computers with Linux: The Miracle No Big Tech Could Stop - Episode 4 of the “The Age of the Dystres” Podcast
The KDE Blog promotes Episode 4 of the “The Age of the Dystres” podcast, which tells the story of the Spanish regional GNU/Linux distribution. The episode focuses on the technical side, covering the engineering, hardware challenges and teaching passion behind the project with several key contributors.
Translation of the Richard Stallman Interview at FOSS Force
Victorhck offers a Spanish translation of Christine Hall’s August 30 email interview with Richard Stallman published on FOSS Force. The interview covers GNU, the open-source split, large language models, SaaSS and digital surveillance, and argues that software freedom remains a moral question.
Vertical Clock for Your Desktop - Plasmoids for Plasma 6 (39)
The KDE Blog presents Vertical Clock. Created by cyberbessa, the widget handles narrow vertical panels well, offering eight visual styles, automatic scaling, and calendar integration, all built using only public API so it survives Plasma updates.
openSUSE Expands AI Support with Intel NPU Driver 1.35.0 and OpenVINO 2026.3.1
The openSUSE News blog reports that Intel NPU Driver 1.35.0 and OpenVINO 2026.3.1 are now packaged for Tumbleweed, Leap 16.0, and Leap 16.1. Testing uncovered a bug that prevented the NPU from initializing on some systems, which was fixed and submitted upstream to the Intel NPU driver project.
LACT: Polkit Authentication Bypass and Temporary File Handling Issues
The SUSE Security blog publishes a review of the LACT GPU control daemon that found a Polkit authentication bypass and a predictable temporary file issue. A PID-race flaw (CVE-2026-75037) could allow local root escalation via profile hooks, while a predictable tarball path (CVE-2026-75038) enabled denial of service and information leaks, with both fixed in upstream.
What’s New in Dolphin of KDE Gear 26.08, the “Enjoy Shiny Stuff” Edition
The KDE Blog rounds up the Dolphin improvements in KDE Gear 26.08. The file manager adds better KDE Connect integration, a filter bar supporting plain text, globbing and regular expressions, independent grouping and sorting, and the ability to close tabs on either side with a right-click.
Binary Function Coverage Part 2: Scaling Up, Fixing Daemons, and Asking the Kernel
Zoltán continues his series on binary function coverage with funkoverage eBPF tracing. He explains how daemons like sshd, cups and postgresql could not be wrapped until the shim was fixed to forward SIGTERM and relay sd_notify so systemd’s service lifecycle worked correctly.
Linux Saloon 217 | Application Potluck
Linux Saloon posts a roundup of technology and Linux updates, including a live weekend discussion about Fedora experiences and Linux security roles at Epic Games. It also covers IBM’s chip architecture advances and Dell overtaking HP in U.S. PC sales amid a shrinking market.
QtWidgets Applications Join Union - This Week in Plasma
The KDE Blog translates a weekly report on the work shaping Plasma 6.8. It highlights the first support for styling QtWidgets apps in the new Union theming system, plus a long list of interface, performance and bug-fix improvements across Plasma 6.6.7, 6.7.5 and 6.8.
My Plasma Desktop for August 2026
The KDE Blog shares the 75th installment of his monthly Plasma desktop showcase. Running on a Slimbook Evo with KDE Neon and Plasma 6.7.4 on Wayland, the post celebrates the huge variety of ways users organize their workspaces.
Tumbleweed - Review of the Week 2026/35
Dominique Leuenberger and Victorhck details Tumbleweed’s week 2026/35 with its five snapshots. Qt 6.11.2, KDE Gear 26.08.0, Linux Kernel 7.2.0 with Cache-Aware Scheduling and Firefox 154.0 were the headline deliveries, while Rust 1.98, Kernel 7.2.2, LLVM 23.1.0 and glibc 2.44 continue through the staging projects.
View more blogs or learn to publish your own on planet.opensuse.org.
Rediseño completo de KDE Connect para Android
En ocasiones una gran aplicación no destaca por ser visualmente atractiva y/o funcional. En mi opinión, esto le pasa a KDE Connect, cuya utilidad está fuera de toda duda pero su aspecto gráfico no es puntero. Afortunadamente los desarrolladores de KDE no están dispuestos a que esta situación perdure en el tiempo y se han puesto manos a las obras con el rediseño completo de KDE Connect para Android, como se puede leer en el artículo publicado en el blog de tintotin.
Rediseño completo de KDE Connect para Android
KDE Connect es una gran aplicación, pero necesita algo de cariño en su aspecto gráfico, algo que se ha dispuesto solucionar Tintotin, el cual ha emprendido la renovación completa de su interfaz y, según sus propias palabras, posiblemente la reescritura de aproximadamente la mitad de la arquitectura para adaptarla a la nueva UI. El código y una versión publicada están disponibles en GitHub para que la comunidad los pruebe.
No obstante, como toda gran revolución, es posible que al tratarse de un cambio de gran alcance, pueden existir regresiones y casos límite aún pendientes, especialmente en la lógica de emparejamiento.
El nuevo aspecto se concreta a muchos niveles, así que vamos a ir desglosándolo poco a poco.
Pantalla principal y dispositivos
La antigua barra lateral deja de ser el menú principal y se sustituye por una pantalla de inicio más convencional. Esta incorpora tarjetas que actúan como accesos directos a los plugins más utilizados y que pueden mostrar información contextual, como el nivel de batería del dispositivo y los métodos de conexión utilizados, incluidos Wi‑Fi y Bluetooth.
Para reducir la sobrecarga visual, los dispositivos no emparejados y los que están fuera de alcance se han trasladado a pantallas diferenciadas, en vez de aparecer junto a los dispositivos disponibles en la vista principal.
Emparejamiento y permisos
El proceso de emparejamiento cuenta con una nueva interfaz superpuesta u overlay. Su objetivo es evitar que el usuario dependa de notificaciones poco visibles para aceptar una solicitud y permitir el emparejamiento incluso cuando no se está usando directamente KDE Connect.
También se ha modificado la gestión de permisos. En lugar de mostrar desde el comienzo una lista grande de plugins que requieren permisos potencialmente sensibles, la aplicación solicita el permiso necesario cuando el usuario intenta utilizar una función concreta. Estas solicitudes pueden aparecer como una superposición encima de otras aplicaciones. El autor relaciona este cambio con el aumento de permisos necesarios para que la aplicación pueda funcionar con Android 17.
Ajustes y plugins
La configuración general de la aplicación se ha separado de la configuración propia de cada dispositivo, con el fin de hacer más clara esa distinción.
El plugin de control multimedia agrupa en una sola pantalla las dos pestañas previas. Los controles de reproducción, la gestión de entradas y salidas de audio y sus ajustes de volumen quedan accesibles desde esa vista, mediante controles y ventanas emergentes específicas.
El mando remoto adopta una disposición inspirada en un control remoto físico, con botones relevantes destacados mediante color. El panel de entrada remota utiliza una apariencia de panel táctil, integra el envío de texto dentro de la misma pantalla y ajusta su tamaño automáticamente para que el teclado virtual no oculte la interfaz.
El control de presentaciones recibe cambios más limitados: los botones importantes pasan a ser más grandes y visibles.
Desarrollo y pruebas
El autor indica que el trabajo le ha llevado casi dos meses y que utilizó modelos de lenguaje para ayudarle con tareas repetitivas de refactorización. Invita a probar la aplicación, informar de errores o regresiones mediante incidencias en GitHub y comunicar también posibles problemas de diseño.
¿Qué os parece? ¿Os gusta como va quedando? Proponed vuestras ideas para que tengamos, entre todos, un KDE Connect fabuloso.
La entrada Rediseño completo de KDE Connect para Android se publicó primero en KDE Blog.
Tiny Wins for Packagers: End-of-Week Update (2026-09-04)
MultiCortex AI Intel Accelerated: CPU, GPU e NPU Intel pronta para a Inteligência Artificial
Sistema operacional Linux integra Intel oneAPI, Level Zero, OpenVINO, Intel Arc e NPU para reduzir a complexidade da computação heterogênea e acelerar o desenvolvimento de aplicações de IA
A Inteligência Artificial está chegando cada vez mais perto do usuário. O que durante muitos anos esteve concentrado em grandes datacenters equipados com aceleradores especializados começa agora a fazer parte dos notebooks, desktops, estações de trabalho e dispositivos de borda. As novas gerações de hardware Intel são um exemplo claro dessa transformação.
Em uma mesma máquina podemos encontrar CPU, GPU Intel Arc e NPU, três arquiteturas com características diferentes e que podem ser exploradas conjuntamente em aplicações de Inteligência Artificial. O desafio, porém, não está apenas em possuir esse hardware.
É necessário fazer
tudo funcionar.
Drivers, firmware, runtimes, bibliotecas, compiladores, frameworks e diferentes camadas de acesso ao hardware precisam estar corretamente instalados, configurados e compatíveis. Foi justamente para atacar esse problema que nasceu o MultiCortex AI Intel Accelerated.
A proposta é simples: entregar um ambiente Linux no qual a infraestrutura necessária para explorar a computação heterogênea Intel já esteja disponível desde o primeiro boot. A própria plataforma apresenta CPU, Intel Arc GPU e Intel NPU como recursos complementares para processamento geral, inferência e IA eficiente.
O problema não é apenas instalar um framework
Uma das etapas mais complexas e custosas na adoção de Inteligência Artificial é a instalação, configuração e integração dos aceleradores com os frameworks utilizados pelos desenvolvedores.
Mesmo em ecossistemas extremamente populares, como NVIDIA e CUDA, preparar corretamente uma máquina para desenvolvimento de IA pode exigir conhecimento especializado. No ecossistema Intel existe um desafio adicional.
Tecnologias como Intel NPU, Intel Arc, oneAPI, Level Zero e OpenVINO ainda são menos conhecidas por uma parcela significativa dos desenvolvedores quando comparadas às stacks tradicionais de GPU.
E possuir uma NPU dentro do processador não significa automaticamente conseguir utilizá-la. Entre a aplicação e o silício existem várias camadas. De forma simplificada:
Uma falha em qualquer uma dessas camadas pode fazer com que um acelerador fisicamente presente na máquina simplesmente desapareça para a aplicação.
Foi exatamente um problema desse tipo que encontrei durante o trabalho realizado com a Intel NPU.
Quando o hardware existe, mas a aplicação não consegue utilizá-lo
Durante os testes do linux-npu-driver 1.35.0, percebi uma situação particularmente preocupante. O hardware estava presente. O firmware estava carregado. O driver de kernel estava funcionando.
Mesmo assim, o OpenVINO não conseguia disponibilizar a NPU.
Em determinados cenários, o problema era ainda mais grave: processos que dependiam da inicialização da NPU terminavam completamente com um SIGABRT.
Ou seja, não era simplesmente uma redução de desempenho ou a execução automática da carga na CPU. O processo poderia literalmente sofrer um crash durante a inicialização do Level Zero. A investigação levou a uma thread interna do driver chamada ResourceCleaner.
O código utilizava:
std::chrono::steady_clock::time_point::max()
como deadline para:
std::condition_variable::wait_until()
A intenção era representar uma espera infinita.
O problema é que determinadas implementações da libstdc++ realizam internamente conversões entre relógios ao processar o deadline recebido por wait_until(). Como time_point::max() já está próximo do maior valor suportado pelo inteiro utilizado internamente para representar o tempo, a operação de conversão poderia provocar um signed integer overflow. Em ambientes onde esse overflow era detectado pelo runtime do GCC, a execução chegava ao helper __addvdi3, que executava um abort().
O resultado final era um: SIGABRT
e o encerramento completo do processo.
Corrigindo o driver da NPU
A solução foi mudar a lógica utilizada pelo ResourceCleaner. Uma espera realmente infinita não precisa ser representada artificialmente por uma data extremamente distante. Quando nenhum timeout está configurado, a solução adequada é utilizar simplesmente:
cv.wait(lock);
Quando existe efetivamente um prazo para a operação de limpeza, permanece:
cv.wait_until(lock, timeout);
A correção também passou a proteger as atualizações da variável idleTimeout utilizando o mutex já existente no mecanismo de limpeza, evitando acesso concorrente entre setIdleTimeout() e a thread executada em background.
A alteração foi desenvolvida e submetida como contribuição upstream diretamente ao repositório oficial intel/linux-npu-driver, no Pull Request #142.
Essa contribuição representa algo importante para o projeto MultiCortex. Não estamos simplesmente instalando pacotes desenvolvidos por terceiros dentro de uma imagem Linux.
Estamos trabalhando, testando e entendendo a stack em profundidade suficiente para chegar até a camada que controla o acelerador e contribuir com sua correção.
É também mais uma contribuição Open Source brasileira chegando à infraestrutura utilizada para Inteligência Artificial.
De cinco falhas para seis testes concluídos
O problema foi reproduzido utilizando o linux-npu-driver 1.35.0 em uma Intel NPU40xx.
O teste utilizado foi:
npu-umd-test --ze-init-test -c none
Antes da alteração, apenas 1 dos 6 testes era concluído corretamente. Os outros cinco processos falhavam com:
status: 134
correspondente ao SIGABRT.
Após a aplicação da correção:
[ PASSED ] 6 tests.
Todos os seis testes foram concluídos.
Mais importante do que o teste isolado foi verificar o comportamento da stack completa.
Com Python e OpenVINO:
import openvino as ovcore = ov.Core()print(core.available_devices)
o resultado passou a ser:
['CPU', 'NPU']
confirmando que a NPU estava novamente disponível para aplicações de Inteligência Artificial.
Esse caso ilustra exatamente por que simplesmente entregar uma lista de pacotes instalados não é suficiente para construir uma plataforma de IA.
A stack precisa ser testada do hardware até a aplicação.
É nesse ponto que entra o MultiCortex AI Intel Accelerated
O MultiCortex AI Intel Accelerated foi desenvolvido para reduzir justamente essa distância entre possuir um computador com aceleradores Intel e efetivamente conseguir utilizá-los para desenvolver Inteligência Artificial.
A imagem Linux reúne uma stack previamente preparada com componentes como:
- Intel oneAPI, como ecossistema de desenvolvimento;
- Level Zero, fornecendo acesso de baixo nível aos dispositivos;
- OpenVINO, para inferência e otimização de modelos;
- drivers e runtime para Intel Arc GPU;
- driver e runtime para Intel NPU;
- suporte à utilização da CPU como parte da mesma arquitetura heterogênea.
Esses componentes já fazem parte da proposta apresentada pela plataforma MultiCortex, reduzindo as etapas necessárias antes que um desenvolvedor consiga efetivamente executar seu primeiro workload.
Em vez de começar o projeto procurando documentação, adicionando repositórios, resolvendo dependências, compilando componentes e diagnosticando incompatibilidades entre drivers e runtimes, o desenvolvedor pode começar pelo que realmente importa:
a aplicação de Inteligência Artificial.
CPU + GPU + NPU
Um dos conceitos centrais do MultiCortex AI Intel Accelerated é a computação heterogênea.
Nem toda carga deve necessariamente ser executada no acelerador mais poderoso.
Cada dispositivo possui características diferentes.
A CPU continua sendo extremamente importante para controle da aplicação, pré e pós-processamento, modelos e operações gerais.
A GPU Intel Arc oferece grande paralelismo e capacidade computacional para cargas intensivas.
A NPU adiciona um acelerador especializado para redes neurais, criado principalmente para executar cargas de IA com grande eficiência energética.
Com ferramentas como o OpenVINO, uma aplicação pode selecionar dispositivos diferentes ou construir pipelines capazes de aproveitar essa diversidade de recursos.
Isso transforma o computador moderno em algo diferente do modelo tradicional em que praticamente todo o processamento era concentrado na CPU.
Passamos a ter diversos motores computacionais disponíveis dentro de uma mesma máquina.
CPU + GPU + NPU.
E o MultiCortex AI Intel Accelerated foi construído justamente para tornar essa computação heterogênea visível, utilizável e mensurável. A demonstração pública da plataforma mostra CPU, NPU e Intel Arc GPU sendo utilizadas simultaneamente.
OpenVINO como ponto de integração
Uma das tecnologias centrais dessa estratégia é o OpenVINO.
O OpenVINO permite desenvolver e executar aplicações de inferência em diferentes dispositivos, criando uma camada de abstração entre os modelos de Inteligência Artificial e os aceleradores disponíveis.
A geração OpenVINO 2026 ampliou ainda mais essa estratégia.
A documentação oficial da versão 2026.3 apresenta suporte a novos modelos executando em CPU, GPU e NPU, além da expansão de modelos como YOLO26 para GPU e NPU e novas integrações para aplicações de IA generativa.
O MultiCortex AI Intel Accelerated utiliza essa capacidade como uma das bases para permitir que desenvolvedores experimentem inferência, visão computacional, processamento de linguagem natural, modelos generativos e outros workloads aproveitando o hardware disponível localmente.
IA na borda
Existe ainda uma consequência importante dessa evolução.
Quanto mais capacidade computacional existe localmente, menos determinadas aplicações precisam depender exclusivamente do datacenter.
Processamento de imagens, reconhecimento de voz, biometria, análise de dados, modelos de linguagem e diferentes mecanismos de predição podem começar a ser executados diretamente no equipamento do usuário.
Isso traz vantagens importantes para aplicações que exigem:
baixa latência, privacidade, funcionamento offline, eficiência energética e soberania sobre os dados.
A NPU tem um papel particularmente interessante nesse cenário.
Ela é um recurso que já está fisicamente presente em uma nova geração de computadores, mas que ainda permanece subutilizado por muitas aplicações.
O desafio agora é permitir que mais desenvolvedores aprendam a utilizá-la.
Reduzindo a barreira de entrada
É exatamente aí que considero estar a principal contribuição do MultiCortex AI Intel Accelerated.
O objetivo não é simplesmente criar mais uma distribuição Linux.
É criar uma plataforma de experimentação e desenvolvimento capaz de reduzir uma das maiores barreiras da computação heterogênea:
a preparação do ambiente.
Um desenvolvedor que deseja estudar Intel NPU não deveria precisar passar dias tentando entender por que o dispositivo não aparece no framework.
Uma empresa que deseja validar um caso de uso com Intel Arc não deveria começar seu projeto de IA diagnosticando versões incompatíveis de drivers.
Uma equipe de inovação interessada em CPU + GPU + NPU deveria poder começar experimentando sua arquitetura, e não montando toda a infraestrutura necessária para chegar até ela.
Por isso, o conceito do MultiCortex AI Intel Accelerated pode ser resumido em uma frase:
Do hardware Intel à aplicação de IA, sem perder tempo preparando o ambiente.
Mais do que consumir tecnologia
Minha experiência trabalhando com OpenVINO e com o driver Intel NPU também reforçou uma convicção que tenho há muitos anos dentro do Open Source.
Não devemos ser apenas consumidores de tecnologia.
Precisamos aprender como ela funciona.
Precisamos empacotar.
Testar.
Encontrar problemas.
Investigar.
Corrigir.
E, sempre que possível, devolver essas melhorias para o projeto original.
A correção desenvolvida para o ResourceCleaner do Intel Linux NPU Driver é um exemplo concreto dessa filosofia.
E o conhecimento adquirido nesse processo retorna diretamente para o desenvolvimento do MultiCortex AI Intel Accelerated.
Isso significa que a plataforma não nasce apenas da integração de componentes.
Ela nasce da experiência prática de fazer CPU, GPU, NPU, Level Zero, oneAPI, drivers e OpenVINO funcionarem juntos em um ambiente Linux real.
O computador já possui um acelerador de IA. Precisamos começar a utilizá-lo.
Estamos entrando em uma nova fase da computação pessoal.
A Inteligência Artificial não estará apenas na nuvem.
Ela estará no próprio equipamento.
CPU, GPU e NPU formarão uma plataforma heterogênea capaz de executar uma parte cada vez maior dos workloads de Inteligência Artificial localmente.
O hardware está chegando.
Agora precisamos entregar aos desenvolvedores as ferramentas para utilizá-lo.
Esse é o propósito do MultiCortex AI Intel Accelerated:
transformar o hardware Intel disponível no computador em uma plataforma Linux completa, integrada e pronta para desenvolvimento e execução de Inteligência Artificial desde o primeiro boot.
GSoC 2026, Event-Driven Automation for Uyuni via MQTT and Node-RED
Hello, openSUSE community!
My name is Geetansh Goyal, and I was a Google Summer of Code (GSoC) 2026 mentee with Uyuni and the openSUSE project. This is my first year contributing to a project of this size, and this post is my account of the summer working on “Event-Driven Automation for Uyuni via MQTT and Node-RED,” mentored by Ondrej Holecek and Abid Mehmood, both from the openSUSE community.
The problem
Uyuni already knows the moment something interesting happens: a system registers, a Salt job returns, a state applies, a software channel finishes building. None of that left the server. If you wanted to react to it, your only option was polling the XML-RPC API on a timer, which means either hammering the API for low latency or accepting a delay you didn’t choose. The goal of the project was to let events push out instead, so external tools can react as they happen.
What I built
The project has two halves. On the Uyuni side, I added an MQTT publisher to the Java core that publishes nine event types, five from the Salt reactor (system registration, job returns, state application, image deployment and batch starts) and four from domain code (org creation, user creation, and content lifecycle management builds starting and completing). Everything is off by default behind a set of configuration properties, so an existing installation notices nothing until an administrator explicitly turns it on.
On the consumer side, I built node-red-contrib-uyuni, a package of custom Node-RED nodes: one to subscribe to Uyuni events, one to call back into the API to apply a state or schedule a reboot, one to query system data, and two config nodes to hold credentials. The idea is that someone who has never touched Uyuni’s API can still wire together “a minion registers, then apply this state, then post to Slack” entirely by dragging nodes onto a canvas.
To make the whole thing easy to try, I also put together container images for a preconfigured Mosquitto broker and for Node-RED with the Uyuni nodes pre-installed, and a small library of example flows: a Slack alert on patch application, automatic Jira ticket creation, email notifications, and a couple more.
What I learned
I came into this as a first-year student who had never worked in a codebase anywhere near this size, and for the first few weeks I mostly felt like I was guessing. Uyuni’s Java core has years of history in it, and just finding where an event should be published, let alone where it safely could be, took longer than I want to admit.
The moment that actually changed how I think about code happened in review. Abid pointed out that my events were sometimes going out before the database transaction that produced them had even committed, meaning a subscriber could hear about something that, a moment later, technically hadn’t happened. I patched it the way I imagine a lot of people patch their first real bug: I found the closest thing that looked like “after commit” and hooked into that. It didn’t work, because I was deferring to the wrong transaction entirely, one that was never doing the actual write. Getting the real fix, which turned out to be as simple as changing the order a handler gets registered in, meant sitting with ActionExecutor until I actually understood what “each handler runs in its own transaction” meant for the code I’d written, instead of poking at it until the symptom went away. That’s the lesson I’ll carry past this project: a fix you don’t understand is just a different bug wearing the first one’s clothes.
The rest of what I learned came from being embarrassingly wrong in front of a real server. I’d copy a file into a running container, restart it to test, and watch my change vanish, because I didn’t yet know that a jar in there was a symlink and ant deploy was quietly doing nothing. I’d get a working config, restart the service to confirm it, and lose everything, because a line I hadn’t noticed in the systemd unit was wiping the container clean on every restart. I found a password sitting in a log file in plain text and realized I’d put it there myself, as a JVM argument, which is exactly why every credential in this project now also accepts an environment variable. None of that was in a diff anywhere. I only found it by breaking my own deployment enough times that I stopped trusting anything I hadn’t watched work end to end, which is how I ended up actually measuring it: about 0.112 seconds from a Salt job finishing to a subscriber hearing about it, checked with my own eyes on a real machine, not assumed.
Where the project stands
The implementation PR and the RFC are both open and under review as I write this, and the Administration Guide documentation is up for review too. Of the stretch goals, the example flow library is done, MQTT over TLS and a Grafana annotation node are still open for whoever picks this up next, including possibly me.
Thanks
Thank you to Ondrej and Abid for the review that actually made me fix the ordering bug properly instead of papering over it, and to openSUSE and GSoC for the chance to spend a summer inside a codebase this size as a first-year student. It was the first time I had to reason about transaction boundaries in someone else’s production system, and I’d do it again.
Este mes de agosto en KDE Linux
Hoy os traigo otro resumen del progreso en KDE Linux, un informe detallado de la última entrada de Nate Graham esta vez aparecido directamente en el Planet KDE, donde nos pone al día sobre los avances de KDE Linux, el sistema operativo «del futuro» de la comunidad KDE. Es decir, que bienvenidos a el progreso de este mes de agosto en KDE Linux, otro paso que nos acerca a un sueño para los simpatizantes de este entorno de trabajo.
Este mes de julio en KDE Linux
El bueno de Nate no solo se encarga de informarnos del progreso de Plasma en sus artículos de «This week in Plasma, sino que en ocasiones nos obsequia con una mirada a otros proyectos de la Comunidad.
Hace unos meses se publicaron artículos como «Busy months in KDE Linux«, «This month in KDE Linux«, «This month in KDE Linux: March 2026», «This month in KDE Linux: May 2026«, «This month in KDE Linux: June 2026» y «This month in KDE Linux: Juy 2026″ en los que Nate nos muestra que el proyecto está vivo y que si no pasa nada en unos meses tendremos entre nosotros la primera versión estable de esta distribución. Por cierto, el título parece haberse estabilizado.
Y el mes de agosto nos volvió a obsequiar con una revisión del proyecto de nuevo con la colaboración de John Veness, que evidentemente os animo a leer completo, que ha titulado «This month in KDE Linux: august 2026» y del cual os ofrezco un resumen del mismo para los que no tenemos un dominio exhaustivo del inglés.
- Instantáneas automáticas de Btrfs: Las carpetas personales ahora son subvolúmenes Btrfs con snapshots automáticos activados.. Está claro que el futuro es ese sistema de archivos.
- kio-snapshot en Dolphin: Nuevo sistema integrado que permite ver y restaurar versiones anteriores de archivos directamente desde el gestor. [Esto mola mucho].
- Entrada de texto CJKV preinstalada (pero que el usuario tiene que activarlo para empezar a usarlo): Soporte nativo para escribir en chino, japonés, coreano y vietnamita sin configuración adicional.blogs.kde
-
Correcciones de seguridad:
- Eliminación del acceso predeterminado al socket de Docker para el grupo
wheel. - Bloqueo de módulos de kernel no autorizados en las imágenes unificadas.
- Eliminación del acceso predeterminado al socket de Docker para el grupo
- Mejoras en actualizaciones: Corrección de fallos en actualizaciones publicadas o en equipos con CPUs lentas o conexiones deficientes.
- Documentación accesible: Enlaces rápidos a la documentación oficial en la sección “Ayuda” del menú, guía para liberar espacio y página de soporte en la web.
- Integración KeePassXC + Flatpak: Documentación sobre uso de KeePassXC con Firefox y Chromium instalados vía Flatpak.
- Barra de progreso del instalador: Mayor precisión para evitar incertidumbre durante la instalación.
- Menú de arranque simplificado: Eliminada la entrada inútil de la consola UEFI.
Como vemos, KDE Linux no es solo una «distro» más; es el campo de pruebas y la vitrina oficial de lo que KDE puede ofrecer cuando controla todo el ecosistema, un sueño que no viene de ahora (ya escuché esto en la Akademy de A Coruña de 2015 y cuyo primer se dio con KDE Neon).
Vemos que el desarrollo de esta Comunidad cuyos objetivos están claros se construye dando pasos pequeños pero seguros.
-
Este mes de agosto en KDE Linux
Bienvenidos a el progreso de este mes de julio en KDE Linux, otro paso que nos acerca a un sueño para los simpatizantes de este entorno de trabajo. -
Este mes de julio en KDE Linux
Bienvenidos a el progreso de este mes de julio en KDE Linux, otro paso que nos acerca a un sueño para los simpatizantes de este entorno de trabajo. -
Este mes de junio en KDE Linux
Hoy os traigo el otro resumen del progreso en KDE Linux, un informe detallado de la última entrada de Nate Graham en su blog «Adventures in Linux and KDE», donde… Leer más: Este mes de junio en KDE Linux
La entrada Este mes de agosto en KDE Linux se publicó primero en KDE Blog.
Defiende al colectivo Autistici/Inventati y el derecho a construir una comunicación resistente
El 26 de agosto de 2026, Estados Unidos designó como terroristas al colectivo italiano que da soporte e infraestructuras digitales (blogs, correo electrónico, etc) a colectivos de activistas desde 2001
El gobierno de EE.UU. una vez más sacándose de la manga una ley para acallar voces disidentes. Un estado terrorista como el de EE.UU. que ha sembrado el miedo y muerte en muchos países y da soporte a otros estados asesinos, retuerce las leyes y los significados en su «neolengua» para que solo se oiga su voz.
Esta vez el brazo ejecutor del nuevo fascismo y nazismo tecnocapitalista ha recaido sobre el colectivo italiano Autistici/Inventati (AI), por ofrecer infraestructura digital a colectivos de activistas.
A/I se presenta como una organización antifascista, antirracista, antisexista y antimilitarista, opuesta al capitalismo y al autoritarismo, y selecciona los proyectos que acoge en función de su compatibilidad con estos principios.
Vayamos a las fuentes de información para saber de qué va este «culebrón». He traducido partes de una carta abierta que ha pueblicado el colectivo, junto con otras fuentes intercalando comentarios propios para seguir el hilo.
El 26 de agosto de 2026, el Departamento del Tesoro de EE.UU., a través de OFAC (Oficina de Control de Activos Extranjeros – la autoridad responsable de gestionar y hacer cumplir sanciones económicas y financieras), sancionó a Autistici/Inventati (A/I), un colectivo italiano que ha estado proporcionando infraestructura digital – correo electrónico, hosting, listas de correo, chat, videoconferencia, streaming y servicios relacionados con la privacidad y el anonimato – a movimientos y activistas.
Washington lo designó como Terrorista Global Especialmente Designado (SDGT), alegando que ha proporcionado apoyo financiero, material o tecnológico al terrorismo y a organizaciones ya sometidas a sanciones. A/I rechaza las acusaciones y declara que sus actividades consisten en proporcionar herramientas para la autodefensa digital e infraestructura para la libertad de comunicación.
Autistici/Inventati (A/I) ha proporcionado servicio de correo electrónico no comerciales, sitios web, listas de correo, Noblogs y otros servicios de comunicación desde 2001. A/I surgió de hacklabs italianos, medios autónomos y movimientos sociales. Su infraestructura fue construida en respuesta a la censura, la vigilancia encubierta y la incautación de servidores. Minimiza los datos identificativos de los movimientos y personas que lo utilizan, utiliza sistemas distribuidos y trata la privacidad como una condición para la participación política más que como un producto.
La infraestructura se gestiona a través de una asociación formalmente reconocida. Esto significa que A/I no es un grupo informal: sus actividades son gestionadas por una asociación que cumple con todas las normativas legales vigentes, con responsabilidades legales, relaciones contractuales y las obligaciones y controles asociados.
Esto no significa que la asociación nunca haya tenido que tratar con el sistema judicial. A lo largo de los años ha habido procedimientos e intervenciones por parte de las autoridades, también a escala internacional.
Entre los episodios recordados por el colectivo se encuentran la intervención de 2004-2005 en los servidores alojados por Aruba, en el contexto de una investigación iniciada por la fiscalía de Bolonia, así como disputas posteriores relacionadas con contenidos o cuentas individuales. En otro caso, tras una demanda de Trenitalia sobre un sitio satírico, el tribunal de Milán falló en defensa de la sátira.
Los anuncios públicos de Estados Unidos apuntan a material y organizaciones que supuestamente usaron infraestructura de A/I.
No demuestran públicamente que A/I planificara las acciones citadas, seleccionara objetivos, dirigiera a los usuarios o redactara material alojado.
Por tanto, la designación plantea una cuestión que va mucho más allá de un colectivo: ¿puede ser tratado como terrorismo mantener una infraestructura de comunicaciones que preserve la privacidad para movimientos desfavorecidos?
Parece claro, que en este renacimiento del nazismo instaurado en los grandes tecnócratas que se codean con el egocéntrico y ególatra presidente de EE.UU. que todo le huele a «rojerío», la respuesta es sí.
Esa teoría amenaza a los hosts independientes, los servicios de comunicaciones cifrados, las bibliotecas, los archivos del movimiento, los editores y pequeños proyectos voluntarios en todas partes.
En este sistema sobre vigilado, querer estar fuera de esa red de seguimiento masivo, es tomado como sospechoso. No querer formar parte de esa red de vigilancia parece que implica que eres culpable.
A/I proporciona infraestructuras digitales, herramientas y servicios a «células Antifa violentas» y otros extremistas de izquierdas. El comunicado cita alojamiento, correo electrónico cifrado, chat y videoconferencia, streaming y la infraestructura asociada a Noblogs. Washington también afirma que la infraestructura estuvo disponible para organizaciones ya sometidas a sanciones, nombrando específicamente al PKK.
Autistici/Inventati no es políticamente neutral; la afinidad política, sin embargo, no es control operativo. Proporcionar una cuenta de correo electrónico, plataforma de publicación o servidor no significa compartir todo lo que un usuario pueda decir o hacer después.
La lógica detrás de esta acusación no es simplemente «A/I llevó a cabo un ataque terrorista». La cuestión es el llamado apoyo material: según Washington, la infraestructura tecnológica constituye un medio para apoyar a individuos o actividades calificadas como terroristas.
A/I rechaza rotundamente la calificación que les ha realizado el gobienro estadounidense. El colectivo se describe a sí mismo como compuesto por voluntarios y activistas digitales, afirmando que simplemente proporciona herramientas digitales de autodefensa para activistas, individuos, grupos y asociaciones.
La designación estadounidense no equivale automáticamente a una prohibición de A/I en Italia o en la Unión Europea. Estados Unidos, la UE y los estados individuales tienen sistemas legales y listas antiterroristas distintas. Sin embargo, la inclusión en la lista OFAC genera una presión significativa sobre los operadores que tratan con la entidad designada.
A nivel técnico cuando un usuario escribe la url autistici.org en su navegador, el ordenador necesita saber a qué dirección IP debe conectarse. El DNS (Sistema de Nombres de Dominio) realiza esta función: traduce un nombre legible por humanos, como autistici.org, a la dirección numérica del servidor.
Si el DNS deja de devolver la coincidencia correcta, el servidor puede permanecer activo pero el sitio web se vuelve inaccesible para los usuarios de ese dominio. Por tanto, es importante no confundir el acto de «desconectar o suspender el dominio» con la decisión de «apagar el servidor». La primera acción afecta a un nivel diferente de la infraestructura de alojamiento.
Este incidente demuestra que la infraestructura digital puede ser dirigida a diferentes niveles. No es necesario incautar el servidor que contiene datos específicos: se pueden tomar medidas contra el nombre de dominio que permite encontrarlo.
En este sentido, el nombre de dominio se convierte en un punto de control. La cuestión central es, por tanto, es: ¿qué ocurre cuando un colectivo italiano, sus servidores y sus usuarios están formalmente ubicados fuera de la jurisdicción estadounidense pero utilizan un dominio.org gestionado por un registro estadounidense y servicios financieros o tecnológicos vinculados al mercado estadounidense?
Una vez más queda patente la débil soberanía tecnológica en esta y otras cuestiones. Los servidores están fuera de la legislación de EE.UU. pero no el dominio utilizado. ¿Quizás debiera ser .it? ignoro si esa sería una mejor solución.
Y una cuestión clave es, ahora ha sido A/I pero ¿cuando decidirá el próximo gobierno declarar terroristas a otra organización? ¿Dónde ponemos el límite? Apoyar a colectivos antifascistas es terrorismo, apoyar a gobiernos que están llevando a cabo un genocidio en Gaza no. Tampoco es terrorismo la escucha masiva de ciudadanos de tu propio país, ni la invasión de un país ni la intromisión en su sistema político para decantarlo hacia tus propios intereses.
El mismo principio podría, en teoría, aplicarse a los proveedores de correo electrónico, servicios en la nube, proveedores de alojamiento, plataformas de mensajería, sistemas de pago o registradores de dominios. La cuestión es establecer cuándo la prestación de un servicio de propósito general se convierte, según las leyes aplicables, en «apoyo material» a una organización terrorista.
Si has llegado a leer hasta est punto, muchas gracias. A continuación te dejo los enlaces a la información de primera mano de A/I.
Enlaces de interés
- https://www.inventati.org/campaign/defend
- https://www.inventati.org/campaign/
- https://www.inventati.org/services/
