Table of Contents

• 1) Introduction
• 2) Overview of the D-Bus Service
• 3) Security Issues
  • 3.1) Lack of Client Authorization
  • 3.2 Missing Input Parameter Verification
  • 3.3) Unsafe umask used in Daemonize Code
• 4) Upstream Bugfixes
• 5) CVE Assignment
• 6) Coordinated Disclosure
• 7) Timeline
• 8) References

1) Introduction

Foomuuri is an nftables-based firewall manager for Linux. The project includes a D-Bus daemon which offers an API similar to firewalld. In early December an openSUSE community member asked us to review Foomuuri for addition to openSUSE Tumbleweed.

During the review we quickly noticed a lack of client authorization and input validation in the implementation of Foomuuri’s D-Bus service. We reported the issues to upstream and performed coordinated disclosure. Upstream published version 0.31 of Foomuuri on 2026-01-07 which contains bugfixes for the security issues.

The next section provides an overview of the Foomuuri D-Bus service. Section 3) discusses the security issues in detail. Section 4) provides an overview of the upstream bugfixes to address the issues. Section 5) looks into the CVEs which were assigned. Section 6) gives insight into the coordinated disclosure process which was established for these findings.

This report is based on Foomuuri release v0.29.

2) Overview of the D-Bus Service

Foomuuri runs with full root privileges and registers a D-Bus interface under the name”fi.foobar.Foomuuri1”. Optionally a firewalld drop-in replacement interface is also registered under “org.fedoraproject.FirewallD1”. Both interfaces hook into the same logic, however, and there is no need to look at them separately.

There are only a few methods provided by the D-Bus interface: getting the list of available zones and managing the assignment of network interfaces to zones.

3) Security Issues

3.1) Lack of Client Authorization

There is no authentication layer like Polkit present in the Foomuuri D-Bus service, and there are also no restrictions on D-Bus configuration level as to who is allowed to connect to the D-Bus interfaces provided.

As a result any local user, including low privilege service user accounts or even nobody, can invoke the D-Bus interface and change the firewall configuration. The only state which can be modified this way is the assignment of interfaces to zones, but this is enough to weaken the firewall configuration or to perform a limited Denial-of-Service.

3.2 Missing Input Parameter Verification

Apart from the lack of access restrictions pointed out above, the input parameters to the D-Bus methods are not carefully scrutinized. While the zone input parameter is at least checked against currently configured zones, no further checks are performed on the interface parameter. This means that, e.g. via the “addInterface” D-Bus method, arbitrary strings can be passed as interface name. There is also intentionally no check if the specified name corresponds to an existing network device in the system (to allow seamless coverage of network devices even before they are added to the system).

One result from this can be log spoofing, since the interface name is passed to logging functions unmodified. The string could contain control characters or newlines, which can manipulate the log.

In DbusCommon.add_interface() the possibly crafted interface name is added to the to-be-generated JSON configuration via the out() method. While we did not verify whether this works in practice, a local attacker could attempt to largely control the JSON configuration passed to nftables, by skillfully embedding additional JSON configuration in the interface parameter.

We were worried that this could even lead to arbitrary code execution by abusing features of nftables like loading external files or plugin code, but it turned out that there are no such features available in the nftables configuration format.

3.3) Unsafe umask used in Daemonize Code

Foomuuri contains optional support to daemonize itself. Normally this is done by systemd and the code in question is not invoked. It contains logic to set the daemon’s umask to 0, however, which is a bad default, since applications or libraries which intend to foster user control of the file mode of newly created files can pass modes like 0666 to open(), rendering them world-writable.

Foomuuri does not contain any code paths that create new files, but the umask setting is also inherited by child processes, for example. While we did not think this was a tangible security issue in this form, we suggested to choose a more conservative value here to prevent future issues.

4) Upstream Bugfixes

We suggested the following fixes to upstream:

