Contributors to openSUSE had a great time at the openSUSE Conference in June. Even as many of them gathered in Nuremberg to discuss how to drive development of the rolling release forward, software package updates for openSUSE Tumbleweed kept rolling out.

June brought major version bumps across the stack with Samba jumping to 4.24.3 carrying seven Common Vulnerabilities and Exposures fixes, MariaDB advancing from 11.8 to 12.3.2, and Flatpak reaching 1.18.0.

KDE Gear 26.04.2 landed as the second bugfix release of the series, and GStreamer progressed to 1.28.4 with security and playback fixes. OpenSSL received a massive security update and both WebKitGTK and the Linux kernel received extensive rounds of vulnerability fixes.

The second half of June was headlined by KDE Plasma 6.7.0 and KDE Frameworks 6.27.0. NetworkManager advanced to 1.56.1 and python-cryptography reached 49.0.0 with post-quantum ML-DSA signing support. FreeRDP 3.27.1 raised the minimum TLS version to 1.2 while addressing multiple CVEs. VirtualBox 7.2.10 added Linux kernel 7.1 support and Wayland clipboard sharing.

As always, be sure to roll back using snapper if any issues arise.

For more details on the change logs for the month, visit the openSUSE Factory mailing list.

New Features and Enhancements

Samba 4.24.3: A major version bump from the 4.23 series brings a major security refresh with several CVE fixes. Notable changes include a fix for unauthenticated remote code execution in the AD DC, SAMR remote code execution, and group policy certificate enrollment without validation.

Flatpak 1.18.0: This major update improves error handling and printed output of flatpak-coredumpctl, adds support for the AMD vendor-specific compute interface (/dev/kfd) via DRI device permissions, and improves startup time for fish shell integration. Ignoring system bus failures in parental controls check and replacing deprecated GTimeVal with g_get_real_time() round out the release.

GPGME 2.1.0: This update introduces new flags is_de_vs and beta_compliance for encryption results, a new decryption flag GPGME_DECRYPT_SESSION_HASH, and support for setting CMS signature attributes via gpgme_sig_notation_add. A new context flag export-filter is also added. Several locking and passphrase handling fixes are included, along with the companion gpgmepp 2.1.0 and qgpgme 2.1.0 updates.

MariaDB 12.3.2: A major version jump from 11.8.8 brings the database server to the 12.3 series. This release carries multiple security fixes alongside a changelog of improvements documented in the upstream release notes.

KDE Gear 26.04.2: Dolphin fixes a dangling pointer access in SettingsDataSource and a swapActiveView crash. Kate corrects working directory handling when invoking git and fixes urlinfo for relative files. Konsole fixes a copy command causing unwanted scroll-to-bottom. Kitinerary adds extractors for BDŽ (Bulgarian State Railways) PDF tickets and Condor PKPass. KOrganizer fixes recurring event start-end time display and Kleopatra now requires GpgME 1.24.2 (at the beginning of the month in Tumbleweed updated to version 2.1.0).

GStreamer 1.28.4: The rtspsrc2 element receives major feature expansion with support for SRTP, authentication, HTTP tunnelling, keep-alive, TLS validation, and latency configuration. Wavpack audio receives channel and channel-mask related fixes. Debug logging performance is improved, and memory leaks across caps allocation, buffer pools, and the GL upload path are resolved. The d3d12decoder gets a fix for Qualcomm GPUs on ARM64 Windows.

GraphicsMagick 1.3.47: DPX subsampling validation is corrected to avoid divide-by-zero. The JNG writer properly handles NULL returns from ImageToBlob(), and the MNG writer enforces a 256-color palette limit. The PS/PS2/PS3 coders enforce dimension limits to prevent Ghostscript-based denial-of-service. SVG gains validations for element id syntax and rejects attribute values with single quotes. The XCF reader reports errors for layerless images and fixes two unsigned integer overflow cases.

fwupd 2.1.4 & 2.1.5: The firmware update daemon received two updates during June. Version 2.1.4 adds support for Compal BIOS version format, NixOS quickstart, encrypted swap detection below device-mapper, and removes the flashrom plugin. Dozens of bounds checks and validation fixes are included across Dell dock, Novatek, Goodix MoC, Synaptics RMI, CCGX DMC, and other device updaters. The 2.1.5 follow-up fixes a msgpack regression for Huddly cameras, adds Elan touchscreen support, and expands the netlink socket buffer to prevent packet loss during event floods.

SDL3 3.4.10: This update adds depth texture array support in the GPU API, GameInput v3 controller sensor support, rumble support for the new Steam Controller, and GameCube rumble support when the adapter is in PC mode. Several new controllers are supported including the GameSir Super Nova and PDP Afterglow Wave Wireless. The X11 Synchronization Extension is disabled by default and can be re-enabled via SDL_HINT_VIDEO_X11_ENABLE_XSYNC_EXT.

Key Package Updates

Linux kernel 7.0.11 & 7.0.12: The kernel received two updates during June with a heavy security focus. Version 7.0.11 carried an extensive set of CVE fixes spanning BPF (end-of-list detection in cgroup storage, negative CO-RE accessor indices), netfilter (divide-by-zero in nfnetlink_osf, IEEE1394 ARP payload handling, arp_tables), ALSA USB audio UAC2 rate parsing, and more. Version 7.0.12 added fixes for NFC LLCP use-after-free, xfrm underflow, netfilter ebtables OOB read, nf_tables dst corruption, tun/tap XDP page handling, ethtool RSS context handling, ALSA HDA cs35l56 and OSS setup UAF, and HSR OOB access in supervision frame handling.

WebKitGTK 2.52.4: A security-focused update fixing 16 CVEs in the web rendering engine. The release adds support for half-width fonts, improves content filter compilation, improves handling of out-of-disk-space conditions in the NetworkProcess cache, fixes scrollbar painting during width changes, fixes playback of certain YouTube videos with low frame rates, and addresses several crashes and rendering issues.

ImageMagick 7.1.2.25: A security-focused update rejecting malformed HDR, PGX, RLA, FITS, SGI, and DDS files with invalid dimensions. Polynomial distortion argument count validation is added, and an out-of-bounds read of GPS rationals in GetEXIFProperty is fixed.

Mesa 26.1.2: The update resolves graphical corruption on older Intel integrated GPUs (e.g., i5-2400) introduced in 26.1.0 and fixes a crash in ANV’s ASTC texture handling on Xe3 when floating-point exceptions are enabled. Vulkan drivers see important corrections: RADV adds workarounds for Forza Horizon 6 and Crimson Desert, ANV restores Android external format compatibility in debug builds, and PanVK/Turnip improve memory reporting and depth state handling. More details are available in the Mesa 26.1.2 release notes.

mutter 50.2: Fixes size increases when quickly unmaximizing windows by drag, cursor position hint for Xwayland with scaling, fullscreening of edge-tiled windows, tablet tool cursor hotspot scaling, alt-tab with sloppy/mouse focus, and broken switch-monitor mapping on stylus buttons. Support for version 2 of the text_input_v3 protocol is implemented, and DND with tablets now works across surfaces.

flatpak 1.18.0: This update adds support for the AMD compute interface (/dev/kfd) via the DRI device permission, enabling GPU compute access for Flatpak applications on AMD hardware. The output of flatpak update is improved with clearer failure causes, and flatpak-coredumpctl gains better error handling. Fish shell integration startup time is improved. Bug fixes include ignoring system bus failures in parental controls checks and replacing deprecated GTimeVal usage.

cups-filters: The cups-browsed service is now provided as a separate sub-package, allowing users to uninstall it to avoid the security risk of automatic print queue creation from any DNS-SD announcement on the local network.

libzypp 17.38.13: Two security fixes in the package management library. A path= entry in .repo files must not refer to a location outside the repo (CVE-2026-44942), and repo keyhint must denote a filename not a path (CVE-2026-44941).

wicked 0.6.79: Fixes an indirect remote shell command injection via unsanitized DHCP strings and leaseinfo dump (CVE-2026-44932). Single-quote escaping is added to leaseinfo dump output, and posix-tz-dbname processing now permits only valid characters per RFC 4833.

Security Updates

OpenSSL 3:

• CVE-2026-45447: Fixes a heap use-after-free in PKCS7_verify() that could lead to memory corruption.

• CVE-2026-45446: Addresses incorrect tag processing for empty messages in AES-GCM-SIV and AES-SIV modes.

• CVE-2026-42770: Resolves FFC-DH peer validation using attacker-supplied q, potentially weakening key exchange.

• CVE-2026-45445: Fixes AES-OCB IV being ignored on the EVP_Cipher() path.

• CVE-2026-42767: Addresses a NULL pointer dereference in CRMF EncryptedValue decryption.

• CVE-2026-42768: Resolves a multi-recipient Bleichenbacher oracle in CMS_decrypt() and PKCS7_decrypt().

• CVE-2026-42769: Fixes trust-anchor substitution via cert/issuer typo in CMP rootCaKeyUpdate.

• CVE-2026-42766: Addresses a possible NULL dereference in password-based CMS decryption.

• CVE-2026-34183: Resolves unbounded memory growth in the QUIC PATH_CHALLENGE handler.

• CVE-2026-42764: Fixes a NULL pointer dereference in QUIC server initial packet handling.

• CVE-2026-34182: Addresses CMS AuthEnvelopedData processing that could accept forged messages.

• CVE-2026-9076: Fixes an out-of-bounds read in CMS password-based decryption.

• CVE-2026-7383: Resolves a possible heap buffer overflow in ASN.1 multibyte string conversion.

• CVE-2026-34180: Addresses a heap buffer over-read in ASN.1 content parsing.

Linux kernel 7.0.11:

• CVE-2026-45838: Fixes end-of-list detection in BPF cgroup storage.

• CVE-2026-45839: Addresses negative CO-RE accessor indices in BPF.

• CVE-2026-45840: Resolves an upcall PID array size issue in openvswitch.

• CVE-2026-45841: Fixes a divide-by-zero in netfilter nfnetlink_osf.

• CVE-2026-45842: Addresses VJ receive packet rejection on SLIP instances.

• CVE-2026-45843: Resolves compressed decode bounds in SLIP.

• CVE-2026-46242: Fixes an eventpoll struct issue in ep_remove.

