Recopilación y traducción del boletín mensual de noticias relacionadas con el software libre publicado por la Free Software Foundation.

La Free Software Foundation (FSF) es una organización creada en Octubre de 1985 por Richard Stallman y otros entusiastas del software libre con el propósito de difundir esta filosofía, frente a las restricciones y abusos a los usuarios por parte del software privativo.

Por cierto este mes se cumplen 40 años de la creación de la FSF.

La Fundación para el software libre (FSF) se dedica a eliminar las restricciones sobre la copia, redistribución, entendimiento, y modificación de programas de computadoras. Con este objeto, promociona el desarrollo y uso del software libre en todas las áreas de la computación, pero muy particularmente, ayudando a desarrollar el sistema operativo GNU.

Mensualmente publican un boletín (supporter) con noticias relacionadas con el software libre, sus campañas, o eventos. Una forma de difundir los proyectos, para que la gente conozca los hechos, se haga su propia opinión, y tomen partido si creen que la reivindicación es justa!!

• En este enlace podéis leer el original en inglés: https://www.fsf.org/free-software-supporter/2026/january
• Y traducido en español (cuando el equipo de traducción lo tengamos disponible) en este enlace: https://www.fsf.org/free-software-supporter/2026/enero

Puedes ver todos los números publicados en este enlace: http://www.fsf.org/free-software-supporter/free-software-supporter

¿Te gustaría aportar tu ayuda en la traducción y colaborar con la FSF? Lee el siguiente enlace:

• https://victorhckinthefreeworld.com/2016/12/22/quieres-ayudar-a-traducir-el-boletin-mensual-de-la-free-software-foundation/

Por aquí te traigo un extracto de algunas de las noticias que ha destacado la FSF este mes de enero de 2026.

Se anuncian los ganadores de los premios Free Software Awards: Andy Wingo, Alx Sa, Govdirectory

Del 9 de diciembre

Cada año, la FSF reconoce a algunos grupos e individuos de la comunidad de software libre que han realizado contribuciones significativas a la libertad del software. Este año, los galardonados con el Premio al Avance del Software Libre, el Premio al Contribuyente Destacado de Software Libre y el Premio a Proyectos de Beneficio Social fueron otorgados a Andy Wingo, Alx Sa y Govdirectory. Lee más sobre los ganadores y piensa en cómo podrías involucrarte en un proyecto de software libre en un futuro próximo.

• https://www.fsf.org/news/2024-free-software-awards-winners

La Free Software Foundation recibe donaciones privadas históricas

Del 24 de diciembre

Hacia el final del cuadragésimo año de la FSF, dos donantes excepcionalmente generosos donaron a la organización una contribución total de 900.000 dólares estadounidenses. Estas donaciones extraordinarias, ambas hechas a la FSF en la criptomoneda Monero, están entre algunas de las mayores donaciones privadas jamás hechas a la organización. Los donantes desean permanecer en el anonimato.

Todas las donaciones, sean 5 USD o 500.000 USD, marcan la diferencia en el trabajo de la FSF para avanzar en el movimiento del software libre. Estas donaciones apoyarán al equipo técnico y la capacidad de infraestructura de la organización, así como fortalecerán sus campañas, iniciativas educativas, de licencias y de incidencia, así como oportunidades futuras. Nunca es tarde para apoyar la misión de la FSF de promover la libertad del usuario de ordenadores — dona hoy.

• https://www.fsf.org/news/free-software-foundation-receives-historic-private-donations

Tu vida digital no es tuya: La batalla oculta por la libertad del software

Del 17 de diciembre por Jason Self

Tú eres el dueño de tu teléfono, pero otra persona dicta sus funciones. Puedes usar redes sociales, pero un algoritmo que no puedes inspeccionar moldea la realidad que ves. Eres dueño de tu coche, pero no puedes arreglarlo. Tienes tu smart TV, pero te está observando.

