Recopilación del boletín de noticias de la Free Software Foundation – octubre de 2024
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.
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/2024/october
- Y traducido en español (cuando el equipo de traducción lo tenga disponible) en este enlace: https://www.fsf.org/free-software-supporter/2024/octubre

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:
Por aquí te traigo un extracto de algunas de las noticias que ha destacado la FSF este mes de octubre de 2024.
Los guardianes de los derechos de autor acaban de destruir una enorme biblioteca digital
Del 20 de septiembre por David Moscrop
La Biblioteca Nacional de Emergencia (NEL), un programa de Internet Archive (IA), de la era de la pandemia, sufrió un duro golpe después de que un tribunal de apelaciones dictaminara que las prácticas de préstamo de la NEL violaban la ley de derechos de autor.
Bajo el programa NEL, más usuarios de la biblioteca sacaron copias digitales de los permitidos bajo la tecnología de Gestión de Restricciones Digitales (DRM) que limita estos materiales.
Tras una intensa batalla legal entre la IA y una coalición de grandes editoriales, la IA finalmente se vio obligada a retirar más de quinientos mil libros de la NEL. La IA no se da por vencida todavía, pero se enfrenta a una hidra masiva y podría necesitar su ayuda para restaurar el acceso público a los libros que fueron sustraídos, así como para preservar y distribuir información en el futuro. Para obtener más información sobre DRM, visite https://defectivebydesign.org.
- https://jacobin.com/2024/09/copyright-internet-archive-library-lawsuit.
- https://www.fsf.org/news/worldwide-community-of-activists-protest-overdrive-and-others-forcing-drm-upon-libraries
- https://victorhckinthefreeworld.com/2024/09/05/la-multinacional-hachette-contra-la-cultura-que-ofrece-internet-archive/
Así es como Apple hace que el iPhone 16 sea más reparable
Del 18 de septiembre por Brian Heater
El derecho a reparar sigue ganando impulso, lo suficiente como para que gigantes tecnológicos como Apple sientan la presión de hacer que ciertos modelos de iPhone sean más reparables.
Si bien el cambio a fabricar algunos componentes del iPhone 16 parece indicativo de que la lucha por la reparación está funcionando, este cambio es especialmente exiguo considerando el historial a largo plazo de Apple en restringir la reparación por parte de los usuarios, llegando incluso a ejercer presión para que sea ilegal para los usuarios modificar sus propios dispositivos.
En este momento, se pueden realizar reparaciones muy limitadas y son bastante difíciles, si no imposibles, sin comprar su kit de reparación de autoservicio patentado. Además, la propia Apple afirma claramente que estos kits y manuales de autorreparación están diseñados para personas con amplia experiencia previa en la reparación de dispositivos electrónicos, que probablemente no sea el usuario medio.
Parece que esto es más un intento de apaciguar las demandas de lucha para reparar a los activistas, y decimos que no es suficiente.
- https://techcrunch.com/2024/09/18/heres-how-apple-is-making-iphone-16-more-repairable
- https://www.fsf.org/bulletin/2023/spring/free-software-at-the-core-of-the-right-to-repair.
- https://www.fsf.org/campaigns/fight-to-repair.
- https://www.fsf.org/campaigns/apple.

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:
Y todos los números del «supporter» o boletín de noticias de 2024 en español, francés, portugués e inglés aquí:
—————————————————————
FreeBSD audit source for syslog-ng
Two weeks ago, I was at EuroBSDcon and received a feature request for syslog-ng. The user wanted to collect FreeBSD audit logs together with other logs using syslog-ng. Writing a native driver in C is time consuming. However, creating an integration based on the program() source of syslog-ng is not that difficult.
This blog shows you the current state of the FreeBSD audit source, how it works, and its limitations. It is also a request for feedback. Please share your experiences at https://github.com/syslog-ng/syslog-ng/discussions/5150!
Read more at https://www.syslog-ng.com/community/b/blog/posts/freebsd-audit-source-for-syslog-ng