• CVE-2026-45844: Addresses IEEE1394 ARP payload handling in netfilter arp_tables.

• CVE-2026-45845: Fixes a NULL pointer dereference in net/sched taprio.

• CVE-2026-45846: Resolves a NULL pointer dereference in bareudp.

• CVE-2026-43494: Fixes zerocopy page pin reset in net/rds.

• CVE-2026-46300: Addresses shared frag marker preservation in skbuff.

• CVE-2026-43503: Resolves shared frag marker propagation through skbuff.

• CVE-2026-46243: Fixes SMB client rejection of userspace cifs.spnego descriptions.

• CVE-2026-46018: Addresses ALSA USB audio UAC2 rate parsing at MAX_NR_RATES.

• CVE-2026-45993: Resolves a LoongArch spectre boundary for syscall dispatch.

• CVE-2026-46006: Fixes a u32 overflow in Nouveau pushbuf relocation.

• CVE-2026-46041: Addresses a sleep-in-atomic context in greybus gb-beagleplay.

• CVE-2026-46022: Fixes an OOB MMIO read in ibmasm.

• CVE-2026-45994: Addresses OOB reads in ibmasm command file write.

• CVE-2026-46064: Resolves a heap over-read in ibmasm I2O message send.

• CVE-2026-46100: Fixes an AFS mmap_prepare revert.

• CVE-2026-46017: Addresses deferred split queue races during migration in mm.

• CVE-2026-46080: Fixes transaction splits in OCFS2 DIO completion.

• CVE-2026-46097: Addresses a use-after-free in edt-ft5x06 input debugfs.

• CVE-2026-46089: Fixes partial discard endio handling in zram.

• CVE-2026-46092: Addresses a PCI upstream bridge existence check in rtw88 WiFi driver.

• CVE-2026-46069: Fixes a use-after-free in mwifiex adapter.

• CVE-2026-46036: Addresses VFIO CDX serialization of device IRQ setting.

• CVE-2026-46034: Resolves a NULL pointer dereference in VFIO CDX interrupt handling.

• CVE-2026-46021: Fixes thermal zone governor cleanup.

• CVE-2026-45996: Addresses a use-after-free on SPI IMX unbind.

• CVE-2026-46074: Fixes memory leaks on SPI CH341 probe failures.

WebKitGTK 2.52.4:

• CVE-2026-28847: Fixes a WebKit memory handling issue that could cause an unexpected crash.

• CVE-2026-28883: Addresses a flaw where processing malicious web content could lead to memory corruption.

• CVE-2026-28901: Resolves a WebKit vulnerability where processing malicious web content could lead to an unexpected crash.

• CVE-2026-28902: Fixes a WebKit issue where processing malicious web content could lead to memory corruption.

• CVE-2026-28903: Addresses a flaw where visiting a malicious website could lead to unexpected behavior.

• CVE-2026-28904: Resolves a WebKit memory corruption issue when processing malicious web content.

• CVE-2026-28905: Fixes a logic issue where a malicious website could access restricted resources.

• CVE-2026-28907: Addresses a WebKit vulnerability that could cause an unexpected crash.

• CVE-2026-28942: Resolves a cross-origin issue in WebKit’s Navigation API.

• CVE-2026-28946: Fixes a WebKit memory handling issue that could lead to an unexpected process crash.

• CVE-2026-28947: Addresses a WebKit flaw where processing malicious web content could bypass the Same Origin Policy.

• CVE-2026-28953: Resolves a logic issue where a malicious website could access script message handlers intended for other origins.

• CVE-2026-28955: Fixes a WebKit memory handling issue that could cause an unexpected process crash.

• CVE-2026-28958: Addresses an authorization flaw where a maliciously crafted webpage could fingerprint the user.

• CVE-2026-43658: Resolves a WebKit sandbox issue where restricted content could be processed outside the sandbox.

• CVE-2026-43660: Fixes a logic flaw where visiting a malicious website could lead to a cross-site scripting attack.

Samba 4.24.3:

• CVE-2026-4480: Fixes unauthenticated remote code execution in the AD DC.

• CVE-2026-4408: Addresses remote code execution in the SAMR protocol.

• CVE-2026-3238: Resolves an unauthenticated UDP packet crash in the AD DC NBT server.

• CVE-2026-3012: Fixes group policy certificate enrollment using HTTP without validation.

• CVE-2026-1933: Addresses a missing access check on reparse point operations.

• CVE-2026-2340: Resolves a vfs_worm not blocking directory modification.

• CVE-2026-40170: Addresses a third-party ngtcp2 update requirement.

OpenEXR 3.4.12:

• CVE-2026-45696: Fixes a heap-buffer-overflow READ via codestream/channel width mismatch in HTJ2K decode.

• CVE-2026-44663: Addresses an integer overflow in the HTJ2K decoder leading to heap-buffer-overflow.

GraphicsMagick 1.3.47:

• CVE-2026-25799: Fixes YUV sampling-factor argument validation to prevent potential security issues.

• CVE-2026-26284: Fixes a security vulnerability in GraphicsMagick image processing.

• CVE-2026-28690: Addresses MNG writer enforcing a 256-color palette limit to prevent excessive memory usage.

• CVE-2026-30883: Fixes detection and reporting of excessively large profiles in the PNG writer.

• CVE-2026-33535: Addresses a static buffer overflow in MagickXImageWindowCommand when a numeric key is held depressed.

• CVE-2026-42050: Fixes an off-by-one error in GraphicsMagick.

MariaDB 11.8.8:

• CVE-2026-49261: Fixes a security vulnerability in the MariaDB server.

• CVE-2026-48165: Addresses a security vulnerability in MariaDB.

• CVE-2026-48163: Resolves a security vulnerability in MariaDB.

python-tornado6 6.5.7:

• CVE-2026-49853: Fixes credentials and cookies not being stripped when following redirects to a different origin.

• CVE-2026-49855: Addresses a denial-of-service via large compressed responses bypassing max_body_size.

• CVE-2026-49854: Resolves an out-of-bounds read of up to three bytes past an input array in the C extension.

7-Zip 26.01:

• CVE-2026-48095: Fixes a heap buffer write overflow that could be triggered by crafted archives.

sshfs 3.7.6:

• CVE-2026-47187: Fixes a symlink escape vulnerability where a rogue SFTP server could read or write local files.

• CVE-2026-48711: Addresses an argument injection vulnerability in SSH command handling.

php8 8.5.7:

• CVE-2026-44927: Fixes pointer difference truncation to int in uriparser that could lead to incorrect URI handling.

• CVE-2026-44928: Addresses a flaw where the EqualsUri function could misclassify two unequal URIs as equal.

libzypp 17.38.13:

• CVE-2026-44942: Fixes a path= entry in .repo files that could refer to locations outside the repository base.

• CVE-2026-44941: Addresses a repo keyhint entry that could specify a path instead of a filename.

wicked 0.6.79:

• CVE-2026-44932: Fixes an indirect remote shell command injection via unsanitized DHCP strings and leaseinfo dump.

perl-Cpanel-JSON-XS 4.41:

• CVE-2026-9516: Fixes a BOM-shift PV-corruption that could cause a SIGABRT.

• CVE-2026-9334: Addresses a type confusion in dupkeys_as_arrayref handling.

openssh:

• CVE-2026-3497: Fixes a possible information disclosure or denial of service due to uninitialized variables in GSSAPI key exchange patches.

python-pip 26.1.2:

• CVE-2026-8643: Fixes console_scripts and gui_scripts entry points whose name would install a script outside the scripts directory.

OpenSC:

• CVE-2026-10275: Fixes a global buffer overflow during key pair generation tests due to missing input validation.

python-M2Crypto 0.48.0:

• CVE-2026-0672: Fixes authcookie handling of CookieError from Python 3.13.12+ to prevent potential security issues.

freeipmi 1.6.18:

• CVE-2026-50031: Fixes potential stack corruption in Dell and Fujitsu IPMI OEM commands and a potential buffer overflow in Fujitsu SEL entry handling.

graphite2 1.3.15:

• CVE-2026-50593: Fixes a security vulnerability in the graphite font shaping library.

ldns 1.9.2:

• CVE-2026-10846: Fixes insufficient verification that DNS responses belong to a query, enabling potential cache poisoning.

glib-networking:

• CVE-2026-10028: Fixes a cycle detection issue when setting the issuer property in the TLS certificate chain.

perl-GD 2.86:

• CVE-2026-11526: Fixes a command injection via 2-arg open() in _make_filehandle.

perl-HTML-Parser 3.85:

• CVE-2026-8829: Fixes a heap-use-after-free in _decode_entities.

djvulibre 3.5.30:

• CVE-2021-46312: Fixes a security vulnerability in DjVu file processing.

rav1e:

• CVE-2025-58160: Fixes a security vulnerability in Rust AV1 encoder dependencies.

Users are advised to update to the latest versions to mitigate these vulnerabilities.

Conclusion

June came with some heavy security hardening across openSUSE Tumbleweed. Samba jumped to the 4.24 series with many CVE fixes, MariaDB advanced to 12.3.2, and Flatpak reached 1.18.0. OpenSSL received an extensive security refresh, while WebKitGTK and the Linux kernel each received large rounds of vulnerability fixes. KDE Gear 26.04.2 continued the steady cadence of KDE application refinements, GStreamer 1.28.4 delivered major RTSP infrastructure improvements, and GraphicsMagick 1.3.47 rolled up years of accumulated upstream security patches. The openSUSE Conference in Nuremberg provided the community backdrop for planning the next phase of the rolling release.

Slowroll Arrivals

Please note that these updates also apply to Slowroll and arrive between an average of 5 to 10 days after being released in Tumbleweed snapshot. This monthly approach has been consistent for many months, ensuring stability and timely enhancements for users. Updated packages for Slowroll are regularly published in emails on openSUSE Factory mailing list.

Contributing to openSUSE Tumbleweed

Stay updated with the latest snapshots by subscribing to the openSUSE Factory mailing list. For those Tumbleweed users who want to contribute or want to engage with detailed technological discussions, subscribe to the openSUSE Factory mailing list . The openSUSE team encourages users to continue participating through bug reports, feature suggestions and discussions.

Your contributions and feedback make openSUSE Tumbleweed better with every update. Whether reporting bugs, suggesting features, or participating in community discussions, your involvement is highly valued.

