This is a roundup of articles from the openSUSE community listed on planet.opensuse.org.

The below featured highlights listed on the community’s blog feed aggregator are from November 1 to 6.

Blog posts this week highlight a post-mortem with the Open Build Service, a Tenerife LanParty, a security issue announcement by SUSE Security Team, Quantum computing in open source and much more.

Here is a summary and links for each post:

Hack Week Project Aims to Rebuild Classic Games

Hack Week 25 is Dec. 1 - 5 and it has a project that is reverse-engineering 1990s PC games like Master of Orion II: Battle at Antares, Chaos Overlords and others to build clean versions capable of running the game. The goal is to have playable prototypes built during the week.

Third update of KDE Gear 25.08

The KDE Blog highlights the third update of Gear 25.08 and introduces several bug-fixes across apps, libraries and widgets to improve stability and translations for Konqi users. Some fixes were made for Kdenlive, KWalletManager and more.

scx: Unauthenticated scx_loader D-Bus Service can lead to major Denial-of-Service

Posts like this don’t happen too often, but this SUSE Security Team Blog should get people’s attention. This security blog post highlights scx project’s scx_loader. The D-Bus service could run with root privileges and no authentication, which could allow any unprivileged user to manipulate system schedulers and potentially cause a denial-of-service.

Tenerife LanParty (Podcast Linux #31)

The KDE Blog post revisits episode #31 of the Podcast Linux series, which is a special feature recorded at the Tenerife LanParty (TLP 2017).

Severe Service Degradation: OBS Unreliable/Unavailable

The Open Build Service team published a service post-mortem discussing recent operational issues and outlining improvements to monitoring and response workflows. Lessons learned from the post-mortem are that the team set sensible limits for build service requests (and possibly other areas) as serving all results at once for a request with 6,000+ actions is unsustainable.

Plasma 6.5 Second Update

The KDE Blog and Plasma 6.5 team released its second update for the desktop environment on Nov. 4. It focuses on improving stability, better translations and bug fixes. A couple fixes included having a smoother automatic shift between light and dark themes and enhancing global WiFi password storage.

Compilation of the Free Software Foundation newsletter – November 2025

Victorhck puts out a new post collecting major FSF updates including their 40-year anniversary projects, the upcoming hackathon (Nov. 21-23), and recent advocacy on software freedom and patents. Victorhck also goes into some details about the announcement of the FSF’s Librephone project.

SUSE delivers Raspberry Pi 5 support

The openSUSE Project announces support for the Raspberry Pi 5, which includes enabling boot to graphical desktop with working Ethernet, WiFi, and USB. The blog acknowledges the extensive contributions by the SUSE Hardware Enablement team related to U-Boot, PCIe and kernel driver support.

LliureX as a tool for educational innovation

The post introduces the UjiLliurex 2025 programme, which leverages the LliureX Linux distribution as a tool for educational innovation in higher education. Its aim is promoting ICT skills and collaborative coordination across the academic community.

Leap Fuels Hands-On Learning, Exploration

The openSUSE Project highlights how users can turn their setups into home labs. It highlights the use case of learning. From tracking aircraft with SDR to deploying Kubernetes clusters, Leap can be used to learn through experimentation on a stable, production-grade base.

Quantum computing and open source: the future is already in open source on Compilando Podcast

The hosts dive into the world of quantum computing during this episode of the Compilando Podcast. What qubits are? Why do ultra-cold conditions matter? The hosts explore how open-source tools like Qiskit and Cirq are helping researchers collaborate globally.

Framework Laptop 13 Protective Bumper

Tech-enthusiast Nathan Wolf goes into a custom 3D printed TPU 98A bumper for the Framework Laptop 13 to improve durability during travels. After 13 major design revisions, he settles on a 10 mm frame that balances protection and usability.

Controlling frame intensity and image focus

The KDE Blog dives into “This Week in KDE Plasma” and highlights two major upcoming features; adjustable boldness for window frames and outlines in Breeze themes, and a global sharpness slider for display content when using a compatible Linux kernel.

View more blogs or learn to publish your own on planet.opensuse.org.

Community developers plan to bring new life to classic 1990s video games by reviving and reverse engineering some classic games during a project during Hack Week 25.

The project calls on participants to select an older game, analyze its data formats and underlying rules, and write a clean-room engine capable of running the original game content.

Many games from the era are simple enough that contributors can produce a playable prototype within the week.

The classic-games project, which has grown over multiple years, has titles listed such as Master of Orion II, Chaos Overlords, and Signus: The Artifact Wars.

Work on Master of Orion II: Battle at Antares is regarded as one of the defining 4X strategy games of the 1990s and has become one of the project’s flagship effort. Developers have decoded savegame formats, resource files and interface screens across several Hack Weeks.

The team working on Chaos Overlords identified resource formats, mapped much of the logic and begun developing a Qt-based interface resembling the original’s mouse-driven design. The game’s AI remains one of the toughest puzzles. Contributors are calling it critical to the game’s identity.

Earlier efforts include Signus: The Artifact Wars, a Czech turn-based strategy title open-sourced in 2003. Developers continue to refine support for original file formats and work toward packaging improvements for openSUSE.

Participants frequently suggest new candidates. Companies and individuals are encouraged to join the project and hack on it for fun.

Another Hack Week 25 effort underway and the project aims to bring missing YaST features into Cockpit and System Roles; this comes following YaST’s deprecation from openSUSE Leap 16.0.

Hack Week, which began in 2007, has become a cornerstone of the project’s open-source culture. Hack Week has produced tools that are now integral to the openSUSE ecosystem, such as openQA, Weblate and Aeon Desktop. Hack Week has also seeded projects that later grew into widely used products; the origins of ownCloud and its fork Nextcloud derive from a Hack Week project started more than a decade ago.

For more information, visit hackweek.opensuse.org.

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

Tercera actualización de KDE Gear 25.08

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

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

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

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

Por ello me congratula compartir con vosotros la tercera actualización de KDE Gear 25.08 que nos ofrece más de 180 errores resueltos entre aplicaciones, librerías y widgets, algo que mejora el rendimiento del sistema.

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

• kdenlive: Corrige que algunas imágenes no se rendericen en la previsualización de la línea de tiempo (Commit, corrige el error #511249
• kosmindoormap: También renderiza escaleras en los pasillos (Commit).
• kwalletmanager: Asegura que el menú contextual de la lista de entradas se cree aunque la lista esté vacía (Commit, corrige el error #510780).

Más información: KDE Gear 25.08.03

La entrada Tercera actualización de KDE Gear 25.08 se publicó primero en KDE Blog.

Table of Contents

• 1) Introduction
• 2) Overview of the Unauthenticated scx_loader D-Bus Service
• 3) Passing Arbitrary Parameters to Schedulers
  • The --pin-root-path Option
  • The --kconfig Option
  • The --btf-custom-path Option
  • The --bpf-token-path Option
