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

——————————–

Es increíble el trabajo de promoción que está realizando Nate en su blog, desde hace más del tiempo que puedo recordar. Cada semana hace un resumen de las novedades más destacadas, pero no en forma de telegrama, sino de artículo completo. Su cita semanal no falla y voy a intentar hacer algo que es simple pero requiere constancia. Traducir sus artículos al castellano utilizando los magníficos traductores lo cual hará que la gente que no domine el inglés esté al día y que yo me entere bien de todo. Bienvenidos pues a «¡Año nuevo, nuevas funciones de accesibilidad!» de la serie Esta semana en Plasma. Espero que os guste.

¡Año nuevo, nuevas funciones de accesibilidad! – Esta semana en Plasma

Nota: artículo original en Blogs KDE. Traducción realizada utilizando Perplexity. Esta entrada está llena de novedades de la Comunidad KDE. Mis escasos comentarios sobre las mejoras entre corchetes.

Nuevas funcionalidades

Plasma 6.6.0

¡La función de accesibilidad “Teclas lentas” ha sido implementada para la sesión de Wayland de Plasma! (Martin Riethmayer, KDE bug #490826) [¡Todo lo que sea mejoras en accesibilidad es más que bienvenido!].

El efecto de zoom ahora cuenta con un modo en el que el puntero nunca se aleja del centro de la pantalla física. (Ritchie Frodomar, KDE bug #513145)

La aplicación de selección de emojis ahora permite elegir un tono de piel preferido para los emojis de manos y personas. (Tobias Ozór, plasma-desktop MR #3399) [Inclusión 100%].

Ahora es posible desactivar los indicadores de tiempo visibles en las notificaciones si te resultan estresantes. (Anton Birkel, KDE bug #411613)

Mejoras en la interfaz de usuario

Plasma 6.5.5

Cuando Discover te pide que busques en Internet una aplicación que no pudo encontrar, ahora la cadena de búsqueda incluye el nombre correcto del sistema operativo si no estás utilizando un sistema basado en Linux. (Jaimukund Bhan, KDE bug #513366)

Plasma 6.6.0

Usar un mando de videojuegos ahora contará como “actividad”, evitando que el sistema entre automáticamente en suspensión o bloquee la pantalla. (Yelsin Sepulveda, KDE bug #328987) [Útil para jugones].

Cuando se conecta o desconecta un portátil mientras está en reposo, ahora se despierta reconociendo correctamente su estado actual. (Nate Graham, KDE bug #507203) [El problema de la hibernación es infinito. A ver si de una vez por todas deja de dar problemas].

La página de pantalla táctil en Configuración del sistema ahora se oculta automáticamente cuando no hay pantallas táctiles conectadas. (Nicolas Fella, KDE bug #513566)

El OSD de selección de pantalla ahora incluye un botón para abrir la página completa de Configuración del sistema si ninguna de las opciones integradas resulta relevante. (Kai Uwe Broulik, kscreen MR #442)

Al crear una nota adhesiva en el escritorio mediante el pegado con clic central, ahora el área de texto obtiene el foco de inmediato, lista para editar. (Kai Uwe Broulik, kdeplasma-addons MR #967)

Se mejoró sutilmente la apariencia de los indicadores superpuestos en los widgets de Plasma, especialmente en los de la bandeja del sistema. (Noah Davis, plasma-workspace MR #6118)

En el lanzador del panel de aplicaciones, los resaltados de las categorías ahora abarcan todo el ancho del área, haciéndolo más uniforme visualmente. (Christoph Wolk, plasma-desktop MR #3408)

El estilo del cambiador de tareas con iconos grandes ahora muestra mejor una gran cantidad de iconos al distribuirlos en varias filas en lugar de desplazarse horizontalmente. (Christoph Wolk, KDE bug #513436)

Corrección de errores importantes

Plasma 6.5.5

Se corrigió un problema que hacía que algunas ventanas emergentes de Plasma permanecieran abiertas de forma inapropiada al perder el foco. (Aleksey Rochev, KDE bug #511187)

Plasma 6.6.0

Posiblemente se haya corregido uno de los bloqueos más comunes de Plasma relacionados con el panel. (David Edmundson, plasma-workspace MR #6086)

Se corrigió un problema en Spectacle que podía hacer que algunas barras de herramientas del modo de región rectangular aparecieran fuera de la pantalla al usar una configuración con varios monitores en la que no todos compartían la misma línea base. (Mario Roß, KDE bug #468794)

Se corrigió un fallo que podía hacer que la etiqueta “¡Nuevo!” de las aplicaciones recién instaladas en Kickoff se desbordara en apps con nombres muy largos. (Christoph Wolk, KDE bug #513272)

Se solucionó un curioso problema que podía hacer que el gestor de tareas iniciara una operación de arrastrar y soltar al hacer doble clic sobre una tarea justo en el borde de la pantalla. (Aleksey Rochev, KDE bug #501922)

Mejoras de rendimiento y aspectos técnicos

Plasma 6.6.0

Se mejoró y corrigió el soporte para OpenBSD en varios componentes. (Rafael Sadowski, KPipeWire MR #229, KInfoCenter MR #284, Solid MR #228)

Cómo puedes ayudar

¡“This Week in Plasma” necesita tu ayuda! Publicar estas entradas lleva tiempo y requiere la colaboración de la comunidad para que siga siendo sostenible. En este momento hay dos formas de ayudar:

• Ayudar a preparar las publicaciones utilizando el proceso actual, que es en su mayoría manual
• Ayudar a automatizar el proceso

El trabajo puede coordinarse en la sala Matrix correspondiente.

Además, puedes ayudar a KDE participando directamente en otros proyectos. Donar tiempo es, en realidad, más valioso que donar dinero. Cada colaborador marca una gran diferencia en KDE: ¡no eres un número ni una pieza más de la máquina! Y no necesitas ser programador; existen muchas otras formas de contribuir.

También puedes ayudar haciendo una donación. Esto ayuda a cubrir los costes operativos, salarios, gastos de viaje para los colaboradores y, en general, a que KDE siga llevando Software Libre al mundo.

Para obtener una nueva característica de Plasma o una corrección de errores mencionada aquí, siéntase libre de enviar un commit a la solicitud de fusión correspondiente en invent.kde.org.

La entrada ¡Año nuevo, nuevas funciones de accesibilidad! – Esta semana en Plasma se publicó primero en KDE Blog.

Dear Tumbleweed users and hackers,

Happy New Year to you all! While people all around the world are celebrating the new year, Tumbleweed has been tirelessly rolling ahead and has published six snapshots (20251227 – 20251231, 20260101). Naturally, there are no groundbreaking changes, as many developers and maintainers are out celebrating, and any greater coordinated effort is taking a bit more time.

Nevertheless, the six snapshots brought you these changes:

• 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 & 3.0.23: finally linking ffmpeg-8
• GPG 2.5.16
• upower 1.91.0

The next snapshot is already in progress of syncing out, and the next few changes are pulling up in the staging projects. You can expect these things shortly:

• SDL3 3.4.0
• Ruby 4.0: currently breaking build of vim, See https://github.com/vim/vim/issues/18884
• transactional-update 6.0.1
• Shadow 4.19.0

Let’s get rolling for the Year 2026! I’m looking forward to a great year!

During my works on Kubernetes on Linux on Z and the creation of https://github.com/azouhr/pgtwin, I came across the same issue that most admins have to solve in two-node clusters. How can I get quorum, and what node is to be the primary.

While using additional techniques like providing a second corosync ring for HA, and even a third ring for an IPMI device, the elegance of having a three node quorum could not easily be implemented in my desired environment.

When trying to solve the correct placement of the primary PostgreSQL database in the two-Node Cluster, it came to me, that there is an external dependency that could be used as arbitrator. It does not really help an application if a resource is available, but it cannot be reached.

The main insight here was:

**Availability without accessibility is useless**

This pattern shifts HA from “server-centric” (is it running?) to “use-case-centric” (can it be used for its intended purpose?). I did some research, however I could not find anyone describing this key principle as a method to determine placement of resources.

We did define a new term to make this handy:

Definition of “Critical Path”:

A critical path is any dependency required for the service to fulfill its designed use case.

Definition of “Path-Aware High Availability (PAHA)”

Path-Aware High Availability is a general clustering pattern where resource promotion decisions explicitly validate critical paths required for service delivery before allowing promotion. Unlike traditional HA which only checks if a service *process* is running, PAHA ensures the service is running on a node where clients can actually use it.

This turned out to be a really interesting thought. Besides network paths, this can also be applied to other paths, totally unrelated to the original use case:

This can even be used to mitigate sick-but-not-dead conditions. For example in a multipath environment, you might want to disable a path that sometimes shows crc errors. Even from the storage side, you would know if there are sufficient paths available, and can disable the sick path.

Now to the fun part. It tells about pacemaker, that such functionality can be implemented by simple configuration means, at least for networks. For pgtwin, the question was, what happens if ring0 (with the PostgreSQL resource) is partially broken. The other ring would keep the cluster running, but the placement of the primary with read-write capability would have to go to the node with service access.

What we had to do, was merely create a ping resource, setup a clone with it, and create a location rule that tells pacemaker where to place the primary resource. In case of pgtwin, we additionally prevent the unpromoted resource from running on a node without ping connectivity, because it likely will not be able to sync with the primary. The configuration looks like this:

primitive ping-gateway ocf:pacemaker:ping \
    params \
        host_list="192.168.1.1" \ 
        multiplier="100" \
        attempts="3" \
        timeout="2" \
    op monitor interval="10s" timeout="20s"
clone ping-clone ping-gateway \
    meta clone-max="2" clone-node-max="1"
location prefer-connected-promoted postgres-clone role=Promoted \
    rule 200: pingd gt 0
location require-connectivity-unpromoted postgres-clone role=Unpromoted \
    rule -inf: pingd eq 0

Now, in the assumed case of a Dual Datacenter setup, what happens if the gateway vanishes on one side is:

1. The cluster makes sure that the primary is on the side with the ping availability.
2. The secondary is located on the other side.
3. The secondary may not run there without the ping resource and is stopped.
4. The primary is notified about the secondary being gone, and switches to async replication mode.

This means, that we lost high availability of the PostgreSQL database, but it still serves the applications as usual. When the gateway comes back, the following happens:

1. The cluster starts pgtwin on the secondary
2. pgtwin initiates a rollback of the database to get the timelines in sync
3. If the rollback is unsuccessful, pgtwin initiates a basebackup from the primary
4. After the nodes are consistent, the database is started as secondary, and the replication is switched to sync again.
5. The primary node is not moved back, because we set a resource stickiness by default.

All of this happens without admin intervention. This procedure greatly improves availability of the PostgreSQL database for the intended use.