Igual os sorprende esta entrada. Como comenté hace poco, KDE blog ahora es administrado íntegramente por mi. Es otras palabras, ahora no solo me dedico a realizar un artículo al día, sino que me corresponde a mi administrar las cuestiones técnicas, administrativas y económicas del blog. Es por ello que KDE Blog solicitó colaboración de la Comunidad y por ello anuncié que no solo iba a necesitar ayuda en temas de código y procesos (algo que al final ha sido menos de lo que pensaba gracias a Neodigit) sino que también iba a probar si la Comunidad podía financiar económicamente este sitio iniciando una campaña de financiación que busca cubrir gastos. En 7 meses el blog solo ha tenido 7 donaciones (muchas gracias a las personas que los han hecho) lo cual me hace sentir un poco decepcionado. Así que lanzo una reflexión y doy un pequeño impulso a la campaña.

7 meses y solo 7 donaciones – KDE Blog solicita colaboración de la comunidad

Un poco de contexto, de nuevo.

En 2018 nació KDE Blog, siendo mi papel únicamente escribir artículos llevando la parte técnica Ebooz. Como dije el 15 de diciembre de 2025, se produjo un cambio y ahora funciona alojado en los de Neodigit, una empresa de Tecnocrática.

Este no fue solamente un cambio de servidores, ya que ahora sería yo quien llevaría el blog en todas sus dimensiones, lo cual me lleva a un nuevo reto tanto de a nivel de conocimientos de tiempo y, por supuesto, económico.

La primera parte la llevo bien: estoy mejorando el aspecto del blog, mejorando las entradas recurrentes con información extra, creando nuevos widgets para facilitar el acceso a entradas antiguas, intentando ofrecer contenido de mayor calidad y actualizando viejas entradas.

Pero la segunda parte parece ser más dura ya que no depende de mi, sino de la buena voluntad de los lectores. En 7 meses solo he tenido 7 donaciones en total, alguna de ellas mucho más generosas de lo que pensaba. En mi imaginación pensaba que muchos miembros de la Comunidad aportaría pequeñas cantidades (el equivalente de un café y algo más) y que subiría poco a poco. No ha sido así, con lo que al menos agradezco 100% las donaciones de las personas que han creído que este blog se merecía esa ayuda económica.

Si que es cierto que los ingresos del blog pueden venir de otras vías como de artículos patrocinados pero intento que sean los mínimos posibles y relacionados con el mundo digital (pero alejados de casinos, apuestas o criptomonedas) y siempre con un toque personal. En unos 210 artículos que llevo este 2026 solo hay uno patrocinado, y encima con información de un Service Menú de KDE Plasma.

No obstante, no es por la cantidad de dinero recaudado mi queja, sino por el poco apoyo en número de donaciones o en agradecimientos que recibe el blog. Es bastante triste dedicar tanto tiempo al blog y tener tan pocos comentarios, tan pocas palmadas en la espalada, etc.

Personalmente, sé que lo que hago gusta en general, que hay artículos buenos, regulares y malos, pero que ayuda en mayor o menor medida a difundir el Software Libre, y eso me basta para seguir. Estoy bien considerado dentro del pequeño grupo de activistas que piensan, de forma acertada, que el Software Libre no funciona sin el esfuerzo de las personas y que su triunfo será el de la humanidad (esto me ha salido muy épico pero seguro que quien está dentro de una asociación lo entiende).

Así que reitero, aunque su existencia no esté vinculado a una posible desaparición del proyecto, KDE Blog sigue solicitando vuestra colaboración global en forma de donación para cubrir los gastos, que aproximadamente están estimados en 130 € por año (alojamiento y dominio). Así que en la cabecera y en la columna de la derecha de las entradas aparecerá la campaña de financiación y agradezco de antemano cualquier colaboración, por pequeña que sea.

La entrada 7 meses y solo 7 donaciones – KDE Blog solicita colaboración de la comunidad se publicó primero en KDE Blog.

O OpenCV 5.0.0 foi lançado oficialmente em junho de 2026 e representa uma das mudanças mais importantes da biblioteca desde a consolidação do OpenCV 2.x e 4.x. Não se trata apenas de uma atualização incremental: a versão 5 reorganiza módulos, remove APIs antigas, moderniza a base de código, melhora o suporte a IA, amplia o suporte a ONNX, introduz novos tipos de dados e prepara a biblioteca para uma computação visual mais heterogênea, envolvendo CPU, GPU, aceleradores e novos backends de hardware. O release oficial do GitHub marca o OpenCV 5.0.0 como a versão mais recente e aponta para o resumo oficial e o guia de migração 4.x → 5.x

O que muda na visão geral

O OpenCV passa a manter duas linhas ativas: a ramificação 4.x, ainda estável, e a nova 5.x, também estável, onde a maior parte das funcionalidades mais recentes será concentrada. A versão 5.0 aproveita partes consolidadas do OpenCV 4.x, adiciona novos recursos, remove componentes obsoletos e introduz algumas mudanças de API, principalmente para limpar dívida técnica acumulada ao longo dos anos.

Na prática, o OpenCV 5.0.0 mira três frentes: modernização da base de código, melhor suporte a IA e melhor preparação para aceleração em diferentes arquiteturas. Isso é especialmente importante para aplicações atuais de visão computacional, robótica, edge AI, sistemas embarcados, inspeção industrial, biometria, vídeo analytics, veículos autônomos e pipelines que combinam visão clássica com deep learning.

Novos requisitos: C++17 e fim do Python 2

Uma das primeiras mudanças é o requisito mínimo de C++17. O OpenCV 5.0 é compilado por padrão com C++17 e deve ser compatível com padrões mais novos. Para quem mantém projetos C++, isso significa revisar toolchains, CMake, compiladores e pipelines de build. O guia oficial de migração recomenda configurar o projeto para C++17 e informa versões mínimas como GCC 8, Clang 9 e MSVC 2017 19.14 ou superior.

O suporte ao Python 2 foi removido. A partir do OpenCV 5.0, é necessário usar Python 3.6 ou superior, e apenas bindings para Python 3 são construídos e distribuídos. Para projetos modernos isso dificilmente será um problema, mas ambientes legados precisarão ser atualizados.

Limpeza pesada: adeus API C legada

O OpenCV 5 removeu a antiga API C do OpenCV 1.x. Funções como cvCreateMat() e cvFindContours(), além de estruturas como CvMat e IplImage, foram retiradas. Alguns macros como CV_8U e CV_32F continuam existindo, mas o caminho oficial agora é a API C++.

Essa decisão é simbólica e técnica. Simbólica porque fecha definitivamente a era do OpenCV 1.x. Técnica porque reduz complexidade, facilita manutenção e permite que a biblioteca avance com modelos de dados e APIs mais modernas. O guia de migração observa que a maior parte do código de produção da última década já não usa diretamente a API C, mas projetos legados precisarão migrar para C++.

OpenVX removido e caminho para uma HAL não CPU

O suporte a OpenVX foi removido da árvore principal. A justificativa é que o OpenCV está caminhando para uma nova camada de abstração de hardware, uma HAL não CPU, que poderá permitir a integração de acelerações específicas de fornecedores sem amarrar a biblioteca a uma única API externa.

Essa mudança é importante para o futuro do OpenCV em ambientes heterogêneos. Em vez de tentar manter integrações antigas e específicas, a biblioteca passa a caminhar para um modelo em que diferentes fornecedores podem plugar acelerações por baixo, mantendo uma interface mais consistente para o desenvolvedor.

G-API e ML clássico foram para o opencv_contrib

O módulo Graph API, conhecido como G-API, foi movido para opencv_contrib. O mesmo aconteceu com o módulo clássico de machine learning, ml. Quem ainda depende de cv::ml::SVM, cv::ml::RTrees ou da G-API precisará compilar o OpenCV com os módulos extras do opencv_contrib.

Para usuários Python, a recomendação oficial é considerar alternativas como scikit-learn para algoritmos clássicos de machine learning. O guia de migração também reforça que cv2.ml.* só estará disponível se o OpenCV for construído com opencv_contrib.

Features2D virou Features

O antigo módulo features2d foi renomeado para features. A mudança reflete uma ampliação de escopo: o módulo deixa de tratar apenas detectores e descritores clássicos 2D e passa a lidar também com vetores de características produzidos por redes neurais modernas.

Detectores clássicos importantes como SIFT, ORB, FAST, GoodFeaturesToTrack e MSER continuam no repositório principal. Já alguns descritores e detectores obsoletos foram movidos para opencv_contrib. O OpenCV 5 também adiciona recursos de características locais baseados em deep learning, incluindo ALIKED e DISK, além do matcher LightGlue.

Outra mudança relevante é a substituição prática do FLANN por busca aproximada de vizinhos mais próxima baseada em Annoy dentro do módulo features. Isso moderniza a forma como o OpenCV lida com busca ANN, especialmente em cenários envolvendo embeddings e vetores de características.

Objdetect foi limpo: Haar e HOG foram para contrib

O módulo objdetect também passou por limpeza. Detectores baseados em Haar e HOG foram movidos para opencv_contrib, no módulo xobjdetect. A explicação é direta: detectores modernos baseados em deep learning tendem a ser mais rápidos e mais precisos.

Para novos projetos, isso sinaliza uma mudança de paradigma. O OpenCV continua preservando compatibilidade via contrib para quem precisa de Haar Cascade ou HOG, mas incentiva o uso de detectores modernos, como modelos DNN para detecção facial e objetos. O guia de migração cita, por exemplo, o uso do FaceDetectorYN baseado em DNN.

Calib3d foi dividido em módulos especializados

O antigo e grande módulo calib3d foi dividido em quatro módulos: geometry, calib, stereo e ptcloud. O módulo geometry concentra algoritmos clássicos de geometria 2D, 3D e nD; calib fica com calibração de câmera; stereo cuida de estimativa de profundidade por correspondência estéreo; e ptcloud reúne algoritmos de alto nível para dados 3D, como odometria visual e TSDF.

Para C++, o cabeçalho legado opencv2/calib3d.hpp continua funcionando como uma camada de compatibilidade, incluindo os novos cabeçalhos por baixo. Para novos projetos, porém, a recomendação é incluir apenas o módulo necessário, como opencv2/geometry.hpp, opencv2/calib.hpp ou opencv2/stereo.hpp. Em Python, a mudança é transparente: as funções continuam acessíveis por cv2.