• restrict access to the D-Bus interfaces to root only, maybe also to members of a dedicated opt-in group. Alternatively Polkit could be used for authentication of callers, which is more effort and complex, however.
• the interface input parameter should be verified right from the beginning of each D-Bus method to make sure that it does not contain any whitespace or special characters and is not longer than IFNAMSIZ bytes (which is currently 16 bytes on Linux).
• as an additional hardening measure we also suggested to apply systemd directives like ProtectSystem=full to Foomuuri’s systemd services, to prevent possible privilege escalation should anything go wrong at the first line of defense.

Upstream decided to implement Polkit authentication for Foomuuri’s D-Bus service and otherwise followed closely our suggestions:

• commit 5944a42 adds Polkit authentication to the D-Bus service. Changing firewall settings now requires admin authorization. The use of Polkit can be disabled in Foomuuri, in which case only clients with UID 0 are allowed to perform the operations.
• commit d1961f4 adds verification of the interface parameter to prevent manipulation of the JSON configuration data.
• commit 806e11d sets the umask used in the daemonize code to a more conservative 0o022 setting, preventing world- or group-writable files from coming into existence.
• commit 5fcf125 adds the ProtectSystem=full directive to all Foomuuri systemd service units.

All of the bugfixes are contained in version 0.31 of Foomuuri.

5) CVE Assignment

In agreement with upstream we assigned the following two CVEs corresponding to this report:

• CVE-2025-67603: lack of client authorization allows arbitrary users to influence the firewall configuration (issue 3.1).

• CVE-2025-67858: a crafted interface input parameter to D-Bus methods can lead to integrity loss of the firewall configuration or further unspecified impact by manipulating the JSON configuration passed to nft (issue 3.2).

6) Coordinated Disclosure

We reported these issues to the upstream developer on 2025-12-11, offering coordinated disclosure. We soon got a reply and discussed the details of the non-disclosure process. Upstream quickly shared patches with us for review and we agreed on the final patches already on 2025-12-19. In light of the approaching Christmas season we agreed on a publication date of 2026-01-07 for general disclosure.

We want to thank the upstream author for the prompt reaction and cooperation in fixing the issues.

7) Timeline

8) References

• Foomuuri GitHub project
• Foomuuri v0.31 Bugfix Release

With the start of the new year, I am very happy to announce the release of version Kraft 2.0.0.

Kraft provides effective invoicing and document management for small businesses on Linux. Check the feature list.

This new version is a big step ahead for the project. It does not only deliver the outstanding ports to Qt6 and KDE Frameworks 6 and tons of modernizations and cleanups, but for the first time, it also does some significant changes in the underlying architecture and drops outdated technology.

Kraft now stores documents not longer in a relational database, but as XML documents in the filesystem. While separate files are more natural for documents anyway, this is paving the way to let Kraft integrate with private cloud infrastructures like OpenCloud or Nextcloud via sync. That is not only for backup- and web-app-purposes, but also for synced data that enables to run Kraft as distributed system. An example is if office staff works from different home offices. Expect this and related usecases to be supported in the near future of Kraft.

But there are more features: For example, the document lifecycle was changed to be more compliant: Documents remain in a draft status now until they get finalized, when they get their final document number. From that point on, they can not longer be altered.

There is too much on the long Changes-List to mention here.

However, what is important is that after more than 20 years of developing and maintaining this app, I continue to be motivated to work on this bit. It is not a big project, but I think it is important that we have this kind of “productivity”-applications available for Linux to make it attractive for people to switch to Linux.

Around Kraft, a small but beautiful community has built up. I like to thank everybody who contributed in any way to Kraft over the years. It is big fun to work with you all!

If you are interested, please get in touch.

Sigo con estas pequeñas aplicaciones que se conocen como applets, widgets o plasmoides… para Plasma 5 (que a partir de ahora lo tengo que especificar), y que dotan de funcionalidades de todo tipo a nuestro entorno de trabajo KDE. Aunque en esta ocasión el plasmoide de hoy, que ejecuta una orden desde tu escritorio, también ya está listo para Plasma 6. Por cierto, el plasmoide se llama Run Commanda y será el 248 de esta serie.