• 4) On the Verge of a Local Root Exploit
• 5) Affected Linux Distributions
• 6) Suggested Fixes
  • Restrict Access to a Group on D-Bus Level
  • Use Polkit for Authentication
  • Making the API more Robust
  • Use systemd Sandboxing
• 7) Missing Upstream Bugfix
• 8) CVE Assignment
• 9) Timeline
• 10) Links

1) Introduction

The scx project offers a range of dynamically loadable custom schedulers implemented in Rust and C, which make use of the Linux kernel’s sched_ext feature. An optional D-Bus service called scx_loader provides an interface accessible to all users in the system, which allows to load and configure the schedulers provided by scx. This D-Bus service is present in scx up to version v1.0.17. As a response to this report, scx_loader has been moved into a dedicated repository.

A SUSE colleague packaged scx for addition to openSUSE Tumbleweed, and the D-Bus service it contained required a review by our team. The review showed that the D-Bus service runs with full root privileges and is missing an authentication layer, thus allowing any user to nearly arbitrarily change the scheduling properties of the system, leading to Denial-of-Service and other attack vectors.

Upstream declined coordinated disclosure for this report and asked us to handle it in the open right away. In the discussion that followed, upstream rejected parts of our report and presented no clear path forward to fix the issues, which is why there is no bugfix available at the moment.