Novos tipos de dados no Core

O módulo Core recebeu novos tipos de dados. Além dos tipos já conhecidos, como CV_8U, CV_16U, CV_32F, CV_64F e CV_16F, o OpenCV 5 introduz CV_16BF para bfloat16, CV_32U para uint32_t, CV_64U para uint64_t, CV_64S para int64_t e CV_Bool para booleanos armazenados em 1 byte.

Essa mudança aproxima o OpenCV das necessidades modernas de IA. Tipos como FP16 e BF16 são fundamentais em deep learning, inferência otimizada, aceleradores e pipelines que buscam reduzir consumo de memória. O OpenCV também informa que operações básicas com hfloat e bfloat estão disponíveis mesmo em hardware sem suporte nativo, usando conversões internas eficientes.

O tipo CV_Bool também é importante porque matrizes booleanas agora podem ser usadas como máscaras onde antes se usavam máscaras uchar ou schar. Isso melhora a semântica do código e deixa mais clara a intenção do desenvolvedor.

Matrizes 1D e 0D de verdade

O OpenCV 5 passa a suportar arrays com menos de duas dimensões. Um std::vector<T> encapsulado em Mat, InputArray ou OutputArray agora é tratado como um array 1D real, e não mais como uma matriz 2D Nx1 ou 1xN, como acontecia no OpenCV 4.x.

Essa mudança pode afetar códigos que verificam diretamente .rows ou .cols. O guia de migração recomenda usar .total() para obter o número de elementos quando o código precisar funcionar de forma compatível. Para distinguir uma matriz vazia de um escalar 0D, a recomendação é usar mat.empty().

MatShape substitui MatSize

O OpenCV 5 introduz MatShape como substituto de MatSize. A nova estrutura carrega informações de forma e layout dos dados, é embutida diretamente em Mat, UMat e GpuMat e evita alocações dinâmicas extras. Ela também é usada extensivamente pelo módulo DNN para inferência de formas.

Para compatibilidade, MatSize continua disponível como alias, mas novos códigos devem preferir MatShape. Essa mudança é especialmente relevante para modelos de IA, tensores e operações multidimensionais.

LAPACK sempre disponível

O OpenCV 5 passa a ter LAPACK sempre disponível internamente. Isso melhora operações como SVD, decomposição de autovalores/autovetores e componentes do framework USAC. Quando não houver uma biblioteca LAPACK externa instalada, o OpenCV constrói e usa um subconjunto interno mínimo.

Imgproc: mais desempenho, mais precisão e melhor texto

O módulo imgproc recebeu mudanças importantes. Algoritmos de geometria computacional, como convex hull, triangulação de Delaunay e funções relacionadas, foram movidos para o módulo geometry. Em C++, pode ser necessário adicionar opencv2/geometry.hpp; em Python, as funções continuam disponíveis por cv2.

As funções warpAffine, warpPerspective e remap foram substancialmente revisadas. A interpolação bilinear e bicúbica deixou de usar aproximações baseadas em tabelas, resultando em maior precisão e melhor desempenho. Segundo o resumo oficial, os ganhos de velocidade variam de 10% a mais de 300%, dependendo da plataforma, tamanho da imagem, tipo de dado e flags de operação.

O redimensionamento por vizinho mais próximo agora segue o algoritmo do Pillow, tornando os resultados compatíveis com ele. Isso é útil para pipelines que misturam OpenCV e Pillow, mas pode exigir atualização de testes pixel-a-pixel baseados em saídas antigas do OpenCV 4.x.

A renderização de texto foi modernizada. O OpenCV 5 substitui o mecanismo antigo por um renderizador TrueType baseado em STB, com a fonte variável Rubik embutida. Usuários também podem carregar fontes customizadas. Isso amplia o suporte a Unicode, embora ainda existam limitações para scripts que exigem shaping complexo, como árabe e devanágari, e para emojis coloridos.

Também foi adicionado o algoritmo TRUCO, sigla para “Threaded Raster Unrestricted Contour Ownership”, usado para acelerar a extração de contornos. O cv::findContours() passa a usar TRUCO automaticamente quando possível, e o novo algoritmo é descrito como várias vezes mais rápido que a implementação anterior.

DNN: o módulo mais transformado do OpenCV 5

A maior mudança do OpenCV 5 está no módulo DNN. Ele recebeu um novo motor de inferência, que passa a coexistir com o motor clássico. Esse novo motor oferece suporte muito melhor a shapes dinâmicos, subgrafos e recursos modernos do ONNX. A cobertura da especificação ONNX passa de menos de 23% no OpenCV 4.x para mais de 80% no OpenCV 5.

A função cv::dnn::readNet() e variantes como readNetFromONNX() passam a aceitar o parâmetro engine = ENGINE_AUTO. Por padrão, o OpenCV tenta usar o novo motor e, se não conseguir carregar o modelo, faz fallback automático para o motor clássico. Também é possível controlar o motor por variável de ambiente: 1 para clássico, 2 para novo motor, 3 para automático e 4 para ONNX Runtime.

O OpenCV 5 também pode ser construído com ONNX Runtime integrado. Nesse modo, o OpenCV usa seu próprio parser ONNX para construir o grafo ORT internamente, evitando depender do pacote ONNX completo e reduzindo o tamanho binário. Para GPU NVIDIA via ORT, a build deve ser feita com as opções correspondentes de ONNX Runtime GPU.

Um ponto de atenção: o novo motor DNN roda atualmente apenas em CPU. O suporte a GPU para esse novo motor será adicionado em versões futuras. Enquanto isso, quem precisa de GPU deve forçar o motor clássico ou compilar com ONNX Runtime e execution providers da NVIDIA.

Fim dos parsers Darknet e Caffe

Os parsers Darknet e Caffe foram removidos. Isso afeta funções como readNetFromDarknet() e readNetFromCaffe(). A recomendação oficial é converter modelos para ONNX e carregá-los com readNetFromONNX(). Modelos TFLite continuam funcionando via motor clássico, com migração para o novo motor planejada.

Essa mudança acompanha o mercado. ONNX se consolidou como formato comum para interoperabilidade entre frameworks, enquanto Darknet e Caffe ficaram mais associados a modelos e pipelines legados.

Suporte a VLMs: visão e linguagem dentro do OpenCV

O novo motor DNN inclui suporte para modelos visão-linguagem, ou VLMs. O OpenCV 5 passa a incluir componentes necessários como tokenizers, camadas de atenção, blocos de decodificação, pós-processamento e KV-cache para executar VLMs de ponta a ponta.

Isso é uma mudança conceitual forte. Historicamente, o OpenCV era visto como uma biblioteca de visão computacional clássica, com suporte crescente a deep learning. Agora ele começa a entrar no território de modelos multimodais, capazes de combinar imagem e texto.

Desempenho do novo DNN

O resumo oficial informa que o novo motor entrega desempenho competitivo em CPU, igualando ou superando o ONNX Runtime em vários modelos. Os benchmarks apresentados comparam tempos de inferência em milissegundos em diferentes plataformas, incluindo Intel i9, Intel i7, Apple M1, Apple M5 e AMD, com modelos como MobileNetv2, ResNet-50, YOLOv8, ViT e SAM2 Encoder.

Os números variam conforme modelo e hardware. Em alguns casos, o ONNX Runtime ainda é mais rápido; em outros, o OpenCV 5 aparece à frente. O ponto central é que o OpenCV deixa de ser apenas uma alternativa simples de inferência e passa a competir mais diretamente com runtimes especializados em workloads de IA.

Modelos migrados para o Hugging Face

A coleção de modelos pequenos e eficientes do OpenCV foi migrada para o Hugging Face. Todos os modelos usam ONNX e devem ser compatíveis com outros frameworks de inferência.

Isso facilita download, reuso, versionamento e integração com ecossistemas modernos de IA. Para quem trabalha com demonstrações, protótipos, pipelines educacionais ou validação rápida de modelos, essa mudança é bastante prática.

Novo módulo Geometry e calibração multicâmera

A reorganização de geometria e calibração é uma das grandes melhorias estruturais do OpenCV 5. O framework USAC passa a ser o backend padrão para algoritmos de estimação robusta, incluindo homografia, matriz essencial, matriz fundamental, solvePnP e outros. Em comparação com o RANSAC clássico, o USAC combina estratégias modernas como PROSAC, NAPSAC, Progressive-NAPSAC, MSAC, MAGSAC++, LMeds, LO-RANSAC, GC-RANSAC e verificação SPRT.

Também foi adicionado um pipeline de calibração multicâmera ao módulo calib. Ele calibra N câmeras simultaneamente em três estágios: intrínsecos por câmera, extrínsecos par-a-par e otimização global final. O pipeline suporta modelos pinhole e fisheye, inclusive rigs mistos.

O pipeline aceita padrões checkerboard, ChArUco e circle grid. Ele também lida com observações parciais, quando nem todas as câmeras enxergam o padrão completo em todos os frames. Isso é essencial para rigs reais, nos quais o campo de visão entre câmeras pode não se sobrepor perfeitamente.

Processamento 3D: malhas, nuvens de pontos, TSDF e ICP

O OpenCV 5 adiciona suporte inicial a algoritmos de malha e nuvem de pontos, incluindo TSDF e ICP. Também foram adicionados importadores e exportadores para formatos populares como .ply e .obj.

Isso aproxima o OpenCV de aplicações de robótica, reconstrução 3D, sensores de profundidade, visão estéreo, SLAM, inspeção volumétrica e percepção espacial. Ainda é um suporte inicial, mas indica uma direção clara para o ciclo 5.x.

Samples revisados e exemplos de IA generativa

Muitos samples foram revisados, exemplos obsoletos foram removidos e novos exemplos foram adicionados. Os samples de deep learning agora usam uma coleção compartilhada de modelos, que pode ser baixada pelo script download_models.py dentro de samples/dnn.

Também foram adicionados samples experimentais para VLMs e modelos de difusão latente, LDM. Isso mostra que o OpenCV está se posicionando não apenas para visão clássica e deep learning discriminativo, mas também para fluxos mais modernos de IA multimodal e generativa.

Documentação modernizada

