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:

• 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-week-2026-23/

Esta semana se han publicado 6 Snapshots  (0529, 0530, 0531, 0601, 0602 y 0603).

Estos son los cambios más relevantes:

• Mesa 26.1.1
• Mariadb 11.8.7 & 11.8.8
• Qt 6.11.1
• Pipewire 1.6.6
• Samba 4.23.8 & 4.24.3
• GNOME 50.2
• util-linux 2.42.1
• gpgme 2.1.0
• libvirt 12.4.0

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

• Mesa 26.1.2
• Linux kernel 7.0.11
• harfbuzz 14.2.1
• php 8.5.7
• KDE Gear 26.04.2
• KDE Plasma 6.7.0
• GCC 16

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

——————————–

Dear Tumbleweed users and hackers,

Another rather uneventful week over here in Europe: another holiday in the middle of the week (for some regions, not all of Europe). The openSUSE community, in its international form, is usually not significantly affected by such interruptions and keeps rolling. That’s exactly what was observed this week as well: 6 snapshots (0529, 0530, 0531, 0601, 0602, and 0603) have been published over the last week.

The main updates contained therein were:

• Mesa 26.1.1
• Mariadb 11.8.7 & 11.8.8
• Qt 6.11.1
• Pipewire 1.6.6
• Samba 4.23.8 & 4.24.3
• GNOME 50.2
• util-linux 2.42.1
• gpgme 2.1.0
• java packaging change: migrated from update-alternative to libalternatives
• libvirt 12.4.0

The future is bright, and looking into my crystal ball (or on the staging dashboard) helps me to predict these changes coming to you soon:

• Mesa 26.1.2
• Linux kernel 7.0.11
• harfbuzz 14.2.1
• php 8.5.7
• KDE Gear 26.04.2
• KDE Plasma 6.7.0, currently 6.6.91 staged for QA
• Rework of Python3 packaging (as a meta package instead of a provides of the default interpreter)
• gcc 16 as the system default compiler

Do not let the AI to remove the fun part from software development. We shouldn't allow gen AI to write software just because it "can". First, we must ask if it "should" do it, and even then, we should ask if we want to delegate the fun part, the thinking, the writing, the learning.

Remember what's important, journey before destination, we are the Code:

Do not let AI to destroy the community, do not let it destroy the technological knowledge commons.

tl;dr

Open Source maintainers are dealing with a lot of new reports and pressure to "fix" the project due to generative AI.

We need to find a way of stopping this and get back to something maintainable before all maintainers get burned out and look for a job in a farm:

• 100% secure software doesn't exists, so there will be always a possible CVE there. As Spaf said in 1989:

The only truly secure system is one that is powered off, cast in a block of concrete and sealed in a lead-lined room with armed guards - and even then I have my doubts.

• Fixing bugs, adds new bugs, and if you need to fix something quick, the probability of new bugs will be higher. Do not forget about the First Law of Programming:

If it works, don't touch it

• The amount of CVE reports is lowering the CVE credibility and quality, so if everything is a "high" security issue, we can't prioritize now and these reports are not different from random issues in github. Do not listen to The Boy Who Cried Wolf

• Stable software is sable because it doesn't change too much. It's something that we are willing to loose trying to reach the impossible of 100% secure software?

The actual problem

There's a lot of money in AI tech right now, and everyone is trying to make the best gen AI tool or just pretend that their tool is the best.

In relation with the software analysis and writing, targeting the open source is the obvious strategy.

1. It's interesting to scrap every line of code, patch, pull request, issue and discussion around software to train your model, so AI scrappers are DDoSing open source projects infrastructure.

2. To promote their tools or themselves, Security Researches are using AI to target any project, reporting High security vulnerabilities, with the only goal of getting a CVE number to say how good they are.

This second point is affecting maintainers, because now you are receiving a lot of poor quality security reports, that are generated with AI and that looks plausible and are hard to read. You need to spend a lot of time to check if there's an actual wolf there or if it's again this boy that's tricking me.

This is burning the energy of maintainers, that instead of doing something productive are wasting their limited time talking with a Stocatic Parrot.

Do not let the AI Bros to use classic manipulation techniques on you!

A lot of open source projects are maintained by volunteers that do the work with passion and love. And even if it's the job that paid your bills, the maintainer can feel the pressure. When someone put a lot of love in something and work on it during years, it's part of his identity, so attacking the software is like attacking the person behind it.