Section 2 provides an overview of the scx_loader D-Bus service and its lack of authentication. Section 3 takes a look into problematic command line parameters which can be influenced by unprivileged clients. Section 4 looks into attempts to achieve a local root exploit using the scx_loader API. Section 5 lists affected Linux distributions. Section 6 discusses possible approaches to fix the issues found in this report. Section 7 takes a look at the upstream efforts to fix the issues.

This report is based on version 1.0.16 of scx.

2) Overview of the Unauthenticated scx_loader D-Bus Service

The scx_loader D-Bus service is implemented in Rust and offers a completely unauthenticated D-Bus interface on the system bus. The upstream repository contains configuration files and documentation advertising this service as suitable to be automatically started via D-Bus requests. Thus arbitrary users in the system (including low privilege service users or even nobody) are allowed to make unrestricted use of the service.

The service’s interface offers functions to start, stop or switch between a number of scx schedulers. The start and switch methods also offer to specify an arbitrary list of parameters which will be directly passed to the binary implementing the scheduler.

Every scheduler is implemented in a dedicated binary and found e.g. in /usr/bin/scx_bpfland for the bpfland scheduler. Not all schedulers that are part of scx are accessible via this interface. The list of schedulers supported by scx_loader in the reviewed version is:

scx_bpfland scx_cosmos scx_flash scx_lavd
scx_p2dq scx_tickless scx_rustland scx_rusty

We believe the ability to more or less arbitrarily tune the scheduling behaviour of the system already poses a local Denial-of-Service (DoS) attack vector that might even make it possible to lock up the complete system. We did not look into a concrete set of parameters that might achieve that, but it seems likely, given the range of schedulers and their parameters made available via the D-Bus interface.

3) Passing Arbitrary Parameters to Schedulers

The ability to pass arbitrary command line parameters to any of the supported scheduler binaries increases the attack surface of the D-Bus interface considerably. This makes a couple of concrete attacks possible, especially when the scheduler in question accepts file paths as input. Apart from parameters that influence scheduler behaviour, all schedulers offer the generic “Libbpf Options”, of which the following four options stick out in this context:

--pin-root-path <PIN_ROOT_PATH>      Maps that set the 'pinning' attribute in their definition will have
                                     their pin_path attribute set to a file in this directory, and be
                                     auto-pinned to that path on load; defaults to "/sys/fs/bpf"
--kconfig <KCONFIG>                  Additional kernel config content that augments and overrides system
                                     Kconfig for CONFIG_xxx externs
--btf-custom-path <BTF_CUSTOM_PATH>  Path to the custom BTF to be used for BPF CO-RE relocations. This custom
                                     BTF completely replaces the use of vmlinux BTF for the purpose of CO-RE
                                     relocations. NOTE: any other BPF feature (e.g., fentry/fexit programs,
                                     struct_ops, etc) will need actual kernel BTF at /sys/kernel/btf/vmlinux
--bpf-token-path <BPF_TOKEN_PATH>    Path to BPF FS mount point to derive BPF token from. Created BPF token
                                     will be used for all bpf() syscall operations that accept BPF token
                                     (e.g., map creation, BTF and program loads, etc) automatically within
                                     instantiated BPF object. If bpf_token_path is not specified, libbpf will
                                     consult LIBBPF_BPF_TOKEN_PATH environment variable. If set, it will be
                                     taken as a value of bpf_token_path option and will force libbpf to
                                     either create BPF token from provided custom BPF FS path, or will
                                     disable implicit BPF token creation, if envvar value is an empty string.
                                     bpf_token_path overrides LIBBPF_BPF_TOKEN_PATH, if both are set at the
                                     same time. Setting bpf_token_path option to empty string disables
                                     libbpf's automatic attempt to create BPF token from default BPF FS mount
                                     point (/sys/fs/bpf), in case this default behavior is undesirable

libbpf is a userspace support library for BPF programs found in the Linux source tree. The following sub-sections take a look at each of the attacker-controlled paths passed to this library in detail.

The --pin-root-path Option

The --pin-root-path option potentially causes libbpf to create the parent directory of this path in bfp_object__pin_programs(). We are not entirely sure under which conditions the logic is triggered, however, and if these conditions are controlled by an unprivileged caller in the context of the scx_loader D-Bus API.