A documentação do OpenCV 5 foi modernizada com tema responsivo, navegação lateral persistente, índice “on this page”, busca instantânea com Ctrl+K, modo claro/escuro e melhor renderização matemática.

Essa melhoria parece secundária, mas é importante para adoção. OpenCV é usado por estudantes, pesquisadores, empresas e engenheiros de produto. Uma documentação mais navegável reduz barreiras de entrada e acelera migrações.

Mudanças importantes para migração

A migração do OpenCV 4.x para 5.x tende a exigir ajustes pequenos na maioria dos projetos, mas alguns pontos merecem atenção. O guia oficial lista como áreas afetadas: requisitos de build, remoção da API C, reestruturação de módulos, mudanças no Core, novo motor DNN, alterações de comportamento no imgproc, mudanças em Video I/O e detalhes dos bindings Python.

Projetos C++ devem revisar includes, especialmente em calib3d, features2d, imgproc, ml, gapi, Haar/HOG e geometria computacional. Projetos Java precisarão atualizar imports em alguns casos. Em Python, boa parte da reestruturação é transparente, pois as funções continuam acessíveis em cv2, mas cv2.ml.*, Haar e HOG dependem de build com opencv_contrib.

No DNN, modelos ONNX continuam sendo carregados de forma parecida, mas Caffe e Darknet devem ser convertidos para ONNX. Quem depende de GPU deve observar que o novo motor é CPU-only por enquanto, sendo necessário usar o motor clássico ou ONNX Runtime com provider NVIDIA.

No imgproc, pipelines com testes pixel-a-pixel podem precisar atualizar baselines. O resize por vizinho mais próximo agora segue o comportamento do Pillow, e warpAffine, warpPerspective e remap podem gerar pequenas diferenças numéricas por usarem interpolação mais precisa.

No módulo Video I/O, VideoCapture::get() passa a retornar -1 para propriedades não suportadas. No OpenCV 4.x, retornava 0, o que era ambíguo porque 0 também pode ser um valor válido para algumas propriedades. A recomendação é testar valores menores que zero para detectar propriedades não suportadas.

Atenção para Android e páginas de 16 KB

O release oficial traz uma observação específica para Android: o SDK Android original do OpenCV 5.0.0 foi construído com NDK antigo e inclui biblioteca C++ padrão sem alinhamento adequado para dispositivos com páginas de 16 KB. Para publicações no Google Play, a recomendação é usar o pacote com sufixo 16kb-page-fix.

Essa observação é importante para desenvolvedores Android, especialmente considerando exigências recentes de compatibilidade em dispositivos e versões novas do sistema.

O impacto prático do OpenCV 5.0.0

Para quem usa OpenCV apenas para carregar imagem, redimensionar, converter cor e salvar vídeo, a migração provavelmente será simples. Mas mesmo nesses casos há ganhos potenciais de desempenho e mudanças de comportamento em resize, warp e renderização de texto.

Para quem usa OpenCV com IA, a mudança é muito maior. O novo DNN, a maior cobertura ONNX, o suporte a VLMs, os novos tipos BF16/FP16 e a integração com ONNX Runtime colocam o OpenCV em uma posição mais competitiva como runtime de inferência em CPU e como ferramenta de prototipação multimodal.

Para robótica, visão 3D e calibração, a divisão de calib3d, o novo pipeline multicâmera, o USAC como backend padrão e o suporte inicial a nuvens de pontos e malhas tornam o OpenCV 5 mais organizado e mais alinhado com aplicações modernas de percepção.

Para sistemas embarcados e edge AI, a direção é clara: o OpenCV quer ser uma camada de visão computacional portátil, capaz de aproveitar acelerações específicas sem obrigar o desenvolvedor a reescrever a aplicação para cada hardware.

Conclusão

O OpenCV 5.0.0 não é apenas uma nova versão; é uma mudança de geração. Ele remove o passado legado da API C, reorganiza módulos, moderniza tipos de dados, melhora processamento de imagem, amplia fortemente o DNN, melhora suporte a ONNX, abre caminho para VLMs, fortalece visão 3D e prepara a biblioteca para um futuro heterogêneo.

A versão também exige cuidado na migração. Projetos que usam Caffe, Darknet, API C antiga, Haar/HOG, cv2.ml.*, G-API, comparações pixel-a-pixel ou GPU via DNN precisam testar com atenção. Mas o ganho é claro: uma biblioteca mais limpa, moderna, pronta para IA e mais adequada ao cenário atual de visão computacional.

O OpenCV 5.0.0 marca a transição do OpenCV de uma biblioteca clássica de visão computacional para uma plataforma moderna de visão, IA, geometria, inferência e percepção multimodal.

Me alegra compartir con todos vosotros la segunda actualización de Plasma 6.7, continuando así la serie de revisión de software que le dotará de más estabilidad, mejores traducción y resolución de errores. Estas actualizaciones son 100% recomendables y casi obligatorias para cualquier usuario ya que lo único que hacen es mejorar la versión sin comprometer sus funcionalidades.

Segunda actualización de Plasma 6.7

No existe Software creado por la humanidad que no contenga errores. Es un hecho incontestable y cuya única solución son las actualizaciones. Es por ello que en el ciclo de desarrollo del software creado por la Comunidad KDE se incluye siempre las fechas de las mismas siguiendo una especie de serie de Fibonacci.

Así que me congratula en presentar que hoy martes 30 de junio de 2026, unas semanas después de liberar el código de Plasma 6.7 la Comunidad KDE presenta la segunda actualización de errores.

Más información: KDE

Las novedades generales de Plasma 6.7

Aprovecho para realizar un listado de las novedades generales de Plasma 6.7:

• Escritorios virtuales por pantalla: Ahora es posible configurar escritorios virtuales de forma independiente para cada monitor.
• Prueba del volumen del micrófono: Se ha añadido una herramienta para comprobar los niveles de entrada de audio, facilitando el diagnóstico de problemas con el micrófono.
• Caracteres especiales en teclado virtual: Al usar el teclado virtual, es posible mantener pulsada una tecla para acceder a los caracteres especiales asociados a ella.
• Interruptor rápido de temas: Se incluye un nuevo control para cambiar instantáneamente entre los temas globales claros y oscuros.
• Calendario lunar vietnamita: Se ha integrado este calendario en el sistema para permitir su uso junto al gregoriano.
• Mejora en «Aplicaciones en segundo plano»: La bandeja del sistema ahora muestra también las aplicaciones que utilizan el sistema de segundo plano moderno, frecuente en paquetes Flatpak.
• Monitorización de impresión: El icono de la bandeja del sistema para impresoras ahora muestra una placa indicando el número de trabajos activos.
• Gestión de colas de impresión: Se ha introducido una nueva herramienta para gestionar colas de impresión, diseñada tanto para un uso doméstico sencillo como para la gestión avanzada de múltiples impresoras.
• Acceso rápido a escritorios en Vista general: Desde la Vista general (Meta + W), ahora es posible cambiar entre escritorios virtuales usando el ratón o las teclas RePág y AvPág.
• Favoritos por arrastrar y soltar: Se ha simplificado la gestión de favoritos en los lanzadores y menús de aplicaciones mediante la función de arrastrar y soltar.

Más información: KDE

La entrada Segunda actualización de Plasma 6.7 se publicó primero en KDE Blog.

A interface entre cérebro e máquina sempre pareceu pertencer ao futuro distante. Durante décadas, a ideia de uma pessoa conseguir se comunicar apenas por meio da atividade cerebral foi tratada como ficção científica ou como uma tecnologia limitada a laboratórios altamente especializados. O projeto Brain2Qwerty, da Meta AI Research, mostra que esse futuro está ficando mais concreto.

O Brain2Qwerty é uma pesquisa de interface cérebro-computador não invasiva capaz de decodificar sentenças digitadas a partir de sinais cerebrais. Em vez de exigir implantes cirúrgicos no cérebro, o projeto utiliza registros de atividade cerebral capturados por tecnologias como MEG, magnetoencefalografia, e EEG, eletroencefalografia. A proposta é ambiciosa: aproximar a IA de um cenário em que pessoas que perderam a capacidade de falar ou se mover possam voltar a se comunicar sem precisar passar por cirurgia cerebral.

A versão mais recente, chamada Brain2Qwerty v2, representa um avanço importante em relação à primeira versão. O Brain2Qwerty v1 já conseguia prever teclas a partir de padrões de atividade cerebral registrados por MEG, mas dependia do tempo exato de cada tecla pressionada, o que limitava seu uso em tempo real. A versão v2 supera essa limitação ao gerar sentenças diretamente a partir de gravações contínuas da atividade cerebral.

Na prática, o sistema combina módulos hierárquicos para interpretar diferentes níveis da linguagem: letras, palavras e sentenças. O pipeline usa redes neurais profundas para transformar sinais cerebrais ruidosos em texto coerente, explorando também o contexto linguístico com modelos de linguagem. Esse ponto é essencial, porque o cérebro não gera um sinal “limpo” como um teclado tradicional; a IA precisa inferir padrões, corrigir ambiguidades e reconstruir o significado provável da frase.

Os resultados chamam atenção. Segundo a Meta, o Brain2Qwerty v2 foi treinado com aproximadamente 22 mil sentenças de nove voluntários, cada um gravado por cerca de 10 horas usando um equipamento de MEG enquanto digitava. O modelo alcançou 61% de acurácia média por palavra e chegou a 78% no melhor participante. Mais de metade das sentenças do melhor caso foram decodificadas com no máximo um erro de palavra.

Esse avanço precisa ser entendido com equilíbrio. Não estamos falando ainda de uma tecnologia pronta para uso doméstico ou clínico amplo. O próprio projeto reconhece dois grandes desafios: a precisão ainda não é suficiente para comunicação cotidiana confiável, e o equipamento de MEG usado nos testes é grande, caro e inacessível para a maioria dos pacientes. Ainda assim, a pesquisa mostra uma tendência promissora: quanto mais dados são usados no treinamento, melhor fica o desempenho do decodificador, sem que tenha sido observado um platô claro de evolução até o momento.