En cada rincón de nuestra vida moderna, estamos rodeados de cosas que hemos comprado pero que se nos prohíbe poseer o comprender realmente. El culpable no es el dispositivo en sí, sino el código invisible que se ejecuta en su interior, y la lucha por el control de ese código es una de las batallas más importantes por los derechos humanos del siglo XXI.

Sigue leyendo para entender mejor cómo los proveedores privativos buscan controlarte y qué puedes hacer para construir un futuro mejor.

• https://www.fsf.org/blogs/community/your-digital-life-is-not-yours

Estas son solo algunas de las noticias recogidas este mes, ¡¡pero hay muchas más muy interesantes!! si quieres leerlas todas (cuando estén traducidas) visita este enlace:

• https://www.fsf.org/free-software-supporter/2026/enero

Y todos los números del «supporter» o boletín de noticias de 2026 en español, francés, portugués e inglés aquí:

• https://www.fsf.org/free-software-supporter/2026

Table of Contents

• 1) Introduction
• 2) Overview of the TLP Daemon
• 3) Security Issues
  • 3.1 Polkit Authorization Check can be Bypassed
  • 3.2 Predictable Cookie Values in HoldProfile Method Allow to Release Holds
  • 3.3 Non-Integer cookie Parameter in “ReleaseProfile” Method Leads to Unhandled Exception
  • 3.4 Unlimited Number of Profile Holds Provides DoS Attack Surface
• 4) CVE Assignment
• 5) Coordinated Disclosure
• 6) Timeline
• 7) References

1) Introduction

TLP is a utility for saving laptop battery power when running Linux (note: the TLP acronym has no special meaning). In version 1.9.0 of TLP a profiles daemon similar to GNOME’s power profiles daemon has been added to the project, providing a D-Bus API for controlling some of TLP’s settings.

Our SUSE TLP package maintainer asked us for a review of the changes contained in the new TLP release, leading us to discover issues in the Polkit authentication logic used in TLP’s profiles daemon, which allow a complete authentication bypass. While looking into the daemon we also found some additional security problems in the area of local Denial-of-Service (DoS).

We reported the issues to upstream in December and performed coordinated disclosure. TLP release 1.9.1 contains fixes for the issues described below. This report is based on TLP 1.9.0.

The next section provides a quick overview of the TLP power daemon. Section 3 discusses the security issues we discovered in detail. Section 4 looks into the CVEs we assigned. Section 5 provides a summary of the coordinated disclosure process we followed for these findings.

2) Overview of the TLP Daemon

The new TLP power daemon is implemented in a Python script of moderate size. The daemon runs with full root privileges and accepts D-Bus client connections from arbitrary users. For authorization of clients a Polkit policy defines a couple of actions which are checked in the daemon’s _check_polkit_auth() function. Some of these actions are allowed for local users in an active session without providing further credentials, others require admin credentials.

3) Security Issues

3.1 Polkit Authorization Check can be Bypassed

The check_polkit_auth() function relies on Polkit’s “unix-process” subject in an unsafe way. The function obtains the caller’s PID and passes this information to the Polkit daemon for authorization, which is inherently subject to a race condition: at the time the Polkit daemon looks up the provided PID, the process can already have been replaced by a different one with higher privileges than the D-Bus client actually has.

As a result of this, the Polkit authorization check in the TLP power daemon can be bypassed by local users, allowing them to arbitrarily control the power profile in use as well as the daemon’s log settings.

This is a well-known issue when using the “unix-process” Polkit subject which was assigned CVE-2013-4288 in the past. For this reason the subject has been marked as deprecated in Polkit. The “unix-process” subject is seeing new use these days, however, when combined with the use of Linux PID file descriptors, which are not affected by the race condition.

Upstream Bugfix

We suggested to upstream to switch to Polkit’s D-Bus “system bus name” subject instead, which is a robust way to authenticate D-Bus clients based on the UNIX domain socket the client uses to connect to the bus. This is what upstream did in commit 08aa9cd.