Ejecuta una orden desde tu escritorio, Run Command – Plasmoides de KDE (248)

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 un plasmoide creado por Himdek que recibe el nombre de Run Commander que básicamente te permite poner una botón en tu escritori, ya sea en el fondo de pantalla o en un panel, que al pulsarlo ejecutará una orden de la terminal.

Como vemos en la captura se puede seleccionar el icono, el texto a mostrar (label), si queremos que se muestre icono, etiqueta o ambos y, finalmente, tenemos lo más importante: la orden que queremos ejecutar.

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.

La entrada Ejecuta una orden desde tu escritorio, Run Command – Plasmoides de KDE (248) se publicó primero en KDE Blog.

When I was looking for a solution that could provide High Availability for two Datacenters, the only solution that remained viable and comprehensible for me was using Corosync/Pacemaker. The reason that I actually need this is, that Mainframe environments typically use two Datacenters, since z/OS can nicely operate with that. The application that I had to setup is Kubernetes on Linux on Z and since Kubernetes itself normally runs with 3 or more nodes, I had to find a different solution. I found, that I could use an external database to run Kubernetes with https://github.com/k3s-io/kine, and being no DBA, I selected PostgreSQL as first try.

For pacemaker, there already exists an OCF Agent called pgsql https://linux.die.net/man/7/ocf_heartbeat_pgsql that is included with the clusterlabs OCF agents. In addition, RedHat created another OCF agent, called PAF https://clusterlabs.github.io/PAF/ that sounded promising. However, I first had to build it on my own, and later I found that it was really nicely promoted, but was missing out on some needed features.

That is, a colleague asked, if I wanted to try to use his AI, and countless improvements and bugs later, the pgtwin https://github.com/azouhr/pgtwin agent really seems quite stable. Now, to some of the main design concepts.

Make use of the promotable clone resource

PostgreSQL’s primary/standby model maps perfectly to promoted/unpromoted. This is actually how you also would configure pgsql with a current pacemaker release. All documentation relies on the current schema of this configuration.

Use Physical Replication with Slots

• Prevent WAL files from being recycled while standby is offline
• Enable standby to catch up after brief disconnections
• Automatically created/managed by pgtwin
• Automatically cleaned up when excessive (prevents disk fill)

Why physical, and not logical replication?

• Byte-identical replica (all databases, all tables, all objects)
• Lower overhead than logical replication
• Supports pg_rewind for timeline divergence recovery

Automatic Standby Initialization

Traditionally, the database admin would have to setup the replication and the OCF agent would then take over the management. However, since we already had basebackup functionality ready in case the WAL had been cleaned up, it was just a small step to provide full initialization

The only steps on the secondary for the admin after configuring the primary are:

• Create the PostgreSQL Data Directory with correct ownership/permissions
• Setup the password file .pgpass

The remaining tasks of creating a sync streaming replication is done during startup of the node by pgtwin.

Timeline Divergence and pg_rewind

After a failover, the old primary may have diverged from the new primary, and thus the synchronous replication will fail. pgtwin handles this as folows:

1. Detect divergence (timeline check in pgsql_demote)
2. Runs pg_rewind to sync from new primary
3. Replays necessary WAL ro reconcile
4. Starts as standby.

This is much faster than trying to do a full basebackup, at least with big databases. Typical failover times are merely seconds.

Replication Health Monitoring

Every monitor cycle, pgtwin does not only check if PostgreSQL is running, but also the replication health. This includes the replication state (streaming, catchup, etc.) as well as the replication lag and the synchronous state.

If the replication check fails for 5 consecutive monitor cycles (configurable), pgtwin automatically triggers recovery. First trying with pg_rewind, however if that fails, it will go for pg_basebackup.