O artigo publicado na Nature Neuroscience sobre o Brain2Qwerty v1 já indicava o potencial da abordagem. Naquele estudo, os pesquisadores demonstraram a decodificação de sentenças digitadas a partir de EEG e MEG em voluntários saudáveis. O desempenho com MEG foi muito superior ao EEG, com taxa média de erro de caracteres de 29% contra 65% no EEG, chegando a 18% de erro nos melhores participantes usando MEG.

A grande mudança da v2 está na aproximação com uma interface mais contínua e natural. Em vez de depender de marcações explícitas de cada tecla, o sistema tenta compreender a produção da frase diretamente a partir do fluxo da atividade cerebral. Isso coloca o Brain2Qwerty em uma categoria muito relevante para o futuro das neuropróteses: sistemas menos invasivos, mais escaláveis e potencialmente mais seguros.

Outro ponto importante é a abertura científica. O repositório oficial no GitHub disponibiliza código para as versões v1 e v2, com licença CC BY-NC 4.0, ou seja, com restrição para uso não comercial. O dataset da v1, coletado pelo BCBL, também foi disponibilizado no Hugging Face, enquanto o dataset da v2 permanece sob embargo até a aceitação do artigo correspondente.

Do ponto de vista tecnológico, o Brain2Qwerty mostra como a próxima geração de IA não estará limitada a texto, imagem, áudio ou vídeo. A fronteira agora avança para sinais biológicos. A IA passa a atuar como tradutora entre padrões neurais e linguagem humana. Isso abre portas para aplicações em acessibilidade, reabilitação, medicina, neurociência computacional e interfaces homem-máquina.

Mas esse tipo de tecnologia também exige responsabilidade. Decodificar sinais cerebrais envolve questões profundas de privacidade, consentimento, segurança e governança. Se hoje discutimos proteção de dados pessoais, amanhã discutiremos com ainda mais intensidade a proteção de dados neurais. O cérebro não pode ser tratado como mais uma fonte comum de dados. Ele representa uma camada extremamente sensível da identidade humana.

O Brain2Qwerty não é apenas um projeto de IA. Ele é um marco simbólico de uma nova fase: a convergência entre inteligência artificial, neurociência e computação de alto desempenho. Ainda há muitos obstáculos técnicos, clínicos e éticos pela frente, mas a direção é clara. A comunicação entre cérebro e máquina está deixando de ser uma promessa distante para se tornar uma área real de pesquisa aplicada.

No futuro, talvez teclados, telas e comandos de voz não sejam as únicas formas de interação com computadores. Projetos como o Brain2Qwerty indicam que poderemos construir interfaces capazes de compreender intenção, linguagem e pensamento motor de forma cada vez mais direta. O desafio será garantir que essa tecnologia seja desenvolvida com segurança, inclusão e respeito à autonomia humana.

Brain2Qwerty é um lembrete poderoso: a próxima grande revolução da inteligência artificial talvez não esteja apenas em máquinas que falam melhor, mas em sistemas capazes de devolver a voz a quem a perdeu.

Fontes:

https://github.com/facebookresearch/brain2qwerty
https://facebookresearch.github.io/brain2qwerty

We started this Google Summer of Code project with a simple question: can a new openSUSE user get useful, system-specific help without sending their questions or machine information to a cloud service?

The idea was to combine a Small Language Model (SLM) running on the user’s machine with retrieval over official openSUSE documentation. Instead of giving generic Linux advice, the assistant should know that the machine is running Leap, whether it uses Btrfs and Snapper, which GPU is installed, and which services have failed. It should then explain tools such as zypper, YaST, Snapper, and firewalld using the documentation that applies to that system.

At the midterm point, that core loop is working on an openSUSE Leap 16.0 VM. The assistant runs locally, retrieves openSUSE documentation from a local LanceDB index, reads selected host context, and is available through both a command-line interface and a web UI. More importantly, it now runs from an openSUSE BCI-based container built by the Open Build Service (OBS), including on a VM with no outbound internet access.

• Source repository
• GSoC proposal
• Public Leap VM demo
• OBS package

From a Small PoC to a Real Leap Deployment

Before GSoC, the project used TinyLlama, ChromaDB, and a small set of documentation to prove that the basic architecture was possible. That was enough for a demo, but not enough to answer the questions that matter for a distribution feature: Which model works well on CPU-only hardware? How is the assistant installed? What happens when the target machine cannot download a model? Can a container inspect the host without being given unnecessary privileges?

The mentor-provided test VM made these questions concrete. It runs Leap 16.0 with 4 vCPUs and 15 GB of RAM, has no GPU, and cannot access the internet. This is a useful target because it prevents an accidental dependency on cloud APIs or a developer’s already-populated cache.

The current request path is:

1. The user asks a question in the CLI or Gradio web UI.
2. The assistant reads relevant, non-sensitive system facts from the host.
3. MiniLM embeddings retrieve matching chunks from a local LanceDB index.
4. The system prompt combines the question, host context, and retrieved sources.
5. A local GGUF model generates the answer through llama.cpp.
6. The answer includes references to the documentation used.

The index currently contains 1,982 chunks from the Leap Startup and Reference guides, Leap 16.0 release notes, and selected openSUSE wiki SDB pages. The SDB set includes common areas such as repositories, upgrades, audio, and NVIDIA driver and SUSE Prime troubleshooting.

Model Selection Needed Measurement, Not Guesswork

One of the first tasks was replacing TinyLlama with models that could produce reliable administration guidance while still running on ordinary hardware. We added model tiers and benchmarked six GGUF models through the complete RAG and system-context pipeline on the Leap VM.

Each model answered the same eight openSUSE onboarding questions. Generation ran offline on the VM, while judging ran separately against saved answers using Gemini 2.5 Flash-Lite, reference answers, and expected-fact checklists. Separating these steps meant the slow CPU generation did not need to be repeated when the scoring method changed.

The benchmark used the same constrained target as the public deployment: 4 vCPUs, 15 GB of RAM, no GPU, and no network access during generation. Latency below is the average time for one complete answer, including retrieval and the prompt built from the retrieved documentation and host context.

Higher and further left is better. Qwen3-4B achieved the highest judged quality; Gemma 4 E4B is the current default and answered about 30 seconds faster. The orange ring marks the current default.

The results showed that a larger model is not automatically a better default. Qwen3-4B scored slightly higher than Qwen3-8B and answered about 30 seconds faster. Gemma 4 E4B offered a useful latency/quality trade-off and is currently the default standard model following mentor discussion. Qwen3-1.7B remains a practical option for lower-resource machines, while TinyLlama is useful only for smoke tests.

The full methodology and per-model discussion are in the evaluation report.

These timings also changed the web UI. A 70-120 second answer can look like a hung application if the interface says nothing. The UI now identifies the selected tier, explains that the model is loaded on the first question, shows elapsed generation time, and reports missing model or index data more clearly.

Offline Means More Than Running the Model Locally

The largest lesson so far is that local inference and offline installation are two different problems.

Once downloaded, a GGUF model can run without a network connection. A usable assistant, however, also needs the embedding model, Python and native libraries, the documentation index, configuration, and compatible file ownership. The VM’s lack of internet access exposed every hidden download quickly.

To make the state visible, we added suse-assist doctor. It checks model files, the vector store, the embedding cache, memory and disk availability, host mounts, offline environment settings, the web port, and the container runtime. We also added suse-assist setup to select a tier, prepare the model and index, optionally import offline data, and run the final checks.

For machines that cannot download assets during setup, the project now has an offline bundle format:

suse-assist bundle export --output suse-assist-offline-bundle.tar.zst
suse-assist bundle import suse-assist-offline-bundle.tar.zst

A bundle contains a selected GGUF model, the MiniLM cache, the LanceDB index, and a manifest with checksums. The import/export commands and firstboot import path are implemented. Producing a release bundle from the VM data and testing it through a complete OEM first boot is one of the next tasks. The final distribution policy is still open: the data could be part of a KIWI image, an RPM payload, a separate artifact, or a firstboot download for connected systems.

Moving the Build into the openSUSE Infrastructure

The first container image was useful for testing, but it was not built in the same way an openSUSE deliverable should be. The container now starts from the SUSE BCI Python base and uses zypper for system dependencies.

The next issue was dependency availability. OBS builds in a clean, offline build environment, while several parts of the Python ML stack are not currently packaged as openSUSE RPMs. This includes important pieces around llama-cpp-python and LanceDB. To test the rest of the path without waiting for all dependency packaging, we built an OBS prototype with an approximately 467 MB wheelhouse. It installs the Python dependencies with pip --no-index, including a locally built llama-cpp-python wheel.

That experiment now builds the real assistant image in home:anujagrawal:suse-assist/suse-assist-image and publishes it as:

registry.opensuse.org/home/anujagrawal/suse-assist/images/opensuse/suse-assist:latest

The Leap VM cannot pull from the registry, so we tested the actual offline delivery path: download the OBS image archive on a connected machine, checksum it, copy it over SSH, load it with Podman, and run it against the prepared data volume. This found a real ownership mismatch, which was fixed by assigning the container’s suseai user a stable UID and GID of 999. The public demo now runs this OBS-built image rather than the earlier local build.

On that VM, suse-assist doctor, web startup, test-tier inference, and standard Gemma 4 E4B inference have all been exercised. A standard-tier answer to “What is zypper?” took about 70 seconds and included retrieved references.

The vendored wheelhouse proves that OBS can build and publish the container. It is not automatically the final packaging answer. The open question is whether this is acceptable as a short-term container solution or whether each missing dependency should be packaged as a proper RPM before the assistant moves beyond a home project.

Preparing for First Boot and Daily Use

Distribution integration should not require users to know a container command. The repository now includes the first scaffolding for a KIWI OEM image, a Podman Quadlet unit, and a firstboot service that prepares the assistant’s data and starts the web service. There is also a native systemd service setup path for a future RPM install, plus a desktop launcher that opens the local UI.

These pieces define how the assistant could be presented as a normal openSUSE feature, but they are not the same as a completed installer integration. The full KIWI image and offline firstboot flow still need end-to-end validation. Integration with Agama or jeos-firstboot also needs to follow the packaging and data distribution decisions rather than hard-code a temporary deployment method.

We also added an MCP server and client proof of concept. The server exposes system context and documentation search as tools, while the client can connect the assistant to external MCP servers. This is not required for the basic onboarding flow, but it shows that the openSUSE-specific context and retrieval work can be reused by other local applications.

Safety Is Part of the Interface