The --kconfig Option

The file found in the --kconfig path is completely read into memory in libbpf_clap_opts.rs line 91. This makes a number of attack vectors possible:

• pointing to a device file like /dev/zero leads to an out of memory situation in the selected scheduler binary.
• pointing to a private file like /etc/shadow causes the scheduler binary to read in the private data. We did not find a way for this data to leak out into the context of an unprivileged D-Bus caller, however. This technique still allows to perform file existence tests in locations that are normally not accessible to unprivileged users.
• pointing to a FIFO named pipe will block the scheduler binary indefinitely, breaking the D-Bus service. Also, by feeding data to such a PIPE, nearly all memory can be used up, keeping the system in a low-memory situation and possibly leading to the kernel’s OOM killer targeting unrelated processes.
• by pointing to a regular file controlled by the caller, crafted KConfig information can be passed into libbpf. The impact of this appears to be minimal, however.

The following command line is an example reproducer which will cause the scx_bpfland process to consume all system memory until it is killed by the kernel:

user$ gdbus call -y -d org.scx.Loader -o /org/scx/Loader \
    -m org.scx.Loader.SwitchSchedulerWithArgs scx_bpfland \
    '["--kconfig", "/dev/zero"]'

The --btf-custom-path Option

The --btf-custom-path option offers similar attack vectors as the --kconfig option discussed above. Additionally, crafted binary symbol information can be fed to the scheduler via this path, which will be processed either by btf_parse_raw() or btf_parse_elf() found in libbpf. This can lead to integrity violation of the scheduler / the kernel, the impact of which we cannot fully judge as we lack expertise in this low level area and did not want to invest more time than necessary for the analysis.

The --bpf-token-path Option

The --bpf-token-path, if it refers to a directory, will be opened by libbpf and the file descriptor will be passed to the bpf system call like this:

bpf(BPF_TOKEN_CREATE, {token_create={flags=0, bpffs_fd=20}}, 8) = -1 EINVAL (Invalid argument)

This does not seem to achieve anything, however, because the kernel code rejects the caller if it lives in the initial user namespace (which the privileged D-Bus service always does). The path could maybe serve as an information leak to test file existence and type, if the behaviour of the scheduler “start” operation shows observable differences depending on the input.

4) On the Verge of a Local Root Exploit

With this much control over the command line parameters of many different scheduler binaries, which offer a wide range of options, we initially assumed that a full local root exploit would not be difficult to achieve. We tried hard, however, and did not find any working attack vector so far. It could be that we overlooked something in the area of the low level BPF handling regarding the attacker-controlled input files discussed in the previous section, however.

scx_loader is saved from a trivial local root exploit merely by the fact that only a subset of the available scx scheduler binaries is accessible via its interface. The scx_chaos scheduler, which is not among the schedulers offered by the D-Bus service, supports a positional command line argument referring to a “Program to run under the chaos scheduler”. Would this scheduler be accessible via D-Bus, then unprivileged users could cause user controlled programs to be executed with full root privileges, leading to arbitrary code execution.

From discussions with upstream it sounds like the exclusion of schedulers like scx_chaos from the D-Bus interface does not stem from security concerns, but rather from functional restrictions, because some schedulers are not supported in all contexts, or are not stable yet.

5) Affected Linux Distributions

From our investigations and communication with upstream it seems that only Arch Linux is affected by the problem in its default installation of scx. Gentoo Linux comes with an ebuild for scx, but for some reason there is no integration of scx_loader into the init system and also the D-Bus autostart configuration file is missing. Thus it will only be affected if an admin manually invokes the service.

Otherwise we did not find a packaging of scx_loader on current Fedora Linux, Ubuntu LTS or Debian Linux. Due to the outcome of this review we never allowed the D-Bus service into openSUSE, which is therefore also not affected.

6) Suggested Fixes

Restrict Access to a Group on D-Bus Level

A quick fix for the worst aspects of the issue would be to restrict the D-Bus configuration in org.scx.Loader.conf to allow access to the interface only for members of a dedicated group like scx. This at least prevents random unprivileged users from abusing the API.