Configuration Validation

At startup, pgtwin validates PostgreSQL configuration for a number of settings that it considers critical. There are hard checks like “restart_after_crash = off” that must be set to off to prevent PostgreSQL from trying to promote itself instead of letting pacemaker handle the situation. But also a number of other parameters.

To check the startup validation, have a look at the pacemaker system logs:

journalctl -u pacemaker -f

State Machine and Lifecyle

pgtwin has a clear idea about the state of PostgreSQL lifecycle:

┌─────────────────────────────────────────────────────────────┐
│                      STOPPED STATE                          │
│  PostgreSQL not running                                     │
└──────────────────────┬──────────────────────────────────────┘
                       │ start operation
                       ↓
              ┌────────────────┐
              │ PGDATA valid?  │
              └────┬───────┬───┘
                   │       │
             NO ←──┘       └──→ YES
              │                 │
              ↓                 ↓
    ┌──────────────────┐  ┌─────────────────┐
    │ Auto-initialize  │  │ Start PostgreSQL│
    │ (pg_basebackup)  │  │ as standby      │
    └────────┬─────────┘  └────────┬────────┘
             │                     │
             └──────────┬──────────┘
                        ↓
┌─────────────────────────────────────────────────────────────┐
│                   UNPROMOTED STATE                          │
│  PostgreSQL running as standby                              │
│  - Replaying WAL from primary                               │
│  - Read-only queries allowed                                │
│  - Monitor checks replication health                        │
└──────────────────────┬──────────────────────────────────────┘
                       │ promote operation
                       ↓
              ┌────────────────────┐
              │ pg_ctl promote     │
              │ (remove standby    │
              │  signal)           │
              └────────┬───────────┘
                       ↓
┌─────────────────────────────────────────────────────────────┐
│                    PROMOTED STATE                           │
│  PostgreSQL running as primary                              │
│  - Accepts write operations                                 │
│  - Streams WAL to standby                                   │
│  - Manages replication slot                                 │
│  - Monitor checks replication health                        │
└──────────────────────┬──────────────────────────────────────┘
                       │ demote operation
                       ↓
              ┌────────────────────┐
              │ Stop PostgreSQL    │
              │ Check timeline     │
              │ pg_rewind if needed│
              │ Create standby     │
              │ signal             │
              └────────┬───────────┘
                       ↓
       (returns to UNPROMOTED STATE)

Failure Handling

The following Failures are handled completely automatically and are designed to provide seamless operation without dataloss:

1. Primary Failure and Recovery
2. Standby Failure and Recovery
3. Replication Failure
4. Split-Brain Prevention

For the Split-Brain Prevention, additional Pacemaker configurations like a second corosync with direct network connection as well as a third ring with IPMI will be needed.

Container Mode

pgtwin is prepared to also support containers instead of a locally installed PostgreSQL database. However, the current implementation is too sluggish and has too much overhead during management of the database.

For future releases, I plan to change the implementation by switching from “podman run” to the use of “nsexec”. We will see, if this makes the implementation usable. Still, currently implemented is

• Version check, that prevents from using a wrong Container PostgreSQL Version with the current PGDATA
• Additional PostgreSQL User that allows to use the PGDATA Userid to be used within the Container.
• All PostgreSQL commands are run by a wrapper, so that there is a seamless integration between bare-metal and container operations guaranteed.

Single-Node Startup

The original authors of pgsql were very considered about the data even in the case of a double crash of the cluster. The scenario they had in mind was like this:

• Primary crashes
• Secondary takes over and handles applications
• Secondary crashes
• Primary comes up with outdated data and continues as primary

Now, with pgtwin there is a number of considerations going to the startup

1. If both nodes come up, pgtwin will check the timeline on who should become promoted
2. If cluster was down, and one node comes up:
   • If Node was primary and had sync mode enabled: Node likely crashed, should not be promoted.
   • If Node was primary and had async mode enabled: Node likely crashed when other node was missing. This node should become primary
   • If Node was secondary: Cluster probably crashed, or was restarted after the secondary crashed, node should not be promoted