syslog-ng logo
Esta semana en KDE Apps
Con la «muerte» del dot se ha puesto en marcha una revitalización de las otras formas de enterarse de lo que pasa en el ecosistema KDE. De esta forma, tal y como se comentó, el KDE Planet se ha revitalizado de forma increible, tanto en su página web como en su canal de Telegram (que esel que sigo). De esta forma me estoy enterando de cosas que antes se me pasaban por alto, como esta nueva iniciativa de Nate Graham y Carl Schwan que han llamado «This Week in KDE Apps» o lo que es lo mismo «Esta semana en KDE Apps» donde recogen pinceladas de los desarrollos de las numerosas aplicaciones del ecosistema KDE. Conozcamos un poco más esta nueva ventana a la Comunidad KDE.
Esta semana en KDE Apps
¡Bienvenidos al tercer post de nuestra serie «Esta semana en KDE Apps»! Si te lo perdiste, acabamos de anunciar esta nueva serie hace dos semanas, y nuestro objetivo es cubrir tanto como sea posible de lo que está sucediendo en el mundo KDE y completar la serie de Nathe «This Week in Plasma«.
Esta semana hemos tenido nuevos lanzamientos de Amarok y Krita. También hay noticias sobre KDE Connect, el enlace entre todos tus dispositivos; Kate, el editor de texto avanzado de KDE; Itinerary, el asistente de viajes que te permite planificar todos tus desplazamientos; Marble, la aplicación de mapas de KDE; y mucho más.
¡Pongámonos manos a la obra!
Así empieza, como ellos dicen, la tercera entrega de una serie que promete ofrecer pinceladas del desarrollo de algunas aplicaciones, y al leerlo me pregunto si alguno de vosotros estaría interesado a leer un breve resumen en castellano de esta entrada, que quedaría algo así:
- Amarok ha lanzado la versión 3.1.1
- Itinerary ahora permite ahora buscar lugares (por ejemplo, nombres de calles) además de paradas. Además, ahora muestra la hora de la conexión cuando se busca una conexión de transporte público.
- Ya está disponible en Digikam un nuevo algoritmo de detección facial basado en YuNet.
- Kate: ¡El plugin de depuración ahora funciona en Windows y además es más usable! Además, el menú contextual mostrará ahora las herramientas externas pertinentes.
- KCron: La página de configuración del sistema se ha portado a QML y se le ha dotado de una nueva interfaz de usuario.
- KDE Connect: Corregido el soporte Bluetooth para KDE Connect.
- Keysmith tiene ahora una página «Acerca de».
- Kleopatra ahora soporta claves OpenPGP v5.

- Se ha lanzado Krita 5.2.5, que aporta más de 50 correcciones de errores desde 5.2.3. Además, se han realizado importantes correcciones en la reproducción de audio, el cálculo de máscaras de transformación y mucho más. Nota: Leyendo para acabar el artículo me he enterado que Krita 5.2.5 tenía un bug crítico. Ya ha sido lanzado Krita 5.2.6.
- LabPlot implementa un nuevo tipo de gráfico: Gráfico de ComEn las versiones modernas de Android, NeoChat solicitará ahora el permiso correcto para enviar notificaciones del sistema.portamiento del Proceso (X-Chart).
-
Marble Maps, la versión QML de Marble, tiene un nuevo icono.
- También ha sido corregida una importante fuente de fallos visuales en la versión QML de Marble al mirar el globo terráqueo.
- Marble Behaim – una versión especial de Marble para mirar la representación del globo terráqueo más antiguo que se conoce – ahora también funciona en el escritorio gracias a Kirigami, y toda la información adicional y los créditos se muestran ahora utilizando una página «Acerca de» estándar.
- En las versiones modernas de Android, NeoChat solicitará ahora el permiso correcto para enviar notificaciones del sistema.
- Ahora Spectacle respeta su formato de archivo de guardado personalizado cuando utiliza la función «Guardar como».
¿Qué os parece? ¿Creo esta serie para KDE Blog o preferís seguirlo en inglés?
Más información: This Week in KDE Apps :New KCron Settings UI, Krita 2.2.5 released, and more
La entrada Esta semana en KDE Apps se publicó primero en KDE Blog.
Copiar en la terminal la salidad de un comando en el portapapeles de Linux
Veamos cómo hacer que la salida de un comando que ejecutamos en la terminal de nuestro sistema GNU/Linux se guarde en el portapapeles de nuestro sistema