We offer a patch for download which does exactly this.

Use Polkit for Authentication

By integrating Polkit authentication, the use of this interface can be restricted to physically present interactive users. Even in this case we suggest to restrict full API access to users that can authenticate as admin, via Polkit’s auth_admin_keep setting. Read-only operations can still be allowed without authentication.

Making the API more Robust

The individual methods offered by the scx.Loader D-Bus service should not allow to perform actions beyond the intended scope, even if a caller would have authenticated in some form as outlined in the previous sections.

To this end, dangerous parameters for schedulers should either be rejected (e.g. by enforcing a whitelist of allowed parameters) or verified (e.g. by determining whether a provided path is only under control of root and similar checks).

Regarding input files, the client ideally should not pass path names at all, but send file descriptors instead, to avoid unexpected surprises and the burden of verifying input paths in the privileged D-Bus service.

Use systemd Sandboxing

The systemd service for scx_loader could make use of various hardening options that systemd offers (like ProtectSystem=full), as long as these do not interfere with the functionality of the service. This would prevent more dangerous attack vectors from succeeding if the first line of defense fails.

7) Missing Upstream Bugfix

Upstream showed a reluctant reaction to the report we provided in a GitHub issue, rejecting parts of our assessment. An attempt to introduce a Polkit authentication layer based on AI-generated code was abandoned quickly, and upstream instead split off the scx_loader service into a new repository to separate it from the scx core project. Our original GitHub issue has been closed, and we cloned it in the new repository to keep track of the issue.

Downstream integrators of scx_loader can can limit access to the D-Bus service to members of an scx group by applying the patch we offer in the Suggested Fixes section. This way access to the problematic API becomes opt-in, and is restricted to more privileged users that actually intend to use this service.

8) CVE Assignment

We suggested to upstream to assign at least one cumulative CVE to generally cover the unauthenticated D-Bus interface aspect leading to local DoS, potential information disclosure and integrity violation. We offered to assign a CVE from the SUSE pool to simplify the process.

Upstream did not respond to this and did not clearly confirm the issues we raised, but rather rejected certain elements of our report. For this reason there is currently no CVE assignment available.

9) Timeline

10) Links

• scx GitHub repository
• scx GitHub issue for this report
• newly created scx_loader GitHub repository
• cloned GitHub issue in the new scx_loader repository
• openSUSE Bugzilla review bug
• suggested patch to restrict access to the D-Bus service