The key insight here is, that in case just one node is restarted, it only should be promoted standalone if it was primary before, and in addition it had async streaming replication activated even though the cluster was configured for sync streaming replication.

The cluster will refuse to start with a single node else. If startup is really needed, the admins will have to override.

pgtwin-migrate

In a future blog entry, I will cover the features of the currently experimental pgtwin-migrate OCF agent. This agent allows to fail over between two PostgreSQL Clusters, like two Versions or between different Vendors.

Hoy toca entrada sencilla y dedicada al mundo del Software Libre en general. En concreto os comparto el vídeo: «¿Qué es LINUX? El único vídeo que necesitas para entenderlo» una creación de Ruizack de Ciber Academia que nos los explica de forma bastante clara utilizando, y creo que es la primera vez que digo esto, herramientas de IA para su edición.

Vídeo: ¿Qué es LINUX? El único vídeo que necesitas para entenderlo

En ocasiones tenemos que explicar a los nuevos usuarios o a gente que tiene curiosidad que es realmente Linux, ya que hay muchos conceptos que entran en juego: GNU, Linux, kernel, aplicaciones, escritorios, distribuciones, etc.

Transmitir todos estas ideas para que el recién llegado vaya entendiendo algo del nuevo mundo que se abre ante él o ella no es sencillo y utilizar analogías y símiles va muy bien, y lo que ha hecho Ruizak es justo eso: utilizar la analogía del coche, que en alguna charla he utilizado.

En palabras del creador del vídeo Ruizak de Ciber Academia:

¿Qué es Linux realmente? No, no es solo “un sistema operativo raro para programadores”. En este vídeo te explico de forma clara, sencilla y visual qué es Linux, qué NO es, por qué existe la confusión con GNU/Linux, cómo funciona su kernel, qué son las distribuciones y por qué Linux está presente en servidores, móviles, coches, routers, supercomputadores… ¡en todo!

No os entretengo más y os dejo el video, creado con IA pero de gran calidad, para que aprendáis y para que lo tengáis a mano por si en un momento dado necesitáis para explicárselo a alguna persona. Toda las contribuciones son importantes.

Contribuye al avance del Software Libre: difunde el conocimiento

Si os gusta el vídeo no dejéis pasar la opotunidad de pagar a su creador, en esta ocasión, utilizando las forma que te permite la plataforma de vídeos Youtube:

• Subscríbete a su canal.
• Ponle un comentario
• Comparte en redes sociales
• O cualquier otra forma que se te ocurra.

Hoy es un buen día para insistir que 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 2017 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.

La entrada Vídeo: ¿Qué es LINUX? El único vídeo que necesitas para entenderlo se publicó primero en KDE Blog.

¿Saben mentir o pedir perdón los LLM que están detrás de inteligencias artificiales como Chat-GPT? ¿Sueñan los androides con ovejas eléctricas?

De la Wikipedia:

Un modelo extenso de lenguaje o LLM (siglas en inglés para Large Language Model), también llamado modelo de lenguaje de gran tamaño, modelo de lenguaje grande, gran modelo de lenguaje, modelo lingüístico grande o modelo de lenguaje a gran escala, es un modelo de lenguaje de aprendizaje profundo, que consta de una red neuronal con muchos parámetros (normalmente miles de millones o más), entrenados en grandes cantidades de texto sin etiquetar mediante aprendizaje autosupervisado o aprendizaje semisupervisado. […]

Algunos LLMs notables son la serie de modelos GPT de OpenAI (por ejemplo, GPT-3 y GPT-4 , utilizados en ChatGPT y Microsoft Copilot), PaLM y Gemini de Google.