3.2 Predictable Cookie Values in HoldProfile Method Allow to Release Holds

The D-Bus methods “HoldProfile” and “ReleaseProfile” can be used by locally logged-in users without admin authentication and allow to establish a “profile hold”, preventing the profile from being automatically switched until it is released again.

The “HoldProfile” method returns a cookie value to the caller which needs to be presented to the “ReleaseProfile” method again to release it. This cookie value is a simple integer which starts counting at zero and is incremented for each call to “HoldProfile”. This makes the cookie value predictable and allows other, unrelated users or applications to release an active profile hold by trying to guess the cookie value in use.

Upstream Bugfix

We suggested to upstream to make the cookie value unpredictable by generating a random number. This is what upstream did in commit a88002e.

3.3 Non-Integer cookie Parameter in “ReleaseProfile” Method Leads to Unhandled Exception

As described in the previous section, the “ReleaseProfile” D-Bus method expects an integer cookie parameter as input. The Python D-Bus framework used to implement the method allows clients to pass non-integer types as cookie, however, which causes an exception to be thrown in the daemon. This does not lead to the daemon exiting, however, since the framework catches the exception.

The issue can be reproduced via the following command line:

user$ dbus-send --system --dest=org.freedesktop.UPower.PowerProfiles \
      --type=method_call --print-reply /org/freedesktop/UPower/PowerProfiles \
      org.freedesktop.UPower.PowerProfiles.ReleaseProfile string:test
Error org.freedesktop.DBus.Python.ValueError: Traceback (most recent call
last):
  File "/usr/lib/python3.13/site-packages/dbus/service.py", line 712, in
_message_cb
    retval = candidate_method(self, *args, **keywords)
  File "/usr/sbin/tlp-pd", line 223, in ReleaseProfile
    cookie = int(cookie)
ValueError: invalid literal for int() with base 10: dbus.String('test')

Upstream Bugfix

While this is not strictly a security issue, we still suggested to make the daemon more robust by actively catching type mismatch issues for the cookie input parameter. Upstream followed this suggestion and implemented it in the same commit as above which introduces unpredictable cookie values.

3.4 Unlimited Number of Profile Holds Provides DoS Attack Surface

The profile hold mechanism described in section 3.2 allows local users in an active session to create an unlimited number of profile holds without admin authentication. This can lead to resource exhaustion in the TLP power daemon, since an integer is entered into a Python dictionary along with arbitrary strings reason and application_id which are also supplied by the client. This API thus offers Denial-of-Service attack surface.

We found a similar issue in GNOME’s power profile daemon some years ago, but GNOME upstream disagreed with our analysis at the time, which is why SUSE distributions are applying a custom patch to limit the number parallel profile holds.

Upstream Bugfix

We asked upstream whether there are any valid use cases for supporting a large number of profile holds in parallel, and it turns out that the typical use case is only to support a single profile hold at any given time. Thus upstream agreed to restrict the number of profile holds to a maximum of 16, which is implemented in commit 6a637c9.

4) CVE Assignment

We assigned CVE-2025-67859 to track issue 3.1 (Polkit authentication bypass). Issues 3.2 (predictable cookie values) and 3.4 (unlimited number of profile holds) would formally also justify CVE assignments; their severity is low, however, and we agreed with upstream to focus on the main aspect of the Polkit authentication bypass.

5) Coordinated Disclosure

We reached out to the upstream author on December 16 with details about the issues and offered coordinated disclosure. Upstream confirmed the issues and accepted coordinated disclosure. We discussed patches and further details over the course of the following two weeks. Due to the approaching Christmas holiday season we decided to set the general publication date to January 7.

We want to express our thanks to the TLP upstream author for the smooth cooperation in handling these issues.

6) Timeline

7) References

• TLP Website
• TLP GitHub project
• TLP Bugfix Release 1.9.1
• openSUSE Bugzilla review bug for TLP 1.9.1

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