This is nothing new, and a lot of people take advantage of this emotional link to manipulate the maintainer to do something that he do not want to do.

AI bros are using these techniques, do not let them to manipulate you and define your project agenda.

Here's a (not complete) list of known manipulation techniques that you can detect (and disarm!) in your daily community work:

• Flooding the queue. Just create so many new issues that the actual maintainers can't deal with it. You feel responsible for the project and feel bad because your TO-DO list is growing.

• This software is not secure (doesn't do what I want), I will use this other one instead that's better. The classic, "GNOME doesn't allow me to change this specific preference, I'll use KDE from now on".

• This software is low quality, it doesn't follow the (my random) quality standards. Direct attack to the maintainer self-esteem.

• Gaslighting software development. LLM are expert at this and people that uses it just copy the tactic. When the maintainer detects something weird and just tries to blame the other person for reporting nonsense and wasting all people time, it starts to invent new arguments and ignore the previous interaction.

So, take it easy, and remember the best clause in almost any software project, THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU:

Disclaimer of Warranty.

THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT
WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND
PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE
DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR
CORRECTION.

Is the software more insecure in 2026?

No. Anyone old enough could remember how insecure old software was. Do you remember windows 98? Do you remember the internet when everything was http (without that little s at the end), when people use ftp to logging into their server and modify the php code directly on production?

It's true that today we have more dependency on technology, but it's also true that everything is more secure, we have more and better cryptography, we have different levels of isolation, virtual environments, containers, virtual machines...

But we have the feeling that since AI can analyse all the software and look for vulnerabilities, we are doomed, because any stupid kid can hack my over engineered GNU/Linux machine!

First, that's not true, you need to know about security to get something useful from any AI tool. But even if it was true, what can you do about it? We need to be practical and find a balance between risk and usefulness, so do not overestimate the risk just because everyone is talking about it right now.

But even then, the security paranoia is not good for anyone. Software is inherently buggy, people write software and makes mistakes, so a possible vulnerability appears. In theory, these bugs are fixed when discovered, so it's always recommended to update to the latest version, because almost all known bugs will be fixed.

But it's also known that new versions comes with new functionality and code, and that means new "unknown" bugs or different behavior. That's a headache, so that's why the stable and Long Term Support are popular distributions, because "if it works, don't touch it".

Stable packages just get the fixes, not new features, but fixes are also code changes, so there's always a possibility to break something, even with a patch update.

The stable software has a lot of value, do not let the AI security paranoia destroy that, and convert everything in a rolling release with the latest and greatest (and possibly broken) software. Sometimes it's better to keep using something old, with known vulnerabilities that you can mitigate, than use the latest with unknown new vulnerabilities that you can't do anything about.

I will fight AI with AI

Please, do not do that. What I was trying to argue during this long post is not a technical problem. The current burnout problem in open source is a social problem, you can't fix it with a new layer of probabilistic tokens.

• Community reaction against AI. The current industry push for the usage of AI everywhere is affecting a lot of people, and as a reaction a lot of people are directly fighting back. Using gen AI just sends the message that you do not care enough to do it yourself, and destroy the trust on the project.

• It doesn't worth it. Even if the AI works (that it doesn't) it doesn't worth it. Writing code is easier than reviewing, you learn and grow with every new line of code that you write, delegating the fun part and personal growth part to an AI will make you work more miserable and you will be a junior forever.

• It doesn't create community. Think about it, it's hard to get someone involved in a software project, but who will want to read or improve the code produced by a gen AI? The only future collaborator will be another AI.

Take it easy

Just remember, you can always say no, there's no hurry, and there's no need to work on something that you don't want just because other people consider that important.

Free Source is something done by people, for people. The software is important, but the community around it is sometimes more important. We use Free source not because it's technically better (that it is), but because we trust who, how and why are writing it.

Remember why are you doing this, do not remove the Fun part, continue with the Just for Fun mood.

La Comunidad KDE es una comunidad responsable y no solo se preocupa en lanzar novedades sino que también en mejorarlas. Me complace presentar, un poco tarde, la segunda actualización de KDE Gear 26.04 que apareció hace casi dos meses. Más estabilidad, mejores traducciones y pequeñas mejoras para las aplicaciones de nuestro entornos de trabajo.

Segunda actualización de KDE Gear 26.04

A pesar de lo que puedan pensar muchas personas, las aplicaciones no son perfectas. Entre las líneas de código se pueden colar errores de tipografía o que el usuario realice alguna opción que en un principio no estaba prevista por los desarrollador, por poner solo un par de ejemplos de imperfecciones.