Este artículo es una de esas «chuletas» o recordatorios de cómo se hace algo para mi yo del futuro, pero además si también a tí te resulta útil y es lo que estabas buscando pues mucho mejor.
Lo que estaba buscando es la manera de copiar la salida de un comando ejecutado en mi terminal al portapapeles del sistema, para después pegarlo en otro sitio, sin tener que seleccionar lo que quiero y copiarlo manualmente.
El ejemplo (real) es el siguiente. Estoy reportando un error de un programa de mi equipo, y en el reporte me pide mi información del sistema como sistema operativo, versión de tal o cual cosa, etc.
Toda esa información que necesito la obtengo rápidamente con kinfo en mi entorno Plasma de KDE ¿no lo sabías? Te dejo un enlace donde lo explico:
Pues bien, la salida de ese comando, la quiero copiar directamente al portapapeles de mi sistema para simplemente pulsar Ctrl+V en la página del reporte y pegar esa información que me ofrece kinfo.
Para esto vamos a utilizar xclip, por lo tanto tienes que tenerlo instalado en tu sistema. Tendremos que canalizar la salida de kinfo a xclip y decirle a este que utilice el portapapeles de mi sistema.
Para hacer todo esto basta con ejecutar el siguiente comando:
kinfo | xclip -selection clipboard
Podemos cambiar el comando kinfo por otro que nos interese. Podemos utilizar las opciones en formato corto del comando xclip para acortar el comando más:
kinfo | xclip -sel clip
Pero si siempre utilizamos xclip de esta manera, podemos acortar aún más el comando creando un alias en nuestro sistema como el siguiente:
alias xclip='xclip -sel clip'
Y con este alias ya configurado podremos acortar aún más nuestro ejemplo, que ahora sería así:
kinfo | xclip
Así configurado es más corto y cómodo.
Otro ejemplo, podremos también copiar por ejemplo las 10 primeras líneas de un archivo al portapapeles desde nuestra terminal con el siguiente comando:
head archivo.txt | xclip
Y después pegarlas en donde queramos. Interesante y rápido ¿verdad? Espero que te sea útil.