System administration answers have more impact than ordinary chatbot responses. Retrieved web pages are therefore treated as untrusted context: instructions inside the retrieved text must not override the system prompt. The assistant cleans hidden reasoning markers, asks for documentation references when recommending commands, and adds warnings around destructive operations and repository vendor changes.

The container runtime also uses a non-root user, dropped capabilities, a read-only root filesystem where possible, resource limits, and a health check. Host system context is mounted read-only. These controls do not make generated advice infallible, but they reduce the authority of the process and make risky advice more visible to the user.

What Changed from the Proposal

The original midterm plan placed more emphasis on completing a jeos-firstboot module and systemd socket activation by this point. The core assistant, model tiers, RAG expansion, system-context work, and Agama integration research are in place, but the VM changed the order of the remaining work.

An onboarding assistant that works only after a developer manually populates model and embedding caches is not ready for first boot. We therefore moved some packaging and offline-distribution work forward: the BCI migration, OBS build, registry publication, setup and doctor commands, bundle format, and offline VM validation. The firstboot integration is now being built on top of a deployment path that has actually run on Leap without internet access.

This was a useful correction to the plan. The main difficulty is not writing one more chat interface. It is delivering several gigabytes of model data and a native ML dependency stack through normal distribution infrastructure, then making the result understandable on machines with very different resources.

Plans for the Second Half

The next part of the project will focus on closing that delivery gap:

1. Build a real offline data bundle from the VM and test bundle import through the OEM firstboot path.
2. Settle the short-term OBS dependency approach: vendored wheels or proper RPMs for the missing ML stack.
3. Produce and validate an installable RPM on a clean Leap system.
4. Decide how model weights and the generated documentation index are distributed, including licensing and image-size implications.
5. Complete the KIWI/firstboot path and connect it to the appropriate openSUSE onboarding surface.
6. Continue expanding evaluation coverage for common problems such as codecs, Packman vendor changes, Wi-Fi and Bluetooth, Btrfs snapshot disk usage, and failed systemd services.

OBS images from home projects are already published to registry.opensuse.org, so development can continue in the current home project. An appropriate long-term development project, potentially an AI-assistant or AI-containers namespace, is being discussed with the openSUSE infrastructure team.

The project has reached the point where the assistant itself works. The second half is about making it an openSUSE feature that users can install, start, diagnose, and use offline without knowing how its model and retrieval stack are assembled.

Thanks to my mentors, Rudraksh Karpe and Satyam Soni, and to the openSUSE community members who have provided the Leap VM, documentation pointers, packaging guidance, and feedback on the live demo.

We started this Google Summer of Code project with a simple question: can a new openSUSE user get useful, system-specific help without sending their questions or machine information to a cloud service?

The idea was to combine a Small Language Model (SLM) running on the user’s machine with retrieval over official openSUSE documentation. Instead of giving generic Linux advice, the assistant should know that the machine is running Leap, whether it uses Btrfs and Snapper, which GPU is installed, and which services have failed. It should then explain tools such as zypper, YaST, Snapper, and firewalld using the documentation that applies to that system.

At the midterm point, that core loop is working on an openSUSE Leap 16.0 VM. The assistant runs locally, retrieves openSUSE documentation from a local LanceDB index, reads selected host context, and is available through both a command-line interface and a web UI. More importantly, it now runs from an openSUSE BCI-based container built by the Open Build Service (OBS), including on a VM with no outbound internet access.

• Source repository
• GSoC proposal
• Public Leap VM demo
• OBS package

From a Small PoC to a Real Leap Deployment

Before GSoC, the project used TinyLlama, ChromaDB, and a small set of documentation to prove that the basic architecture was possible. That was enough for a demo, but not enough to answer the questions that matter for a distribution feature: Which model works well on CPU-only hardware? How is the assistant installed? What happens when the target machine cannot download a model? Can a container inspect the host without being given unnecessary privileges?

The mentor-provided test VM made these questions concrete. It runs Leap 16.0 with 4 vCPUs and 15 GB of RAM, has no GPU, and cannot access the internet. This is a useful target because it prevents an accidental dependency on cloud APIs or a developer’s already-populated cache.

The current request path is:

1. The user asks a question in the CLI or Gradio web UI.
2. The assistant reads relevant, non-sensitive system facts from the host.
3. MiniLM embeddings retrieve matching chunks from a local LanceDB index.
4. The system prompt combines the question, host context, and retrieved sources.
5. A local GGUF model generates the answer through llama.cpp.
6. The answer includes references to the documentation used.

The index currently contains 1,982 chunks from the Leap Startup and Reference guides, Leap 16.0 release notes, and selected openSUSE wiki SDB pages. The SDB set includes common areas such as repositories, upgrades, audio, and NVIDIA driver and SUSE Prime troubleshooting.

Model Selection Needed Measurement, Not Guesswork

One of the first tasks was replacing TinyLlama with models that could produce reliable administration guidance while still running on ordinary hardware. We added model tiers and benchmarked six GGUF models through the complete RAG and system-context pipeline on the Leap VM.

Each model answered the same eight openSUSE onboarding questions. Generation ran offline on the VM, while judging ran separately against saved answers using Gemini 2.5 Flash-Lite, reference answers, and expected-fact checklists. Separating these steps meant the slow CPU generation did not need to be repeated when the scoring method changed.

The benchmark used the same constrained target as the public deployment: 4 vCPUs, 15 GB of RAM, no GPU, and no network access during generation. Latency below is the average time for one complete answer, including retrieval and the prompt built from the retrieved documentation and host context.