Este no es un problema del Software Libre ya que el Software actual funciona de esta manera ya que no se piensa en él como un producto final que se encierra en una caja y se olvida. En la actualidad se sabe que el Software está vivo y sería estúpido ir guardando las mejoras sin dejarlas a disposición del gran público.

Con esto se gana en rapidez y evolución pero puede aumentar el número de errores (por norma general) leves, los cuales son subsanables con pequeñas actualizaciones.

La Comunidad KDE lo tiene claro: grandes lanzamientos cada cuatro meses y actualizaciones mensuales para subsanar errores.

Por ello me congratula compartir con vosotros la segunda actualización de KDE Gear 26.04 que nos ofrece un buen número de errores resueltos entre aplicaciones, librerías y widgets, algo que mejora el rendimiento del sistema.

Aquí podéis encontrar la lista completa de cambios de KDE Gear 26.04.2, pero por poner unos cuantos ejemplos de los errores que sea han resuelto tenemos:

• akregator: Se ha corregido un fallo al ejecutarse en arm64. (Código modificado).
• ksanecore: Se ha corregido un fallo durante el arranque de skanlite. (Código modificado, corrige el fallo #517465).
• koko: Se ha corregido el fallo de la acción de mover a la papelera que anulaba las acciones de borrado del editor. (Código modificado, corrige el fallo #519784).

Más información: KDE Gear 26.04.2

La entrada Segunda actualización de KDE Gear 26.04 se publicó primero en KDE Blog.

Every time a piece of software encounters a new access pattern, the answer is to tweak the policy. Then tweak it again. Then tweak it again. Then tweak it again. Then tweak it again. At what point does this stop being a security model and start becoming an endless process of granting exceptions?

There is one thing in open source software that consistently consumes more time than it has any right to.

SELinux.

Every few weeks it seems like another SELinux issue appears.

Implementing a new feature? Fix SELinux. Fixing a bug? Fix SELinux. Scratching your butt? Gotta fix your SELinux policy. Repeat forever.

At some point we should start asking the question: What exactly is this accomplishing?

The Concept

The idea is straightforward. If an attacker compromises a process, SELinux limits what that process can access. The attacker is confined to a security domain and prevented from reaching resources outside that domain.

That’s a reasonable goal.

I’m not arguing against the idea of mandatory access control. I’m questioning whether this was the right tradeoff.

The Cost of Convergence

If a piece of software has been around for twenty years, and enough users have run into enough denials, and enough maintainers have added enough exceptions, then sure, maybe the policy eventually becomes stable.

But what a ridiculous way to get there.

The model seems to be: run the software, wait for SELinux to break something, examine the denial, add a rule, repeat until users stop complaining.

That’s not design. That’s playing whac-a-mole.

We’re not thoughtfully defining a security model. We’re painfully discovering the application’s behavior by tripping over every possible thing it might need to do.

An Engineering Failure

SELinux asks us to accept that defining a security model requires years of stumbling over ourselves. I have a hard time believing that’s the best we can come up with.

Surely there must be a middle ground somewhere between “the application can do anything it wants” and “the application can’t do anything until we’ve spent the next several years teaching SELinux how it works.”

At some point we should be willing to ask whether there is a better way to solve this problem.

I don’t have the answer.

But I’m no longer satisfied with pretending that SELinux is the answer.

OpenSSL 4.0 was released just over a month ago. So, how is its support progressing in syslog-ng? Well, Git master already supports it, and the patch is easy to backport to earlier releases. At the same time, version 4.12 will support OpenSSL 4.0 out of the box.

A month ago, someone from Gentoo Linux reached out to the syslog-ng team about OpenSSL 4.0 support. I asked the community about their expectations, knowing that version 4.0 is not an LTS version. However, I quickly learned that all major distros were preparing to use it in their rolling development versions. A few days later, we also received hints on how to add support for it in syslog-ng. And thus, a PR was born, which is now merged into syslog-ng git master.

What does this mean for you?

• If you need OpenSSL 4.0 support RIGHT NOW using a RELEASED syslog-ng version, then use syslog-ng 4.11 and the related pull request from https://github.com/syslog-ng/syslog-ng/pull/5688
• Use the latest syslog-ng git snapshot, as the above PR is already merged.
• Wait a few more weeks, as syslog-ng 4.12 will be released soon with OpenSSL 4.0 support.

Originally published at https://www.syslog-ng.com/community/b/blog/posts/the-status-of-openssl-4-0-support-in-syslog-ng

Tras un parón debido al salto de Qt5/KF5 a Qt6/KF6 que realizó la Comunidad KDE hace ya más de año y medio. Es por ello que decidí retomar esta sección aunque renombrándola ya que en ella solo hablaría de Plasmoides para Plasma 6. Así que hoy os presento uno que coloca el sistema solar en tu escritorio. Se trata de Celestial Sky, el plasmoide número 31 de la serie, que desde el punto de vista terrestre nos muestra la posición del Sol y los planetas. Espero que os guste.

El sistema solar en tu escritorio con Celestial Sky- Plasmoides para Plasma 6 (31)

Como he comentado en otras ocasiones, de plasmoides tenemos de todo tipo funcionales, de configuración, de comportamiento, de decoración o, como no podía ser de otra forma, de información sobre nuestro sistema como puede ser el uso de disco duro, o de memoria RAM, la temperatura o la carga de uso de nuestras CPUs.

Así que espero que le deis la bienvenida a Celestial Sky, una creación de Tmate que lo describe como:

Un widget de KDE Plasma 6 que muestra las posiciones actuales de los cuerpos del sistema solar a lo largo del arco celeste, con horas precisas de salida y puesta y un control deslizante de tiempo para previsualizar posiciones pasadas y futuras.

En desarrollo: este widget aún es experimental y se encuentra en fase de pruebas activas. Es posible que haya errores y cambios importantes.

Este plasmoide se debe configura para poner el horizonte alineado con nuestra longitud y latitud, la cual podéis buscar en latitude.to. Además, podemos personalizar el tamaño de los planetas y la opacidad del fondo. No es mucho pero como dice su creador, esta es una primera versión.

Y como siempre digo, si os gusta el plasmoide podéis «pagarlo» de muchas formas en la página de KDE Store, que estoy seguro que el desarrollador lo agradecerá: puntúale positivamente, hazle un comentario en la página o realiza una donación. Ayudar al desarrollo del Software Libre también se hace simplemente dando las gracias, ayuda mucho más de lo que os podéis imaginar, recordad la campaña I love Free Software Day de la Free Software Foundation donde se nos recordaba esta forma tan sencilla de colaborar con el gran proyecto del Software Libre y que en el blog dedicamos un artículo.

Más información: KDE Store

¿Qué son los plasmoides?

Para los no iniciados en el blog, quizás la palabra plasmoide le suene un poco rara pero no es mas que el nombre que reciben los widgets para el escritorio Plasma de KDE.

En otras palabras, los plasmoides no son más que pequeñas aplicaciones que puestas sobre el escritorio o sobre una de las barras de tareas del mismo aumentan las funcionalidades del mismo o simplemente lo decoran.

Aquí bajo os muestro los últimos publicados en el blog:

• 
  El sistema solar en tu escritorio con Celestial Sky- Plasmoides para Plasma 6 (31)
  Calendario original para tu escritorio, Almanac Asimetric – Plasmoides para Plasma 6 (2)
• 
  Reloj de interfaz múltiple para tu escritorio con Manalog Clock- Plasmoides para Plasma 6 (30)
  Calendario original para tu escritorio, Almanac Asimetric – Plasmoides para Plasma 6 (2)
• 
  Reloj original para tu escritorio con Scrolling Clock- Plasmoides para Plasma 6 (29)
  Calendario original para tu escritorio, Almanac Asimetric – Plasmoides para Plasma 6 (2)
• 
  Visualiza la letra de las canciones con Plasma Lyrics – Plasmoides para Plasma 6 (28)
  Calendario original para tu escritorio, Almanac Asimetric – Plasmoides para Plasma 6 (2)
• 
  Ordena archivos de forma automática con Magic Folder – Plasmoides para Plasma 6 (27)
  Calendario original para tu escritorio, Almanac Asimetric – Plasmoides para Plasma 6 (2)
• 
  Visor meteorológico Aero Weather – Plasmoides para Plasma 6 (26)
  Calendario original para tu escritorio, Almanac Asimetric – Plasmoides para Plasma 6 (2)
• 
  Controla tu batería en Plasma con Battery Plasmoid Boero – Plasmoides para Plasma 6 (27)
  Calendario original para tu escritorio, Almanac Asimetric – Plasmoides para Plasma 6 (2)
• 
  Lanzador estilo MacOS para KDE Plasma: Tahoe Launcher – Plasmoides para Plasma 6 (25)
  Calendario original para tu escritorio, Almanac Asimetric – Plasmoides para Plasma 6 (2)
• 
  Mejoras en el nuevo Bouncy Ball de Plasma 6
  Calendario original para tu escritorio, Almanac Asimetric – Plasmoides para Plasma 6 (2)

La entrada El sistema solar en tu escritorio con Celestial Sky- Plasmoides para Plasma 6 (31) se publicó primero en KDE Blog.

The Travel Support Program (TSP), which is aided through donations to the Geeko Foundation, is now accepting applications for the openSUSE.Asia Summit 2026.

Funds are allocated by the foundation specifically for travel assistance for speakers attending the event.

Applications for the TSP are open now and will run until July 31, which will follow an announcement related the Call for Papers.

People whose talks are accepted can submit a request at tsp.opensuse.org.

The TSP exists to ensure financial constraints don’t prevent passionate contributors and community members from participating.

The openSUSE.Asia Summit 2026 organizers of the summit encourage you to apply early.

For questions about the TSP process, visit the wiki for more information and read the Geeko Foundation’s travel policy.

Further details will be shared later about the event planning, so please pay attention to announcements for the summit.

We look forward to seeing you there!

For more details on openSUSE.Asia Summit 2026, visit events.opensuse.org.

La evolución de software es imparable, aunque no nos acabe de gustar y estemos siempre luchando contra la obsolescencia. Lamentablemente, los recursos de las Comunidades del Software Libre son limitados y no hay gente para todo. Así que con una mezcla de pena y resignación os comento que KDE Plasma dice adiós a X11, una decisión meditada y basada en números. Como todo el mundo ya sabía, el futuro es Wayland y es hora de dedicar todos los esfuerzos a sacarle el máximo rendimiento.

KDE Plasma dice adiós a X11: el futuro es Wayland

Lo podemos leer en el blog de David Edmundson en el que se anuncia que a partir de plasma 6.8 (cuyo lanzamiento está previsto en unos cinco meses), ya no existirá la opción de iniciar sesión en X11.

De esta forma, y en aras de depurar código, los desarrolladores comenzarán una limpieza masiva de todo el código específico de X11 en Plasma Shell, la configuración del sistema y la configuración de dispositivos.

No obstante, eso no significa que la tecnología X11 desaparece por completo ya que se mantendrán aspectos como:

• XWayland: que seguirá presente, por lo que las aplicaciones antiguas de X11 seguirán funcionando correctamente dentro de la sesión de Wayland.
• Aplicaciones KDE: que también seguirán funcionando en entornos de escritorio basados en X11 sin problemas.
• Gestor de inicio (Login Manager): que permitirá seguir iniciando sesiones X11 de otros entornos de escritorio.

Las motivaciones que expone David son las esperadas: el mantenimiento de dos rutas de código paralelas (ya que ahora X11 no interaccionará para nada con Plasma, haciéndolo solo vía XWayland) permitirá al equipo enfocarse exclusivamente en Wayland, facilitando mejoras de rendimiento, optimizaciones de memoria y la implementación de nuevas funcionalidades.

Y, como decía al inicio, esta decisión viene por los número. Las métricas internas de KDE muestran que más del 95% de los usuarios de Plasma 6.6 ya utilizan Wayland, y que el desarrollo activo sobre X11 por parte de los contribuidores era prácticamente inexistente.

Para finalizar un detalle importante: Plasma 6.7 es la última versión que incluirá X11 y, por tanto, David anima a los usuarios que todavía necesiten X11 por algún motivo específico a informar de sus problemas ahora, para que el equipo pueda conocer los puntos de fricción antes del lanzamiento de la versión 6.8.

En fin, tarde o temprano tenía que llegar, así que muchas gracias a X11 por los servicios prestados y…

¡Larga vida a Wayland!

La entrada KDE Plasma dice adiós a X11: el futuro es Wayland se publicó primero en KDE Blog.

Not the best film ever, but in today's Hollywood landscape it's a rare breath of fresh air. Kane Parsons takes the internet meme concept he started on YouTube and actually makes a feature-length film that's doing great at the box office.

The mood is great. That unsettling stillness of these generic liminal spaces. For something that builds a feeling / mood, the flick would benefit from a butcher in the editing room. I'd probably still not give it the extra star, but this really isn't the kind of movie that needs the extra 20 minutes.

Biggest entertainment was definitely watching my son freak out in the third act. :)

★★★★☆