Schedule for openSUSE.Asia Summit is Published
The schedule for this year’s openSUSE.Asia Summit is out and features a diverse lineup of talks highlighting advancements in open-source and with the project.
This year’s event takes place in Tokyo, Japan, and is a two-day event running from Nov. 2 to Nov. 3, that includes talks about technologies involving openSUSE, Fedora, Ubuntu, Debian, AlmaLinux, Rocky Linux, and many other open-source projects.
The summit brings together developers, community members and open-source enthusiasts from around the world to Asia for discussions about Linux distribution updates to security and design.
Fuminobu Takeyama will open the event with a welcome address, which will be followed by a keynote from the company providing the venue, SHIFT Inc.. This will be followed by a talk about What is openSUSE? and talks about the future of Leap and an update about the Geeko Foundation. Trustees from the Geeko Foundation will provide an overview of the foundation’s financial and operational progress as well as providing insights about the use of the Travel Support Program, fundraising efforts and more.
A technical keynote about container and virtualization platforms focusing on openSUSE Leap Micro and a talk about language support for LibreOffice based on specific needs of Chinese, Japanese, and Korean (CJK) users will take place toward the beginning of the summit.
A talk related to secure software packaging and and AI/ML edge computing will provide some great content for attendees on the first day of the summit.
The second day is scheduled to have talks covering areas like the future of desktop Linux, free software in healthcare and geographic information systems using open-source technologies.
Find the schedule at events.opensuse.org.
Installing NVIDIA CUDA on Leap
In a blog post last year Simplify GPU Application Development with HMM on Leap we've described how to install CUDA using the NVIDIA open kernel driver built by SUSE. For this, we utilized driver packages from the graphics driver repository for openSUSE Leap hosted by NVIDIA. This happend to work at the time, as at the time the kernel driver version for the graphics driver happened to be the same as the one used by CUDA. This, however, is not usually the case and at present, therefore this method fails.
NVIDIA CUDA Runtime Installation on openSUSE Leap 15.6 Bare Metal
To recap, CUDA will work with the 'legacy' proprietary kernel driver that has existed for a long time as well as the open driver KMP provided with CUDA. There is also a pre-built driver KMP avaiable on openSUSE Leap (starting with version 15.5). The latter provides the additional perks:
- since it is fully pre-build it does not require an additional tool chain
to complete the build during installation - which the CUDA provided drivers
will install as dependencies.
This helps to keep an installation foot print small which is desirable for HPC compute nodes or AI clusters. - It is singed with the same key as the kernel and its components and thus will integrate seamlessly into a secure boot environment without enrolling an additional MOK - which usually requires access to the system console.
The NVIDIA open driver supports all recent GPUs, in fact, it is required for cutting edge platforms such as Grace Hopper or Blackwell, and recommended for all Turing, Ampere, Ada Lovelace, or Hopper architectures. The the proprietary driver is only still required for older GPU architectures.
The versions of the driver stacks for CUDA and for graphics frequently
differ. CUDA's higher level libraries will work with any version equal or
later to the one these have been released with. This means for instance,
that CUDA 12.5 will run with a driver stack version greater or equal to
555.42.06. The components of the lower level stack - ie. those packages
with the driver generation in their name (at the time of writing G06) -
need to match the kernel driver version.
The component stack for graphics is always tightly version coupled.
To accomodate versions difference for CUDA and graphics, openSUSE Leap
is now providing two sets of NVIDIA Open Driver KMPs: the version targetting
CUDA has the string -cuda prepended before -kmp in the package name.
With this, installing CUDA using the open driver becomes quite simple.
CUDA comes with a number of meta-packages which provide an easy way to install certain aspects while still obeying required dependencies. A more detailed list of these meta packages and their purposes will follow in a future blog. To run applications built with CUDA the only components required are the runtime. If we plan to set up a minimal system - such as an HPC compute node - these are the only components to be installed. They consist of the low level driver stack as well as the CUDA libraries. In a containerized system, the libraries would reside inside the application container.
To install the runtime stack for CUDA 12.9, we would simply run:
# zypper ar https://developer.download.nvidia.com/compute/cuda/repos/opensuse15/x86_64/cuda-opensuse15.repo
# zypper --gpg-auto-import-keys refresh
# zypper -n in -y nv-prefer-signed-open-driver
# version=$(rpm -qa --queryformat '%{VERSION}\n' nv-prefer-signed-open-driver | cut -d "_" -f1 | sort -u | tail -n 1)
# zypper -n in -y --auto-agree-with-licenses \
nvidia-compute-utils-G06 = ${version} cuda-libraries-12-9
The command above will install the SUSE-built and signed driver. Further changes to the module configuration as described in the previous blog are no longer required.
Now we can either reboot or run
# modprobe nvidia
to make sure, the driver is loaded. Once it's loaded, we ought to check if the installation has been successful by running:
nvidia-smi -q
If the driver has loaded successfully, we should see information about the GPU, the driver and CUDA version installed:
==============NVSMI LOG==============
Timestamp : Mon Aug 12 09:31:57 2024
Driver Version : 555.42.06
CUDA Version : 12.5
Attached GPUs : 1
GPU 00000000:81:00.0
Product Name : NVIDIA L4
Product Brand : NVIDIA
Product Architecture : Ada Lovelace
Display Mode : Enabled
Display Active : Disabled
Persistence Mode : Disabled
Addressing Mode : HMM
...
NVIDIA CUDA Runtime Installation for containerized Workloads
Containerized workloads using CUDA have their highlevel CUDA runtime libraries installed inside the container. The low level libraries are made available when the container is run. This allows running containerized workloads relatively independent of the version of the driver stack as long as the CUDA version is not newer than the version of driver stack used. Depending on what container environment we plan to use, there are different ways to achieve this. We've learned in a previous blog, how to do this using the NVIDIA GPU Operator and a driver container. This does not require to install any NVIDIA components on the container host. The kernel drivers will be loaded from within the driver container, they do not need to be installed on the container host. However, there are other container systems and different ways to install CUDA for K8s.
Set up Container Host for podman
For podman, we require a different approach. For this, kernel driver as
well as the nvidia-container-toolkit need to be installed on the container
host. We need to use the container toolkit to configure podman to set up the
GPU device files and the low level driver stack (libraries and tools)
inside a container.
# zypper ar https://developer.download.nvidia.com/compute/cuda/repos/opensuse15/x86_64/cuda-opensuse15.repo
# zypper --gpg-auto-import-keys refresh
# zypper -n in -y nv-prefer-signed-open-driver
# version=$(rpm -qa --queryformat '%{VERSION}\n' nv-prefer-signed-open-driver | cut -d "_" -f1 | sort -u | tail -n 1)
# zypper -n in -y --auto-agree-with-licenses \
nvidia-compute-utils-G06 = ${version} \
nvidia-container-toolkit
Now, we can configure podman for the devices found in our system:
# nvidia-ctk cdi generate --output=/etc/cdi/nvidia.yaml
This command should show INFO as well as some WARN messages but should
not return any lines marked ERROR.
To run containers which use NVIDIA GPUs, we need to specify the device
using the argument: --device nvidia.com/gpu=<device>. Here, <device> may be on individual GPU or - on GPUs that support Multi-Instance GPU
(MIG) - an individual MIG device: ie GPU_ID or GPU_ID:MIG_ID) or all.
We are also able to specify multiple devices:
$ podman run --device nvidia.com/gpu=0 \
--device nvidia.com/gpu=1:0 \
...
This uses GPU 0 and MIG device 1 on GPU 1.
We may find the available devices by running:
$ nvidia-ctk cdi list
Set up Container Host for K8s (RKE2)
There are different ways to set up the K8s to let containers use NVIDIA devices. One has been described in a separate blog), however the driver stack can also be installed on the container host itself while still using the GPU Operator. The disadvantage of this approach is that the driver stack needs to be installed on each container host.
# zypper ar https://developer.download.nvidia.com/compute/cuda/repos/opensuse15/x86_64/cuda-opensuse15.repo
# zypper --gpg-auto-import-keys refresh
# zypper -n in -y nv-prefer-signed-open-driver
# version=$(rpm -qa --queryformat '%{VERSION}\n' nv-prefer-signed-open-driver | cut -d "_" -f1 | sort -u | tail -n 1)
# zypper -n in -y --auto-agree-with-licenses \
nvidia-compute-utils-G06 = ${version}
We need to perform above steps on each node (ie, server, agents) which have an NVIDIA GPU installed. How to continue depends whether we perfer to use the NVIDIA GPU Operator (without a driver container) or just use the NVIDIA Device Plugin container.
with the NVIDIA GPU Operator
Once the previous steps have been completed, we can start the GPU Operator:
OPERATOR_VERSION="v24.6.1"
DRIVER_VERSION="555.42.06"
helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
helm repo update
helm install \
-n gpu-operator --generate-name \
--wait \
--create-namespace \
--version=${OPERATOR_VERSION} \
nvidia/gpu-operator \
--set driver.enabled=false \
--set driver.version=${DRIVER_VERSION} \
--set operator.defaultRuntime=containerd \
--set toolkit.env[0].name=CONTAINERD_CONFIG \
--set toolkit.env[0].value=/var/lib/rancher/rke2/agent/etc/containerd/config.toml \
--set toolkit.env[1].name=CONTAINERD_SOCKET \
--set toolkit.env[1].value=/run/k3s/containerd/containerd.sock \
--set toolkit.env[2].name=CONTAINERD_RUNTIME_CLASS \
--set toolkit.env[2].value=nvidia \
--set toolkit.env[3].name=CONTAINERD_SET_AS_DEFAULT \
--set-string toolkit.env[3].value=true
We need to set OPERATOR_VERSION to the GPU Operator version we
whish like to use and DRIVER_VERSION to the driver version
we are running.
Now, we are able to see the pods starting:
kubectl get pods -n gpu-operator
The final state should either be Running or Completed.
Now, we should check the logs of the nvidia-operator-validator whether
the driver has been set up successfully
# kubectl logs -n gpu-operator -l app=nvidia-operator-validator
and the nvidia-cuda-validator if CUDA workloads can be run successfully.
# kubectl logs -n gpu-operator -l app=nvidia-cuda-validator
Both commands should return that the validations have been successful.
without the NVIDIA GPU Operator
Alternatively, we can set up NVIDIA support without the help of the GPU
Operator. For this, we will need to create a configuration - much like
for podman - and use the NVIDIA Device
Plugin.
If not done already, we need to install the nvidia-container-toolkit
package, for this:
# zypper -n in -y nvidia-container-toolkit
and restart RKE2:
# systemctl restart rke2-server
on the K8s server or
# systemctl restart rke2-agent
on each agent with NVIDIA hardware installed. This will make sure, the container runtime is configure appropriately.
Once the server is again up and running, we should find this entry in
/var/lib/rancher/rke2/agent/etc/containerd/config.toml:
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes."nvidia"]
runtime_type = "io.containerd.runc.v2"
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes."nvidia".options]
BinaryName = "/usr/bin/nvidia-container-runtime"
SystemdCgroup = true
Which is required to use the correct runtime for workloads requiring NVIDA
harware.
Next, we need to configure the NVIDIA RuntimeClass as an additional
K8s runtime so that any user whose pods need access to the GPU
can request them by using the runtime class nvidia:
# kubectl apply -f - <<EOF
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
name: nvidia
handler: nvidia
EOF
Since Device Plugin version 0.15 we need to set a hardware feature label telling the DaemonSet that there is a GPU on the node. This is normally set by the Node or GPU Feature Discovery daemons both deployed as part of the GPU Operator chart. Since we don't use this, we will have to set this manually for each node with a GPU:
kubectl label nodes <node_list> nvidia.com/gpu.present="true"
and install the NVIDIA Device Plugin:
# helm repo add nvdp https://nvidia.github.io/k8s-device-plugin
# helm repo update
# helm upgrade -i nvdp nvdp/nvidia-device-plugin \
--namespace nvidia-device-plugin --create-namespace \
--set runtimeClassName=nvidia
The pod should start up, complete the detection and tag the nodes with the number of GPUs available. To verify, we run:
# kubectl get pods -n nvidia-device-plugin
NAME READY STATUS RESTARTS AGE
nvdp-nvidia-device-plugin-tjfcg 1/1 Running 0 7m23s
# kubectl get node `cat /etc/HOSTNAME` -o json | jq .status.capacity
{
"cpu": "32",
"ephemeral-storage": "32647900Ki",
"hugepages-1Gi": "0",
"hugepages-2Mi": "0",
"memory": "65295804Ki",
"nvidia.com/gpu": "1",
"pods": "110"
}
Acknowledgements
Many ideas in this post were taken from the documentation NVIDIA GPUs in SLE Micro.
Further Documentation
NVIDIA CUDA Installation Guide for Linux
Installing the NVIDIA Container Toolkit
Support for Container Device Interface
Media / Fn Keys Not Registering on Framework 13 | Linux
Kraft Version 1.2.2
Kraft (Github) is the desktop app making it easy to create offers and invoices quickly and beautifully in small companies. It is targetted to the free desktop and runs on Linux.
This is the release announcement of the new Kraft version 1.2.2. This is a small service release that fixes a few bugs and CI issues.
Right after this release, the branch with significant changes for Kraft 2.0 will be merged to master. These changes will make Kraft ready for sharing documents across private file clouds and with that enable use cases for distributed use via internet, along with other significant feature updates.
Details about the next big release with version number 2.0 can be read on the Github Discussion page.
Any feedback and contribution is highly appreciated.
Ya puedes probar la versión Beta del cliente de correo Thunderbird para Android
El conocido cliente de correo Thunderbird, pronto estará disponible para dispositivos Android y tu puedes ayudar a probar la versión Beta hoy mismo