[

Higher and further left is better. Qwen3-4B achieved the highest judged quality; Gemma 4 E4B is the current default and answered about 30 seconds faster. The orange ring marks the current default.

The results showed that a larger model is not automatically a better default. Qwen3-4B scored slightly higher than Qwen3-8B and answered about 30 seconds faster. Gemma 4 E4B offered a useful latency/quality trade-off and is currently the default standard model following mentor discussion. Qwen3-1.7B remains a practical option for lower-resource machines, while TinyLlama is useful only for smoke tests.

The full methodology and per-model discussion are in the evaluation report.

These timings also changed the web UI. A 70-120 second answer can look like a hung application if the interface says nothing. The UI now identifies the selected tier, explains that the model is loaded on the first question, shows elapsed generation time, and reports missing model or index data more clearly.

Offline Means More Than Running the Model Locally

The largest lesson so far is that local inference and offline installation are two different problems.

Once downloaded, a GGUF model can run without a network connection. A usable assistant, however, also needs the embedding model, Python and native libraries, the documentation index, configuration, and compatible file ownership. The VM’s lack of internet access exposed every hidden download quickly.

To make the state visible, we added suse-assist doctor. It checks model files, the vector store, the embedding cache, memory and disk availability, host mounts, offline environment settings, the web port, and the container runtime. We also added suse-assist setup to select a tier, prepare the model and index, optionally import offline data, and run the final checks.

For machines that cannot download assets during setup, the project now has an offline bundle format:

suse-assist bundle export --output suse-assist-offline-bundle.tar.zst
suse-assist bundle import suse-assist-offline-bundle.tar.zst

A bundle contains a selected GGUF model, the MiniLM cache, the LanceDB index, and a manifest with checksums. The import/export commands and firstboot import path are implemented. Producing a release bundle from the VM data and testing it through a complete OEM first boot is one of the next tasks. The final distribution policy is still open: the data could be part of a KIWI image, an RPM payload, a separate artifact, or a firstboot download for connected systems.

Moving the Build into the openSUSE Infrastructure

The first container image was useful for testing, but it was not built in the same way an openSUSE deliverable should be. The container now starts from the SUSE BCI Python base and uses zypper for system dependencies.

The next issue was dependency availability. OBS builds in a clean, offline build environment, while several parts of the Python ML stack are not currently packaged as openSUSE RPMs. This includes important pieces around llama-cpp-python and LanceDB. To test the rest of the path without waiting for all dependency packaging, we built an OBS prototype with an approximately 467 MB wheelhouse. It installs the Python dependencies with pip --no-index, including a locally built llama-cpp-python wheel.

That experiment now builds the real assistant image in home:anujagrawal:suse-assist/suse-assist-image and publishes it as:

registry.opensuse.org/home/anujagrawal/suse-assist/images/opensuse/suse-assist:latest

The Leap VM cannot pull from the registry, so we tested the actual offline delivery path: download the OBS image archive on a connected machine, checksum it, copy it over SSH, load it with Podman, and run it against the prepared data volume. This found a real ownership mismatch, which was fixed by assigning the container’s suseai user a stable UID and GID of 999. The public demo now runs this OBS-built image rather than the earlier local build.

On that VM, suse-assist doctor, web startup, test-tier inference, and standard Gemma 4 E4B inference have all been exercised. A standard-tier answer to “What is zypper?” took about 70 seconds and included retrieved references.

The vendored wheelhouse proves that OBS can build and publish the container. It is not automatically the final packaging answer. The open question is whether this is acceptable as a short-term container solution or whether each missing dependency should be packaged as a proper RPM before the assistant moves beyond a home project.

Preparing for First Boot and Daily Use

Distribution integration should not require users to know a container command. The repository now includes the first scaffolding for a KIWI OEM image, a Podman Quadlet unit, and a firstboot service that prepares the assistant’s data and starts the web service. There is also a native systemd service setup path for a future RPM install, plus a desktop launcher that opens the local UI.

These pieces define how the assistant could be presented as a normal openSUSE feature, but they are not the same as a completed installer integration. The full KIWI image and offline firstboot flow still need end-to-end validation. Integration with Agama or jeos-firstboot also needs to follow the packaging and data distribution decisions rather than hard-code a temporary deployment method.

We also added an MCP server and client proof of concept. The server exposes system context and documentation search as tools, while the client can connect the assistant to external MCP servers. This is not required for the basic onboarding flow, but it shows that the openSUSE-specific context and retrieval work can be reused by other local applications.

Safety Is Part of the Interface

System administration answers have more impact than ordinary chatbot responses. Retrieved web pages are therefore treated as untrusted context: instructions inside the retrieved text must not override the system prompt. The assistant cleans hidden reasoning markers, asks for documentation references when recommending commands, and adds warnings around destructive operations and repository vendor changes.

The container runtime also uses a non-root user, dropped capabilities, a read-only root filesystem where possible, resource limits, and a health check. Host system context is mounted read-only. These controls do not make generated advice infallible, but they reduce the authority of the process and make risky advice more visible to the user.

What Changed from the Proposal

The original midterm plan placed more emphasis on completing a jeos-firstboot module and systemd socket activation by this point. The core assistant, model tiers, RAG expansion, system-context work, and Agama integration research are in place, but the VM changed the order of the remaining work.

An onboarding assistant that works only after a developer manually populates model and embedding caches is not ready for first boot. We therefore moved some packaging and offline-distribution work forward: the BCI migration, OBS build, registry publication, setup and doctor commands, bundle format, and offline VM validation. The firstboot integration is now being built on top of a deployment path that has actually run on Leap without internet access.

This was a useful correction to the plan. The main difficulty is not writing one more chat interface. It is delivering several gigabytes of model data and a native ML dependency stack through normal distribution infrastructure, then making the result understandable on machines with very different resources.

Plans for the Second Half

The next part of the project will focus on closing that delivery gap:

1. Build a real offline data bundle from the VM and test bundle import through the OEM firstboot path.
2. Settle the short-term OBS dependency approach: vendored wheels or proper RPMs for the missing ML stack.
3. Produce and validate an installable RPM on a clean Leap system.
4. Decide how model weights and the generated documentation index are distributed, including licensing and image-size implications.
5. Complete the KIWI/firstboot path and connect it to the appropriate openSUSE onboarding surface.
6. Continue expanding evaluation coverage for common problems such as codecs, Packman vendor changes, Wi-Fi and Bluetooth, Btrfs snapshot disk usage, and failed systemd services.

OBS images from home projects are already published to registry.opensuse.org, so development can continue in the current home project. An appropriate long-term development project, potentially an AI-assistant or AI-containers namespace, is being discussed with the openSUSE infrastructure team.

The project has reached the point where the assistant itself works. The second half is about making it an openSUSE feature that users can install, start, diagnose, and use offline without knowing how its model and retrieval stack are assembled.

Thanks to my mentors, Rudraksh Karpe and Satyam Soni, and to the openSUSE community members who have provided the Leap VM, documentation pointers, packaging guidance, and feedback on the live demo.

Es muy complicado guiar un proyecto de Software Libre ya que gran parte de su desarrollo es voluntario y las personas que lo suelen hacer no están obligadas a hacer lo que no quieren hacer (esto ha sonado un poco extraño pero creo que me entendéis). De esta forma, y para solucionar este problema, la Comunidad KDE lleva ya cuatro ciclos marcándose objetivos comunes consensuados que marcan el rumbo del proyecto. Ha llegado el tiempo de renovarlos, así que me complace anunciar que KDE busca sus próximas metas y que ha abierto el plazo para diseñar el futuro del proyecto. Si crees que KDE debe seguir una senda determinada este es el momento de proponerlo.

KDE busca sus próximas metas: Se abre el plazo para diseñar el futuro del proyecto

Esta forma de marcar las líneas preferenciales de desarrollo se inició en el 2017, en el que se marcaron aumentar el número de contribuyentes al proyecto, mejorar la privacidad de KDE y pulir la usabilidad.

Durante tres años se trabajó especialmente con esos objetivos y fue en el primer día de la Akademy de 2019 en Milán donde se hizo público los nuevos objetivos KDE: Aplicaciones portables, Consistencia y Adopción de Wayland.

Con mayor o menor logro en 2022 llegó la hora de dar un nuevo impulso y proceder a explorar nuevas formas de hacer evolucionar el proyecto con nuevos objetivos: Automatización, Sostenibilidad (KDE Eco) y Accesibilidad.

Y en 2024 se repitió la historia y se decidió que en los siguientes años se trabajaría para simplificar el desarrollo de aplicaciones, mejorar la interacción con dispositivos y búsqueda nuevos colaboradores

Una vez pasado ya 2 años desde los últimos objetivos el órgano de gobierno de KDE, que se llama KDE e.V., ha decidido que es el momento de seguir avanzando ya que piensan que los anteriores están más o menos alcanzado. De esta forma desde el mes de junio está pidiendo a los miembros de la Comunidad que propongan al resto cuáles son los objetivos que creen más importantes para el desarrollo del Proyecto.

Hay que puntualizar que estos objetivos no significan que los desarrolladores se centren solo en ellos, pero si que estarán dentro de todas las mentes pensantes del proyecto con lo que se espera dar un gran salto respecto a ellos

Posteriormente, se realizará una votación y se seleccionan los 3 objetivos principales que los desarrolladores deberían tener en mente cuando estén desarrollando el Proyecto KDE.

Para presentar una nueva propuesta de objetivos, puedes utilizar el tablero de trabajo dedicado y dar forma a la futura dirección de la comunidad KDE.

Cronograma / Calendario

• Presentación de propuestas: Del 20 de junio al 8 de agosto
• Refinamiento de las propuestas: Del 9 al 27 de agosto
• Periodo de votación: Del 28 de agosto al 11 de septiembre
• Recuento y preparación: Del 12 al 18 de septiembre
• Anuncio en Akademy: 19 de septiembre

Más información: KDE

La entrada KDE busca sus próximas metas: Se abre el plazo para diseñar el futuro del proyecto se publicó primero en KDE Blog.

El pasado 16 de junio fue lanzado Plasma 6.7. Es hora de empezar las obligatorias entradas para recopilar cuáles han sido las buenas nuevas que nos ofrece esta nueva iteración de nuestro entorno de trabajo favorito. Y empezamos con las novedades en los plasmoides en Plasma 6.7, esas pequeñas aplicaciones que hacen más productivo y funcional nuestro escritorio.

Las novedades en los plasmoides en Plasma 6.7

Una de los complemente que me apasionan del entorno de trabajo Plasma de la Comunidad KDE son los plasmoides o widgets, unas pequeñas aplicaciones que ponemos en nuestro escritorio o en nuestras barras de tareas que nos proporcionan información, efectos visuales o funcionalidades extras muy a mano o golpe de click.

Entre ellas nos encontramos desde relojes con información meteorológica a calendarios, pasando a pelotas que dan botes por nuestro fondo de pantalla o selectores de colores que hacen más fácil el diseño de todo tipo de proyectos.

Para este Plasma 6.7 las novedades fundamentales que nos ofrecen los desarrolladores son las siguientes:

• Posibilidad de cambiar entre los modos claro y oscuro directamente desde el plasmoide «Luminosidad y color»
• «Aplicaciones en segundo plano» en la Bandeja del sistema, una forma más de tener control sobre tu sistema.

Y, además, se ha añadido el calendario lunar vietnamita porque ya sabemos que el software KDE es para todo el mundo.

Las novedades generales de Plasma 6.7

Aprovecho para realizar un listado de las novedades generales de Plasma 6.7:

• Escritorios virtuales por pantalla: Ahora es posible configurar escritorios virtuales de forma independiente para cada monitor.
• Prueba del volumen del micrófono: Se ha añadido una herramienta para comprobar los niveles de entrada de audio, facilitando el diagnóstico de problemas con el micrófono.
• Caracteres especiales en teclado virtual: Al usar el teclado virtual, es posible mantener pulsada una tecla para acceder a los caracteres especiales asociados a ella.
• Interruptor rápido de temas: Se incluye un nuevo control para cambiar instantáneamente entre los temas globales claros y oscuros.
• Calendario lunar vietnamita: Se ha integrado este calendario en el sistema para permitir su uso junto al gregoriano.
• Mejora en «Aplicaciones en segundo plano»: La bandeja del sistema ahora muestra también las aplicaciones que utilizan el sistema de segundo plano moderno, frecuente en paquetes Flatpak.
• Monitorización de impresión: El icono de la bandeja del sistema para impresoras ahora muestra una placa indicando el número de trabajos activos.
• Gestión de colas de impresión: Se ha introducido una nueva herramienta para gestionar colas de impresión, diseñada tanto para un uso doméstico sencillo como para la gestión avanzada de múltiples impresoras.
• Acceso rápido a escritorios en Vista general: Desde la Vista general (Meta + W), ahora es posible cambiar entre escritorios virtuales usando el ratón o las teclas RePág y AvPág.
• Favoritos por arrastrar y soltar: Se ha simplificado la gestión de favoritos en los lanzadores y menús de aplicaciones mediante la función de arrastrar y soltar.

Más información: KDE

La entrada Las novedades en los plasmoides en Plasma 6.7 se publicó primero en KDE Blog.

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 estas semanas.

Y recuerda que puedes estar al tanto de las nuevas publicaciones de snapshots en esta web:

• https://victorhck.gitlab.io/tumbleweed_snapshots/

El anuncio original lo puedes leer en el blog de Dominique Leuenberger, publicado bajo licencia CC-by-sa, en este este enlace:

• https://dominique.leuenberger.net/blog/2026/06/tumbleweed-review-of-the-weeks-2026-25-26/

Estas 2 semanas se han publicado 11 Snapshots (0611, 0612, 0613, 0615, 0616, 0617, 0618, 0619, 0622, 0623, y 0625).

Estos son los cambios más relevantes:

• GraphicsMagick 1.3.47
• fwupd 2.1.5
• Linux kernel 7.0.12
• MariaDB 12.3.2
• GCC 15.3.0
• GStreamer 1.28.4
• VirtualBox 7.2.8 & 7.2.10
• KDE Frameworks 6.27.0
• AppArmof 5.0.1
• LLVM 22.1.7
• KDE Plasma 6.7.0 & 6.7.1
• Mozilla Firefox 152.0 & 152.0.1 & 152.0.2
• Poppler 26.06.0
• Mesa 26.1.3
• FFmpeg 8.1.2
• Pipewire 1.6.7
• Bash 5.3.15
• NetworkManager 1.56.1

Y para próximas snapshots, ya se están preparando las siguientes actualizaciones:

• libzio 1.15
• Agama: El equipo intentará introducir cambios semanales en Factory. Ya sabes, ¡Release soon, Release often! Así que ahora son más que bienvenidos los reportes de errores.
• Qemu 11.0.0: Se eliminó la compatibilidad con host de 32 bits.
• curl 8.21.0:
• Linux kernel 7.1
• Linux kernel 7.1 headers
• systemd

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

——————————–