Aunque el proyecto Podcast Linux está parado esto no significa que no tenga cabida en el blog y, mientras pueda, seguiré promocionándolo con la esperanza de que reviva, como cierto pájaro mitológico. Y he pensado hacerlo de una forma sencilla para mi y creo que benificiosa para todos, creando poco a poco un índice de todas sus emisiones, de forma que podamos encontrar en este blog una alternativa a su magnífica obra. Así que bienvenidos aTrigésimoprimer audio de Podcast Linux – «Especial TLP2017» (Podcast Linux #31)» donde Juan nos radia un evento por dentro.

Trigésimoprimer audio de Podcast Linux – «Especial Tenerife LanParty 2017» (Podcast Linux #31)

Como los lectores del blog sabrán hace un tiempo Podcast Linux cerró sus emisiones por motivos que solo incumben a su creador. Desde el blog no quiero dejar que su recuerdo se desvanezca así que seguiré publicitando sus audios ya que su calidad no debe caer en el olvido.

Hace un tiempo decidí empezar por el principio, mostrando su primer audio, el cual no promocioné en su día y poco a poco hemos pasado ya los 30 episodios repasados.

De esta forma continuo con su trigésimoprimer audio de esta serie presentado en el blog, que en palabras de Juan:

Muy buenas linuxer@, bienvenid@ a otro especial. En esta ocasión no es un directo, sino el evento tecnológico más importante de mi isla, la Tenerife LanParty ( TLP2017 ).
Gracias a la OSL de la Universidad de La Laguna he podido compartir varios días en este evento y quiero hacerte llegar todo lo vivido allí.
Los diferentes audios recogidos son:
Molotov Studio
Canariarcade
WikiMedia España
Juan Fernando de la Rosa y FreeCad
Varias entrevistas para dar a conocer el podcasting.
Gamika Podcast
Patricio García, director de la OSL de la Universidad de La Laguna.

Más información: Podcast Linux

Sigue a Podcast Linux

Aprovecho para animaros a seguir Podcast Linux en algunos de los canales de comunicación que tiene:

• Twitter: https://twitter.com/podcastlinux
• Mastodon: https://mastodon.social/@podcastlinux/
• Correo: podcastlinux@disroot.org
• Web: https://podcastlinux.com/
• Telegram: https://t.me/podcastlinux
• Telegram Juan Febles: https://t.me/juanfebles
• Youtube: https://www.youtube.com/PodcastLinux
• Feed Podcast Linux: https://podcastlinux.com/feed
• Feed Linux Express (Audios Telegram): https://podcastlinux.com/Linux-Express/feed

La entrada Trigésimoprimer audio de Podcast Linux – «Especial Tenerife LanParty 2017» (Podcast Linux #31) se publicó primero en KDE Blog.

Me alegra compartir con todos vosotros la segunda actualización de Plasma 6.5, iniciando así una serie de revisión de software que le dotará de más estabilidad, mejores traducción y resolución de errores. Estas actualizaciones son 100% recomendables y casi obligatorias para cualquier usuario ya que lo único que hacen es mejorar la versión sin comprometer sus funcionalidades.

Segunda actualización de Plasma 6.5

No existe Software creado por la humanidad que no contenga errores. Es un hecho incontestable y cuya única solución son las actualizaciones. Es por ello que en el ciclo de desarrollo del software creado por la Comunidad KDE se incluye siempre las fechas de las mismas siguiendo una especie de serie de Fibonacci.

Así que me congratula en presentar que hoy martes 4 de noviembre de 2025, dos semanas después de liberar el código de Plasma 6.5 la Comunidad KDE presenta su segunda actualización de errores.

Más información: KDE

Las novedades generales de Plasma 6.5

Aprovecho para realizar un listado de las novedades generales de Plasma 6.5:

• Cambio automático entre tema claro y oscuro
• Paneles desplazables para widgets y accesos
• Nuevo asistente de configuración inicial (KISS)
• Almacenamiento global de contraseñas Wi-Fi
• Mejoras de rendimiento en KWin al reproducir vídeo
• Configuración de diales en tabletas de dibujo
• Mejoras en la gestión de colores para monitores HDR
• Uso de la tecla Enter en las acciones de apagado del menú Kickoff
• Filtro de accesibilidad para escala de grises
• Ajustes visuales con bordes redondeados en menús

Más información: KDE

La entrada Segunda actualización de Plasma 6.5 se publicó primero en KDE Blog.

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/2025/november
• Y traducido en español (cuando el equipo de traducción lo tengamos disponible) en este enlace: https://www.fsf.org/free-software-supporter/2025/noviembre

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 noviembre de 2025.

La FSF anuncia el proyecto Librephone

Del 14 de octubre

La FSF está abordando la libertad en la telefonía móvil con su nuevo proyecto, Librephone. Este proyecto no construirá un sistema operativo móvil desde cero. Se trata de un proyecto a largo plazo para comprender mejor y aplicar ingeniería inversa al código no libre utilizado por prácticamente todos los SoC actuales, además de sentar las bases para un futuro de libertad en la telefonía móvil.

Puedes mantenerte informado uniéndote al canal #librephone en el servidor IRC Libera.Chat. Toda la información sobre Librephone se publicará en su página web, ¡así que no olvides añadirla a tus marcadores!

• https://www.fsf.org/news/librephone-project
• https://www.fsf.org/campaigns/librephone
• http://librephone.fsf.org/

La FSF cumple 40 años con un nuevo proyecto revolucionario y un nuevo presidente

Del 4 de octubre

El aniversario de la FSF comenzó con una conversación entre los miembros de la junta directiva Christina Haralanova, Gerald J. Sussman, Ian Kelling y Richard M. Stallman, quienes hablaron sobre la misión de la organización y su visión de futuro.

Durante esta conversación, se presentó a Ian Kelling como el nuevo presidente de la FSF. El anuncio de la presidencia de Kelling no fue el único cambio importante que se compartió en FSF40: la directora ejecutiva de la FSF, Zoë Kooyman, presentó el proyecto más reciente de la organización: Librephone. Puedes leer más sobre el evento del 40.º aniversario de la FSF en el siguiente artículo.

• https://www.fsf.org/news/fsf-turns-forty-with-a-new-president-and-a-new-campaign

El ocaso de Windows 10 no significa el fin de tu PC

Del 9 de octubre

Para quienes tengan ordenadores con Windows 10, es posible que hayan experimentado diversos problemas al intentar la actualización forzada a Windows 11 (siempre que su hardware fuera compatible). Esta no es la primera vez que Microsoft intenta controlar a los usuarios, ni será la última.

El fin del soporte para Windows 10 es la oportunidad perfecta para frenar este ciclo y pasarse a un sistema operativo GNU/Linux que respete la libertad. Existen varias distribuciones GNU/Linux libres y aprobadas por la FSF a las que pueden cambiarse, muchas de ellas con útiles tutoriales en línea. Prueben alguna si aún no usan un sistema operativo libre; siempre tendrán la libertad de volver a un sistema operativo que intente limitar sus funciones.

• https://www.fsf.org/es/2025-fin-de-windows-10

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/2025/noviembre

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

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

SUSE delivers Raspberry Pi 5 support

It is finally happening. Raspberry Pi 5 users can now look forward to proper support in openSUSE Tumbleweed.

And it is not just about U-Boot, it is so much more. This is thanks to the hard work of many parties like SUSE Hardware Enablement team, RaspberryPi, Ideas on Board, Linaro, and many other engineers, along with Linux and U-Boot subsystem maintainers and many other engineers were patient enough to review our patches.

Many maybe wondering why it is taking so long to enable Raspberry Pi 5-based devices to work on anything other than Raspberry Pi OS; they no longer need to wonder.

About the boot process

First, let’s highlight the simplified OS-level boot architecture differences.

In Raspberry Pi OS, firmware located in the device’s EEPROM directly runs the vendor-developed Linux kernel.

In openSUSE, we use GRUB2. However, GRUB2 itself requires the machine to have UEFI firmware interfaces to be able to locate boot artifacts. Therefore, openSUSE uses the popular Das U-Boot bootloader to provide these interfaces.

This software combination works fine for (open)SUSE products. But this means we have had to add the missing RPi 5 features to U-Boot and the Linux kernel.

New RPi 5 hardware enhancements

Now, on the hardware side, there are some significant differences between the RPi 5 and all previous generations of devices.

Before the RPi 5, all controllers (like USB, Ethernet, SPI, I2C, GPIO, CSI, and so on) were part of the main SoC (BCM2835, BCM2836, BCM2835, BCM2710, BCM2711) and were more or less the same across different generations of these SoCs. Adding support for them in U-Boot and Linux was more or less straightforward.

On the RPi 5, things changed significantly. There is a new “south bridge” chip, the RP1, which contains all of the above controllers. The RP1 is connected to the main SoC (BCM2712) via a PCIe bus.

Fortunately, one thing has remained the same: The MicroSD card controller is still part of the main SoC. So, besides a few small differences in the SD controller’s internals, adding support for it to U-Boot and the Linux kernel was relatively easy.

Initial U-Boot support for bcm2712 SD controller

Add minimal boot support for Raspberry Pi 5

This led people to think that openSUSE was ready to run on this device.

But this was just the beginning of a long journey.

Let’s go back to PCIe. Older RPi’s also have a PCIe root complex, but the RPi 5’s is a little bit different. So, for U-Boot or Linux to be able to access all of the interesting controllers devices, we had to add support for it in U-Boot and the Linux kernel. This was done by this patch set:

Add PCIe support for bcm2712

There are a few other important pieces that landed in the Linux kernel:

• Add support for new MSI-X Interrupt Peripheral

• Add support for pin control driver for BCM2712 SoC

• Add support for clocks provided by RP1

• Implement RaspberryPi RP1 gpio support

After the PCI Express driver was working and Linux could see devices attached to the PCIe root complex, we had to port the driver that handles the new RP1 chip, behind which are the USB, Ethernet, and so on… This became a difficult task because many people had different views on how this should be implemented. But in the end, we got it merged:

Add support for RaspberryPi RP1 PCI device

Now Linux was able to see devices that were attached behind the RP1 chip. Of course, these controllers (Ethernet, for example) were a little bit different than those on the BCM2711, so a new set of patches was required:

Add support for Raspberry Pi RP1 ethernet controller

Of course, there were many more patches required to make this device usable. A really, really short list of them can be found below.

Currently openSUSE Tumbleweed is booting fine from SD card up to the graphical Desktop Environment using HDMI output.

What you should expect to be working once booted into Tumbleweed:

• Ethernet
• WiFi
• Bluetooth
• USB
• HDMI
• …

What is coming

Hopefully U-Boot will soon gain support for BCM2712 PCIe root complex controller. This will bring in ability device to boot from disk. Fixes for Ethernet controller are also on it is way.

Improve Raspberry Pi 5 support

Before you start

Before diving into your openSUSE on Raspberry Pi 5 adventure, make sure your device has the latest EEPROM update.

If you just received your Pi 5 without any system on it, you can prepare a MicroSD card with the EEPROM updater using Raspberry Pi Imager, or simply run the following commands from an existing image on your Pi 5:

sudo rpi-eeprom-update -a
sudo reboot

Do not skip the Debug Probe

If your RPi 5 seems to hang at the U-Boot stage when testing images, you are not alone. This is a known issue being tracked under:

boo#1250992.

This is a temporary workaround, and the issue is expected to be resolved soon.

Using the Debug Probe will save you a lot of time and frustration while experimenting with openSUSE on your RPi 5. It is also a handy tool to keep around for future embedded projects.

Really short list of RPi 5 related patches.

• Add DRM HDMI Codec framework

• Add support for BCM2712 HVS

• Add support for BCM2712 / Pi5 display hardware

• Add watchdog support for BCM2712

• Add Raspberry Pi’s RP1 ADC

What images should I try

You can now run most Raspberry Pi 4 compatible Tumbleweed appliance images or MicroOS if you prefer the immutable variant on your Raspberry Pi 5. openSUSE Leap and Leap Micro are currently out of scope for the effort, but are expected to gain full support in their next releases (16.1 and 6.3 released in late 2026).

Before you begin, make sure that you have the Debug Probe connected. Then write one of the Raspberry Pi images from openSUSE Tumbleweed appliances to your microSD card, and you should be ready to go.

If you can’t decide which image to start with, the Tumblweed Arm GNOME image for raspberrypi is a safe choice.

xzcat image.aarch64.raw.xz | dd of=/dev/sda bs=1M status=progress conv=fsync; sync

If you run into any issues, we highly recommend reaching out on the openSUSE Arm matrix channel or subscribing to the openSUSE Arm mailing list. Alternatively, you’re welcome to use forums.opensuse.org for general openSUSE questions. For general ARM information, visit the openSUSE ARM Portal.

Why run openSUSE on your RPi 5

The official Raspberry Pi OS offers a simple desktop experience, but it is mostly geared toward desktop use and does not include features like containers by default.

With SUSE’s hardware enablement work, you can now get the full openSUSE experience on your Pi. Personally, I enjoy running Cockpit with combination of automatic updates, and I even run containers with my private openSUSE mirror and Nextcloud AIO in containers on my RaspberryPi.

Time to celebrate

To celebrate the hard work of the SUSE Hardware Enablement team, we have sent Raspberry Pi 5 starter kits and Debug Probes to our friends Dale from LowTechLinux and Liam from The Register to share their first impressions with the community.

We also brought a smile to the face of Tomáš, one of last weekend’s openALT.cz attendees, who won a Raspberry Pi 5 and Debug Probe in our openSUSE Quiz. The quiz application, widely used by the openSUSE Booth crew around the world, now features an “openSUSE Arm” section that helps participants learn more about openSUSE’s Arm efforts.

Stay tuned and keep watching our Raspberry Pi 5 Hardware Compatibility page. We will share more updates once USB boot and PCIe are fully functional on the Raspberry Pi 5.