La versión Beta de Thunderbird para Android ya está disponible y tu puedes ayudar a pulir los posibles problemas encontrados. Las pruebas beta ayudan a encontrar errores críticos y aspectos que queden por corregir que podemos pulir en las próximas semanas.
¡Cuantas más personas prueben la versión beta y se aseguren de que todo lo que figura en la lista de verificación de pruebas funciona correctamente, mejor!
Este artículo es una traducción/adaptación del artículo original en inglés escrito por Monica Ayhens-Madon en la página oficial del proyecto Thunderbird, que puedes leer aquí:
Se parte de Thunderbird participando en las pruebas
¡Cualquiera puede ser probar la versión beta! Tanto si ya tienes eperiencia o nunca antes has probado una imagen beta, la comunidad de Thunderbird quiere ponértelo fácil ya que su objetivo es hacer que las pruebas sean rápidas, eficientes y, con suerte, divertidas.
El plan de lanzamiento es el siguiente y ojalá se cumpla y no haya eventos graves que lo obstaculicen:
- 30 de septiembre: primera beta de Thunderbird para Android
- Tercera semana de octubre – primer versión candidata final de lanzamiento
- Cuarta semana de octubre: lanzamiento de Thunderbird para Android
Descarga la imagen Beta
Aquí tienes un par de opciones donde descargarte la versión Beta y empezar tus pruebas:
- Descarga Thunderbird Beta en Google Play Store
- Descarga la última versión preliminar desde nuestra página de lanzamientos de Github
Todavía están trabajando en la preparación de las versiones para F-Droid.
Cosas que probar en la versión Beta
Una vez que hayas descargado la versión beta de Thunderbird para Android, los puntos que habría que comprobar son los siguientes:
- Configuración automática (el usuario solo proporciona la dirección de correo electrónico y tal vez la contraseña)
- Configuración manual (el usuario proporciona la configuración del servidor)
- Leer mensajes
- Obtener mensajes
- Cambiar entre cuentas
- Mover correo electrónico a la carpeta
- Notificar por mensaje nuevo
- Editar borradores
- Escribir un mensaje
- Enviar un mensaje
- Acciones de correo electrónico: responder, reenviar
- Eliminar un correo electrónico
- NO experimentar pérdida de datos en estas acciones
Prueba el cambio de K-9 a Thunderbird para Android
Si ya estás usando K-9 Mail, puedes ayudar a probar una característica importante: transferir tus datos de K-9 Mail a Thunderbird para Android. Para hacer esto, deberás asegurarte de haber actualizado a la última versión beta de K-9 Mail.
Este proceso de transferencia es un paso clave para facilitar que los usuarios de K-9 Mail pasen a Thunderbird. Probar esto ayudará a garantizar una experiencia fluida y confiable para las futuras personas que realicen el cambio.
Las versiones posteriores incluirán además una forma de transferir la información desde Thunderbird Desktop a Thunderbird para Android.
Lo que no se está probando ahora
Sabemos que es tentador comentar todo lo que uno encuentre en la versión beta. Pero por ahora hay que ceñirse en los errores críticos, la lista de verificación anterior y los problemas que podrían impedir que los usuarios interactúen de manera efectiva con la aplicación, para que se pueda publicar una excelente versión final.
Dónde reportar lo encontrado
Puedes compartir tus comentarios en la lista de correo beta de Thunderbird para Android y también ver los comentarios de otras personas. Es fácil registrarse y compartir qué funcionó y, lo que es más importante, qué no funcionó de las tareas anteriores en tus pruebas.
Para los informes de errores, lo ideal es proporcionar tantos detalles como sea posible, incluidos los pasos para reproducir el problema, el modelo de tu dispositivo y la versión del sistema operativo, y cualquier captura de pantalla o mensaje de error que creas que puede ser relevante.
¿Quieres chatear con otros miembros de la comunidad, incluidos otros evaluadores y contribuyentes que trabajan en Thunderbird para Android? ¡Puedes unirte en Matrix!
¿Tiene ideas que te gustaría ver en futuras versiones de Thunderbird para Android? Mozilla Connect, es su sitio oficial para enviar y votar ideas.

POWER for open source enthusiasts: what is coming?
Recently I was at EuroBSDCon, where several participants recognized that I am a POWER guy. And they were right, I have been an IBM POWER Champion focusing on open source software on POWER for the past three years.

Talos II POWER9 mainboard
I got the usual question from people: is there anyone working on an affordable and open source friendly POWER machine? My answer was a definite yes, but also had to admit that I do not know the actual status for any of the projects. I looked around again and did not find any updates for this year. Still, I collected some pointers, as these might be interesting also outside of the BSD community.
- The OpenPOWER foundation has a PowerPI special interest group, which plans to create a small and affordable POWER computer. https://openpowerfoundation.org/
- Raptor Computing announced on Twitter that they are working on new POWER machines, Talos III and Blackbird II: https://x.com/RaptorCompSys/status/1715147706061168822
It is almost the end of the year, so I am not sure if we will see any actual hardware this year, but I hope that we will have at least a couple of announcements before the end of the year.
By the way: if you want an open source friendly POWER machine now Raptor Computing is the place to go. Even if POWER 9 energy efficiency is not the best by today’s standards, they provide fully owner controlled computing using OpenPOWER, which is something completely unique in the world of computers.