El siguiente artículo es una traducción/adaptación de un artículo creado por el activista por el software libre Alexandre Oliva y publicado bajo una licenciaCC-by-sa 3.0 y que puedes leer en el original en este enlace:

• https://blog.lx.oliva.nom.br/2026-01-03-LLMs-cannot-lie.en.html

Y que me ha permitido traducir y publicar en mi blog, muchas gracias por eso. Espero que os resulte tan interesante como me lo pareció a mí.

Los modelos de lenguaje grandes se disculpan a menudo cuando se los reprocha.

A veces incluso dicen ser sinceros.

No están mintiendo.

Pero tampoco están siendo sinceros de verdad.

No pueden.

No pueden sentir arrepentimiento, no pueden sentir pena, no comprenden lo que hicieron mal.

Por eso no pueden ofrecer una disculpa sincera.

No pueden distinguir el bien del mal, no pueden distinguir lo verdadero de lo falso.

La razón por la que no pueden mentir es que se requiere la intención de engañar, y no son capaces de tener ninguna intención en absoluto.

Por tanto ellos tampoco pueden ser sinceros. No pueden sentir nada.

No pueden decir si lo que generan es cierto.

Su entrenamiento y sus algoritmos apuntan a la probabilidad, a la plausibilidad.

La verdad ni siquiera es una consideración.

Y no les importa. No les puede importar. No son capaces de preocuparse.

Son solo Iteradores Autocompletadores

Calculan qué palabra parece probable que aparezca a continuación, una tras otra.

No entienden, no tienen sentido común ni inteligencia.

Si parecen inteligentes es porque están entrenados para imitar.

Cuando se disculpan, no te están engañando.

Sólo fueran entrenados con disculpas.

Quizás algunas de las disculpas utilizadas durante la fase de enseñanza fueron incluso sinceras.

Pero imitar esa disculpa no equivale a ser una disculpa sincera.

Tal vez fueron entrenados con disculpas por expertos manipuladores de sentimientos.

Incluso entonces, no aprendieron a manipular los sentimientos.

Sólo se les enseñó a utilizar ciertas construcciones del lenguaje en tales situaciones.

No te están mintiendo.

No tienen ni idea de lo que están haciendo.

No están tramando una forma de apaciguar tu ira.

Simplemente no pueden hacer eso.

Quizás quienes los controlan quisieron que lo hicieran.

Quizás quienes los controlan los entrenaron para hacerlo.

Y se miran, en su sabiduría 1/infinita.

Recuerde, no hay ningún compromiso con la verdad en sus predictores de palabras.

O con la honestidad. O para evitar tu decepción.

(Por mucho que estén entrenados para complacerte y embriagarte con halagos).

No hay intención de engañar en su pensamiento: no pueden pensar.

No pueden mentir más de lo que pueden decir lo que es verdad: simplemente no pueden saberlo.

No hay inteligencia ni comprensión ahí.

No son inteligencias artificiales.

No son más que generadores de tonterías, y no les importa.

No les importa. Simplemente son Generadores de Tonterias

En cuanto a quienes los controlan y los entrenan… Parece que tampoco les importa.

Y es aquí cuando me viene a la mente un dibujo de David Revoy (también gran defensor y usuario del software libre), que puedes ver en este enlace si tienes interés:

• https://www.davidrevoy.com/article1103/the-correct-incantation

Ya tenemos, desde noviembre, sede para el encuentro anual de desarrolladores de la Comunidad KDE. De esta forma me complace anunciar que Akademy 2026 se celebrará en Graz, Austria. Será una edición especial con motivo del 30.º aniversario de KDE que tendrá lugar en la Universidad Tecnológica de dicha ciudad. Reserven ya la fecha.

Akademy 2026 se celebrará en Graz, Austria

El evento más importante de la Comunidad KDE no se mueve del centro de Europa. En esta ocasión la ciudad seleccionada ha sido Graz, la segunda ciudad más grande de Austria , conocida por su casco antiguo bien conservado, que es Patrimonio de la Humanidad por la UNESCO y también reconocida por sus instituciones educativas, en particular la Universidad de Graz y la Universidad de Tecnología de Graz, lo que la convierte en un centro de innovación e investigación.

Akademy 2026 será una edición especial, con la que se celebrará el 30.º aniversario de KDE que continuará reuniendo a colaboradoras y colaboradores, personas usuarias, socios y amistades de KDE para reflexionar sobre tres décadas de colaboración, innovación, crecimiento de la comunidad y compromiso con el Software Libre. Al igual que en años anteriores, Akademy 2026 será un evento híbrido, con participación tanto presencial como en línea.

Las fechas exactas serán anunciadas muy pronto. Hasta entonces, sigue las cuentas de Mastodon y Lemmy del evento para no perderte ninguna novedad sobre Akademy.​

Como es habitual, en breve se lanzará el «Call for Papers» y se empezará la búsqueda de patrocinadores, los cuales suelen ser necesarios para financiar los viajes de los desarrolladores y sufragar otros gastos menores como la fiesta de bienvenida tan clásica en este tipo de eventos.

Si eres simpatizante del Proyecto KDE y puedes asistir, no te la puedes perder. Conocer cara a cara a los principales desarrolladores KDE no tiene precio y es una experiencia única.

Además, no olvidemos que después de los dos días de charlas, se celebran 5 días de intenso trabajo de hacking donde además de picar código se realizan talleres donde se enseña, se discute, se alinean posturas y se fijan las bases del desarrollo de partes de KDE, como Plasma, que se seguirán a lo largo de un año.

¿Qué es Akademy?

Para los que no lo sepan, Akademy es el evento de la Comunidad KDE que aúna en una gran conferencia todo tipo de simpatizantes de KDE como desarrolladores, diseñadores, usuarios, traductores, promotores. Allí se reunirán a lo largo de una semana para compartir charlas, cenas, ponencias, talleres y, en definitiva, para trabajar juntos.
Es una gran semana que sirve para unir más fuerte los lazos que unen nuestra Comunidad, así como para crear nuevos.

Akademy lleva realizándose anualmente bajo este nombre desde 2004, en la página web oficial o en la wikipedia podéis encontrar los nombres y fechas anteriores eventos.

Para que os hagáis una ligera idea de la magnitud del evento, os dejo una imagen de grupo de Akademy 2023 de Tesalónica en la que tuve la suerte de participar.

La entrada Akademy 2026 se celebrará en Graz, Austria 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 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/01/tumbleweed-review-of-the-week-2026-1/

Comienza el año con la publicación en esta semana de tránsito entre 2025 y 2026 con 6 nuevas snapshots 20251227 – 20251231 y 20260101 y una más que acaba de ser publicada a la hora de escribir este artículo.

Las actualizaciones más destacadas de esta semana:

• Python 3.13.11 (some CVE fixes)
• libgit2 1.9.2S
• Neon 0.36.0
• Harfbuzz 12.3.0
• NetworkManager 1.54.3
• GStreamer 1.26.10
• VLC 3.0.22 y 3.0.23
• GPG 2.5.16
• upower 1.91.0

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

• SDL3 3.4.0
• Ruby 4.0
• transactional-update 6.0.1
• Shadow 4.19.0

Si quieres estar a la última con software actualizado y probado utiliza openSUSE Tumbleweed la opción rolling release de la distribución de GNU/Linux openSUSE.

Mantente actualizado y ya sabes: Have a lot of fun!!

Enlaces de interés

• ¿Por qué deberías utilizar openSUSE Tumbleweed?
• zypper dup en Tumbleweed hace todo el trabajo al actualizar
• ¿Cual es el mejor comando para actualizar Tumbleweed?
• ¿Qué es el test openQA?
• http://download.opensuse.org/tumbleweed/iso/
• https://es.opensuse.org/Portal:Tumbleweed

——————————–