In diesem Überblick beschreibe ich am Beispiel der Proxmox inventory source, wie eine eigene Inventory Source im Ansible Automation Controller hinzugefügt werden kann.

Die folgenden Schritte wurden mit der Ansible Automation Platform 2.4 getestet. Die einzelnen Schritte sollten in gleicher Weise auch in Ansible AWX ausgeführt werden können.

Um diesem Text folgen zu können, werden Kenntnisse im Umgang mit Ansible und Git auf der Kommandozeile vorausgesetzt.

Der Text verweist, wo möglich, auf bestehende Dokumentation. Es handelt sich bei diesem Text nicht um ein klassisches Tutorial. Er dient mir als Gedächtnisstütze und mag euch eine Anregung sein, bzw. im besten Fall die Wissenslücken schließen, die sich mit der Dokumentation allein nicht schließen lassen.

Ausgangssituation

Abschnitt 18.4.5.1. Inventory sources im Automation Controller User Guide führt die in der Ansible Automation Platform (AAP) unterstützten Inventory Sources auf. Möchte man nun bspw. Proxmox Virtual Environment (PVE), Microsoft Active Directory oder Cisco DNA Center als Quelle für sein Inventar benutzen, wird man auf den ersten Blick nicht fündig.

Für das Beispiel in diesem Text werden Hosts aus der Bestandsliste eines PVE als Inventory Source hinzugefügt. Die dabei verwendete Vorgehensweise kann auch für andere Inventory Plugins verwendet werden. Die Entwicklung von Inventory Plugins ist jedoch nicht Gegenstand dieses Textes. Hierzu wird auf die Dokumentation unter „Developing dynamic inventory“ verwiesen.

Mein Kollege Steffen Scheib hat mir geholfen, das Proxmox-Plugin zu konfigurieren, wofür ich ihm an dieser Stelle nochmal ganz herzlich danke. Es liegt auf meiner Arbeitsstation als Ansible Project in folgender Verzeichnisstruktur vor:

]$ tree proxmox_inventory/
proxmox_inventory/
├── collections
│   └── requirements.yml
├── inventory
│   └── inventory.proxmox.yml
└── vault_password_file

3 directories, 3 files

Mit Ausnahme der Datei vault_password_file wurden alle Dateien und Verzeichnisse in Git aufgenommen. Ich verwende einen einfachen Git-Server in meiner Laborumgebung, auf welchen ich meine lokalen Repositorys pushe. Der Automation Controller synchronisiert das Projekt aus dem Git-Repo, um es als Inventory Source verfügbar zu machen.

Die Vorgehensweise im Überblick

1. Ansible Credential für Source Control erstellen
2. Ein Ansible Projekt hinzufügen
3. Einen Custom Credential Type erstellen
4. Ein Ansible Inventory hinzufügen

Ansible Credential für Source Control erstellen

Das Proxmox Inventory Plugin befindet sich in einem Git-Repository, auf welches mit SSH-Key-Authentifizierung zugegriffen werden kann. Damit auch der Automation Controller auf dieses Repository zugreifen kann, wird ein Credential vom Typ Source Control erstellt.

Der SSH-Private-Key wurde von meinem Host hochgeladen und verschlüsselt im Automation Controller gespeichert. Der Key lässt sich in der GUI nicht wieder sichtbar machen, lediglich ersetzen.

Ein Ansible Projekt hinzufügen

Der Dokumentation folgend, wird ein Projekt hinzugefügt:

Wenn alles passt, wird das Projekt nach dem Speichern erfolgreich synchronisiert:

Dieses Projekt wird in einem späteren Schritt zur Erstellung des Inventory benötigt.

Einen Custom Credential Type erstellen

Bevor ich auf die Erstellung selbst eingehe, möchte ich kurz beschreiben, warum dieser Schritt notwendig ist.

Folgender Codeblock zeigt meine Datei inventory.proxmox.yml welche einige mit Ansible Vault verschlüsselte Werte enthält:

]$ cat inventory/inventory.proxmox.yml 
---
plugin: 'community.general.proxmox'
url: 'https://pve.example.com'
user: !vault |
          $ANSIBLE_VAULT;1.1;AES256
          30623661316338386633623162303036346562346238386162633263636164636338393532613565
          3332616265353962326139363533313261623739643765640a623032613034613139653162356266
          34646464323233313964663939643631313539353736313364333433643136306632633065633664
          3234346635396563350a656334353632643830353534386636306365656261356436613662623163
          31663535363264356537336531393731633164613733316537383433653334643433
token_id: !vault |
          $ANSIBLE_VAULT;1.1;AES256
          62356662336534646661353666356263363734666231643932393430336639363032303266636432
          3762343235633335613663393838343532326230353130380a616161313830373265306137346562
          61613662333764393565316362623838633332376366373161646237363163663039613863393439
          3165616664626633390a396465343430373837343662373634653634643138613131633034306432
          62623438366166353765366339323263393833396133653866343833663335663766
token_secret: !vault |
          $ANSIBLE_VAULT;1.1;AES256
          66386338643463373837666164396332306261366634396630306430663937613963346164636433
          3362396566343932393234353439383932316436396437380a336365393038373566383534623136
          30353332383464356664393666383664636536666531663463623232353136353636363366653431
          3234616531623537630a393530643437376363653438643036636436316636616265316361623661
          35313832613063633662363531346164306638373538393164373663633335333863646430663232
          6339343164633865636239356538326438333937366134613738

validate_certs: false

# fail if a variable is not resolvable
strict: true

# facts are required to retrieve proxmox_vmtype
want_facts: true

# only allow qemu VMs
filters:
  - "proxmox_vmtype == 'qemu'"

Auf der Kommandozeile meines Hosts kann ich den Inhalt des Dynamic Inventory wie folgt anzeigen lassen:

ansible-inventory -i inventory/inventory.proxmox.yml --list --vault-password-file vault_password_file

Die Datei vault_password_file befindet sich jedoch nicht im Git, da sie das Passwort im Klartext enthält. Aus diesem Grund möchte ich die Datei auch nicht auf dem Automation Controller ablegen. Irgendwie müssen auf dem Automation Controller jedoch Credentials hinterlegt werden, um die Ansible Vault encrypted_strings zu entschlüsseln. Die Lösung steckt in diesem Kommentar auf Github. Im Automation Controller User Guide gibt es dazu Chapter 11. Custom credential types.

Fertig sieht das dann so aus:

Das Schlüssel-Wert-Paar secret: true stellt sicher, dass das Passwort verschlüsselt gespeichert wird. Es kann danach im Automation Controller nicht mehr im Klartext angezeigt werden. Nachdem der neue Credential Typ erstellt ist, kann dieser instanziiert werden:

Das Vault Passwort wird in das entsprechende Formularfeld kopiert. Es ist standardmäßig nicht sichtbar und wird wie oben bereits erwähnt, verschlüsselt gespeichert. Mit diesem Credential verfügt der Automation Controller nun über die notwendigen Informationen, um das Proxmox Inventory auszulesen.

Ein Ansible Inventory hinzufügen

Zuerst wird ein Inventory nach Dokumentation erstellt. Anschließend wird diesem eine Inventory Source hinzugefügt.

Die Formularfelder sind dabei wie folgt zu befüllen:

• Name: Kann frei vergeben werden
• Source: Sourced from a Project
• Credential: Hier wird das im vorangegangenen Schritt erstellte Credential ausgewählt
• Project: Hier wird das in obigen Abschnitt erstellte Projekt ausgewählt
• Inventory file: Kann in diesem Fall auf `/ (project root)` gesetzt werden

Nach dem Speichern wird die Inventory Source durch Klick auf ‚Sync‘ synchronisiert:

Und wir haben 17 Hosts in unserem Inventory:

Damit endet dieser kurze Überblick auch schon. Ich wünsche euch viel Freude bei der Inventarpflege.

Software Freedom in Europe 2024

In 2024, we continued to promote software freedom through our presence at conferences and events across Europe, as well as through our various activities and initiatives. Despite our ongoing financial challenges, we have actively raised our voice in defence of Device Neutrality and are advocating for a dedicated Free Software budget in Europe.

After more than 20 years of promoting software freedom, we have reached a critical point, having faced significant financial challenges in recent years. Our ability to continue our vital work was severely compromised, as our work was threatened by a decline in supporters, compounded by economic pressures such as rising inflation. For the first time, we were forced to send out an urgent appeal via email - a heartfelt and unprecedented request for help to our community, emphasising that without immediate and substantial support, the FSFE's long-standing mission to protect and promote software freedom across Europe would be in jeopardy. Fortunately, the response from the community was overwhelmingly positive. Many supporters stepped forward and helped to stabilise our immediate situation.

Our work is far from complete, and continuous financial support is crucial to sustaining our mission. Software freedom is a long-term struggle that demands persistent effort, dedication, and resources. The importance of this ongoing fight is underscored by recent events, such as Apple's litigation with the European Commission to avoid complying with the Digital Markets Act (DMA). The FSFE is the only non-profit that is intervening, with the aim to leverage the voice of the Free Software community against the company’s unfair practices. This endeavour can take decades and it is a complex, time-consuming, and resource-intensive endeavour but we strongly believe that we need to be there to defend Device Neutrality and the interests of the Free Software community.

Unfortunately, the broader landscape for Free Software is facing more challenges. Recently, the European Union decided to cut its funding to the Next Generation Internet (NGI) initiative, highlighting a critical issue: the lack of secure, long-term financial support for Free Software. Software freedom requires not only nice words but also proper public funding. Free Software is essential for ensuring transparency, security, and innovation in the digital age, and without steady support, these values are at risk. It's crucial that policymakers recognize the importance of Free Software and advocate for its continued growth and protection to ensure that technology remains a tool for empowerment.

We have continued initiatives such as the Router Freedom wiki and our "Public Money? Public Code!" initiative, where we have started to focus more on watchdog activities, monitoring real progress towards Free Software in public administrations and speaking out when we see steps in the wrong direction. We continued to raise awareness of Free Software and its importance for a democratic society through active participation in conferences, celebrating the "I Love Free Software" day, and through the work of our local groups across Europe.

In the recent months we have continued focusing also on the younger generations. In this regard, the third edition of "Youth Hacking for Freedom" (YH4F) is underway, with preparations for the fourth edition already in progress. The Ada & Zangemann book is becoming a well-known open educational resource, being translated into 10 languages, while its readings continue to inspire and educate. Additionally, we are working on producing a film about Ada’s story to further amplify its impact and reach a broader audience.

As we navigate these challenges, it is clear that our mission to promote software freedom and empower users to control technology requires a sustained, long-term support commitment. The recent outpouring of community support is a beacon of hope, but the road ahead is long and fraught with obstacles. We must continue to advocate for the public funding and political support necessary to safeguard the Free Software community. By continuing to focus on education and public outreach, especially to younger generations, we are laying the groundwork for a future where software freedom could thrive. With your continued support, we can continue our work and ensure that we get closer to our vision of software freedom for the decades to come.

Table of contents

1. Device Neutrality: the Free Software community “shows its teeth”
2. Next Generation Internet and the lack of long-term sustainable funding for Free Software
3. Reaching Generation Alpha: Youth Hacking 4 Freedom and Ada & Zangemann
4. Policy work: Advocating for Free Software
5. Legal Support: giving advice to projects and individuals
6. Our work on public awareness
7. Join the movement

Device Neutrality: the Free Software community “shows its teeth”

Device Neutrality empowers users to take control of their devices, allowing them to choose how and what software they run, free from restrictions imposed by manufacturers or software vendors. This control is essential to ensure that users are not locked into a particular operating system or forced to use pre-installed applications. Device Neutrality promotes innovation, competition and consumer rights by preventing monopolistic practices and enabling a diverse software landscape.

Free Software is key for Device Neutrality, and this issue has become increasingly important as large technology companies tighten their grip on the devices and operating systems they control, raising concerns about privacy, digital rights and market dominance. In 2024, the FSFE has faced monopolistic power over devices head on. Notwithstanding the dangers of giant corporations over the entire digital markets, the FSFE performed key contributions to safeguard software freedom: we got involved in strategic litigation against Apple, coordinated key interventions with different civil-society stakeholders, and have been closely working with the Commission on the implementation of the Digital Markets Act. In all these processes, we leveraged the voice of the Free Software community, focusing on the benefits of smaller Free Software projects for digital markets.

Strategic litigation against Apple’s monopolistic control over devices

The Digital Markets Act (DMA), which came into effect in early March, introduces significant provisions that directly impact Free Software. This law requires "gatekeepers" to permit the direct installation of software from any source, commonly known as (sideloading). Additionally, it mandates that gatekeepers must support alternative app stores and repositories, giving users more choices in how they access and manage software. The DMA also imposes interoperability obligations, ensuring that third-party developers have access to the same hardware and software functions as the "gatekeepers." These measures collectively aim to enhance competition and innovation in the digital marketplace.

Apple was designated as “gatekeeper” in September 2023, but started litigation against the Commission in December, 2023. The company has pushed an aggressive approach against the DMA, proposing new terms and conditions that harm Free Software. In February 2024, the FSFE decided to intervene, pairing up with the Commission to protect Free Software against Apple’s strike against DMA. In August 2024, the Court of Justice of the European Union authorized the FSFE to intervene in the case. This is a far-reaching case with deep consequences not only for Software Freedom, but for fairness of digital markets, open internet and digital democracy.

Implementing the DMA: leveraging the voice of the Free Software community

As the Apple’s example demonstrates, abusive gatekeepers’ behaviour requires constant monitoring. Implementation of the DMA has been technically and legally challenging, as “malicious compliance” from gatekeepers has posed real risks to Software Freedom. The FSFE has been working with a large spectrum of community actors. For instance, the FSFE worked with F-Droid, The App Fair Project and other interoperability experts to investigate Apple's DMA compliance and its impact on Free Software. During the past months, we coordinated several expert workshops with stakeholders, discussed with regulators in FOSDEM, had official meetings with the EU Commission's DMA team, and submitted a comprehensive position to the European Commission detailing several problematic elements in Apple's compliance that will harm Free Software. FSFE also submitted a joint position to the Commission highlighting the main problematic aspects of Apple's behaviour towards Free Software. Furthermore, FSFE submitted its feedback to the United Kingdom’s Competition and Markets Authority on the regime guidance, emphasizing the importance of Free Software for fair digital markets, as envisioned in the newly enacted Digital Markets, Competition and Consumers Act (DMCCA). In collaboration with F-Droid, the FSFE also prepared a study for Japan's competition authority, the HDMC, on how Apple's compliance with the DMA poses a risk to Free Software and Device Neutrality.

We are calling for volunteers and civil society organisations to help the message against monopolization of digital markets resonate. We need robust support from policy makers for Free Software, so alternatives to gatekeepers can flourish in fair and safe environments.

In addition to this, at the beginning of August we have announced that we are intervening in the case of Apple vs Commission to uphold the DMA. It is litigation brought by Apple against the European Commission in the Court of Justice of the European Union. Following the FSFE’s application for intervention, the court recognized the FSFE’s interests in the case as a stakeholder and allowed the intervention. We will submit our arguments to the court by mid-September.

Router Freedom: several victories notwithstanding the outbreak from telcos

Although we should be free to choose the technical devices we use in our private lives, some Internet Service Providers (ISPs) still unduly limit how customers connect to the Internet, or discriminate against owners of alternative devices. This undermines Router Freedom.

In the last year, we have accomplished a lot! We participated and monitored regulatory processes in Germany, Austria, Italy and Belgium. Fiber operators have pushed against Router Freedom, bringing regulators to court and asking for regulatory exceptions. The FSFE has coordinated efforts with a broad spectrum of stakeholders, including volunteers, business representatives, digital right groups and consumer protection organisations to repel these reactionary initiatives from telcos.

• Germany: Fiber operators requested the national regulator BnetzAg to create an exception against Router Freedom, asking to take end-users’ freedom over equipment by imposing their own fiber terminals. The FSFE intervened in the process, claiming that Router Freedom is key for open internet and net neutrality, so the regulator should confirm its own 2016 decision to safeguard Router Freedom for all network topologies.
• Belgium: As a decisive victory, the Belgian regulator BIPT has introduced Router Freedom for all types of network in the country. The FSFE has participated as a key stakeholder in the process, contributing to BIPT’s work, presenting the views of the community and end-users. Later in 2024, the telecom operator Orange has started litigation against the regulator, asking for a exception for fiber, claiming the regulator was not diligent in the decision making. The court ruled against the operator, confirming the diligent work of BIPT in analysing all the benefits of Router Freedom for end-users and digital markets, stating all the allegations undue. This decision represented a decisive victory for Router Freedom, as for the first time, a court confirmed a regulatory procedure involving fiber networks. The FSFE demanded that other regulators take this as a good example.
Lucas Lasota, Legal Programme Manager, speaking at the DORS/CLUC 2024 conference on "When our routers are not free: the challenges for an Open and Neutral Internet".
• Austria: Despite the outcry of a broad spectrum of stakeholders demonstrating to the Austrian regulator RTR the necessity of regulating Router Freedom, the authority dismissed the case with no further consideration. The FSFE has been very active in the country, coordinating efforts with civil-society, industry representatives and policy makers, but nonetheless the regulator decided to follow the telecom operators’ interests in not attending to civil-society demands.

Making Router Freedom easier for users: the tech wiki

In addition to our policy and legal efforts to conduct a European-wide initiative to defend the rights and interests of end-users regarding Router Freedom, the FSFE has launched an initiative exclusively dedicated to end-users: a practical guide for interested technical people desiring to change their router provided by the ISP, helping them on the path (sometimes not so trivial) of installing their own private router at home. We introduce the new Router Freedom tech wiki, prepared by our Netherlands team of volunteers!🎉

This wiki helps you to replace the ISP’s router/modem with your own. Most modems of the internet service provider allow you to set them in 'bridge' mode, so you can use your own router for the internal networking. Although this allows you to separate your internal networking from the ISP, you would end up with two devices where you could just have one.

Device Neutrality website

This year we launched a new landing page about Device Neutrality to ensure that everyone, regardless of their technical background, can grasp the basics of this crucial concept. The landing page is designed to explain the essentials in a simple and easy way. By making it simple, we aim to raise awareness and foster a broader understanding, helping users recognize the importance of supporting and advocating for Device Neutrality in their own digital lives.

Also, following the page design, we created a poster with the basics which you can order from us to promote Device Neutrality in your office, university, or at events.

Next Generation Internet and the lack of long-term sustainable funding for Free Software

Although it had proven its success, a couple of months ago we found out that the European Commission is cutting its funding in the current draft for the Horizon Europe 2025 Work Programme. This decision highlights the larger problem of the lack of motivated and sustainable public funding for Free Software projects.

For years, we have been advocating for the need for public funding for Free Software, as software freedom guarantees that software remains a tool for empowerment, fostering independent development and innovation. Through our 'Public Money? Public Code!' initiative, which continues to gain support from organizations signing the Open Letter, we are raising awareness at conferences, events, and in explaining it to politicians.

Looking to the future, particularly in light of potential funding cuts for Free Software projects under the Next Generation Internet (NGI) initiative, it’s clear that sustainable funding for Free Software must be addressed at the European level. Establishing a long-term funding scheme is crucial. In the coming years, our policy efforts will focus on raising this issue across Europe, ensuring that fragmented, limited, and uncoordinated funding for Free Software becomes a thing of the past.

The recent cut of €27 million from the NGI initiative has exposed the vulnerability of financial support for software freedom, highlighting a critical problem: Europe needs sustainable, secure, and dedicated funding to maintain control over its technology through Free Software. Much of Europe's digital infrastructure depends on these projects to ensure technological independence and resilience. Reducing or cutting this funding endangers Europe’s autonomy in the digital realm. In response to the European Commission’s ambiguous stance on future funding, the FSFE has participated in the latest public consultation, advocating for the long-term financial backing Free Software solutions need to drive Europe’s digital transformation.

Since November 2018, the FSFE has been a partner organisation of Next Generation Internet Zero (NGI0), which is a coalition of non-profit organizations from all over Europe coordinated by the NLnet Foundation. Coming under the overall NGI umbrella, the purpose of NGI0 is to provide financial grants and technical support to researchers and developers who are working on Free Software solutions that contribute to the establishment of the Next Generation Internet. As a part of the NGI0 consortium, the FSFE is providing support to Free Software projects with their legal and licensing issues, as well as introducing them to the REUSE specification, a tool that can simplify the license process.

Currently, the FSFE is working on four NGI0 programs: NGI Entrust, NGI Core, NGI Review, and NGI Commons Fund.

REUSE, make licensing easy

REUSE helps make a project's licensing and copyright status more transparent, ensure that third-party code is properly attributed, and make the project's code easily reusable. This tool is currently used worldwide and its specification has been adopted by several corporate and institutional projects.

REUSE is constantly evolving and improving. Last June the alpha version v3.1.0a1 of the REUSE tool was released containing the new REUSE.toml functionality, and after the publication of the REUSE Specification v3.2, soon v.3.3 will be released. Currently, the tool is in its version v4.0.3.

More and more organisations, companies, and individuals are using REUSE and benefiting from the growing ecosystem of its specification, its helper tool, its API and all the documentation. As using REUSE does not require registration, there are not precise numbers about its users but we know that it is being adopted by:

• All 2000+ compliant projects of the REUSE API
• Many projects of the EU-funded Next Generation Internet project we help to become REUSE compliant from the start.
• DLR, the KDE community, and Software Heritage made REUSE the standard for their licensing policy.
• Corporate licensing policies of Siemens, SAP, Huawei, Liferay, and many more.
• Large parts of the Linux Kernel with ~70% by now.

Reaching Generation Alpha: Youth Hacking 4 Freedom and Ada & Zangemann

Educating and supporting the young generation in the learning and use of Free Software is crucial to the mission of the FSFE. Through our activities in this field we are fostering innovation, collaboration, and digital literacy in the future. We are supporting a generation that can control their technology and empower themselves. The children's illustrated book Ada & Zangemann introduces the concepts of Free Software to young readers, making these complex ideas accessible and sparking curiosity. Our Youth Hacking 4 Freedom contest is aimed at teenagers, who want to create, share and improve software.

With these two activities, the FSFE encourages the next generations to become active contributors to the digital world, shaping technology, rather than mere consumers.

Youth Hacking 4 Freedom: teenagers coding great ideas

Young people, from all over Europe, compete in Youth Hacking 4 Freedom to win cash prizes by creating programs of their choice licensed as Free Software. The six winners are invited to the Award ceremony weekend.

Second edition: In October 2023 we had the Awards Ceremony weekend in Brussels with the winners and members of the jury from that edition. 2023 winners were:

• Ultimate Hacker Award: Davide Rorato for ArduPlot
• Elite Hacker Award: Marlon Wolff for ClassQuiz
• Awesome Award: Simon Sommer for OpenRadio
• Best Maker Award: Oriol Villegas Martin for DogBag4City
• Best Freedom Project Award: Marius Angermann for Artix Engine
• Best Power User Tool Award: Matthias Kaak for hashfindutils

During this year we also learnt a bit more about some of the projects and their developers thanks to our YH4F interviews to participants.

Third edition: In October 2024, we will announce the names of the 2024 YH4F winners, marking the end of a journey that began at the end of 2023 when they registered to take part in this edition. From January to the end of June, the participants worked on their projects. During this time, they had the opportunity to meet online once a month and get advice from experts while networking with their peers. A broad group of technology experts, the YH4F Jury, then evaluated the projects submitted at the end of June.

Also during this year we presented this contest in different conferences such as FOSDEM, Chemnitz Linux Days and esLibre.

For the new edition, starting in January 2025, YH4F got a new sponsor on board.

Ada & Zangemann: Italian, French and Spanish version

The illustrated book "Ada & Zangemann - A Tale of Software, Skateboards, and Raspberry Ice Cream" by Matthias Kirschner, the President of the FSFE, tells the story of the famous inventor Zangemann and the girl Ada, a curious tinkerer. Ada begins to experiment with hardware and software, and in the process realises how crucial it is for her and others to control technology.

In recent months, we got a lot of amazing and interesting news about Ada, from book readings to new translations to the project of making a film of this story.

The first reading of the story of Ada in Italian took place during Software Freedom Day and to make it even more special, everyone enjoyed home-made ice cream thanks to one of our volunteers!

The story of "Ada & Zangemann" was also published in French and, thanks to the French Ministry of Education, you can download the ebook free of charge or read the mobile friendly online version. The book was translated into French by more than a hundred students, aged 13 to 19, from four different schools in France, over the course of the 2022-2023 school year, sharing the work and coordinating it using online tools.

The book was covered in a radio interview by "Radio France", in several articles, including Le Monde, ZDnet, or blogs, as well as TV coverage at Sqool TV with Alexis Kauffmann, from the French Ministry of Education and the person who started with the idea of the French translation.

And even more! The book was awarded the 2024 Youth Book Prize of the InCyber Forum Europe. This is the first time this prize has been awarded to a children's book. And 300 copies of Ada & Zangemann were distributed to teachers at the Journée du Libre Éducatif 2024. The book was presented at this fair, that this year was held in Paris, by two of the students who translated it.

Thanks to the Volkswagen Group in Spain, the story of Ada & Zangemann is now being printed in Spanish! The company has distributed 500 copies to its employees and, from September, its STEM team will be embarking on a 'STEM tour', visiting schools in several Spanish cities around the country to share the story encouraging children, and especially girls, to get into STEM.

To reach even more children, we are currently working to have an "Ada & Zangemann" movie produced by a professional 2D animation studio. We plan to release the movie in four languages by the end of this year as an Open Educational Resource under a Creative Commons Licence, the same one that Wikipedia has. Everyone will be able to download and share it, use it in schools, and integrate it with other educational material, making a difference to the quality of IT education that is so vital for young people in our digital society.

"They are young + they need the code", the FSFE's format to bring Free Software into the schools (online)

The FSFE's pilot project “They are young + they need the code” is inspired by the book "Ada & Zangemann". This educational format, designed by the FSFE, helps the children to understand the importance of controlling their own technology, through reading the book and manual activities. Currently the project is being tested in Italy, and we are waiting to hear back from our volunteers, who are bringing the format to the schools and libraries.

Free Software Knowledge IT Project, partnership with Edulife

At the end of last year, during SFSCON 2023, the FSFE and the Edulife Foundation kicked off a collaboration project to raise awareness about the benefits of Free Software to the next generation of innovators.

The project consists in a two-year agreement to deliver educational content to students from the ITS Academy LAST about Free Software legal aspects, policy and public awareness. Last January, and as part of this academic program, the FSFE delivered educational content about Free Software, with a focus on Free Software legal issues, policy aspects and public awareness in the form of lectures. In addition, again this year the students will attend SFSCON.

Policy work: Advocating for Free Software

Political decisions and policies within the European Union significantly impact Free Software, its ecosystems, and its communities. For 20 years the FSFE has engaged with policymakers to ensure that the Free Software community's voice is heard. Advocating at the European level for software freedom is essential to make decision-makers all over Europe understand the importance of Free Software in our society.

This past year has seen the adoption of important pieces of legislation which the FSFE has been active on, such as the Interoperable Europe Act, the Artificial Intelligence Act, the Product Liability Directive and the upcoming adoption of the Cyber Resilience Act.

Looking at the future, especially in light of the recent developments around the possible cuts of funding directed to Free Software projects with the Next Generation Internet (NGI) initiative, Free Software funding should be addressed at the European level with the institution of a long-term sustainable funding scheme. In the next year(s), our policy efforts will be also focused to raise this issue at the European level, and we will make sure that uncoordinated, scattered and small funding for Free Software will not be the norm any more.

Liability in the AI, PLD and CRA

During the past year, the EU has been debating the introduction of liability rules for software, including Free Software, in different legislation, namely the AI Act, Product Liability Directive and the Cyber Resilience Act. The way they were first proposed, all proposals would have harmed the Free Software ecosystem and thus the society and the economy.

The main debate around this proposal focused on liability. With different wording, the three proposals initially excluded liability of Free Software only outside the course of a commercial activity. This would have failed to address a large part of software that is deployed and at the same time smaller and non-profit projects would have been harmed as they would have to bear major costs and face legal risks even if there was any kind of commercial activity, like in the case of voluntary contributions to code.

At an early stage, the FSFE argued in a hearing in the EU Parliament, for the inclusion of clear and precise exemptions for Free Software development in the legislation and for liability to be transferred to those who significantly financially benefit from it on the market.

The co-legislators have largely complied with our demands and following intensive debates, have significantly improved the Commission’s proposal, by introducing an exemption for Free Software and including it in the articles of the regulations.

Even if with different wordings, this position has been voted in the PLD and the AI Act, but still needs to be finally voted in the CRA.

Interoperable Europe Act

The EU's Interoperable Europe Act aims to improve cross-border digital public services. The FSFE has called on policymakers to recognize the importance of Free Software in achieving this goal. Following the "Public Money? Public Code!" initiative, we have been emphasizing the need for public administrations to have control over the software they use while ensuring efficient use of public funds.

Despite efforts to include the Free Software community in the decision-making process through the soon to be implemented Interoperable Europe Board foreseen by the regulation, the Free Software community will only be involved in the Interoperable Europe Community. However, this involvement allows our Community to offer expertise, highlighting the need to closely monitor the regulation's implementation to identify opportunities for effective contributions from civil society.

While acknowledging some shortcomings and ambiguities in the wording of the Act, we welcome certain victories. For instance, the European Commission is now required to provide an annual report on Free Software interoperability solutions and support actions that promote these solutions. These measures will help assess the Act's success in prioritizing Free Software and allow us to continue our oversight role.

Cyber Solidarity Act

The Cyber Solidarity Act aims at strengthening collaboration among EU member states around Cyber Security, in order to strengthen solidarity and capacities in the Union to detect, prepare for and respond to cybersecurity threats and incidents.

In a hearing at the Committee of the Regions, we highlighted that in order to establish trustworthy and resilient systems, public bodies must ensure they have full control over the software and the computer systems at the core of their state digital infrastructure, and this is only possible by prioritizing the use of Free Software.

Furthermore we advocated for the inclusion of civil society in the implementation of the act, and we welcomed that legislators agreed on including different stakeholders in the legislation.

However, in the recent framework of EU regulations aimed at enhancing digital infrastructure security, in the Cyber Solidarity Act, legislators failed to recognise the importance of Software Freedom when it comes to developing ad-hoc tools.

Liability, Cybersecurity and Free Software

The FSFE, along with NLnet Labs and the Open Source Security Foundation, submitted feedback on the Network and Information Security (NIS) implementation act, emphasizing the need to protect the European Free Software ecosystem. The NIS2 implementation act, which focuses on cybersecurity regulations, also impacts the Free Software ecosystem in Europe. It's essential that these measures enhance cybersecurity without hindering Free Software development, as Free Software is a vital component in this field.

In their joint feedback to the European Commission’s draft NIS2 Implementing Act on "Cybersecurity risk management & reporting obligations for digital infrastructure, providers, and ICT service managers," the FSFE and its partners expressed concerns about the focus on business-to-business (B2B) relationships. They pointed out that many complex software products, central to the digital infrastructure sector, are developed by independent individuals, non-profit organizations, or academic institutions. In these cases, beyond the freedoms provided by Free Software licenses, there is no formal relationship between the developer and the entities covered by NIS2.

Public Money?, Public Code! demands at the European Union

The FSFE has also taken part in crucial consultations at the European level. For the FSFE it is important to give input in this kind of process as it makes the Free Software community’s voice heard, and we can make sure the community's demands reach policymakers in crucial phases of the legislative process.

• Software Freedom Funding

In the wake of the recent €27 million cut in the NGI funding, the FSFE has responded to the growing concern by asking the community to take part in a public consultation of the European Commission, which asked for feedback on their Digital Europe funding programme.

The community stressed theurgent need for sustainable, long-term financial support for Free Software to ensure Europe's technological independence. Europe needs sustainable, secure, and dedicated funding to ensure its control over technology through Free Software. Much of Europe's digital infrastructure relies on Free Software projects to ensure independence and resilience. Reducing or cutting funding threatens Europe's technological autonomy. With the participation of our community in the public consultation, we hope that Free Software solutions will receive the long-term funding they need.

We will keep you up to date on this issue, as the consultation will be at the end of the process at the time of publication of this report..

• European digital infrastructure needs a Free Software first approach

In its response to the European Commission's consultation on the white paper "How to Master Europe’s Digital Infrastructure Needs?", the FSFE highlighted the vital role Free Software plays in creating robust digital infrastructure across Europe. We argued that embracing software freedom can address challenges at various levels—global, regional, and local—by fostering collaboration, openness, and the ability to quickly resolve issues. The FSFE suggested redirecting IT investments towards Free Software instead of relying on closed-source, proprietary options. This shift would enhance Europe's IT landscape, create jobs, and save costs over time by reducing the need for redundant solutions.

Consultancy for public administrations

The FSFE not only demands Free Software friendly policies but also helps administrations across Europe to take concrete steps towards "Public Money? Public Code!". Since December 2023, the German Centre for Digital Sovereignty of Public Administration (ZenDiS) has contracted the services of the FSFE to advise them on Free Software and related issues. The scope of our consultancy includes strategies around ZenDiS’ products openDesk (the former Sovereign Workplace, a workplace solution for the public sector) and OpenCoDE (the code-sharing platform for public administrations in Germany), international cooperation and community engagement, criteria for Free Software procurement, stakeholder analysis, and providing input on topics such as Free Software supply chains, Free Software maintenance and fraudulent market behaviour.

Monitoring and watchdog activities as part of "Public Money? Public Code!"

Since the FSFE launched the "Public Money? Public Code!" initiative, we have welcomed every step towards more Free Software in public administrations. But in the last few years it has become clear that this is not enough. That is why FSFE decided to act more like a watchdog: While on the one hand we continue to call for Free Software friendly policies and point out best practices, on the other hand we closely monitor the implementation of Free Software policies and raise our voice when we see things going in the wrong direction.

A recent example of this stronger watchdog role is the situation around the German IT service provider Dataport and its openwashing software dPhoenix for public administrations, which FSFE continued to observe and comment on last year. As a result of our communication, Dataport stopped promoting dPhoenix as “Open Source” and admitted that it is proprietary. A more detailed explanation of the FSFE’s watchdog activities can be found in our Software Freedom Podcast Episode #22 on “Public Money? Public Code!”.

Openwashing is a topic the FSFE has been working on intensively over the past year. In the context of "Public Money? Public Code!", openwashing is not just a case of fraudulent labelling, but also leads to taxpayers being misled about how their tax money is being used. As we repeatedly receive reports of openwashing among bidders for public sector free software tenders, we have conducted a public community survey on the topic. We have gathered information, opinions and examples about openwashing to better understand the strategies and methods behind it, and to be able to come up with suggestions on how to tackle it. First results were presented at FrOSCon, together with ideas for better Free Software procurement, aiming to avoid pitfalls like openwashing, but also other kinds of problematic market behaviour.

When it comes to monitoring the implementation of Free Software policies, our tool TEDective can be of great help to analyse, understand and visualise the money flows in public tenders.

TEDective

During the past months, we have continued working on developing TEDective. This is a free software solution that makes European public procurement data explorable for non-experts.

This year we got the help of some students that improved the took and added some results.

Some of the improvements:

• eForms the EC standard, has been introduced and implemented.
• Improvement of the currency conversion.
• New deduplication model, based on clustering algorithm for organizations.
• Improved API endpoints & graph queries.
• New search filters for end-users.

We will continue working on this initiative, as well as spreading the news about it in different events and conferences, and we are looking for contributors who would like to get involved or fund the project. Get in touch via tedective@fsfe.org if you are interested!

Legal Support: giving advice to projects and individuals

At the FSFE we help answer licensing questions, provide technical support to make licensing easier (among others, with REUSE), provide legal education materials on Free Software, and organise an annual conference for the FSFE's legal network, the Free Software Legal and Licensing Workshop (LLW). We are also part of several EU-funded projects, helping with legal concepts and issues.

ZOOOM project

This year, the FSFE completed its work on the European Commission funded ZOOOM Initiative. The aim of this project was to raise awareness of the importance of managing rights and obligations related to Free Software, Open Data, and Open Hardware, especially when doing so in relation to innovation in digital industries.

As part of our work with ZOOOM, the FSFE produced research and educational materials on Free Software legal issues, which contributed to a larger toolkit on Open Software, Data, and Hardware. In addition to the usual discussions regarding Free Software licensing, this material also includes analyses on developing trends in digital innovation, which primarily focused on Free Software's role in developments in large language models, and artificial intelligence. This work, along with the work produced by our ZOOOM consortium partners on Open Data and Open Hardware, is to be included in education, business creation, and innovation programs across the EU that aim to build expertise in European small and medium-sized enterprises (SMEs).

Another part of our work with the ZOOOM initiative was to promote and to disseminate the research that we've conducted on these topics. You may have over the past 12 months seen FSFE staffers at various conferences across Europe, connecting with local communities and raising awareness on the importance of understanding our rights and obligations when working with Free Software, as well as with Open Data and Open Hardware. Although the project has officially come to a close, the ZOOOM toolkit and training materials are a useful tool to promote a healthier ecosystem where Free Software legal and licensing obligations are understood and followed across various digital industries, and where the ideals of Free Software are upheld.

Legal Network and LLW 2024

The FSFE continued to support the Free Software legal community with our continued coordination of the Legal Network this year. The Legal Network is a global community of legal professionals from diverse fields, all working on legal and licensing issues related to Free Software. The Legal Licensing Workshop (LLW) provides a neutral and safe space for participants to engage in discussions, even on controversial topics, fostering mutual learning and collaboration.

This year, our facilitation of the Legal Network has led to the discussion and proliferation of legal understanding in the international legal community of a number of trending topics, including the relevance of Free Software licenses to the development of large language models, developments in litigation efforts to enforce copyleft in various jurisdictions, as well as the ever constant detailed dissection of the effects of various licenses.

As part of our support for the legal community, we also organized our annual Free Software Legal and Licensing Workshop (LLW) in April for the legal professionals on our Legal Network to meet in person to present their work, and to discuss legal issues and best practices surrounding Free Software legal and licensing issues. As in 2023, this year’s event was once again held in Gothenburg, Sweden, at the Chalmers Conference Center, over 3 days.

While the LLW conference is always a great opportunity for Legal Network members to share their projects and research findings, or to engage in thought provoking discussions on both the practical and philosophical aspects of Free Software legal practice, this year’s conference was also a great opportunity for participants to catch up with one another in person, and to meet new Legal Network members. It is the aim of the FSFE that building such professional relationships helps to build shared consensus in the practice of law related to Free Software across jurisdictions, and to reduce friction in the famously prickly legal sphere. We are happy to say that with the extremely smooth running of the 2024 edition of the LLW, we have been successful in this aim this year.

We look forward to organizing the 2025 edition of the LLW in Essen, Germany, at the Unperfekthaus.

Our work on public awareness

We are deeply committed to raising public awareness of Free Software, and our website plays a central role in this effort. It serves as a comprehensive resource, providing information about the basics of Free Software, our ongoing activities, and our vibrant community. In recent months, we have focused on improving the attractiveness and usability of the site. In particular, we've redesigned the front page and introduced a new categorisation system for our publications to make them more accessible to readers. We've also revised the structure of our activities page. Our press site has also been redesigned to help journalists find the information they need more easily and quickly.

Since September 2023, we have published 55 news items in English, our official outreach language, but some of these publications have also been translated into other European languages, mainly thanks to our awesome team of translators. Besides, we publish monthly email updates in which our experts inform our subscribers about current news, events, activities, and how you can contribute.

From a technical standpoint, we have overhauled the translation status page. It now displays the files that need translation for each language, prioritized by the importance of the files—essentially based on how many clicks it takes to reach the page from the front page. The status page also links directly to the source files in Git and the Webpreview tool, which shows the current translated version. This should make it easier to resume translation work. Additionally, for some time now, translated pages with a newer English version have shown a warning indicating that the translation is outdated. Also, currently if a translation is too outdated, instead the EN original will be displayed again.

Another technical improvement that we have done these past months was in the event registration. An event can now be linked to a local or topic group and will automatically be added to the group's calendar, which is accessible from the group overview page and can be integrated into calendar apps via CalDAV, just like other calendars in Nextcloud. For proper integration, events now include start and end times. The existing ICS file also correctly uses these dates, allowing subscribers to see the event times in their feeds. Additionally, events can be automatically sent to the group’s mailing list, though this feature hasn't been used by any group yet. The process for adding events to our events page has also been partially automated—a pull request is automatically generated for new events, collecting all language versions, and the event filename is adjusted accordingly. This version improves clarity, reduces redundancy, and streamlines the explanation. Let me know if you'd like any adjustments!

We also have made some progress in the migration from wiki.fsfe.org to docs.fsfe.org, but still we need to continue working on it during the next months. Last but not least, over the past year we switched from the old ticket system to the new one.

We have also continued with our Software Freedom Podcast. This year we published 4 episodes, which might be a bit less than previous years but the person in charge was on maternity leave for several months in 2024.

This year, in the podcast we talked about PMPC, the current status of Free Software in our society in US and Europe, we had a special episode at Christmas about "What is Free Software" and we learned about MirageOS.

We also have a number of social media channels, the main ones being Mastodon and Peertube, where we post more frequently, using the ones that are not part of the Fediverse to promote topics and issues related with the main audience of those networks.

I Love Free Software Day

"I Love Free Software Day" 2024 focused on the younger generations and how to introduce them to the Free Software community. Therefore, several of our local groups celebrated this day with a meeting focused on younger people.

The FSFE planned a special gift for several organisations and long-term volunteers to prepare them for I Love Free Software Day. We gave them an acrylic glass heart and an LED strip, and a microcontroller and some jumper cables. The challenge? To tinker with these things and upload a picture of the heart on 14 February. It turned out to be quite a challenge, but a lot of fun!

For the 2024 celebrations, over a hundred people came together in 13 local meetings - either online or in person - organised by FSFE chapters or other Free Software groups in seven different countries.

Merchandising and Info Material

This year we worked on adding new stickers to our -already- great collection.

At the end of last year, we focused on expanding our already impressive sticker collection. With our team's creativity, we developed new slogans and illustrations, resulting in fresh stickers in a variety of colours and formats.

In the months that followed, we attended various conferences and events, where we gathered valuable feedback on these new stickers.

We also took the opportunity to refresh our merchandise. By the end of 2023, we introduced two new T-shirts: a new colour for our classic “There’s No Cloud” design and a striking new graphic for the "Hacking for Freedom" slogan. Both T-shirts have been well-received, alongside another exciting addition to our web shop and event displays—the vibrant red “I Love Free Software” socks.

At the start of summer, we ran a successful sale offering free shipping for two weeks, resulting in over 100 orders, including several large ones.

Our community

While our local groups have continued with their activity in their local and regional levels, this year we have continued with the online coordinators’ meetings. Besides organizing booths and being at events -even in Asia- our volunteers have also been involved in several activities such as PMPC, Ada & Zangemann….

This year we also activated a new local group, that is going to focus on Poland

In Italy, we had a fundraising innitiative, in which we gifted all supporters and ex-supporters a copy of the book and informed them about the activities happening in Italy.

FSFE Netherlands connected with the local free software community by hosting info stands, an ILoveFSDay event and an introductory presentation at WikiconNL. They continued the discussions online and in chat, moving forward on topics like banking apps and education. The Dutch Ada Zangemann book translation is progressing and could benefit from sponsors for the print run.

This year we also spent a nice day with members of the Italian community in Bolzano, going on a hike with them the day after SFSCON. And in the summer we were back at the LinuxHotel for our now traditional summer meeting! During a long weekend we spent time with volunteers, learning about current work topics and getting feedback. We even had time to get to know each other a bit better with some networking games and in the evenings.

Join the movement

Become a supporter: Your support and contribution for the promotion of Free Software are important for securing our continuous work, ensuring our independence, strengthening our democratic society, promoting and implementing concrete steps towards software freedom, and making it easier to use and develop Free Software.

Advocating for freedom costs money and we depend on people like you to support us. Thanks to all our supporters and special kudos to our donors. We guarantee that all support is used to foster software freedom in Europe a little more each day, step by step, bit by bit for the next decades.

With your help we can keep on defending software freedom. Thank you for your trust, your support, and your ideas to continue bringing Free Software to our society!

Support FSFE

Software Freedom in Europe 2025

In 2025 we remained engaged in enforcing the DMA, intervening in the Apple vs EC legal case; we participated in the debates around the CRA and public procurement to ensure that Free Software is embedded in Europe’s digital future. Also, we continued providing legal support and improved REUSE, while involving teenagers with YH4F, and we reached new audiences with the new Ada & Zangemann movies.

As we look towards the year 2048, we know the kind of world we are aiming for. Our vision for 2048 is clear: a world where everyone has the right to remove and install any software on any device, where public funding for software is exclusively allocated to Free Software, and where regulatory frameworks actively encourage the development and use of Free Software. A world in which young people have the opportunity to tinker, experiment and code with Free Software as the default and Free Software contributors should be able to focus on contributing to society without constantly worrying about legal issues. In 2025, we took significant strides toward this vision.

In the realm of Device Neutrality, we advanced our case against Apple at the European Court of Justice, challenging restrictive practices that hinder user choice. Simultaneously, we celebrated Germany's confirmation of Router Freedom, a victory that empowers users to choose their own router hardware. In Italy, our coalition work influenced fiber network regulations, ensuring they protect end-user rights.

Legal support and education remained at the forefront of our initiatives. We updated the REUSE specification and tools, launched the Legal Corner column, continued helping with legal questions and achieved another edition of the Free Software Legal and Licensing Workshop (LLW), while continue being active in the NGI consortium.

Engaging the next generations, we hosted the fourth edition of Youth Hacking 4 Freedom, programming contest and inspired teenagers across Europe to create innovative Free Software projects. With "Ada & Zangemann - A Tale of Software, Skateboards, and Raspberry Ice Cream" we continued to captivate young minds, with the animated movie reaching audiences worldwide, while adding more translations and reaching to more and more children through readings and events.

We were actively participating in discussions around the AI Act, Cyber Resilience Act, and public procurement, emphasizing the importance of integrating Free Software principles into legislative frameworks shaping markets that benefit Free Software users and developers. We continued working on our "Public Money? Public Code!" framework, including an event for local governments.

Community engagement flourished through various events and outreach activities. We celebrated the "I Love Free Software Day" with events in multiple countries, highlighting the often-overlooked Free Software projects that power our daily lives. Our presence at conferences such as FOSDEM, SFSCON, DevConf.CZ, etc. facilitated meaningful discussions and strengthened our network.

Behind the scenes, our technical team enhanced infrastructure resilience, optimized website performance, and improved accessibility, ensuring that our digital infrastructure effectively serve our growing community. This year, we bid farewell to our office space at Schönhauser Allee after many years of having it as our home base. The generous donation of the Software Freedom Flat (SFF) by Reinhard Wiesemann and our move there, marks a pivotal moment, as it provides dedicated spaces for the FSFE's team and volunteers for living there and collaborating with each other.

Reflecting on these accomplishments, we are reminded that the journey toward our 2048 vision is a collective effort. It is through the dedication of our supporters, volunteers, and partners that we continue to make meaningful progress. Together, we are shaping a future where software freedom is a reality for all.

Table of contents

1. Device Neutrality
2. Free Software Markets and PMPC
3. Young Generation
4. Legal Education
5. Volunteer Engagement
6. Core Infrastructure
7. Join the movement

Device Neutrality

The FSFE’s work on the Digital Markets Act (DMA) has been twofold. Since the beginning of 2024, we have intervened in a key case before the Court of Justice of the European Union (CJEU) involving Apple and the European Commission. At the same time, we have actively contributed to the implementation of the DMA, working to ensure it is applied in a developer-friendly way that empowers Free Software developers and strengthens Free Software in general.

The FSFE remains the only civil society organisation engaged in private enforcement of the DMA, intervening for Free Software in a key court case involving Apple and the European Commission. Apple is trying to avoid obligations derived from the Digital Markets Act (DMA). The FSFE seeks to hold Apple accountable under the DMA in a developer-friendly way.

In summer 2024, the CJEU granted the FSFE the right to intervene in the proceedings. By September 2024, we had submitted our legal arguments to the Court, and we now await its decision.

Regulatory Intervention to protect Free Software and Interoperability

Alongside litigation, the FSFE has engaged proactively with the DMA’s regulatory processes. By the end of 2024, we had begun a comprehensive study on how Apple’s restrictive interoperability policies harm Free Software. The findings were first presented in November 2024 during a conference on DMA implementation in Brussels, and later in the DMA and Beyond Conference organised by the Knight-Georgetown Institute and Yale University in Washington, D.C., in February 2025.

In January 2025, the FSFE joined civil society organisations, developers, and researchers in submitting a position to the European Commission’s public consultation on Apple’s compliance with the DMA’s interoperability requirements. We stressed the urgent need for Apple to provide effective and free-of-charge interoperability. Following nearly a year of regulatory dialogue, the Commission concluded its specification procedure on Apple’s compliance with Article 6(7), covering both software and hardware interoperability. Throughout this process, the FSFE provided technical analyses, academic research, and active contributions to consultations, while also building a coalition of Free Software projects directly affected by Apple’s policies.

Although the Commission stopped short of requiring interoperability by design, its final decision reflects many of our arguments. Developers now benefit from greater clarity, including a timeline for Apple’s responses to interoperability requests and an appeal mechanism to challenge Apple’s decisions. Apple must compete on innovation rather than imposing unilateral security standards.

To continue monitoring how gatekeepers implement their interoperability obligations and to ensure that Free Software is not harmed, the FSFE launched the Interoperability Survey. This initiative collects structured feedback from Free Software developers, referred to as “access seekers”, about their experiences when requesting interoperability under Article 6(7) DMA. The survey aims to foster innovation and support alternative solutions developed by the Free Software community. Developers who have submitted, or plan to submit, an interoperability request are encouraged to participate.

In addition to legal and regulatory engagement, the FSFE has worked to raise awareness about the importance of the DMA and its implementation. Over the past year, we have contributed to conferences and events across Europe, produced an episode of the Software Freedom Podcast, and organised two workshops. One of these workshops was dedicated to Free Software organisations, while the other was hosted by the German Open Source Business Alliance, where we highlighted the DMA’s potential for Free Software companies.

Successes for Router Freedom

2025 has been a successful year for Router Freedom. Our work in this field collected victories in Germany and extended interventions in regulatory processes in Italy. More and more users can enjoy the freedom to use their own equipment to connect to the internet, run Free Software on their devices and get rid of internet providers’ lock-ins!

In Germany, after 10 years the regulator Bundesnetzagentur has finally confirmed Router Freedom in the country. After a failed attempt by internet providers to exclude Router Freedom from fiber networks, the Bundesnetzagentur rejected all the arguments brought forward by the telecom operators, explaining in detail why freedom of terminal equipment is crucial for end-users. The FSFE has been pushing for this since 2013, submitted a detailed position paper debunking the arguments of the fiber operators. We have demonstrated that Router Freedom represents freedom of choice, security, consumer welfare, fair competition and sustainability.

In Italy, the situation remains challenging, but we work hard to achive the best outcome for end users. Although the country was among the first to introduce Router Freedom for DSL connections in 2018, the national regulator AGCOM later introduced exceptions that weakened this right for fiber networks. In 2024, we worked with a coalition of organizations and volunteers to demand a formal regulatory process.

This effort brought a considerable victory in February 2025, when AGCOM’s consumer division launched a regulatory process to decide whether consumers can freely choose their own routers and modems for fiber connections. During the public consultation, the FSFE mobilized a broad coalition of stakeholders (including civil society, industry representatives, hacker spaces, and Linux User Groups) and submitted a comprehensive study defending users’ rights. While a final decision is still pending, we continue to monitor developments closely.

On the European level, Router Freedom continues to be a priority for the telecom sector. Several topics are still unclear and will require further analysis and commitment to public awareness and education towards decision makers. For instance, Router Freedom is not currently guaranteed in satellite networks, and the diverse cross EU legislation for cybersecurity in radio equipment will led to further restrictions imposed on end-users.

Refund4Freedom - reclaim the costs of unwanted Windows licenses

In 2025, consumers still face the widespread practice of being forced to purchase computers bundled with Microsoft Windows, without the option to refuse the license or obtain a refund. This situation obliges users to pay for software they may not wish to use, restricting their freedom of choice. The FSFE said Basta!

Together with the Italian Linux Society (ILS), we launched the Refund4Freedom initiative. The project supports consumers in reclaiming the cost of unwanted Windows licenses, documents manufacturers’ refund practices, and raises awareness about unlawful software bundling. It also advocates for fairer policies from hardware vendors, ensuring that users can freely choose their preferred operating system.

With Microsoft ending support for Windows 10 in 2025, the initiative also underscores the opportunity for users to adopt a GNU/Linux distribution. In this context, the FSFE supports the End of 10 campaign. For example, since spring 2025, the FSFE’s Berlin group has been organizing regular “End of 10 Install Parties,” in cooperation with other local actors. These events provide users with guidance on migrating to GNU/Linux distributions and offer support in addressing their questions. Other FSFE groups are also active on this issue, and a dedicated FSFE Matrix room provides further information and coordination.

Free Your Android

Since 2012, we have been running the Free Your Android initiative to help Android users reclaim control over their devices and data, encouraging the use of Free Software apps and operating systems, and highlighting how people can switch to or support alternatives that respect user freedom. As an long running activity, we have been monitoring the situation there, and talked about it at our booths or at workshops, such as the one that took place last spring in a library in Berlin or at Devconf.cz.

In the last months Free Software on Android phones is facing serious challenges. With current versions of Android, Google delays publication of the source code and completely withholds crucial components like hardware specific code for their own devices. This significantly complicates ROM development for anyone who does not directly partner with Google, so especially Free Software ROM developers. At the same time, Google is trying to restrict developer access in general by requiring registration, further worsening the situation for software freedom on phones. At the same time, CalyxOS has announced that they cannot provide software updates until further notice and it's still unclear how this situation will resolve.

The FSFE is responding proactively by closely engaging with developers and other stakeholders to safeguard freedom and privacy on phones. We are also in the process of updating our Free Your Android pages to reflect the changed landscape. This will make sure we provide clear, up to date advice to help users choose software that ensures long-term freedom.

We also hope that EU regulations such as the DMA will help in this respect.

REUSE - make licensing easy for humans and machines alike

We end up 2024 with the release of the REUSE Specification 3.3 and REUSE tool 5.0.0, making it even easier to license your code as Free Software. REUSE provides all the tools and documentation that developers need to apply standards-compliant and comprehensive licensing information to their projects, without needing to be a legal expert.

REUSE continues to evolve thanks to steady input from a vibrant global community, both in the form of issues, code contributions, and general feedback. This year presented an unexpected challenge when the primary maintainer had to temporarily step down due to illness. Although these kinds of transitions are never easy, we did our best to make it as smooth as possible and the software remains in capable hands.

A major success this year was the move of Arch to adopt REUSE. In RFC 52, the developers propose using REUSE for license annotation in their packaging. This step by a major distribution is a great example of how REUSE helps by providing machine-readable licensing information and simplifying processes.

The REUSE tool plays a crucial role in ensuring that NGI (Next Generation Internet) projects comply with Free Software licensing best practices. REUSE provides a simple, standardized method to embed machine-readable licensing information directly into project files, making it easy for both humans and automated systems to verify compliance. This clarity fosters trust among collaborators, funders, and end users, and it significantly lowers the barriers to adoption and reuse of NGI results.

In the last months, we have actively continue supporting NGI projects in adopting REUSE by offering direct advice, training materials, and guidance on implementation. Through workshops, documentation, and consultations, we help project teams understand the importance of licensing clarity and how to apply the REUSE standard to their own work.

Free Software Markets and PMPC

In Software Freedom in Europe 2024, we warned about the European Commission’s plans to cut funding for NGI projects. As we highlighted in a statement in November 2024, the European Commission’s recurring uncertainty around budget allocations underscores how fragile essential Free Software support remains. Without predictable, long-term public investment, projects that underpin Europe’s digital autonomy risk being left dependent on fragmented or short-lived sources of funding. The future of our digital independence requires stable and sustainable financial backing, not on short-term funding that can vanish with the next budget draft. For years, the FSFE has highlighted how Free Software is key for the backbone of Europe’s digital infrastructure, and through our Public Money? Public Code! initiative we have shown how making publicly funded software available as Free Software strengthens that backbone by ensuring transparency, reusability, and independence. The past year has shown that ensuring its resilience requires long-term, structural funding commitments.

Over the past year, we have been advocating for this. At SFSCON 2024 in Bolzano and at the OpenSouth Code in Málaga in 2025, we had underlined that Free Software requires permanent funding structures. In collaboration with other stakeholders, FSFE co-organized the FOSS Funding devroom at FOSDEM 2025, where developers, funders, and policymakers discussed the future of financial support for Free Software projects.

Beyond conferences, we has also worked to broaden the conversation through our communication channels. In episode 26 of the Software Freedom Podcast, we explored the systemic funding challenges Free Software faces, offering insights into why public institutions and governments must guarantee stable support rather than relying solely on voluntary or market-driven contributions. This perspective was further reinforced by the FSFE’s official contribution to the EU’s long-term budget consultation, where the organization called for a dedicated, structural funding line for Free Software at the European level.

Sustainable funding must also be accompanied by better public procurement practices. Currently, many EU institutions and national administrations still default to proprietary vendors, locking themselves into costly and inflexible contracts. By prioritising Free Software, Europe could ensure that public money is invested in solutions that remain reusable, transparent, and accessible to all.

In June 2025 the Industry Committee voted on procurement to focus on interoperable solutions, and pointing to the benefits of Free Software in fostering competitiveness and innovation thanks to its global character, although its report lacked of concrete measures. Further insights into this issue were discussed in Software Freedom Podcast episode 34 and in the episode 35, where we provided an in-depth analysis of the EU's Tech Sovereignty vote, highlighting the critical role of Free Software in achieving technological independence. On the other hand, we contributed with a statement to the EC consultation on this topic.

This is precisely the vision behind Public Money? Public Code!: software paid for by the public should serve the public. Combining structural funding with Free Software–friendly procurement would provide not only the financial security but also the political framework needed for Europe to fully reclaim control over its digital infrastructure.

During these months, we have also continued our engagement with key European regulations, particularly the Cyber Resilience Act (CRA) and the AI Act. As part of the Dialogue on Cybersecurity project, the FSFE and the Federal Office for Information Security (BSI) are working are working together with representatives from civil society, academia, industry and public authorities in a project on the Cyber Resilience Act (CRA) and its implication for Free Software. through expert talks, a questionnaire to call for CRA stewards for their active input, and talks at FrOSCon 2025 and another at Datenspuren 2025.

On the AI Act, we were advocating for strong safeguards and transparent governance of AI systems in Europe. The episode 36 of the Software Freedom Podcast discusses our call on the European Commission to implement the AI Act in ways that respect Free Software.

While these examples show up our ongoing commitment to ensuring that emerging EU regulations both protect digital rights and empower the Free Software ecosystem, reinforcing Europe’s technological independence and resilience, we are also working to help people and organisations understand how Free Software fosters freedom, transparency, and self-determination, and to encourage its use and development. To this end, we organised the symposium “Public Money? Public Code! in practice” in Essen in April 2025, with a focus on public administrations – especially municipalities. Experts from politics, public administration, business, academia, and civil society discussed why Free Software is indispensable for digital sovereignty, how effective procurement can work, what resources are needed, and how administrations can proactively move forward.

Building on this success, we piloted and launched a new Public Money? Public Code! activity for volunteers across Europe. With a blueprint now in place, the next edition is planned for Denmark in 2026. We invite volunteers in other countries to bring the symposium to their local context – and we are ready to support with project planning, topic selection, speakers, implementation, and communication.

"Public Money? Public Code!" in Germany

At the end of 2024, Germany’s coalition collapsed without fulfilling promises to advance Free Software in public administration. A Bundestag hearing shortly before the elections gave us the opportunity to contribute strong arguments for Free Software to the parliamentary record and to warn against openwashing. Our #SFP27 podcast looks more closely at the hearing and explains our position.

The FSFE monitored the election period and the formation of the new CDU/CSU–SPD government: We called on parties to commit to “Public Money? Public Code!”, secure long-term funding for Free Software, deepen administrative Free Software knowledge, and monitor progress.Consequently, the coalition agreement announced ambitious goals for Free Software, but failed to offer details or measures.

To this day, it remains unclear what these goals are and what role Free Software will play for Germany’s technological sovereignty. Despite promises to make Free Software the guiding principle of digital infrastructure, the current federal budget and the procurement reform missed key opportunities to advance Free Software. Whether the planned stack will consistently rely on Free Software and ensure European interoperability also remains uncertain. After the government’s first 100 days, we pointed out these shortcomings in a detailed analysis and made clear: Germany and Europe need Free Software – the time to act is now!

MP Explore to reach representatives

In order to streamline part of our policy work and to support other small organisations in such work, this year we developed MP Explore, a tool designed to retrieve official and publicly available up-to-date contact information about parliamentarians. This information help us to to reach representatives from several parliaments, when doing our policy activities.

MP Explore relies on well-maintained data sources that collect up-to-date, official, and accurate information of MPs across Europe. Such data sources are based on official and publicly accessible sources from parliaments. Currently, we have developed data sources for the European Parliament, the German Parliament (Bundestag), and the North Rhine-Westphalia State Parliament (Germany).

Thanks to the contribution of our volunteers, we are currently coordinating the creation of MP Explore Sources for parliaments in Belgium, Denmark, Italy, and Norway.

Young Generation

Ada & Zangemann the movie

Since its first publication at the end of 2021, the illustrated book Ada & Zangemann – A Tale of Software, Skateboards, and Raspberry Ice Cream has found its way into homes, schools, and libraries around the world.

But in October 2024 a new milestone was reached: Ada & Zangemann came to life on the big screen! On Ada Lovelace Day, the movie premiered worldwide. This achievement was only possible thanks to the support of our community. The first English screening featured special guests Vint Cerf, one of the “fathers of the Internet,” and Franziska Heine, Executive Director of Wikimedia Germany.

The celebration continued in Germany: on 27 November, the film premiered in Essen, in the country’s largest cinema, where over 800 guests, most of them children, enjoyed the fairy tale on the big screen.

In 2025, the movie reached even more audiences, with new releases in:

• French, supported by the French Ministry of Education
• Spanish, thanks to Volkswagen Spain
• Danish, once again made possible by our dedicated local group in Denmark and with a premier screening in Aarhus.

You can explore all versions of the movie here: ada.fsfe.org/movie. The movie is in our YouTube and Peertube channels, where some versions are already more than 2100 single viewers. As it is distributed under a Creative Commons license, anyone is able to download and share the movie, embed it on websites, use it in schools, display it at events including cinemas (for which we provide special movie files), and integrate it with other educational material, making a difference to the quality of tech education that is so vital for young people in our digital society.

Meanwhile, the book itself continues its global journey, having distributed over 15.000. Originally published in German and English, it is now published in 11 languages, most recently Danish, through the incredible efforts of our local group there, who not only translated the story but also created a publishing company to bring it to life.

Altogether, more than 25,000 children worldwide have discovered Ada’s story through books, readings, screenings, discussions, and workshops.

And there’s even more: thanks to our Italian volunteers, Ada & Zangemann can now be enjoyed as as an audio book in Italian. Other Italian volunteers created an Ada & Zangemnann themed mini-game on the Luanti gaming platform .Try it out!

Readings have also taken place in Italy, Spain, rural Germany, and as far away as Sri Lanka! And thanks mainly to the amazing work of our volunteers, this year the improvements to the Ada & Zangemann git repository continued. The docbook source format was merged and expanded to support more output formats, including the previous source format for backwards compatibility. Online translations on Weblate are now possible because of this, resulting in 28 languages in some state of progress. The automation is being improved with the community, with plans for better documentation and more formats like the online digibook by C&F Editions and the Kamishibai format by Squeeek.

Interesting fact: on 10 November 2024 Ada was featured as Media of the Day on Wikimedia Commons.

They are young + they need the code

The FSFE's pilot project “They are young + they need the code” is also using by the book "Ada & Zangemann". This educational format, designed by the FSFE, helps the children to understand the importance of controlling their own technology, through reading the book and manual activities. Currently the project is being tested in Italy, and we are waiting to hear back from our volunteers, who are bringing the format to the schools and libraries.

This educational format can take place in schools or libraries, where volunteers read the book or play the audiobook and then guide the children in an activity such as a treasure hunt, robotics lab, or drawing session. Through this mix of storytelling and hands-on learning, children discover the importance of controlling their own technology"

Youth Hacking 4 Freedom

One more year, one more round of Youth Hacking 4 Freedom. And another one on the way! In October 2024, we went to Brussels for the 3rd YH4F Awards Ceremony. Once again, we were impressed by the quality and creativity of the projects submitted. This round was also the first time we had some team projects among the winners.

2024 winners

• Ultimate Hacker Award: Gaspard with ‘Versia’, a federated social network based on the Versia protocol.
• Elite Hacker Award: Sofía with ‘Identity’, an app that helps people in palliative care or suffering from dementia to save their most meaningful memories.
• Awesome Award: ‘Eventfully’, a team project by Konrad, Luis, Benedikt, Dorothea, Leonie and Jona: a software to find and explore events in your area, connect with others, and learn more about culture, technology and other topics from one website.
• Creative Hacker Award: Manuel with ‘YLLM4F (Youth Large Language Models 4 Freedom)’, a platform, that combining three advanced language tools, ensures that chatbots interact in a youth-friendly way.
• Epic Game Award: Corentin, Edmond and Tipragot with ‘Beats into shapes’, a rhythm game where you forge items with the sound of music.
• Community Support Award: Tobias with ‘PraiseLink’, a WebApp for sharing sheets and lyrics of music. It can be used for singing choirs or live performance groups.

Over the past few months, we spoke with some of the participants as they shared their experiences: Sofía, one of the winners; and with Aya, Vinícius and Simon, three contestants. As news, this year we also started publishing interviews with the jury members, so current and future participants get a better glimpse about what it is expected from them. In 2025, we talked with Alexios and with Brie.

Soon, in October, the winners of the 2025 edition will be announced. They will also be welcomed at the 2025 YH4F Awards Ceremony: a weekend in Brussels featuring various activities, networking opportunities, and the presence of several jury members.

Their journey began last January with the start of the programming period, which included optional monthly online meetings that ran until June. Afterwards, a broad group of experts evaluated the projects and faced the difficult task of selecting six winners.

Moreover, this initiative is made possible thanks to the generous financial support of our donor, Reinhard Wiesemann, as well as several sponsors. In 2024, OpenSSF joined the competition, and this year we are also proud to have Proxmox and SUSE OSCC on board.

Legal Education

In the past twelve months, the FSFE has increased our efforts to spread awareness and education about the legal concepts and issues that affect Free Software. We feel that this is a particularly important area to work on, as having a basic understanding of the legal principles behind Free Software can help developers better navigate essential aspects of Free Software, such as copyright and licensing.

To that end, the FSFE has developed a training curriculum for basic legal topics. This year, we have provided our training to many vocational students in computer science in Italy, through the Italian based Edulife project.

Additionally, this year saw the launch of our Legal Corner, a regular column that seeks to explain various legal concepts that Free Software developers may encounter, as well as explore current events in the legal realm that impact Free Software.Up to know we have deal with the following topics:

• MIA or Dead Contributors - Does It Matter For Your Software Project?
• Restrictions on our Freedom to Study Software: A Legal Case Study from Poland
• The threshold of originality for copyrightable source code
• Bringing SumUp to compliance: a case study of license enforcement

As explained in one of the Legal Corner articles, one of our volunteers, and team member, discovered that SumUp’s “Solo” payment terminal incorporated multiple Free Software components without providing the required disclosures, license texts, copyright attribution, or access to source code. She contacted SumUp and demanded compliance under the applicable Free Software licenses; after almost a year of back-and-forth, SumUp finally delivered a USB stick containing the required disclosures and the CCS. Additionally, SumUp also updated their Solo device software to now show the relevant FOSS disclosures, and also to indicate where users will be able to access the CCS.

The FSFE also concluded our direct work in the EU funded ZOOOM Initiative early this year. This was a project that sought to raise awareness on the importance of Free Software, Open Hardware, and Open Data, as key pillars of a sustainable, trustworthy, and sovereign industrial ecosystem in Europe. While the project has come to an end, we are nevertheless still involved in spreading awareness of the ZOOOM Toolkit, a resource produced during the project for SMEs to learn how to integrate the open principles of software, hardware, and data into their business models.

NGI projects

Since 2018, the FSFE has been involved in the Next Generation Internet Zero (NGI0) initiative as a consortium member. Funded by the European Commission, the NGI0 initiative hopes to support the development of the internet into a platform, which is also referred to as the Next Generation Internet, that is accessible and diverse, and that respects fundamental rights, including values such as privacy. At the FSFE, we believe that Free Software is key to accomplish this goal, so that all users are able to use the internet as an effective tool to achieve their full potential.

NGI0 projects provide financial grants and technical support to researchers and developers who are working on Free Software solutions that contribute to the establishment of the vision of the Next Generation Internet.

We have for the past year been working on our current NGI0 projects: NGI0 Entrust, NGI0 Core, NGI0 Commons Fund, and NGI0 Review.

As we’ve always done with our previous NGI0 projects, we have been assisting the software projects receiving grants from these various NGI0 projects with their legal and licensing needs, as well as helping them in their transitions when adopting our REUSE specification.

We continued our work with NGI0 this year by helping many developers working on Free Software solutions solve a diverse range of problems, as well as helping them have a better understanding of Free Software licenses, compliance issues, and how they can avoid some of these pitfalls by adopting our REUSE specification.

As part of our work in NGI0, we have also attended several conferences, giving talks about it and Free Software.

LLW and Legal Network

The FSFE’s Free Software Legal & Licensing Workshop (LLW), is a a two and a half day conference for members of the Legal Network community to meet face-to-face and share legal expertise. In 2025, the conference was held in the Unperfekthaus in Essen, bringing together over 100 legal and compliance professionals, technologists, and policy experts from across the globe. The 2025 edition delved into the evolving legal landscapes impacting Free Software, with a particular focus on Artificial Intelligence and cybersecurity.

Volunteer Engagement

Since September 2024, we have published around 60 news items in English, our official outreach language, with some of these also translated into other European languages thanks to our awesome team of translators. Kudos to all of them!

To make their work even easier, this year we simplified the FSFE translation process by integrating LibreTranslate into our translator tool, Webpreview. We also updated our translators page. to make the process clearer and more accessible.

We made some small but meaningful updates to our website as well. For example the donors page to improve transparency and recognition for our supporters. The donors page now shows donation amounts more clearly and includes a visual marker indicating how long each donor has been supporting the FSFE. You can check out the updated page here. Our supporters quotes at the main page are also changed regularly and we are finishing moving all our pages in the wiki into docs.fsfe.org.

But that’s not all. We released 12 new episodes of our Software Freedom Podcast, including a brand-new series explaining European policy topics related to Free Software. We continued featuring inspiring guests, such as Marc Prud’hommeaux discussing his App Fair Project, and explored initiatives like South Tyrol’s steps toward software freedom. Thanks to our volunteers, who not only help with editing but also contribute technically, our podcasts are gradually adopting Podcast 2.0v features! And we continued with our monthly newsletter and our mailings!

Our presence in the Fediverse is growing, so in followers in Mastodon and in our Peertube channel. In the later you can also find out all our videos, from our well known "What is Free Software" video to our presence in the latest conferences.

In 2024, the FSFE were also part of the organization of the 1st Berlin Fediverse Day. You can find out all the talks from that event on our Peertube Channel. Currently, we are involved in the organization of the 2nd Berlin Fediverse Day, which will take place at the beginning of October.

In 2025, the FSFE announce it suport to the the Dutch call to adopt social media platforms that respect public values.

One last news related to the Fediverse: since the beginning of the year we are using the Fediverse as discussion room for our publications, pointing the discussion link of the articles to the Fediverse posting about that publication. This result on the turning off the Discourse forums at community.fsfe.org by the end of March 2025.

IloveFS

Each year on the 14 February we celebrate the “I Love Free Software Day”. On this day, we thank all the people behind Free Software projects or programs and let them know that their work does not go unnoticed.

One more year we asked our community to join us organizing different local events to celebrate this occasion. A lot of you followed our call for action! In 2025 the FSFE and its local groups focused on hidden Free Software projects for the "I Love Free Software Day". Together we wanted to raise awareness of all the hidden Free Software Projects that power our daily infrastructure. Free Software is everywhere and often it is the small projects that become a vital part of our lives - therefore we dedicated this "I Love Free Software Day" to all those projects that are not that prominent, so to shed some light on them. ❤️

We had 19 amazing events in 11 different European countries. Each event was unique and every group came up with a different idea on how to mark this special occasion.

It was and is inspiring to see how many of you participated in the “I Love Free Software Day”. Without you this would not have been possible. Find out more about the “I Love Free Software Day 2025” and the different events and thanks you! in our ilovefs 2025 report.

Our community and conferences

As always, raising public awareness remains a key part of our mission, with active participation in SFSCON, 38c3, FOSDEM... This important presence would not have been possible without the dedication of our outstanding volunteers, who not only supported us at these major gatherings but also took the initiative to organize booths at various local events. Their commitment and hard work play a vital role in bringing our message to a wider audience.

Our local groups have also been active with different initiatives beyond their regular meetings. For example, the Berlin and Zurich groups contributed to the End of 10 initiative, organizing local events to help users transition to Linux; the Polish group joined the FSF’s 40th anniversary celebrations in Warsaw; and the Netherlands group has been working on translating Ada & Zangemann into Dutch; a story that, as mentioned earlier, is now also available in Danish thanks to our community there.

Alongside these local efforts, we also came together twice as a wider community to spend time with our community and supporters. In November, we enjoyed a beautiful hike near Bolzano, followed by lively conversations over lunch. During the summer, we gathered in Berlin for our Summer Meeting at the Software Freedom Flat to share inspiring talks, delicious food, and even home-made ice cream! All while working on Free Software topics for the upcoming monhts.

In recent years, the FSFE has partnered with LUGBZ (Linux User Group Bolzano-Bozen) to honor individuals who have made exceptional contributions to the promotion and dissemination of Free Software across Europe. The 2024 European SFS Award, presented at last year’s SFSCON, was awarded posthumously to Vim developer Bram Moolenaar.

Merchandising and Info Material

At the end of 2024, we reintroduced hoodies to our merchandise catalogue! Available in blue or black, these zipped hoodies were primarily offered through pre-order and could be picked up at various conferences. Since they are too bulky for regular online shipping, we reserved them for in-person distribution. Featuring a redesigned illustration of the Free Software Four Freedoms on the back, we also ordered a few extra, so you can still find them at our booth at several upcoming events.

In 2025, we expanded our merchandise with two new temporary tattoo sheets:

• one inspired by the illustrated book Ada & Zangemann – A Tale of Software, Skateboards, and Raspberry Ice Cream,
• and another featuring logos from our different activities.

Our information materials have also grown: from the Device Neutrality campaign, we now have a poster and a round sticker, as well as a new poster presenting our Vision for 2048.

This summer, we’ve made some updates to our “Spread the Word” page to make it easier for you to order exactly the materials you need. You can now choose from four different package sizes: "My laptop", "I want postcards", "Stickers for me and my friend", and Standard.There is an extra option, Custom, for you to detailed your needs so you only get what you need/want.

But the news are not over! We’re starting some collaborations to create some new designs that we hope you will enjoy while we continue to improve our website to make your orders, merchandising or promo material, easier! One of them is https://www.hellotux.com/fsfe: you can order now at this online shop some cool clothes with our logo! >

Core Infrastructure

During this last year our System Hackers & Administrators have been hard at work ensuring that the technical infrastructure that supports the FSFE’s work remains healthy and aligned with our needs and those of our community. Aside from the never ending maintenance work in our servers and services, this year has seen the release and development of widespread improvements that have optimized our work. It has also seen our infrastructure struggling under the pressure that malicious LLM bots induce.

Our custom website build process, which takes care of rendering the more than 5500 pages of our website, has seen major improvements thanks to one of our System Hackers who took on the challenge of revamping it with a focus on speed and maintainability. Thanks to the improvements brought by this change, we have been considering the introduction of many features, such as native Markdown support, that will further streamline our work.

The improvement of the website build process goes hand in hand with the changes made to Webpreview, our one-stop tool for publishers, translators, and proofreaders, which has been used as the testing ground for upcoming features like Markdown support.

Besides, the FSFE infrastructure is targeted by LLM harvesting bots, like many other communities alike. The services suffered the most were the mailing list archives and the git server. The mailing lists operation was disrupted due to a problem that happened in the database of the list archive server and access to many files and functionality on the git service had to be closed for supporters only. While the mailing list archives remain closed at the moment to prevent them from the LLM bots, access to the git service could be lifted again after deploying Anubis as additional layer and tighten up the existing firewall rules.

In the last few months, we have been organizing monthly calls with our System Hackers to ensure that, even though we are spread all over Europe, we can coordinate and easily discuss improvements and next steps to our infrastructure.

Join the movement

Become a supporter: Your support and contribution for the promotion of Free Software are important for securing our continuous work, ensuring our independence, strengthening our democratic society, promoting and implementing concrete steps towards software freedom, and making it easier to use and develop Free Software.

Advocating for freedom costs money and we depend on people like you to support us.Thanks also to all our supporters and our donors for their generous financial contributions. In the last twelve months, we want to especially thank our donors who contributed 18,000 € or more per year: Vodafone, Internet Archive Europe, Proton Pass, and Linuxhotel. We also warmly thank those who donated 3,600 € or more per year, such as AVM, FastBill, GitHub, Heinlein, Intevation, OpenProject, Reinhard Wiesemann, Siemens, and Y Combinator.

At the same time, we want to express our heartfelt gratitude to everyone making smaller contributions. Even if the amount looks modest, we know it can be a real effort, and together these donations make a big difference in sustaining our work.

We guarantee that all support is used to foster software freedom in Europe a little more each day, step by step, bit by bit, for the next decades.

With your help we can keep on defending software freedom. Thank you for your trust, your support, and your ideas to continue bringing Free Software to our society!

Support FSFE

Dieses Tutorial führt in den RHEL image mode ein und zeigt, wie ein solches Image in einer virtuellen Maschine (VM) installiert werden kann. Es wird ebenfalls gezeigt, wie ein installiertes Image aktualisiert und bei Bedarf zurückgerollt werden kann.

Während diese Einführung in Deutsch gehalten ist, liegen die Dokumentation und weitere verwendete Quellen ausschließlich in englischer Sprache vor.

Das Tutorial richtet sich in erster Linie an Sysadmins, die bereits Erfahrung mit dem Betrieb von RHEL oder einer verwandten Enterprise Linux Distribution haben. Es bietet keine allgemeine Einführung in die Installation und den Betrieb von Red Hat Enterprise Linux.

Zum Inhalt

Die folgende Liste bietet einen Überblick über den Inhalt:

• Was ist der RHEL image mode?
  • Konsolidierung von Bereitstellungsprozessen
  • Immutable RHEL
  • Deklarative Konfiguration des Betriebssystems
• Voraussetzungen
• Meine Laborumgebung
• RHEL Bootc Image erstellen
  • Containerfile
  • Build
    • Login registry.redhat.io
    • Image erstellen
  • Test
• Zwischenfazit
• ISO-Image mit dem bootc-image-builder erstellen
  • Benutzer, Passwort und SSH-Schlüssel hinzufügen
  • Das Container-Image in den passenden Benutzerkontext kopieren
    • Möglichkeit 1
    • Möglichkeit 2
  • Der bootc-image-builder in Aktion
• Offline-Installation mit dem RHEL image mode
• Fazit nach der Installation von RHEL image mode
• Systemupdate und Rollback
  • Bootc Image Installation aktualisieren bzw. Konfiguration ändern
    • Aktualisierung des RHEL Bootc Image
    • Das zu verwendende Image aus dem System heraus wechseln
    • Automatische Aktualisierungen und wie man sie deaktivieren kann
  • Rollback
• Ende
• Quellen und weiterführende Links

Was ist der RHEL image mode?

RHEL image mode ist eine Technology Preview und stellt eine neue Methode dar, um RHEL zu konfigurieren, installieren bzw. deployen und zu verwalten.

Durch Nutzung von Container-Tools wird ein Container-Image erstellt, welches neben dem RHEL-Userland auch den RHEL-Kernel, Boot Loader, Firmware und Treiber umfasst. Dieses RHEL-Container-Image (auch RHEL Bootc Image genannt) kann anschließend genutzt werden, um RHEL im Datacenter oder in der Cloud – auf Bare-Metal-Servern, virtuellen Maschinen oder Edge-Geräten zu deployen. Das RHEL-Container-Image kann direkt als Container ausgeführt werden, um die Funktionalität zu testen. Für das Deployment kann das Container-Image in ein Disk-Image für die entsprechende Zielplattform konvertiert werden. Ein installiertes oder als Disk-Image provisioniertes System läuft anschließend nativ auf der Hardware bzw. in der virtuellen Maschine und wird dort nicht als Container ausgeführt.

Konsolidierung von Bereitstellungsprozessen

In vielen Unternehmen kommen heute neben klassischen virtuellen Maschinen auch Linux-Container zum Einsatz. RHEL image mode bietet die Möglichkeit, Bereitstellungsprozesse zu konsolidieren, indem für die Bereitstellung von RHEL-Images die gleichen Werkzeuge genutzt werden, wie für die Bereitstellung von Container-Images für Anwendungen.

Immutable RHEL

Mit Ausnahme von /etc und /var ist das Wurzel-Dateisystem in RHEL image mode immutable (read-only).

Anwendungen und Updates werden durch aktualisierte RHEL-Container-Images verteilt. Ein provisioniertes System lädt dazu das aktualisierte Image auf die lokale Festplatte und startet dieses nach einem Neustart. Im Fehlerfall kann durch einen weiteren Neustart einfach das vorherige Image gestartet werden. So können fehlgeschlagene Updates einfach zurückgerollt werden.

Dies bietet dem Admin die Sicherheit, bei Bedarf zum vorherigen Zustand zurückkehren zu können, ohne dafür auf VM-/Storage-Snapshots oder andere Mechanismen außerhalb des Betriebssystems zurückgreifen zu müssen.

Deklarative Konfiguration des Betriebssystems

RHEL image mode macht es einfach, zu konfigurieren und zu verfolgen, welche Pakete in einem Basis-Image enthalten sind und wann welche Pakete hinzugefügt wurden.

Red Hat veröffentlicht in der Container-Registry registry.redhat.io RHEL Bootc Base Images, welche die Basis für eigene Images darstellen. Zu jeder Version wird eine Liste der enthaltenen Pakete veröffentlicht. Diese ist über den Red Hat Ecosystem Catalog einsehbar:

Hier ist zu beachten, dass obwohl amd64 als Architektur ausgewählt wurde, die Liste Pakete aller verfügbaren Architekturen zeigt. Natürlich sind im Basis-Image nicht 2302 Pakete enthalten. Die Filtermöglichkeiten und die Ergebnisliste zeigen leider unerwartete Ergebnisse. Ich habe dies bereits intern gemeldet und hoffe, dass sich bald jemand der Sache annimmt.

Das in obiger Abbildung gezeigte Image enthält für die amd64-Architektur 441 Pakete. Vergleiche ich dies mit zwei meiner RHEL 9 Installationen, die auf der Minimalinstallation basieren, so umfassen diese 591 bzw. 510 Pakete. Der Vergleich hinkt allerdings, da ich auf den RHEL package mode Installationen bereits weitere Software nachinstalliert habe. Ich bin jedoch erfreut, dass das Basis-Image nicht mehr Pakete als eine Minimalinstallation enthält.

Pakete, die zusätzlich hinzugefügt werden sollen, werden im Containerfile aufgeführt, welches üblicherweise einer Versionskontrolle unterliegt. Änderungen können so jederzeit nachvollzogen werden.

Weitere Informationen bietet das Kapitel 1 in Using image mode for RHEL to build, deploy, and manage operating systems.

Voraussetzungen

Um die in diesem Tutorial gezeigten Schritte selbst ausführen zu können, werden folgende Dinge benötigt:

• Ein registriertes RHEL 9 System
  • mit einer beliebigen RHEL Subskription,
  • dem installierten Meta-Paket container-tools
• Zugriff auf registry.redhat.io
• Eine virtuelle Maschine oder einen Rechner, auf dem RHEL image mode installiert werden kann

Falls ihr gerade keine geeignete Laborumgebung zur Verfügung habt, könnt ihr den Image Mode auch in diesen interaktiven Labs ausprobieren:

• Introduction to image mode for Red Hat Enterprise Linux
• Day 2 operations with image mode for Red Hat Enterprise Linux

Meine Laborumgebung

Meine Laborumgebung besteht aus zwei virtuellen Maschinen, welche auf einem Laptop ausgeführt werden. Beide VMs verfügen über 2 vCPU, 8 GB RAM und 40 GB Speicher.

Auf VM 1 werden folgende Tätigkeiten ausgeführt:

• Erstellung und Ausführung einer einfachen Container-Registry
• Erstellung und Pflege eines oder mehrerer rhel-bootc-Container-Images
• Erstellung von Disk-Images

Anhand von VM 2 werden folgende Dinge demonstriert:

• Installation von RHEL image mode
• Aktualisierung der Installation
• Wechsel des verwendeten Images
• Rollback

Die in diesem Tutorial verwendeten Containerfiles, Dateien und Skripte habe ich in einem Git-Repository gesammelt. Fühlt euch frei, die dortigen Dateien auf eigene Gefahr für eigene Versuche zu verwenden. Repository-URL: https://github.com/tronde/image-mode-demo

RHEL Bootc Image erstellen

Dieser Abschnitt wurde aus Kapitel 2 der Dokumentation Using image mode for RHEL to build, deploy, and manage operating systems abgeleitet. In ihm wird das RHEL-Container-Image erstellt, welches im nächsten Schritt für das Deployment in einer VM vorbereitet wird. Dieser Abschnitt behandelt folgende Schritte:

1. Containerfile(5) erstellen
2. Container-Image mit podman-build(1) erstellen
3. Container-Image auf dem Build-System testen

Containerfile

Mit dem folgenden Containerfile(5) wird konfiguriert, wie das RHEL Bootc Base Image ‚rhel-bootc:9.5‚ angepasst werden soll:

$ cat Containerfile 
FROM registry.redhat.io/rhel9/rhel-bootc:9.5
ADD index.html /var/www/html/index.html
RUN dnf -y install httpd \
    openssh-server \
    bind-utils \
    net-tools \
    chrony \
    vim-enhanced \
    man-pages \
    strace \
    lsof \
    tcpdump \
    bash-completion && \
    dnf clean all
RUN systemctl enable httpd sshd

1. Es wird eine index.html-Datei hinzugefügt
2. Die installierten Pakete werden aktualisiert
3. Weitere Pakete werden installiert
4. Der DNF-Paket-Cache wird entfernt
5. Die Dienste httpd und sshd werden aktiviert, damit sie nach dem Boot-Vorgang automatisch starten

Die im Containerfile aufgeführten Pakete sind eine persönliche Auswahl, die ich gern auf meinen Systemen habe. Ihr könnt hier natürlich die Pakete eurer Wahl eintragen.

Für dieses Tutorial installiere ich den Dienst httpd. Das von dem Image provisionierte System wird also einen Webserver hosten. Dass ich die index.html-Datei ebenfalls dem Image hinzufüge, soll mir lediglich den späteren Test in diesem Tutorial vereinfachen. Je nach Aufbau, Inhalt und Änderungsrate der auszuliefernden Webseite bzw. Webanwendung ist es nicht sinnvoll, diese in das Image zu integrieren.

Build

Login registry.redhat.io

Bevor das erste Container-Image erstellt werden kann, ist eine Anmeldung an der Container-Registry registry.redhat.io notwendig:

$ podman login registry.redhat.io
Username: alice
Password: 
Login Succeeded!

Weitere Unterstützung zur Anmeldung bietet: Red Hat Container Registry Authentication

Image erstellen

Mit dem folgenden Befehl kann nun ein Image aus obigen Containerfile erstellt werden:

$ time podman build -t localhost/rhel9.5-bootc:test .
…
Successfully tagged localhost/rhel9.5-bootc:test
c958185aa4c578af37b5bca796c7c5e50a270f7b7de38126c31fa6ab97046f41

real    2m52.574s
user    2m31.787s
sys     0m59.680s
$ podman images
REPOSITORY                                  TAG               IMAGE ID      CREATED         SIZE
localhost/rhel9.5-bootc  test              c958185aa4c5  40 seconds ago  1.68 GB
registry.redhat.io/rhel9/rhel-bootc         9.5               7cf5466a7756  2 days ago      1.56 GB

Das Container-Image wird unter dem Namen localhost/rhel9.5-bootc:test im lokalen Dateisystem gespeichert.

Der Build-Vorgang dauerte insgesamt knapp 3 Minuten. Darin ist die Zeit zum Herunterladen des Basis-Image registry.redhat.io/rhel9/rhel-bootc:9.5 enthalten. Ist dieses Image bereits vorhanden, dauert der Build-Vorgang nur knapp über 1 Minute.

Test

Der nun folgende Code-Block zeigt, wie das soeben erstellte Container-Image mit Podman im interaktiven Modus gestartet werden kann. Es wird geprüft, ob die index.html-Datei vorhanden ist und wie viele Pakete das Image enthält.

$ podman run -it --rm --name mybootc localhost/rhel9.5-bootc:test /bin/bash
bash-5.1# ls -l /var/www/html
total 4
-rw-r--r--. 1 root root 342 Jan 11 11:20 index.html
bash-5.1# rpm -qa | wc -l
465
bash-5.1#

Als nächste teste ich, ob die index.html-Datei auch ausgeliefert wird:

$ podman run -d --rm -p 127.0.0.1:8888:80 --name mybootc localhost/rhel9.5-bootc:test 
fa9c1f5110cd58c3f28760fb5a5d69cdc4595a5cba2f29ff67f85eaa076204ab
$ curl http://127.0.0.1:8888
<!DOCTYPE html>
<html lang="de">
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Bootc Demo Page</title>
  </head>
  <body>
                <p>Diese Seite wird von einem Webserver ausgeliefert, der mit RHEL Bootc Image Mode bereitgestellt wurde.</p>
  </body>
</html>

Test erfolgreich! Die konfigurierte Webseite wird wie erwartet ausgeliefert. Der Container wird mit podman stop mybootc gestoppt und der Test ist beendet.

Zwischenfazit

Bis hier wurde ein Containerfile erstellt, welches das zu verwendende Basis-Image, die zusätzlich zu installierenden Pakete und die auszuführenden Dienste definiert. Mit Hilfe dieses Containerfiles und Podman wurde anschließend das Container-Image localhost/rhel9.5-bootc:test erzeugt. Mit einem einfachen Test konnte auf dem Build-System verifiziert werden, dass die index.html-Datei wie gewünscht ausgeliefert wird.

Das Image enthält keinerlei Passwörter oder SSH-Schlüssel. Es sind somit bisher keinerlei Geheimnisse enthalten, die mit dem Image verloren gehen könnten.

Verglichen mit einer klassischen RHEL-Minimalinstallation, die als Basis für ein Golden-Image dient, konnte der Vorgang deutlich schneller abgeschlossen werden.

ISO-Image mit dem bootc-image-builder erstellen

Der bootc-image-builder ist eine Container-Variante des RHEL Image Builder. Mit diesem wird in den folgenden Schritten ein ISO-Image aus dem zuvor erstellten Container-Image erzeugt. Mit dem ISO-Image wird anschließend eine Installation in einer VM durchgeführt.

Mit dem bootc-image-builder können auch Disk-Images wie AMI, GCE, QCOW2, RAW und VMDK erzeugt werden. Ich habe mich für ISO entschieden, da dies am vielseitigsten verwendbar ist. Man kann damit VMs unter KVM/Qemu und VMware genauso installieren, wie Bare-Metal-Server.

Benutzer, Passwort und SSH-Schlüssel hinzufügen

Um sich nach der Installation interaktiv am System anmelden zu können, werden dem ISO-Image ein Benutzer mit Passwort und SSH-Schlüssel hinzugefügt. Dafür wird die folgende Datei toml.config genutzt:

$ cat config.toml 
[[customizations.user]]
name = "alice"
password = "changeme"
key = "ssh-ed25519 AAAAC3NzaC…cr alice@example.com"
groups = ["wheel"]

Durch Hinzufügen des Benutzers zur Gruppe wheel darf dieser privilegierte Kommandos mittels sudo ausführen.

Das Container-Image in den passenden Benutzerkontext kopieren

Das Image localhost/rhel9.5-bootc:test wurde mit einem rootless-Benutzer erstellt. Der Befehl im folgenden Abschnitt muss jedoch mit root-Rechten ausgeführt werden. Rootful-Podman kann jedoch nicht auf das Image zugreifen, welches wir mit rootless-Podman erstellt haben. Der Vorgang würde fehlschlagen mit der Meldung: Error: localhost/rhel9.5-bootc:test: image not known.

Um dies zu verhindern, gibt es zwei Möglichkeiten. Möglichkeit 1 bietet sich an, wenn man das ISO-Image auf dem gleichen System wie das Container-Image erzeugen möchte. Hierbei wird das Container-Image einfach in den passenden Benutzerkontext kopiert. Die zweite Möglichkeit besteht darin, das Container-Image in eine Container-Registry zu pushen, aus der es dann im nächsten Schritt wieder gepullt werden kann.

Möglichkeit 1

Das Container-Image wird mit folgendem Befehl aus dem Kontext des Benutzers ‚alice‘ in den Kontext des Benutzers ‚root‘ kopiert.

$ podman image scp alice@localhost::rhel9.5-bootc:test
…
$ sudo podman images
REPOSITORY                                    TAG         IMAGE ID      CREATED         SIZE
localhost/rhel9.5-bootc                       test        fb6237fff684  21 minutes ago  1.68 GB

Wird kein Ziel-Benutzer spezifiziert, wird root als Ziel angenommen. Weitere Informationen zur Verwendung dieses Befehls bietet podman-image-scp(1) und der Artikel: How Podman can transfer container images without a registry?

Möglichkeit 2

Selbstverständlich kann das Container-Image auch in einer Container-Registry gespeichert und im root-Kontext von dort wieder heruntergeladen werden. Für die spätere Aktualisierung eines installierten RHEL image mode Systems ist die Nutzung einer Container-Registry von Vorteil.

How to implement a simple personal/private Linux container image registry for internal use beschreibt die Einrichtung einer einfachen Registry. Ich habe die auszuführenden Schritte in dem Skript create_simple_container_registry.sh zusammengefasst. Die zur Ausführung notwendigen Parameter werden in der Datei registry.vars konfiguriert. Diese Datei ist bereits mit Standardwerten gefüllt, die direkt verwendet werden können. Installiert und konfiguriert wird die Registry mit dem Kommando:

$ sudo bash create_simple_container_registry.sh

Ich trage die IP-Adresse und den Hostnamen meiner VM 1 in die Datei /etc/hosts ein, damit die Namensauflösung funktioniert. Der folgende Code-Block zeigt, wie das Image localhost/rhel9.5-bootc in die Registry gepusht wird.

$ podman login --tls-verify=false vm1.example.com:5000
Username: registryuser
Password: 
Login Succeeded!
$ podman tag localhost/rhel9.5-bootc:test vm1.example.com:5000/rhel9.5-bootc:test
$ podman push --tls-verify=false jkastnin-tpp1-rhel9-podman-1:5000/rhel9.5-bootc:test
Getting image source signatures
…
Writing manifest to image destination

Die Option --tls-verfiy=false ist notwendig, da ein selbstsigniertes TLS-Zertifikat verwendet wird. Mit dem folgenden Befehl kann überprüft werden, ob sich das Image in der Registry befindet.

$ curl -k -u registryuser:registrypass https://vm1.example.com:5000/v2/_catalog
{"repositories":["rhel9.5-bootc"]}

Der bootc-image-builder in Aktion

Der folgende Code-Block zeigt, wie mit dem bootc-image-builder eine ISO-Datei erzeugt wird, die sich für eine RHEL-Installation in einer Offline-Umgebung eignet. Der Befehl muss mit sudo ausgeführt werden, da erweiterte Benutzerrechte erforderlich sind.

Da das Container-Image des bootc-image-builder noch nicht lokal vorliegt, muss zuerst ein Login bei registry.redhat.io erfolgen. Dies wurde weiter oben bereits für den rootless-Benutzer durchgeführt, muss für den rootful-Benutzer jedoch wiederholt werden, da Logins nicht zwischen verschiedenen Benutzerkontexten geteilt werden.

Achtung: Der folgende Befehl funktioniert nur, wenn das Image localhost/rhel9.5-bootc:test für root verfügbar ist. Dies kann durch eine der Methoden, die im vorherigen Abschnitt beschrieben wurden, sichergestellt werden. Ich habe in diesem konkreten Fall Möglichkeit 1 verwendet.

$ sudo podman login registry.redhat.io
Username: alice
Password: 
Login Succeeded!
$ mkdir output
$ time sudo podman run \
> --rm \
> -it \
> --privileged \
> --pull=newer \
> --security-opt label=type:unconfined_t \
> -v /var/lib/containers/storage:/var/lib/containers/storage \
> -v $(pwd)/config.toml:/config.toml \
> -v $(pwd)/output:/output \
> registry.redhat.io/rhel9/bootc-image-builder:latest \
> --type iso \
> --config /config.toml \
> --local \
> localhost/rhel9.5-bootc:test
…
real    22m31.407s
user    0m1.997s
sys     0m2.049s
$ ls -lh output/bootiso/
total 2.4G
-rw-r--r--. 1 root root 2.4G Jan 11 14:26 install.iso

Nun zur Erklärung des Ganzen:

1. Der Login erfolgt, um das bootc-image-builder-Image herunterladen zu können
2. Im Projektverzeichnis wird das Verzeichnis output erstellt, welches die ISO-Datei enthalten wird
3. Nun folgt ein ziemlich langer Aufruf von podman run
   • Falls in registry.redhat.io eine neuere Version des bootc-image-builder gefunden wird, wird diese heruntergeladen und genutzt
   • bootc-image-builder muss mit erhöhten Rechten ausgeführt werden, weshalb die Ausführung mittels sudo und die Option --privileged erforderlich sind
   • Ort der config.toml und Verzeichnis für das ISO werden dem Container als Volume zugänglich gemacht
   • Mit --type iso wird festgelegt, dass eine ISO-Datei erstellt werden soll
   • Die Option --local gibt an, dass das lokal existierende Image localhost/rhel9.5-bootc.test verwendet und dies nicht aus einer Registry geholt werden soll

Dass der Vorgang ganze 22 Minuten dauerte, ist den 2 vCPU-Kernen und den 8 GB RAM meiner VM geschuldet. Während der Arbeitsspeicher gerade ausreichend war, dürften weitere CPU-Kerne den Vorgang deutlich beschleunigen.

Das nun erstellte ISO kann zur Installation in VM 2 verwendet werden.

Offline-Installation mit dem RHEL image mode

Das im vorherigen Abschnitt erstellte Disk-Image install.iso wird nun verwendet, um VM 2 zu installieren. Die Installation läuft wie eine normale unbeaufsichtigte Anaconda-Installation ab.

In der Datei toml.config wurde ein Benutzer mit einem SSH-Schlüssel spezifiziert, der nun zum Login in das neue System verwendet werden kann.

$ ssh -o StrictHostKeyChecking=no alice@vm2.example.com
Warning: Permanently added 'vm2.example.com' (ED25519) to the list of known hosts.

$ lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
loop0    7:0    0  7.1M  1 loop 
sr0     11:0    1  2.4G  0 rom  
zram0  251:0    0  7.8G  0 disk [SWAP]
vda    252:0    0   30G  0 disk 
├─vda1 252:1    0    1G  0 part /boot
├─vda2 252:2    0    1G  0 part [SWAP]
└─vda3 252:3    0   28G  0 part /var
                                /sysroot/ostree/deploy/default/var
                                /etc
                                /sysroot

$ $ mount | grep -E '"/"|var|sysroot|etc'
/dev/vda3 on /sysroot type ext4 (ro,relatime,seclabel)
composefs on / type overlay (ro,relatime,seclabel,lowerdir=/run/ostree/.private/cfsroot-lower::/sysroot/ostree/repo/objects,redirect_dir=on,metacopy=on)
/dev/vda3 on /etc type ext4 (rw,relatime,seclabel)
/dev/vda3 on /sysroot/ostree/deploy/default/var type ext4 (rw,relatime,seclabel)
/dev/vda3 on /var type ext4 (rw,relatime,seclabel)

$ less /usr/lib/systemd/system/bootc-fetch-apply-updates.service
[jkastnin@localhost ~]$ systemctl status httpd
● httpd.service - The Apache HTTP Server
     Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; preset: disabled)
     Active: active (running) since Tue 2025-01-14 15:29:07 UTC; 28min ago
       Docs: man:httpd.service(8)
   Main PID: 829 (httpd)
…

Da ich im Vorfeld keine genaueren Angaben gemacht habe, wurde der Datenträger automatisch partitioniert. Die Installation lässt sich durch Kickstart-Dateien steuern. Dazu wird der Inhalt der Kickstart-Datei in die Datei config.toml eingefügt. Siehe hierzu Kapitel 4.9. Using bootc-image-builder to build ISO images with a Kickstart file in der RHEL-Dokumentation.

Fazit nach der Installation von RHEL image mode

• Mit rootless podman wurde ein rhel9.5-bootc:test Image erstellt
• Mit dem bootc-image-builder wurde ein ISO-Image erstellt, welchem ein Benutzer mit Passwort und öffentlichem SSH-Schlüssel hinzugefügt wurde und welches sich für die Installation von Offline-Systemen eignet
• Das ISO-Image wurde genutzt, um RHEL image mode in einer VM zu installieren
• Test von Login und einiger weniger Kommandos
• Der konfigurierte Webserver wird ausgeführt und liefert die kleine Beispielwebseite aus

Auf dem Weg hier her wurde erklärt, wie Container-Images mittels podman-image-scp(1) ohne Container-Registry zwischen Benutzerkontexten und Hosts kopiert werden können. Es wurde gezeigt, wie eine einfache Container-Registry betrieben und genutzt werden kann.

Weitere Möglichkeiten zum Deployment von RHEL Bootc Images finden sich in der Dokumentation in Chapter 6. Deploying the RHEL bootc images. Darin findet sich auch ein Abschnitt, wie man das RHEL bootc image aus einer Registry mithilfe von Anaconda und Kickstart installiert.

Systemupdate und Rollback

Zu den Aufgaben des IT-Betriebs gehört es, Betriebssysteme zu aktualisieren, ihre Konfiguration neuen Anforderungen anzupassen und im Fehlerfall die letzten Änderungen schnell rückgängig machen zu können. Diesen Aufgaben widmen sich die beiden folgenden Abschnitte.

Bootc Image Installation aktualisieren bzw. Konfiguration ändern

Während RHEL package mode Systeme zur Laufzeit mit DNF bzw. YUM aktualisiert werden und mit diesen Werkzeugen Software (de-)installiert wird, ist der Ablauf bei RHEL image mode Systemen anders:

1. Das RHEL Bootc Image wird aktualisiert
2. Das aktualisierte Container-Image wird in einer Registry verfügbar gemacht
3. Das aktualisierte Image wird in den Staging-Bereich des laufenden RHEL image mode Systems geladen
4. Durch einen Neustart wird das aktualisierte Image geladen
5. Bei Bedarf, z.B. bei auftretenden Problemen, kann das vorherige Image geladen werden

Aktualisierung des RHEL Bootc Image

Ich möchte die Pakete lsof, strace und tcpdump doch nicht in meiner Standardinstallation haben und sie aus der existierenden Installation entfernen. Deshalb kommentiere die entsprechenden Zeilen aus:

$ cat Containerfile
FROM registry.redhat.io/rhel9/rhel-bootc:9.5
ADD index.html /var/www/html/index.html
RUN dnf -y install httpd \
    openssh-server \
    bind-utils \
    net-tools \
    chrony \
    vim-enhanced \
    man-pages \
#    strace \
#    lsof \
#    tcpdump \
    bash-completion && \
    dnf clean all
RUN systemctl enable httpd sshd

Als Nächstes wird ein neues Image erstellt und in die Registry gepusht. Diesmal verwende ich den Tag 0.0.1, um für den Verlauf dieses Tutorials leichter den Überblick zu behalten:

$ podman build -t vm1.example.com:5000/rhel9.5-bootc:0.0.1 .
STEP 1/4: FROM registry.redhat.io/rhel9/rhel-bootc:9.5
STEP 2/4: ADD index.html /var/www/html/index.html
--> Using cache eb262e01451d150d95636b3771ca8b5985155edd45bcfef838726002f910a411
…
Successfully tagged vm1.example.com:5000/rhel9.5-bootc:0.0.1
ce3ec0f5ae5af0d27415c76aed480bfda51d39d5aeffdd78c7c06e29907c3d46

$ podman push --tls-verify=false vm1.example.com:5000/rhel9.5-bootc:0.0.1

Das zu verwendende Image aus dem System heraus wechseln

Der nun folgende Schritt wird in dem laufenden RHEL image mode System in VM 2 ausgeführt. In der RHEL-Dokumentation ist dieser Schritt in Abschnitt 8.1. Switching the container image reference beschrieben.

Für diesen Schritt ist eine funktionierende Namensauflösung zwischen VM 1 und VM 2 erforderlich. In der Laborumgebung kann dies mithilfe der Datei /etc/hosts erfolgen. Da in der Registry ein selbstsigniertes Zertifikat verwendet wird und das Kommando bootc keine Option --tls-verify besitzt, muss eine insecure registry in VM 2 konfiguriert werden. Der folgende Codeblock zeigt den Inhalt der Datei, mit der die insecure registry konfiguriert wird:

~]# cat /etc/containers/registries.conf.d/001-labregistry.conf
[[registry]]
location="vm1.example.com:5000"
insecure=true

Da bootc auch nicht über ein Login-Kommando verfügt und keinen Zugriff auf die Login-Informationen von Podman hat, wird in VM 2 ein Pull-Secret für bootc konfiguriert. Dazu wird eine Zeichenkette bestehend aus Benutzername:Passwort in Base-64 kodiert und zusammen mit der Registry-URL in die Datei /etc/ostree/auth.json geschrieben. Der folgende Code-Block zeigt dies mit den Beispielwerten aus diesem Tutorial:

~]# echo -n "registryuser:registrypass" | base64 -w 0 ; echo
cmVnaXN0cnl1c2VyOnJlZ2lzdHJ5cGFzcw==

~]# cat /etc/ostree/auth.json 
{
	"auths": {
		"vm1.example.com:5000": {
			"auth": "cmVnaXN0cnl1c2VyOnJlZ2lzdHJ5cGFzcw=="
		}
	}
}

Es gibt verschiedene Möglichkeiten, das Pull-Secret zu hinterlegen:

• Manuell, wie gerade gezeigt
• Mit einer Automationslösung wie z.B. Ansible zur Laufzeit des Zielsystems
• Bei der Erstellung des Disk-Images mit bootc-image-builder
• Bei hinreichend gesicherter Container-Registry direkt im RHEL Bootc Image

Siehe für weitere Hinweise hierzu Abschnitt 11.2 bis 11.4 im Anhang Managing users, groups, SSH keys, and secrets in image mode for RHEL.

Nun können wir mit dem folgenden Befehl von Image vm1.example.com:5000/rhel9.5-bootc:test zu Image vm1.example.com:5000/rhel9.5-bootc:0.0.1 wechseln:

~]# bootc switch vm1.example.com:5000/rhel9.5-bootc:0.0.1
layers already present: 67; layers needed: 2 (37.5 MB)
Fetched layers: 35.74 MiB in 23 seconds (1.58 MiB/s)                                                                   Deploying: done (5 seconds)                                                                                        Pruned images: 1 (layers: 0, objsize: 0 bytes)
Queued for next boot: vm1.example.com:5000/rhel9.5-bootc:0.0.1
  Version: 9.20250109.0
  Digest: sha256:c3925bc5d9618e803a3164f8f87a16333e4bf274469e72075d5cb50cf8ac51d9

Nach dem Wechsel befindet sich das ab nun zu verwendende Image zunächst im Staging-Bereich des lokalen Systems und wird beim nächsten Neustart aktiviert. Der Befehl bootc status gibt dazu übersichtlich Informationen aus, welches Image gestaged ist und welches aktuell verwendet wird:

~]# bootc status
Current staged image: vm1.example.com:5000/rhel9.5-bootc:0.0.1
    Image version: 9.20250109.0 (2025-01-14 19:58:27.484294313 UTC)
    Image digest: sha256:c3925bc5d9618e803a3164f8f87a16333e4bf274469e72075d5cb50cf8ac51d9
Current booted image: localhost/rhel9.5-bootc:test
    Image version: 9.20250109.0 (2025-01-11 12:40:29.172146867 UTC)
    Image digest: sha256:eee2c8ea204615a9341f3747a6156c5b7bc208bbcf60f0a5bb28f142f6b0aa54
No rollback image present

Nach einem Neustart wird der Status mit bootc status erneut kontrolliert und wir sehen, dass nun das Image aus der Registry verwendet wird und das vorherige Image für ein Rollback vorgehalten wird:

~]$ sudo bootc status
No staged image present
Current booted image: jkastnin-tpp1-rhel9-podman-1:5000/rhel9.5-bootc:0.0.1
    Image version: 9.20250109.0 (2025-01-14 19:58:27.484294313 UTC)
    Image digest: sha256:c3925bc5d9618e803a3164f8f87a16333e4bf274469e72075d5cb50cf8ac51d9
Current rollback image: localhost/rhel9.5-bootc:test
    Image version: 9.20250109.0 (2025-01-11 12:40:29.172146867 UTC)
    Image digest: sha256:eee2c8ea204615a9341f3747a6156c5b7bc208bbcf60f0a5bb28f142f6b0aa54

Automatische Aktualisierungen und wie man sie deaktivieren kann

Auf RHEL image mode Systemen existiert ein systemd.timer(5), welcher automatische Updates anstößt. Folgender Code-Block zeigt die Timer- und Service-Unit in VM 2:

$ systemctl status --no-pager bootc-fetch-apply-updates.{timer,service}
● bootc-fetch-apply-updates.timer - Apply bootc updates
     Loaded: loaded (/usr/lib/systemd/system/bootc-fetch-apply-updates.timer; disabled; preset: disabled)
     Active: active (waiting) since Wed 2025-01-15 08:29:37 UTC; 1h 1min ago
      Until: Wed 2025-01-15 08:29:37 UTC; 1h 1min ago
    Trigger: Wed 2025-01-15 10:28:13 UTC; 57min left
   Triggers: ● bootc-fetch-apply-updates.service
       Docs: man:bootc(8)

Jan 15 08:29:37 localhost systemd[1]: Started Apply bootc updates.

○ bootc-fetch-apply-updates.service - Apply bootc updates
     Loaded: loaded (/usr/lib/systemd/system/bootc-fetch-apply-updates.service; static)
     Active: inactive (dead)
TriggeredBy: ● bootc-fetch-apply-updates.timer
       Docs: man:bootc(8)

Ein Blick in die Service-Unit verrät, was passiert, wenn diese getriggert wird:

$ cat /usr/lib/systemd/system/bootc-fetch-apply-updates.service
[Unit]
Description=Apply bootc updates
Documentation=man:bootc(8)
ConditionPathExists=/run/ostree-booted

[Service]
Type=oneshot
ExecStart=/usr/bin/bootc update --apply --quiet

Das Kommando hinter ExecStart=:

1. Prüft, ob ein neues Image in der Container-Registry verfügbar ist (Prüfung efolgt auf Digest nicht auf Tag)
2. Falls ein neues Image verfügbar ist, wird dieses gestaged
3. Der Host wird automatisch neugestartet, um das neue Image zu laden

Möchte man Aktualisierungen durch andere Verfahren steuern, kann die automatische Aktualisierung wie folgt gestoppt werden:

$ systemctl mask bootc-fetch-apply-updates.timer

Rollback

Angenommen, das System soll auf das zuvor verwendete Conatiner-Image zurückgerollt werden. So kann man sich zuvor mit bootc status einen Überblick verschaffen, welches Image als Rollback-Image eingetragen ist:

$ sudo bootc status
Current staged image: jkastnin-tpp1-rhel9-podman-1:5000/rhel9.5-bootc:0.0.2
    Image version: 9.20250109.0 (2025-01-15 09:36:38.866194063 UTC)
    Image digest: sha256:e68453dd17a45ad9243139b5cbb0565bbd97aa2bcd5a230c41e44d295281f9a7
Current booted image: jkastnin-tpp1-rhel9-podman-1:5000/rhel9.5-bootc:0.0.1
    Image version: 9.20250109.0 (2025-01-15 09:36:38.866194063 UTC)
    Image digest: sha256:e68453dd17a45ad9243139b5cbb0565bbd97aa2bcd5a230c41e44d295281f9a7
Current rollback image: jkastnin-tpp1-rhel9-podman-1:5000/rhel9.5-bootc:0.0.1
    Image version: 9.20250109.0 (2025-01-14 19:58:27.484294313 UTC)
    Image digest: sha256:c3925bc5d9618e803a3164f8f87a16333e4bf274469e72075d5cb50cf8ac51d9

Euch fällt evtl. auf, dass zwei Images den gleichen Tag, aber unterschiedliche SHA-256-Prüfsummen haben, und zwei Tags die gleiche Prüfsumme und unterschiedliche Tags. Lasst euch davon bitte nicht irritieren; dies ist nur meiner Spielerei geschuldet.

Bei einem Rollback wird das Image hinter dem Eintrag Current rollback image als Boot-Image verwendet. Ein Rollback wird mit folgendem Kommando ausgeführt:

$ sudo bootc rollback
Next boot: rollback deployment

Nur den Neustart muss man noch selbst durchführen. Nach dem Neustart sieht der Status wie folgt aus:

$ sudo bootc status
[sudo] password for jkastnin: 
No staged image present
Current booted image: jkastnin-tpp1-rhel9-podman-1:5000/rhel9.5-bootc:0.0.1
    Image version: 9.20250109.0 (2025-01-14 19:58:27.484294313 UTC)
    Image digest: sha256:c3925bc5d9618e803a3164f8f87a16333e4bf274469e72075d5cb50cf8ac51d9
Current rollback image: jkastnin-tpp1-rhel9-podman-1:5000/rhel9.5-bootc:0.0.1
    Image version: 9.20250109.0 (2025-01-15 09:36:38.866194063 UTC)
    Image digest: sha256:e68453dd17a45ad9243139b5cbb0565bbd97aa2bcd5a230c41e44d295281f9a7

Anhand der SHA-256-Prüfsumme ist zu erkennen, dass das vorherige rollback image nun den Platz mit dem vorherigen booted image gewechselt hat. Ein weiterer Aufruf von bootc rollback führt zu einem weiteren Image-Wechsel.

Hinweis: Wenn nach einem Update ein Rollback durchgeführt wird und der Systemd-Timer für automatische Updates nicht deaktiviert wurde, führt dieser Timer bei Ablauf zu einem erneuten Update des Systems.

Ende

Hier endet die Einführung in RHEL image mode. Wer dem Tutorial aufmerksam gefolgt ist, sollte an dieser Stelle in der Lage sein:

• RHEL Bootc Images zu erstellen
• Eine einfache Container-Registry mit Podman zu betreiben
• Mit bootc-image-builder Disk-Images zu erstellen
• Ein System im RHEL image mode zu installieren
• Das installierte System zu aktualisieren
• Zu einem anderen Image zu wechseln
• Ein Rollback auf das vorherige Image durchzuführen

Wenn euch diese Einführung gefallen hat, freue ich mich, wenn ihr sie mit euren Netzwerken teilt. Nutzt gern die Kommentarfunktion, um mich wissen zu lassen, wie euch diese Einführung gefallen hat.

Falls ihr euch weitere Artikel rund um den RHEL image mode wünscht, teilt mir dies gern ebenfalls über die Kommentarfunktion mit.

Quellen und weiterführende Links

1. What does a „Technology Preview“ feature mean?
2. Technology Preview Features – Scope of Support
3. Image mode for RHEL: 4 key use cases for streamlining your OS
4. How to get list of the packages included in ‚Minimal Install‘ ? (Login notwendig)
5. How Podman can transfer container images without a registry?
6. How to implement a simple personal/private Linux container image registry for internal use
7. Using image mode for RHEL to build, deploy, and manage operating systems
8. Red Hat Container Registry Authentication
9. Composing a customized RHEL system image
10. Deploying a container image by using Anaconda and Kickstart
11. 8.5. Turning off automatic updates

Konferenzbuch erschienen: „Was Bits und Bäume verbindet – Digitalisierung nachhaltig gestalten“

Logo Bits & Bäume (© Bits & Bäume)

Welche Rolle spielt Nachhaltigkeit für stabile Tech-Communities? Welche ökologischen Chancen stecken in digitalen Anwendungen etwa für Klima- und Ressourcenschutz? Welche Arten von Digitalisierung stehen diesen Zielen entgegen oder sind gar kontraproduktiv? Wie kann die digitale Gesellschaft demokratisch und gerecht gestaltet und zugleich darauf ausgerichtet sein, auf friedvolle Weise die Grundlagen unseres Lebens auf diesem Planeten zu bewahren?

Mit Fragen wie diesen nahm die Bits & Bäume, die Konferenz für Digitalisierung und Nachhaltigkeit am 17. und 18. November 2018 in Berlin ihren Ausgang. Die Teilnehmer*innen haben unter verschiedensten Aspekten versucht zu beantworten, wie wir als Gesellschaft die Digitalisierung als Schlüsseltechnologie unserer Zeit mit der Menschheitsfrage nach den planetaren Grenzen zusammendenken können.

Auffällig an der Bits & Bäume ist sofort der bunte Trägerkreis der Konferenz:

• Brot für die Welt
• Bund für Umwelt und Naturschutz Deutschland e.V. (BUND)
• Chaos Computer Club e.V. (CCC)
• Deutscher Naturschutzring e.V. (DNR)
• Forum InformatikerInnen für Frieden und gesellschaftliche Verantwortung e.V. (FIfF)
• Germanwatch e.V.
• Institut für ökologische Wirtschaftsforschung (IÖW)
• Konzeptwerk Neue Ökonomie e.V.
• Open Knowledge Foundation Deutschland e.V. (OKF)
• Technische Universität Berlin

Anja Höfner vom IÖW hat den durchmischten Trägerkreis folgendermaßen zusammengefasst:

Die Bits & Bäume bringt zusammen, was noch nicht zusammengehört: Techies auf der einen und Akteure aus der Umweltszene auf der anderen Seite – nur so wird eine nachhaltige digitale Zukunft gestaltbar!

Die Konferenz wurde durch die Deutsche Bundesstiftung Umwelt (DBU) unterstützt und über die Förderung von Projekten einzelner Trägerkreisorganisationen vom Bundesministerium für Bildung und Forschung (BMBF) kofinanziert. Medienpartner ist netzpolitik.org, die Plattform für digitale Freiheitsrechte.

Die Vorträge der Bits & Bäume sind als Video- und Audiomitschnitte dokumentiert. Auch Do-FOSS hat einen Beitrag beigesteuert: Freie Software in Kommunen: Vom Sollen zum Wollen (30:08 Min.):

Noch auf der Konferenz wurden insgesamt 11 Forderungen in den folgenden sieben Kategorien aufgestellt:

• Sozial-ökologische Zielsetzung bei der Gestaltung der Digitalisierung
• Demokratie
• Datenschutz und Kontrolle von Monopolen
• Bildung
• Entwicklungs- und handelspolitische Aspekte
• IT-Sicherheit
• Langlebigkeit von Software und Hardware

Diese Forderungen können seither unterstützt werden.

Nun ist Anfang Juli das Konferenzbuch der Bits & Bäume beim oekom-Verlag erschienen: Was Bits und Bäume verbindet – Digitalisierung nachhaltig gestalten. Das Buch steht unter der Creative Commons 3.0 (CC BY-NC-SA 3.0 DE) Lizenz. Es darf also unter Nennung der Originalquelle vervielfältigt und nicht kommerziell weiterverbreitet werden. Der freie Zugang zum Buch fördert damit die weitergehende Diskussion.

Seitens der Konferenzteilnehmer*innen wird Freie Software als zentraler Baustein für eine nachhaltige Digitalisierung beschrieben. Diese Überlegungen spiegeln sich in der Arbeit von Do-FOSS wider. U.a. hat Do-FOSS im Rahmen des städtischen Agenda-Siegels 2016 Freie Software als Teil der globalen Nachhaltigkeitsziele 2030 identifiziert. Auch in der Publikation des Umweltbundesamtes mit dem Titel Nachhaltige Software werden zahlreiche positive Auswirkungen auf soziale und wirtschaftliche Organisationsformen durch Freie Software beschrieben. Dazu gehören Zusammenhänge mit dem Energieverbrauch von Software (Green Software Engineering), den Hardwareanforderungen, der Wiederverwendbarkeit von Software (und damit der Einsparung von Entwicklungsressourcen), dem gesellschaftlich zugänglichen Wissen (in Form von Gemeingütern) und Modularität (Anpassbarkeit von Softwarelösungen). Vor dem Hintergrund dieser Überlegungen kann Freie Software auch als Beitrag zu den Green-IT-Bestrebungen der Stadt Dortmund verstanden werden.

Der Mehrwert dieser Erkenntnisse ist für die Stadt Dortmund erheblich. Denn sie zeigen auf, dass Digitalisierung innerhalb einer Behörde für eine enkeltaugliche Welt anders gedacht werden kann. Auf Grundlage dieser Überlegungen können beispielsweise das Dortmunder Systemhauses (dosys.) als stadteigener IT-Dienstleister und das Umweltamt Kooperationsstrukturen neu ausprägen, um Digitalisierung und Nachhaltigkeit zusammenzuführen. Dies ist besonders vor dem Hintergrund relevant, da der Verwaltungsvorstand der Stadt Dortmund auch Nachhaltigkeitsaspekte in der Potenzialanalyse zu Freier Software untersuchen lassen möchte. Um diese Potenziale für eine Diskussion anschaulich zu machen, vergleicht Do-FOSS bereits seit längerem Freies Saatgut mit Freier Software. Vandana Shiva erklärt die Parallelen zwischen Freier Software und Freiem Saatgut folgendermaßen in dem kurzen Video Seeds of open source (1:38 Min.):

Einen ähnlichen Ansatz hat auch Do-FOSS in einem Beitrag für das Konferenzbuch der Bits & Bäume beschrieben (S. 79-81) und gibt diesen im Folgenden im Wortlaut wieder.

Saatgut wie Software – Eine Frage der Lizenz

Was geht mich das an?
SAATGUT WIE SOFTWARE
Eine Frage der Lizenz

Saatgut und Software könnten kaum verschiedener sein. Saatgut ist analog, Software ist digital. Saatgut begleitet die Menschheitsgeschichte bereits sehr lange, Software ist, geschichtlich gesehen, noch jung. Saatgut kommt aus der Natur, Software entstammt der menschlichen Kultur. Was also haben Saatgut und Software gemeinsam? Der jeweilige Gebrauch kann an Nutzungsbedingungen geknüpft sein, welche der Hersteller vorgibt. So kann zum Beispiel das Recht eingeschränkt werden, Software oder selbst geerntetes Saatgut weiterzugeben. Sind Saatgut oder Software auf solche Weise eingeschränkt, werden sie ‹unfrei› oder ‹proprietär› ^[1] genannt. Zudem wird unfreies Saatgut biologisch und unfreie Software technisch in der Regel auf eine Weise am Markt bereitgestellt, die eine Nachzüchtung von Saatgut oder eine Weiterentwicklung von Software unterbindet. Bei Freiem Saatgut und Freier Software ^[2] hingegen werden Nutzung und Weitergabe nicht eingeschränkt. Aus gesellschaftlicher Sicht können Saatgut und Software also entweder als Privateigentum oder als Gemeingut ^[3] bewirtschaftet werden. Wir wollen im Folgenden aufzeigen, dass mit dem freien oder proprietären Ansatz jeweils Vor- und Nachteile verbunden sind. Die folgende Betrachtung von Nutzungsrechten und Gemeingütern stellt gesellschaftliche Prinzipien heraus, die sich auf andere Themenfelder übertragen lassen. Saatgut und Software dienen dabei als Beispiele für unsere Betrachtungen.

FREIE LIZENZEN: SCHUTZ FÜR GEMEINGUT

Welche Rechte Hersteller von Saatgut oder Software einräumen und welche Pflichten sie einfordern, wird durch Lizenzen geregelt. Um rechtliche Abhängigkeiten der Landwirtschaft von Saatgutproduzenten zu verhindern, hat die Initiative OpenSourceSeeds ^[4] die Freie Open-Source-Saatgut-Lizenz ^[5] mit den folgenden drei Regeln entwickelt:

REGEL 1: Jede*r darf das Saatgut frei nutzen, es vermehren, weiterentwickeln, züchterisch bearbeiten und es im Rahmen bestehender Gesetze weitergeben.

REGEL 2: Niemand darf das Saatgut und seine Weiter­­entwicklungen mit geistigen Eigentumsrechten wie Patenten belegen.

REGEL 3: Jede*r Empfänger*in überträgt zukünftigen Nutzer*innen des Saatguts und seinen Weiterentwicklungen die gleichen Rechte und Pflichten.

Vorbild bei der Entwicklung dieser Lizenz waren die Freien Softwarelizenzen. ^[6] Die Free Software Foundation Europe formuliert deren Prinzipien wie folgt:

FREIHEIT 1: Ein Programm für jeden Zweck auszuführen.

FREIHEIT 2: Die Funktionsweise eines Programms zu untersuchen und es an seine Bedürfnisse anzupassen.

FREIHEIT 3: Kopien weiterzugeben und damit seinen Mitmenschen zu helfen.

FREIHEIT 4: Ein Programm zu verbessern und die Verbesserungen an die Öffentlichkeit weiterzugeben, sodass die gesamte Gesellschaft profitiert.

Diese Prinzipien werden durch konkrete Freie-Software-Lizenzen wie z. B. die GNU General Public License ^[7] ausgestaltet.

SAATGUT WIE SOFTWARE
UNGLEICH UND GLEICH ZU GLEICH

Proprietäre Lizenzen haben auf dem Software- und dem Saatgutmarkt sehr ähnliche Auswirkungen. So sieht man in beiden Märkten eine starke Monopolisierung. Im Softwarebereich entfallen bei Desktop-Computern über 80 Prozent der installierten Betriebssysteme auf Microsoft Windows. ^[8] Im Saatgutbereich beherrschen seit der Fusion von Bayer und Monsanto im Jahr 2018 nur noch drei Konzerne 60 Prozent des weltweiten Saatgutmarktes. ^[9] Das Ergebnis dieses Trends zur Machtkonzentration ist erschreckend: 75 Prozent der zu Beginn des 20. Jahrhunderts noch verfügbaren Sortenvielfalt sind heute verloren. ^[10] Beiden Märkten ist wiederum gemein, dass häufig die Monopole dadurch aufrechterhalten werden, dass Kund*innen der Wechsel zu Alternativen erschwert wird. Im Softwarebereich führt das dazu, dass die Auswahl von Softwareprodukten sich nicht mehr nur an Sachgründen wie zum Beispiel einem starken Datenschutz orientiert. Somit ist die digitale Souveränität eingeschränkt.

Ob auf dem Acker oder am Bildschirm, das grundsätzlich Fatale an proprietären ­Strukturen ist, dass sie

• sozial abhängig machen, denn sie führen zu Machtkonzentrationen bei wenigen,
• arm an Vielfalt sind, denn es herrscht eine starke Tendenz zur Monokultur, und …
• kulturvernichtend wirken, denn lokales Wissen kann sich nur schwer erhalten oder weiterentwickeln

Saatgut und Software sollten als Gemeingut behandelt, anstatt privat eingehegt werden. Freie Lizenzen sind eine Voraussetzung dafür, dass Menschen sich mit ihrer Umwelt auseinandersetzen können. Sie ermöglichen es ihnen, Saatgut und Software nach ihren Bedürfnissen zu verwenden, zu verstehen, zu verbreiten und zu verbessern. Diese vier Freiheiten für Gemeingüter sind zentral für eine mündige Gesellschaft.

Umweltamt nutzt Freie Lizenz, um Saatgut als Gemeingut zu schützen

Das Umweltamt engagiert sich gemeinsam mit OpenSourceSeeds auf Basis der Open-Source-Saatgut-Lizenz dafür, Saatgut zu einer Freien Ressource zu erheben und so als Gemeingut zu schützen. Damit gibt es eine Alternative zu Monopolen und Konzernmacht. Anschaulich wird diese Alternative in dem Video Vielfältiges Saatgut, braucht vielfältige Menschen (1:43 Min.) von OpenSourceSeeds erläutert:

Dass Freie Lizenzen ökologisch sinnvoll sind, beschreibt auch der Beitrag Eine Tomate, frei für alle – Mit der Open-Source-Tomate gegen den Klimawandel von heute.de vom 19.07.2019:

Eine Tomate, frei für alle – Mit der Open-Source-Tomate gegen den Klimawandel
Mit Saatgut werden weltweit harte Geschäfte gemacht – das hat soziale Folgen und wirkt negativ aufs Klima. Dem stemmt sich die Stadt Dortmund mit einer speziellen Idee entgegen.

Das Umweltamt arbeitet mit einer Freien Lizenz und wirkt so gemeinwohlorientiert für die Menschen. Einen ähnlichen Ansatz verfolgt das dosys. mit der kommunalen Potenzialanalyse zum Einsatz von Freier Software.

Freie Lizenzen für die Kreislaufwirtschaft der Stadt Dortmund

Zur Ausgestaltung der Anwendungsmöglichkeiten von Freien Lizenzen für eine nachhaltige und digitale Zukunft könnten die Erfahrungen aus den Bereichen des Umweltamtes und des dosys. in einem Gesamtzusammenhang beschrieben werden, ähnlich zu Modellen von planetaren Grenzen wie z.B. der Visualisierung des Donut-Modells von Kate Raworth.

Das Donut-Modell zeigt im gesellschaftlichen Fundament den Mangel an sozialen und gesellschaftlichen Grundlagen sowie die planetaren Grenzen in der ökologischen Decke. Daran angelehnt könnte eine gemeinsame Grundlage für das Umweltamt und das dosys. die folgende Architektur einer digital-emanzipatorischen Kreislaufwirtschaft sein, die von den Grundgedanken eines wechselseitigen Miteinanders und Freien Lizenzen getragen ist:

Die Autor*innen erläutern ihre Grafik im Konferenzbuch (S. 117) der Bits & Bäume wie folgt:

Die in die Abbildung eingebetteten acht Elemente stellen exemplarisch Anknüpfungspunkte dar, mit denen Wertschöpfung in einer auf Teilhabe und Lebensqualität ausgerichteten Circular Economy [Kreislaufwirtschaft – Anm. d. Verf.] realisiert werden kann.

Freie Lizenzen gewährleisten Zugang und Transparenz. Zusammen mit Commons schaffen sie Gemeinschaft und Solidarität. Dabei begünstigen Freie Lizenzen auf zentrale Weise, innerhalb der planetaren Grenzen zu leben. Auf kommunaler Ebene geht die Stadt Dortmund mit dem Umweltamt und dem dosys. bereits voran. Do-FOSS freut es, Ausprägungen von Commons-Public-Partnerships für Saatgut und Software bei der Stadt Dortmund zu erkennen. Solche Partnerschaften müssten von der Verwaltung weiterentwickelt und vermehrt verfolgt werden, um den Menschen strukturelle Lösungen für die Verfügungsrechte über ihre Mitwelt anbieten zu können. Die Auszeichnung der GEMEINGÜTER-Initiative mit dem Agenda-Siegel 2018 durch die Stadt Dortmund bestärkt Bestrebungen diesen Weg weiterzugehen, den auch Do-FOSS gerne weiter mitbegleitet.

Dokumente zum Herunterladen

Das Konferenzbuch Was Bits und Bäume verbindet – Digitalisierung nachhaltig gestalten kann hier, sowie der Beitrag von Do-FOSS zum Buch Saatgut wie Software – Eine Frage der Lizenz kann hier heruntergeladen werden. Außerdem können die Videos Do-FOSS – Freie Software in Kommunen: Vom Sollen zum Wollen hier, Vandana Shiva – Seeds of open source hier und OpenSourceSeeds – Vielfältiges Saatgut, braucht vielfälitge Menschen hier heruntergeladen werden.
Von Do-FOSS gesammelte Unterlagen zur Bits & Bäume können hier eingesehen werden. Weitere Informationen zum Thema „Open-Source-Saatware“ wurden von Do-FOSS hier zusammengestellt.

Soweit im gesetzlichen Rahmen möglich verzichtet der Autor auf alle Urheber- und damit verwandten Rechte an diesem Werk.
Es kann beliebig genutzt, kopiert, verändert und veröffentlicht werden.
Für weitere Informationen zur Lizenz, siehe hier.

The post Bits & Bäume – Digitalisierung und Nachhaltigkeit durch Freie Lizenzen appeared first on Do-FOSS.

CachyOS ist das Kunststück gelungen, die Spitze der distrowatch-Charts zu erklimmen. Über diesen Meilenstein haben zuletzt die meisten IT-Medien berichtet. Das Ranking spiegelt zwar nicht die Anzahl der Installationen wider (diese Zahlen kennt distrowatch nicht), wohl aber das Interesse, das durch Seitenzugriffe gemessen wird. Und das Interesse an CachyOS ist aktuell hoch.

Warum? CachyOS ist eine relativ neue Distribution auf der Basis von Arch Linux. CachyOS verfügt aber über ein verhältnismäßig komfortables grafisches Installationsprogramm, verwendet einen eigenen, auf Geschwindigkeit optimierten Kernel und eigene Paketquellen, deren Programme ebenfalls im Hinblick auf optimale Geschwindigkeit kompiliert sind (mit mehreren Varianten optimiert je nach CPU-Generationen). CachyOS implementiert interessante Features per Default: btrfs-Dateisystem mit komprimierten Subvolumes und Snapper, ufw-Firewall, systemd-boot, fish als Shell etc. Die CachyOS-spezifischen Details sind im Wiki gut dokumentiert.

In Summe ergibt das ein schnelles, modernes und sympathisches Linux, das ganz offensichtlich den Zeitgeist trifft. Höchste Zeit also, dass ich auch in meinem Blog etwas dazu schreibe :-)

Eckdaten

• Rolling Release Modell auf Arch-Linux-Basis (aber mit eigenen Paketquellen)
• x86-only, keine ARM-Variante
• btrfs als Defaultdateisystem
• Snapper als Snapshot-Tool (erfordert btrfs)
• systemd-boot als Default-Boot-Loader
• fish als Default-Shell
• ufw als Firewall
• Unzählige Desktops zur Auswahl (mit einer gewissen Präferenz zu KDE)
• paru als AUR-Helper
• CachyOS-spezifische Zusatzprogramme:CachyOS Hello, CachyOS Package Manager, CachyOS Kernel Manager etc.

Die meisten Details sind frei wählbar. Sie haben bei der Installation die Wahl zwischen diversen Boot-Loadern, können die Dateisysteme frei konfigurieren usw. Ich habe mich bemüht, möglichst nahe an den CachyOS-Vorgaben/Vorlieben zu bleiben, inklusive KDE als Desktop.

Installation

Die Installation von CachyOS erfolgt aus einem Live-System heraus mit dem Programm Calamares. (Dieses distributionsunabhängige Framework wird auch von diversen anderen Distributionen verwendet.) Nach einem ersten Test in einer virtuellen Maschine habe ich diese Installation auf einem Lenovo-P1-Notebook durchgeführt. Die 1-TB-SSD war anfänglich leer, ich wollte aber nur ca. 1/5 der SSD nutzen.

Sie müssen UEFI Secure Boot deaktivieren, falls dieses auf Ihrem Rechner aktiv ist. Es ist möglich, Secure Boot nachträglich zu aktivieren.

Die Installation beginnt — ein wenig absurd! — mit einem Auswahldialog zwischen fünf Boot-Loadern. Willkommen in Nerdistan :-) Hier wäre ein Link in das CachyOS-Wiki hilfreich, wo die Vor- und Nachteile der fünf Programme gut zusammengefasst sind. Die Kurzfassung: GRUB funktioniert immer. Das vorgeschlagene systemd-boot ist klein + schnell und mein persönlicher Favorit. Es unterstützt allerdings nicht die Auswahl eines Snapper-Snapshots während des Bootprozesses. Genau das können GRUB und Limine. GRUB kenne ich von ca. 1000 anderen Linux-Installationen, systemd-boot verwende ich unter Arch Linux, also habe ich mich aus Neugier für Limine entschieden. Bei Limine landen alle Boot-Dateien (sowohl EFI als auch Kernel, Initrd etc.) in einer Partition mit vfat-Dateisystem. Calamares hat das in Verwirrung gebracht (siehe unten).

Erst danach startet das eigentliche Installationsprogramm mit Einstellung von Sprache, Region und Tastatur.

Wie bei den meisten Distributionen gelingt die Installation am einfachsten und schnellsten, wenn Sie dem Installationsprogramm die Kontrolle über den gesamten Datenträger überlassen und dieses selbst entscheiden kann, welche Partitionen es haben will. Aber wie einleitend erwähnt, wollte ich nur ca. 1/5 der SSD für CachyOS reservieren und habe deswegen eine manuelle Partitionierung durchgeführt. Der Prozess ist in Calamares nur mäßig intuitiv, aber zu schaffen. Ich habe eine 2-GB-Partition für /boot mit FAT32 und eine 180-GB-Partition für / mit btrfs eingerichtet.

Ärgerlicherweise hat Calamares die /-Partitionen vor der /boot-Partition platziert (abweichend von der Darstellung im Partitionseditor und im Zusammenfassungsdialog), was spätere Anpassungen nahezu unmöglich macht :-( Ist das so schwierig?

Beim Verlassen des Partitionseditor beklagt sich Calamares, dass die EFI-Partition fehlt. So wie ich das CachyOS-Wiki und die Limine-Dokumentation verstanden habe, ist diese Partition nicht erforderlich. Ich habe dennoch versucht, in Calamares wie gewünscht eine weitere EFI-Partition einzurichten, bin aber gescheitert. Es gibt nirgendwo die Option, das ESP-Flag zu setzen. Zuletzt habe ich entschieden, mich auf die Dokumentation zu verlassen und die Calamares-Empfehlung zu ignorieren und habe die Installation ohne EFI-Partition fortgesetzt. (Spoiler: hat funktioniert …)

In den nächsten Schritten wählen Sie zuerst den Desktop und dann eventuell gewünschte Zusatzpakete aus. Ich habe mich für KDE entschieden und keine weiteren Paket-Änderungen durchgeführt.

Im Dialog »Users« müssen Sie entweder einen eigenen root-User einrichten oder die Option »Nutze das gleiche Passwort auf für das Administratorkonto« verwenden. Ich will weder noch: sudo reicht mir, root braucht kein Passwort (wie unter Ubuntu und macOS). Aber es hilft nichts, diesen Fall sieht Calamares nicht vor.

Calamares zeigt nun eine Zusammenfassung an. Danach beginnt die Installation, die (zumindest bei meinem lahmen Internet) recht lange braucht. Alle erforderlichen Pakete werden frisch heruntergeladen.

Alles in allem ist die Installation mit etwas Linux-Erfahrung zu schaffen. Wenn Arch Linux die Messlatte ist, gibt es nichts zu meckern. Fedora, openSUSE oder Ubuntu zeigen aber, dass es deutlich intuitiver geht.

Erste Schritte

Immerhin: Nach einem Neustart bootet CachyOS korrekt. Die Distribution ist auf Platz 1 in der EFI-Bootliste, Limine funktioniert wie es soll.

Nach dem Login erscheint das Programm »CachyOS Hello« und hilft bei den ersten Schritten, z.B. bei der Installation weiterer Pakete. Google Chrome ist in der Auswahl nicht enthalten, aber paru -S google-chrome führt zum Ziel.

In der Folge habe ich ein paar Stunden damit verbracht, CachyOS arbeitstauglich zu machen: Desktop einrichten, Nextcloud installieren, meine wichtigsten git-Repos herunterladen, Emacs und VSCode installieren usw. Merkwürdigerweise lässt sich die Fenstergröße von Emacs nur ganz schwer mit der Maus ändern — wohl ein Problem im Zusammenspiel mit KDE?

Shell

CachyOS verwendet meine Lieblings-Shell fish per Default — großartig. (Zu fish will ich demnächst einen eigenen Blog-Artikel verfassen.) Auch ein paar praktische Tools wie duf und exa sind standardmäßig installiert. Das bringt Farbe und Komfort ins Terminal. Die bash ist ebenso installiert, z.B. um eigene Scripts damit auszuführen.

btrfs und Snapper

CachyOS empfiehlt btrfs als Dateisystem. Wenn Sie sich dafür entscheiden, richtet CachyOS dort einige Subvolumes für /home, /var/cache, /var/tmp etc. ein. In allen Subvolumes ist die Komprimierfunktion aktiv.

# /etc/fstab
# <file system>   <mount point>  <type>  <options>  <dump>  <pass>
UUID=36C7-65AA    /boot          vfat    defaults,umask=0077 0 2
UUID=6d011...     /              btrfs   subvol=/@,defaults,noatime,compress=zstd,commit=120 0 0
UUID=6d011...     /home          btrfs   subvol=/@home,defaults,noatime,compress=zstd,commit=120 0 0
UUID=6d011...     /root          btrfs   subvol=/@root,defaults,noatime,compress=zstd,commit=120 0 0
UUID=6d011...     /srv           btrfs   subvol=/@srv,defaults,noatime,compress=zstd,commit=120 0 0
UUID=6d011...     /var/cache     btrfs   subvol=/@cache,defaults,noatime,compress=zstd,commit=120 0 0
UUID=6d011...     /var/tmp       btrfs   subvol=/@tmp,defaults,noatime,compress=zstd,commit=120 0 0
UUID=6d011...     /var/log       btrfs   subvol=/@log,defaults,noatime,compress=zstd,commit=120 0 0
tmpfs             /tmp           tmpfs   defaults,noatime,mode=1777 0 0

compress=zstd bringt im Root-Dateisystem relativ viel. In den restlichen Subvolumes ist der Nutzen — zumindest bei meinen Daten — sehr überschaubar.

sudo compsize -x /

  Processed 264495 files, 143727 regular extents (144574 refs), 152617 inline.
  Type       Perc     Disk Usage   Uncompressed Referenced  
  TOTAL       59%      6.5G          11G          11G       
  none       100%      4.3G         4.3G         4.3G       
  zstd        33%      2.2G         6.7G         6.7G       
  prealloc   100%      1.2M         1.2M          15M       

sudo compsize -x /home

  Processed 16181 files, 18299 regular extents (18888 refs), 6961 inline.
  Type       Perc     Disk Usage   Uncompressed Referenced  
  TOTAL       95%       10G          10G          10G       
  none       100%      9.9G         9.9G         9.8G       
  zstd        25%      180M         715M         711M       
  prealloc   100%      2.5M         2.5M          44M       

sudo compsize -x /var/cache/

  Processed 2489 files, 1855 regular extents (1855 refs), 1219 inline.
  Type       Perc     Disk Usage   Uncompressed Referenced  
  TOTAL       99%      3.7G         3.7G         3.7G       
  none       100%      3.7G         3.7G         3.7G       
  zstd        27%      2.0M         7.5M         7.1M       

sudo compsize -x /var/log

  Processed 11 files, 99 regular extents (129 refs), 0 inline.
  Type       Perc     Disk Usage   Uncompressed Referenced  
  TOTAL       83%       13M          16M          16M       
  none       100%       12M          12M         3.0M       
  zstd        25%      956K         3.7M         3.7M 

In CachyOS ist das von SUSE entwickelte Programm Snapper installiert. Es erstellt vor und nach jeder Paketinstallation bzw. jedem Update Snapshots. Sollte etwas schiefgehen, kann das Root-Dateisystem beim Neustart in einen früheren Zustand zurückversetzt werden. (Den folgenden Limine-Screenshot habe ich in einer virtuellen Maschine erstellt.)

Eine Liste aller Snapshots erstellen Sie mit sudo snapper list. Noch bequemer gelingt die Snapper-Administration mit dem vorinstallierten btrfs-assistant. Snapper ist so vorkonfiguriert, dass maximal 50 Snapshots gespeichert werden. Danach werden alte Snapshots automatisch gelöscht.

Persönlich habe ich Snapper noch nie benötigt. (Ich kenne das Programm schon seit einigen Jahren von openSUSE.) Man kann argumentieren, dass es ein Hilfsmittel für den Notfall ist, mit nur minimalen störenden Nebenwirkungen. Der Speicherbedarf für die Snapshots ist relativ klein. Wenn Sie die mit Snapper einhergehende Komplexität stört, deinstallieren sie einfach das gleichnamige Paket.

Limine

Wie gesagt, Sie haben bei CachyOS die Wahl zwischen vielen Boot-Loadern. Mich hat Limine interessiert, weil ich das Programm bisher noch nie verwendet habe. Kurz die Eckdaten: x86 + ARM, BIOS + EFI, aber kein Secure Boot.

Unter CachyOS landen die Dateien für Limine und EFI normalerweise in einem FAT32-Dateisystem:

sudo tree /boot

├── 83267ffa7c0b4bf08a12eaa512f27972
│   ├── limine_history
│   │   ├── initramfs-linux-cachyos_sha256_60497733c69906ce771ecb34ce15abf118bd774e9f02526191cb54b5fcbd7fd4
│   │   ├── snapshots.json
│   │   ├── snapshots.json.old
│   │   └── vmlinuz-linux-cachyos_sha256_8705f3a6f237fcedd807f687e2e3a8d3d5fb97eaa1edf6b8f3c88bcc8635753d
│   └── linux-cachyos
│       ├── initramfs-linux-cachyos
│       └── vmlinuz-linux-cachyos
├── EFI
│   ├── boot
│   │   └── BOOTX64.EFI
│   └── Limine
│       ├── limine_x64.bak
│       └── limine_x64.efi
├── initramfs-linux-cachyos.img
├── intel-ucode.img
├── limine.conf
├── limine.conf.old
├── limine-splash.png
└── vmlinuz-linux-cachyos

Die gesamte Konfiguration befindet sich in der Textdatei /boot/limine.conf. Im folgenden Listing habe ich die vielen dort befindlichen UUIDs durch xxx ersetzt, damit die Struktur der Datei besser erkenntlich ist.

timeout: 5
default_entry: 2
remember_last_entry: yes

# CachyOS Limine theme
# Author: diegons490 (https://github.com/diegons490/cachyos-limine-theme)
term_palette: 1e1e2e;f38ba8;a6e3a1;f9e2af;89b4fa;f5c2e7;94e2d5;cdd6f4
term_palette_bright: 585b70;f38ba8;a6e3a1;f9e2af;89b4fa;f5c2e7;94e2d5;cdd6f4
term_background: ffffffff
term_foreground: cdd6f4
term_background_bright: ffffffff
term_foreground_bright: cdd6f4
interface_branding:
wallpaper: boot():/limine-splash.png

/+CachyOS
  //linux-cachyos
  comment: 6.16.0-5-cachyos
  protocol: linux
  module_path: boot():/xxx/linux-cachyos/initramfs-linux-cachyos#xxx
  kernel_path: boot():/xxx/linux-cachyos/vmlinuz-linux-cachyos#xxx
  kernel_cmdline: quiet nowatchdog splash rw rootflags=subvol=/@ root=UUID=xxx

     //Snapshots
     comment: Selecting any snapshot to boot into it.
     ///25 │ 2025-08-09 11:33:41
     comment: tree
     ////linux-cachyos
     comment: 6.16.0-5-cachyos
     protocol: linux
     module_path: boot():/xxx/limine_history/initramfs-linux-cachyos_sha256_xxx
     kernel_path: boot():/xxx/limine_history/vmlinuz-linux-cachyos_sha256_xxx
     kernel_cmdline: quiet nowatchdog splash rw rootflags=subvol=/@/.snapshots/25/snapshot root=UUID=xxx
     ...

Um die für Snapper erforderlichen Konfigurationsänderungen kümmert sich das Paket limine-snapper-sync. Das Paket stellt einige systemd-Units zur Verfügung. Die Konfiguration übernimmt /etc/limine-snapper-sync.conf.

Geschwindigkeit

CachyOS stellt eine Menge Kernel zur Auswahl und gibt Ihnen unkompliziert die Möglichkeit, den Scheduler zu beeinflussen. (Der Scheduler steuert, wie viel Rechenzeit welcher Prozess bekommt.) Die für CachyOS kompilierten Kernel sind besonders im Hinblick auf die Geschwindigkeit optimiert. Details können Sie hier, hier und hier nachlesen.

Darüber hinaus betreibt CachyOS mehrere Repositories mit Paketen, die für unterschiedliche CPU-Generationen optimiert sind. Anstatt also ein Paket anzubieten, das auf jeder noch so alten CPU läuft, gibt es mehrere Pakete, die die Features Ihrer CPU optimal nutzt. Installationen auf Rechner mit einer modernen CPU verwenden automatisch die v3-Repos. Details finden Sie wieder im CachyOS-Wiki.

# Datei /etc/pacman.conf
...
[cachyos-v3]
Include = /etc/pacman.d/cachyos-v3-mirrorlist
[cachyos-core-v3]
Include = /etc/pacman.d/cachyos-v3-mirrorlist
[cachyos-extra-v3]
Include = /etc/pacman.d/cachyos-v3-mirrorlist
[cachyos]
Include = /etc/pacman.d/cachyos-mirrorlist

Was bringen all diese Maßnahmen? Subjektiv nicht viel. Mein Notebook fühlt sich mit CachyOS nicht spürbar schneller an als mit anderen Distributionen. (Die meiste Zeit verwende ich mein Notebook unter Arch Linux, insofern ist das meine Referenz. Und die meiste Zeit erledige ich Dinge, die nicht CPU-intensiv sind — Texte verfassen, Code entwickeln etc.) Andererseits: Wenn Sie viele performance-intensive Programme ausführen (Compiler, lokale KI-Tools, Spiele), dann sind die Optimierungen von CachyOS absolut wertvoll.

Phoronix hat im Mai 2025 umfangreiche Benchmarktests durchgeführt, in denen CachyOS hinter Clear Linux (mittlerweile eingestellt) auf Platz 2 landete, knapp vor Debian 13 RC. Aber die Unterschiede zwischen den Testkandidaten waren überwiegend minimal, im einstelligen Prozentbereich. Schneller ist natürlich immer besser, aber Wunder kann auch CachyOS nicht vollbringen.

CachyOS verwendet standardmäßig ZRAM-Swap und benötigt normalerweise keine zusätzliche Swap-Partition oder Datei. ZRAM-Swap verwendet den Arbeitsspeicher als Auslagerungsort und komprimiert die dort gespeicherten Blöcke. Dieses auch bei Fedora übliche Feature funktioniert normalerweise sehr gut (außer Sie haben wirklich deutlich zu wenig RAM). Der Swap-Speicher wird von systemd eingerichtet (siehe auch zram-generator).

zramctl 

  NAME       ALGORITHM DISKSIZE  DATA COMPR TOTAL STREAMS MOUNTPOINT
  /dev/zram0 zstd         30,8G  1,2M 84,7K  840K         [SWAP]

Auch das Verzeichnis /tmp ist via tmpfs im Arbeitsspeicher abgebildet (siehe /etc/fstab). All diese Maßnahmen führen dazu, dass das (hoffentlich ausreichend verfügbare) RAM unter CachyOS möglichst gut im Sinne einer optimalen Geschwindigkeit genutzt wird.

Hardware-Erkennung und Treiber-Installation

CachyOS hat mit chwd ein eigenes Tool zur Hardware-Erkennung. Es wird bei der Installation verwendet, um alle notwendigen Treiber zu installieren. Im späteren Betrieb liefert chwd --list einen Überblick über die installierten Treiber. chwd --autoconfigure wiederholt die Treiberkonfiguration, z.B. um Treiber für später eingebaute Komponenten zu installieren.

sudo chwd --list

> 0000:00:02.0 (0300:8086:3e9b) VGA compatible controller Intel Corporation:

╭──────────┬───────────╮
│ Name     ┆ Priorität │
╞══════════╪═══════════╡
│ intel    ┆ 4         │
├╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌┤
│ fallback ┆ 3         │
╰──────────┴───────────╯

> 0000:01:00.0 (0300:10de:1cbb) VGA compatible controller NVIDIA Corporation:

╭──────────────────┬───────────╮
│ Name             ┆ Priorität │
╞══════════════════╪═══════════╡
│ nvidia-dkms      ┆ 12        │
├╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌┤
│ nvidia-open-dkms ┆ 10        │
├╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌┤
│ fallback         ┆ 3         │
╰──────────────────┴───────────╯

Firewall

Unter CachyOS läuft per Default die von Ubuntu stammende Firewall ufw. Von außen kommende Verbindungen werden für alle Ports (auch 22/SSH) blockiert. Wenn Sie einen SSH- oder Webserver installieren und von außen sichtbar machen möchten, müssen Sie den entsprechenden Port öffnen, z.B. so:

sudo systemctl enable --now sshd

sudo ufw allow ssh

sudo ufw status

  Status: active

  To                         Action      From
  --                         ------      ----
  22                         ALLOW       Anywhere                  
  22 (v6)                    ALLOW       Anywhere (v6)             

Fazit

CachyOS ist eine sympathische, in vielen Details originelle, gut funktionierende neue Linux-Distribution. Es macht Spaß damit zu arbeiten, und man merkt, wie viel Mühe in die Entwicklung geflossen ist.

Ich habe schon viele Distributionen kommen und gehen gesehen. Hinter CachyOS steht ein verhältnismäßig kleines Team ohne die finanzielle Unterstützung großer Sponsoren. Wird es CachyOS also nächstes oder übernächstes Jahr noch geben? Ich weiß es nicht. Das Risiko, plötzlich eine nicht mehr gewartete Distribution zu nutzen, ist aber überschaubar: Zur Not sollte durch einen Wechsel der Paketquellen der Umstieg auf das ursprüngliche Arch Linux gelingen.

Es gehört zu meinem Beruf, dass ich viele Linux-Distributionen ausprobiere. Einen Wechsel meiner »Hauptinstallation« auf meinem Arbeits-Notebook mache ich aber nur ganz selten, das ist einfach zu viel Mühe. Dort läuft seit ca. drei Jahren Arch Linux und ich bin damit zufrieden.

CachyOS macht vieles richtig. Wenn ich mein Notebook heute neu aufsetzen bzw. ein neues Notebook einrichten müsste, würde ich vermutlich CachyOS eine Chance geben. Dafür gibt es aktuell aber keine Notwendigkeit, und so werde ich bis auf weiteres Arch Linux treu bleiben. So groß sind die Unterschiede zu CachyOS dann auch wieder nicht.

Quellen/Links

• https://cachyos.org
• https://wiki.cachyos.org
• https://wiki.cachyos.org/installation (unbedingt lesen!)
• https://distrowatch.com/table.php?distribution=cachyos
• https://www.phoronix.com/review/framework-13-amd-linux-2025
• https://limine-bootloader.org/
• https://github.com/systemd/zram-generator
• https://limine-bootloader.org
• https://github.com/limine-bootloader/limine

Snapper

• https://doc.opensuse.org/documentation/tumbleweed/snapper
• https://wiki.archlinux.org/title/Snapper
• https://documentation.suse.com/en-us/smart/systems-management/html/snapper-basic-concepts

News/Tests

• https://www.heise.de/news/CachyOS-im-Test-Wie-schnell-kann-ein-Linux-sein-10492703.html
• https://www.golem.de/news/cachyos-arch-linux-fuer-einsteiger-2507-198421.html

Nachdem ich mich vor ein paar Wochen ausführlich mit der Installation von Fedora Asahi Linux auseinandergesetzt habe, geht es jetzt um die praktischen Erfahrungen. Der Artikel ist ein wenig lang geworden und geht primär auf Tools ein, die ich in meinem beruflichen Umfeld oft brauche.

Ich habe mich für die Gnome-Variante von Fedora Asahi Linux entschieden, die grundsätzlich ausgezeichnet funktioniert. Dazu aber gleich eine Einschränkung: Der Asahi-Entwickler Hector Martin ist KDE-Fan; insofern ist die KDE-Variante besser getestet und sollte im Zweifelsfall als Desktop-System vorgezogen werden.

Hardware-Unterstützung

Asahi Linux unterstützt aktuell noch keine Macs mit M3-CPUs. Außerdem hapert es noch bei USB-C-Displays (HDMI funktioniert), einigen Thunderbolt-/USB4-Features und der Mikrofon-Unterstützung. (Die Audio-Ausgabe funktioniert, bei den Notebooks anscheinend sogar in sehr hoher Qualität. Aus eigener Erfahrung kann ich da beim Mac Mini nicht mitreden, dessen Lautsprecher ist ja nicht der Rede wert.) Auf die Authentifizierung mit TouchId müssen Sie auch verzichten. Einen guten Überblick über die Hardware-Unterstützung finden Sie am Ende der folgenden Seite:

https://asahilinux.org/fedora/

Ich habe Fedora Asahi Linux nur auf einem Mac Mini M1 getestet (16 GB RAM). Damit habe ich sehr gute Erfahrungen gemacht. Das System ist genauso leise wie unter macOS (sprich: lautlos, auch wenn der Lüfter sich immer minimal dreht). Aber ich kann keine Aussagen zur Akku-Laufzeit machen, weil ich aktuell kein MacBook besitze. Wie gut Linux die Last zwischen Performance- und Efficiency-Cores verteilt, kann ich ebenfalls nicht sagen.

Der Ruhezustand funktioniert, auch das Aufwachen ;-) Dazu muss allerdings kurz die Power-Taste gedrückt werden. Ein Tastendruck oder ein Mausklick reicht nicht.

Tastatur

An meinem Mac Mini ist eine alte Apple-Alu-Tastatur angeschlossen. Grundsätzlich funktioniert sie auf Anhieb. Ein paar kleinere Optimierungen habe ich vor einiger Zeit hier beschrieben.

Konfiguration bei der Linux-Installation

Ich habe ja schon in meinem Blog-Beitrag zur Installation festgehalten: Während der Installation von Fedora gibt es praktisch keine Konfigurationsmöglichkeiten. Insbesondere können Sie weder die Partitionierung noch das Dateisystem beeinflussen (es gibt eine Partition für alles, das darin enthaltene Dateisystem verwendet btrfs ohne Verschlüsselung).

Wenn Sie davon abweichende Vorstellungen haben und technisch versiert sind, können Sie anfänglich nur einen Teil des freien Disk-Speichers für das Root-System von Fedora nutzen und später eine weitere Partition (z.B. für /home) nach eigenen Vorstellungen hinzuzufügen.

Swap-File

Während der Installation wurde auf meinem System die Swap-Datei /var/swap/swapfile in der Größe von 8 GiB eingerichtet (halbe RAM-Größe?). Außerdem verwendet Fedora standardmäßig Swap on ZRAM. Damit kann Fedora gerade ungenutzte Speicherseite in ein im RAM befindliches Device auslagern. Der Clou: Die Speicherseiten werden dabei komprimiert.

Beim meiner Konfiguration (16 GiB RAM, 8 GiB Swap-File, 8 GiB ZRAM-Swap) glaubt das System, dass es über fast 32 GiB Speicherplatz verfügen kann. (Etwas RAM wird für das Grafiksystem abgezwackt.) Ganz geht sich diese Rechnung natürlich nicht aus, weil ja das ZRAM-Swap selbst wieder Arbeitsspeicher kostet. Aber sagen wir 4 GB ZRAM entspricht mit Komprimierung 8 GB Speicherplatz + 11 GB restliches RAM + 8 GB Swapfile: das würde 27 GB Speicherplatz ergeben. Wenn nicht alle Programme zugleich aktiv sind, kann man damit schon arbeiten.

cat /proc/swaps

Filename             Type          Size      Used    Priority
/var/swap/swapfile   file          8388576   0       -2
/dev/zram0           partition     8388592   0       100

free -m
           total    used     free      shared  buff/cache   available
Mem:       15444    8063     2842        1521        7112        7381
Swap:      16383       0    16383

Weil ich beim Einsatz virtueller Maschinen gescheitert bin (siehe unten), kann ich nicht beurteilen, ob diese Konfiguration mit der Arbeitsspeicherverwaltung von macOS mithalten kann. Die funktioniert nämlich richtig gut. Auch macOS komprimiert Teile des gerade nicht genutzten Speichers und kompensiert so (ein wenig) den unendlichen Apple-Geiz, was die Ausstattung mit RAM betrifft (oder die Geldgier, wenn mehr RAM gewünscht wird).

Gnome + Fractional Scaling: mühsam wie vor 10 Jahren

Ein altes Problem: Auf meinem 4k-Monitor (27 Zoll) ist der Bildschirminhalt bei einer Skalierung von 100 % arg klein, bei 200 % sinnlos groß. Seit Jahren wird gepredigt, wie toll Gnome + Wayland ist, aber Fractional Scaling funktioniert immer noch nicht standardmäßig?

Dieses Problem lässt sich zum Glück lösen:

gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']"

Aus Gnome ausloggen, neu einloggen. Jetzt können in den Systemeinstellungen 125 % eingestellt, optimal für mich.

Die meisten Programme, die ich üblicherweise verwende, kommen mit 125 % gut zurecht. Wichtigste Ausnahme (für mich): Emacs. Die Textdarstellung ist ziemlich verschwommen. Angeblich gibt es eine Wayland-Version von Emacs (siehe hier), aber ich habe noch nicht versucht, sie zu installieren.

Webbrowser: kein Google Chrome

Als Webbrowser ist standardmäßig Firefox installiert und funktioniert ausgezeichnet. Chromium steht alternativ auch zur Verfügung (dnf install chromium). Ich bin allerdings, was den Webbrowser betrifft, in der Google-Welt zuhause. Ich habe mich vor über 10 Jahren für Google Chrome entschieden. Lesezeichen, Passwörter usw. — alles bei Google. (Bitte die Kommentare nicht für einen Browser-Glaubenskrieg nutzen, ich werde keine entsprechenden Kommentare freischalten.)

Insofern trifft es mich hart, dass es aktuell keine Linux-Version von Google Chrome für arm64 gibt. Ich habe also die Bookmarks + Passwörter nach Firefox importiert. Bookmarks sind easy, Passwörter müssen in Chrome in eine CSV-Datei exportiert und in Firefox wieder importiert werden. Mit etwas Webrecherche auch nicht schwierig, aber definitiv umständlich. Und natürlich ohne Synchronisation. (Für alle Firefox-Fans: Ja, auch Firefox funktioniert großartig, ich habe überhaupt keine Einwände. Wenn ich die Entscheidung heute treffen würde, wäre vielleicht Firefox der Gewinner. Google bekommt auch so genug von meinen Daten …)

Drag&Drop von Nautilus nach Firefox funktionierte bei meinen Tests nicht immer zuverlässig. Ich glaube, dass es sich dabei um ein Wayland-Problem handelt. Ähnliche Schwierigkeiten hatte ich auf meinen »normalen« Linux-Systemen (also x86) mit Google Chrome auch schon, wenn Wayland im Spiel war.

Nextcloud: perfekt

Zum Austausch meiner wichtigsten Dateien zwischen diversen Rechnern verwende ich Nextcloud. Ich habe nextcloud-client-nautilus installiert und eingerichtet, funktioniert wunderbar. Damit im Panel das Nextcloud-Icon angezeigt wird, ist die Gnome-Erweiterung AppIndicator and KStatusNotifierItem Support erforderlich.

Spotify + Firefox: gescheitert

Ich höre beim Arbeiten gerne Musik. Die Spotify-App gibt es nicht für arm64. Kein Problem, ich habe mich schon lange daran gewöhnt, Spotify im Webbrowser auszuführen. Aber Spotify hält nichts von Firefox: Wiedergabe von geschützten Inhalten ist nicht aktiviert.

Das Problem ist bekannt und gilt eigentlich als gelöst. Es muss das Widevine-Plugin installiert werden. Asahi greift dabei auf ein Paket der ChromeBooks zurück. Es kann mit widevine-installer installiert werden. (widevine-installer befindet sich im gleichnamigen Paket und ist standardmäßig installiert.) Gesagt, getan:

sudo widevine-installer 

This script will download, adapt, and install a copy of the Widevine
Content Decryption Module for aarch64 systems.

Widevine is a proprietary DRM technology developed by Google.
This script uses ARM64 builds intended for ChromeOS images and is
not supported nor endorsed by Google. The Asahi Linux community
also cannot provide direct support for using this proprietary
software, nor any guarantees about its security, quality,
functionality, nor privacy. You assume all responsibility for
usage of this script and of the installed CDM.

This installer will only adapt the binary file format of the CDM
for interoperability purposes, to make it function on vanilla
ARM64 systems (instead of just ChromeOS). The CDM software
itself will not be modified in any way.

Widevine version to be installed: 4.10.2662.3
...
Installing...
Setting up plugin for Firefox and Chromium-based browsers...
Cleaning up...

Installation complete!
Please restart your browser for the changes to take effect.

Nach einem Firefox-Neustart ändert sich: nichts. Ein weiterer Blick in discussion.fedoraproject.org verrät: Es muss auch der User Agent geändert werden, d.h. Firefox muss als Betriebssystem ChromeOS angeben:

Mozilla/5.0 (X11; CrOS aarch64 15329.44.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36

Es gibt zwei Möglichkeiten, den User Agent zu ändern. Die eine besteht darin, die Seite about:config zu öffnen, die Option general.useragent.override zu suchen und zu ändern. Das gilt dann aber für alle Webseiten, was mich nicht wirklich glücklich macht.

Die Alternative besteht darin, ein UserAgent-Plugin zu installieren. Ich habe mich für den User-Agent Switcher and Manager entschieden.

Langer Rede kurzer Sinn: Mit beiden Varianten ist es mir nicht gelungen, Spotify zur Zusammenarbeit zu überreden. An dieser Stelle habe ich nach rund einer Stunde Frickelei aufgegeben. Es gibt im Internet Berichte, wonach es funktionieren müsste. Vermutlich bin ich einfach zu blöd.

Spotify + Chromium: geht

Da wollte ich Firefox eine zweite Chance geben … Stattdessen Chromium installiert, damit funktioniert Spotify (widevine-installer vorausgesetzt) auf Anhieb. Sei’s drum.

Chromium läuft übrigens standardmäßig als X-Programm (nicht Wayland), aber nachdem ich den Browser aktuell nur als Spotify-Player benutze, habe ich mir nicht die Mühe gemacht, das zu ändern.

Visual Studio Code: weitgehend problemlos

VSCode lässt sich unkompliziert installieren; unter https://code.visualstudio.com/download gibt es arm64-Pakete (RPM).

Wie Emacs und Chromium läuft auch Code vorerst als X-Programm. Entsprechend unscharf ist die Schrift bei 125% Scaling. Das ArchWiki verrät, dass beim Programmstart die Option --ozone-platform-hint=auto übergeben werden muss. Das funktioniert tatsächlich: Plötzlich gestochen scharfe Schrift auch in Code.

Ich habe mir eine Kopie von code.desktop erstellt und die gerade erwähnte Option in die Exec-Zeile eingebaut. Bingo!

cp /usr/share/applications/code.desktop .local/share/applications/

qemu/libvirt/virt-manager: keine Grafik, keine Maus, keine Tastatur, kein Glück

Meine Arbeit spielt sich viel in virtuellen Maschinen und Containern ab. QEMU und die libvirt-Bibliotheken sind standardmäßig installiert, die grafische VM-Verwaltung gibt es mit dnf install virt-manager dazu.

Als nächstes habe ich mir ein Daily-ISO-Image für Arm64 von Ubuntu 24.04 heruntergeladen und versucht, es in einer virtuellen Maschine zu installieren. Kurz nach dem Start stürzt der virt-manager ab. Die virtuelle Maschine läuft weiter, allerdings nur im Textmodus. Später bleibt die die Installation in einer snap-Endlosschleife hängen. Nun gut, es ist eine Entwicklerversion, die noch nicht einmal offiziellen Beta-Status hat.

Nächster Versuch mit 23.10. Allerdings gibt es auf cdimage.ubuntu.com kein Desktop-Image für arm64!? Gut, ich nehme das Server-Image und baue dieses nach einer Minimalinstallation mit apt install ubuntu-desktop in ein Desktop-System um. Allerdings stellt sich heraus, dass apt sehr lange braucht (Größenordnung: eine Stunde, bei nur sporadischer CPU-Belastung; ich weiß nicht, was da schief läuft). Die Textkonsole im Viewer von virt-manager ist zudem ziemlich unbrauchbar. Installation fertig, Neustart der virtuellen Maschine. Es gelingt nicht, den Grafikmodus zu aktivieren.

Dritter Versuch, Debian 12 für arm64. Obwohl ich mich für eine Installation im Grafikmodus entscheide, erscheinen die Setup-Dialoge in einem recht trostlosen Textmodus (so, als würde die Konsole keine Farben unterstützen).

Schön langsam dämmert mir, dass mit dem Grafiksystem etwas nicht stimmt. Tatsächlich hat keine der virtuellen Maschinen ein Grafiksystem! (virt-manager unter x86 richtet das Grafiksystem automatisch ein, und es funktioniert — aber offenbar ist das unter arm64 anders.) Ich füge also das Grafiksystem manuell hinzu, aber wieder treten diverse Probleme auf: der VGA-Modus funktioniert nicht, beim Start der VM gibt es die Fehlermeldung failed to find romfile vgabios-stdvga.bin. QXL lässt sich nicht aktivieren: domain configuration does not support video model qxl. RAMfb führt zu einem EFI-Fehler während des Startups. Zuletzt habe ich mit virtio Glück. Allerdings funktioniert jetzt die Textkonsole nicht mehr, der Bootvorgang erfolgt im Blindflug.

Der Grafikmodus erscheint, aber die Maus bewegt sich nicht. Klar, weil der virt-manager auch das Mauseingabe-Modul nicht aktiviert hat. Ich füge auch diese Hardware-Komponente hinzu. Tatsächlich lässt sich der Mauscursor nach dem nächsten Neustart nutzen — aber die Tastatur geht nicht. Ja, die fehlt auch. Wieder ‚Gerät hinzufügen‘, ‚Eingabe/USB-Tastatur‘ führt zum Ziel. Vorübergehend habe ich jetzt ein Erfolgserlebnis, für ein paar Minuten kann ich Ubuntu 23.10 tatsächlich im Grafikmodus verwenden. Ich kann sogar eine angemessene Auflösung einstellen. Aber beim nächsten Neustart bleibt der Monitor schwarz: Display output is not active.

An dieser Stelle habe ich aufgegeben. Die nächste Auflage meines Linux-Buchs (die steht zum Glück erst 2025 an) könnte ich in dieser Umgebung nicht schreiben. Dazu brauche ich definitiv eine Linux-Installation auf x86-Hardware.

Docker, pardon, Podman: voll OK

Red Hat und Fedora meiden Docker wie der Teufel das Weihwasser. Dafür ist die Eigenentwicklung Podman standardmäßig installiert (Version 4.9). Das Programm ist weitestgehend kompatibel zu Docker und in der Regel ein guter Ersatz.

Ich setze in Docker normalerweise stark auf docker compose. Dieses Subkommando ist in Podman noch nicht integriert. Abhilfe schafft das (einigermaßen kompatible) Python-Script podman-compose, das mit dnf installiert wird und aktuell in Version 1.0.6 vorliegt.

Mein Versuch, mit Podman mein aus LaTeX und Pandoc bestehendes Build-System für meine Bücher zusammenzubauen, gelang damit überraschend problemlos. In compose.yaml musste ich die Services mit privileged: true kennzeichnen, um diversen Permission-denied-Fehlern aus dem Weg zu gehen. Auf jeden Fall sind hier keine unlösbaren Hürden aufgetreten.

Fazit

Soweit Asahi Linux mit Ihrem Mac kompatibel ist und Sie keine Features nutzen möchten, die noch nicht unterstützt werden (aus meiner Sicht am schmerzhaftesten: USB-C-Monitor, Mikrofon), funktioniert es großartig. Einerseits die Apple-Kombination aus hoher Performance und Stille, andererseits Linux mit all seinen Konfigurationsmöglichkeiten. Was will man mehr?

Leider sind die arm64-Plattform (genaugenommen aarch64) und Wayland noch immer nicht restlos Linux-Mainstream. Alle hier beschriebenen Ärgernisse hatten irgendwie damit zu tun — und nicht mit Asahi Linux! Der größte Stolperstein für mich: Mit virt-manager lässt sich nicht vernünftig arbeiten. Mag sein, dass sich diese Probleme umgehen lassen (Gnome Boxes?; Cockpit), aber ich befürchte, dass die Probleme tiefer gehen.

Eine gewisse Ironie an der Geschichte besteht darin, dass ich gerade am Raspberry-Pi-Buch arbeite: Raspberry Pi OS ist mittlerweile ebenfalls für die arm64-Architektur optimiert, es verwendet ebenfalls Wayland. Aber Fractional Scaling ist für den PIXEL Desktop sowieso nicht vorgesehen, damit entfallen alle damit verbundenen Probleme. So fällt es nicht auf, dass diverse Programme via XWayland laufen. Und um die arm64-Optimierungen hat sich die Raspberry Pi Foundation in den letzten Monaten gekümmert — zumindest, soweit es für den Raspberry Pi relevante Programme betrifft. Ich arbeite also momentan sowie schon in einer arm64-Welt, und es funktioniert verblüffend gut!

Wenn es also außer dem Raspberry Pi und den MacBooks noch ein paar »normale« Notebooks mit arm64-CPUs gäbe, würde das sowohl dem Markt als auch der Stabilität von Linux auf dieser Plattform gut tun.

Bleibt noch die Frage, ob Asahi Linux besser als macOS ist. Schwer zu sagen. Für hart-gesottene Linux-Fans sicher. Für meine alltägliche Arbeit ist der größte Linux-Pluspunkt absurderweise ein ganz winziges Detail: Ich verwende ununterbrochen die Linux-Funktion, dass ich Text mit der Maus markieren und dann sofort mit der mittleren Maustaste wieder einfügen kann. macOS kann das nicht. Für macOS spricht hingegen die naturgemäß bessere Unterstützung der Apple-Hardware.

Losgelöst davon funktionieren fast alle gängigen Open-Source-Tools auch unter macOS. Über den Desktop von macOS kann man denken, wie man will; ich kann damit leben. Hundertprozentig glücklich machen mich auch Gnome oder KDE nicht. In jedem Fall ist es unter macOS wie unter Linux mit etwas Arbeit verbunden, den Desktop so zu gestalten, wie ich ihn haben will.

PS: Ein persönliches Nachwort

Seit zwei Monaten verwende ich versuchsweise macOS auf einem Mac Mini (wie beschrieben, M1-CPU + 16 GB RAM) als Hauptdesktop. Ich schreibe/überarbeite dort meine Bücher, bereite den Unterricht vor, administriere Linux-Server, entwickle Code. Virtuelle Maschinen laufen mit UTM. Docker funktioniert gut, allerdings stört, dass der Speicher für Docker fix alloziert wird. (Docker unterstützt sogar Rosetta. Ich habe eine Docker-Umgebung, die ein x86-Binary enthält, zu dem es kein arm64-Äquivalent gibt. Und es läuft einfach, es ist schwer zu glauben …)

Ich verwende Chrome als Webbrowser, Thunderbird als E-Mail-Programm, LibreOffice für Office-Aufgaben, Gimp als Bitmap-Editor, draw.io als Zeichenprogramm, Emacs + Code als Editoren, Skim als PDF-Viewer. Im Terminal sind diverse SSH-Sessions aktiv, so dass ich den Raspberry Pi, meine Linux-Server usw. administrieren kann. Zusatzsoftware installiere ich mit brew so unkompliziert wie mit dnf oder apt. Im Prinzip bin ich auf keine unüberwindbaren Hindernisse gestoßen, um meine alltägliche Arbeit auszuführen.

Es gibt nur ganz wenige originale macOS-Programme, die ich regelmäßig ausführe: das Terminal, Preview + Fotos. Außerdem finde ich es praktisch, dass ich M$ Office nativ verwenden kann. Ich hasse Word zwar abgrundtief, muss aber beruflich doch hin und wieder damit arbeiten. Das habe ich bisher auf einem Windows-Rechner erledigt.

Letzten Endes ist der Grund für dieses Experiment banal: Mich nervt der Lüfter meines Linux-Notebooks (ein fünf Jahre alter Lenovo P1) immer mehr. Wenn ich die meiste Zeit Ruhe haben will, muss ich den Turbo-Modus der CPU deaktivieren. Ist es für Intel/AMD wirklich unmöglich, eine CPU zu bauen, die so energieeffizient ist wie die CPUs von Apple? Kann keiner der Mainstream-Notebook-Hersteller (Lenovo, Dell etc.) ein Notebook bauen, das ganz gezielt für den leisen Betrieb gedacht ist, OHNE die Performance gleich komplett auf 0 zu reduzieren?

Im Unterschied zum Lenovo P1 läuft mein Mac komplett lautlos und ist gleichzeitig um ein Mehrfaches schneller. Es ist nicht auszuschließen, dass mein nächstes Notebook keine CPU von Intel oder AMD haben wird, sondern eine M3- oder M4-CPU von Apple. Die Option, auf diesem zukünftigen MacBook evt. auch Linux ausführen zu können, ist ein Pluspunkt und der Grund, weswegen ich mich so intensiv mit Asahi Linux auseinandersetze.

Links/Quellen

• Asahi installieren: https://kofler.info/fedora-asahi-remix/
• Hardware-Unterstützung: https://asahilinux.org/fedora/
• Swap on RAM: https://fedoraproject.org/wiki/Changes/SwapOnZRAM
• Mac-Tastatur unter Linux: https://kofler.info/apple-aluminium-tastatur-unter-linux
• Firefox + Widevine: https://docs.fedoraproject.org/en-US/fedora-asahi-remix/faq/#_how_do_i_access_protected_content_in_browsers_widevine_drm, https://discussion.fedoraproject.org/t/firefox-and-widevine-aarch64-support/86797/4
• Emacs für Wayland: https://discussion.fedoraproject.org/t/wayland-native-emacs/99994
• VSCode für Wayland: https://wiki.archlinux.org/title/Wayland#Electron
• Podman Compose Permission Denied: https://stackoverflow.com/questions/72182709/weird-permissions-podman-docker-compose-volume

Ich habe es nicht ausprobiert, aber Sie können auch Ubuntu auf M1/M2-Macs installieren. Canonical überlegt anscheinend sogar, das irgendwann offiziell zu unterstützen.

• https://ubuntuasahi.org/
• https://github.com/UbuntuAsahi/ubuntu-asahi
• https://www.youtube.com/watch?v=EJ8hdpXkkMI&ab_channel=UbuntuOnAir

…dann können keine Ansible-Playbooks auf dem Zielsystem ausgeführt werden, Sysadmins lassen vom Schreiben der Playbooks ab und wenden sich der Fehleranalyse zu. Genau das mache ich nämlich gerade.

Und damit ihr auch etwas davon habt, halte ich das Ganze in diesen Beitrag fest. Die Gründe dafür sind vielfältig:

• Unerfahrene Sysadmins können lernen, wie man bei einer Fehleranalyse vorgehen kann, um nach endlich vielen Schritten zu einem Ergebnis zu kommen
• Falls ich meine Arbeit unterbrechen muss, kann ich mich mithilfe dieses Textes besser erinnern, was ich schon getestet habe und meine Arbeit fortsetzen
• Falls ich Expertenrat einholen muss, kann ich zeigen, was ich schon alles versucht habe

Die erfahrenen Supporter und Sysadmins unter euch sind gerne eingeladen, in den Kommentaren zu ergänzen, wie ihr bei so einem Problem vorgeht und was ich hätte besser machen können. So lernen wir alle etwas dabei.

Die Methode

Bei einer Fehleranalyse stochert man nicht einfach im Heuhaufen herum, in der Hoffnung eine Nadel zu finden. Ich gehe während der Fehleranalyse in folgender Schleife (Pseudocode) vor:

Solange das Problem besteht:
  Sichte und bewerte die vorhandenen Informationen;
  Forumuliere eine Hypothese zur Ursache des Problems;
  Überprüfe die Hypothese;
  Hast du damit das Problem gefunden, stelle es ab und höre auf;
  Hast du das Problem damit noch nicht gefunden, nimm die gewonnenen Erkenntnisse und iteriere;

Das Problem

$ ansible -i hosts host.example.com -m ping
host.example.com | FAILED! => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3.9"
    },
    "changed": false,
    "module_stderr": "Shared connection to host.example.com closed.\r\n",
    "module_stdout": "/usr/bin/python3.9: can't open file '/home/tronde/.ansible/tmp/ansible-tmp-1757269581.9965136-5304-74956742819711/AnsiballZ_ping.py': [Errno 1] Operation not permitted\r\n",
    "msg": "MODULE FAILURE: No start of json char found\nSee stdout/stderr for the exact error",
    "rc": 2
}

Der obige Code-Block zeigt das fehlgeschlagene Ansible-Ad-hoc-Kommando. Das Kommando führt das Module ansible.builtin.ping aus, welches prüft, ob eine Verbindung zum Zielsystem hergestellt werden kann und eine nutzbare Python-Umgebung gefunden wird. Wenn dies erfolgreich ist, sieht die Ausgabe wie im folgenden Code-Block aus:

$ ansible -i hosts host2.example.com -m ping
host2.example.com | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3.9"
    },
    "changed": false,
    "ping": "pong"
}

Die Ausgangslage

Bevor ich mit der Fehleranalyse beginne, schreibe ich auf, was ich über meinen Ansible Control Node und meine beiden Managed Nodes weiß.

Ansible Control Node

• Fedora release 42 (Adams)
• ansible [core 2.18.6]
  • config file = /etc/ansible/ansible.cfg
  • ansible python module location = /usr/lib/python3.13/site-packages/ansible
  • executable location = /usr/bin/ansible
  • python version = 3.13.7 (main, Aug 14 2025, 00:00:00) GCC 15.2.1 20250808 (Red Hat 15.2.1-1)
  • jinja version = 3.1.6
  • libyaml = True

Ansible Managed Nodes

Über host.example.com und host2.example.com ist bekannt, dass es:

• sich um Red Hat Enterprise Linux release 9.6 (Plow) handelt
• Ich mich mit dem User tronde und SSH-Private-Key einloggen kann
  • Bei tronde handelt es sich um einen unprivilegierten Benutzer
  • Dieser darf sudo nutzen, um seine Rechte auszuweiten; dazu muss ein Passwort eingegeben werden
• SELinux auf Enforcing steht

Die Fehlermeldung

Und ich habe natürlich eine Fehlermeldung:

"module_stdout": "/usr/bin/python3.9: can't open file '/home/tronde/.ansible/tmp/ansible-tmp-1757269581.9965136-5304-74956742819711/AnsiballZ_ping.py': [Errno 1] Operation not permitted\r\n",

Python meldet, dass die Ausführung von AnsiballZ_ping.py nicht zugelassen ist.

Hypothese 1: Es liegt nicht an AnsiballZ_ping.py

Wenn dieses Python-Skript nicht ausgeführt werden kann, kann ein anderes Python-Skript ebenfalls nicht ausgeführt weden. Um diese Hypothese zur überprüfen, versuche ich, die UID des Benutzers mit dem Modul ansible.builtin.command abzufragen:

$ ansible -i hosts host.example.com -m command -a 'id'
host.example.com | FAILED! => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3.9"
    },
    "changed": false,
    "module_stderr": "Shared connection to host.example.com closed.\r\n",
    "module_stdout": "/usr/bin/python3.9: can't open file '/home/tronde/.ansible/tmp/ansible-tmp-1757271016.543905-6189-111082369101490/AnsiballZ_command.py': [Errno 1] Operation not permitted\r\n",
    "msg": "MODULE FAILURE: No start of json char found\nSee stdout/stderr for the exact error",
    "rc": 2
}

Damit ist bewiesen, dass die Fehlerursache nicht allein im Skript AnsiballZ_ping.py liegt.

Hypothese 2: Es ist ein Problem mit Berechtigungen

Die Meldung [Errno 1] Operation not permitted deutet an, dass fehlende Berechtigungen die Ursache sein können. Also führe ich das Kommando auf dem betroffenen Managed Node einmal als root aus.

$ ansible -i hosts host.example.com -m ping -b -K
BECOME password: 
host.example.com | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3.9"
    },
    "changed": false,
    "ping": "pong"
}

Root darf also, was tronde nicht darf, denn mit erweiterten Berechtigungen kann das Kommando erfolgreich ausgeführt werden. Die Python-Skripte, die tronde nicht ausführen darf, liegen im Pfad /home/tronde/.ansible/tmp/<von-Ansible-temporär-erstelltes-Verzeichnis>/AnsiballZ_{command,ping}.py.

Hypothese 3: tronde darf keine Python-Skripte ausführen

Genauer gesagt, tronde darf keine Python-Skripte ausführen, welche unterhalb von /home/tronde/.ansible/tmp/ abgelegt sind. Auch diese These wird direkt geprüft. Dazu logge ich mich per SSH als User tronde auf dem Zielsystem ein, erstelle ein einfaches Python-Skript und versuche dieses auszuführen:

$ mkdir /home/tronde/.ansible/tmp/test
$ cat << EOF > /home/tronde/.ansible/tmp/test/hello.py
> #!/usr/bin/env python3.9
> print("Hello World")
> EOF
$ chmod u+x /home/tronde/.ansible/tmp/test/hello.py
$ /usr/bin/python3.9 /home/tronde/.ansible/tmp/test/hello.py
/usr/bin/python3.9: can't open file '/home/tronde/.ansible/tmp/test/hello.py': [Errno 1] Operation not permitted

Durch diesen Test habe die Hypothese verifiziert und zusätzlich folgendes gelernt: Meine Ansible-Konfiguration auf meinem Ansible Control Node hat nichts mit dem Problem zu tun, da das Problem auftritt, wenn Ansible gar nicht beteiligt ist.

Hypothese 4: Falsche Datei-Berechigungen verhindern die Ausführung der Datei

Ich schaue mir die Datei-Berechtigungen bis zur Datei hello.py mit dem Programm namei(1) an:

$ namei -mo /home/tronde/.ansible/tmp/test/hello.py
f: /home/tronde/.ansible/tmp/test/hello.py
 dr-xr-xr-x root      root      /
 drwxr-xr-x root      root      home
 drwxr-x--- tronde tronde tronde
 drwxrwxr-x tronde tronde .ansible
 drwx------ tronde tronde tmp
 drwxr-xr-x tronde tronde test
 -rwxr--r-- tronde tronde hello.py

Das sieht auf den ersten Blick nicht verkehrt aus. Ich wechsel in das Verzeichnis und lasse mir die Attribute der Datei mit verschiedenen Programmen anzeigen.

$ cd .ansible/tmp/test/
$ stat hello.py
  File: hello.py
  Size: 46        	Blocks: 8          IO Block: 4096   regular file
Device: fd06h/64774d	Inode: 51511298    Links: 1
Access: (0744/-rwxr--r--)  Uid: ( 1000/tronde)   Gid: ( 1000/tronde)
Context: unconfined_u:object_r:user_home_t:s0
Access: 2025-09-07 21:21:08.201875001 +0200
Modify: 2025-09-07 21:23:04.564787755 +0200
Change: 2025-09-07 21:23:25.642771941 +0200
 Birth: 2025-09-07 21:21:08.201875001 +0200

$ getfacl hello.py
# file: hello.py
# owner: tronde
# group: tronde
user::rwx
group::r--
other::r--

$ file hello.py 
hello.py: writable, executable, regular file, no read permission

Datei-Berechtigungen und Linux-ACL bescheinigen dem User tronde Lesezugriff auf die Datei hello.py. Das file-Kommando bescheinigt jedoch no read permission.

Hypothese 5: Das chmod u+x verursacht das Problem

Nach der Erstellung des Skripts habe ich dieses mit chmod u+x ausführbar gemacht. Vielleicht verursacht erst dieser Befehl das Problem. Also schaue ich mir die Informationen zum Dateityp vor und nach dem Kommando an. Dazu erstelle ich ein neues Skript.

$ cat <<EOF >hello2.py
> #!/usr/bin/env python3.9
> print("Hello Sysadmin.")
> EOF
$ file hello2.py 
hello2.py: writable, regular file, no read permission

Damit kann ich chmod ebenfalls als Fehlerquelle ausschließen.

Hypothese 6: Shebang verursacht das Problem

Die Shebang #! sorgt dafür, dass das folgende Kommando mit dem Dateinamen als Argument ausgeführt wird. Gleichzeitig gibt die Shebang auch dem Programm file einen Hinweis darauf, um welchen Dateityp es sich handelt.

Zur Überprüfung dieser Hypothese erhebe ich zuerst die Antworten zu folgenden Fragen.

Kann das Skript ohne Shebang ausgeführt werden?

Bei der Überprüfung von Hypothese 2 habe ich verifiziert, dass root die Dateien wie gewohnt ausführen kann. Nun editiere ich die Datei hello2.py mit root-Rechten und entferne die Shebang. Anschließend versuche ich als User tronde, die Datei mit Hilfe des Python3.9-Interpreters auszuführen.

$ file hello2.py 
hello2.py: ASCII text
$ cat hello2.py 
print("Hello Sysadmin.")
$ /usr/bin/python3.9 hello2.py 
Hello Sysadmin.

Ohne Shebang kann ich das Skript ausführen. Füge ich die Shebang wieder ein, ist der Fehler zurück. Ich kann die Datei noch nicht mal mehr lesen:

$ cat hello2.py 
cat: hello2.py: Operation not permitted

$ sudo !!
sudo cat hello2.py 
#!/usr/bin/python3.9
print("Hello Sysadmin.")

Zeigen Bash-Skripte mit Shebang das gleiche Verhalten?

$ cat <<EOF >world.sh
> #!/usr/bin/env bash
> echo "Hello world."
> EOF

$ file world.sh 
world.sh: Bourne-Again shell script, ASCII text executable

$ cat world.sh 
#!/usr/bin/env bash
echo "Hello world."

$ bash world.sh 
Hello world.

$ chmod u+x world.sh

$ ./world.sh 
Hello world.

Hier ist das Verhalten wie erwartet. Damit ist zwar noch nicht sicher bewiesen, dass das Shebang-Problem mit dem Python-Interpreter zusammenhängt, es gibt aber einen ersten Hinweis.

Wie sieht die Ausgabe von file auf einem Referenzsystem aus?

Mit host2 habe ich ja ein System, das Python-Skripte ohne Fehler ausführt. Ich erstelle auch hier das hello.py-Skript inkl. Shebang und lasse mir die Ausgabe von file anzeigen:

$ cat <<EOF >hello.py
> #!/usr/bin/env python3.9
> print("Hello, world.")
> EOF

$ file hello.py 
hello.py: Python script, ASCII text executable

Hier findet sich kein Hinweis auf no read permission.

Hypothese 7: Es ist nur der User tronde betroffen

Um diese Hypothese zu prüfen, erstelle ich einen neuen Benutzer test, ein Python-Skript und prüfe, ob das Problem auftritt:

# useradd test
# su - test
$ pwd
/home/test
$ cat <<EOF >hello.py
> #!/usr/bin/env python3
> print("Hello, world.")
> EOF
$ cat hello.py 
cat: hello.py: Operation not permitted

Das Problem ist nicht auf den User tronde beschränkt. Es scheint alle nicht privilegierten User zu betreffen.

Zwischenfazit

• Das Problem scheint Host-spezifisch zu sein, da es auf einem Referenzsystem nicht auftritt
• Das Problem tritt nur auf, wenn nicht privilegierte User ein Python-Skript ausführen, welches eine Shebang enthält
  • Diese Skripte können jedoch mit root-Rechten ausgeführt werden
  • Ohne die Shebang können die Skripte mittels /usr/bin/python3 <scriptname> ausgeführt werden
• Ist eine Shebang enthalten, die einen Python-Interpreter enthält, verlieren unprivilegierte User den Lesezugriff auf die Datei (cat, less, etc. sind dann ebenfalls betroffen)
• Trage ich eine andere Shebang z.B. #!/usr/bin/bash ein, kann ich das Skript als unprivilegierter User mittels `python3 <scriptname>` korrekt ausführen

Für mich bedeutet das leider, dass ich mir nun Hilfe suchen muss, da mir die Ideen ausgehen. Also beginne ich mit einer Internetsuche nach „troubleshooting shebang in python3″… und frage anschließend eine Kollegin um Rat. Vielen lieben Dank Michi für deine Zeit und Ideen!

Die Ursache

Michi und ich haben uns in einer Videokonferenz zusammengefunden und das Problem gemeinsam untersucht. Dabei sind wir nach obigen Muster vorgegangen:

1. Genau eine Sache überprüfen
2. Ergebnis auswerten
3. Eine weitere Vermutung prüfen
4. Ergebnis auswerten usw.

Dabei haben wir uns SELinux, das Audit-Log, die Linux-ACLs, das Environment, alias, locale und die Ausgabe diverser strace-Kommandos angeschaut. Die Details spare ich an dieser Stelle ein und komme zum Wesentlichen. Michi fand diesen Foreneintrag: Non-root users unable to read perl scripts. Darin wird fapolicyd als Fehlerquelle identifiziert. Und das ist tatsächlich auch in meinem Fall der Übeltäter.

Stoppe ich fapolicyd.service, kann ich die Python-Skripte mit Shebang wieder ausführen. Starte ich den Dienst erneut, ist auch das Problem zurück. Die Ursache ist identifiziert.

Moment, was ist fapolicyd?

Das Software-Framework fapolicyd steuert die Ausführung von Anwendungen basierend auf einer benutzerdefinierten Richtlinie. Dies ist eine der effizientesten Methoden, um die Ausführung nicht vertrauenswürdiger und potenziell bösartiger Anwendungen auf dem System zu verhindern.

Übersetzung aus Introduction to fapolicyd

Die von Ansible generierten und die von mir zum Test erstellten Python-Skripte wurden in der Ausführung blockiert, da diese als nicht vertrauenswürdig eingestuft wurden.

Allerdings fällt das in diesem Fall in die Kategorie „Gut gemeint ist nicht gleich gut gemacht“. Denn während zwar der Zugriff auf Python-Skripte mit Shebang für nicht-privilegierte User blockiert wird, können Skripte ohne entsprechende Shebang weiterhin ausgeführt werden. Wirkliche Sicherheit bietet dies nicht. Ich mache mir dazu mal eine Notiz, um das beobachtete Verhalten im Nachgang mit den Entwicklern zu diskutieren. Vielleicht habe ich das Design und Konzept von fapolicyd noch nicht ganz verstanden.

Warum ich da nicht früher drauf gekommen bin

• Keine Ausgabe gab einen Hinweis darauf, dass fapolicyd die Ausführung blockiert
• Ich habe fapolicyd vor langer Zeit zum Test auf diesem Host installiert und vergessen, dass es läuft
• Durch fehlende Konfiguration gab es keine Einträge im Audit-Log, die auf die Ursache hätten hinweisen können

Wie findet man die Ursache, wenn man weiß, dass fapolicyd läuft?

Erstmal muss man wissen bzw. sich in meinem Fall daran erinnern, dass fapolicyd läuft. Dann kann man für einen schnellen Test fapolicyd.service stoppen und prüfen, ob das Problem noch besteht.

Um nun herauszufinden, warum fapolicyd die Ausführung von Python-Skripten mit Shebang blockiert, folge ich der Dokumentation in Kapitel 12.6. Troubleshooting problems related to fapolicyd. Ich stoppe fapolicyd.service und starte den Dienst mit dem Befehl fapolicyd --debug-deny. Damit werden nur Einträge ausgegeben, die blockierte Zugriffe zeigen. In diesem Modus führe ich den ursprünglichen Ansible-Ad-hoc-Befehl ansible -i hosts host.example.com -m ping aus, der wie erwartet fehlschlägt. In der Ausgabe auf host.example.com sehe ich nun:

09/08/2025 20:39:07 [ DEBUG ]: Rule number API supported yes                                            
09/08/2025 20:39:08 [ DEBUG ]: rule=11 dec=deny_audit perm=open auid=1000 pid=693342 exe=/usr/bin/python3.9 : path=/home/tronde/.ansible/tmp/ansible-tmp-1757356747.8650832-23284-14960045792104/AnsiballZ_ping.py ftype=text/x-python trust=0
09/08/2025 20:39:08 [ DEBUG ]: rule=11 dec=deny_audit perm=open auid=1000 pid=693342 exe=/usr/bin/python3.9 : path=/home/tronde/.ansible/tmp/ansible-tmp-1757356747.8650832-23284-14960045792104/AnsiballZ_ping.py ftype=text/x-python trust=0

Die Lösung

Damit ich host.example.com mit Ansible verwalten kann, muss ich die Ausführung von Python-Skripten unterhalb von /home/tronde/.ansible/tmp/ erlauben. Das dazu erforderliche Vorgehen ist in der Dokumentation in Kapitel 12.4. Adding custom allow and deny rules for fapolicyd beschrieben. Für meinen konkreten Fall sehen die einzelnen Schritte wie folgt aus:

Nach obiger Ausgabe habe ich Regel 11 (rule=11) getriggert. Also schaue ich mir zuerst an, was in Regel 11 steht und anschließend, in welcher Datei unterhalb von /etc/fapolicyd/rules.d diese Regel steht:

~]# fapolicyd-cli --list | grep 11
11. deny_audit perm=any all : ftype=%languages

~]# grep 'deny_audit perm=any all : ftype=%languages' /etc/fapolicyd/rules.d/*
/etc/fapolicyd/rules.d/70-trusted-lang.rules:deny_audit perm=any all : ftype=%languages

Anschließend erstelle ich eine Allow-Regel, in einer neuen Datei. Diese muss lexikalisch vor obiger Datei mit der Deny-Regel liegen:

~]# cat <<EOF >/etc/fapolicyd/rules.d/69-trusted-ansible-scripts.rules
> allow perm=any exe=/usr/bin/python3.9 trust=1 : dir=/home/tronde/.ansible/tmp/ trust=0
> EOF

~]# fagenrules --check
/sbin/fagenrules: Rules have changed and should be updated

~]# fagenrules --load
~]#

Anschließend führe ich zum Test folgende Kommandos aus:

1. Auf host.example.com: fapolicy --debug-deny
2. Auf meinem Ansible Control Node: $ ansible -i inventory host.example.com -m ping

Ich bestaune das gewünschte Ergebnis:

host.example.com | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3"
    },
    "changed": false,
    "ping": "pong"
}

Nun beende ich den Debug-Modus und starte fapolicyd.service. Fehleranalyse und Entstörung sind damit beendet.

Für welche Anwendungsfälle diese Lösung funktioniert

Die obige Lösung sorgt dafür, dass Python-Skripte unterhalb des Verzeichnisses /home/tronde/.ansible/tmp/, welche eine Python-Shebang beinhalten, mit dem Python-Interpreter /usr/bin/python3.9 ausgeführt werden können.

Diese Lösung funktioniert nicht

• Für andere unprivilegierte User außer tronde
• Für andere Python-Interpreter wie z.B. /usr/bin/python3 oder /usr/bin/python3.11

Hinterher ist man immer schlauer

Jetzt, wo ich weiß, wonach ich suchen muss, finde ich auch direkt mehrere Treffer in den Red Hat Solutions:

• Why do I get unexpected “Operation not permitted” errors when trying to access files
• No FANOTIFY event seen in the audit log despite fapolicyd blocking operations
• Fapolicyd : Configure ansible automation execution for non-root users
• [AAP] Ansible job callback get „PermissionError“ „Operation not permitted“ due to fapolicyd deny rule

Dokumentation findet sich neben der Manpage fapolicyd(8) z.B. auch im RHEL 9 Security Hardening Guide ab Kapitel 12. Mit RHELDOCS-20981 – Improve section „Deploying fapolicyd“ in RHEL Security Hardening Guide – habe ich zudem einen Verbesserungsvorschlag eingereicht.

Fazit

Dieser Text hat an einem konkreten Beispiel gezeigt, wie eine strukturierte Fehleranalyse durchgeführt wird. Diese führt über die Problembeschreibung sowie das Formulieren von Hypothesen und deren Falsifizierung/Verifizierung nach endlich vielen Schritten zu einer Lösung.

Die Länge des Textes zeigt, wie aufwändig eine Fehleranalyse werden kann. Wenn man keinen direkten Zugriff auf das betroffene System hat und mit jemandem ausschließlich über ein Ticket-System kommunizieren kann, wird schnell klar, dass sich ein Fall über mehrere Tage und Wochen hinziehen kann.

Ich war irgendwann geistig erschöpft und hatte keine Lust mehr allein weiterzumachen, da mir die Ideen ausgingen. In diesem Fall hilft es, sich einen frischen Geist zur Unterstützung zu holen. Gemeinsam mit meiner Kollegin Michi konnte die Ursache (fapolicyd) identifiziert werden.

Mit Hilfe der Dokumentation war ich dann auch in der Lage, das Problem zu lösen. Ich kann nun Ansible-Playbooks auf dem Zielsystem ausführen.

Der Dienst fapolicyd überzeugt mich nicht. Meine Gedanken dazu werde ich in einem Folgeartikel mit euch teilen.

In einem weiteren Folgeartikel werde ich darüber schreiben, was Hilfesuchende und Supporter tun können, damit beide Seiten eine möglichst gute Support-Erfahrung haben.

Ich freue mich nun über ein gelöstes Problem und schreibe an meinem Ansible-Playbook weiter.

Agenda-Siegel 2018 der Stadt Dortmund an die GEMEINGÜTER-Initiative verliehen

Bild: Gemeingütertag der GEMEINGÜTER-Initiative von Pauluskirche und Kultur

Für die Organisation des Gemeingütertages – Commons, Nachhaltigkeit und Klima hat die GEMEINGÜTER-Initiative unseres Kooperationspartners Pauluskirche und Kultur das Agenda-Siegel 2018 erhalten. Zu dem Gemeingütertag hat Do-FOSS gemeinsam mit dem Kooperationspartner der FOSS-AG und dem Open-Office-Veranstalter Reiner Bock einen Beitrag geleistet.

Der Gemeingütertag bot einen breiten Kontext in dem u.a. Freie Software als Commons diskutiert wurde.

Commons sind Ressourcen (Code, Wissen, Nahrung, Energiequellen, Wasser, Land, Zeit u.a.), die aus selbstorganisierten Prozessen des gemeinsamen bedürfnisorientierten Produzierens, Verwaltens, Pflegens und/oder Nutzens (Commoning) hervorgehen. ^[1]

Wer mehr zum Kerngedanken des Themas Commons erfahren möchte, sei auf den Einführungsvortrag des Gemeingütertags vom Commons-Institut hingewiesen. Ergänzend hierzu stellt Do-FOSS gesammelte Unterlagen zum Thema Commons zur Verfügung.

Do-FOSS gratuliert der GEMEINGÜTER-Initiative für den Erhalt des Agenda-Siegels 2018. Den Commons-Aspekt von Freier Software sieht Do-FOSS dabei als sehr gute Ergänzung zu der eigenen Auszeichnung mit dem Agenda-Siegel 2016, welche sich auf Nachhaltigkeitsaspekte von Freier Software bezog.

Im Folgenden soll die Bewerbung der GEMEINGÜTER-Initiative für sich selbst sprechen.

Bewerbung der GEMEINGÜTER-Initiative um das Agenda-Siegel 2018 im Wortlaut

Bewerbungsbogen

Die Stadt Dortmund verleiht das Agenda-Siegel als Auszeichnung für bürgerschaftliche Projekte und Ideen im Bereich nachhaltiger Entwicklung, die im Sinne der Agenda 21 ökologische, ökonomische und soziale Dimensionen verbinden. Auch Projekte unter dem Motto „Global denken, lokal handeln“ sind gefragt. Damit soll Engagement aus der Mitte der Gesellschaft ausgezeichnet und der Begriff „Nachhaltigkeit“ vor Ort mit Leben erfüllt werden.

Einsendeschluss: 31. Oktober 2018

Angaben zum Projekt:
1. Bezeichnung/Name des Projekts:

Gemeingütertag – Commons, Nachhaltigkeit und Klima
Leben ist für Alle!
(s. 02. Anlage – Gemeingütertag (Logo) und Pressefoto 03. Anlage – Pressefoto Gemeingütertag (Foto))

Der Gemeingütertag – eine Veranstaltung der GEMEINGÜTER-Initiative von Pauluskirche und Kultur – fand ganztägig am Samstag, den 7. Juli 2018 statt und bestand aus einem facettenreichen Programm mit vielen Organisationen und Initiativen – diese boten: Informationsstände rund um die Kirche, Mitmachaktionen, Vorträge, Themenforen, Gesprächskreise, Workshops, Kultur, sowie Essen und Trinken, Shops und vieles mehr. Der Eintritt war FREI! Alle waren willkommen!

Bereits am Freitag, den 6. Juli 2018 gab es ein Auftaktkonzert zum Gemeingütertag. Es war ein Konzert ohne Eintrittsgeld. Alle konnten entscheiden was sie geben möchten und den entsprechenden Betrag in einen Hut legen. Kultur ist für Alle!

Dem Gemeingütertag lagen folgende Überlegungen zu Grunde:

Luthers Gnadenlehre
Martin Luthers Gnadenlehre sagt: der Glaube ist ein Geschenk. Da gibt es nichts, was du dafür leisten musst. Du bist ein geliebtes Kind Gottes. Von Anbeginn an.

>>Gottes Güter umsonst
Dass die Menschen an allen Gütern der Gemeinschaft teilhaben können unabhängig von ihrer Leistung, das wäre – so der Reformationshistoriker Berndt Hamm – die Überführung der Gnadenlehre Luthers in eine Gesellschaftstheorie. Commons, Gemeingüter als Konsequenz aus Luthers Gnadenlehre: Weil wir Menschen sind, nimmt uns Gott an. Weil wir Menschen sind, steht uns zu, was wir zum Leben brauchen – nicht aufgrund irgendeiner Leistung.<< (Christoph
Fleischmann; Podcast und Manuskript: https://tinyurl.com/Gottes-Gueter-umsonst)

Wer verfügt über unsere Lebensgüter?
Wir haben im Reformationsjahr (2016-2017) viel darüber gesprochen, wer über unsere Lebensgüter verfügt (vgl. https://tinyurl.com/Wvd-Flyer, s. a. Videozusammenfassung der Veranstaltungsreihe „Wer verfügt darüber?“ vom 13.06.2017 [https://tinyurl.com/WvD-Video, Länge: 15:51 Min.]). Sollten nicht alle lebenswichtigen Güter wie Wasser, Saatgut, Medikamente, Energie und heutzutage auch Digitales Frei für alle verfügbar sein? So wie die Bibel, die jeder lesen und verstehen können sollte, so wie der Glaube, den nicht allein die Kirchen bestimmen sollten. Bisher bestimmen aber Privatinteressen, z.B. große Konzerne, über unser aller Lebensgüter und betrachten diese als ihr Eigentum.

Was steht mir als Mensch zu, weil ich Mensch bin?
>>Wenn wir uns zu dieser Haltung durchringen können: Dass Menschsein an sich bedeutet, dass wir teilhaben an den Ressourcen dieser Erde, die uns geschenkt worden sind. Und dann versuchen wir diese Ressourcen dieser Erde so gemeinschaftlich zu verwalten, dass wir es nicht abhängig machen von der Leistung des Einzelnen und dem Geldeinkommen des Einzelnen. Das ist tatsächlich ein Paradigmenwechsel, denn da geht es um die Frage, wie verhalten wir uns zu dem Anderen und wie können wir dafür sorgen, dass alle mitkommen und niemand ausgeschlossen wird. […] Weil wir Mensch sind, steht uns [Frei] zu, was wir zum Leben brauchen. Und nicht: Nur wer arbeitet, darf auch essen.<< (Silke Helfrich; https://commons.blog)

Wie können Frei verfügbare Ressourcen beschrieben werden?
„Eine Ressource ist Frei, wenn
(1) man sie ohne Erlaubnis nutzen kann; oder
(2) die Erlaubnis, sie zu nutzen, neutral vergeben
wird.“ (Lawrence Lessig)

Eine Welt – für Alle
In der GEMEINGÜTER-Initiative werden wir weiter über die Verfügungsrechte unserer Lebensgüter diskutieren und für Veränderungen in der Wahrnehmung unserer Menschenrechte eintreten. Hierzu war der ‚Gemeingütertag – Commons, Nachhaltigkeit und Klima‘ ein Beitrag von uns für Eine Welt für Alle.

Den Aktiven des Gemeingütertages war gemeinsam, dass sie sich in eines der Unterthemen des Gemeingütertages – nämlich Commons, Nachhaltigkeit und Klima – einordnen konnten (vgl. 04. Anlage – Gemeingütertag – Programm).

2. Welche Ziele verfolgen Sie mit dem Projekt?

Der Gemeingütertag verfolgte im Wesentlichen zwei Ziele:

• Zum einen sollte ein Ort der Begegnung im Lichte sozialer und ökologischer Überlegungen geschaffen werden. Dies ist mit dem Gemeingütertag gelungen.
• Zum anderen sollten sich soziale und ökologische Fragen sichtbar miteinander verbinden. Denn in der Beantwortung unserer ökologischen Fragen durch soziale Perspektiven, werden Möglichkeiten für ein zukunftsfähiges Zusammenleben gesehen.

Die planetaren Grenzen werden mit unserer jetzigen Lebensweise überschritten. Daher bedürfen wir einer sozialökologischen Transformation. Diese transformative Notwendigkeit haben wir am Gemeingütertag weiter befördert und verfolgen sie in der GEMEINGÜTER-Initiative täglich weiter.

3. Bitte geben Sie möglichst vollständig an, welche Aspekte nachhaltiger Entwicklung berührt sind.

? Ökonomie
? Ökologie
? Soziales
? Globales/Internationales

4. Bitte beschreiben Sie möglichst umfassend, welchen Beitrag das Projekt zu den acht Kriterien
des Agenda-Siegels leistet.

4.1 Themenübergreifender Ansatz
(z. B. gleichwertige Berücksichtigung sozialer, ökonomischer und ökologischer Kriterien, interdisziplinärer
und ressort-übergreifender Ansatz)

Der Gemeingütertag bot die folgenden Themen (alphabetisch):

• Armutsverwaltung in Dortmund
• Bedingungsloses Existenzrecht – Bedingungsloses Grundeinkommen
• Bildung
• Commons
• Eine Welt
• Energie
• Ernährung
• Fair Trade
• Faircomomy
• Fahrrad fahren in Dortmund
• Flucht
• FreiFunk
• Freie Software
• Frieden
• Geld/Finanzen
• Gemeinwohlökonomie
• Genossenschaftsgedanken
• Gesundheit
• Gewaltfreie Kommunikation
• Gewerkschaft
• Kirchentag 2019 in Dortmund
• Klimaschutz und Klimaanpassung in Dortmund
• Kultur
• Landraub/Migration
• Menschenrechte
• Minimalismus
• Müll
• Nachhaltigkeit
• Reichtum
• Reparierbarkeit
• Theologie des Lebens
• Veganismus
• Wasser

4.2 Kommunikation und Beteiligung
(z. B. besondere Form oder Intensität der Beteiligung und Mitwirkung von Bürgerinnen und Bürgern)

Es waren alle Menschen offen zum Besuch des Gemeingütertages, zum Mitdiskutieren und auch zur späteren Mitarbeit in der GEMEINGÜTER-Initiative eingeladen.

Die Ergebnisse unseres gemeinsamen Tages arbeiten wir in der GEMEINGÜTER-Initiative derzeit auf und werden diese in den Kirchentag 2019 einbringen, der vom 19.-23. Juni 2019 in Dortmund stattfinden wird. Alle Beteiligten Organisationen sind in diesen Prozess eingebunden.

4.3 Impulse und Innovationsanstöße
(z. B. experimenteller Charakter, ungewöhnlicher Lösungsansatz)

„Die Logik des Kapitalismus heißt teilen. Nur teilen darin nicht die Menschen, sondern sie werden geteilt.“ (Quelle: 05. Anlage – Heinrich Böll Stiftung – Die Welt der Commons – Muster gemeinsamen Handelns (2015)). Entsprechend war eine Überlegung, die zum Gemeingütertag geführt hat diese: Wie können Lern- und Emanzipationsprozesse so gestaltet werden, dass Menschen aus Markt- und Konsumlogik befreit werden, die entfremdet und vereinzelt? Um diese Frage zu beantworten wurden Commons beim Gemeingütertag als beziehungstragendes Sozialgefüge erprobt. Es ging darum durcheinander wie aneinander zu sein und zu werden. Entsprechend war der Gemeingütertag dem kreativen Imperativ der Commons verpflichtet: >>Gestaltung für Menschen und Leben. Nicht für Profit.<< Die Konzepte hierfür wurden von den Aktiven des Gemeingütertages mitgebracht (vgl. 04. Anlage – Gemeingütertag – Programm).

4.4 Langfristigkeit und Handlungsorientierung
(z. B. Veränderbarkeit und Anpassungsfähigkeit an künftige Entwicklungen, messbare Erfolge)

Das Rahmenwerk des Programms war modular aufgebaut. Insofern könnte der Gemeingütertag in seinen Grundüberlegungen (in beliebiger Zusammensetzung) wiederholt werden (vgl. 4.6 Übertragbarkeit und Multiplikationsfähigkeit).

Eine Grundüberlegung des Gemeingütertages war es einen Ort der Begegnung zu schaffen. Dies hat in vielen Teilnehmenden eine Resonanz erzeugt. Messbar ist diese Kulturarbeit jedoch (zunächst) nicht. In vielen Gesprächen, die nach dem Gemeingütertag stattgefunden haben, war diese Resonanz aber erfahrbar (vgl. 4.8 Kontinuität).

4.5 Ressourcenschonung
(z. B. Umweltverträglichkeit, Ressourceneffizienz, Vermeidung künftiger Altlasten, Flächenrecycling
und Wiederverwertbarkeit)

Abgesehen von den zahlreichen Aktiven des Gemeingütertages, die sich für Nachhaltigkeit einsetzen, war die Veranstaltungsdurchführung möglichst ressourcenschonend ausgelegt. Seitens der Pauluskirche wurden die Materialien mit Lastenrädern transportiert und der Essensstand der beiden Veranstaltungstage „miteinander vegan“ (https://www.miteinander.world) hat ausschließlich kompostierbares Geschirr ausgegeben. Darüber hinaus ist die vegane Lebensweise deutlichst umweltverträglicher als eine Lebensweise mit Tierprodukten (vgl. 06.1 Anlage – Treibhauseffekt verschiedener Ernährungsweisen pro Kopf und Jahr dargestellt in Autokilometern (08.2008) und 06.2 Anlage – Treibhauseffekt der Herstellung von Nahrungsmitteln dargestellt in Autokilometern (08.2008)).

4.6 Übertragbarkeit und Multiplikationsfähigkeit
(z. B. Projekte müssen von anderen Akteuren nachempfunden werden können)

Das Konzept und die Grafiken des Gemeingütertages sind unter der Creative Commons‘ CC0 (http://creativecommons.org/publicdomain/zero/1.0/deed.de) verfügbar. Das heißt, dass das Konzept und die Grafiken (http://www.pauluskircheundkultur.net/94.html) des Gemeingütertages ohne Bedingungen beliebig genutzt, kopiert, verändert und veröffentlicht werden können.

4.7 Örtliche Relevanz und globale Perspektive
(z. B. Maßnahme in einem kommunalen, regionalen und globalen Gesamtkonzept)

Die Unterthemen des Gemeingütertages – nämlich Commons, Nachhaltigkeit und Klima – geben Hinweise auf die örtliche Relevanz und die globale Perspektive, die mit der GEMEINGÜTER-Initiaitve verfolgt werden. Im Einzelnen sind dies:

• Commons:
  Die Commons stellen gem. der Ubuntu-Philosophie fest: „Ich bin, weil wir sind.“ D.h. wir gehen aus Beziehungen hervor. Beziehungen kommen zwar vor allem örtlich zum tragen, sind aber die Basis menschlichen Zusammenlebens und können in ihrer Verflechtung in einer globalisierten Welt sogar um die Erde herum reichen (vgl. z.B. Gründe für fairen Handel, …). Wir wollen dafür sorgen, dass alle mitkommen und niemand ausgeschlossen wird.
• Nachhaltigkeit:
  Die Nachhaltigkeit fragt nach der Dauer der Beziehungen. Können Sie möglichst langfristig tragfähig sein? Ökologische Nachhaltigkeit wird in diesem Sinne auch als Verlängerung der Menschenrechte verstanden.
• Klima:
  Das Klima spricht die Dauerhaftigkeit von sozialer und ökologischer Nachhaltigkeit im Kontext einer der beiden speziesrelevanten Meschheitsfragen an: Der Klimazusammenbruch als Herausforderung der Menschenheit für einen zukunftsfähigen (zivilisatorisch bewohnbaren) Planeten.
  (Die andere speziesrelevante Menschheitsfrage sind Atomwaffen und Kernenergie.)

Bei der Betrachtung von Commons, Nachhaltigkeit und Klima wurden in der Gesamtschau der Aktiven des Gemeingütertages u.a. beinahe alle Globalen Nachhaltigkeitsziele berührt (vgl. 07. Anlage – Die SDGs im Überblick).

Die Erkenntnisse des Gemeingütertages sollen sich über die Zeit zu Konzepten für eine sozialökologische Stadtteilarbeit entwickelt werden. In diesem Zusammenhang lautet eine Frage: Wie können wir lokal so leben, dass es global verträglich ist?

4.8 Kontinuität
(z. B. verantwortliche Akteure arbeiten längerfristig an dem Projekt und stehen als Ansprechpartner zur
Verfügung, verlässliche Projekt- und Zeitplanung)

Der Gemeingütertag war eine Veranstaltung der GEMEINGÜTER-Initiative (https://tinyurl.com/GEMEINGUETER-Initiative) von Pauluskirche und Kultur. Mit Freude kann gesagt werden, dass die Pauluskirche – die Kulturkirche mit besonderem Gesicht – in Dortmund und der Region eine Institution ist. Die Pauluskirche stellt sich und ihre Arbeit seit 2002 hier näher dar: http://www.pauluskircheundkultur.net/kulturkirche.html

Seit dem Gemeingütertag hat die GEMEINGÜTER-Initiative folgende weitere Veranstaltungen durchgeführt und wird auch danach nicht müde die sozialökologischen Transformationen voranzubringen:

• 7. Juli: Mitgliedschaft der Ev. Lydia-Gemeinde bei der Genossenschaft BioBoden eG erworben; https://bioboden.de (s. 08. Anlage – Mitgliedschaft bei BioBoden eG am 07.07.2018 erworben (Foto))
  Mit diesem Schritt unterstützt die Gemeinde in einer Form solidarischer Ökonomie, dass Land aus der Logik als Ware für eine ökologische Landwirtschaft befreit wird.
• GEMEINGÜTER-Café: ein Wegpunkt der „Wege zur Nachhaltigkeit“ des Instituts für Kirche und Gesellschaft (befindet sich bis zum Kirchentag 2019 im Aufbau)
• 6.-9. September: Teilnahme an der Messe FAIR FRIENDS mit einem Gemeinschaftsstand ‚Gemeingütertag‘, an dem täglich wechselnde Organisationen teilgenommen haben (vgl. 09.1 Anlage – Messe FAIR FRIENDS 2018 – Gemeinschaftsstand Gemeingütertag – Standplan, s. 09.2 Anlage – Messe FAIR FRIENDS – Gemeinschaftsstand Gemeingütertag (Foto) und 09.3 Anlage – Messe FAIR FRIENDS – Gemeinschaftsstand Gemeingütertag (Foto))
• 9. September: Talk to heaven-Gottesdienst: „Ehrfurcht vor dem Leben – Albert Schweitzers Aufruf in einer bedrohten Welt“
• 11. September: Ein Königreich am Abgrund – Straßentheater beleuchtet Klimawandel: dramatische Folgen für die Gesundheit (in Zusammenarbeit mit der BUKO Pharma-Kampagne und der FH Dortmund)
• 14. September: Vortrag von Gerhard Breidenstein: „Spiritualität und nachhaltiger Lebensstil“
• ab 17. September: Teilnahme am Urban-Gardening-Netzwerk des Quartiersmanagements der Nordstadt
• 19. September: Unterstützung des Themenabends von RESQSHIP e.V. „Flüchtlinge retten – Ein Schiff fürs Mittelmeer“
• 20. September: Filmabend mit anschl. Diskussion „Das Schönauer Gefühl“ – Elektrizitätswerke Schönau – eine Stunde Spannung: Die mitreißende Geschichte der Stromrebellen aus dem Schwarzwald als Dokumentarfilm
• ab 1. Oktober: Beteiligung an „Nordstadt naturnah“ des Quartiersmanagements der Nordstadt
• 6. Oktober: Aufruf zur Demo Hambacher Wald – „Wald retten – Kohle stoppen“
• 11. Oktober: Vortrag von Eugen Drewermann: „Von Krieg zu Frieden“
• 26. November: Das Presbyterium der Ev. Lydia-Gemeinde Dortmund hat am 04.10.2018 einen Antrag zum Wechsel des Stromanbieters des Kirchenkreises von der Aktiengesellschaft Lichtblick SE zu den genossenschaftlichen Elektrizitätswerken Schönau (EWS) eG beschlossen. Dieser Antrag steht nun bei der Kreissynode des Ev. Kirchenkreises für Dortmund, Lünen und Selm am 26. November zur Abstimmung. (s. 10. Anlage – Antrag – Wechsel des Stromanbieters des Kirchenkreises von Lichtblick SE zu den Elektrizitätswerken Schönau (EWS) eG)
• 29. November: Vortrag von Marcel Hunecke: „Psychologie der Nachhaltigkeit“; die Veranstaltung beginnt mit einem Impuls von urgewald: „Schmutzige Geschäfte oder Faire Geldanlagen?“
• Derzeit läuft die Programmplanung für 2019.

Dokumente zum Herunterladen

Alle Dokumente rund um die Bewerbung und Verleihung des Agenda-Siegels 2018 an die GEMEINGÜTER-Initiative können hier heruntergeladen werden. Die Pressemitteilung der Stadt Dortmund vom 10.12.2018 gibt es direkt hier.

[1] Quelle: Workshop des Bildungswerks Berlin der Heinrich-Böll-Stiftung – Commoning: Wie offene Werkstätten gesellschaftliche Utopie erlebbar machen

Soweit im gesetzlichen Rahmen möglich verzichtet der Autor auf alle Urheber- und damit verwandten Rechte an diesem Werk.
Es kann beliebig genutzt, kopiert, verändert und veröffentlicht werden.
Für weitere Informationen zur Lizenz, siehe hier.

The post Gemeingütertag: Anerkennung und breiter Kontext für Freie Software appeared first on Do-FOSS.

Mit Version 16 springt openSUSE gewissermaßen in ein neues Zeitalter. Eine Weile war unklar, in welcher Form und auf welcher Basis openSUSE (überhaupt) weitergeführt wird. Letztlich haben sich die Entwickler zu einem pragmatischen Ansatz entschieden: Auch mit Version 16 bleibt openSUSE Leap eine »normale« Distribution mit Paket-Updates (kein Immutable System mit atomaren Updates) — so wie der große Enterprise-Bruder SLES 16. Für diesen Artikel habe ich einen ersten Blick auf die Distribution geworfen.

Installation

openSUSE verwendet das neue, HTML-basiertes Installationsprogramm agama, dessen Minimalismus Parallelen zu Fedora zeigt. Das Programm läuft unter Gnome im Webbrowser Firefox im Full-Screen-Modus. Es ist mir zwar gelungen, den Voll-Screen-Modus zu beenden, ich konnte aber keine anderen Programme starten, d.h. es liegt kein vollwertiges Live-System vor.

Tipp 1: Mit [Strg]+[+] bzw. [Strg]+[-] können Sie den Zoomfaktor verändern. Per Kontextmenüs können Sie Screenshots erstellen. Je nach (erkannter) Bildschirmauflösung wird das seitliche Menü nicht dauerhaft angezeigt, kann aber über den Menü-Button eingeblendet werden.

Tipp 2: Es ist möglich, das Installationsprogramm von einem externen Rechner aus zu bedienen. Dazu wechseln Sie mit Strg+Alt+F1 in eine Konsole. Dort wird die URL (https://agama.local) und das Passwort angezeigt. Jetzt können Sie im Webbrowser die URL oder IP-Adresse angeben, müssen die unsichere Verbindung (selbst signiertes Zertifikat) akzeptieren und sich einloggen. Eigentlich cool!

Im ersten Schritt stellen Sie rechts oben Sprache und Tastaturlayout für das Installationsprogramm ein und entscheiden Sie sich zwischen Leap 16 und Leap Micro 6.2. (Ich habe nur ersteres ausprobiert.)

Jetzt beginnt die eigentliche Installation. Wenn Sie einen statischen Hostnamen wünschen, geben Sie den gewünschten Namen an. Unter Lokalisierung stellen Sie nochmals (!) Sprache, Tastatur und Zeitzone ein — dieses Mal für das zu installierende System. Eleganter wäre, wenn der Installer die bereits durchgeführten Einstellungen einfach übernehmen würde, aber sei’s drum.

Im Punkt Netzwerk können Sie eine WLAN-Konfiguration durchnehmen. Ethernet-Verbindungen mit DHCP werden automatisch hergestellt.

Damit kommen wir zur Partitionierung und zum Einrichten der Dateisystemeim Punkt Speicherung. Der Installer schlägt vor, drei Partitionen einzurichten: /boot/efi, eine Swap-Partition und eine Systempartition mit btrfs-Dateisystem und neu Subvolumes (/boot, /var, /root, /home usw.). Optional können Sie das Setup auf LVM umstellen (was im Zusammenspiel mit btrfs aber selten große Vorteile mit sich bringt) und eine Verschlüsselung aktivieren. Für Installationen in eine virtuelle Maschine oder auf einen Rechner, wo Sie einfach die gesamte SSD nutzen möchten, ist das Layout OK.

Auf »echter« Hardware schlägt das Setup-Programm vor, alle vorhandenen Partitionen des Datenträgers zu löschen und dann openSUSE zu installieren. VORSICHT!! Das Setup-Programm bietet die Möglichkeit, auf die Partitionierung Einfluss zu nehmen, die Menüs sind aber nicht ganz leicht zu erkennen (siehe die folgenden fünf Screenshots).

Aufpassen müssen Sie auch beim Punkt Software: Standardmäßig wird nur eine Minimalinstallation ohne Desktop-System durchgeführt! Sie müssen die Auswahl ändern und haben dann die Wahl zwischen Gnome, KDE und XFCE.

Zuletzt richten Sie einen Benutzer ein, der automatisch sudo-Rechte erhält. Installieren startet nun die Installation.

Ich habe mehrere Installationen in VMs durchgeführt, eine »echte« auf meinen Mini-PC. Echte Fehler sind keine aufgetreten, aber intuitiv ist die Bedienung des neuen Installers wirklich nicht. Warum muss das Rad ununterbrochen neu erfunden werden, wenn soviele andere Linux-Probleme einer Lösung harren?

Software-Versionen und Paketverwaltung

Die Versionsnummern wichtiger Basispakete stimmen zum größten Teil mit jenen von Debian 13 überein.

Basis               Programmierung     Server
---------------     --------------     ---------------
Kernel     6.12     bash       5.2     Apache      2.4
glibc      2.40     gcc       15.1     CUPS        2.4
Wayland    1.24     git       2.51     MariaDB    11.8
GRUB       2.12     Java     17/21     OpenSSH    10.0
Mesa       24.3     PHP        8.4     PostgreSQL   17
Systemd     257     Podman     5.4     Postfix    3.10
NetworkMan 1.52     Python    3.13     qemu/KVM   10.0
Gnome        48                        Samba      4.22
KDE Plasma  6.4

Generell ist das Angebot in Leap 16 im Vergleich zu den Vorgängerversionen 15.n aber geschrumpft, worauf LinuxUser hinweist (32.400 Pakete im Vergleich zu 44.700). Für Desktop-Programme ist Flatpak die beste Alternative. Darüberhinaus wird sich weisen, wie groß das Angebot von Paketen sein wird, die in externen Repositories angeboten werden.

Für Multimedia-Pakete war in der Vergangenheit Packman zuständig. Es ist zu erwarten, dass es dort in Zukunft ein Leap-16-Repository geben wird. Aktuell ist das aber noch nicht der Fall.

Am Fundament der Paketverwaltung hat sich wenig geändert — dafür sind weiterhin rpm (Low-Level) und zypper (High-level) zuständig. Desktop-Programme können wahlweise mit Software (Gnome) oder Discover (KDE) installiert werden. Das allumfassende Paketverwaltungs-Modul innerhalb von YaST gibt es nicht mehr.

Standardmäßig sind nur die Repos repo-oss und repo-openh264 aktiv:

zypper repos

  Repository priorities are without effect. All enabled repositories share the same priority.

  # | Alias                       | Name                      | Enabled | GPG Check | Refresh
  --+-----------------------------+---------------------------+---------+-----------+--------
  1 | Leap                        | Leap 16.0                 | No      | ----      | ----
  2 | openSUSE:repo-non-oss       | repo-non-oss (16.0)       | No      | ----      | ----
  3 | openSUSE:repo-non-oss-debug | repo-non-oss-debug (16.0) | No      | ----      | ----
  4 | openSUSE:repo-openh264      | repo-openh264 (16.0)      | Yes     | (r ) Yes  | Yes
  5 | openSUSE:repo-oss           | repo-oss (16.0)           | Yes     | (r ) Yes  | Yes
  6 | openSUSE:repo-oss-debug     | repo-oss-debug (16.0)     | No      | ----      | ----
  7 | openSUSE:repo-oss-source    | repo-oss-source (16.0)    | No      | ----      | ----

Für Verwirrung — auch in Software und Discover — kann das inaktive Repo Leap 16.0 sorgen. Es bezieht sich aber nur auf das Installationsmedium und wird im weiteren Betrieb tatsächlich nicht mehr gebraucht.

Das non-oss-Repo enthält diverse proprietäre Programme:

zypper modifyrepo --enable openSUSE:repo-non-oss

AdobeICCProfiles
bladeRF-fpga-firmware
bladeRF-fx3-firmware
bpg-fonts
discord
iozone
iozone-doc
ivtv-firmware
john-wordlists
Leap-Addon-NonOss
Leap-Addon-NonOss-release
libunrar-devel
libunrar7_1_10
libunrar7_1_10-x86-64-v3
ncat
ndiff
netperf
nmap
non_oss
nping
opera
patterns-non_oss
patterns-non_oss_opt
perlref
Reaction
Reaction-data
steamcmd
stream
unrar
wine-mono
xv
xv-doc
zenmap

Erste Schritte unter KDE

Ich habe openSUSE sowohl mit Gnome als auch mit KDE installiert, aber die weiteren Tests dann in einem KDE-System durchgeführt. KDE verwendet sowohl in virtuellen Maschinen als auch auf echter Hardware X11. Das ist ein wenig enttäuschend, Fedora 42 läuft per default mit Wayland (Fedora 43 beta natürlich auch), und meine Erfahrungen damit waren ausgezeichnet.

Der Versuch, die Auflösung meines 4k-Monitors auf 1920×1080 zu reduzieren, scheiterte. Der Bildschirminhalt wird komplett falsch skaliert, oben und unter im Monitor bleibt ein schwarzer Streifen. Bei 2560×1600 kam gar kein Bild zustande. Diese Probleme hatte ich noch nie. Ich bin dann bei der 4k-Auflösung geblieben und habe die Skalierung verändert. Das funktioniert unter KDE glücklicherweise wunderbar.

Zur Paketverwaltung ist Discover vorgesehen. Prinzipiell funktioniert das Programm zufriedenstellend. Irritierend ist auch hier die (korrekt!) inaktive Paketquelle Leap 16.

Bei der Systemadministration sind Sie auf die Module der KDE-Systemeinstellungen angewiesen. YaST steht nicht mehr zur Verfügung.

Wie schon erwähnt, entscheidet sich der Installer, wenn Sie nicht andere Optionen einstellen, für ein btrfs-Dateisystem mit vielen Subvolumes aber ohne Komprimierung.

cat /etc/fstab 

UUID=c3b4e719-0afe-4ad0-aea0-ad6a8c5c81e1  /                       btrfs  defaults                      0  0
UUID=c3b4e719-0afe-4ad0-aea0-ad6a8c5c81e1  /var                    btrfs  subvol=/@/var                 0  0
UUID=c3b4e719-0afe-4ad0-aea0-ad6a8c5c81e1  /usr/local              btrfs  subvol=/@/usr/local           0  0
UUID=c3b4e719-0afe-4ad0-aea0-ad6a8c5c81e1  /srv                    btrfs  subvol=/@/srv                 0  0
UUID=c3b4e719-0afe-4ad0-aea0-ad6a8c5c81e1  /root                   btrfs  subvol=/@/root                0  0
UUID=c3b4e719-0afe-4ad0-aea0-ad6a8c5c81e1  /opt                    btrfs  subvol=/@/opt                 0  0
UUID=c3b4e719-0afe-4ad0-aea0-ad6a8c5c81e1  /home                   btrfs  subvol=/@/home                0  0
UUID=c3b4e719-0afe-4ad0-aea0-ad6a8c5c81e1  /boot/grub2/x86_64-efi  btrfs  subvol=/@/boot/grub2/x86_64-efi  0  0
UUID=c3b4e719-0afe-4ad0-aea0-ad6a8c5c81e1  /boot/grub2/i386-pc     btrfs  subvol=/@/boot/grub2/i386-pc  0  0
UUID=EC5D-8DB9                             /boot/efi               vfat   utf8                          0  2
UUID=c3b4e719-0afe-4ad0-aea0-ad6a8c5c81e1  /.snapshots             btrfs  subvol=/@/.snapshots          0  0

lsblk

nvme1n1     259:6    0   1.8T  0 disk 
├─nvme1n1p1 259:7    0 372.5G  0 part 
├─nvme1n1p2 259:8    0     1G  0 part /boot/efi
├─nvme1n1p3 259:9    0   400G  0 part 
├─nvme1n1p4 259:10   0   100G  0 part 
├─nvme1n1p5 259:11   0   200G  0 part 
├─nvme1n1p6 259:12   0 279.4G  0 part 
├─nvme1n1p7 259:13   0 244.1G  0 part 
└─nvme1n1p8 259:14   0   100G  0 part /var
                                      /usr/local
                                      /srv
                                      /root
                                      /opt
                                      /home
                                      /boot/grub2/i386-pc
                                      /boot/grub2/x86_64-efi
                                      /.snapshots
                                      /

Neuerungen

Hinter den Kulissen gibt es eine Menge Neuerungen im Vergleich zu Version 15.n (siehe die Release Notes). Ganz kurz die wichtigsten Details:

• Wie schon erwähnt: YaST gibt es nicht mehr. openSUSE empfiehlt, Cockpit zur Administration zu verwenden.

• Per Default kommt SELinux zum Einsatz, AppArmor ist immerhin noch als Option verfügbar.

• openSUSE 16 ist year-2038-safe.

• openSUSE 16 soll bis 2031 jährlich mit neuen Versionen gepflegt werden. (Das wäre dann Version 16.6.) openSUSE 17 soll dann 2032 erscheinen. Warten wir ab, ob es dabei bleibt.

• openSUSE 16 setzt bei x86-CPUs den V2-Level voraus. Konkret bedeutet das, dass die CPUs nicht älter als gut 15 Jahre sein dürfen (Details). 32-Bit-CPUs werden nicht mehr unterstützt.

• Auf Rechnern mit NVIDIA-GPU werden die entsprechenden Paketquellen automatisch aktiviert und die proprietären Treiber installiert. Solche Systeme sollte jetzt out-of-the-box funktionieren. (Habe ich aber nicht getestet, mein Testrechner hat eine AMD-CPU/GPU.)

• PulseAudio wurde durch PipeWire ersetzt.

• Per Default darf root sich nicht via SSH anmelden. Verwenden Sie einen Account mit sudo-Rechten, oder ändern Sie ggfs. /etc/ssh/sshd_config.

• libvirt + Docker: Wenn Sie Docker und libvirt (Qemu/KVM) einsetzen, funktioniert in den virtuellen Maschinen das Networking nicht mehr. Schuld ist Docker, das nicht in der Lage ist, sein Firewall-System auf nft umzustellen :-( Die Lösung ist gleich wie unter Fedora: Sie müssen das libvirt-Firewall-Backend zurück auf iptables setzen (Details).

• nmap: Das populäre nmap-Tool hat die Lizenz geändert. openSUSE enthält die letzte Version unter der alten Lizenz.

Migrationstool

Es gibt ein neues Migrationstool, mit dem Sie einerseits openSUSE 15.6 auf Version 16.0 upgraden und andererseits einen Wechsel zwischen verschiedenen SUSE-Varianten (Leap, Tumblewheed, Slowroll, Enterprise) durchführen können. Ich habe das Programm allerdings nicht ausprobiert.

SSH-Server und Firewall

Der SSH-Server wird standardmäßig installiert, läuft aber nicht. Abhilfe:

systemctl enable --now sshd

Als Firewall läuft standardmäßig das von Fedora und RHEL bekannte Programm firewalld. Standardmäßig sind nur die Ports für SSH und den DHCP-Client offen:

firewall-cmd --list-services

  dhcpv6-client ssh

Qemu/KVM-Zwischenablage

Wenn Sie openSUSE 16 in einer virtuellen Maschine mit Qemu ausführen, funktioniert die Zwischenablage nicht. Abhilfe: zypper install spice-vdagent, unter Gnome (Wayland!) zusätzlich zypper install wl-clipboard.

Fazit

In openSUSE 16 ist viel Zeit, Mühe und Liebe geflossen — und das Ergebnis kann sich wirklich sehen lassen. Die Frage ist allerdings, ob das reicht. Das Angebot am Distributionsmarkt ist überwältigend groß, und mir fällt es ehrlich schwer, eine klare Zielgruppe für openSUSE zu erkennen.

• Den Mainstream decken Debian, Fedora und Ubuntu ab. Meine Empfehlung an Linux-Desktop-Einsteiger geht ganz stark in diese Richtung.
• Server-seitig wieder Debian und Ubuntu plus RHEL und Klone.
• Wer gerne immer Up-to-date ist: Arch Linux (oder ein Derivat).
• CachyOS kitzelt maximale Performance aus dem Rechner, verbunden mit den Arch-Linux-Vorteilen und aktuell einem Hype-Faktor.
• Linux Mint vielleicht für Einsteiger. (Ich war allerdings nie ein riesiger Mint-Fan und sehe wenig Vorteile im Vergleich zu Debian/Fedora/Ubuntu.)
• Pop!_OS als Distribution für system76-Kunden. Und falls der COSMIC-Desktop je fertig + stabil wird, könnte die Distribution ein interessantes Angebot für technisch orientierte Anwender werden (Entwickler/Admins/Freaks).

Im Vergleich zu Debian/Fedora/Ubuntu ist in Leap 16 das Software-Angebot geringer. Die Aktualität vieler Pakete kann wiederum mit Fedora und Ubuntu nicht mithalten. Als ausgesprochen einsteigerfreundlich empfinde ich Leap auch nicht (schon gar nicht die Installation). YaST als Argument fällt weg. (Das Konfigurations-Tool wurde schon in den letzten Jahren nur noch sehr halbherzig gepflegt.) Der Dateisystem-Editor von openSUSE während der Installation war Weltklasse, aus meiner Sicht besser als bei allen anderen Distributionen. Er ist dem neuen Installationsprogramm zum Opfer gefallen.

Wer sollte sich also für openSUSE entscheiden, und warum? openSUSE 16 ist natürlich eine super Trainings-Umgebung für SLES 16. Aber ist das genug? Selbst innerhalb der SUSE-Welt empfand ich Tumblewheel (oder Slowroll) in den letzten Jahren deutlich spannender als Leap.

Quellen/Links

• https://get.opensuse.org
• https://news.opensuse.org/2025/10/01/next-chapter-opens-with-leap-release/
• https://github.com/agama-project/agama
• https://news.opensuse.org/2025/10/01/migrating-to-leap-16-with-opensuse-migration-tool
• https://doc.opensuse.org/release-notes/x86_64/openSUSE/Leap/16.0/html/release-notes-leap-160/
• https://doc.opensuse.org/release-notes/x86_64/openSUSE/Leap/16.0/html/release-notes-leap-160/index.html#id-networking
• https://doc.opensuse.org/release-notes/x86_64/openSUSE/Leap/16.0/html/release-notes-leap-160/index.html#v160-nmap-deprecation-notice
• https://github.com/openSUSE/opensuse-migration-tool
• https://en.opensuse.org/X86-64_microarchitecture_levels
• https://www.linux-community.de/ausgaben/linuxuser/2025/10/opensuse-leap-16-in-der-praxis/
• https://www.linux-community.de/ausgaben/linuxuser/2025/03/status-der-entwicklung-von-opensuse-leap-16-0/3/

Ein Browser muss heute weit mehr können, als nur Websites darzustellen. Bei allen Gemeinsamkeiten sind es vor allem die Unterschiede, wieso sich Nutzer für den einen oder den anderen Browser entscheiden. Dieser Artikel stellt zwölf einzigartige Firefox-Features vor, die es in dieser Form in keinem anderen Browser gibt.

Hinweis: Natürlich gibt es viele Nischen-Browser, die vielleicht ebenfalls das eine oder andere der hier genannten Features besitzen. Für diesen Artikel wurden die aktuell relevantesten Desktop-Browser angesehen. Das sind Firefox, Chrome, Edge, Brave, Vivaldi, Opera sowie Safari. Selbstverständlich gibt es auch in diesen Browsern Funktionen, die es in Firefox in der Form nicht gibt. Dieser Artikel behandelt besondere Funktionen von Firefox nach Ansicht des Verfassers.

1. Lokale Übersetzungsfunktion

Eine Übersetzungsfunktion gehört heute zum Standard-Repertoire der meisten Browser. Was Firefox von allen anderen unterscheidet, ist die Tatsache, dass der Mozilla-Browser keine eingegeben Texte an einen Cloud-Dienst wie den von Google oder Microsoft senden muss. Stattdessen geschieht die Übersetzung dank lokaler KI vollständig auf dem Gerät des Anwenders. Dies stellt einen erheblichen Privatsphäre-Gewinn für die Nutzer dar und macht die Übersetzungsfunktion auch in einem Umfeld nutzbar, in welchem mit sensiblen Inhalten gearbeitet wird.

In Zukunft wird die Übersetzungsfunktion noch für viele weitere Sprachen zur Verfügung stehen und auch hinsichtlich der Übersetzungsqualität sind weitere Verbesserungen zu erwarten. Neben der vollständigen Website-Übersetzung ist auch die Übersetzung nur von markiertem Text auf auf einer Website sowie die Übersetzung von beliebigem Text möglich, welches einfach in ein Textfeld eingegeben werden kann.

2. Erkennung von gefälschten Produktbewertungen

Einen wichtigen Anwendungsfall für einen Browser stellt Online-Shopping dar. Ein großes Problem beim Online-Shopping sind gefälschte Produktbewertungen, welche die Kunden zum Kauf minderwertiger Ware verführen sollen. Auch dieses Problem löst Mozilla mit Hilfe Künstlicher Intelligenz (KI). Hierfür setzt Mozilla auf seinen hauseigenen Dienst Fakespot. Im deutschsprachigen Raum wird bislang nur Amazon unterstützt, in den USA darüber hinaus auch noch Walmart und Best Buy. Neben einer Bewertung der Glaubwürdigkeit aller Rezensionen zeigt Firefox den tatsächlichen Bewertungsdurchschnitt nach Abzug aller mutmaßlichen Fake-Bewertungen sowie eine Zusammenfassung der wichtigsten Informationen aus den glaubwürdigen Bewertungen an.

3. Content-Empfehlungen auf Startseite

Für zwei weitere Funktionen setzt Mozilla ebenfalls auf einen hauseigenen Dienst: Pocket. Zum einen bietet Pocket Content-Empfehlungen auf der Standard-Startseite von Firefox, welche auch beim Öffnen eines neuen Tabs erscheint. Diese Empfehlungen sollen laut Mozilla „informieren, inspirieren, unterhalten und neue, einzigartige Perspektiven aufzeigen“. Die Artikel werden von menschlichen Pocket-Redakteuren „aus einer breiten und vielfältigen Palette von Publikationen ausgewählt, die sich durch sorgfältige, zuverlässige und vertrauenswürdige Berichterstattung auszeichnen“.

Damit unterscheidet sich Firefox von Edge und Brave, welche ebenfalls Artikel auf der Startseite anzeigen können, dabei aber als vollständig automatisierte News-Aggregatoren dienen. Brave zeigt dabei außerdem selbst in der deutschsprachigen Version lediglich englischsprachige Artikel an.

4. Später-Lesen-Dienst

Zum anderen dient Pocket als Später-Lesen-Dienst. Wird ein Artikel über eine Browser-Schaltfläche in die persönliche Pocket-Ablage gelegt, steht dieser auf allen Geräten mit Pocket-App oder über die Website zur Verfügung. In Pocket lassen sich die Artikel in einer speziellen Leseansicht ohne Werbung und andere störende Elemente anzeigen und einzelne Textstellen markieren, die App kann die Artikel auch vorlesen und für die Offline-Nutzung speichern.

5. Cookie-Banner-Blocker

Mittlerweile gibt es sie auf fast jeder Website: Cookie-Dialoge. Diese durch die Europäische Union erzwungene Maßnahme soll theoretisch die Datenschutz-Interessen der Nutzer wahren, führt in der Praxis aber vor allem zu Nutzer-Frust.

Firefox kann viele Cookie-Banner automatisch blockieren. Zwar gibt es für dieses Problem auch Lösungen in anderen Browsern wie Brave und Vivaldi, diese basieren aber lediglich auf Filterlisten für traditionelle Werbeblocker. Der Nachteil ist, dass diese die Dialoge selbst zwar blockieren, damit aber auch potenziell Website-Funktionalität beeinträchtigen. Mozillas Lösung hingegen sieht vor, nicht einfach nur stumpf die Dialoge zu blockieren, sondern im Namen des Nutzers eine Ablehnung durchzuführen. Zwar funktioniert diese Lösung auf weniger Websites, verursacht dafür aber auch weniger Probleme.

6. Einzigartiger Bild-im-Bild-Modus für Videos

Der sogenannte Bild-im-Bild-Modus erlaubt es, Videos von der Website loszulösen und über andere Tabs und sogar Anwendungen zu legen. Firefox war der erste Browser, der mit diesem Feature experimentierte, und während mittlerweile auch andere (aber nicht alle) Browser nachgezogen sind, bleibt Firefox allen anderen Browsern mit diesem Feature weit überlegen.

So ist Firefox der einzige Browser, der mehrere losgelöste Fenster gleichzeitig erlaubt. Außerdem bietet Firefox die Option an, automatisch den Bild-im-Bild-Modus bei Tabwechsel zu aktivieren und bei Rückkehr in den Original-Tab automatisch wieder zu beenden.

Auch der Video-Player des Bild-im-Bild-Modus bietet weit mehr Funktionen in Firefox als in jedem anderen Browser: Die Wiedergabe kann pausiert und wieder gestartet werden, man sieht den Wiedergabe-Fortschritt und kann an eine andere Stelle des Videos springen, ein Wechsel in den Vollbildmodus ist möglich, der Ton kann aus- und wieder eingeschaltet werden, die Lautstärke kann geändert werden und sogar Untertitel werden auf vielen unterstützten Plattformen direkt im Miniatur-Player angezeigt.

7. Die umfangreichste Leseansicht aller Browser

Firefox gehörte auch bei der Leseansicht zu den ersten Browsern. Heute bietet so ziemlich jeder Browser dieses Feature an. Worum geht es? Die Leseansicht bereitet Artikel im Web in einer Weise auf, dass sie besonders gut und störungsfrei gelesen werden können. Die Artikel folgen also einer festen Gestaltung, was Schriften, Größen, Abstände und Farben betrifft, irrelevante Elemente wie Werbung werden entfernt.

Dabei gibt es in den verschiedenen Browsern auch verschiedene Optionen der Anpassung. Firefox gehört zu den Browsern mit mehr Optionen zur Textanpassung und erlaubt als einziger Browser sogar eine komplett freie Farbgestaltung. Außerdem lassen sich die Texte sogar vorlesen – ein Feature, welches sonst nur in Edge gefunden werden konnte. Im Komplettpaket bietet Firefox damit den umfangreichsten Lesemodus aller Browser an.

8. PDF-Editor, der auch auf Barrierefreiheit achtet

PDF-Dateien betrachten kann jeder Browser, PDF-Dateien bearbeiten jedoch nur Firefox und Edge. Und während es in Edge zwar möglich ist, auf einer PDF-Datei zu schreiben und zu zeichnen, kann Firefox sogar Bilder einfügen. Aber nicht nur das: Firefox fragt bei eingefügten Bildern nach einem Alternativtext – dieser ist wichtig, damit die PDF-Datei zugänglich für Menschen mit Sehbehinderung bleibt. Per lokaler Künstlicher Intelligenz kann Firefox in Zukunft sogar selbständig Alternativtexte für eingefügte Bilder in PDF-Dateien erzeugen.

9. Tab-Umgebungen

Tab-Umgebungen sind ein Feature, welches standardmäßig nur in Vorabversionen von Firefox aktiviert ist, aber auch darüber hinaus aktiviert werden kann und ansonsten vor allem durch Erweiterungen wie Mozillas eigener Erweiterung Firefox Multi-Account Containers genutzt werden.

Bei den Tab-Umgebungen handelt sich um ein einzigartiges Privatsphäre-Feature von Firefox. Die Container stellen getrennte Umgebungen unter anderem für Cookies, Local Storage, IndexedDB, den HTTP- und den Bilder-Cache dar. Chronik, Lesezeichen, gespeicherte Passwörter sowie Formulardaten hingegen teilen sich alle Container. Somit handelt es sich um eine einfache Möglichkeit, bestimmte Daten voneinander zu trennen, ohne dafür komplett eigene Browser-Profile nutzen zu müssen.

Ein möglicher Anwendungsfall, der sich daraus ergibt, ist beispielsweise das Anmelden mit sowohl einer privaten als auch mit einer geschäftlichen E-Mail-Adresse beim selben Anbieter – gleichzeitig, ohne einen anderen Browser hinzuziehen oder ein privates Fenster dazu zweckentfremden zu müssen. Als weiteres Beispiel wäre denkbar, auf Facebook angemeldet zu sein, ohne dass Facebook den Benutzer über die Facebook-Buttons auf Webseiten tracken kann. Wenn es um Tracking geht, ist es natürlich auch bis zur Werbung nicht so weit und so ist ein weiteres denkbares Szenario, dass man Webseiten privat besuchen möchte, ohne entsprechende Werbeanzeigen zu sehen, wenn man Firefox für die Arbeit benutzt. Und wer das Mozilla VPN nutzt, kann darüber sogar theoretisch in jedem Tab über einen anderen Standort online sein.

10. Das mächtigste Erweiterungssystem aller Browser

Die Anpassung via Erweiterungen ist in jedem Browser möglich. Und während es mit der sogenannten WebExtension-Architektur eine große Schnittmenge zwischen allen Browsern gibt, was die Entwicklung browserübergreifend funktionierender Erweiterungen vereinfacht, gibt es doch Unterschiede. So unterstützt Firefox zusätzliche Schnittstellen, welche in Erweiterungen für Chromium-basierte Browser (Chrome, Edge, Brave, Vivaldi, Opera, …) nicht existieren, darunter eine API für Sidebars, welche es sonst nur noch für Opera gibt, oder eine Schnittstelle für die zuvor besprochenen Tab-Umgebungen, die es in keinem anderen Browser gibt.

Aber auch bei Schnittstellen, die für alle Browser zur Verfügung stehen, gibt es Unterschiede. So hat der Entwickler von uBlock Origin, der populärsten Werbeblocker-Erweiterung, bereits vor Jahren erklärt, wieso uBlock Origin in Firefox sehr viel besser als mit allen Chromium-basierten Browsern funktioniert.

Mit dem neuen Manifest v3 schränkt Google die Erweiterungs-Entwickler noch weiter ein. Um beim Beispiel von uBlock Origin zu bleiben, wird es davon in Zukunft nur noch eine stark eingeschränkte Version (uBlock Origin Lite) für Browser geben, welche ausschließlich das Manifest v3 unterstützen.

Zwar unterstützt auch Firefox das Manifest v3, Mozilla hat aber bewusst nicht jede Einschränkung übernommen. Und während Google ab dem kommenden Jahr die Ausführung von Manifest v2-Erweiterungen unterbinden wird, hat Mozilla eine langfristige Unterstützung des Manifest v2 zugesagt.

11. Im wahrsten Sinn unbegrenzte Anpassbarkeit

Grenzen setzt natürlich auch Mozilla mit dem Erweiterungssystem. Für erfahrene Nutzer bietet Mozilla aber die Werkzeuge, um wirklich jeden Aspekt des Browsers – sowohl visueller als auch funktioneller Natur – den eigenen Bedürfnissen anzupassen, wozu es in keinem anderen Browser auch nur ansatzweise etwas Vergleichbares gibt. So lässt sich die komplette Browseroberfläche via CSS umgestalten – als wäre es eine Website. Gleiches gilt für die Darstellung von Websites, deren Anpassung via CSS nur in Firefox ganz ohne Add-on möglich ist. Und durch Scripts lassen sich sogar Funktionen ergänzen oder gar bestehende Browser-Funktionen überschreiben.

Tipp: Im deutschsprachigen Forum von camp-firefox.de bieten wir einen eigenen Bereich, der sich nur um Anpassungen dieser Art dreht. Der Nutzer fragt und bekommt in den meisten Fällen eine fertige Lösung, die einfach nur noch übernommen werden muss.

12. Vielfalt bei den Chatbots

Von KI-basierten Chatbots kann man halten, was man will, ich bin selbst kein allzu großer Freund davon. Aber sie sind ein Thema im Jahr 2024. Und deswegen ist zum Abschluss noch einmal Künstliche Intelligenz das Thema. Mittlerweile findet man Chatbot-Integrationen in den allermeisten Browsern. Während man noch keinen Chatbot direkt in Chrome finden kann, bietet Google mit Gemini einen solchen an und hat entsprechende KI-Integrationen teilweise in seinen Services. Edge hat den Copilot integriert, Brave hat mit Leo seinen eigenen Chatbot, für Opera gilt Gleiches mit Aria, die zudem ChatGPT und ChatSonic als weitere Optionen anbieten. Auch von Apple wird über eine Integration für Safari im Herbst spekuliert. Nur Vivaldi hat sich bislang explizit dagegen positioniert.

Mozilla verfolgt einen etwas anderen Ansatz. Während alle anderen auf eigene Lösungen setzen, setzt Mozilla auf bestehende Lösungen und dabei auf Vielfalt. Aktuell kann der Nutzer in Vorab-Versionen von Firefox bereits aus fünf verschiedenen Chatbots wählen: Google Gemini, ChatGPT, Anthropic Claude, HuggingChat sowie Le Chat Mistral. Und noch mehr können in Zukunft folgen. Vor allem, da die Technologie und aktuellen Modelle noch nicht so weit sind, immer zuverlässige Informationen zu liefern, kann es aus Nutzersicht eine gute Idee sein, mehrere Anbieter zu befragen, statt sich auf einen zu verlassen.

Bonus: Firefox trägt zur Vielfalt bei den Browser-Engines bei

Was vielen nicht bewusst ist: Ob nun Google Chrome, Microsoft Edge, Brave, Vivaldi, Opera oder viele der kleineren Nischen-Browser: Alle diese Browser nutzen unter der Haube die Chromium-Plattform samt Blink-Engine. Und damit zahlt die Nutzung von jedem dieser Browser auf das Google-Monopol ein und ermöglicht es Google immer mehr, Standardisierungsprozesse zu umgehen und de facto alleine zu bestimmen, wie das Web funktioniert. Für die Vielfalt am Browsermarkt, aber auch die Wahrung der Nutzerinteressen ist es von elementarer Bedeutung, dass es noch Browserhersteller gibt, die sich nicht nur „ins gemachte Nest setzen“, sondern selbst die wertvolle Arbeit der Entwicklung einer Browser-Engine leisten – wie Mozilla mit seiner Gecko-Engine oder Apple mit der WebKit-Engine. Die Entwicklung einer Engine ist die mit Abstand härteste Aufgabe für einen Browserhersteller und der Grund, wieso sich Browserhersteller wie Brave, Vivaldi und Opera, aber selbst ein Milliardenkonzern wie Microsoft die Arbeit lieber sparen. Denn am Ende kostet das sehr viel Geld ohne direkt ersichtlichen Ertrag. Dabei darf die Bedeutung dieser wichtigen Arbeit nicht unterschätzt werden.

Abschluss

Dies war nur eine Auswahl meiner persönlichen Favoriten. Es gibt noch einiges mehr zu entdecken, was es in dieser Form entweder nur in Firefox oder zumindest nicht in jedem anderen Browser gibt. So gibt es beispielsweise zwar in jedem Browser eine Screenshot-Funktion inklusive Möglichkeit, die komplette Website, statt nur den sichtbaren Bereich abzubilden, aber nur Firefox, Edge und Vivaldi machen diese auch für einfache Endanwender leicht zugänglich, während die anderen Browser diese Funktion in den Entwicklerwerkzeugen verstecken. Firefox ist auch der einzige Browser, der einen eigenen Zertifikatsspeicher nutzt und dafür nicht ausschließlich auf den Zertifikatsspeicher des Betriebssystems vertraut, was Vorteile für die Sicherheit von Firefox sowie des Webs im Allgemeinen bringt.

Und jetzt ihr: Was ist euer absolutes Lieblings-Feature von Firefox? Gibt es vielleicht ein Feature, welches ihr in dieser Liste vermisst? Oder besitzt ein anderer Browser ein Feature, welches Firefox eurer Meinung nach unbedingt übernehmen sollte?

Der Beitrag 12 Features, die Firefox einzigartig machen erschien zuerst auf soeren-hentzschel.at.

In den letzten Tagen gab es eine katastrophale Berichterstattung anderer Websites über eine experimentelle Unterstützung von Privacy Preserving Attribution (PPA) in Firefox 128. Auffällig: Die Websites, die so negativ berichtet haben, sind zu einem großen Teil selbst die größten Profiteure vom Tracking ihrer eigenen Leser – etwas, was es mit PPA nicht geben würde. Dieser Artikel liefert die Fakten, welche andere Websites verschweigen, und erklärt, was es mit Privacy Preserving Attribution wirklich auf sich hat, wieso es hier nicht alleine um Mozilla geht, welche Rolle auch die anderen Browser sowie Let’s Encrypt-Betreiberin ISRG spielen und wieso PPA in Wahrheit gut für den Nutzer ist.

Die Sache mit der Werbung

Ohne Frage ist Werbung auf Websites ein kontroverses Thema. Ob man nun Werbung auf Websites akzeptieren kann oder jede Form von Werbung blockiert: Tatsache ist, dass ein großer Teil des Webs werbefinanziert ist und sich das nicht ändern wird, nur weil ein Teil der Nutzer einen Werbeblocker verwendet. Wie ich bereits in meinem Kommentar zu Werbeblockern vor neun Jahren formuliert hatte:

„Alles hat seinen Preis, auch das, was einen selbst nichts kostet. Ausgaben für Server, Redaktionsräume sowie Redakteure und ja, manche Webseite besitzt sogar tatsächlich die Dreistigkeit, auch etwas verdienen zu wollen. Mir persönlich kann auf jeden Fall kein Leser erzählen, dass er acht Stunden am Tag arbeitet, vielleicht sogar mehr, nur um der guten Sache wegen und kein Geld dafür von seinem Arbeitgeber sehen will. Ein Geschäftsmodell gibt Webseiten die Möglichkeit, den Lesern kostenlos Inhalte in einer Weise anbieten zu können, welche für die Content-Anbieter lukrativ ist. Die Alternative dazu ist es eben nicht, die Inhalte werbefrei anzubieten, die Alternative dazu ist es, die Inhalte gar nicht anzubieten. Denn wieso sollte jemand ein Geschäft, eine Online-Redaktion, irgendetwas aufbauen und ggf. sogar die Verantwortung für viele Menschen und deren Existenzen übernehmen, wenn überhaupt kein eigener Nutzen darin besteht? Das mag edel klingen, geht aber leider vollkommen an der Realität vorbei.“

An dieser Stelle soll keine Moraldebatte über Werbeblocker geführt werden. Wer Werbung blockieren will, soll Werbung blockieren. Das ist hier nicht das Thema. Aber jedem muss klar sein, dass nur weil man selbst Werbung blockiert, dies nichts daran ändert, dass werbefinanzierte Websites weiterhin über Werbung finanziert werden und nicht auf magische Weise plötzlich anders.

Wieso gibt es Tracking und was ist das Problem damit?

Das Schalten von Werbung kostet Geld. Und Werbung, die den potenziellen Käufer nicht interessiert, wird nicht zu einem Kaufabschluss, einer sogenannten „Conversion“, führen. Also versucht man, Werbung möglichst an diejenigen auszuspielen, die sich potenziell eher für das Produkt interessieren, als an der Zielgruppe vorbei. Das verspricht höhere Conversion-Raten und damit mehr Kaufabschlüsse bei gleichem Werbeeinsatz oder den gleichen Umsatz mit weniger Investition in Werbung. Damit das richtig funktioniert, muss der Erfolg der Werbung natürlich auch gemessen werden.

Was erst einmal gut klingt, hat aus Nutzersicht den großen Nachteil, dass diese Personalisierung üblicherweise über sogenanntes „Tracking“ erfolgt. Vereinfacht gesagt bedeutet das, dass Nutzer während des Surfens im Web „verfolgt“ werden, es entstehen „Nutzer-Profile“. Und diese sind teilweise sehr detailliert und können ein umfangreiches Bild vermitteln, welches teilweise so eindeutig ist, dass man leicht aus der Masse hervorsticht und über längere Zeiträume diesen eindeutigen Datensätzen zugeordnet werden kann. Aus Privatsphäre-Sicht des Nutzers ist dies sicher nicht erstrebenswert. Deswegen arbeiten Browserhersteller wie Mozilla seit Jahren daran, den Tracking-Schutz des Browsers immer weiter zu verbessern. Gerade Firefox liefert in sehr regelmäßigen Abständen immer weitere Privatsphäre-Verbesserungen.

Immer nur blockieren hat das Problem nicht gelöst

Nun könnte man auf die Idee kommen, dass wenn Tracking so schlecht ist, Browser doch einfach alle Tracking-Versuche blockieren könnten. Zu glauben, das sei bereits die ganze Antwort auf das Problem, wäre naiv.

Browser wie Firefox unternehmen bereits große Anstrengungen, Tracking zu blockieren. Je schwieriger das Tracking über konventionelle Wege gemacht wird, desto kreativer wird allerdings auch die Werbebranche. Vor Jahren wurde sogar schon damit begonnen, mit HSTS eine Sicherheits-Funktion für Tracking-Zwecke zu missbrauchen. Dass Nutzer Sicherheits-Funktionen abschalten, um die Privatsphäre zu gewährleisten, sollte definitiv nicht das Ziel sein.

Zu bedenken ist außerdem, dass es auch auf Kosten der Website-Kompatibilität geht, je mehr man blockiert. Nicht grundlos bietet Firefox einen Standard- sowie einen strengeren Tracking-Schutz an, der mehr blockiert, dafür aber auch einiges an Problemen auf Websites verursacht. Diesen standardmäßig für alle Nutzer zu aktivieren, wäre nach heutigem Stand nicht möglich, da Firefox-Nutzer so viele Probleme auf Websites hätten, für die aus Sicht vieler Nutzer natürlich Firefox Schuld wäre, dass sie vermutlich zu einem Browser wechseln würden, der diese Probleme nicht hat – vielleicht auch, weil dieser weniger gegen Tracking unternimmt als Firefox.

Um Tracking wirklich nachhaltig zu eliminieren, kann es nur einen Weg geben: Es muss eine Alternative angeboten werden, bei der jeder gewinnt: Nutzer und Werbetreibende. Werbetreibende müssen in der Lage sein, ihre Werbung zielgerichtet auszuspielen und den Erfolg messen zu können. Nutzer müssen sich sicher hinsichtlich ihrer Privatsphäre fühlen können. Nur wenn die Interessen beider Seiten gewahrt bleiben, gibt es eine realistische Chance, Tracking eines Tages tatsächlich zu eliminieren.

„Werbung ist blöd, ich würde auch für Content bezahlen“

Das ist natürlich eine vorbildliche Haltung. Generell sollten Content-Ersteller, deren Inhalte man regelmäßig konsumiert, unterstützt werden. Allerdings sind Menschen mit dieser Einstellung in einer klaren Minderheit. Bezahlmodelle funktionieren realistisch betrachtet nur für einen ganz kleinen Teil aller Websites. Im Allgemeinen ist die Zahlungsbereitschaft der Nutzer für Websites minimal bis nicht existent. In Zeiten, in denen ohnehin alles teurer wird, gilt dies eher mehr als weniger. Und angenommen, mehr Websites würden eine Bezahlung verlangen: Selbst zahlungsbereite Konsumenten dürften wohl eine Grenze haben.

Auch Mozilla hatte mit dem Projekt Firefox Better Web vor vier Jahren mit dem Konzept einer Bezahlversion des Webs experimentiert, welches gegen eine monatliche Zahlung Werbefreiheit auf den teilnehmenden Partnerseiten versprochen hat. Dieses Experiment wurde relativ schnell eingestellt. Und das ist nur ein Beispiel. Versuche, Alternativen zur Werbung zu etablieren, gab es auch von anderen immer wieder. Fakt ist: Bis heute hat sich kein Geschäftsmodell für das Web gefunden, welches eine echte Alternative darstellt. Sogenannte Paywalls oder Bezahlschranken funktionieren im Einzelfall, aber sind keine Lösung für das Web als Ganzes. Zumal es auch der Idee eines offenen Webs widerspricht, wenn der Zugang zu großen Teilen des Webs eben nicht mehr offen ist, sondern bezahlt werden muss. Und es gibt bereits eine erschreckende Tendenz in diese Richtung.

Worum geht es bei Privacy Preserving Attribution (PPA)?

Nun kommen wir endlich zur Privacy Preserving Attribution, PPA. Wie ich bereits im Artikel zu Firefox 128 und damit deutlich vor der aktuellen Debatte beschrieben habe, geht es darum, eine Alternative zu etablieren, welche Tracking überflüssig macht. Werbetreibende sollen relevante Daten erhalten, ohne dass dabei Daten über einzelne Personen gesammelt werden. Im Vergleich zum Tracking ist das aus Sicht des Nutzers ohne jeden Zweifel die bessere Option.

Konkret geht es hier um die Attribution, sprich eine Zuordnung, wie oft eine bestimmte Werbung gesehen wurde und zu einem Kaufabschluss geführt hat. Ohne eine solche Zuordnung wüssten Werbetreibende nicht, ob ihre Werbung funktioniert oder nicht. Diese Information ist aber von elementarer Bedeutung und Werbetreibende gehen jeden technisch möglichen Weg, diese Information zu erhalten. Deswegen ist die Idee, diese Information in einer Weise bereitzustellen, welche die Privatsphäre der Nutzer schützt, sodass hierfür kein Tracking mehr stattfinden muss, wie es bislang der Fall ist.

Der entscheidende Unterschied zwischen PPA und Tracking ist der, dass bei PPA der Browser die Kontrolle darüber hat, welche Informationen geteilt werden. Und wenn Werbetreibende auf diese Schnittstelle setzen, kann der Browser die Privatsphäre der Nutzer vollständig gewährleisten, was nicht möglich ist, wenn stattdessen auf Nutzer-Tracking gesetzt wird und die Browser-Maßnahmen gegen Tracking von Werbetreibenden bewusst umgangen werden.

Wie funktioniert PPA?

Die Funktionsweise von PPA ist, grob skizziert, dass der Browser Impressionen über eine Anzeige speichert, also wie oft diese angezeigt worden ist. Damit gespeichert werden auch weitere Informationen zur Anzeige, wie die Ziel-Website. Die Website gibt an, an welchen Anzeigen sie interessiert ist. Auf Grundlage dieser Angaben erstellt der Browser dann einen Bericht, gibt diesen aber nicht an die Website weiter. Stattdessen wird dieser verschlüsselt und anonym über das Distributed Aggregation Protocol (DAP) an einen Aggregationsdienst gesendet. Dieser Aggregationsdienst kombiniert diesen Bericht dann mit vielen weiteren Berichten. Darüber hinaus wird ein zusätzliches „Rauschen“ hinzugefügt, das für einen differentiellen Datenschutz sorgt.

Was kompliziert klingt, sorgt dafür, dass keine Browsing-Aktivitäten an irgendjemanden gesendet werden. Werbetreibende erhalten lediglich aggregierte Informationen zur Wirksamkeit ihrer Anzeigen.

Wer ist der Aggregationsdienst und was hat Let’s Encrypt damit zu tun?

Mozilla setzt als DAP-Partner auf die Internet Security Research Group, kurz: ISRG, welche als Aggregationsdienst für PPA dient. Wem die ISRG nichts sagt: Dahinter steckt niemand Geringeres als die Betreiberin von Let’s Encrypt. Also jene Organisation, der zig Millionen von Websites für ihre HTTPS-Zertifikate vertrauen, einschließlich dieses Blogs.

Wenn nun also PPA für ein so großes Vertrauensdefizit in Bezug auf Mozilla sorgt, wie es manche darstellen, dürfte für Let’s Encrypt als Produkt der ISRG nichts anderes gelten. Immerhin erhält diese die ganze Berichte vom Browser. Und wenn der ISRG und damit Let’s Encrypt nicht mehr vertraut wird, sollte man konsequenterweise vielleicht auch alle Websites meiden, welche ein Zertifikat von Let’s Encrypt verwenden. Alles andere wäre nicht konsequent.

Wieso PPA sogar eine realistische Chance haben könnte

Es gab schon viele Ansätze, das Problem von Werbung und Tracking zu lösen. Wieso sollte nun ausgerechnet PPA bessere Chancen haben? Die Antwort könnte in der Zusammenarbeit mit ausgerechnet einem der größten Werbeunternehmen der Welt liegen.

Wie bereits festgestellt, wird das Hinzufügen immer weiterer Anti-Tracking-Mechanismen nicht das grundsätzliche Problem lösen. Um dieses Problem zu lösen, ist es wichtig, genau zuzuhören, was die Anforderungen der Werbebranche sind, statt an deren Interessen vorbeizuarbeiten, damit die dann wieder die nächsten Schutzmaßnahmen umgehen.

Für die Entwicklung von PPA hat Mozilla mit Meta zusammengearbeitet, Betreiberin unter anderem von Facebook und Instagram und damit von zwei der weltweit größten Werbeplattformen, die sehr gerne ihre Nutzer tracken. Was auf den ersten Blick nach keinem guten Match klingt, ergibt viel Sinn: Denn wenn am Ende eine Lösung steht, mit der sogar Meta leben könnte, stehen die Chancen nicht schlecht, dass die Lösung auch für andere Werbedienstleister gut genug ist.

PPA betrifft nur Nutzer, die ohnehin Werbung sehen

Ein häufiges Argument in der ganzen Debatte ist, dass die Nutzer ja grundsätzlich gegen Werbung seien und sie deswegen auch gegen PPA sind. Was sie dabei übersehen: Da sie aus genau diesem Grund ja ohnehin einen Werbeblocker einsetzen, sehen sie auch keine Werbung und damit gibt es auch keine Attribution. Diese Nutzer betrifft es also überhaupt nicht. PPA betrifft aber alle Nutzer, die Werbung sehen – und verbessert deren Privatsphäre gegenüber Werbung, welche auf Tracking setzt. Daran gibt es nichts auszusetzen, wie man es auch dreht und wendet.

PPA verbessert die Privatsphäre – über Werbung hinaus

PPA kann aber auch die Privatsphäre über Anwendungsfälle der Werbung hinaus verbessern und betrifft damit dann doch wieder auch Nutzer, die keine Werbung sehen. Wie das?

Wie bereits besprochen, wird Tracking vor allem in Zusammenhang mit Werbung genutzt. Wenn sich nun eine datenschutzfreundliche Alternative zum Tracking etablieren würde und Werbetreibende hierfür nicht länger auf Tracking setzen würden, würde daraus auch folgen, dass die Browserhersteller daran arbeiten könnten, den Tracking-Schutz ihrer Browser schärfer zu stellen und noch mehr Tracking zu unterbinden. Denn während sich praktisch alle einig sind, dass Tracking schlecht für die Privatsphäre ist, ist das Interesse der Werbemessung ja durchaus legitim. Wenn dieser Anwendungsfall wegfällt, kann Tracking für andere Zwecke leichter identifiziert und blockiert werden und Schutzmaßnahmen, die jetzt vielleicht noch aus Webkompatibilitätsgründen nicht als Standard umgesetzt werden können, könnten es dann möglicherweise.

Wen betrifft das PPA-Experiment in Firefox 128 denn jetzt überhaupt?

Beim PPA-Experiment in Firefox 128 handelt es sich um eine sogenannte Origin Trial. Vor allem Nutzer von Google Chrome sollten das Konzept kennen, denn dort sind zahlreiche Origin Trials aktiv – denen der Nutzer übrigens auch nicht explizit zustimmt. Gleiches gilt für Microsoft Edge.

Doch was bedeutet das? Das bedeutet, dass die Schnittstelle nicht einfach so von jeder Website genutzt werden kann. Die Nutzung dieser Schnittstelle muss beim jeweiligen Browserhersteller beantragt werden.

Dies hängt damit zusammen, dass es in dieser Phase darum geht, überhaupt erst einmal festzustellen, ob PPA so funktioniert, wie man es sich erhofft, um mit diesen Erkenntnissen dann den entsprechenden Webstandard weiterzuentwickeln.

PPA ist nach aktuellem Stand nur für wenige Websites in den USA aktiv.

Muss PPA standardmäßig aktiviert sein?

Ein Kritikpunkt in der Debatte ist auch die standardmäßige Aktivierung von PPA. Ist das notwendig? Für mich ist das ein eindeutiges Ja. Ansonsten wäre die Antwort darauf, ob PPA eine Alternative zum Tracking werden kann, doch bereits vorweggenommen.

Tracking erfolgt nicht über eine Schnittstelle, die dediziert dafür da ist, die Nutzer zu verfolgen. Tracking erfolgt über ganz normale Webtechnologie, welche standardmäßig verfügbar ist. Müsste PPA, anders als so ziemlich jeder andere Webstandard, zunächst vom Benutzer aktiviert werden, könnte sich PPA auch nicht als Alternative zum Tracking etablieren, weil das Ergebnis dann zwansläufig deutlich unter dem wäre, was Tracking liefert. Außerdem verbessert eine standardmäßige Aktivierung von PPA auch deren Privatsphäre von dem Aspekt her, dass man keinen zusätzlichen Tracking-Vektor schafft, weil Nutzer mit aktiviertem PPA in einer Minderheit wären.

Als kurzzeitig angelegtes Experiment, welches nur auf wenigen Seiten aktiviert ist und wichtige Erkenntnisse zur weiteren Entwicklung des Standards liefern soll, wäre es außerdem nicht zielführend, wäre PPA nicht standardmäßig aktiviert. Denn um realistische Daten zu erhalten und damit eine Aussagekraft zu entwickeln, mit der man arbeiten kann, ist eine entsprechende Skalierung unabdingbar.

Und dennoch hat Mozilla seinen Nutzern in Firefox eine sichtbare Einstellung gegeben, um PPA zu deaktivieren. Etwas, was sie nicht hätten tun müssen, in Anbetracht dessen, dass auch die Webstandards, die für Tracking genutzt werden, nicht per Checkbox deaktivierbar sind.

Für Nutzer mit abgeschalteter Telemetrie ist PPA im Übrigen in jedem Fall auch inaktiv, unanbhängig von dieser Checkbox.

Alternative Ansätze nicht gut genug

Mozilla hat sich in den letzten Jahren auch ganz genau angesehen, wie alternative Vorschläge wie beispielsweise FLoC, die Topics API und Privacy Sandbox von Google funktionieren. Das Resultat war, dass diese Vorschläge die Privatsphäre nicht ausreichend schützen. Statt einfach nur zu kritisieren, hat Mozilla selbst aktiv daran gearbeitet, eine bessere Lösung zu finden. PPA ist das Ergebnis von Jahren der Recherche, Diskussion und Entwicklung, auch basierend auf Erfahrungen durch die Entwicklung von erfolgten Privatsphäre-Verbesserungen in Firefox und den Fehlern, die andere Vorschläge machten.

Angeblicher Zusammenhang mit Kauf eines „Werbeunternehmens“ ist gelogen, PPA bereits vor 2 1/2 Jahren angekündigt

Im Juni hatte Mozilla angekündigt, das Unternehmen Anonym gekauft zu haben. Anonym stellt Lösungen bereit, um den Erfolg digitaler Werbung in einer datenschutzfreundlichen Weise zu messen. Tatsächlich klingt das auf den ersten Blick sogar sehr zusammenhängend. Anonym stellt allerdings technische Lösungen auf Seiten der Werbedienstleister bereit. PPA geht das Thema von der Browserseite her an. Unbestritten ist, dass beide ein gemeinsames Ziel verfolgen.

Die Behauptung mancher Website, Anonym stecke hinter Mozillas Vorstoß mit PPA, ergibt überhaupt keinen Sinn. Denn Mozilla hat Privacy Preserving Attribution bereits im Februar 2022 angekündigt, also vor knapp 2 1/2 Jahren. Schon damals hatte Mozilla im Übrigen ausdrücklich um Feedback gebeten.

Eine solche Behauptung, die von Mozilla im Übrigen auch verneint wurde, kam beispielsweise von heise (keine Verlinkung, da Lügen nicht durch Backlinks belohnt werden sollten), wo man unverschämterweise sogar so weit ging, in den Raum zu werfen, Mozilla würde für die PPA-Integration – von wem auch immer – Geld erhalten. Selbstredend gab es weder für das eine noch das andere eine Quelle. Dies hat sich der Redakteur schlicht und ergreifend ausgedacht. Dies war auch nicht die einzige falsche Behauptung einer Seite, welche schon in der Vergangenheit immer wieder dadurch aufgefallen ist, dass gründliche Recherchen wohl eher nicht im Pflichtenheft der Redakteure stehen.

Kein Alleingang von Mozilla, W3C-Gruppe

PPA ist nichts, was Mozilla im Stillen für sich alleine entwickelt hätte. Bereits die Ankündigung im Februar 2022 verwies auf die Private Advertising Technology Community Group, eine Arbeitsgruppe innerhalb des World Wide Web Consortiums (W3C), wo sich Mozilla Feedback einholen konnte und kann. Deren Teilnehmerliste ist prominent bestückt, unter anderem mit anderen Browserherstellern wie Google, Microsoft, Apple und Samsung, aber auch mit Verlagen, Werbeunternehmen und anderen Tech-Unternehmen. Da sind wir nämlich wieder genau dort, wo wir bereits früher im Artikel waren: Eine nachhaltige Lösung muss alle beteiligten Parteien ins Boot holen.

Wenn PPA funktioniert, profitieren nicht nur Firefox-Nutzer davon

Mozillas Ziel war es immer, das Web als Plattform zu verbessern. Marktanteile von Firefox sind schön und natürlich auch wichtig, da ein hoher Marktanteil logischerweise auch die eigene Position verbessert, um Änderungen durchzusetzen. PPA ist aber ein Beispiel, bei dem es nicht nur um Firefox geht.

Innerhalb von Firefox kann Mozilla daran arbeiten, den Tracking-Schutz seines Browsers immer weiter zu verbessern. Davon profitieren dann natürlich ausschließlich Firefox-Nutzer. Wenn jedoch PPA in der Praxis tatsächlich funktioniert und Werbedienstleister nicht länger auf Tracking setzen müssten, kann es den Nutzern egal sein, welchen Browser sie nutzen, weil der Privatsphäre-Vorteil dann unabhängig vom Browser gegeben wäre.

Zu guter Letzt: Lest euch die Quellen immer selbst durch

Eine abschließende Bitte: Glaubt nicht alles, was irgendwelche Websites behaupten, egal wie groß deren Name ist. Stellt euch immer auch die Frage, was wohl die Motivation des jeweiligen Verfassers ist. Tatsache ist, dass ein großer Teil der Websites, die PPA in ein so schlechtes Licht rücken, eine auffällig hohe Anzahl an Tracking-Scripts laden, sprich selbst zu den größten Profiteuren Tracking-basierter Werbung zählen. PPA hingegen muss erst beweisen, dass es zu keiner Beeinträchtung der Einnnahmen-Situation für Verlage führen würde. Natürlich kann das auch nur Zufall sein und die Recherche zum Thema fand einfach nur auf unterirdisch schlechtem Niveau statt. So oder so gilt: Besser immer selbst die Quellen prüfen, egal bei welchem Thema.

Natürlich muss auch diesem Blog, der im Übrigen komplett werbefrei und zu 100 Prozent unabhängig (Spenden für eine Unterstützung unabhängiger und Fakten-basierter Berichterstattung gerne gesehen ) betrieben wird, nicht blind vertraut werden. Einige Quellen dieses Artikels sind bereits direkt in den Artikel eingearbeitet. Am Ende möchte ich noch auf ein paar weitere offizielle Veröffentlichungen zum Thema in englischer Sprache hinweisen, für alle, die noch tiefer in das Thema einsteigen wollen:

• support.mozilla.org: Privacy-Preserving Attribution
• Mozilla Explainers: Experiment: Privacy-Preserving Attribution Measurement API
• Outline of a private attribution measurement API
• Bobby Holley (CTO, Firefox) auf Reddit: A Word About Private Attribution in Firefox

Der Beitrag Wieso Privacy Preserving Attribution (PPA) gut für die Privatsphäre der Nutzer ist erschien zuerst auf soeren-hentzschel.at.

Aktuell komme ich mit den Blog-Artikeln zu neuen Linux-Distributionen kaum mehr hinterher. Ubuntu 25.10 ist gerade fertig geworden, und zur Abwechslung gibt es deutlich mehr technische Neuerungen/Änderungen (und auch mehr Bugs) als sonst. Ich konzentriere mich hier vor allem auf die neue SSD-Verschlüsselung mit Keys im TPM. Generell ist Ubuntu 25.10 als eine Art Preview für die nächste LTS-Version 26.04 zu sehen.

Neuerungen

Neben den üblichen Software-Updates, auf die ich diesmal nicht im Detail eingehe (topaktueller Kernel 6.17!) gibt es vier grundlegende Neuerungen:

• Gnome unterstützt nur noch Wayland als Grafiksystem. Diese Neuerung hat das Gnome-Projekt vorgegeben, und die Ubuntu-Entwickler mussten mitziehen. Ich kann nicht sagen, ob mit Überzeugung — immerhin ist das ja auch eine Vorentscheidung für Ubuntu 26.04. Die Alternative wäre gewesen, sowohl für dieses als auch für das kommende Release bei Gnome 48 zu bleiben. Persönlich läuft Gnome + Wayland für mich in allen erdenklichen echten und virtuellen Hardware-Umgebungen gut, d.h. ich trauere X nicht nach. (Über XWayland können natürlich weiterhin einzelne X-Programme ausgeführt werden — wichtig für Programme, die noch nicht auf Wayland-kompatible Bibliotheken portiert sind. Aber der Desktop als Ganzes und der Display Manager müssen jetzt Wayland verwenden.)

• initramfs-Dateien mit Dracut: Ubuntu verwendet zum Erzeugen der für den Boot-Prozess erforderlichen Initial-RAM-Filesystem (umgangssprachlich der initrd-Dateien) das von Red Hat etablierte Kommando dracut und weicht damit vom Debian-Fundament ab, das weiterhin mkinitramfs verwendet. Das bewährte Kommando update-initramfs bleibt erhalten, aber dieses Script ruft nun eben dracut auf. Die Änderung gilt aktuell nur für Ubuntu Desktop, während Ubuntu Server vorerst bei mkinitramfs bleibt (mehr Details).

• Rust Utilities: Nicht nur im Linux-Kernel wächst die Bedeutung der Programmiersprache Rust, auch immer mehr Standard-Utilities von Linux werden aktuell im Rahmen von uutils neu in Rust implementiert. Der entscheidende Vorteil von Rust ist eine bessere interne Speicherverwaltung, die weniger Sicherheitsprobleme verspricht (keine Buffer Overflows, keine Null Pointer). In Ubuntu 25.10 wurde sudo durch die Rust-Implementierung sudo-rs ersetzt. Analog kommen auch die Rust-Core-Utilities zum Einsatz (Paket rust-coreutils, siehe /usr/lib/cargo/bin/coreutils). Das betrifft viele oft benötigte Kommandos, z.B. cat, chmod, chown, cp, date, dd, echo, ln, mv, shaXXXsum etc. Ein Blick in /usr/bin zeigt eine Menge entsprechender Links. Sicherheitstechnisch ist die Umstellung erfreulich, aber die Neuimplementierung hat natürlich auch zu neuen Fehlern geführt. Schon während der Beta-Phase hat Phoronix über größere Probleme berichtet, und ganz ist der Ärger vermutlich noch nicht ausgestanden. Update 27.10.: Ein Fehler in date hat dazu geführt, dass automatische Updates nicht mehr funktionieren, siehe den Bugbericht im Launchpad. Dieser Fehler ist mittlerweile behoben.

• TPM-Unterstützung: Bei der Installation können Sie die Keys für die Dateisystemverschlüsselung nun im TPM speichern. Auf die Details gehe ich gleich ausführlich ein.

Flatpak-Probleme

Viel schlechte Presse haben sich die Ubuntu-Entwickler mit einem Flatpak-Bug eingehandelt. Aktuell gibt es ja zwei alternative Formate für (Desktop-)Pakete, Snap (Ubuntu) versus Flatpak (Red Hat und der Rest der Welt). Aufgrund einer AppArmor-Änderung funktionierten Flatpaks unter Ubuntu nicht mehr. Bugbericht, Behebung, fertig?

Und genau hier begann das eigentliche Fiasko. Der Bug-Bericht stammt nämlich vom 5. September. Dennoch wurde Ubuntu 23.10 fünf Wochen später mit eben diesem Bug freigegeben. Und das ist doch ein wenig peinlich, weil es den Eindruck vermitteln könnte, dass es Ubuntu nur wichtig ist, dass das eigene Paketformat funktioniert. (Und auch wenn Ubuntu ein großer Snap-Befürworter ist, gibt es eine Menge Ubuntu-Derivate, die auf Flatpaks setzen.)

Seit ein paar Tagen gibt es einen Fix, dieser wird aber noch nicht ausgeliefert. (Es kann sich nur noch um wenige Tage handeln.) Alternativ kann als Workaround das AppArmor-Profil für fusermount3 deaktiviert werden:

sudo ln -s /etc/apparmor.d/fusermount3 /etc/apparmor.d/disable/
sudo apparmor_parser -R /etc/apparmor.d/fusermount3

Natürlich ist die ganze Geschichte ein wenig der Sturm im Wasserglas, aber es ist/war definitiv ein vermeidbarer Sturm.

Dateisystem-Verschlüsselung mit Keys im TPM

Zuerst eine Einordnung des Themas: Wenn Sie eine Linux-Installation mit einem verschlüsselten Dateisystem einrichten, müssen Sie während des Boot-Vorgangs zwei Passwörter eingeben: Ganz zu Beginn das Disk-Verschlüsselungspasswort (oft ‚Pass Phrase‘ genannt), und später Ihr Login-Passwort. Die beiden Passwörter sind vollkommen getrennt voneinander, und sie sollten aus Sicherheitsgründen unterschiedlich sein. Elegant ist anders.

Wenn Sie dagegen unter macOS oder Windows das Dateisystem verschlüsseln (FileVault, Bitlocker), gibt es trotzdem nur ein Login-Passwort. Analog gilt das übrigens auch für alle Android- und Apple-Smartphones und -Tablets.

Warum reicht ein Passwort? Weil der Key zur Verschlüsselung des Dateisystems in der Hardware gespeichert wird und während des Boot-Vorgangs von dort ausgelesen wird. Auf x86-Rechnern ist dafür das Trusted Platform Module zuständig. Das TPM kann kryptografische Schlüssel speichern und nur bei Einhaltung bestimmter Boot-Regeln wieder auslesen. Bei aktuellen AMD-CPUs sind die TPM-Funktionen im CPU-Package integriert, bei Intel kümmert sich der Platform Controller Hub (PCH), also ein eigenes Chipset darum. In beiden Fällen ist das TPM sehr Hardware-nah implementiert.

Der Sicherheitsgewinn bei der Verwendung des TPMs ergibt sich daraus, dass das Auslesen des Verschlüsselungs-Keys nur gelingt, solange die Verbindung zwischen Disk und CPU/Chipset besteht (die Disk also nicht in einen anderen Rechner eingebaut wurde) UND eine ganz bestimmte Boot-Sequenz eingehalten wird. Wird die Disk ausgebaut, oder wird der Rechner von einem anderen Betriebssystem gebootet, scheitert das Auslesen des Keys. (Genaugenommen enthält das TPM nicht direkt den Key, sondern den Key zum Key. Deswegen ist es möglich, den Dateisystemverschlüsselungs-Key im Notfall auch durch die Eingabe eines eigenen Codes freizuschalten.)

Die Speicherung des Keys im TPM ermöglicht es also, das Dateisystem zu verschlüsseln, OHNE die Anwender ständig zur Eingabe von zwei Schlüssel zu zwingen. Die TPM-Bindung schützt vor allen Angriffen, bei denen die SSD oder Festplatte ausgebaut wird. Wenn der gesamte Rechner entwendet wird, schützt TPM immer noch vor Angriffen, die durch das Booten von einem fremden System (Linux auf einem USB-Stick) erfolgen. Allerdings kann der Dieb den Rechner ganz normal starten. Das Dateisystem wird dabei ohne Interaktion entschlüsselt, aber ein Zugriff ist mangels Login-Passwort unmöglich. Das System ist also in erster Linie so sicher wie das Login-Passwort. Weiterhin denkbar sind natürlich Angriffe auf die auf dem Rechner laufende Software (z.B. ein Windows/Samba/SSH-Server). Kurzum: TPM macht die Nutzung verschlüsselter Dateisysteme deutlich bequemer, aber (ein bisschen) weniger sicher.

Zum Schluss noch eine Einschränkung: Ich bin kein Kryptografie-Experte und habe die Zusammenhänge hier so gut zusammengefasst (und definitiv vereinfacht), wie ich sie verstehe. Weder kann ich im letzten Detail erklären, warum es bei Windows/Bitlocker unmöglich ist, den Key auch dann auszulesen, wenn der Rechner von einem Linux-System gebootet wird, noch kann ich einschätzen, ob die von Ubuntu durchgeführte Implementierung wirklich wasserdicht und fehlerfrei ist. Aktuell ist sowieso noch Vorsicht angebracht. Die Ubuntu-Entwickler bezeichnen Ihr System nicht umsonst noch als experimentell.

Ubuntu mit TPM-Verschlüsselung einrichten

Ubuntu bezeichnet die Speicherung des Verschlüsselungs-Keys als noch experimentelles Feature. Dementsprechend habe ich meine Tests in einer virtuellen Maschine, nicht auf physischer Hardware ausgeführt. Mein Host-System war Fedora mit QEMU/KVM und virt-manager. Beim Einrichten der virtuellen Maschine sollten Sie UEFI aktivieren. Außerdem müssen Sie unbedingt ein TPM-Device zur virtuellen Maschine hinzufügen.

Bei der Installation entscheiden Sie sich für die Hardware-gestützte Verschlüsselung.

Im nächsten Dialog können Sie den Entschlüsselung des Datenträgers von einem weiteren Passwort abhängig machen. (Der Key für die Verschlüsselung ist dann mit einem TPM-Key und mit Ihrer Passphrase abgesichert.) Sicherheitstechnisch ist das die optimale Variante, aber damit erfordert der Boot-Vorgang doch wieder zwei Passworteingaben. Da können Sie gleich bei der »normalen« Verschlüsselung bleiben, wo Sie das LUKS-Passwort zum Beginn des Boot-Prozesses eingeben. Ich habe mich bei meinen Tests auf jeden Fall gegen die zusätzliche Absicherung entschieden.

Die Zusammenfassung der Konfiguration macht schon klar, dass das Setup ziemlich komplex ist.

Der Key für die Verschlüsselung wird zufällig generiert. Der Installer zeigt einen Recovery-Key in Textform und als QR-Code an. Diesen Key müssen Sie unbedingt speichern! Er ist erforderlich, wenn Sie den Datenträger in einen anderen Rechner übersiedeln, aber unter Umständen auch nach größeren Ubuntu- oder BIOS/EFI-Updates. Wenn Sie den Recovery-Key dann nicht mehr haben, sind Ihre Daten verloren!

Nach dem Abschluss der Installation merken Sie beim nächsten Reboot nichts von der Verschlüsselung. Der Key zum Entschlüsseln der SSD/Festplatte wird vom TPM geladen und automatisch angewendet. Es bleibt nur der »gewöhnliche« Login.

Als nächstes habe ich mir natürlich das resultierende System näher angesehen. /etc/fstab ist sehr aufgeräumt:

cat /etc/fstab

  /run/mnt/ubuntu-boot/EFI/ubuntu /boot/grub none bind
  /swap.img none    swap    sw  0   0

Selbiges kann man von der Mount-Liste leider nicht behaupten. (Diverse Snap-Mounts habe ich weggelassen, außerdem habe ich diverse UUIDs durch xxx bzw. yyy ersetzt.)

findmnt  -t ext4,vfat

  TARGET                             SOURCE                                         FSTYPE
  /                                  /dev/mapper/ubuntu-data-xxx                    ext4
  ├─/run/mnt/ubuntu-boot             /dev/vda3                                      ext4
  ├─/run/mnt/ubuntu-seed             /dev/vda2                                      vfat
  ├─/run/mnt/data                    /dev/mapper/ubuntu-data-xxx                    ext4
  │ ├─/run/mnt/data/usr/lib/firmware /dev/mapper/ubuntu-data-xxx[/var/.../firmware] ext4
  │ └─/run/mnt/data/usr/lib/modules  /dev/mapper/ubuntu-data-xxx[/var/.../modules]  ext4
  ├─/run/mnt/ubuntu-save             /dev/mapper/ubuntu-save-yyy                    ext4
  ├─/usr/lib/firmware                /dev/mapper/ubuntu-data-xxx[/var/.../firmware] ext4
  ├─/var/lib/snapd/seed              /dev/vda2                                      vfat
  ├─/boot/grub                       /dev/vda3[/EFI/ubuntu]                         ext4
  ├─/usr/lib/modules                 /dev/mapper/ubuntu-data-xxx[/var/.../modules]  ext4
  └─/var/lib/snapd/save              /dev/mapper/ubuntu-save-yyy                    ext4

lsblk

  vda                     253:0    0    32G  0 disk
  ├─vda1                  253:1    0     1M  0 part
  ├─vda2                  253:2    0   4,9G  0 part  /var/lib/snapd/seed
  │                                                  /run/mnt/ubuntu-seed
  ├─vda3                  253:3    0   750M  0 part  /boot/grub
  │                                                  /run/mnt/ubuntu-boot
  ├─vda4                  253:4    0    32M  0 part
  │ └─ubuntu-save-yyy     252:1    0    25M  0 crypt /var/lib/snapd/save
  │                                                  /run/mnt/ubuntu-save
  └─vda5                  253:5    0  26,4G  0 part
    └─ubuntu-data-xxx     252:0    0  26,3G  0 crypt /run/mnt/data/usr/lib/modules
                                                     /usr/lib/modules
                                                     /run/mnt/data/usr/lib/firmware
                                                     /usr/lib/firmware
                                                     /
                                                     /run/mnt/data

Die Partition ubuntu-save (Mount-Punkt /run/mnt/ubuntu-save) enthält lediglich eine JSON-Datei sowie ein paar Key-Dateien (ASCII).

Ich bin ein großer Anhänger des KISS-Prinzips (Keep it Simple, Stupid!). Sollte bei diesem Setup etwas schief gehen, ist guter Rat teuer!

Mit virtuellen Maschinen kann man schön spielen — und das habe ich nun gemacht. Ich habe eine zweite, neue VM eingerichtet, die 1:1 der ersten entspricht. Diese VM habe ich mit dem virtuellen Datenträger der ersten VM verbunden und versucht zu booten. Erwartungsgemäß ist das gescheitert, weil ja der TPM-Speicher bei der zweiten VM keine Keys enthält. (Das Experiment entspricht also dem Ausbau der Disk aus Rechner A und den Einbau in Rechner B.)

Wichtig: Der Key ist ohne Bindestriche einzugeben. Die Eingabe erfolgt im Blindflug (ich weiß, Sicherheit), was bei 40 Ziffern aber sehr mühsam ist.

Immerhin hat der Boot-Vorgang anstandslos funktioniert — allerdings nur einmal. Beim nächsten Reboot muss der Recovery-Key neuerlich eingegeben werden. Ich habe keinen Weg gefunden, die Keys im TPM der zweiten virtuellen Maschine (Rechner B) zu verankern. Wenn sich wirklich die Notwendigkeit ergibt, die SSD in einen neuen Rechner zu migrieren, wäre das eine große Einschränkung.

Danach habe ich wieder VM 1 gebootet. Dort hat alles funktioniert wie bisher. VM 1 hat also nicht bemerkt, dass die Disk vorübergehend in einem anderen Rechner genutzt und auch verändert wurde. Ich bin mir nicht sicher, ob das wünschenswert ist.

Letztlich bleiben zwei Fragen offen:

• Wie sicher sind die Daten, wenn das Notebook in falsche Hände gerät?

• Wie sicher ist es, dass ich an meine eigenen Daten rankomme, wenn beim Setup etwas schief geht? Aus meiner persönlichen Sichtweise ist dieser zweiter Punkt der wichtigere. Die Vorstellung, dass nach einem Update der Boot-Prozess hängenbleibt und ich keinen Zugriff mehr auf meine eigenen Daten habe, auch keinen Plan B zur manuellen Rettung, ist alptraumhaft. Es ist diese Befürchtung, weswegen ich das System gegenwärtig nie in einem produktivem Setup verwende würde.

Einfacher ist oft besser, und einfacher ist aktuell die »normale« LUKS-Verschlüsselung, auch wenn diese mit einer wenig eleganten Passwort-Eingabe bei jedem Boot-Prozess verbunden ist. Da weiß ich immerhin, wie ich zur Not auch aus einem Live-System heraus meine Daten lesen kann.

Fazit

Ubuntu 25.10 ist aus meiner Sicht ein mutiges, innovatives Release. Ich kann die Kritik daran nur teilweise nachvollziehen. Die Nicht-LTS-Releases haben nun einmal einen gewissen Test-Charakter und sind insofern mit Fedora-Releases zu vergleichen, die auch gelegentlich etwas experimentell sind.

Das interessanteste neue Feature ist aus meiner Sicht definitiv die Speicherung der Crypto-Keys im TPM. Leider bin technisch nicht in der Lage, die Qualität/Sicherheit zu beurteilen. Noch hat das Feature einen experimentellen Status, aber falls TPM-Keys in Ubuntu 26.04 zu einem regulären Feature werden, würde es sich lohnen, das Ganze gründlich zu testen. Allerdings haben sich diese Mühe bisher wohl nur wenige Leute gemacht, was schade ist.

Generell hätte ich beim TPM-Keys-Feature mehr Vertrauen, wenn sich Ubuntu mit Red Hat, Debian etc. auf eine distributionsübergreifende Lösung einigen könnte.

Post Scriptum am 5.11.2025

Ich habe in den letzten Monaten aktuelle Versionen von CachyOS, Debian, Fedora, openSUSE und Ubuntu getestet. Immer wieder taucht die Frage auf, welche Distribution ich Einsteiger(inne)n empfehle. Ubuntu ist schon lange nicht mehr meine persönliche Lieblingsinstallation. Von den genannten fünf Distributionen hat Ubuntu aber definitiv das beste und einfachste Installationsprogramm. Und für den Start mit Linux ist das durchaus entscheidend …

Quellen/Links

• https://canonical.com/blog/canonical-releases-ubuntu-25-10-questing-quokka
• https://discourse.ubuntu.com/t/questing-quokka-release-notes/59220
• https://discourse.ubuntu.com/t/spec-switch-to-dracut/54776
• https://uutils.github.io/ (Rust Utilities)
• https://github.com/trifectatechfoundation/sudo-rs
• https://www.phoronix.com/news/Ubuntu-25.10-Coreutils-Makeself
• https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bug/2127970
• https://bugs.launchpad.net/ubuntu/+source/flatpak/+bug/2122161
• https://www.phoronix.com/news/Ubuntu-25.10-Broken-Flatpaks
• https://www.omgubuntu.co.uk/2025/10/flatpak-broken-ubuntu-25-10-apparmor-bug

TPM

• https://de.wikipedia.org/wiki/Trusted_Platform_Module
• https://learn.microsoft.com/en-us/windows/security/hardware-security/tpm/switch-pcr-banks-on-tpm-2-0-devices
• https://canonical-ubuntu-desktop-documentation.readthedocs-hosted.com/en/latest/explanation/hardware-backed-disk-encryption
• https://en.ubunlog.com/Ubuntu-is-betting-on-encryption-with-TPM-2–which-is-controversial-but-not-at-all-like-Windows-0./
• https://linuxsecurity.com/news/vendors-products/ubuntu-25-10-tpm-encryption

Testberichte

• https://www.omgubuntu.co.uk/2025/10/ubuntu-25-10-new-features
• https://www.omgubuntu.co.uk/2025/10/flatpak-broken-ubuntu-25-10-apparmor-bug
• https://www.derstandard.at/story/3000000290393
• https://heise.de/-10722802

Dies ist mein Erfahrungsbericht zu den ersten Schritten mit InstructLab. Ich gehe darauf ein, warum ich mich über die Existenz dieses Open Source-Projekts freue, was ich damit mache und was ich mir von Large Language Models (kurz: LLMs, zu Deutsch: große Sprachmodelle) erhoffe. Der Text enthält Links zu tiefergehenden Informationen, die euch mit Hintergrundwissen versorgen und einen Einstieg in das Thema ermöglichen.

Dieser Text ist keine Schritt-für-Schritt-Anleitung für:

• die Installation von InstructLab CLI,
• die Installation und das Training von LLMs

Terminologie und Abkürzungen in diesem Text

Die Begriffe Künstliche Intelligenz (KI) oder englisch artificial intelligence (AI) werden in diesem Text synonym verwendet und zumeist einheitlich durch KI abgekürzt.

Beim Bezug auf große Sprachmodelle bediene ich mich der englischen Abkürzung LLM oder bezeichne diese als KI-ChatBot bzw. nur ChatBot.

Was ist InstructLab?

InstructLab ist ein von IBM und Red Hat ins Leben gerufenes Open Source-Projekt, mit dem die Gemeinschaft zur Verbesserung von LLMs beitragen kann. Jeder

• mit einem Linux-Notebook oder
• MacBook und
• der Fähigkeit Anleitungen zu folgen und
• wer YAML-Dateien schreiben kann,

der kann nun teilhaben und ausgewählte LLMs lokal auf seinem Endgerät ausführen, testen und verbessern. Für eine ausführliche Beschreibung siehe:

• Was ist InstructLab?
• InstructLab: Advancing generative AI through open source
• Welcome to the InstructLab Project

Informationen zu Open Source LLMs und Basismodellen für InstructLab bieten diese Links:

• Open Source Large Language Models selbst betreiben. Thorsten Honroth, Dr. Julien Siebert und Patricia Kelbert. Blog des Frauenhofer-Institut für Experimentelles Software Engineering. 2024-01-19.
• Open source large language models: Benefits, risks and types. IBM Data and AI Team. IBM Blog. 2023-09-27.
• Open sourcing IBM’s Granite code models. Mike Murphy. IBM Research Blog. 2024-05-06.
• InstructLab-kompatible Basismodelle. IBM watsonx Docs.
• Hugging Face. The AI community building the future. The platform where the machine learning community collaborates on models, datasets, and applications. URL: https://huggingface.co/

Meine Einstellung gegenüber KI-ChatBots

Gegenüber KI-Produkten im Allgemeinen und KI-ChatBots im Speziellen bin ich stets kritisch, was nicht bedeutet, dass ich diese Technologien und auf ihnen basierende Produkte und Services ablehne. Ich versuche mir lediglich eine gesunde Skepsis zu bewahren.

Was Spielereien mit ChatBots betrifft, bin ich sicherlich spät dran. Ich habe schlicht keine Lust, mich irgendwo zu registrieren und unnötig Informationen über mich preiszugeben, nur um anschließend mit einer Büchse chatten und ihr Fragen stellen zu können, um den Wahrheitsgehalt der Antworten anschließend noch verifizieren zu müssen.

Mittlerweile gibt es LLMs, welche ohne spezielle Hardware auch lokal ausgeführt werden können. Diese sprechen meine Neugier und meinen Spieltrieb schon eher an, weswegen ich mich nun doch mit einem ChatBot unterhalten möchte.

Mein InstructLab-Setup

Für meine ersten Versuche nutze ich mein Lenovo ThinkPad T14s (AMD) in der Ausstattung von 2021. Aktuell installiert ist Fedora 40 Workstation, welches zu den getesteten Betriebssystemen von InstructLab zählt.

Die Einrichtung des InstructLab-CLI und der erste Chat

Für die Einrichtung halte ich mich an den Getting Started Guide. Es sind folgende Befehle auszuführen, bis das erste LLM gestartet werden kann:

sudo dnf install gcc-c++ gcc make pip python3 python3-devel python3-GitPython
mkdir instructlab
cd instructlab
python3 -m venv --upgrade-deps venv
source venv/bin/activate
pip cache remove llama_cpp_python
pip install git+https://github.com/instructlab/instructlab.git@stable --extra-index-url=https://download.pytorch.org/whl/cpu
eval "$(_ILAB_COMPLETE=bash_source ilab)"
ilab init
ilab download
ilab serve

Der lokale LLM-Server wird mit dem Befehl ilab serve gestartet. Mit dem Befehl ilab chat wird die Unterhaltung mit dem Modell eingeleitet.

Im folgenden Video sende ich zwei Anweisungen an das LLM merlinite-7b-lab-Q4_K_M. Den Chatverlauf seht ihr in der rechten Bildhälfte. In der linken Bildhälfte seht ihr die Ressourcenauslastung meines Laptops.

Wie ihr seht, sind die Antwortzeiten des LLM auf meinem Laptop nicht gerade schnell, aber auch nicht so langsam, dass ich währenddessen einschlafe oder das Interesse an der Antwort verliere. An der CPU-Auslastung im Cockpit auf der linken Seite lässt sich erkennen, dass das LLM durchaus Leistung abruft und die CPU fordert.

Exkurs: Die Studie Energieverbrauch Index-basierter und KI-basierter Websuchmaschinen gibt einen interessanten Einblick in den Ressourcenverbrauch. Leider war ich nicht in der Lage, diese Studie als PDF aufzutreiben.

Mit den Antworten des LLM bin ich zufrieden. Sie decken sich mit meiner Erinnerung und ein kurzer Blick auf die Seite https://www.json.org/json-de.html bestätigt, dass die Aussagen des LLM korrekt sind.

Anmerkung: Der direkte Aufruf der Seite https://json.org, der mich mittels Redirect zu obiger URL führte, hat sicher deutlich weniger Energie verbraucht als das LLM oder eine Suchanfrage in irgendeiner Suchmaschine. Ich merke dies nur an, da ich den Eindruck habe, dass es aus der Mode zu geraten scheint, URLs einfach direkt in die Adresszeile eines Webbrowsers einzugeben, statt den Seitennamen in eine Suchmaske zu tippen.

Ich halte an dieser Stelle fest, der erste kleine Test wird zufriedenstellend absolviert.

KI-Halluzinationen

Da ich einige Zeit im Hochschulrechenzentrum der Universität Bielefeld gearbeitet habe, interessiert mich, was das LLM über meine ehemalige Dienststelle weiß. Im nächsten Video frage ich, wer der Kanzler der Universität Bielefeld ist.

Da ich bis März 2023 selbst an der Universität Bielefeld beschäftigt war, kann ich mit hinreichender Sicherheit sagen, dass diese Antwort falsch ist und das Amt des Kanzlers nicht von Prof. Dr. Karin Vollmerd bekleidet wird. Im Personen- und Einrichtungsverzeichnis (PEVZ) findet sich für Prof. Dr. Vollmerd keinerlei Eintrag. Für den aktuellen Kanzler Dr. Stephan Becker hingegen schon.

Da eine kurze Recherche in der Suchmaschine meines geringsten Misstrauens keine Treffer zu Frau Vollmerd brachte, bezweifle ich, dass diese Person überhaupt existiert. Es kann allerdings auch in meinen unzureichenden Fähigkeiten der Internetsuche begründet liegen.

Bei der vorliegenden Antwort handelt es sich um eine Halluzination der Künstlichen Intelligenz.

Im Bereich der Künstlichen Intelligenz (KI) ist eine Halluzination (alternativ auch Konfabulation genannt) ein überzeugend formuliertes Resultat einer KI, das nicht durch Trainingsdaten gerechtfertigt zu sein scheint und objektiv falsch sein kann.

Solche Phänomene werden in Analogie zum Phänomen der Halluzination in der menschlichen Psychologie als von Chatbots erzeugte KI-Halluzinationen bezeichnet. Ein wichtiger Unterschied ist, dass menschliche Halluzinationen meist auf falschen Wahrnehmungen der menschlichen Sinne beruhen, während eine KI-Halluzination ungerechtfertigte Resultate als Text oder Bild erzeugt. Prabhakar Raghavan, Leiter von Google Search, beschrieb Halluzinationen von Chatbots als überzeugend formulierte, aber weitgehend erfundene Resultate.

Quelle: https://de.wikipedia.org/wiki/Halluzination_(K%C3%BCnstliche_Intelligenz)

Oder wie ich es umschreiben möchte: „Der KI-ChatBot demonstriert sichereres Auftreten bei völliger Ahnungslosigkeit.“

Wenn ihr selbst schon mit ChatBots experimentiert habt, werdet ihr sicher selbst schon auf Halluzinationen gestoßen sein. Wenn ihr mögt, teilt doch eure Erfahrungen, besonders jene, die euch fast aufs Glatteis geführt haben, in den Kommentaren mit uns.

Welche Auswirkungen überzeugend vorgetragene Falschmeldungen auf Nutzer haben, welche nicht über das Wissen verfügen, diese Halluzinationen sofort als solche zu entlarven, möchte ich für den Moment eurer Fantasie überlassen.

Ich denke an Fahrplanauskünfte, medizinische Diagnosen, Rezepturen, Risikoeinschätzungen, etc. und bin plötzlich doch ganz froh, dass sich die EU-Staaten auf ein erstes KI-Gesetz einigen konnten, um KI zu regulieren. Es wird sicher nicht das letzte sein.

Um das Beispiel noch etwas auszuführen, frage ich das LLM erneut nach dem Kanzler der Universität und weise es auf seine Falschaussagen hin. Der Chatverlauf ist in diesem Video zu sehen:

Die Antworten des LLM enthalten folgende Fehler:

• Professor Dr. Ulrich Heidt ist nicht der Kanzler der Universität Bielefeld
• Die URL ‚https://www.uni-bielefeld.de/english/staff/‘ existiert nicht
• Die URL ‚http://www.universitaet-bielefeld.de/en/‘ existiert ebenfalls nicht
• Die Universität hieß niemals „Technische Universitaet Braunschweig“
• Sie wurde 2009 auch nicht umbenannt
• Es gibt nicht 8, sondern 14 Fakultäten

Der Chatverlauf erweckt den Eindruck, dass der ChatBot sich zu rechtfertigen versucht und nach Erklärungen und Ausflüchten sucht. Hier wird nach meinem Eindruck menschliches Verhalten nachgeahmt. Dabei sollten wir Dinge nicht vermenschlichen. Denn unser Chatpartner ist kein Mensch. Er ist eine leblose Blechbüchse. Das LLM belügt uns auch nicht in böser Absicht, es ist schlicht nicht in der Lage, uns eine korrekte Antwort zu liefern, da ihm dazu das nötige Wissen bzw. der notwendige Datensatz fehlt. Daher versuche ich im nächsten Schritt, dem LLM mit InstructLab das notwendige Wissen zu vermitteln.

Wissen und Fähigkeiten hinzufügen und das Modell anlernen

Das README.md im Repository instructlab/taxonomy enthält die Beschreibung, wie man dem LLM Wissen (englisch: knowledge) hinzufügt. Weitere Hinweise finden sich in folgenden Dateien:

• https://github.com/instructlab/taxonomy/blob/main/README.md#getting-started-with-knowledge-contributions
• https://github.com/instructlab/taxonomy/blob/main/docs/knowledge-contribution-guide.md
• https://github.com/instructlab/instructlab/blob/main/README.md#-creating-new-knowledge-or-skills-and-training-the-model

Diese Dateien befinden sich auch in dem lokalen Repository unterhalb von ~/instructlab/taxonomy/. Ich hangel mich an den Leitfäden entlang, um zu sehen, wie weit ich damit komme.

Wissen erschaffen

Die Überschrift ist natürlich maßlos übertrieben. Ich stelle lediglich existierende Informationen in erwarteten Dateiformaten bereit, um das LLM damit trainieren zu können.

Da aktuell nur Wissensbeiträge von Wikipedia-Artikeln akzeptiert werden, gehe ich wie folgt vor:

1. Erstelle das Repository https://github.com/Tronde/instructlab_knowledge_contributions_unibi mit einer README.md, ohne .gitignore und LICENCE
2. Konvertiere den Wikipedia-Artikel Bielefeld University ohne Bilder und Tabellen in eine Markdown-Datei und füge sie dem in Schritt 1 erstellten Repository unter dem Namen unibi.md hinzu
3. Füge dem lokalen Taxonomy-Repository neue Verzeichnisse hinzu: mkdir -p university/germany/bielefeld_university
4. Erstelle in dem neuen Verzeichnis eine qna.yaml und eine attribution.txt Datei
5. Führe ilab diff aus, um die Daten zu validieren

Der folgende Code-Block zeigt den Inhalt der Dateien qna.yaml und eine attribution.txt sowie die Ausgabe des Kommandos ilab diff:

(venv) [tronde@t14s instructlab]$ cat /home/tronde/src/instructlab/taxonomy/knowledge/university/germany/bielefeld_university/qna.yaml
version: 2
task_description: 'Teach the model the who facts about Bielefeld University'
created_by: tronde
domain: university
seed_examples:
 - question: Who is the chancellor of Bielefeld Universtiy?
   answer: Dr. Stephan Becker is the chancellor of the Bielefeld University.
 - question: When was the University founded?
   answer: |
     The Bielefeld Universtiy was founded in 1969.
 - question: How many students study at Bielefeld University?
   answer: |
     In 2017 there were 24,255 students encrolled at Bielefeld Universtity?
 - question: Do you know something about the Administrative staff?
   answer: |
     Yes, in 2017 the number for Administrative saff was published as 1,100.
 - question: What is the number for Academic staff?
   answer: |
     In 2017 the number for Academic staff was 1,387.
document:
 repo: https://github.com/Tronde/instructlab_knowledge_contributions_unibi.git
 commit: c2d9117
 patterns:
  - unibi.md
(venv) [tronde@t14s instructlab]$ 
(venv) [tronde@t14s instructlab]$ 
(venv) [tronde@t14s instructlab]$ cat /home/tronde/src/instructlab/taxonomy/knowledge/university/germany/bielefeld_university/attribution.txt 
Title of work: Bielefeld University
Link to work: https://en.wikipedia.org/wiki/Bielefeld_University
License of the work: CC-BY-SA-4.0
Creator names: Wikipedia Authors
(venv) [tronde@t14s instructlab]$ 
(venv) [tronde@t14s instructlab]$ 
(venv) [tronde@t14s instructlab]$ ilab diff
knowledge/university/germany/bielefeld_university/qna.yaml
Taxonomy in /taxonomy/ is valid :)
(venv) [tronde@t14s instructlab]$

Synthetische Daten generieren

Aus der im vorherigen Abschnitt erstellten Taxonomie generiere ich im nächsten Schritt synthetische Daten, welche in einem folgenden Schritt für das Training des LLM genutzt werden.

Dazu wird der Befehl ilab generate aufgerufen, während sich das LLM noch in Ausführung befindet. Dieser endet bei mir erfolgreich mit folgendem Ergebnis:

(venv) [tronde@t14s instructlab]$ ilab generate
[…]
INFO 2024-05-28 12:46:34,249 generate_data.py:565 101 instructions generated, 62 discarded due to format (see generated/discarded_merlinite-7b-lab-Q4_K_M_2024-05-28T09_12_33.log), 4 discarded due to rouge score
INFO 2024-05-28 12:46:34,249 generate_data.py:569 Generation took 12841.62s
(venv) [tronde@t14s instructlab]$ ls generated/
discarded_merlinite-7b-lab-Q4_K_M_2024-05-28T09_12_33.log
generated_merlinite-7b-lab-Q4_K_M_2024-05-28T09_12_33.json
test_merlinite-7b-lab-Q4_K_M_2024-05-28T09_12_33.jsonl
train_merlinite-7b-lab-Q4_K_M_2024-05-28T09_12_33.jsonl

Zur Laufzeit werden alle CPU-Threads voll ausgelastet. Auf meinem Laptop dauerte dieser Vorgang knapp 4 Stunden.

Das Training beginnt

Jetzt wird es Zeit, das LLM mit den synthetischen Daten anzulernen bzw. zu trainieren. Dieser Vorgang wird mehrere Stunden in Anspruch nehmen und ich verplane mein Laptop in dieser Zeit für keine weiteren Arbeiten.

Um möglichst viele Ressourcen freizugeben, beende ich das LLM (ilab serve und ilab chat). Das Training beginnt mit dem Befehl ilab train… und dauert wirklich lange.

Nach 2 von 101 Durchläufen wird die geschätzte Restlaufzeit mit 183 Stunden angegeben. Das Ergebnis spare ich mir dann wohl für einen Folgeartikel auf und gehe zum Fazit über.

Fazit

Mit dem InstructLab Getting Started Guide gelingt es in kurzer Zeit, das Projekt auf einem lokalen Linux-Rechner einzurichten, ein LLM auszuführen und mit diesem zu chatten.

KI-Halluzinationen stellen in meinen Augen ein Problem dar. Da LLMs überzeugend argumentieren, kann es Nutzern schwerfallen oder gar misslingen, die Falschaussagen als solche zu erkennen. Im schlimmsten Fall lernen Nutzer somit dummen Unfug und verbreiten diesen ggf. weiter. Dies ist allerdings kein Problem bzw. Fehler des InstructLab-Projekts, da alle LLMs in unterschiedlicher Ausprägung von KI-Halluzinationen betroffen sind.

Wie Knowledge und Skills hinzugefügt werden können, musste ich mir aus drei Guides anlesen. Dies ist kein Problem, doch kann der Leitfaden evtl. noch etwas verbessert werden.

Knowledge Contributions werden aktuell nur nach vorheriger Genehmigung und nur von Wikipedia-Quellen akzeptiert. Der Grund wird nicht klar kommuniziert, doch ich vermute, dass dies etwas mit geistigem Eigentum und Lizenzen zu tun hat. Wikipedia-Artikel stehen unter einer Creative Commons Attribution-ShareAlike 4.0 International License und können daher unkompliziert als Quelle verwendet werden. Da sich das Projekt in einem frühen Stadium befindet, kann ich diese Limitierung nachvollziehen. Ich wünsche mir, dass grundsätzlich auch Primärquellen wie Herstellerwebseiten und Publikationen zugelassen werden, wenn Rechteinhaber dies autorisieren.

Der von mir herangezogene Wikipedia-Artikel ist leider nicht ganz aktuell. Nutze ich ihn als Quelle für das Training eines LLM, bringe ich dem LLM damit veraltetes und nicht mehr gültiges Wissen bei. Das ist für meinen ersten Test unerheblich, für Beiträge zum Projekt jedoch nicht sinnvoll.

Die Generierung synthetischer Daten dauert auf Alltagshardware schon entsprechend lange, das anschließende Training jedoch nochmals bedeutend länger. Dies ist meiner Ansicht nach nichts, was man nebenbei auf seinem Laptop ausführt. Daher habe ich den Test auf meinem Laptop abgebrochen und lasse das Training aktuell auf einem Fedora 40 Server mit 32 GB RAM und 10 CPU-Kernen ausführen. Über das Ergebnis und einen Test des verbesserten Modells werde ich in einem folgenden Artikel berichten.

Was ist mit euch? Kennt ihr das Projekt InstructLab und habt evtl. schon damit gearbeitet? Wie sind eure Erfahrungen?

Arbeitet ihr mit LLMs? Wenn ja, nutzt ihr diese nur oder trainiert ihr sie auch? Was nutzt ihr für Hardware?

Ich freue mich, wenn ihr eure Erfahrungen hier mit uns teilt.

Wer meiner Artikelreihe „Nextcloud auf dem RasPi“ gefolgt ist und alle Schritte nacheinander umgesetzt hat, sollte erfolgreich eine Nextcloud 29 auf dem Raspberry Pi installiert haben, die über ein SSL-Zertifikat von Let’s Encrypt aus dem Internet erreichbar ist. Obwohl inzwischen Version 30 am 14.09.2024 veröffentlicht wurde, wird diese noch nicht im Stable-Zweig bereitgestellt. Daher werde ich nun auf die Behebung der verbleibenden Fehler in Nextcloud 29 eingehen.

Es fällt sicherlich auf, dass im installierten System in den Verwaltungseinstellungen zahlreiche Fehlermeldungen aufgelaufen sind. Diese müssen nun behoben und beseitigt werden.

Ihr Datenverzeichnis und Ihre Dateien sind wahrscheinlich vom Internet aus erreichbar. Die .htaccess-Datei funktioniert nicht. Es wird dringend empfohlen, Ihren Webserver dahingehend zu konfigurieren, dass das Datenverzeichnis nicht mehr vom Internet aus erreichbar ist oder dass Sie es aus dem Document-Root-Verzeichnis des Webservers herausverschieben.

Das PHP-Speicherlimit liegt unterhalb des empfohlenen Wertes von 512 MB.

Die PHP-Konfigurationsoption „output_buffering“ muss deaktiviert sein

Ihr Webserver ist nicht ordnungsgemäß für die Auflösung von „/ocm-provider/“ eingerichtet. Dies hängt höchstwahrscheinlich mit einer Webserver-Konfiguration zusammen, die nicht dahingehend aktualisiert wurde, diesen Ordner direkt zu auszuliefern. Bitte vergleichen Sie Ihre Konfiguration mit den mitgelieferten Rewrite-Regeln in „.htaccess“ für Apache oder den in der Nginx-Dokumentation mitgelieferten. Auf Nginx sind das typischerweise die Zeilen, die mit „location ~“ beginnen und ein Update benötigen. Weitere Informationen finden Sie in der Dokumentation .

Ihr Webserver ist nicht ordnungsgemäß für die Auflösung von .well-known-URLs eingerichtet. Fehler bei: /.well-known/webfinger Weitere Informationen finden Sie in der Dokumentation .

4 Fehler in den Protokollen seit 20. September 2024, 10:15:53

Der Server hat keine konfigurierte Startzeit für das Wartungsfenster. Das bedeutet, dass ressourcenintensive tägliche Hintergrundaufgaben auch während Ihrer Hauptnutzungszeit ausgeführt werden. Wir empfehlen, das Wartungsfenster auf eine Zeit mit geringer Nutzung festzulegen, damit Benutzer weniger von der Belastung durch diese umfangreichen Aufgaben beeinträchtigt werden. Weitere Informationen finden Sie in der Dokumentation .

Einige Header sind in Ihrer Instanz nicht richtig eingestellt – Der Strict-Transport-Security-HTTP-Header ist nicht gesetzt (er sollte mindestens 15552000 Sekunden betragen). Für erhöhte Sicherheit wird empfohlen, HSTS zu aktivieren. Weitere Informationen finden Sie in der Dokumentation .

In der Datenbank fehlen einige Indizes. Auf Grund der Tatsache, dass das Hinzufügen von Indizes in großen Tabellen einige Zeit in Anspruch nehmen kann, wurden diese nicht automatisch erzeugt. Durch das Ausführen von „occ db:add-missing-indices“ können die fehlenden Indizes manuell hinzugefügt werden, während die Instanz weiter läuft. Nachdem die Indizes hinzugefügt wurden, sind Anfragen auf die Tabellen normalerweise schneller. Fehlende optionaler Index „mail_messages_strucanalyz_idx“ in der Tabelle „mail_messages“. Fehlende optionaler Index „mail_class_creat_idx“ in der Tabelle „mail_classifiers“. Fehlende optionaler Index „mail_acc_prov_idx“ in der Tabelle „mail_accounts“. Fehlende optionaler Index „mail_alias_accid_idx“ in der Tabelle „mail_aliases“. Fehlende optionaler Index „systag_by_objectid“ in der Tabelle „systemtag_object_mapping“. Fehlende optionaler Index „mail_messages_mb_id_uid_uidx“ in der Tabelle „mail_messages“. Fehlende optionaler Index „mail_smime_certs_uid_email_idx“ in der Tabelle „mail_smime_certificates“. Fehlende optionaler Index „mail_trusted_senders_idx“ in der Tabelle „mail_trusted_senders“. Fehlende optionaler Index „mail_coll_idx“ in der Tabelle „mail_coll_addresses“.

Das PHP OPcache-Modul ist nicht ordnungsgemäß konfiguriert. Der „OPcache interned strings“-Puffer ist fast voll. Um sicherzustellen, dass sich wiederholende Strings effektiv zwischengespeichert werden können, wird empfohlen, „opcache.interned_strings_buffer“ mit einem Wert größer als „8“ in der PHP-Konfiguration zu setzen.. Weitere Informationen finden Sie in der Dokumentation .

Die Datenbank wird für transaktionale Dateisperren verwendet. Um die Leistung zu verbessern, konfigurieren Sie bitte Memcache, falls verfügbar. Weitere Informationen finden Sie in der Dokumentation .

Es wurde kein Speichercache konfiguriert. Um die Leistung zu verbessern, konfigurieren Sie bitte Memcache, sofern verfügbar. Weitere Informationen finden Sie in der Dokumentation .

Für Ihre Installation ist keine Standard-Telefonregion festgelegt. Dies ist erforderlich, um Telefonnummern in den Profileinstellungen ohne Ländervorwahl zu überprüfen. Um Nummern ohne Ländervorwahl zuzulassen, fügen Sie bitte „default_phone_region“ mit dem entsprechenden ISO 3166-1-Code der Region zu Ihrer Konfigurationsdatei hinzu. Weitere Informationen finden Sie in der Dokumentation .

Sie haben Ihre E-Mail-Serverkonfiguration noch nicht festgelegt oder überprüft. Gehen Sie bitte zu den „Grundeinstellungen“, um diese festzulegen. Benutzen Sie anschließend den Button „E-Mail senden“ unterhalb des Formulars, um Ihre Einstellungen zu überprüfen. Weitere Informationen finden Sie in der Dokumentation .

Dieser Instanz fehlen einige empfohlene PHP-Module. Für eine verbesserte Leistung und bessere Kompatibilität wird dringend empfohlen, diese zu installieren: – gmp für WebAuthn passwortlose Anmeldung und SFTP-Speicher Weitere Informationen finden Sie in der Dokumentation .

Fehlerbeseitigung

Der erste Fehler in der Liste (… Datenverzeichnis und Ihre Dateien sind wahrscheinlich vom Internet aus erreichbar …) wird behoben, indem man die Konfigurationsdatei des Webservers mit

sudo nano /etc/apache2/apache2.conf

öffnet und den folgenden Eintrag

<Directory /var/www/>
        Options Indexes FollowSymLinks
        AllowOverride None
        Require all granted
</Directory>

sucht. Hier wird „None“ durch „All“ ersetzt. Anschließend wird der Webserver neu gestartet und überprüft, ob die Fehlermeldung tatsächlich verschwunden ist. Diese Vorgehensweise wird nun bei jedem der zu beseitigenden Fehler wiederholt. Auf diese Weise lässt sich gut nachvollziehen, wie die Liste nach und nach abgebaut wird.

sudo service apache2 restart

Beim zweiten Fehler gilt es, das Memory Limit in der php.ini von 128MB auf 512MB anzuheben. Hierzu öffnet man diese mit

sudo nano /etc/php/8.2/apache2/php.ini

und ändert den Wert von

memory_limit = 128M

auf.

memory_limit = 512M

Anschließend wird der Webserver erneut gestartet.

sudo service apache2 restart

Eine weitere Fehlermeldung (… Einige Header sind in Ihrer Instanz nicht richtig eingestellt …) wird behoben, indem wir den Header HSTS aktivieren.

sudo a2enmod headers

Im Anschluss geht man in den VirtualHost, wie im Artikel „Nextcloud auf dem RasPi – Teil 5“ beschrieben,

sudo nano /etc/apache2/sites-available/raspi.conf

und entfernt das Rautezeichen vor der Zeile. Die Zeile wird also auskommentiert

Header always set Strict-Transport-Security "max-age=31536000"

und der Webserver neu gestartet.

sudo service apache2 restart

Danach wird ein weiterer Fehler (… E-Mail-Serverkonfiguration noch nicht festgelegt …) wie folgt behoben: Hierzu navigiert man in die Verwaltungseinstellungen → Verwaltung → Grundeinstellungen und ermöglicht Nextcloud, eMails zu senden. Dies ist wichtig, damit man bei einem vergessenen Passwort als Nutzer dieses zurücksetzen kann.

Diese Daten sind natürlich an die eigene E-Mail-Adresse anzupassen. Die meisten E-Mail-Anbieter geben hier entsprechende Anleitungen.

Die nächste Fehlermeldung (… keine Standard-Telefonregion festgelegt …) verschwindet, indem die Konfigurationsdatei der Nextcloud mit

sudo nano /var/www/html/nextcloud/config/config.php

um folgende Zeile am Ende der Auflistung erweitert wird.

'default_phone_region' => 'DE',

Die Fehlermeldung zum OPcache-Modul (… PHP OPcache-Modul ist nicht ordnungsgemäß konfiguriert …) lässt sich beseitigen, indem das Paket php-apcu installiert und die Erweiterung entsprechend konfiguriert wird.

sudo apt install php-apcu -y

Danach wird die Konfiguration der Nextcloud mit

sudo nano /var/www/html/nextcloud/config/config.php

erneut aufgerufen und

'memcache.local' => '\\OC\\Memcache\\APCu',

vor ’trusted_domains … eingefügt. Um das Ganze wirksam umzusetzen, öffnet man noch einmal die php.ini mit

sudo nano /etc/php/8.2/apache2/php.ini

und fügt diesen Block am Ende der Datei ein.

opcache.enable=1
opcache.interned_strings_buffer=64
opcache.max_accelerated_files=10000
opcache.memory_consumption=128
opcache.save_comments=1
opcache.revalidate_freq=1

Abschließend wird der Apache2 wieder neu gestartet.

sudo service apache2 restart

Die Problematik zum Thema (… konfigurieren Sie bitte Memcache …) lässt sich lösen, indem man einen Redis-Server installiert, konfiguriert und diesen einbindet. Dazu werden die Pakete redis-server und php-redis installiert.

sudo apt install redis-server php-redis -y

In der redis.conf werden danach mit

sudo nano /etc/redis/redis.conf

die Zeilen

unixsocket /run/redis/redis-server.sock
        unixsocketperm 770

gesucht, auskommentiert und der Redis-Server gestartet.

sudo service redis start

Nun muss der Benutzer www-data noch zur Gruppe redis hinzugefügt werden.

sudo usermod -aG redis www-data

Um das Ganze nun abschließend umzusetzen, wird erneut die Konfiguration der Nextcloud geöffnet,

sudo nano /var/www/html/nextcloud/config/config.php

um folgenden Block unter der Zeile ’memcache.local … einzufügen.

'filelocking.enabled' => true,
  'memcache.locking' => '\OC\Memcache\Redis',
  'redis' => array(
     'host' => 'localhost',
     'port' => 6379,
     'timeout' => 0.0,
      ),

Nach einem erneuten Neustart des Webservers sollte nun auch diese Fehlermeldung verschwunden sein.

sudo service apache2 restart

Nun wird noch dafür gesorgt, dass HTTPS bei einer Webserveranfrage erzwungen wird. Dazu wird das Apache2-Modul rewrite installiert

sudo a2enmod rewrite

und via

sudo nano /etc/apache2/sites-available/raspi.conf

ein weiteres Mal der VirtualHost aufgerufen und dieser Block unter der Zeile <VirtualHost *:80> eingefügt.

RewriteEngine On
        RewriteCond %{HTTPS} !=on
        RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Wieder wird der Webserver gestartet.

sudo service apache2 restart

Die Fehlermeldung zu fehlenden Modulen (… fehlen einige empfohlene PHP-Module …) wird durch die Installation des Pakets php-gmp beseitigt.

sudo apt install php-gmp -y

Nach der Installation wird der Apache2 ein weiteres Mal neu gestartet.

sudo service apache2 restart

Ein anderer Fehler (… Server hat keine konfigurierte Startzeit für das Wartungsfenster …) lässt sich beheben, indem man die Nextcloud-Konfiguration mit

sudo nano /var/www/html/nextcloud/config/config.php

um diese zwei Zeilen

'maintenance' => false,
  'maintenance_window_start' => 1,

unter dem letzten Block erweitert.

Um OCC-Befehle auszuführen, ist es notwendig, den Alternative PHP Cache (APC) für das Command Line Interface (CLI) zu aktivieren. Dies ist wichtig, um den nächsten Fehler zu beheben. Dazu wird die entsprechende Konfigurationsdatei geöffnet

sudo nano /etc/php/8.2/mods-available/apcu.ini

und folgender Eintrag

apc.enable_cli=1

ans Ende gesetzt und der Webserver neu gestartet.

sudo service apache2 restart

Jetzt kann die Fehlermeldung (… In der Datenbank fehlen einige Indizes …) behoben werden, nachdem das Verzeichnis /var/www/html/nextcloud/ zuvor betreten wurde.

cd /var/www/html/nextcloud/

Hier führt man den entsprechenden OCC-Befehl aus, der fehlende Indizes der Nextcloud-Datenbank hinzufügt.

sudo -u www-data php occ db:add-missing-indices

Abschließend wird die Log-Datei der Nextcloud gelöscht. Danach sollte sich ein grünes Häkchen mit dem Hinweis „Alle Überprüfungen bestanden“ zeigen.

sudo -u www-data truncate /var/www/html/nextcloud/data/nextcloud.log --size 0

Fazit

Selbstverständlich ist es von entscheidender Bedeutung, dass die Nextcloud optimal funktioniert. Dieser Artikel soll dazu beitragen. Anfangs mag man durch die Vielzahl der Fehlermeldungen etwas überwältigt sein. Doch wenn alle Schritte nach und nach abgearbeitet werden, wird man am Ende mit dem grünen Häkchen belohnt. Ein regelmäßiger Blick in die Verwaltungseinstellungen gibt Aufschluss über den Fortschritt und erleichtert das Verständnis der durchgeführten Maßnahmen.

Tipp

Nach der Veröffentlichung des ersten Point Releases von Nextcloud 30 wird automatisch ein Upgrade auf diese Version vorgeschlagen. Es wird empfohlen, über den grafischen Updater auf die neuere Version umzusteigen.

Vorschau

Der nächste Artikel dieser Reihe wird sich damit befassen, das System mit „PHP-FPM“ weiter zu optimieren und die Ladezeiten zu verkürzen.

Sachstandsbericht im Ausschuss für Personal und Organisation veröffentlicht

Bild: AG Freie Software

DIREKT ZUR VIDEOBOTSCHAFT

Gemeinsam mit der Stadt Dortmund legt Do-FOSS den ersten Sachstandsbericht (CC-BY-SA) des städtischen digitalen Innovationsprojekts Potenzialanalyse Freie Software und Offene Standards vor. Der Bericht wurde vom zuständigen Ausschuss für Personal und Organisation am 30.01.2020 zur Kenntnis genommen.

Die Motivation für den Einsatz von Freier Software wird u.a. von den folgenden Überlegungen getragen:

• IT-Monopole wie das der Firma Microsoft und Herstellerabhängigkeiten werden zunehmend als konträr zum Gemeinwohl erkannt. Ohne digitale Souveränität gibt es keine Souveränität des öffentlichen Dienstes und keine staatliche Souveränität. Freie Software ist für die Souveränität digitaler Gesellschaften der Grundbaustein.
• Für Do-FOSS gilt es eine IT-Betriebsverantwortung u.a. im gültigen vergaberechtlichen und datenschutzrechtlichen Rechtsrahmen zu gewährleisten. Freie Software bietet hierfür die nötigen Voraussetzungen.
• Die Dortmunder Stadtverwaltung strebt für attraktive Arbeitsplätze in der Digitalisierung nach agilen, flexiblen und mobilen Arbeitsmethoden. Eine IT-Infrastruktur auf Basis von Offenen Standards bietet hierfür die nötige Modularität.
• Die kommunale IT-Landschaft entspricht einem heterogenen Strauß an Anforderungen und Anwendungen. Eine zentrale Herausforderung ist es daher, diese Aspekte in einer IT-Strategie zu bündeln, sodass die Vorteile von Freier Software für die Stadt Dortmund zum Tragen kommen.

Der IT- und Personaldezernent Christian Uhr lobte auf der Pressekonferenz zur Vorstellung des Sachstandsberichts die strategische Begleitung der städtischen Arbeitsgruppe Freie Software durch Do-FOSS. Dabei hob er die sachorientierte Sicht von Do-FOSS als Bürgerinitiative mit neutraler Außensicht auf die Verwaltung hervor. Besonderer Dank seitens Do-FOSS gilt den langjährigen Kooperationspartnern für ihre Unterstützung bei unserem Vorhaben.

Ausblick

Der Sachstandsbericht gibt im abschließenden Abschnitt (vgl. Abschnitt 6) folgenden Ausblick:

Durch die aktuellen Entwicklungen auf Bundesebene (vgl. u.a. die Pressemitteilung des Bundesministeriums des Inneren, für Bau und Heimat BMI intensiviert Aktivitäten zur Stärkung der digitalen Souveränität in der öffentlichen Verwaltung ^[1] und die zugrunde liegende Studie Strategische Marktanalyse zur Reduzierung von Abhängigkeiten von einzelnen Software-Anbietern ist es für die Stadtverwaltung Dortmund geboten die eigene Digitalisierungsstrategie im Hinblick auf Freie Software und Offene Standards weiterzuentwickeln. Die Charta Digitales Dortmund 2018-2030 bietet für die weitere Bearbeitung einen geeigneten Rahmen. […]

Im Zusammenhang mit der städtischen Digitalisierungsstrategie wird die Zusammenarbeit mit dem CIO der Stadt Dortmund intensiviert. Das CIO übernimmt künftig die vernetzende Funktion, da sich die Thematik über viele Bereiche der Stadt Dortmund erstreckt. Die Ausrichtung der Arbeitsgruppe Freie Software wird daher entsprechend angepasst und sieht in diesem Zuge vor den Ergebnisbericht zum Einsatzpotenzial Freier Software und Offener Standards bis Ende des zweiten Quartals 2022 zu erstellen sowie den politischen Gremien vorzulegen. Bis zur Fertigstellung des Ergebnisberichts wird es verschiedene fachliche und öffentliche Beteiligungsformate geben; u.a. wird für das erste Quartal 2022 eine kommunale Open Government Konferenz in Dortmund geplant.

[1] Pressemitteilung des BMI vom 19.09.2019, abgerufen am 07.12.2019

Do-FOSS sieht besonders der kommunalen Open Government Konferenz entgegen und freut sich auf die gemeinsame Konferenzplanung mit dem Offene Kommunen.NRW Institut (OK.NRW). Es wird eine Konferenz für Freie Software für Kommunen und ein Bündnisauftakt für Kommunen für Freie Software. Hierzu lädt Do-FOSS bereits per Video ein:

Die künftige Arbeit der Arbeitsgruppe Freie Software kann in einer Instanz von OpenProject verfolgt werden. Die Ergebnisse der Arbeitsgruppe Freie Software stehen, wie bei Do-FOSS üblich, unter einer Creative-Commons-Lizenz, so auch der aktuelle Sachstandsbericht (CC-BY-SA). Bei Fragen oder Anmerkungen kann die Arbeitsgruppe unter ag_freiesoftware@stadtdo.de und Do-FOSS unter kontakt@do-foss.de kontaktiert werden.

Pressemitteilung der Stadt Dortmund im Wortlaut

Die Pressemitteilung der Stadt Dortmund Masterplan „Digitale Verwaltung – Arbeiten 4.0“: Sachstandsbericht – Potential von Freier Software und Offenen Standards nutzen vom 14.01.2020 im Wortlaut:

Masterplan „Digitale Verwaltung – Arbeiten 4.0“:
Sachstandsbericht – Potential von Freier Software und Offenen Standards nutzen

Die Stadtverwaltung Dortmund hat bereits 2018 damit begonnen im Rahmen des Masterplans Digitale Stadtverwaltung die Potentiale von Freier Software und Offener Standards zu untersuchen. Mit Blick auf die aktuellen Aktivitäten und Entwicklungen auf Bundes- und Landesebene zur Stärkung der digitalen Souveränität der öffentlichen Verwaltung wird deutlich, wie wichtig diese Analyse für die Fortentwicklung der eigenen Digitalisierungsstrategie ist. Dabei geht es insbesondere darum, Wege zur Reduzierung von Abhängigkeiten zu einzelnen IT-Anbietern zu finden. Daneben verfolgt die Stadtverwaltung Dortmund mit dem Projekt u.a. noch weitere Zielvorstellungen, wie die Erhöhung der Flexibilität und Steuerungsfähigkeit beim Softwareeinsatz, dem Einsatz von offenen und standardisierten Dateiformaten und der Ermöglichung neuer Synergien sowie dem Abbau von lizenzrechtlichen Hemmnissen.

Eine erste wichtige Zwischenetappe ist nun erreicht. Die Arbeitsgruppe Freie Software, bestehend aus dem Dortmunder Systemhaus, dem Personalrat der Stadtverwaltung Dortmund und der Bürgerinitiative Do-FOSS, der Initiative für den Einsatz Freier und Quelloffener Software (Free and Open Source Software, kurz FOSS), hat die erste Phase der Potentialanalyse abgeschlossen und einen ersten Sachstandsbericht, u.a. mit Anforderungen, Begriffen und einer Bestandsaufnahme erstellt. Diese Dokumentation dient der Arbeitsgruppe als Basis für das weitere Vorgehen. Personal- und Organisationsdezernent Christian Uhr lobt die bisherige Zusammenarbeit mit der Bürgerinitiative: „Das Projekt ist ein gutes Beispiel dafür, dass Bürger und Verwaltung konstruktiv und vertrauensvoll zusammenarbeiten können. Die neu gewonnenen Erkenntnisse werden uns dabei helfen, Abhängigkeiten vorzubeugen und auch in Zukunft digital handlungsfähig zu bleiben.“

Der Ergebnisbericht zum Einsatzpotenzial Freier Software und Offener Standards soll den politischen Gremien bis Ende des zweiten Quartals 2022 vorgelegt werden. Bis zur Fertigstellung des Ergebnisberichts wird es verschiedene fachliche und öffentliche Beteiligungsformate geben; u.a. wird für das erste Quartal 2022 eine kommunale Open Government Konferenz in Dortmund geplant.

Kontakt: Michael Meinders

Auszug aus der Vorlage an den Ausschuss für Personal und Organisation im Wortlaut

Die vollständige Vorlage an den Ausschuss für Personal und Organisation kann hier eingesehen werden. Der wesentliche Auszug aus der Vorlage wird im Folgenden wiedergegeben.

Die Verwaltung wurde beauftragt, einen Bericht zum Einsatzpotenzial von Freier Software und von Offenen Standards im Bereich der städtischen Informations- und Telekommunikationstechnik vorzulegen.

Im Rahmen der Arbeitsgruppe „Freie Software“, bestehend aus dem Dortmunder Systemhaus, dem Personalrat der Stadtverwaltung Dortmund und der Bürgerinitiative Do-FOSS, der Initiative für den Einsatz Freier und Quelloffener Software (Free and Open Source Software, kurz FOSS) bei der Stadt Dortmund, wurden daraufhin verschiedene Beschreibungen und Auswertungen für den Abschluss der ersten Phase „Begriffe, Anforderungen und Bestandsaufnahme“ erstellt. Die Dokumentation der ersten Phase dient als Basis für die weitere Vorgehensweise und umfasst die folgenden Themenpunkte:

a) Beschreibung allgemeiner Vorüberlegungen und Begriffsbestimmungen
In diesem Abschnitt wird ein allgemeiner Einblick in das Themenfeld des Softwareeinsatzes und den damit verbundenen Fragestellungen bzgl. der Nutzungsrechte, der Kompatibilität und Interoperabilität, des Datenschutzes und der IT-Sicherheit gegeben. Insbesondere wird definiert, was Freie Software und Offene Standards sind, wie diese mit unterschiedlichen Geschäftsmodellen auf dem Softwaremarkt verknüpft sind und welche Zusammenhänge in Bezug auf Handlungsspielräume sowie Herstellerabhängigkeiten bestehen. Darüber hinaus wird eine einheitliche Terminologie und Kategorisierung von Software für das weitere Dokument eingeführt.

b) Beschreibung von Anforderungen der Stadt Dortmund an eine Software
Dieser Abschnitt beschreibt, wie die Stadt Dortmund Software in einem transparenten Verfahren auswählt und diese nach einem geregelten Prozess einführt. Grundlage dafür ist die „Geschäftsanweisung zur Einführung von Anwendungssoftware in der Stadtverwaltung Dortmund“ vom 13.07.2017, welche sich aktuell in einer grundlegenden Überarbeitungsphase befindet. Bei der Erstellung des Zwischenberichtes wurden bereits neue Einflüsse der Überarbeitung berücksichtigt. Oberstes Ziel bei der Auswahl ist die Erfüllung der zu Grunde liegenden Aufgabenstellung.

c) Erfassung der eingesetzten Freien-Software-Produkte in der Stadtverwaltung
Dortmund
Es wurde eine erste Bestandsaufnahme zum Freien-Software-Einsatz innerhalb der Dortmunder Stadtverwaltung erstellt. Die Erfassung wurde für Desktop- und Serversysteme getrennt vorgenommen und für die weitere Analyse im Verlauf des Projektes aufbereitet. Eine vollständige Liste der ermittelten Produkte auf Desktopsystemen, sowie die Häufigkeit der installierten Betriebssysteme in der Serverlandschaft sind im Sachstandsbericht erfasst.

d) Erfassung der Dateiendungen und -formate in der Stadtverwaltung Dortmund
Innerhalb der Stadtverwaltung Dortmund werden verschiedene Dateiformate verarbeitet. Zur weiteren Analyse wurden die geläufigsten Dateiendungen innerhalb der Stadtverwaltung Dortmund erfasst und auf Dateiformate zurückgeführt, soweit dies eindeutig möglich war. Eine vollständige Liste der betrachteten 1.121 Dateiendungen inkl. deren Häufigkeiten wurde erstellt. Es wurden die Top 50 Dateiendungen ausgewertet und kategorisiert, sowie die Top 20 Dateiendungen und -formate im zeitlichen Änderungsverlauf betrachtet.

Ausblick
Durch die aktuellen Entwicklungen auf Bundesebene (vgl. u.a. die Pressemitteilung des Bundesministeriums des Inneren, für Bau und Heimat „BMI intensiviert Aktivitäten zur Stärkung der digitalen Souveränität in der öffentlichen Verwaltung“ vom 19.09.2019, https://www.bmi.bund.de/SharedDocs/pressemitteilungen/DE/2019/09/digitale-souveraenitaet-oeff-verwltg.html, abgerufen am 07.12.2019 und die zugrunde liegende Studie „Strategische Marktanalyse zur Reduzierung von Abhängigkeiten von einzelnen Software-Anbietern“) ist es für die Stadtverwaltung Dortmund geboten, die eigene Digitalisierungsstrategie im Hinblick auf Freie Software und Offene Standards weiterzuentwickeln. Die Charta „Digitales Dortmund 2018-2030“ bietet für die weitere Bearbeitung einen geeigneten Rahmen.

Im Zusammenhang mit der städtischen Digitalisierungsstrategie wird die Zusammenarbeit mit dem CIO der Stadt Dortmund intensiviert. Das CIO übernimmt künftig die vernetzende Funktion, da sich die Thematik über viele Bereiche der Stadt Dortmund erstreckt. Die Ausrichtung der Arbeitsgruppe Freie Software wird daher entsprechend angepasst und sieht in diesem Zuge vor, den Ergebnisbericht zum Einsatzpotenzial Freier Software und Offener Standards bis Ende des zweiten Quartals 2022 zu erstellen sowie den politischen Gremien vorzulegen. Bis zur Fertigstellung des Ergebnisberichts wird es verschiedene fachliche und öffentliche Beteiligungsformate geben; u.a. wird für das erste Quartal 2022 eine kommunale Open Government Konferenz in Dortmund geplant.

Dokumente zum Herunterladen

Der Sachstandsbericht Untersuchung der Potenziale von Freier Software und Offenen Standards inkl. Anhänge kann hier heruntergeladen werden. Die Pressemitteilung der Stadt Dortmund vom 14.01.2020 kann hier und das zugehörige Pressefoto kann hier bzw. hier hochaufgelöst heruntergeladen werden. Die Vorlage an den Ausschuss für Personal und Organisation zu seiner Sitzung vom 30.01.2020 kann hier heruntergeladen werden. Die Strategische Marktanalyse zur Reduzierung von Abhängigkeiten von einzelnen Software-Anbietern im Auftrag des Bundesministeriums des Inneren, für Bau und Heimat kann hier heruntergeladen werden. Die Charta Digitales Dortmund 2018-2030 kann hier heruntergeladen werden. Eine Broschüre Public Money – Public Code – Modernising Public Infrastructure with Free Software kann hier heruntergeladen werden.

Soweit im gesetzlichen Rahmen möglich verzichtet der Autor auf alle Urheber- und damit verwandten Rechte an diesem Werk.
Es kann beliebig genutzt, kopiert, verändert und veröffentlicht werden.
Für weitere Informationen zur Lizenz, siehe hier.

The post Stadt Dortmund legt mit Zwischenbericht der AG Freie Software den Grundstein für digitale Souveränität appeared first on Do-FOSS.

Vor zwei Jahren half »Prompt Engineering« zu besseren Ergebnissen bei KI-Tools. Heute ist der Weg ein anderer:

• Die Datei AGENTS.md (für die meisten KI-Tools) bzw. CLAUDE.md (für Claude Code) im Projektverzeichnis fasst wichtige Projektinformationen und Coding-Anweisungen zusammen. IDEs wie Cursor bzw. CLIs wie Claude Code oder Codex berücksichtigen diese Datei bei jedem Session-Start automatisch. Damit bietet diese Datei eine großartige Möglichkeit, das Default-Verhalten von KI-Tools den eigenen Ansprüchen anzupassen. (AGENTS.md können CLAUDE.md auf verschiedenen Ebenen gespeichert werden, um z.B. allgemeine Coding-Anweisungen mit spezifischen Projektinformationen zu kombinieren.)

• Skills ermöglichen es, Anweisungen für bestimmte Bearbeitungsschritte im Markdown-Format zu formulieren. Während AGENTS.md immer berücksichtigt wird, werden Skills nur bei Bedarf ausgewertet. Skills können auch Anweisungen für den Aufruf externer Tools beinhalten und ersetzen dann in manchen Fällen die MCP-Server-Konfiguration. (Auch Skills können wahlweise projektspezifisch oder auf globaler Ebene eingerichtet werden.)

Dieser Beitrag zeigt die Anwendung von AGENTS.md und Skills speziell für die Programmiersprache Swift — losgelöst davon, ob Sie in Xcode arbeiten oder eine externe CLI verwenden. Der Artikel hat einen leichten Claude-Fokus, weil ich mich persönlich in der Anthropic-Welt wohler fühle als in der von OpenAI. Qualitativ gibt es keine großen Unterschiede zwischen beiden Systemen, beide funktionieren mittlerweile herausragend gut.

Ich setze hier voraus, dass Sie grundlegende Erfahrung mit KI-Tools haben und zumindest ein CLI-Tool (ich empfehle Claude Code, aber auch Codex CLI, Gemini CLI, Copilot CLI usw.) ausprobiert haben.

AGENTS.md bzw. CLAUDE.md auf Projekt-Ebene

Wenn Sie in Xcode mit Claude Agent oder Codex arbeiten, sollte Ihr erster Prompt in einem neuen Projekt /init lauten. Der Claude Agent bzw. Codex analysiert dann Ihren Code und erzeugt die Datei CLAUDE.md bzw. AGENTS.md. (AGENTS.md ist ein generischer Name. Die Datei wird von den meisten KI-Tools berücksichtigt, absurderweise aber nicht von Anthropic-Tools, die auf CLAUDE.md bestehen.)

Die Datei wird im Projektverzeichnis gespeichert; sie ist im Projektnavigator unsichtbar, weil dieser eine Verzeichnisebene tiefer ansetzt. Im Regelfall lohnt es sich, diese Datei in einem Editor nachzubearbeiten und dort bei Bedarf eigene Coding-Anweisungen hinzuzufügen.

Beachten Sie, dass die Datei bei jeder Session in den Kontext gelesen wird. Halten Sie sich daher kurz!

Die von Claude Code ohne meine Mithilfe generierte Datei CLAUDE.md für das Cart-Beispielprogramm (Kapitel 25 in meinem Swift-Buch) sieht beispielsweise so aus:

# CLAUDE.md

This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.

## Build & Run

This is an Xcode project (`family-cart.xcodeproj`). Build and run through Xcode or use the `BuildProject` MCP tool. There are no tests, no linter, and no package dependencies.

## Architecture

**Family Cart** is a SwiftUI shopping list app that syncs across family members via a REST API. The codebase follows a strict three-layer structure reflected in the folder naming:

### 1_model
- **ShoppingItem** — Immutable `struct` (Codable, Identifiable). All mutations produce new copies via the `with(...)` helper. Persisted locally as JSON in the Documents directory (`shoppingItems.json`). The `[ShoppingItem].save()` extension handles local persistence.
- **Category** — `@Observable class` with 10 predefined grocery categories. Each has a `shortcut` string (e.g. `"bread"`, `"veg"`, `"dairy"`) used as the foreign key in ShoppingItem. Categories are not persisted — they are recreated from `predefinedCategories()` on every launch. `Color(hex:)` extension lives here.

...
## Key Patterns

- **No Combine**: The app uses `@Observable` (Observation framework) and Swift concurrency (async/await). Avoid introducing Combine.
- **Immutable model pattern**: `ShoppingItem` is a struct. Always use `with(...)` to create modified copies, then `replaceItem(_:with:)` on the view model. Never mutate items in place.
- **Single ViewModel**: All state flows through `ShoppingViewModel`. Views receive it as a parameter (not via `@Environment`).
- **Categories as constants**: The 10 categories and their shortcuts are hardcoded. Category images use custom assets with `-fill` suffix variants for selected state.
- **Localization**: Strings are localized via `Localizable.xcstrings` (English + German). Category names use `LocalizedStringKey`.
- **Soft delete**: Items are never removed from the array — `deleteItem()` sets `isDeleted = true` and title to `"deleted"`.

## REST API

Backend at `cart.kofler.info:443`. Authentication via HMAC-SHA256 tokens that rotate every 5 minutes. Key endpoints:

- `GET /version` — connectivity test
- `GET/PUT /items/{family_id}` — pull/push shopping items
- `PUT /newfamily`, `PUT /newmember` — family setup
- `GET /family/{code}`, `GET /members/{family_id}` — family lookup

AGENTS.md bzw. CLAUDE.md auf Xcode-Ebene

Während AGENTS.md bzw. CLAUDE.md im Projektverzeichnis eben nur für dieses Projekt gilt, können Sie die gleichnamige Datei auch in speziellen Xcode-Verzeichnissen speichern. Die dort formulierten Regeln gelten dann für alle Projekte in Xcode, in denen Sie den jeweiligen Agenten zu Hilfe nehmen.

Die aktuelle KI-Integration sieht die folgenden beiden Verzeichnisse zur Konfiguration von Claude Agent bzw. Codex vor (Quelle):

~/Library/Developer/Xcode/CodingAssistant/codex
~/Library/Developer/Xcode/CodingAssistant/ClaudeAgentConfig

Die dort gespeicherten Dateien werden — parallel zu eventuell ebenfalls vorhandenen gleichnamigen Dateien auf Projektebene — automatisch berücksichtigt, sobald Xcode Codex oder Claude Agent startet.

Vorsicht! Das ClaudeAgentConfig-Verzeichnis gilt nicht, wenn Sie in Xcode Claude verwenden. Es wird nur von Claude Agent berücksichtigt. Diese verwirrende Differenzierung zwischen zwei fast gleichnamigen KI-Features hat mir anfangs eine Menge Zeit gekostet.

Systemweite AGENTS.md-Dateien sind also der ideale Ort, um Swift- bzw. Xcode-spezifische Anweisungen zu speichern, die nichts mit einem konkreten Projekt zu tun haben. Es ist empfehlenswert, den Coding-Agenten dort Hinweise zu geben, dass diese ausschließlich moderne Swift-Sprachmerkmale (z.B. Concurrency) und SwiftUI-Features nutzen sollen.

Warum ist das so wichtig? Sprachmodelle werden mit im Internet verfügbaren Informationen trainiert. Dort überwiegen aber veraltete Informationen, die sich auf ältere Swift/SwiftUI-Versionen beziehen. Deswegen ist der von KI-Sprachmodellen generierte Code oft sub-optimal. (Dass Apple den Coding-Agenten via MCP Zugriff auf die aktuelle Dokumentation gibt, hilft nicht viel. Die KI erkennt gar nicht die Notwendigkeit, dort nachzusehen.)

Es gibt im Internet mehrere Vorlagen für AGENTS.md/CLAUDE.md. Die beste stammt meiner Ansicht nach von Paul Hudson (Hacking with Swift):

https://github.com/twostraws/SwiftAgents/blob/main/AGENTS.md

Laden Sie die Datei herunter, und speichern Sie diese unter einem der beiden folgenden Pfade:

~/Library/Developer/Xcode/CodingAssistant/codex/AGENTS.md
~/Library/Developer/Xcode/CodingAssistant/ClaudeAgentConfig/CLAUDE.md

Lesenswert ist dazu auch Hudsons Blog-Artikel What to fix in AI-generated Swift code!

AGENTS.md bzw. CLAUDE.md auf Systemebene

Die Dateien .claude/CLAUDE.md bzw. .codex/AGENTS.md erfüllen die gleiche Funktion, aber auf Systemebene und losgelöst von Xcode. Dort durchgeführte Einstellungen gelten allerdings für ALLE Programmiersprachen. Insofern ist es keine gute Idee, hier Swift- oder Xcode-spezifische Anweisungen zu speichern.

Wenn die Dateien CLAUDE.md bzw. AGENTS.md auf mehreren Ebenen (System, Xcode, Projekt) existieren, werden alle Dateien berücksichtigt und kombiniert. Umso wichtiger ist es, die Dateien nicht unnötig aufzublähen.

Swift-spezifische Skills

Skills verfolgen die gleiche Idee wie AGENTS-Dateien, formulieren also Regeln im Markdown-Format. Aber während die AGENTS-Dateien immer berücksichtigt werden, werden Skills nur bei Bedarf ausgewertet. Beispielsweise kann ein Skill-Dateiset Refactoring-Regeln enthalten. Erst wenn Sie in einem Prompt explizit Refactoring erwähnen (manchmal müssen Sie ganz explizit auf den Skill hinweisen), werden die dort gespeicherten Zusatzregeln berücksichtigt. Skills können auch Anweisungen für den Aufruf externer Tools beinhalten. Das ist an dieser Stelle aber kein Thema.

In den letzten Monaten haben einige Blogger Skill-Sets für Swift und SwiftUI zusammengestellt (siehe die Links am Ende dieses Beitrags). Ich greife an dieser Stelle den besonders nützlichen Skill SwiftUI Pro heraus:

https://github.com/twostraws/SwiftUI-Agent-Skill

Dieser Skill ist dazu gedacht, um in vorhandenen SwiftUI-Projekten einen Code Review durchzuführen — wahlweise via Claude Code, Codex CLI oder Xcode. Das KI-Sprachmodell durchsucht den Code dann nach veraltetem Code und macht Verbesserungsvorschläge. Das funktioniert großartig!!

Ein konkretes Anwendungsbeispiel im Zusammenspiel mit Claude Code folgt gleich. Vorerst geht es aber um die Installation, bei der es mehrere Varianten gibt, je nachdem ob Sie den Skill in einer CLI (Claude Code, Codex CLI) oder direkt in Xcode nutzen möchten.

Beginnen wir mit der Installation für CLI-Tools: Dazu öffnen Sie ein Terminalfenster und wechseln in das Projektverzeichnis. (Das Installationskommando setzt Node.js voraus. Führen Sie gegebenenfalls vorher brew install node aus.)

cd my-swiftui-project
npx skills add https://github.com/twostraws/swiftui-agent-skill --skill swiftui-pro

Während der Installation werden Sie gefragt, welche KI-Tools/Agenten Sie verwenden (z.B. Antigravity, Claude Code, Codex, Cursor usw.). Das hat Einfluss auf den Installationsort. Viele KI-Tools berücksichtigen das Verzeichnis .agents/skills, aber manche Tools wollen ihr eigenes Verzeichnis (z.B. .agent/skills oder .claude/skills). Dort werden standardmäßig Links auf die Dateien in .agents eingerichtet.

Außerdem müssen Sie sich entscheiden, ob die Skills universell für alle Projekte gelten sollen (Installation relativ zum Home-Verzeichnis) oder nur für ein Projekt (Installation im Projekt-Verzeichnis). Vor allem wenn Sie auf Ihrem Rechner Projekte in verschiedenen Programmiersprachen entwickeln, ist die projektspezifische Installation sicherer.

Die Xcode-Installation ist leider etwas umständlicher. Ich gehe davon aus, dass Sie vorher eine CLI-Installation in ein Projektverzeichnis durchgeführt haben. Von dort kopieren Sie nun das gewünschte Skills-Unterverzeichnis in das passende Xcode-Verzeichnis:

# für Claude Code
mkdir -p ~/Library/Developer/Xcode/CodingAssistant/ClaudeAgentConfig/skills
cd my-swiftui-project
cp -a .claude/skills/swiftui-pro ~/Library/Developer/Xcode/CodingAssistant/ClaudeAgentConfig/skills

# für Codex
mkdir -p ~/Library/Developer/Xcode/CodingAssistant/codex/skills
cd my-swiftui-project
cp -a .agents/skills/swiftui-pro ~/Library/Developer/Xcode/CodingAssistant/codex/skills

Jetzt sollten Sie sich noch vergewissern, dass der neue Skill wirklich im KI-Agenten Ihrer Wahl innerhalb von Xcode verfügbar ist (hier für Claude Code).

Der Aufruf des Skills variiert je nach Coding-Agent:

• Claude Agent: /swiftui-pro funktioniert nicht. (Dieses Claude-Code-Kommando klappt nur in der CLI.) Vielmehr müssen Sie in Xcode einen Prompt formulieren, der so ähnlich wie diese Anweisung aussieht: »Use the SwiftUI Pro skill to look for problems in this project.«

• Codex: $swiftui-pro

Anwendungsbeispiel mit Claude Code

Im Folgenden gehe ich davon aus, dass Sie mit Claude Code arbeiten. Nach dem Start vergewissern Sie sich mit dem Kommando /skills, dass Claude die Skill-Regeln swiftui-pro kennt. Den Code Audit starten Sie nun mit /swiftui-pro (bzw. in Codex mit $swiftui-pro).

cd my-swiftui-project
claude

> /skills

  ...

> /swiftui-pro 

  ...

  Summary

  1. Accessibility (high): Multiple icon-only buttons throughout
    (PlanTabView:66, SettingsTabView:159, CategoriesView:23/37) are invisible
    to VoiceOver. The CategoryHeader uses onTapGesture instead of Button, also
    problematic for VoiceOver.

  2. Deprecated API (high): foregroundColor() used in 6+ locations should be
    foregroundStyle().  cornerRadius() used in 3 locations should be
    clipShape(.rect(cornerRadius:)). tabItem() should be the modern Tab
    API. .autocapitalization() should be .textInputAutocapitalization(). Style
    struct instances (PlainButtonStyle(), etc.) should use static member
    syntax.

  3. Code organization (medium): Multiple type definitions per file throughout
     the view layer (PlanTabView has 3 types, SettingsTabView has 3,
     EditItemView has 3, CategoriesView has 2). Each should be in its own
     file. The itemsForEach method returning some View should be a dedicated
     View struct.

  4. Data flow (medium): Category class is @Observable but missing
     @MainActor. @State var vm in ShoppingTabView, PlanTabView, and
     CategoriesView is not marked private.

  5. Modern Swift (low): Use Date.now over Date(), URL.documentsDirectory over
     FileManager lookups, !items.isEmpty over items.count > 0, modern ISO 8601
     date parsing, and the Tab enum pattern for tab selection.

  The review is complete above. Would you like me to fix any of these issues?

Alle Probleme auf einmal zu beheben ist keine gute Idee. Besser gehen Sie schrittweise vor und erstellen nach jedem Fix und dem nachfolgenden Test Ihrer App Xcode einen Commit.

> fix foregroundColor()

  Done. Replaced all .foregroundColor() with .foregroundStyle() across 3 files:                            

  - ContentView.swift - 4 occurrences (debug overlay text colors)                                          
  - PlanTabView.swift - 2 occurrences (toggle button labels)              
  - SettingsTabView.swift - 3 occurrences (error text, warning text, sync time indicator) 

> ! git commit -a -m 'fixed foregroundColor -> foregroundStyle'  

Lesetipps

AGENT-Dateien und Skills bestehen aus Markdown-Dateien. Selbst wenn Sie keine KI-Tools verwenden wollen, lohnt sich die Lektüre dieser Regeldateien. Sie werden nirgendwo sonst so kompakte Regeln zur richtigen Swift/SwiftUI-Programmierung finden! Lesen Sie beispielsweise die Anweisungen zur richtigen Verwendung von Actors aus dem Concurrency-Skill von Paul Hudson.

Quellen/Links

Grundlagen zu AGENTS.md/CLAUDE.md/Skills

• https://agents.md
• https://developers.openai.com/codex/guides/agents-md
• https://code.claude.com/docs/en/features-overview
• https://support.claude.com/en/articles/12512176-what-are-skills

Agentic Coding mit Xcode

• https://kofler.info/xcode-26-3-kann-endlich-ki
• https://developer.apple.com/documentation/Xcode/setting-up-coding-intelligence#Customize-the-Codex-and-Claude-Agent-environments
• https://www.hackingwithswift.com/articles/281/what-to-fix-in-ai-generated-swift-code
• https://www.hackingwithswift.com/articles/282/swiftui-agent-skill-claude-codex-ai
• https://www.hackingwithswift.com/articles/283/how-to-install-and-use-ai-agent-skills-in-xcode
• https://www.hackingwithswift.com/articles/283/how-to-install-and-use-ai-agent-skills-in-xcode
• https://developer.apple.com/documentation/xcode/giving-agentic-coding-tools-access-to-xcode

Für Swift optimierten AGENTS.md-Dateien und Skills von Paul Hudson

• https://github.com/twostraws/swiftagents (AGENTS.md)
• https://github.com/twostraws/SwiftUI-Agent-Skill (Swift-Basics und SwiftUI)
• https://github.com/twostraws/swiftdata-agent-skill (SwiftData)
• https://github.com/twostraws/swift-concurrency-agent-skill (Concurrency)
• https://github.com/twostraws/Swift-Testing-Agent-Skill (Unit-Tests)

Ähnliche Dateien/Skills von anderen Entwicklern

• https://github.com/AvdLee/SwiftUI-Agent-Skill
• https://github.com/AvdLee/Swift-Concurrency-Agent-Skill

Videos

• https://www.youtube.com/watch?v=QdpaI_j0FRU (Stewart Lynch)
• https://www.youtube.com/live/sc6pvW6vQzA (Paul Hudson)

Die Kinder bekommen ihre Weihnachtsgeschenke am 24.12., bei mir war diesmal zufällig schon eine Woche vorher Bescherung. Direkt von Taiwan versendet traf gestern ein Framework Desktop ein (Batch 17). Wobei von »Geschenk« keine Rede ist, ich habe den Rechner ganz regulär bestellt und bezahlt. Über das Preis/Leistungs-Verhältnis darf man gar nicht nachdenken … Aber für die Überarbeitung des Buchs Coding mit KI will ich nun mal moderat große Sprachmodelle (z.B. gpt-oss-120b) selbst lokal ausführen.

Dieser Blog-Beitrag fasst meine ersten Eindrücke zusammen. In den nächsten Wochen werden wohl noch ein paar Artikel rund um Ollama und llama.cpp folgen.

Auswahl

Ich war auf der Suche nach einem Rechner mit 128 GByte RAM, das von der GPU genutzt werden kann. Dafür gibt es aktuell drei Plattformen (Intel glänzt durch Abwesenheit):

• AMD Ryzen AI Max+ 395 (»Strix Halo«): Dieser Prozessor kombiniert 16 Zen-5-CPU-Cores und 40 GPU-Cores (Radeon 8060S). Die Speicherbandbreite (LPDDR5X) beträgt bis zu 250 GiB/s. Desktop-PCs mit 2 TB SSD kosten zwischen 2.000 und 3.000 €, Notebooks ca. 4.000 €.

• Apple Max CPUs: Der Prozessor M4 Max vereint 16 CPU-Cores mit 40 GPU-Cores. Die Speicherbandbreite erreicht beeindruckende 550 GiB/s. Ein entsprechender Mac Studio mit 2 TB SSD kostet ca. 5000 €, ein MacBook mit vergleichbarer Ausstattung ca. 6000 €.

• NVIDIA DGX Spark: Diese Plattform besteht aus einer 20-Core ARM-CPU plus NVIDIA Blackwell GPU mit 48 Compute Units. Wegen des LPDDR5X-RAMs ist die Speicherbandbreite wie bei Strix Halo auf ca. 250 GiB/s limitiert. Komplettsysteme kosten ca. 4000 € (Asus, Dell, NVIDIA).

Was die Rechenleistung betrifft, spielen alle drei Plattformen in der gleichen Liga, vielleicht mit kleinen Vorteilen bei Apple, vor allem was Effizienz und Lautstärke betrifft. Gegen die NVIDIA-Lösung spricht, dass diese Rechner dezidiert für KI-Aufgaben gedacht sind; eine »normale« Desktop-Nutzung ist nur mit großen Einschränkungen möglich.

Generell darf man sich von der KI-Geschwindigkeit der aufgezählten Geräten keine Wunder erwarten: GPU-Leistung und Speicherbandbreite sind nur mittelprächtig. Praktisch jede dezidierte Grafikkarte kann kleine Sprachmodelle schneller ausführen — aber nur, solange das Sprachmodell komplett im dezidierten VRAM Platz hat. (Bei Desktop-PCs können Sie mehrere Grafikkarten einbauen und kombinieren, aber das ist teuer und kostet viel Strom.) Die oben aufgezählten CPUs mit integrierter GPU können dagegen das gesamten RAM nutzen. Das ist langsamer als bei dezidierten GPUs, aber es macht immerhin die Ausführung von relativ großen Modellen möglich.

Apple ist wie üblich bei vergleichbarer Ausstattung am teuersten. Umgekehrt muss man anerkennen, dass von allen hier aufgezählten Geräten ein Mac Studio vermutlich der einzige Computer ist, der in drei Jahren noch einen nennenswerten Wiederverkaufswert hat.

Am anderen Ende des Preisspektrums befindet sich die AMD-Variante. Es gibt diverse chinesische Mini-PCs mit der AMD-395-CPU: z.B. Bosgame (aktuell am billigsten), GMKtec EVO-X2, Beelink GTR9 (instabil, Probleme mit Intel-Netzwerkadapter) und Minisforum MS-S1 MAX. HP bietet den Z2 Mini G1a zu einem relativ vernünftigen Preis an, aber das Gerät ist anscheinend sehr laut. Schließlich gibt es den Framework Desktop, der ansprechend aussieht, in Tests gut abgeschnitten hat und die beste/leiseste Kühlung hat (leider ein Irrtum, siehe unten).

Ich habe mich nach wochenlanger Recherche für das Framework-Angebot entschieden. Das Konzept der Framework-Geräte ist sympathisch. Außerdem gibt es eine große Community rund um das Gerät. Zum Zeitpunkt der Bestellung kostete der Rechner mit 128 GByte RAM, ein paar Adaptern, Kacheln und Lüfter knapp 2.500 € (inkl. USt). Eine SSD habe ich anderswo besorgt. (Update 15.1.2026: Der Framework Desktop ist mittlerweile leider noch teurer geworden.)

Lieferung

Der Rechner wurde am 12.12. von Taiwan versendet und kam sechs Tage später bei mir an. Faszinierend. (Ich habe noch nie bei Temu & Co. bestellt, habe diesbezüglich auch keine Ambitionen. Insofern war die Verfolgung des Pakets rund um die halbe Welt für mich Neuland.)

Bis zum Schluss wusste ich nicht, ob nun Zoll zu zahlen ist oder nicht. Offenbar nicht. Ich kann nicht sagen, ob sich Framework bei EU-Lieferungen um die ganze Abwicklung kümmert oder ob es Zufall/Glück war. (Das Gerät ist weiß Gott auch ohne Zoll teuer genug …)

Der Zusammenbau ist unkompliziert und gelingt in einer halben Stunde. Ich habe dann Fedora 43 installiert (weitere zehn Minuten). Alles funktionierte auf Anhieb, das Gerät lief die erste halbe Stunde praktisch lautlos.

Benchmark-Tests

Ich habe mich nicht lange mit Benchmark-Tests aufgehalten. BIOS in Grundzustand, Fedora 43 mit Gnome im Energiemodus Ausgeglichen.

Geekbench lieferte 2790 Single / 20.700 Multi-Core

Kernel kompilieren (Version 6.18.1): 9:08 Minuten

BIOS

F2 bzw. je nach Tastatur Fn+F2 führt in die BIOS/EFI-Einstellungen. Dort gibt es eine Menge Optionen zur Steuerung des CPU-Lüfters. Der GPU kann ein fixer Speicher (bis zu 96 GiB) zugewiesen werden. Für die meisten Anwendungen ist das aber nicht sinnvoll. Viele Bibliotheken sind in der Lage, den GPU-Speicher dynamisch anzufordern. Insofern ist es zweckmäßig, den fix reservierten GPU-Speicher möglichst klein einzustellen.

Es gibt keine Optionen, die die CPU/GPU-Leistung beeinflussen.

Achtung: Es gibt ein BIOS-Update von Version 0.03.03 auf 0.03.04. Gnome Software bietet das Update zur Installation an. Allerdings bereitet die neue BIOS-Version Probleme und verlangsamt den Boot-Prozess massiv. Das Update sollte daher nicht installiert werden!

Stromverbrauch

Ich habe den Stromverbrauch am Netzstecker mit einem uralten Haushalts-Strommessgerät gemessen. Dessen Genauigkeit ist sicher nicht großartig, aber die Größenordnung meiner Messwerte klingt plausibel: Demnach beträgt die Leistungsaufnahme im Ruhezustand ca. 12 bis 13 Watt (wieder: Fedora mit Gnome Desktop, Energie-Modus ausgeglichen, keine rechenintensiven Vorgänge, BIOS im Grundzustand). Beim Kompilieren des Kernels steigt die Leistung kurz auf 160 Watt und pendelt sich dann ziemlich stabil rund um 140 Watt ein.

Geräuschentwicklung

Der Rechner hat zwei Lüfter: einen großen für die CPU (kann beim Bestellprozess konfiguriert werden, ich habe mich für das etwas teurere Noctua-Modell entschieden) und einen kleinen, der unsichtbar aber unüberhörbar im Netzteil am Boden des Rechners eingebaut ist.

Der CPU-Lüfter läuft standardmäßig nur unter Last und produziert dann ein gut erträgliches Geräusch (mehr Brummen als Surren). Die Steuerung des CPU-Lüfters kann im BIOS verändert werden. Ich habe probeweise einen Dauerbetrieb mit 25 % eingestellt. Der Lüfter bleibt dann für meine Ohren bei knapp einem Meter Abstand immer noch lautlos, sorgt aber für eine stetige leichte Kühlung.

Das Problem ist das äußerst schmale Netzteil, das sich im unteren Teil des Gehäuses befindet. Framework ist auf das Netzteil ziemlich stolz, aber viele Desktop-Besitzer können diese Begeisterung nicht teilen. Ein schier endloser Forum-Thread dokumentiert den Frust über das Netzteil. Im Prinzip ist es einfach:

• Das Netzteil ist komplett gekapselt. Der große CPU-Lüfter kann es daher nicht kühlen.

• Die Luftzufuhr wird durch eine enge Röhre und das Gitter des Gehäuses enorm behindert.

• Das Netzteil ist mit 80 Plus Silver nur mäßig effizient, was sich vermutlich im Leerlaufbetrieb besonders stark auswirkt.

• Im Netzteil steht die Luft. Dieses wird durch die Abwärme immer heißer.

• Ca. 1/2 h nach dem Einschalten wird eine kritische Temperatur erreicht. Nun startet unvermittelt der winzige Lüfter. Eine halbe Minute reicht, um das Netzteil mit frischer Luft etwas abzukühlen — aber nach ca. 10 Minuten beginnt das Spiel von neuem. (Unter Last läuft natürlich auch der Netzteillüfter häufiger.)

Das Geräusch des Netzteil-Lüfters ist leider wesentlich unangenehmer als das des CPU-Lüfters. Der kleine Lüfter hat eine unangenehme Frequenz, und das regelmäßige Ein/Aus stört. Eine BIOS-Steuerung ist nicht vorgesehen. Vermutlich wäre es gescheiter, den Netzteil-Lüfter ständig bei niedriger Frequenz laufen zu lassen, um ohne viel Lärm einen andauernden Luftaustausch zu gewährleisten. Aber diese Möglichkeit besteht nicht.

Um es klar zu stellen: Selbst wenn der Netzteillüfter läuft, ist das Gerät nicht wirklich laut — und vermutlich immer noch leiser als Konkurrenzprodukte (die ich aber nicht ausprobiert habe). Und dass der Computer unter Last nicht lautlos ist, war sowieso zu erwarten.

Ärgerlich ist, dass das Gerät trotz seines ausgezeichneten CPU-Kühler-Designs im Leerlauf bzw. bei geringer Belastung nicht leiser ist. Technisch wäre das möglich. Da wurde rund um das Netzteil viel Potenzial verschenkt.

Fazit

Der Framework Desktop wurde offensichtlich mit viel Liebe zum Detail entwickelt. Der Rechner ist optisch ansprechend und liegt preislich im Vergleich zu seinen Konkurrenzprodukten im Mittelfeld. (Generell ist leider zu befürchten, dass die Preise von Computern in den nächsten Monaten steigen werden, weil sowohl RAM als auch SSDs fast täglich teurer werden.)

Die CPU-Kühlung ist vermutlich die beste aller aktuellen Strix-Halo-Angebote. Bei meinen bisherigen Tests lief der Rechner absolut stabil.

Extrem schade, dass das Netzteil so ein Murks ist. Wenn das Netzteil intelligenter gekühlt würde, wäre im Leerlauf bzw. bei moderater Nutzung ein weitgehend lautloser Betrieb möglich. Stattdessen nervt das Gerät mit einem hochfrequenten Gesurre, das alle paar Minuten startet und eine halbe Minute später wieder aufhört. Ärgerlich!

Quellen/Links

• https://frame.work/at/de/desktop
• https://guides.frame.work/Guide/Framework+Desktop+(AMD+Ryzen+AI+Max+300+Series)+DIY+Edition+%E2%80%93+Kurzanleitung/464
• https://community.frame.work/c/desktop/203
• https://community.frame.work/t/fedora-43-slow-to-boot-update-because-of-system-firmware-3-04/78930

Netzteil

• https://frame.work/at/de/products/desktop-power-supply-400w
• https://frame.work/at/de/blog/framework-desktop-deep-dive-power-supply
• https://community.frame.work/t/noisy-psu-fan/74751/493
• https://community.frame.work/t/exterior-fan-to-solve-the-noisy-psu-fan-problem/76398/37

Andere Geräte

• https://www.bosgamepc.com/products/bosgame-m5-ai-mini-desktop-ryzen-ai-max-395
• https://www.notebookcheck.com/Bester-Mini-PC-des-Jahres-AMD-Strix-Halo-128-GB-RAM-Radeon-RX-8060S-im-Bosgame-M5-getestet.1084304.0.html
• https://www.bee-link.com/de/products/beelink-gtr9-pro-amd-ryzen-ai-max-395
• https://craigwilson.blog/post/2025/2025-09-25-beelink395bsod/ (Bee Link Netzwerkprobleme)
• https://www.notebookcheck.com/HP-Z2-Mini-G1a-mit-AMD-Strix-Halo-im-Test-Kompakte-Workstation-mit-Ryzen-AI-Max-und-Radeon-RX-8060S.1059460.0.html
• https://minisforumpc.eu/de/products/minisforum-ms-s1-max-mini-pc
• https://www.heise.de/bestenlisten/testbericht/minisforum-ms-s1-max-mit-ryzen-ai-max-395-einer-der-staerksten-mini-pcs-im-test/6n5m46y

Seit einigen Jahren ist CentOS kein produktionstauglicher RHEL-Klon mehr. Wer RHEL produktiv nutzen will, aber nicht dafür bezahlen kann, hat die Qual der Wahl: zwischen AlmaLinux, CentOS Stream (nicht für Langzeitnutzung), Oracle Linux, RHEL via Developer Subscription und Rocky Linux. Ich bin ein wenig zufällig im AlmaLinux-Lager gelandet und habe damit über mehrere Jahre, vor allem im Unterricht, ausgezeichnete Erfahrungen gemacht.

Nach diversen Tests mit der Beta-Version läuft AlmaLinux 10 jetzt nativ auf meinem Mini-PC (AMD 8745H), außerdem die aarch64-Variante in einer virtuellen Maschine auf meinem Mac. Dieser Artikel stellt die neue Version AlmaLinux 10 vor, die am 27. Mai 2025 freigegeben wurde, genau eine Woche nach dem Release von RHEL 10. Die meisten Informationen in diesem Artikel gelten auch für RHEL 10 sowie für die restlichen Klone. Oft beziehe ich mich daher im Text auf RHEL (Red Hat Enterprise Linux), also das zugrundeliegende Original. Es gibt aber auch ein paar feine Unterschiede zwischen dem Original und seinen Klonen.

Ich habe vor, diesen Artikel in den nächsten Wochen zu aktualisieren, wenn ich mehr Erfahrungen mit AlmaLinux 10 gemacht habe und es zu Rocky Linux 10 und Oracle Linux 10 weitere Informationen gibt.

Update 8.6.2025: Der MySQL-Server ist per Default weiterhin offen wie ein Scheunentor.

Update 16.6.2025: Zu Rocky Linux 10 gibt es jetzt auch Release Notes.

Update 16.6.2025: Postfix und BDB vs LMDB

Update 27.6.2025: Oracle Linux 10 ist auch verfügbar, ich habe am Ende des Artikels Links zum Oracle-Blog und zu den Release Notes eingebaut

Update 3.7.2025: Im Hetzner-Cloud-Konfigurator können Sie jetzt auch AlmaLinux 10 und Rocky Linux 10 auswählen. Die Netzwerkkonfiguration erfolgt durch /etc/NetworkManager/system-connections/cloud-init-eth0.nmconnection (nicht mehr durch die veralteten Dateien in /etc/syconfig/network-scripts).

Versionsnummern und Paketverwaltung

Basis               Programmierung     Server
---------------     --------------     ---------------
Kernel     6.12     bash       5.2     Apache      2.4
glibc      2.39     gcc       14.2     CUPS        2.4
Wayland    1.23     git       2.47     MySQL       8.4
Gnome        47     Java        21     MariaDB   11.11
Mesa       24.2     PHP        8.3     OpenSSH     9.9
Systemd     257     Podman     5.4     PostgreSQL 16.8
NetworkMan 1.52     Python    3.12     Postfix     3.8
GRUB       2.12     Node.js     22     qemu/KVM    9.1
                                       Samba      4.21

Red Hat hat mit RHEL 10 den X.org-Server aus den Paketquellen entfernt. RHEL setzt damit voll auf Wayland. (Mit XWayland gibt es für X-Client-Programme eine Kompatibilitätsschicht.) Weil RHEL und seine Klone zumeist im Server-Betrieb und ohne grafische Benutzeroberfläche laufen, ist der Abschied von X.org selten ein großes Problem. Einschränkungen können sich aber im Desktop-Betrieb ergeben, vor allem wenn statt Gnome ein anderes Desktop-System eingesetzt werden soll.

Eine Menge wichtiger Desktop-Programme sind aus den regulären Paketquellen verschwunden, unter anderem Gimp und LibreOffice. RHEL empfiehlt, die Programme bei Bedarf aus Flathub zu installieren. Davon abgesehen ist aber kein Wechsel hin zu Flatpaks zu bemerken. flatpak list ist nach einer Desktop-Installation leer.

In der Vergangenheit haben RHEL & Co. von wichtigen Software-Produkten parallel unterschiedliche Versionen ausgeliefert. Dabei setzte RHEL auf das Kommando dnf module. Beispielsweise stellte RHEL 9 Mitte 2025 die PHP-Versionen 8.1, 8.2 und 8.3 zur Auswahl (siehe dnf module list php).

Anscheinend sollen auch in RHEL 10 unterschiedliche Versionen (»AppStreams«) angeboten werden — allerdings nicht mehr in Form von dnf-Modulen. Wie der neue Mechanismus aussieht, habe ich nach dem Studium der Release Notes allerdings nicht verstanden.

Administration und Logging

Wie schon in den vergangenen Versionen setzt RHEL zur Administration auf Cockpit. Die Weboberfläche ist per Default aktiv, nicht durch eine Firewall geschützt und über Port 9090 erreichbar.

Bei einer Desktop-Installation sind standardmäßig rsyslog und das Journal installiert. rsyslog protokolliert wie eh und je in Textdateien in /var/log. Das Journal führt dagegen keine persistente Speicherung durch. Die Logging-Dateien landen in einem temporären Dateisystem in /run/log/journal und verschwinden mit jedem Reboot wieder. Wenn Sie ein dauerhaftes Journal wünschen, führen Sie die folgenden Kommandos aus:

mkdir /var/log/journal

systemctl restart systemd-journald
systemctl restart systemd-journal-flush
systemctl restart systemd-journald.socket

MySQL

Unbegreiflicherweise ist MySQL — jetzt in Version 8.4 — auch in RHEL 10 per Default so konfiguriert, dass jeder Benutzer mit mysql -u root ohne Passwort volle MySQL-Administrationsrechte erhält. Bei Ubuntu erhält per Default nur sudo mysql Admin-Rechte, und bei MariaDB (egal, ob unter Debian, Fedora, RHEL oder Ubuntu) gilt die gleiche Regel. Warum also nicht auch bei RHEL und MySQL?

Wie dem auch sei, das Problem ist nicht neu. Führen Sie also unmittelbar nach der Installation von mysql-server das Kommando mysql_secure_installation aus! Entscheidend ist dabei die Einstellung einen root-Passworts für MySQL.

sudo mysql_secure_installation

  Would you like to setup VALIDATE PASSWORD component? y
  There are three levels of password validation policy:
    LOW    Length >= 8
    MEDIUM Length >= 8, numeric, mixed case, and special characters
    STRONG Length >= 8, numeric, mixed case, special characters, 
           dictionary file
    Please enter 0 = LOW, 1 = MEDIUM and 2 = STRONG: 1
  Please set the password for root here.
    New password: ************
    Re-enter new password: ************
  Disallow root login remotely? y
  Remove test database and access to it? y
  Reload privilege tables now? y

Postfix und BDB versus LMDB

RHEL 10 liefert den Mail-Server Postfix in der Version 3.8 aus. Bei früheren RHEL-Versionen hat Postfix Berkeley Datenbanken (BDB) zur Speicherung von Konfigurationstabellen verwendet. Mit RHEL 10 wird allerdings die libdbd-Bibliotheken aufgrund von Lizenzproblemen nicht mehr mitgeliefert. Postfix verwendet jetzt per Default LMDB-Datenbanken:

grep lmdb /etc/postfix/main.cf

  alias_maps = lmdb:/etc/aliases
  alias_database = lmdb:/etc/aliases
  default_database_type = lmdb

So weit, so gut. Ich bin beim Versuch, einen Postfix-Server einzurichten, allerdings über die Datei /etc/aliases gestolpert. Bisher was es notwendig, nach jeder Änderung in dieser Datei die entsprechende BDB-Datenbank aliases.db mit dem Kommando newaliases neu zu generieren. Genau dieser Hinweis steht auch in der von RHEL ausgelieferten Beispieldatei /etc/aliases. Und erstaunlicherweise funktioniert das Kommando auch unter RHEL 10. newaliases ist über fünf Links mit /usr/sbin/smtpctl aus dem Paket opensmtpd verbunden und scheint weiterhin BDB-Funktionen zu enthalten, Lizenzsorgen hin oder her.

Das Problem ist allerdings, dass Postfix /etc/aliases.db ignoriert und sich stattdessen darüber beklagt, dass es /etc/aliases.lmdb nicht gibt.

journalctl -u postfix

  ... postfix/smtpd[56492]: error: open database /etc/aliases.lmdb: No such file or directory

Ich habe eine Weile gebraucht, bis ich einen Weg gefunden habe, aliases.lmdb zu erzeugen. Das richtige Kommando, das newaliases ersetzt, sieht jetzt so aus:

postalias /etc/aliases

Virtualisierung

Red Hat enthält die üblichen qemu/kvm-Pakete als Basis für den Betrieb virtueller Maschinen. Die Steuerung kann wahlweise auf Kommandoebene (virsh) oder mit der Weboberfläche Cockpit erfolgen.

Das wesentlich komfortablere Programm virt-manager hat Red Hat schon vor Jahren als obsolet bezeichnet, und ich hatte Angst, das Programm wäre mit Version 10 endgültig verschwunden. Aber überraschenderweise gibt es das Paket weiterhin im CodeReady-Builder-Repository:

crb enable
dnf install virt-manager

virt-manager ist aus meiner Sicht die einfachste Oberfläche, um virtuelle Maschinen auf der Basis von QEMU/KVM zu verwalten. Red Hat empfiehlt stattdessen Cockpit (dnf install cockpit-machines), aber dieses Zusatzmodul zur Weboberfläche Cockpit hat mich bisher nicht überzeugen können. Für die Enterprise-Virtualisierung gibt es natürlich auch OpenShift und OpenStack, aber für kleine Lösungen schießen diese Angebote über das Ziel hinaus.

Bereits in RHEL 9 hat Red Hat die Unterstützung für Spice (Simple Protocol for Independent Computing Environments) eingestellt (siehe auch dieses Bugzilla-Ticket). Spice wurde/wird von virt-manager als bevorzugtes Protokoll zur Übertragung des grafischen Desktops verwendet. Die Alternative ist VNC.

Abweichend von RHEL wird Spice von AlmaLinux weiter unterstützt (siehe Release Notes).

EPEL (Extra Packages for Enterprise Linux)

Zu den ersten Aktionen in RHEL 10 oder einem Klon gehört die Aktivierung der EPEL-Paketquelle. In AlmaLinux gelingt das einfach mit dnf install epel-release. Es wird empfohlen, zusammen mit EPEL auch die gerade erwähnte CRB-Paketquelle zu aktivieren.

Die EPEL-10-Paketquelle ist mit schon gut gefüllt. dnf repository-packages epel list | wc -l meldet über 17.000 Pakete! Ein paar Pakete habe ich dennoch vermisst:

• google-authenticator fehlt noch, ist aber in EPEL 10.1 für Fedora schon enthalten, wird also hoffentlich auch für RHEL10 & Klone bald verfügbar sein.

• joe fehlt ebenfalls nicht mehr (Stand 3.7.2025). Ich installiere dieses Editor-Paket gerne, weil es jmacs zur Verfügung stellt, eine minimale Emacs-Variante. Ich bin vorerst auf mg umgestiegen, es entspricht meinen Ansprüchen ebenfalls. (Ich bin kein vi-Fan, und nano ist mir ein bisschen zu minimalistisch. Den »richtigen« Emacs brauche ich aber auch nicht, um zwei Zeilen in /etc/hosts zu ändern.)

AlmaLinux in der Hetzner-Cloud

Hetzner bietet mittlerweile vorkonfigurierte Cloud-Instanzen für AlmaLinux 10 und RockyLinux 10 an. Die einzige wesentliche Neuerung, die mir aufgefallen ist, betrifft die Netzwerkkonfiguration. Während Hetzner bis Version 9 auf die eigentlich dort schon veralteten Dateien in /etc/sysconfig/network-scripts gesetzt hat, kümmert sich jetzt eine NetworkManager-Datei um die Konfiguration. Beispiel:

cat /etc/NetworkManager/system-connections/cloud-init-eth0.nmconnection

# Generated by cloud-init. Changes will be lost.
[connection]
id=cloud-init eth0
uuid=1dd9a779-d327-56e1-8454-c65e2556c12c
autoconnect-priority=120
type=ethernet

[user]
org.freedesktop.NetworkManager.origin=cloud-init

[ethernet]
mac-address=96:00:04:6E:A0:A0

[ipv4]
method=auto
may-fail=false

[ipv6]
method=manual
may-fail=false
address1=2a01:4f8:1c17:53db::1/64
gateway=fe80::1
dns=2a01:4ff:ff00::add:1;2a01:4ff:ff00::add:2;

AlmaLinux versus Original (RHEL)

Im Wesentlichen verwendet AlmaLinux den gleichen Quellcode wie RHEL und ist zu diesem vollständig kompatibel. Es gibt aber ein paar feine Unterschiede:

• Seit RHEL den Zugang zum Quellcodes für die Updates erschwert hat (siehe Ärger für Red-Hat-Klone und Red Hat und die Parasiten), greift AlmaLinux auch auf den Upstream-Quellcode einzelner Projekte zu, führt Bugfixes/Sicherheits-Updates zum Teil früher durch als RHEL und besteht nicht mehr auf eine vollständige Bit-für-Bit- und Bug-für-Bug-Kompatibilität. Im Detail ist diese Strategie und das Ausmaß der Kompatibilität hier dokumentiert.

• Red Hat hat RHEL 10 für x86_v3 kompiliert, unterstützt damit nur relativ moderne Intel- und AMD-CPUs. Deswegen läuft RHEL 10 auf älteren Computern nicht mehr! Alma Linux macht es ebenso, bietet aber darüber hinaus eine v2-Variante an und unterstützt damit auch ältere Hardware. Die Mikroarchitektur-Unterschiede zwischen v2 und v3 sind z.B. in der Wikipedia sowie auf infotechys.com beschrieben. Das v2-Angebot umfasst auch die EPEL-Paketquelle.

• Der Verzicht auf Bit-für-Bit-Kompatibilität gibt AlmaLinux die Möglichkeit, sich in einigen Details vom Original abzuheben. Das betrifft unter anderem die Unterstützung von Frame Pointers als Debugging-Hilfe sowie die fortgesetzte Unterstützung des Protokolls Spice,

AlmaLinux vs RockyLinux und Oracle Linux

In der Vergangenheit waren alle Klone praktisch gleich. Nun gut, Oracle hat immer einen eigenen »unbreakable« Kernel angeboten, aber davon abgesehen war das gesamte Paketangebot Bit für Bit kompatibel zum Original, kompiliert aus den gleichen Quellen. Die Extrapakete aus der EPEL-Quelle sind sowieso für das Original und seine Klone ident.

Seit Red Hat 2023 den Zugriff auf den Source-Code aller Updates eingeschränkt bzw. deutlich weniger unbequemer gemacht hat, haben sich AlmaLinux auf der einen und Rocky Linux und Oracle Linux auf der anderen Seite ein wenig auseinander entwickelt. AlmaLinux hat den Anspruch auf Bit-für-Bit-Kompatibilität aufgegeben (siehe oben). Rocky Linux und Oracle Linux beziehen den Quellcode für Updates hingegen nun aus anderen öffentlichen Quellen, unter anderem aus Cloud- und Container-Systemen (Quelle).

RHEL Developer

Für Entwickler macht Red Hat mit dem Red Hat Developer eigentlich ein attraktives Angebot. Nach einer Registrierung gibt es 16 freie Lizenzen für Tests und Entwicklungsarbeit. Ich habe einen entsprechenden Account, habe RHEL 10 installiert und registriert, bin aber dennoch nicht in der Lage, die Paketquellen zu aktivieren. Vielleicht bin ich zu blöd, vielleicht wird RHEL 10 noch nicht unterstützt (diesbezüglich fehlt klare Dokumentation) — ich weiß es nicht. Ich habe es ein paar Stunden probiert, und ich werde es in ein paar Wochen wieder versuchen. Vorerst fehlt mir dazu aber die Zeit und der Nerv.

Quellen und Links

AlmaLinux Release Notes und Dokumentation

• https://almalinux.org/blog/2025-05-27-welcoming-almalinux-10
• https://wiki.almalinux.org/release-notes/10.0.html
• https://almalinux.org/blog/future-of-almalinux/

Rocky Linux Release Notes

• https://docs.rockylinux.org/release_notes/10_0/

Red Hat Release Notes und Dokumentation

• https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/10.0_release_notes/index
• https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html-single/considerations_in_adopting_rhel_10/index
• https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/configuring_and_managing_windows_virtual_machines/index
• https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html-single/considerations_in_adopting_rhel_10/index
• https://bugzilla.redhat.com/show_bug.cgi?id=2030592
• https://developers.redhat.com/

Oracle Linux Release Notes

• https://blogs.oracle.com/linux/post/oracle-linux-10-now-generally-available
• https://docs.oracle.com/en/operating-systems/oracle-linux/10/relnotes10.0/
• https://docs.oracle.com/en/operating-systems/oracle-linux/10/

Berkeley Databases (BDB)

• https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html-single/10.0_release_notes/index#removed-features-infrastructure-services
• https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html-single/considerations_in_adopting_rhel_10/index
• https://gitlab.archlinux.org/archlinux/packaging/packages/postfix/-/blob/main/postfix.install?ref_type=heads#L10

Andere Test- und News-Berichte

• https://www.heise.de/news/Nun-offiziell-RHEL-10-ist-da-mit-KI-fuer-Admins-10392007.html

Frühere eigene Blog-Artikel

• https://kofler.info/nachruf-auf-centos/
• https://kofler.info/almalinux-9/
• https://kofler.info/aerger-fuer-red-hat-klone/
• https://kofler.info/kommentar-red-hat-und-die-parasiten/

Sonstiges

• https://infotechys.com/x86-64-v3-architecture
• https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels

Dies ist der Folgeartikel, den ich in der Einführung in das Advanced Intrusion Detection Environment (AIDE) versprochen hatte. Es handelt sich hierbei um einen Proof of Concept (PoC), der zeigt, wie AIDE mithilfe einer Ansible-Rolle ferngesteuert werden kann. Die Einführung wird als bekannt vorausgesetzt.

Grundlegende Ansible-Kenntnisse, wie die Verwendung von Ansible-Rollen und das Ausführen von Playbooks werden ebenfalls als bekannt vorausgesetzt. Wer Ansible nicht kennt, sei an die offizielle Dokumentation verwiesen.

Welche Aufgaben sind mit Ansible zu lösen?

• Das Paket aide ist auf den Zielsystemen installiert
• Die optionale Generierung und Verteilung der Konfigurationsdatei aide.conf
• Die Initialisierung der AIDE-Datenbank
• Zentrale Speicherung der AIDE-Datenbanken aller verwalteter Hosts auf dem Ansible Control Node (ACN)
• Durchführung von Integritäts-Checks
• Aktualisierung der AIDE-Datenbanken und erneute Speicherung auf dem ACN

Durch die Speicherung der AIDE-Datenbanken und -Konfigurationsdateien auf dem ACN sind diese gegen Veränderung auf einem kompromittierten Host geschützt. Gegen Veränderungen auf dem ACN selbst sind die Dateien nur mit Unix-Dateiberechtigungen geschützt. Doch wenn der ACN kompromittiert ist, hat man eh ein ganz anderes Problem, als sich um AIDE Sorgen zu machen.

Labor-Umgebung

Meine Labor-Umgebung für diesen PoC besteht aus den vier Hosts:

• ansible-ctrl (RHEL 8 mit installiertem ansible-core)
• rhel7
• rhel8
• rhel9

Der ACN kann sich via SSH zu den Zielsystemen (rhel{7,8,9}) verbinden und dort Programmcode mit erhöhten Rechten ausführen.

Die von mir für diesen PoC entwickelte Ansible-Rolle gibt es unter der URL: https://github.com/Tronde/aide

Beschreibung der Ansible-Rolle aide

Die Rolle ist nicht idempotent. Sie ruft das Programm aide auf den Zielsystemen mit verschiedenen Optionen auf und verarbeitet deren Ausgabe. Dazu macht die Rolle Gebrauch des Moduls ansible.builtin.command.

Gesteuert wird die Rolle über Ansible-Tags. Wird die Rolle in einem Playbook ohne Angabe von Tags ausgeführt, werden keinerlei Veränderungen an den Zielsystemen vorgenommen.

Der folgende Code-Block zeigt ein Beispiel-Playbook zum Aufruf der Rolle. Die Tags und die Variable aide_db_fetch_dir werden im Anschluss erläutert.

# SPDX-License-Identifier: MIT
---
- name: Example aide role invocation
  hosts: targets
  tasks:
    - name: Include role aide
      tags:
        - install
        - generate_config
        - init
        - check
        - update
      vars:
        aide_db_fetch_dir: files
      ansible.builtin.include_role:
        name: aide

• install – Bei Angabe dieses Tags stellt die Rolle sicher, dass das Paket aide auf den Zielsystemen installiert ist
• generate_config – Generiert die Datei /etc/aide.conf unter Nutzung von templates/aide.conf.j2; das Template ist an die individuellen Bedürfnisse anzupassen; Details siehe nächster Abschnitt
• init – Hiermit wird die AIDE-Datenbank initialisiert, welche als Referenzdatenbank für zukünftige Checks dient
• check – Führt einen Integritäts-Check unter Verwendung der Referenzdatenbank durch
• update – Führt einen Integritäts-Check durch und erzeugt eine neue AIDE-Datenbank, welche zukünftig als Referenz dient

Die Variable aide_db_fetch_dir erwartet im Auslieferungszustand das Verzeichnis files parallel zum Playbook. In diesem Verzeichnis werden Unterverzeichnisse für jeden Host erstellt, in denen die AIDE-Datenbank der verwalteten Systeme gespeichert wird. Soll ein anderer Speicherort verwendet werden, ist der Wert dieser Variablen entsprechend anzupassen. Die AIDE-Datenbanken werden mit dem Ansible-Module ansible.builtin.fetch von den verwalteten Systemen geholt.

Nutzung für die verschiedenen Anwendungsfälle

In diesem Abschnitt beschreibe ich die fünf Anwendungsfälle für den PoC. Alle Anwendungsfälle wurden gegen RHEL 7, RHEL 8 und RHEL 9 getestet. Für diesen Blog beschränke ich mich jedoch auf Tests gegen RHEL 9, um die Übersichtlichkeit der Ausgaben zu verbessern.

Es wird stets das Playbook aus dem Abschnitt Beschreibung der Ansible-Rolle aide verwendet und mit unterschiedlichen Tags ausgeführt.

Anwendungsfall 1: Installation von AIDE

Um AIDE nutzen zu können, muss es zuerst installiert sein. Dies wird mit folgendem Playbook-Aufruf festgestellt:

[root@ansible-ctrl ansible]# ansible-playbook aide.yml --tags install

PLAY [Example aide role invocation] ********************************************

TASK [Gathering Facts] *********************************************************
ok: [rhel9]

TASK [Include role aide] *******************************************************

TASK [aide : Ensure required packages are installed] ***************************
changed: [rhel9]

PLAY RECAP *********************************************************************
rhel9                      : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Für diesen Anwendungsfall arbeitet die Rolle idempotent. Bei einer zweiten Ausführung werden keine weiteren Änderungen am System vorgenommen:

[root@ansible-ctrl ansible]# ansible-playbook aide.yml --tags install

PLAY [Example aide role invocation] ********************************************

TASK [Gathering Facts] *********************************************************
ok: [rhel9]

TASK [Include role aide] *******************************************************

TASK [aide : Ensure required packages are installed] ***************************
ok: [rhel9]

PLAY RECAP *********************************************************************
rhel9                      : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Anwendungsfall 2: Generierung der Datei /etc/aide.conf

Zusammen mit der Rolle wird die Datei templates/aide.conf.j2 ausgeliefert. Dabei handelt es sich um die Standardkonfigurationsdatei aus einer RHEL9-Installation, in welcher zusätzlich der Pfad /root/.ansible* von der Überwachung ausgenommen wurde, um falsch positive Ergebnisse zu vermeiden.

Diese Datei ist an die individuellen Bedürfnisse anzupassen. Wer Hilfe zum Templating mit Jinja2 benötigt, findet in der Ansible-Dokumentation einen Einstieg.

Ausgerollt wird die Konfigurationsdatei dann wie folgt:

[root@ansible-ctrl ansible]# ansible-playbook aide.yml --tags generate_config

PLAY [Example aide role invocation] ********************************************

TASK [Gathering Facts] *********************************************************
ok: [rhel9]

TASK [Include role aide] *******************************************************

TASK [aide : Generate /etc/aide.conf] ******************************************
changed: [rhel9]

PLAY RECAP *********************************************************************
rhel9                      : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Auch mit diesem Tag arbeitet die Rolle idempotent.

Wird dieser Schritt ausgelassen, wird in allen folgenden Anwendungsfällen die Standardkonfigurationsdatei verwendet, welche bei der Installation des Pakets aide mitinstalliert wurde.

Anwendungsfall 3: Initialisierung der AIDE-Datenbank

Um Integritäts-Checks durchführen zu können, muss zuerst die AIDE-Datenbank initialisiert werden. Dies geschieht mit dem folgenden Aufruf:

[root@ansible-ctrl ansible]# ansible-playbook aide.yml --tags init

PLAY [Example aide role invocation] ********************************************

TASK [Gathering Facts] *********************************************************
ok: [rhel9]

TASK [Include role aide] *******************************************************

TASK [aide : Initialize AIDE database] *****************************************
changed: [rhel9]

TASK [aide : Fetch AIDE database] **********************************************
changed: [rhel9]

TASK [aide : Remove remote AIDE database file] *********************************
changed: [rhel9]

PLAY RECAP *********************************************************************
rhel9                      : ok=4    changed=3    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Nach der Initialisierung der AIDE-Datenbank wird diese auf den ACN kopiert und von den verwalteten Systemen entfernt. Dies hat den Hintergrund, dass es sich beim ACN um ein sehr gut gesichertes System handelt und die Datenbanken hier am besten vor einer Kompromittierung geschützt sind.

Wird der Standardwert der Variable aide_db_fetch_dir verwendet, findet sich die AIDE-Datenbank jetzt im Pfad files/rhel9/var/lib/aide/aide.db.new.gz. Dabei entspricht rhel9 in der Pfadangabe dem inventory_hostname des jeweiligen Zielsystems.

Dieser Teil der Rolle ist nicht idempotent. Wird das Playbook erneut ausgeführt, wird eine neue AIDE-Datenbank erstellt, auf den ACN heruntergeladen und vom Zielsystem gelöscht.

Anwendungsfall 4: Ausführung einer Integritätsprüfung

Der nun folgende Code-Block zeigt den Playbook-Aufruf zur Integritätsprüfung. Hier wird zuerst die AIDE-Datenbank auf das Zielsystem kopiert, anschließend ein AIDE-Check ausgeführt. Da im folgenden Beispiel keine Änderungen detektiert wurden, besitzt der Task „[aide : Check against AIDE reference database]“ den Status „ok“.

[root@ansible-ctrl ansible]# ansible-playbook aide.yml --tags check

PLAY [Example aide role invocation] ********************************************

TASK [Gathering Facts] *********************************************************
ok: [rhel9]

TASK [Include role aide] *******************************************************

TASK [aide : Copy AIDE reference database to remote] ***************************
changed: [rhel9]

TASK [aide : Check against AIDE reference database] ****************************
ok: [rhel9]

PLAY RECAP *********************************************************************
rhel9                      : ok=3    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Dieser Teil der Rolle ist nicht idempotent. Bei jedem Aufruf wird ein neuer Integritäts-Check ausgeführt.

Ich habe die Datei /etc/hosts auf dem Zielsystem manipuliert, um auch den Fall zu zeigen, wenn eine Änderung erkannt wurde.

Zu Beginn der folgenden Ausgabe ist zu erkennen, dass der Task „[aide : Copy AIDE reference database to remote]“ den Status „ok“ besitzt. Ansible hat erkannt, dass die AIDE-Datenbank bereits in unverändertem Zustand auf dem Zielsystem existiert, und hat sie deshalb nicht erneut übertragen. Der Task „[aide : Check against AIDE reference database]“ schlägt nun allerdings fehl (Status: „fatal“), da Veränderungen erkannt wurden. Die zugegeben etwas unübersichtliche Ausgabe enthält die Nachricht, dass die Datei /etc/hosts verändert wurde.

[root@ansible-ctrl ansible]# ansible-playbook aide.yml --tags check

PLAY [Example aide role invocation] ********************************************

TASK [Gathering Facts] *********************************************************
ok: [rhel9]

TASK [Include role aide] *******************************************************

TASK [aide : Copy AIDE reference database to remote] ***************************
ok: [rhel9]

TASK [aide : Check against AIDE reference database] ****************************
fatal: [rhel9]: FAILED! => {"changed": true, "cmd": ["aide", "--check"], "delta": "0:00:27.177397", "end": "2024-03-29 05:16:50.682795", "msg": "non-zero return code", "rc": 4, "start": "2024-03-29 05:16:23.505398", "stderr": "", "stderr_lines": [], "stdout": "Start timestamp: 2024-03-29 05:16:23 -0400 (AIDE 0.16)\nAIDE found differences between database and filesystem!!\n\nSummary:\n  Total number of entries:\t45541\n  Added entries:\t\t0\n  Removed entries:\t\t0\n  Changed entries:\t\t1\n\n---------------------------------------------------\nChanged entries:\n---------------------------------------------------\n\nf   ...    .C... : /etc/hosts\n\n---------------------------------------------------\nDetailed information about changes:\n---------------------------------------------------\n\nFile: /etc/hosts\n  SHA512   : YobgpcvAMPey0QX1lK4K+5EFySF1xrB/ | 7nIivvNa5ozfhOqSFLmPIiu6g04Wbx1n\n             9FRzTCPNC93+13Y5/lm2inC4x4rydlf2 | iGNf0/QTgFjaMGug8HywxTiO2PREZRNS\n             EcvonCf3pHuXj6lEmAjBnw==         | 3qNEi4Qm6an5inSY72sjfA==\n\n\n---------------------------------------------------\nThe attributes of the (uncompressed) database(s):\n---------------------------------------------------\n\n/var/lib/aide/aide.db.gz\n  MD5      : gMgRyMOExVAdOAvdgt4QDA==\n  SHA1     : w7tmPKNvRYggY/JZ5wv+7ZdcSZM=\n  RMD160   : CO0pK5tfg66MaO17YB8eaRuyyMw=\n  TIGER    : n8UbZJNt9gL672+pR9IPjoyhpAsUJ46O\n  SHA256   : k8UHnv2CK4zYrfZN+bDp6SCcLkx21px6\n             GNZlwySPKcY=\n  SHA512   : DFw5wlBoJQOBCrs0ulvVxaMvoQk/oBEQ\n             TkOmhfHAdevUWNAgCJ0KH0q26LsynEMj\n             MWQpsGf7v12iACc4SP9ANA==\n\n\nEnd timestamp: 2024-03-29 05:16:50 -0400 (run time: 0m 27s)", "stdout_lines": ["Start timestamp: 2024-03-29 05:16:23 -0400 (AIDE 0.16)", "AIDE found differences between database and filesystem!!", "", "Summary:", "  Total number of entries:\t45541", "  Added entries:\t\t0", "  Removed entries:\t\t0", "  Changed entries:\t\t1", "", "---------------------------------------------------", "Changed entries:", "---------------------------------------------------", "", "f   ...    .C... : /etc/hosts", "", "---------------------------------------------------", "Detailed information about changes:", "---------------------------------------------------", "", "File: /etc/hosts", "  SHA512   : YobgpcvAMPey0QX1lK4K+5EFySF1xrB/ | 7nIivvNa5ozfhOqSFLmPIiu6g04Wbx1n", "             9FRzTCPNC93+13Y5/lm2inC4x4rydlf2 | iGNf0/QTgFjaMGug8HywxTiO2PREZRNS", "             EcvonCf3pHuXj6lEmAjBnw==         | 3qNEi4Qm6an5inSY72sjfA==", "", "", "---------------------------------------------------", "The attributes of the (uncompressed) database(s):", "---------------------------------------------------", "", "/var/lib/aide/aide.db.gz", "  MD5      : gMgRyMOExVAdOAvdgt4QDA==", "  SHA1     : w7tmPKNvRYggY/JZ5wv+7ZdcSZM=", "  RMD160   : CO0pK5tfg66MaO17YB8eaRuyyMw=", "  TIGER    : n8UbZJNt9gL672+pR9IPjoyhpAsUJ46O", "  SHA256   : k8UHnv2CK4zYrfZN+bDp6SCcLkx21px6", "             GNZlwySPKcY=", "  SHA512   : DFw5wlBoJQOBCrs0ulvVxaMvoQk/oBEQ", "             TkOmhfHAdevUWNAgCJ0KH0q26LsynEMj", "             MWQpsGf7v12iACc4SP9ANA==", "", "", "End timestamp: 2024-03-29 05:16:50 -0400 (run time: 0m 27s)"]}

PLAY RECAP *********************************************************************
rhel9                      : ok=2    changed=0    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0

An dieser Stelle wurde gezeigt, dass sowohl unveränderte Systeme als auch Systeme mit Veränderungen erkannt und gemeldet werden. Dabei muss natürlich niemand die Standardausgabe beobachten. Stattdessen kann Logging für Ansible Ausgaben konfiguriert werden.

Anwendungsfall 5: Update der AIDE-Datenbank

Dieser Anwendungsfall nimmt an, dass erfolgte Änderungen legitim sind und in die AIDE-Referenzdatenbank aufgenommen werden sollen. Dies geschieht wie folgt:

[root@ansible-ctrl ansible]# ansible-playbook aide.yml --tags update

PLAY [Example aide role invocation] ********************************************

TASK [Gathering Facts] *********************************************************
ok: [rhel9]

TASK [Include role aide] *******************************************************

TASK [aide : Update AIDE database] *********************************************
changed: [rhel9]

TASK [aide : Fetch AIDE database] **********************************************
changed: [rhel9]

TASK [aide : Remove remote AIDE database file] *********************************
changed: [rhel9]

PLAY RECAP *********************************************************************
rhel9                      : ok=4    changed=3    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Nachdem die Referenzdatenbank aktualisiert wurde, wird diese wieder auf den ACN kopiert und vom Zielsystem entfernt.

Das folgende Beispiel zeigt, dass auf dem Zielsystem der AIDE-Check nun ohne Fehler absolviert wird:

[root@ansible-ctrl ansible]# ansible-playbook aide.yml --tags check

PLAY [Example aide role invocation] ********************************************

TASK [Gathering Facts] *********************************************************
ok: [rhel9]

TASK [Include role aide] *******************************************************

TASK [aide : Copy AIDE reference database to remote] ***************************
changed: [rhel9]

TASK [aide : Check against AIDE reference database] ****************************
ok: [rhel9]

PLAY RECAP *********************************************************************
rhel9                      : ok=3    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Ansible hat erkannt, dass die AIDE-Datenbank auf dem Zielhost nicht mit der aktuellen Referenzdatenbank übereinstimmt und hat letztere daher auf das Zielsystem übertragen. Die Überprüfung endet mit dem Status „ok“. Das System entspricht dem Soll-Zustand.

Zusammenfassung

Der Proof of Concept hat gezeigt, dass AIDE mit der verwendeten Ansible-Rolle ferngesteuert genutzt werden kann. AIDE-Datenbank und Konfigurationsdatei werden dabei getrennt von den verwalteten Systemen gespeichert und sind daher gegen Veränderung bei Kompromittierung der Zielsysteme geschützt. Bei Bedarf, wenn Ansible Abweichungen des Ist- zum Soll-Zustand erkennt, werden diese Dateien auf die Zielsysteme übertragen.

Der größte Arbeitsaufwand steckt in der Erstellung einer oder mehrerer AIDE-Konfigurationsdateien, die optimal zur eigenen Umgebung passen und möglichst keine falsch positiven Ergebnisse erzeugen. Dieser Aufwand besteht jedoch auch, wenn man AIDE ohne Ansible einsetzt.

Einen Punkt hat dieser PoC unberücksichtigt gelassen. Es nützt natürlich nichts, wenn man die Ausgaben der Playbooks nur protokolliert, die Protokolle jedoch nicht analysiert, um entsprechende Alarme in Monitoring- oder Ticket-Systemen zu erzeugen. Dies sei den Anwendern zur selbstständigen Übung überlassen. ;-)

Die Aufgabenstellung ist sehr speziell, und dementsprechend wird dieser Beitrag vermutlich nur wenig Leute interessieren. Aber egal: Ich habe mich drei Tage damit geärgert, vielleicht profitieren ein paar Leser von meinen Erfahrungen …

Die Zielsetzung ist bereits in der Überschrift beschrieben. Ich besitze einen Mini-PC mit AMD 8745H-CPU und 32 GiB RAM. Die CPU enthält auch eine integrierte GPU (Radeon 780M). Auf diesem Rechner wollte ich das momentan sehr beliebte Sprachmodell gpt-oss-20b ausführen. Dieses Sprachmodell ist ca. 11 GiB groß, umfasst 20 Milliarden Parameter in einer etwas exotischen Quantifizierung. (MXFP4 wurde erst 2024 standardisiert und bildet jeden Parameter mit nur 4 Bit ab. Die Besonderheit besteht darin, dass für unterschiedliche Teile des Modells unterschiedliche Skalierungsfaktoren verwendet werden, so dass die Parameter trotz der wenigen möglichen Werte einigermaßen exakt abgebildet werden können.)

Das Sprachmodell wird von der Firma OpenAI kostenlos angeboten. Die Firma gibt an, dass die 20b-Variante ähnlich gute Ergebnisse wie das bis 2024 eingesetzt kommerzielle Modell o3-mini liefert, und auch KI-Experte Simon Willison singt wahre Lobeshymnen auf das Modell.

PS: Ich habe alle Tests unter Fedora 42 durchgeführt.

Warum nicht Ollama?

Für alle, die nicht ganz tief in die lokale Ausführung von Sprachmodellen eintauchen wollen, ist Ollama zumeist die erste Wahl. Egal, ob unter Windows, Linux oder macOS, viele gängige Sprachmodelle können damit unkompliziert ausgeführt werden, in der Regel mit GPU-Unterstützung (macOS, Windows/Linux mit NVIDIA-GPU bzw. mit ausgewählten AMD-GPUs).

Bei meiner Hardware — und ganz allgemein bei Rechnern mit einer AMD-iGPU — ist Ollama aktuell aber NICHT die erste Wahl:

ROCm: Ollama setzt bei NVIDIA-GPUs auf das Framework CUDA (gut), bei AMD-GPUs auf das Framework ROCm (schlecht). Dieses Framework reicht alleine vermutlich als Grund, warum AMD so chancenlos gegen NVIDIA ist. Im konkreten Fall besteht das Problem darin, dass die iGPU 780M (interner ID gfx1103) offiziell nicht unterstützt wird. Die Empfehlung lautet, ROCm per Umgebungsvariable zu überzeugen, dass die eigene GPU kompatibel zu einem anderen Modell ist (HSA_OVERRIDE_GFX_VERSION=11.0.2). Tatsächlich können Sprachmodelle dann ausgeführt werden, aber bei jeder Instabilität (derer es VIELE gibt), stellt sich die Frage, ob nicht genau dieser Hack der Anfang aller Probleme ist.

Speicherverwaltung: Auch mit diesem Hack scheitert Ollama plus ROCm-Framework an der Speicherverwaltung. Bei AMD-iGPUs gibt es zwei Speicherbereiche: fix per BIOS allozierten VRAM sowie dynamisch zwischen CPU + GPU geteiltem GTT-Speicher. (Physikalisch ist der Speicher immer im RAM, den sich CPU und GPU teilen. Es geht hier ausschließlich um die Speicherverwaltung durch den Kernel + Grafiktreiber.)

Ollama alloziert zwar den GTT-Speicher, aber maximal so viel, wie VRAM zur Verfügung steht. Diese (Un)Logik ist am besten anhand von zwei Beispielen zu verstehen. Auf meinem Testrechner habe ich 32 GiB RAM. Standardmäßig reserviert das BIOS 2 GiB VRAM. Der Kernel markiert dann 14 GiB als GTT. (Das kann bei Bedarf mit den Kerneloptionen amdttm.pages_limit und amdttm.page_pool_size verändert werden.) Obwohl mehr als genug Speicher zur Verfügung steht, sieht Ollama eine Grenze von 2 GiB und kann nur winzige LLMs per GPU ausführen.

Nun habe ich im BIOS das VRAM auf 16 GiB erhöht. Ollama verwendet nun 16 GiB als Grenze (gut), nutzt aber nicht das VRAM, sondern den GTT-Speicher (schlecht). Wenn ich nun ein 8 GiB großes LLM mit Ollama ausführen, dann bleiben fast 16 GiB VRAM ungenutzt! Ollama verwendet 8 GiB GTT-Speicher, und für Ihr Linux-System bleiben gerade einmal 8 GiB RAM übrig. Es ist zum aus der Haut fahren! Im Internet gibt es diverse Fehlerberichte zu diesem Problem und sogar einen schon recht alten Pull-Request mit einem Vorschlag zur Behebung des Problems. Eine Lösung ist aber nicht Sicht.

Ich habe mich mehrere Tage mit Ollama geärgert. Schade um die Zeit. (Laut Internet-Berichten gelten die hier beschriebenen Probleme auch für die gehypte Strix-Halo-CPU.)

Next Stop: llama.cpp

Etwas Internet-Recherche liefert den Tipp, anstelle von Ollama das zugrundeliegende Framework llama.cpp eben direkt zu verwenden. Ollama greift zwar selbst auf llama.cpp zurück, aber die direkte Verwendung von llama.cpp bietet andere GPU-Optionen. Dieser Low-Level-Ansatz ist vor allem bei der Modellauswahl etwas umständlicher. Zwei Vorteile können den Zusatzaufwand aber rechtfertigen:

• Die neuste Version von llama.cpp unterstützt oft ganz neue Modelle, mit denen Ollama noch nicht zurechtkommt.

• llama.cpp kann die GPU auf vielfältigere Weise nutzen als Ollama. Je nach Hardware und Treiber kann so eventuell eine höhere Geschwindigkeit erzielt bzw. der GPU-Speicher besser genutzt werden, um größere Modelle auszuführen.

Die GitHub-Projektseite beschreibt mehrere Installationsvarianten: Sie können llama.cpp selbst kompilieren, den Paketmanager nix verwenden, als Docker-Container ausführen oder fertige Binärpakete herunterladen (https://github.com/ggml-org/llama.cpp/releases). Ich habe den einfachsten Weg beschritten und mich für die letzte Option entschieden. Der Linux-Download enthält genau die llama.cpp-Variante, die für mich am interessantesten war — jene mit Vulkan-Unterstützung. (Vulkan ist eine 3D-Grafikbibliothek, die von den meisten GPU-Treibern unter Linux durch das Mesa-Projekt gut unterstützt wird.) Die Linux-Version von llama.cpp wird anscheinend unter Ubuntu kompiliert und getestet, dementsprechend heißt der Download-Name llama-<version>-bin-ubuntu-vulkan-x86.zip. Trotz dieser Ubuntu-Affinität ließen sich die Dateien bei meinen Tests aber problemlos unter Fedora 42 verwenden.

Nach dem Download packen Sie die ZIP-Datei aus. Die resultierenden Dateien landen im Unterverzeichnis build/bin. Es bleibt Ihnen überlassen, ob Sie die diversen llama-xxx-Kommandos direkt in diesem Verzeichnis ausführen, das Verzeichnis zu PATH hinzufügen oder seinen Inhalt in ein anderes Verzeichnis kopieren (z.B. nach /usr/local/bin).

cd Downloads
unzip llama-b6409-bin-ubuntu-vulkan-x64.zip
cd build/bin
./llama-cli --version

  loaded RPC backend from ./build/bin/libggml-rpc.so
  ggml_vulkan: Found 1 Vulkan devices:
  ggml_vulkan: 0 = AMD Radeon 780M Graphics (RADV PHOENIX) (radv) ...
  loaded Vulkan backend from ./build/bin/libggml-vulkan.so
  loaded CPU backend from ./build/bin/libggml-cpu-icelake.so
  version: 6409 (d413dca0)
  built with cc (Ubuntu 11.4.0-1ubuntu1~22.04.2) for x86_64-linux-gnu

Für die GPU-Unterstützung ist entscheidend, dass auf Ihrem Rechner die Bibliotheken für die 3D-Bibliothek Vulkan installiert sind. Davon überzeugen Sie sich am einfachsten mit vulkaninfo aus dem Paket vulkan-tools. Das Kommando liefert fast 4000 Zeilen Detailinformationen. Mit einem Blick in die ersten Zeilen stellen Sie fest, ob Ihre GPU unterstützt wird.

vulkaninfo | less

  Vulkan Instance Version: 1.4.313
  Instance Extensions: count = 24
    VK_EXT_acquire_drm_display  : extension revision 1
    VK_EXT_acquire_xlib_display : extension revision 1
    ...
  Layers: count = 1
     VK_LAYER_MESA_device_select
     Devices: count = 2
       GPU id = 0 (AMD Radeon 780M Graphics (RADV PHOENIX))
       GPU id = 1 (llvmpipe (LLVM 20.1.8, 256 bits))
  ...

Erste Tests

Um llama.cpp auszuprobieren, brauchen Sie ein Modell. Bereits für Ollama heruntergeladene Modelle sind leider ungeeignet. llama.cpp erwartet Modelle als GGUF-Dateien (GPT-Generated Unified Format). Um die Ergebnisse mit anderen Tools leicht vergleichen zu können, verwende ich als ersten Testkandidat immer Llama 3. Eine llama-taugliche GGUF-Variante von Llama 3.1 mit 8 Milliarden Parametern finden Sie auf der HuggingFace-Website unter dem Namen bartowski/Meta-Llama-3.1-8B-Instruct-GGUF:Q4_K_M.

Das folgende Kommando lädt das Modell von HuggingFace herunter (Option -hf), speichert es im Verzeichnis .cache/llama.cpp, lädt es, führt den als Parameter -p angegebenen Prompt aus und beendet die Ausführung dann. In diesem und allen weiteren Beispielen gehe ich davon aus, dass sich die llama-Kommandos in einem PATH-Verzeichnis befinden. Alle Ausgaben sind aus Platzgründen stark gekürzt.

llama-cli -hf bartowski/Meta-Llama-3.1-8B-Instruct-GGUF:Q4_K_M \
  -p 'bash/Linux: explain the usage of rsync over ssh'

  ... (diverse Debugging-Ausgaben)
  Running in interactive mode.
  - Press Ctrl+C to interject at any time.
  - Press Return to return control to the AI.
  - To return control without starting a new line, end your input with '/'.
  - If you want to submit another line, end your input with '\'.
  - Not using system message. To change it, set a different value via -sys PROMPT

> bash/Linux: explain the usage of rsync over ssh

  rsync is a powerful command-line utility that enables you to 
  synchronize files and directories between two locations. Here's 
  a breakdown of how to use rsync over ssh: ...

> <Strg>+<D>

         load time =  2231.02 ms
  prompt eval time =   922.83 ms /  43 tokens (46.60 tokens per second)
         eval time = 31458.46 ms / 525 runs   (16.69 tokens per second)

Sie können llama-cli mit diversen Optionen beeinflussen, z.B. um verschiedene Rechenparameter einzustellen, die Länge der Antwort zu limitieren, den Systemprompt zu verändern usw. Eine Referenz gibt llama-cli --help. Deutlich lesefreundlicher ist die folgende Seite:

https://github.com/ggml-org/llama.cpp/discussions/15709

Mit llama-bench können Sie diverse Benchmark-Tests durchführen. Im einfachsten Fall übergeben Sie nur das Modell in der HuggingFace-Notation — dann ermittelt das Kommando die Token-Geschwindigkeit für das Einlesen des Prompts (Prompt Processing = pp) und die Generierung der Antwort (Token Generation = tg). Allerdings kennt llama-bench die Option -hf nicht; vielmehr müssen Sie mit -m den Pfad zur Modelldatei übergeben:

llama-bench -m ~/.cache/llama.cpp/bartowski_Meta-Llama-3.1-8B-Instruct-GGUF_Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf

  model                         size     test   token/s (Tabelle gekürzt ...)
  -----------------------  ---------  -------  --------
  llama 8B Q4_K - Medium    4.58 GiB    pp512    204.03
  llama 8B Q4_K - Medium    4.58 GiB    tg128     17.04

Auf meinem Rechner erreicht llama.cpp mit Vulkan nahezu eine identische Token-Rate wie Ollama mit ROCm (aber ohne die vielen Nachteile dieser AMD-Bibliothek).

AMD-Optimierung

Bei meinen Tests auf dem schon erwähnten Mini-PC mit AMD 8745H-CPU mit der iGPU 780M und 32 GiB RAM funktionierte llama.cpp mit Vulkan viel unkomplizierter als Ollama mit ROCm. Ich habe die VRAM-Zuordnung der GPU wieder zurück auf den Defaultwert von 2 GiB gestellt. Per Default steht llama.cpp auf meinem Rechner dann ca. der halbe Arbeitsspeicher (2 GiB VRAM plus ca. 14 GiB GTT) zur Verfügung. Vulkan kann diesen Speicher ohne merkwürdige Hacks mit Umgebungsvariablen korrekt allozieren. Das reicht ohne jedes Tuning zur Ausführung des Modells gpt-20b aus (siehe den folgenden Abschnitt). So soll es sein!

Wenn Sie noch mehr Speicher für die LLM-Ausführung reservieren wollen, müssen Sie die Kerneloptionen pages_limit und pages_pool_size des AMDGPU-Treibers verändern. Wenn Sie 20 GiB GGT-Speicher nutzen wollen, müssen Sie für beide Optionen den Wert 5242880 angeben (Anzahl der 4-kByte-Blöcke):

# neue Datei /etc/modprobe.d/amd.conf
# 20 * 1024 * 1024 * 1024 / 4096 = 20 * 1024 * 256 = 5242880
options ttm pages_limit=5242880
options ttm page_pool_size=5242880

Danach aktualisieren Sie die Initrd-Dateien und führen einen Neustart durch:

sudo update-initramfs -u                   # Debian und Ubuntu
sudo dracut --regenerate-all --force       # Fedora, RHEL, SUSE

sudo reboot

sudo dmesg | grep "amdgpu.*memory"

  amdgpu: 2048M of VRAM memory ready   (<-- laut BIOS-Einstellung)
  amdgpu: 20480M of GTT memory ready   (<-- laut /etc/modprobe.d/amd.conf)

Modellauswahl

Mit llama.cpp können Sie grundsätzlich jedes Modell im GPT-Generated Unified Format (GGUF) ausführen. Auf der Website von HuggingFace stehen Tausende Modelle zur Wahl:

https://huggingface.co/models?pipeline_tag=text-generation&library=gguf

Die Herausforderung besteht darin, für die eigenen Zwecke relevante Modelle zu finden. Generell ist es eine gute Idee, besonders populäre Modelle vorzuziehen. Außerdem werden Sie rasch feststellen, welche Modellgrößen für Ihre Hardware passen. Die höhere Qualität großer Modelle bringt nichts, wenn die Geschwindigkeit gegen Null sinkt.

gpt-oss-20b

Eine llama.cpp-kompatible Version finden hat ggml-org auf HuggingFace gespeichert. Sofern ca. 15 GiB freier VRAM zur Verfügung stehen (unter AMD: VRAM + GTT), führt llama.cpp das Modell problemlos und beachtlich schnell aus. Beachten Sie, dass es sich hier um ein »Reasoning-Modell« handelt, das zuerst über das Problem nachdenkt und diesen Denkprozess auch darstellt. Danach wird daraus das deutlich kompaktere Ergebnis präsentiert.

llama-cli -hf ggml-org/gpt-oss-20b-GGUF -p 'bash: explain array usage'

  ...

llama-bench -m ~/.cache/llama.cpp/ggml-org_gpt-oss-20b-GGUF_gpt-oss-20b-mxfp4.gguf

  model                         size     test   token/s
  -----------------------  ---------  -------  --------
  gpt-oss 20B MXFP4 MoE    11.27 GiB    pp512    305.68
  gpt-oss 20B MXFP4 MoE    11.27 GiB    tg128     27.93

Server-Betrieb

Die Kommandos llama-cli und llama-bench dienen in erster Linie zum Testen und Debuggen. Sobald Sie sich einmal überzeugt haben, dass llama.cpp grundsätzlich funktioniert, werden Sie das Programm vermutlich im Server-Betrieb einsetzen. Das entsprechende Kommando lautet llama-server und ist grundsätzlich wie llama-cli aufzurufen. Falls Sie llama-server unter einem anderen Account als llama-cli aufrufen, aber schon heruntergeladene Modelle weiterverwenden wollen, übergeben Sie deren Pfad mit der Option -m:

llama-server -c 0 -fa on --jinja -m /home/kofler/.cache/llama.cpp/ggml-org_gpt-oss-20b-GGUF_gpt-oss-20b-mxfp4.gguf

Sie können nun unter http://localhost:8080 auf einen Webserver zugreifen und das gestartete Modell komfortabel bedienen. Im Unterschied zu Ollama hält llama.cpp das Modell dauerhaft im Arbeitsspeicher. Das Modell kann immer nur eine Anfrage beantworten. Die Verarbeitung mehrere paralleler Prompts erlaubt --parallel <n>.

Es ist unmöglich, mit einem Server mehrere Modelle parallel anzubieten. Vielmehr müssen Sie mehrere Instanzen von llama-server ausführen und jedem Dienst mit --port 8081, --port 8082 usw. eine eigene Port-Nummer zuweisen. (Das setzt voraus, dass Sie genug Video-Speicher für alle Modelle zugleich haben!)

Falls auch andere Rechner Server-Zugang erhalten sollen, übergeben Sie mit --host einen Hostnamen oder eine IP-Nummer im lokalen Netzwerk. Mit --api-key oder --api-key-file können Sie den Server-Zugang mit einem Schlüssel absichern. Mehr Details zu den genannten Optionen sowie eine schier endlose Auflistung weiterer Optionen finden Sie hier:

https://github.com/ggml-org/llama.cpp/tree/master/tools/server

Was bringt die GPU? Nicht viel …

Jetzt habe ich drei Tage versucht, gpt-oss per GPU auszuführen. Hat sich das gelohnt? Na ja. Mit -ngl 0 kann die Token Generation (also das Erzeugen der Antwort per Sprachmodell) von der GPU auf die CPU verlagert werden. Das ist natürlich langsamer — aber erstaunlicherweise nur um 25%.

llama-bench -ngl 0 -m ~/.cache/llama.cpp/ggml-org_gpt-oss-20b-GGUF_gpt-oss-20b-mxfp4.gguf

  model                         size     test   token/s
  -----------------------  ---------  -------  --------
  ...
  gpt-oss 20B MXFP4 MoE    11.27 GiB    tg128     21.15

Warum ist der Unterschied nicht größer? Weil die 780M keine besonders mächtige GPU ist und weil die Speicherbandbreite der iGPU viel kleiner ist als bei einer dezidierten GPU mit »echtem« VRAM.

Zur Einordnung noch zwei Vergleichszahlen: MacBook Pro M3: 42 Token/s (mit GPU) versus 39 Token/s (nur CPU)

Quellen/Links

Sprachmodell gpt-oss

• https://huggingface.co/openai/gpt-oss-20b
• https://huggingface.co/ggml-org/gpt-oss-20b-GGUF
• https://simonwillison.net/2025/Aug/5/gpt-oss
• https://github.com/ggml-org/llama.cpp/discussions/15095

Ollama

• https://ollama.com
• https://github.com/ollama/ollama/blob/main/docs/gpu.md#overrides
• https://github.com/ollama/ollama/issues/12062
• https://github.com/ollama/ollama/pull/6282

llama.cpp

• https://github.com/ggml-org/llama.cpp
• https://github.com/ggml-org/llama.cpp/discussions/15709
• https://huggingface.co/models?pipeline_tag=text-generation&library=gguf
• https://community.frame.work/t/igpu-vram-how-much-can-be-assigned/73081/7
• https://github.com/ggml-org/llama.cpp/tree/master/tools/server

In meinem heutigen Beitrag kommentiere ich den 2024 State of Open Source Report und vergleiche die enthaltenen Ergebnisse mit meinen persönlichen Erfahrungen.

Der 2024 State of Open Source Report (im Folgenden auch als Bericht oder Report bezeichnet) wurde von der Firma OpenLogic in Zusammenarbeit mit der Open Source Initiative (OSI) und der Eclipse Foundation erstellt. Der Bericht kann hier als PDF kostenlos heruntergeladen werden (der Haken für den Empfang von Kommunikation muss nicht gesetzt werden). Ich werde in diesem Text häufig auf den Bericht als Quelle verweisen, sodass ich euch empfehle, den Report ebenfalls verfügbar und im besten Fall gelesen zu haben. Seitenangaben beziehen sich auf das PDF mit dem Bericht.

Transparenzhinweis: Ich arbeite als Technical Account Manager für die Firma Red Hat. Meine Arbeit beeinflusst meinen Blick auf den Bericht. Dieser Kommentar stellt ausschließlich meine persönliche Sicht dar.

Informationen zum Bericht

Im Zeitraum vom 10. Oktober bis 8. November 2023 wurde weltweit eine anonyme Umfrage durchgeführt, welche insgesamt 2046 Antworten erhielt (siehe S. 4-6). Es findet sich darin kein Hinweis, ob die Umfrage repräsentativ ist. Es werden jedoch Angaben darüber gemacht, aus welcher Weltregion, Unternehmensgröße und Job-Rolle die Antworten stammen, um diese einordnen zu können.

Nutzung und Verbreitung von Open Source in Unternehmen

Es freut mich zu lesen, dass 95 Prozent der Antworten belegen, dass der Anteil an Open Source in den an der Umfrage teilnehmenden Unternehmen gestiegen (67,57 %) oder gleichgeblieben (27 %) ist (siehe S. 7). Auffällig ist allerdings auch, dass im Mittleren Osten 22,22% angaben, dass der Einsatz von Open Source zurückgegangen ist. Unternehmen, die gar keine Open-Source-Software einsetzen, haben vermutlich nicht an der Umfrage teilgenommen. Der Bericht macht dazu keine Aussage.

Auf Seite 8 findet sich die Aussage, dass 40 % aus der C-Level-Abteilung (z.B. CEO, CTO, CIO, CFO, etc.) angegeben haben, dass der Anteil an Open Source gleichgeblieben ist, während über 60% der Teilnehmer aus technischen Rollen eine Zunahme von Open Source sehen. Laut Bericht deutet dies auf eine mögliche Entfernung bzw. Trennung der Führung von der Basis hin. Dieser Ansicht mag ich mich nicht anschließen, da immerhin 58,46% der Führungskräfte ebenfalls eine Zunahme von Open Source in ihren Unternehmen sehen; das ist von den 60% der technischen Rollen doch nun wirklich nicht weit weg.

Interessant finde ich die genannten Gründe für den Einsatz von Open Source in Unternehmen (siehe S. 9-10). Ein wenig betrübt es mich, dass knapp 37 % „Keine Lizenzkosten“ und „Kostenminimierung“ als wichtigstes Argument für den Einsatz von Open Source nannten; hat Open Source in meinen Augen doch so viel mehr zu bieten, während sich das Ziel der Kostenminimierung nicht in jedem Fall erreichen lässt.

Meiner persönlichen Erfahrung nach verschieben sich die Aufwände in vielen Fällen lediglich. So stellten einige Organisationen fest, dass der Einsatz kostenlos verfügbarer Open-Source-Software mit einem höheren Personalbedarf bzw. einem erhöhten Aufwand für Wissensaufbau und Fehleranalysekompetenz einhergeht. Hier finden sich zum Teil die Kosten wieder, die man zuvor für Lizenzen und externen Support aufgewendet hat. Es gibt hier keine pauschal gültige Empfehlung. Jedes Unternehmen muss für sich selbst bewerten, ob es das erforderliche Personal selbst aufbauen bzw. einstellen kann oder ob der Einkauf externer Unterstützung in Zeiten von Fachkräftemangel nicht doch günstiger ist.

Macht man sich von externem Wissen abhängig, läuft dies dem Ziel entgegen, sich mit Open Source unabhängiger von einzelnen Herstellern machen zu wollen. Hier ist darauf zu achten, wie viel Auswahl an Anbietern am Markt besteht.

Ich nehme allerdings ebenfalls wahr, dass die wirtschaftliche Situation in vielen Unternehmen angespannt ist und kann das Ziel, Kosten zu reduzieren, nachvollziehen. Ich hoffe darauf, dass Unternehmen, die Open Source zur Kostensenkung einführen, auch die weiteren Vorteile, wie z.B. die Vermeidung von Vendor Lock-ins sowie offene Standards und Interoperabilität erkennen und zu schätzen lernen. Die zuletzt genannten Punkte sind immerhin 21 % der Befragten heute schon wichtig.

Herausforderungen beim Einsatz von Open Source

Wie bereits im vorangegangenen Abschnitt erwähnt, ist für den Einsatz von Open Source die Verfügbarkeit des notwendigen Wissens und entsprechende Fertigkeiten notwendig. Immerhin 38 % der befragten Unternehmen sehen es als eine Herausforderung an, das notwendige Wissen und die Fähigkeiten zum effizienten Einsatz von Open Source im Unternehmen verfügbar zu machen (S. 13). Dabei versuchen sie, dies auf unterschiedlichen Wegen verfügbar zu machen. Das Diagramm auf Seite 14 zeigt, dass die Mehrheit mit 45% auf Training des eigenen Personals setzt. Weitere 38% versuchen, Personal mit dem benötigten Wissen einzustellen.

Ich arbeite aktuell selbst in einem Unternehmen, in dem die Fort- und Weiterbildung der eigenen Mitarbeiter einen hohen Stellenwert besitzt. Ich freue mich sehr, dass mein Unternehmen mich aktiv dabei unterstützt, mein Wissen aktuell zu halten und in verschiedenen Bereichen auszubauen.

Ohne einen Beleg zur Hand zu haben, meine ich mich zu erinnern, dass die Qualifizierung bestehenden Personals für ein Unternehmen häufig günstiger ist, als neues Personal einstellen und einarbeiten zu müssen. Falls ihr dazu eine gute Quelle habt, teilt sie mir doch bitte in den Kommentaren mit.

Updates und Patches

Auf Seite 13 des Berichts findet sich die Aussage, dass es für 40 % aller Umfrageteilnehmer eine große bis sehr große Herausforderung darstellt, die Systeme und Anwendungen auf einem aktuellen Stand (Patchlevel) zu halten.

Nach meiner Erfahrung zählen ein geringer Automatisierungsgrad, unzureichende Testprozeduren und eine zu starre Aufbauorganisation mit komplizierten und langwierigen Abstimmungsprozessen zu den größten Problemen in diesem Bereich. Wenn Wartungsfenster zur Installation von (Sicherheits-)Updates mit 3-6 Monaten Vorlauf angekündigt und geplant werden müssen und es keinen Prozess für schnelle Notfallupdates gibt, kann man halt nicht innerhalb von 72 Stunden reagieren und Schwachstellen schließen. Wenn die Kommunikation zwischen Betriebs- und Anwendungs-Team rein über Ticketsystem läuft, hat man zwar einen sauberen Prozessablauf mit Genehmigungs- und Prüfschritten; werden die Schritte jedoch alle manuell ausgeführt, darf man sich nicht wundern, wenn Updates vier Tage statt vier Stunden brauchen.

Noch immer begegnen mir im Gespräch Szenarien, wo Anwendungsteams nicht über Testsysteme und Testpläne verfügen. Die Folgen eines Updates/Patches lassen sich nur direkt in Produktionsumgebung prüfen. Bei Fehlern kommt es dann sofort zu einer Beeinträchtigung des Dienstes und der Stresslevel steigt. Wo es bereits an der Fähigkeit mangelt, Änderungen zeitnah zu verifizieren, fehlt oft auch die Möglichkeit, auf einen zuletzt als funktionierend bekannten Stand zurückzurollen. Hier bleibt nur der Weg voran unter Einsatz aller verfügbaren Ressourcen, bis das Problem behoben oder das Unternehmen insolvent ist.

Nicht immer ist es ganz so dramatisch. Häufig löst mangelnde Automation einen langwierigen Abstimmungsprozess aus. Viele Personen müssen Zeit einplanen, um diverse Schritte im Prozessablauf manuell auszuführen, zu testen und zu dokumentieren. Schnell sind 3,6 kg Excel-Dateien erstellt, das Update aber immer noch nicht abgeschlossen.

Ich erinnere mich an die schöne Zeit zwischen 2011 und 2014. Unser damaliger stellvertretender Abteilungsleiter hatte die Idee, DevOps auszuprobieren. Dazu wurden Teams aus Entwicklern und Systemadministratoren gebildet, die nun gemeinsam für den Betrieb und die Verfügbarkeit bestimmter Anwendungen verantwortlich waren. Statt den auf Papier dokumentierten Verantwortungsübergängen und dem daraus häufig folgenden Hin- und Herschiebens des schwarzen Peters saßen wir jetzt gemeinsam in einem Boot und hatten gemeinsame Ziele. Wir lernten dabei die Sicht- und Arbeitsweise der jeweils anderen Job-Rolle kennen und zu verstehen. Und im gemeinsamen Dialog, gelang es uns Automationsprozesse zu entwickeln, um Updates schneller und erfolgreicher durchführen zu können. Leider überlebte dieses Modell die Zeit nicht. Heute ist mir bekannt, dass mit dem Wechsel dieses Modells auch die alten Probleme zurückkehrten und deutlich weniger Updates durchgeführt werden.

Oft liegt die Verantwortung für die Installation von Updates/Patches beim Betrieb. Jedoch ist nur das Anwendungsteam in der Lage, die korrekte Funktionsfähigkeit der Anwendung/des Dienstes zu beurteilen. Auch wenn manche Abteilungsleiter es nicht gerne hören, es geht am besten gemeinsam, mit kurzen Abstimmungswegen über Team- und Abteilungsgrenzen hinweg.

Der zweite Schlüssel zum Erfolg ist Automation. Lasst den Automaten die einzelnen Prozessschritte ausführen, welche in der Regel wie folgt aussehen:

1. Anwendung bzw. Dienste stoppen
2. Updates/Patches installieren
3. System neu starten
4. Anwendung bzw. Dienste starten
5. Anwendung/Dienst auf korrekte Ausführung testen
6. Bei Fehlschlag –> Rollback bzw. bei Erfolg –> Update erfolgreich

Zeit und Energie, die hier investiert werden, zahlen sich in aktuellen Systemen mit weniger Sicherheitslücken aus. Schafft einen Raum, in dem sich eure Experten aus Systemadministration und Anwendungsentwicklung austauschen und abstimmen können.

Selbstverständlich haben die Qualität der vom Hersteller bereitgestellten Updates ebenfalls einen großen Einfluss auf den Erfolg von Patchinstallationen. Sollte es hier wiederholt Probleme geben und keine Besserung in Sicht sein, ist ggf. ein Wechsel des Anbieters in Erwägung zu ziehen. Doch bevor ihr euch Hals über Kopf in die Migration stürzt, denkt daran, dass das Gras auf der anderen Wiese stets grüner wirkt, als es ist. Es geht nicht ohne ausführliche Tests.

Ich wünsche allen, die sich für Updates und Patches Nächte und Wochenenden um die Ohren schlagen müssen, dass sich die Situation für euch bessert und sich dies im nächsten Open Source Statusbericht ablesen lässt.

Wartung von End-of-Life Versionen

Manche nennen es den Giftschrank, andere die Schmuddelecke. Gemeint sind damit Betriebssystem-Releases und Anwendungen, die das Ende ihres Lebenszyklus erreicht oder schon überschritten haben. Laut Seite 13 des Berichts ist dies für 42 % der Umfrageteilnehmer ein Thema.

Die Gründe warum diese Systeme noch existieren, lauten häufig sehr ähnlich. Fast immer läuft eine geschäftskritische Anwendung darauf,

• Von der im Unternehmen niemand mehr weiß, wie sie funktioniert, um sie auf ein neues Betriebssystem zu migrieren
• Für deren Migration keine Ressourcen verfügbar sind
• Mit der komplizierte und langwierige Abstimmungsprozesse zur Migration verbunden sind; niemand will das Ding anfassen
• Die für keine aktuellere Betriebssystem-Version zertifiziert ist

Im hier kommentierten Bericht wird auf Seite 15 ausgewiesen, dass 22 % der Befragten noch CentOS einsetzten, dessen Release 7 seit dem 30. Juni 2024 End-of-Life (EoL) ist. In der Umfrage kommt es sogar auf Platz 3 der am häufigsten eingesetzten Distributionen.

Egal ob man nun EoL-Betriebssysteme oder EoL-Laufzeitumgebungen betrachtet, die Lösung ist stets dieselbe. Die dazugehörige Anwendung muss zuerst auf einer neueren und unterstützten Version laufen, bevor die alte abgeschaltet werden kann. Dazu müssen Teams in der Lage sein, Anwendungen neu deployen und das Deployment testen zu können. Auch hier helfen Testsysteme, -prozeduren und Automation. Auch hierbei ist es unerlässlich, dass Betrieb und Anwendungsteams zusammenarbeiten, um den Erfolg der Migration sicherzustellen. Je schneller Feedback-Loops und Abstimmungsprozesse sind, desto schneller sind notwendige Prozeduren etabliert. Die Zeit für Releasewechsel lässt sich so signifikant verkürzen. Ressourcen sind damit schneller frei und können für innovative Entwicklungsprojekte genutzt werden.

Leider erlebe ich häufig, dass Abteilungen nur in ihrem eigenen Bereich nach Lösungen suchen und den Kontakt zu anderen Abteilungen meiden, ja beinahe scheuen. Doch ist dies kein technisches Problem. Es ist eine organisatorische Herausforderung, die angegangen werden muss. Es liegt doch im Interesse aller Beteiligten, regelmäßig wiederkehrende Releasewechsel schnell und störungsarm abwickeln zu können.

In meinem beruflichen Alltag erlebe ich häufig, dass In-Place-Upgrades als Allheilmittel angesehen werden. Ich hingegen bin kein großer Freund davon. Sie sind der vermeintlich einfache Weg, doch führen sie zur dunklen Seite der Macht. Ein In-Place-Upgrade aktualisiert das Betriebssystem inkl. der installierten Bibliotheken und Laufzeitumgebungen. Es befreit nicht von der obligatorischen Aufgabe, die darauf laufenden Anwendungen im Anschluss zu testen. Stellt man dabei Fehler fest, gibt es häufig kein Zurück mehr. Eine Ausnahme bilden hier virtuelle Umgebungen, bei denen man zuvor einen Snapshot der virtuellen Maschine erstellen kann.

Wer eine Anwendung immer nur mit In-Place-Upgrades von einem Release auf das nächste rettet, verliert mit einer größeren Wahrscheinlichkeit die Fähigkeit, die Anwendung sauber neu zu deployen. Man tut sich hiermit keinen Gefallen.

Ich bin der Überzeugung, dass Organisationen in der Lage sein müssen, ihre geschäftskritischen Anwendungen mit einem definierten Zustand automatisiert ausrollen zu können. Dies unterstützt Releasewechsel, erleichtert den Auf- und Abbau von Testumgebungen sowie die Verifizierung von Fehlern und das Nachstellen von Bugs. Anwendungen können so auch deutlich leichter und schneller gegen neuen Bibliotheken und Laufzeitumgebungen getestet werden. Es lohnt sich, Zeit zum Schärfen der Axt zu investieren, bevor man mit dem Fällen der Bäume beginnt. Oder anders ausgedrückt, wer keine Zeit hat, den Zaun zu reparieren, weil er mit Kühe einfangen beschäftigt ist, wird nie zum Melken kommen.

Open Source Distributionen

In dieser Kategorie auf Seite 15 listet der Bericht die Linux-Distributionen auf, die von den Umfrageteilnehmern verwendet werden. Ubuntu führt diese Liste an und liegt mit 46 % vor Debian mit 23%. Platz 3 geht an CentOS mit 22%. Den undankbaren vierten Platz belegt Amazon Linux mit knapp 20%. Die noch recht neue Distribution CentOS Stream findet sich auf Platz 13 mit 9,5%.

Ich habe diese Werte mit denen aus dem State of Open Source Report von 2023 verglichen. Ubuntu hat im Vergleich um 27 % zugelegt (Platz 1 mit 29% in 2023). Debian kam 2023 mit 16,63% auf Platz 6 hinter CentOS Stream mit 16,74%. Die Plätze 2 und 3 wurden 2023 von Alpine Linux (21,1%) und Oracle Linux (19,72%) belegt. CentOS kam damals mit 15% auf Platz 8.

Der Bericht von 2024 spekuliert, dass Red Hat’s Änderung beim Zugriff auf den RHEL Quelltext und das EoL von CentOS mitverantwortlich für diese Veränderungen sind, kann jedoch keine klaren Belege dafür liefern. Laut Bericht sind die Linux Wars noch nicht entschieden und wir können auf den kommenden Bericht gespannt sein.

Es hat mich überrascht, dass RHEL und SLES es gar nicht in das Ranking geschafft haben. Unter Berücksichtigung, dass die Kostenreduktion in diesem Bericht die Hauptmotivation für den Einsatz von Open Source darstellt, lässt sich ggf. erklären, warum Distributionen gerade nicht hoch im Kurs stehen, die kostenpflichtige Support-Subskriptionen für den produktiven Einsatz voraussetzen.

Ich freue mich schon darauf, herauszufinden, wie dieses Ranking im nächsten Bericht aussieht.

Cloud-Native Open Source Technologies

Das Diagramm auf Seite 17 zeigt das Ranking der wichtigsten Cloud-Native Open Source Technologies für die Umfrageteilnehmer. Platz 1 wird von Docker mit 44,6 % eingenommen, gefolgt von Kubernetes mit 33,61 %.

Der große Vorsprung von Docker vor Podman mit 16,6 % hat mich ein wenig überrascht. Ich hätte den Abstand nicht als so groß eingeschätzt. Hier interessiert mich, welche Vorteile die Nutzer in Docker gegenüber Podman sehen. Leider macht der Bericht hierzu keine Aussage. Ich selbst nutze Podman unter Debian, Fedora und RHEL. In Debian stehen ungünstigerweise nur ältere Podman Releases zur Verfügung, denen wichtige Funktionen fehlen. Dies ist in meinen Augen eine Erklärung, warum Podman gerade in diesen Distributionen wenig genutzt wird. Dies ist allerdings nur wilde Spekulation meinerseits. Ich kann dies nicht belegen.

Für mich ebenfalls unerwartet ist OpenStack mit knapp 18 % sowie OKD und Rancher mit jeweils unter 10%. In diesem Bereich leide ich vermutlich an Betriebsblindheit. Wenn man bei Red Hat arbeitet, kann man leicht den Eindruck gewinnen, dass die ganze Welt nur noch OpenShift macht.

Ich freue mich darauf, diese Kategorie über die nächsten Jahre zu beobachten und zu sehen, wie sich Podman entwickelt, wofür ich eine gewisse Vorliebe habe.

Automations- und Konfigurations-Management

Wer die Kategorie Ansible in diesem Blog kennt, weiß bereits, dass ich mich gerne mit Ansible beschäftige. So freut es mich zu sehen, dass Ansible im betrachteten Bericht auf Seite 25 Platz 1 mit 30% belegt. Überraschend finde ich hingegen, dass 27% angaben, keinerlei Open Source Automations- bzw. Konfigurationsmanagement zu verwenden. Der Bericht führt dies auf Antworten aus jungen Unternehmen zurück, die (noch) keine Notwendigkeit für Automation sehen. Ich möchte diesen Unternehmen empfehlen, frühzeitig eine Automation First Philosophie zu entwickeln, da ich überzeugt bin, dass sich ein konsequenter Einsatz von Automations- und Konfigurationsmanagementwerkzeugen schnell auszahlt.

Unter den Systemadministratoren liegen Ansible (40 %) und Puppet (36%) als beliebteste Werkzeuge nah beieinander. Es ist immer gut, Auswahl und Wettbewerb zu haben. Ich freue mich über den Anteil von Puppet, gerade weil ich in den Nachrichten nur noch wenig Notiz davon nehme.

Salt liegt bei unter 10 % und ich habe auch schon längere Zeit nichts mehr von diesem Projekt gehört. Schade, die Architektur von Salt finde ich ganz interessant.

Im aktuellen Bericht nutzen knapp 23 % Terraform und der Lizenzwechsel zeigt noch keine große Abwanderung zu dessen Fork OpenTofu. Da die Datenerhebung jedoch Ende 2023 durchgeführt wurde, kann der Bericht eine etwaige Nutzerabwanderung noch nicht darstellen. In 2024 hat IBM die Übernahme von Hashi Corp bekannt gegeben. Ich bin gespannt, wie es mit den Produkten und deren Nutzung weitergeht. Hoffentlich gibt der nächste Bericht erste Einblicke.

Fazit

Durch die Arbeit in einem großen IT-Unternehmen mit einem starken eigenen Portfolio fällt es leicht, eine Betriebsblindheit für die Entwicklungen außerhalb des eigenen Kosmos zu entwickeln. Berichte wie der 2024 State of the Open Source Report helfen, der Betriebsblindheit entgegenzuwirken.

Ich habe nicht alle Kategorien des aktuellen Berichts im Detail betrachtet, sondern mir diejenigen herausgepickt, die mein persönliches Interesse ansprechen. Darüber in diesem Blog zu schreiben, hilft mir, über den Bericht und meine Erfahrungen zu reflektieren. Und wenn euch dieser Kommentar ebenfalls gefällt, freue ich mich umso mehr.

Seit über 30 Jahren nutze ich Linux, und knapp 25 Jahre davon war die bash meine Shell. Ein eigener Prompt, der das aktuelle Verzeichnis farbig anzeigte, was das Maß der Dinge :-)

Mein Umstieg auf die zsh hatte mit Git zu tun: Die zsh in Kombination mit der Erweiterung Oh my zsh gibt im Prompt direktes Feedback über den Zustand des Repositories (aktiver Zweig, offene Änderungen). Außerdem agiert die zsh in vielen Details »intelligenter« (ein viel strapazierter Begriff, ich weiß) als die bash. Es macht ein wenig Arbeit, bis alles so funktioniert wie es soll, aber ich war glücklich mit meinem Setup.

Seit ein paar Monaten habe ich die Default-Shell meiner wichtigsten Linux-Installationen neuerlich gewechselt. Ich gehöre jetzt zum rasch wachsenden Lager der fish-Fans. fish steht für Friendly Interactive Shell, und die Shell wird diesem Anspruch wirklich gerecht. fish bietet von Grund auf eine Menge Features, die zsh plus diverse Plugins inklusive Oh my zsh erst nach einer relativ mühsamen Konfiguration beherrschen. Die Inbetriebnahme der fish dauert bei den meisten Distributionen weniger als eine Minute — und die Defaultkonfiguration ist so gut, dass weitere Anpassungen oft gar nicht notwendig sind. Und sollte das doch der Fall sein, öffnet fish_config einen komfortablen Konfigurationsdialog im Webbrowser (außer Sie arbeiten in einer SSH-Session).

Die Stärken der fish im Vergleich zu bash und zsh haben aus meiner Sicht wenig mit der Funktionalität zu tun; einige Features der fish lassen sich auch mit bash-Hacks erreichen, fast alle mit zsh-Plugins. Der entscheidende Vorteil ist vielmehr, dass die fish out of the box zufriedenstellend funktioniert. Für mich ist das deswegen entscheidend, weil ich viele Linux-Installationen verwende und keine Zeit dafür habe, mich jedesmal mit dem Shell-Setup zu ärgern. Deswegen hatte ich in der Vergangenheit auf meinen wichtigsten Installationen zsh samt einer maßgeschneiderten Konfiguration, auf allen anderen aber der Einfachheit halber die bash oder eine unkonfigurierte zsh-Installation.

Installation

Die Installation ist schnell erledigt. Alle gängigen Distributionen stellen fish als Paket zur Verfügung. Also apt/dnf install fish, danach:

chsh -s $(which fish)

Aus- und neu einloggen, fertig.

Falls Ihnen die fish doch nicht zusagt, ist die bisherige Shell ebenso schnell mit chsh -s $(which bash) oder chsh -s $(which zsh) reaktiviert.

Features

Im Prinzip verhält sich die fish wie jede andere Shell. Insbesondere gelten die üblichen Mechanismen zum Start von Kommandos, zur Ein- und Ausgabeumleitung mit < und >, zur Bildung von Pipes mit | sowie zur Verarbeitung von Kommandoergebnissen mit $(cmd). Was ist also neu?

• Während der Eingabe verwendet die fish Farben, um verschiedene Bestandteile Ihres Kommandos (z.B. Zeichenketten) zu kennzeichnen. Das sieht nett aus, der entscheidende Vorteil ist aber, dass Sie oft Tippfehler erkennen, bevor Sie Return drücken: Kommandos, die es gar nicht gibt, werden rot hervorgehoben, ebenso nicht geschlossene Zeichenketten. (Die Farben sind vom aktiven Farbschema abhängig.)

• Die Vervollständigung von Kommandos, Optionen, Datei- und Variablennamen mit der Tabulator-Taste ist noch »intelligenter« als bei bash und zsh. fish greift dazu auf über 1000 *.fish-Dateien im Verzeichnis /usr/share/fish/completions zurück, die Regeln für alle erdenklichen Fälle enthalten und mit jeder fish-Version erweitert werden. Die fish zeigt sogar kurze Hilfetexte an (siehe die folgende Abbildung). Wenn es viele mögliche Vervollständigungen gibt, zeigt fish diese in mehreren Spalten an. Sie können mit den Cursortasten das gewünschte Element auswählen.

• Bei der Eingabe von Kommandos durchsucht die fish die History, also eine Datei, in der alle zuletzt ausgeführten Kommandos gespeichert wurden. In etwas blasserer Schrift schlägt es das passendste Kommando vor. Die fish berücksichtigt dabei auch den Kontext (welches Verzeichnis ist aktiv, welche Kommandos wurden vorher ausgeführt) und schlägt oft — fast schon ein wenig unheimlich — das richtige Kommando vor. Wenn Sie dieses Kommando ausführen möchten, vervollständigen Sie die Eingabe mit Cursor rechts (nicht Tabulator!) und drücken dann Return. Durch ähnliche Kommandos können Sie mit den Cursortasten blättern.

• Alternativ können Sie auch mit Strg+R suchmuster nach früher ausgeführten Kommandos suchen. Die fish sucht nach dem Muster nicht nur in den Anfangsbuchstaben, sondern in den gesamten Zeichenketten der History.

• Wenn das aktuelle Verzeichnis Teil eines Git-Repositories ist, zeigt fish den Namen des aktuellen Zweigs in Klammern an. (Wenn Sie mehr Git-Infos sehen wollen, ändern Sie die Prompt-Konfiguration.)

Globbing-Eigenheiten

In Shells wird die Umwandlung von *.txt in die Liste passender Dateinamen als »Globbing« bezeichnet. Die fish verhält sich dabei fast gleich wie die bash — aber mit einem kleinen Unterschied: Wenn es keine passenden Dateien gibt (z.B. keine einzige Datei mit der Endung .txt), löst die fish einen Fehler aus. Die bash übergibt dagegen das Muster — also *.txt — an das Kommando und überlässt diesem die Auswertung. In der Regel tritt der Fehler dann dort auf. Also kein großer Unterschied?

Es gibt Sonderfälle, in denen das Verhalten der bash günstiger ist. Stellen Sie sich vor, Sie wollen mit scp alle *.png-Dateien von einem externen Rechner auf Ihren lokalen Rechner übertragen:

scp externalhost:*.png .

In der bash funktioniert das wie gewünscht. Die fish kann aber mit externalhost:*.png nichts anfangen und löst einen Fehler aus. Abhilfe: Sie müssen das Globbing-Muster in Anführungszeichen stellen, also:

scp "externalhost:*.png" .

Analoge Probleme können auch beim Aufruf von Paketkommandos auftreten. apt install php8-* funktioniert nicht, wohl aber apt install "php8-*". Hintergründe zum Globbing-Verhalten können Sie hier nachlesen:

Tastenkürzel

Grundsätzlich gelten in der fish dieselben Tastenkürzel wie in der bash. In der fish gibt es darüberhinaus weitere Kürzel, von denen ich die wichtigsten hier zusammengestellt habe. bind oder fish_config (Dialogblatt bindings) liefert eine wesentlich längerer Liste aller Tastenkürzel. Beachten Sie, dass es vom Desktopsystem und vom Terminal abhängt, ob die Alt-Tastenkürzel wirklich funktionieren. Wenn die Kürzel vom Terminal oder dem Desktopsystem verarbeitet werden, erreichen Sie die fish nicht.

Kürzel              Bedeutung
------------------  -------------------------------------------------------
Alt+Cursor links    führt zurück ins vorige Verzeichnis (prevd)
Alt+Cursor rechts   macht die obige Aktion rückgängig (nextd)
Alt+E               öffnet den Dateinamen mit $EDITOR
Alt+H oder F1       zeigt die man-Seite zum eingegebenen Kommando an (Help)
Alt+L               führt ls aus
Alt+P               fügt der Eingabe &| less hinzu (Pager)
Alt+S               fügt sudo am Beginn der Eingabe ein
Alt+W               zeigt Aliasse und eine Beschreibung des Kommandos (What is?)

Noch eine Anmerkung zu Alt+S: In meiner Praxis kommt es ständig vor, dass ich sudo vergesse. Ich führen also dnf install xy aus und erhalte die Fehlermeldung, dass meine Rechte nicht ausreichen. Jetzt drücke ich einfach Alt+S und Return. Die fish stellt sudo dem vorigen, fehlgeschlagenen Kommando voran und führt es aus.

Konfiguration

Das Kommando fish_config öffnet einen Konfigurationsdialog im Webbrowser. Falls Ihr Webbrowser gerade minimiert ist, müssen Sie das Fenster selbst in den Vordergrund bringen. Im Browser können Sie nun ein Farbenschema auswählen, noch mehr Informationen in den Prompt integrieren, die Tastenkürzel nachlesen etc.

In SSH-Sessions scheitert der Start eines Webbrowsers. In diesem Fall können Sie mit fish_config prompt bzw. fish_config theme das Promptaussehen und das Farbschema direkt im Textmodus verändern.

Wenn Sie Änderungen durchführen, werden diese im Terminal mit set -U fish_xxx newvalue ausgeführt und in Konfigurationsdateien in .config/fish gespeichert, insbesondere in:

~/.config/fish/fish_variables                (Farbeinstellungen)
~/.config/fish/functions/fish_prompt.fish    (Prompt)

Das Gegenstück zu .bashrc oder .zshrc ist die Datei .config/fish/config.fish. Das ist der richtige Ort, um eigene Abkürzungen zu definieren, den PATH zu erweitern etc. config.fish enthält einen vordefinierten if-Block für Einstellungen, die nur für interaktive fish-Sessions relevant sind. Alle anderen Einstellungen, die z.B. in Scripts gelten sollen, führen Sie außerhalb durch. Das folgende Listing zeigt ein paar typische Einstellungen:

# Datei .config/fish/config.fish
...

# PATH ändern
fish_add_path ~/bin
fish_add_path ~/.local/bin

# keine fish-Welcome-Nachricht
set -U fish_greeting ""

# Einstellungen nur für die interaktive Nutzung
if status is-interactive
    # abr statt alias
    abbr -a ls eza
    abbr -a ll 'eza -la'
    abbr -a gc 'git commit'

    # Lieblingseditor
    set -gx EDITOR /usr/bin/jmacs
end

Das obige Listing zeigt schon, das die fish gängige Einstellungen anders handhabt als bash und zsh:

Abkürzungen: Anstelle von alias sieht die fish das Kommando abbr vor. alias steht auch zur Verfügung, von seinem Einsatz wird aber abgeraten. abbr unterscheidet sich durch ein paar Details von alias: Die Expansion in das Kommando erfolgt bereits, wenn Sie Return drücken. Sie sehen daher, welches Kommando wirklich ausgeführt wird, und dieses Kommando (nicht die Abkürzung) wird in der History gespeichert.

PATH-Änderungen: Sie müssen die PATH-Variable nicht direkt verändern, sondern können stattdessen fish_add_path aufrufen. Ihr Pfad wird am Ende hinzugefügt, wobei die Funktion sicherstellt, dass es keine Doppelgänger gibt.

Variablen (set): Die Optionen des set-Kommandos zur Einstellung von Variablen funktionieren anders als in der bash:

• -g: Die Variable ist in der gesamten fish-Session zugänglich (Global Scope), nicht nur in einer Funktion oder einem Block.

• -x: Die Variable wird an Subprozesse weitergegeben (Export).

• -U: Die Variable wird dauerhaft in .config/fish/fish_variables gespeichert und gilt daher auch für künftige fish-Sessions (Universal). Sie wird aber nicht exportiert, es sei denn, Sie verwenden -Ux.

• -l: Definiert eine lokale Variable, z.B. innerhalb einer Funktion.

Zusätzliche eingebaute Kommandos

Jede Shell hat eine Menge integrierter Kommandos wie cd, if oder set. In der fish können Sie mit builtin -n alle derartigen Kommandos auflisten. Die meisten Kommandos entsprechen exakt den bash- und zsh-Vorgaben. In der fish gibt es aber einige originelle Erweiterungen: math führt einfache Berechnungen aus, random produziert ganzzahlige Zufallszahlen, string manupuliert Zeichenketten ohne die umständliche Parametersubstitution, path extrahiert Komponenten aus einem zusammengesetzten Dateinamen, count zählt Objekte (vergleichbar mit wc -l etc. Das folgende Listing zeigt die Anwendung dieser Kommandos:

math "2.5 * 3.8"

  9.5

string split " "  "lorem ipsum dolor est"

  lorem
  ipsum
  dolor
  est

string replace ".png" ".jpg" file1.png file2.png file3.png

  file1.jpg
  file2.jpg
  file3.jpg

string sub -s 4 -e 8 "abcdefghijkl"   # Start und Ende inklusive

  defgh

path basename /home/kofler/images/img_234.png

  img_234.png

path dirname /home/kofler/images/img_234.png

  /home/kofler/images

path extension /home/kofler/images/img_234.png

  .png

random 1 100

  13

random choice a b c

  c

count *          # das aktuelle Verzeichnis hat
                 # 32 Dateien/Verzeichnisse
  32

ps ax | count    # gerade laufen 264 Prozesse

  264

Programmierung

Die Bezeichnung Friendly Interactive Shell weist schon darauf hin: Die fish ist für die interaktive Nutzung optimiert, nicht für die Programmierung. Die fish unterstützt aber sehr wohl auch die Script-Programmierung. Diese ist insofern attraktiv, weil die fish-Entwickler auf maximale Kompatibilität verzichtet haben und die schlimmsten Syntaxungereimtheiten der bash behoben haben. fish-Scripts sind daher ungleich leichter zu verstehen als bash-Scripts. Umgekehrt heißt das leider: fish-Scripts sind inkompatibel zu bash und zsh und können nur ausgeführt werden, wo die fish zur Verfügung steht. Für mich ist das zumeist ein Ausschlusskriterium.

Anstelle einer systematischen Einführung will ich Ihnen hier anhand eines Beispiels die Vorteile der fish beim Programmieren nahebringen. Das Script ermittelt die Anzahl der Zeilen für alle *.txt-Dateien im aktuellen Verzeichnis. (Ich weiß, wc -l *.txt wäre einfacher; es geht hier nur darum, diverse Syntaxeigenheiten in wenig Zeilen Code zu verpacken.) Die bash-Variante könnte so aussehen:

#!/bin/bash
files=(*.txt)
if [ ${#files[@]} -eq 0 ]; then
    echo "No .txt files found"
    exit 1
fi
for file in "${files[@]}"; do
    if [ -f "$file" ]; then
        lines=$(wc -l < "$file")
        echo "$file: $lines lines"
    fi
done

Das äquivalente fish-Script ist deutlich besser lesbar:

#!/usr/bin/env fish
set files *.txt
if not count $files > /dev/null
    echo "No .txt files found"
    exit 1
end
for file in $files
    if test -f $file
        echo "$file: "(count < $file)" lines"
    end
end

Auf ein paar Details möchte ich hinweisen:

• Kontrollstrukturen werden generell mit end abgeschlossen, nicht mit fi für if oder mit esac für case.

• Bedingungen für if, for etc. müssen weder in eckige Klammern gestellt noch mit einem Strichpunkt abgeschlossen werden.

• Die fish verarbeitet Variablen korrekt selbst wenn sie Dateinamen mit Leerzeichen enthalten. Es ist nicht notwendig, sie in Anführungszeichen zu stellen (wie bei "$file" im bash-Script).

Wenn Sie in eigenen Scripts Optionen und andere Parameter verarbeiten möchten, hilft Ihnen dabei das Builtin-Kommando argparse. Eine gute Zusammenstellung aller Syntaxunterschiede zwischen bash und fish gibt die fish-Dokumentation.

Paketmanager fisher

Das Versprechen von fish ist ja, dass fast alles out-of-the-box funktioniert, dass die Installation von Zusatzfunktionen und deren Konfiguration ein Thema der Vergangenheit ist. Aber in der Praxis tauchen trotzdem immer Zusatzwünsche auf. Mit dem Paketmanager fisher können Zusatzmodule installiert werden. Eine Sammlung geeigneter Plugins finden Sie hier.

Die Geschichte von fish

Die fish ist erst in den letzten Jahren so richtig populär geworden. Das zeigt, dass es auch in der Linux-Welt Modetrends gibt. fish ist nämlich alles andere als neu. Die erste Version erschien bereits 2005.

fish wurde ursprünglich in C entwickelt, dann nach C++ und schließlich nach Rust portiert. Erst seit Version 4.0 (erschienen im Februar 2025) besteht fish ausschließlich aus Rust-Code sowie in fish selbst geschriebenen Erweiterungen.

Fazit

Die fish punktet durch die gut durchdachte Grundkonfiguration und die leichte Zugänglichkeit (Konfiguration und Hilfe im Webbrowser). Es gibt nicht das eine Feature, mit dem sich die fish von anderen Shells abhebt, es ist vielmehr die Summe vieler, gut durchdachter Kleinigkeiten und Detailverbesserungen. Das Arbeiten in der fish ist intuitiver als bei anderen Shells und macht mehr Spaß. Probieren Sie es aus!

Bei der Programmierung ist die fish inkompatibel zu anderen Shells und insofern kein Ersatz (auch wenn die fish-eigenen Features durchaus spannend sind). Zur Ausführung traditioneller Shell-Scripts brauchen Sie weiterhin eine traditionelle Shell, am besten die bash.

Quellen/Links

• https://fishshell.com
• https://fishshell.com/docs/current/fish_for_bash_users.html
• https://fishshell.com/docs/current/language.html#wildcards-globbing
• https://github.com/jorgebucaran/fisher (Paketmanager)
• https://github.com/jorgebucaran/awsm.fish (populäre Erweiterungspakete)

YouTube-Videos

• https://www.youtube.com/watch?v=lzTDo1KsL-I (The best shell you are not using)
• https://www.youtube.com/watch?v=8GN9D-OnG-A (Fish Shell Tips and Tricks / Can Your Shell Do This?)

Rund um die Integration von KI-Tools in Xcode hat sich Apple bisher nicht mit Ruhm bekleckert (siehe auch meinen Blog-Artikel zu Xcode 26.1 und 26.2). Aber mit Version 26.3 ist Xcode endlich doch im KI-Zeitalter angekommen. Der Schlüssel zum Erfolg: die Einhaltung offener Standards.

KI funktioniert in Xcode 26.3, weil Apple mit mcpbridge einen MCP-Server mit ca. 20 Tools für Xcode implementiert hat. Damit können Sprachmodelle direkt mit Xcode kommunizieren, Code ändern, auf aktuelle Apple-spezifische Dokumentation zugreifen, Apps ausprobieren und Fehler beheben.

Konfiguration

Der Konfigurationsdialog Intelligence sieht simpel aus, stiftet in Wirklichkeit aber Verwirrung. Auf den ersten Blick könnte man meinen, es gäbe zwei vordefinierte KI-Provider: OpenAI mit ChatGPT und Codex auf der einen Seite, Anthropic mit Claude auf der anderen Seite. Es sind aber VIER!

• ChatGPT: simple KI-Unterstützung, in begrenztem Ausmaß kostenlos
• OpenAI Codex: Agentic Coding mit Codex
• Claude: simple KI-Unterstützung
• Claude Agent: Agentic Coding mit Claude (vergleichbar mit der CLI Claude Code)

Ich gehe im Folgenden davon aus, dass Sie ein ChatGPT- oder Claude-Abo haben und dieses für Xcode nutzen möchten. Dazu installieren Sie zuerst das entsprechende Zusatzprogramm OpenAI Codex bzw. Claude Agent (Button Get). Ärgerlicherweise scheint die KI-Integration auch ohne diese Zusatzinstallation zu funktionieren — aber dann landen Sie bei den eingeschränkten Varianten ChatGPT oder Claude, die nur mittelmäßig funktionieren, keine Skill-Unterstützung aufweisen usw.

Im nächsten Schritt müssen Sie die Verbindung zum jeweiligen KI-Konto herstellen. Die Authentifizierung erfolgt in einem Webbrowser-Fenster. Die konfigurierten KI-Tools bekommen automatisch Zugang zu den MCP-Diensten von Xcode.

Es besteht auch die Möglichkeit, andere externe sowie lokale KI-Provider zu nutzen. Am interessantesten wäre sicherlich Google Gemini, aber ich habe aus Zeitgründen von Tests abgesehen. (Freie, lokale Modelle sind nach meinen Erfahrungen mit anderen IDEs eher ungeeignet. Sie sind für Agentic Coding nicht leistungsfähig genug. Außerdem basieren sie meist auf relativ altem Trainingsmaterial, was bei Swift/SwiftUI besonders ungünstig ist.)

Die Option Allow external agents to use Xcode tools ist nur dann relevant, wenn Sie ein externes (nicht in Xcode eingebettetes) KI-Tool verwenden, z.B. Claude Code oder Codex. Diese externen Tools können dann den in Xcode integrierten MCP-Server nutzen und z.B. Apps ausführen, davon Screenshots erstellen und auf diese Weise UI-Fehler erkennen/beheben.

In der KI-Seitenleiste wählen Sie den gewünschten, zuvor konfigurierten KI-Dienst aus. Alle Agentic Coding Funktionen gibt es aber nur mit Codex oder Claude Agent!

Erster Versuch (ChatGPT)

Als ersten Versuch habe ich mit dem Modell ChatGPT (ohne OpenAI-Konto) eine minimale Variante des Break-Out-Spiels als iOS-App entwickelt (siehe die erste Abbildung dieses Artikels).

Prompt: create a simple break out game as an iOS app

Zwei Minuten später war die App fertig. 170 Zeilen Code, alle in ContentView.swift. Xcode zeigte allerdings einen Build-Error an und wies auch gleich auf die Ursache hin: Es fehlte import Combine, worum ich mich selbst kümmerte. Danach war die App prinzipiell verwendbar.

Einerseits ist das Ergebnis beeindruckend, andererseits ist die Code-Qualität aber nicht großartig: Xcode bemängelte zwei onChange-Aufrufe, deren Syntax veraltet ist. Aber auch davon losgelöst ist der Code nicht effizient. Die Spielelemente sind alle in SwiftUI abgebildet (kein SpriteKit). Das ist die einfachste Lösung, aber die Implementierung ist langsam. Das Spiel wird stotternd langsam, sobald das Paddel mit der Maus verschoben wird.

Ich habe mit ein paar Folge-Prompts versucht, das Spiel zu verbessern:

Prompt: the onChange() modifiers are deprecated; please fix

Prompt: ok. it works, but it is extremely slow if I move the paddle. (As long as there is no user input, speed is OK)

Das KI-Tool ersetzte zuerst onChange durch task (OK) und baute dann @GestureState ein, um die Geschwindigkeit zu verbessern (ohne Erfolg).

Zweiter Versuch (Claude Agent)

Für den zweiten Versuch habe ich zuerst den Claude Agent heruntergeladen und mit meinem Claude-Konto verknüpft. Gleicher Prompt, also:

Prompt: create a simple break out game as an iOS app

Der erste Unterschied zum vorigen Beispiel besteht darin, dass der Claude Agent über das Problem zuerst nachdenkt und eine To-do-Liste erstellt. Diese arbeitete er dann Punkt für Punkt ab.

Der Code fällt mit ca. 350 Zeilen deutlich umfangreicher aus. Er ist in den beiden neuen Dateien BreakOutGame.swift und BreakOutGameView.swift deutlich besser organisiert. Der Code trennt zwischen Datenmodell und View. (Auf eine vollständige Realisierung des MVVM-Musters hat der Claude Agent aber verzichtet.) Der Code funktioniert auf Anhieb und ist frei von offensichtlich veralteten Funktionen. Auch die Performance ist deutlich besser.

Xcode kritisiert allerdings zwei Main-actor-Isolation-Probleme (Warnungen, keine Errors).

Prompt: there are two main actor isolation warnings; fix them

Claude gelingt es auf Anhieb, die Probleme zu beheben (Respekt!).

Eine weitere Analyse des Codes ergibt: Der Code ist OK, aber nicht ausgezeichnet. Der SwiftUI-Pro-Skill (mehr dazu in einem zweiten Blog-Artikel) kritisiert z.B. die Verwendung eines Timers für den GameLoop und schlägt stattdessen TimeLineView(.animation) vor.

Beispiel 3: Vorhandenen Code bearbeiten/erweitern (Claude Agent)

Im dritten Beispiel habe ich das einigermaßen komplexe Cart-Projekt aus meinem Swift-Buch geladen (siehe Kapitel 25). In ca. 2000 Zeilen Code, die über ein Dutzend Dateien verteilt sind, realisiert die App die Verwaltung einer Einkaufsliste, die mittels eines Backends (REST-API) über mehrere Familienmitglieder synchronisiert wird.

Mein erster Prompt sah so aus:

Prompt: /init

Dieses Claude-Code-typische Kommando analysiert die Code-Basis und erstellt die Datei CLAUDE.md mit einer Zusammenfassung über die Organisation des Codes. Damit tut sich der Claude Agent bei weiteren Aufrufen leichter, sich im Code zu orientieren, und muss diesen Schritt nicht wiederholen. Die Datei landet direkt im Projektverzeichnis und ist deswegen im Projektnavigator (der eine Ebene tiefer ansetzt) unsichtbar.

Der Claude Agent lädt diese Datei bei zukünftigen Sessions automatisch. In der Regel ist es zweckmäßig, die Datei durchzulesen und bei Bedarf eigene Erweiterungen durchzuführen. Ich habe bei diesem Test aber darauf verzichtet.

Als Nächstes habe ich in den Projekteinstellungen Default Actor Isolation = MainActor eingestellt (siehe auch den Blog-Artikel Swift 6.2 und Xcode 26.1).

Prompt: This app now uses Default Actor Isolation = MainActor. Remove no longer necessary main actor attributes.

Es gibt nur eine Stelle im Code. Claude Agent findet sie und entfernt das nun überflüssige Attribut.

In der Praxis haben sich die Synchronisationseinstellungen der App als zu groß herausgestellt. Die App speichert Änderungen alle 40 Sekunden. Wenn lokal nichts geändert wird, werden Remote-Änderungen sogar nur alle 10 Minuten durchgeführt. Der folgende Prompt führt direkt zum Ziel, obwohl ich Claude keinerlei Informationen gebe, wo sich die relevanten Einstellungen befinden.

Prompt: change the sync settings; I want to write changes after 20 seconds, read remote changes every 30 seconds

Die UI der App ist in einer TabView über drei Tabs verteilt. Ich möchte, dass die App auch bei jedem Tab-Wechsel eine Synchronisation durchführt. Wiederum findet der Claude Agent sofort die richtige Stelle im Code und baut dort einen asynchronen Aufruf der Sync-Methode ein.

Prompt: I also want to sync on every tab change.

Prompt: I want the app to also sync when it is disabled (switch to another app). There is already code for this, but it does not work reliable.

Claude Agent verbessert den Code entsprechend.

Prompt: update the version to 1.0.2

Prompt: ok. can you also update it in the target settings?

Hier kommt Claude an seine Grenzen. Er findet zwar eine Zeichenkette im Code, die er von 1.0.1 auf 1.0.2 ändert. Aber die Xcode-Einstellungen Target / Identity / Bundle Identifier kann es nicht ändern und bittet darum, diesen Schritt selbst zu erledigen.

Meine relativ einfachen Prompts verschleiern, wie weit Agentic Coding geht. Paul Hudson geht in seinem YouTube-Video aufs Ganze und beginnt mit einem Prompt, um eine Schach-Spiel-App zu programmieren. Eine viertel Stunde später ist die App soweit fertig, dass ein erstes Spiel möglich ist. Derartige Mammut-Prompts sind aber selten zweckmäßig. Gehen Sie Schritt für Schritt vor (wobei ein Schritt durchaus die Implementierung eines neuen Features sein kann), testen Sie die App, führen Sie einen Commit durch!

Xcode vs. Claude Code

Apple hat sich mit der Integration von KI-Tools in Xcode viel Zeit gelassen. Außerhalb des Apple-Universums hat sich mehr bewegt. Der aus meiner Sicht gerade spannendste Weg zur Programmierung von Swift-Apps ist heute das Command Line Interface (CLI) Claude Code.

Die Vorgehensweise sieht so aus: Sie erzeugen/laden mit Xcode Ihr Projekt. Gleichzeitig öffnen Sie ein Terminal, wechseln in das Projektverzeichnis und starten dort Claude Code. Durch Prompts weisen Sie Claude Code an, welche Funktionen es entwickeln soll. Xcode bleibt offen, Sie verwenden die IDE aber nicht (oder nur in Ausnahmefällen) zum Programmieren, sondern dazu, den von Claude Code produzierten Code zu lesen und die resultierende App zu testen bzw. auszuprobieren.

Diese Vorgehensweise ist ungewohnt, aber effizient. Manche Entwickler sind der Ansicht, der größte Vorteil moderner KI-Tools bestünde darin, dass Xcode nicht oder zumindest nur noch am Rande benötigt wird.

Im Vergleich zu den integrierten KI-Tools in Xcode bietet Claude Code diverse Zusatzfunktionen. Enorm hilfreich ist die Möglichkeit, Skills und MCP-Server zu nutzen. Das für mich wichtigste Feature ist aber der Planungsmodus (Ein-/Ausschalten mit Shift+Tab): Er gibt Ihnen die Möglichkeit, ein neues Feature in Ruhe zu planen, ohne den Code dabei anzurühren. Erst wenn Sie mit dem von Claude Code präsentiertem Plan vollständig zufrieden sind, beginnen Sie mit der Realisierung.

Erfreulicherweise unterstützt Xcode ab Version 26.3 auch externe KI-Tools und stellt diesen via MCP dieselben Funktionen wie internen KI-Tools zur Verfügung. Dazu müssen Sie in den Xcode-Einstellungen Intelligence / Allow external agents to use Xcode tools aktivieren. Die Kommandos, um den Xcode-Server in Claude Code bzw. in Codex einmalig einzurichten, sehen so aus (Dokumentation von Apple):

claude mcp add --transport stdio xcode -- xcrun mcpbridge
codex mcp add xcode -- xcrun mcpbridge

Damit der Aufruf von mcpbridge funktioniert, muss in den Xcode-Einstellungen unter Locations die richtige Xcode-Version eingestellt sein. Bei mir war der Eintrag ursprünglich leer (keine Ahnung warum), der MCP-Aufruf scheiterte deswegen.

Wenn Claude Code oder ein anderes externes KI-Tool MCP-Funktionen nutzen will, müssen Sie das vorher bewilligen.

Sind alle Voraussetzungen erfüllt, schreiben Sie die Prompts in Claude Code und verwenden Xcode nur noch, um den Code anzusehen bzw. Ihre App zu testen.

Sonstiges

• Auch Xcode 26.3 verwendet Swift 5 per Default. Wenn Sie Swift 6 wünschen, müssen Sie die Build Settings ändern. (Update 31.3.2026: Auch Xcode 26.4 bleibt bei Swift 5.)
• Der in Xcode 26 eliminierte Attribute Inspector ist nicht zurückgekommen. Das gilt auch für diverse andere UI-Elemente (z.B. die Refactor-Kommandos Extract Subview oder Embed in Xxx), die es früher in Xcode gab und die mit Version 26 verschwunden sind.
• Die aktuelle Swift-Version lautet — unverändert seit September 2025 — 6.2. (Genau genommen sind wir bei 6.2.4, aber es gibt seit einem halben Jahr keine nennenswerten Neuerungen.)

Quellen/Links

• https://developer.apple.com/documentation/xcode-release-notes/xcode-26_3-release-notes
• https://www.apple.com/newsroom/2026/02/xcode-26-point-3-unlocks-the-power-of-agentic-coding
• https://developer.apple.com/documentation/Xcode/setting-up-coding-intelligence
• https://developer.apple.com/documentation/xcode/giving-agentic-coding-tools-access-to-xcode
• https://zenvanriel.com/ai-engineer-blog/apple-xcode-agentic-coding-mcp-guide/
• https://kofler.info/ki-skills-fuer-swift/

Videos zum Thema »Agentic Coding mit Xcode 26.3«

• https://developer.apple.com/videos/play/tech-talks/111428/ (KI-Crashkurs, 5 Minuten)
• https://www.youtube.com/watch?v=QdpaI_j0FRU (30-minütiges Video von Stewart Lynch)
• https://www.youtube.com/live/sc6pvW6vQzA (zweistündiges Video von Paul Hudson, zwar mit einigem Leerlauf, aber dennoch empfehlenswert; behandelt auch Claude Code)

Wahlprüfstein Freie Software

Wahlprüfstein Freie Software

Do-FOSS hat den folgenden Wahlprüfstein organisiert, um die politische Meinungsbildung im derzeitigen Kommunalwahlkampf (in NRW) in Bezug auf Freie Software zu fördern. Im Folgenden veröffentlicht Do-FOSS die Fragen und die Antworten der Dortmunder Parteien Bündnis 90/DIE GRÜNEN, CDU, DIE LINKE., FDP, Piratenpartei und SPD. Do-FOSS freut es sehr, dass alle OB-Kandidat*innen Freie Software positiv sehen. Dies passt zum Leitbild zur Digitalisierung der Stadt Dortmund. Darin heißt es, dass Offenheit und Transparenz bereits auf der Ebene der Algorithmen umzusetzen sind. Dortmund und Freie Software gehören zusammen.

Fragen von Do-FOSS

Folgende Fragen wurden von Do-FOSS gestellt:

1. Als Initiative fordern wir von unserer Stadtverwaltung die Nutzung von Freier Software / Open-Source-Software und Offenen Standards. Damit wollen wir digitale Souveränität fördern und die Krisensicherheit der Stadt Dortmund stärken. Wir setzen uns mit Freier Software für Transparenz, einen effektiven Datenschutz und eine selbstbestimmte, herstellerunabhängige Digitalisierung ein. Wir wollen digitale Teilhabe hürden- und barrierefrei gestalten, sodass alle Menschen mit der Software und dem Endgerät ihrer Wahl die Dortmunder Verwaltung erreichen können. Dies wird auf technischer Ebene durch Offene Standards verwirklicht.

   Wollen Sie den Einsatz von Freier Software und Offenen Standards als Bausteine für digitale Souveränität unterstützen?

2. Wir denken, öffentliche Gelder (Steuergelder) sollen öffentliche Güter erzeugen. Im Fall von Software heißt dies, dass die Öffentlichkeit über den Quellcode von öffentlich finanzierter Software verfügen kann. Dies gewährleistet, dass die Verwaltung keinen privaten Verwertungsinteressen folgen muss. Dieses Ziel verfolgt die Kampagne Public Money? Public Code! der Free Software Foundation Europe.

   Welche Haltung haben Sie zu dem Grundsatz „Public Money? Public Code!“?

3. Mit Freier Software kann aus unserer Sicht der IT-Standort Dortmund gestärkt werden, denn Geschäftsideen können vor Ort entwickelt werden. Bei Freier Software ist der Marktzugang offen und nicht durch Monopolrechte eingeschränkt. Startups und lokale Softwareanbieter werden damit in die Lage versetzt, Lösungen für die öffentliche IT-Infrastruktur anzubieten, und können gezielt in die städtische Wirtschaftsförderung einbezogen werden.

   Sehen Sie Freie Software als Teil einer Strategie zur Wirtschaftsförderung des IT-Standorts Dortmund?

Antworten der OB-Kandidat*innen im Wortlaut

Die Antworten der Parteien folgen in alphabetischer Reihenfolge nach Parteinamen.

Bündnis 90/DIE GRÜNEN, Daniela Schneckenburger

Logo von Bündnis 90/DIE GRÜNEN (© Bündnis 90/DIE GRÜNEN)

1. Wir GRÜNE unterstützen den Einsatz Freier Software und Offener Standards schon seit langem auf vielfältige Weise. Unter anderem haben wir unser Parteibüro weitestgehend auf Open-Source-Software umgestellt. Explizit schreiben wir im Wahlprogramm zur Kommunalwahl 2020: „Wir fordern die Nutzung von Open-Source-Software und Offenen Standards. Damit fördern wir die digitale Souveränität und stärken die Krisensicherheit der Stadt Dortmund. Wir setzen uns mit Open-Source-Software für Transparenz, Datenschutz und das Recht auf informationelle Selbstbestimmung in der Datenverarbeitung ein.“

   Daneben setzen wir uns dafür ein, dass sämtliche Daten, die durch die Stadt bereitgestellt werden können, in offenen Standards verarbeitet werden, so dass keine Herstellerabhängigkeit erzeugt wird. Das Open Data Portal wollen wir erweitern und die Daten einfacher verfügbar machen. Das Loslösen von Herstellerabhängigkeiten ist auch bei der Weiterentwicklung und Anpassung bestehender Software möglich, wenn der aktuelle Hersteller ein Programm nicht mehr weiterentwickeln kann oder will. Gerade in sensiblen Bereichen wie Smart City kann durch Open-Source-Software das Vertrauen in den Datenschutz sichergestellt werden. Der Erfolg der Corona-Warn-App überzeugt uns zusätzlich.

2. Wir unterstützen den Grundsatz „Public Money – Public Code“ und die Ziele der Initiative explizit.

3. Freie Software kann Teil der Wirtschaftsförderung sein. Mit dem Ausschreiben von Softwareprojekten, die zu Open-Source-Software wird, können Aufträge kleinteiliger und spezialisierter vergeben werden. Dies bietet – neben den oft größeren Firmen, die die Basis-Software bereitstellen – insbesondere auch kleineren IT-Unternehmen die Möglichkeit, mit passgenauen Anwendungen weitergehende Spezialbedarfe abzudecken. Zusätzlich bietet sich die Chance herstellerunabhängiger Wartung und Fehlersuche. Wir wollen lokale Unternehmen von den Vorteilen von Open-Source-Entwicklungen überzeugen und dafür als Vorbild vorangehen.

CDU, Dr. Andreas Hollstein

Logo der CDU (© CDU)

1. Ja. Die CDU hat dazu den Sachstandsbericht zur Untersuchung des Potentials von Freier Software und Offenen Standards (Drucksache 16108-19) am 30.01.2020 im Ausschuss für Personal und Organisation des Rates zustimmend zur Kenntnis genommen. Die dort beschriebenen Inhalte tragen wir mit und sind daher gespannt auf den Ergebnisbericht zum Einsatzpotential Freier Software und Offener Standards, der bis Mitte 2022 den politischen Gremien vorgelegt werden soll.

2. Wir begrüßen die Veröffentlichung als Open Source von im öffentlichen Auftrag entwickelter Software. Derzeitige gesetzliche Regelungen, die einer kostenfreien Weitergabe von mit Steuergeldern erstellten Gütern entgegenstehen, müssen auf Bundesebene in diesem Sinne angepasst werden. Allerdings wird der kleinste Teil der in öffentlichen Einrichtungen eingesetzten Software in deren Auftrag entwickelt. In der großen Zahl der Fälle wird kommerziell angebotene Software eingekauft und gemäß den Bedürfnissen der Institution angepasst. Prüfenswert ist hier die Überlegung, finanzielle Ressourcen in die bedarfsgerechte Weiterentwicklung von Open Source Projekten zum Einsatz in der Verwaltung zu stecken, als kommerzielle Produkte anzupassen.

3. Ja. Dortmund ist bundesweit ein prominenter IT-Standort. Ausweis hierfür sind bspw. die TU und FH, die B1ST Software-Factory und viele Dortmunder IT-Unternehmen. In den kommenden Jahren wird am Dortmunder Hafen der Campus für Digitales entstehen, der den IT-Standort Dortmund weiter stärken wird. Im Sinne einer 360°-Betrachtung des Themas IT, ist es für uns selbstverständlich, dass auch die Freie Software ein Teil der Dortmunder-IT-Wirtschaftsförderungsstrategie sein muss.

DIE LINKE., Utz Kowalewski

Logo von DIE LINKE. (© DIE LINKE.)

1. Unsere Fraktion hat die Einführung freier Software in den letzten beiden Wahlperioden konsequent unterstützt und auch aktiv eingefordert. Dies wollen wir auch in Zukunft weiterführen. In unserem Wahlprogramm für die kommende Wahlperiode heißt es: „DIE LINKE fordert die Umstellung der Stadtverwaltung auf Open-Source-Programme. Open Source heißt, dass jede*r den Quellcode des Computerprogramms einsehen, verändern und ihren*seinen Bedürfnissen anpassen kann. Nur wer den Quellcode kennt, kann sagen, was ein Programm wirklich tut. Daher kann die Stadt nur so die Datensicherheit ihrer Einwohner*innen garantieren. Sie spart Lizenzgebühren und macht sich herstellerunabhängig.“

2. Die Stadtverwaltung ist auch im Bereich der IT finanziell nicht auskömmlich. Allerdings wird der in Dortmund geleistete Aufwand durch die kostenpflichtige Weitergabe von selbst erstellter Software zum Einsatz in einigen Nachbarkommunen reduziert. Alle sicherheits- und datenschutzrelevanten Programme im Kundenkontakt sollten als Open Source auch zur Überprüfung durch Dritte verfügbar sein. DIE LINKE begrüßt daher die Kampagne der Free Software Foundation. Auch hinsichtlich der Freigabe von öffentlichkeitsrelevanten Daten wie den Geoinformationsdaten sind wir eindeutig: Wir wollen diese Daten öffentlich zugänglich machen. Langwierige Antragsstellungen werden so überflüssig. Bauvorhaben und Planungen können beschleunigt werden.

3. Wir halten es für sinnvoll, wirtschaftliche Ökosysteme mit Hilfe von kleineren IT-Unternehmen und Startups zu schaffen, die sich rund um die Dortmunder Stadtverwaltung und die kommunalen Betriebe als größten Arbeitgeber der Region orientieren. Die von der Wirtschaftsförderung initiierte Smart City Allianz deckt diesen Bereich nicht ab, sondern steht durch seine strenge Unterordnung unter die Interessen einiger weniger IT-Großkonzerne im Gegensatz zu dieser Idee.

FDP, Michael Kauch

Logo der FDP (© FDP)

1. Ja. Gerade die öffentliche Verwaltung sollte hier als Vorbild voran gehen. Die Vorteile liegen auf der Hand: Man denke nur an den Aspekt des Vertrauens, den man bei der Corona-Tracing-App beobachten konnte, oder auch schlicht an die Tatsache, dass mögliche IT-Sicherheitslücken schneller gefunden werden können.

2. Dem stimmen wir zu. Darüber hinaus stehen wir auch für Open Data und Open Government ein, also für die Veröffentlichung von nicht-unternehmensbezogenen und nicht-personenbezogenen Daten der Verwaltung in maschinenlesbarer Form. Dies sorgt für mehr Transparenzund stärkt die Demokratie.

   Deshalb haben wir folgenden Punkt in unser Wahlprogramm aufgenommen: „Um Smart City-Ansätze in Dortmund Wirklichkeit werden zu lassen, fordern die Freien Demokraten die umfangreiche Bereitstellung kommunal gesammelter Daten im Rahmen eines Open Data-Projekts. Dabei sind höchste Datenschutzstandards einzuhalten und Datensicherheit zu gewährleisten.“

3. Wir sehen Freie Software als einen wichtigen Treiber für Innovation und Wettbewerb. Darüber hinaus wollen wir die Datensilos der öffentlichen Verwaltung aufbrechen und die dort liegenden nicht-unternehmensbezogene und nicht-personenbezogene Daten in maschinenlesbarer Form zu veröffentlichen. Denn auch das kann Triebfeder für innovative Geschäftsideen sein.

   Zu einer Strategie kann dies beispielsweise werden, wenn sich die öffentliche Verwaltung bei der Beschaffung von IT-Lösungen auf Open Source Projekte konzentriert und am besten darüber hinaus auch jungen Unternehmen bzw. Start-Ups eine Chance gibt.

Piratenpartei, Christian Gebel

Logo der Piratenpartei (© Piratenpartei)

1. Wir unterstützen den Einsatz Freier Software und offener Standards in allen Lebensbereichen, natürlich auch in der öffentlichen Verwaltung. Dort sogar besonders, denn das Wohl des von der öffentlichen Hand verwaltete Gemeinwesen darf nicht abhängig sein von den Interessen weniger Software-Hersteller. Deshalb fordern wir, dass eine anerkannt freie Lizenz und der Datenaustausch mittels offener Standards wichtige Bestandteile des Kriterienkatalogs bei Ausschreibungen von Software-Produkten werden.

2. Wir fordern nicht nur “Public Money? Public Code!”, sondern auch “Public Money? Public Media!” und “Public Money? Public Data!”. Wenn die öffentliche Verwaltung die Erzeugung von Code, Medieninhalten oder datenschutzrechtlich unbedenklichen Daten beauftragt, muss das Produkt der Öffentlichkeit zur freien Verfügung stehen. Und je mehr Kommunen nach diesen Grundsätzen handeln, desto mehr profitiert die Allgemeinheit.

3. Freie Software ermöglicht einen besonders niedrigschwelligen Einstieg in die IT. Freie Software wächst aber auch mit den Anforderungen und ist daher prädestiniert für den Aufbau von Unternehmen. Wir fordern daher den Aufbau eines Kompetenzzentrums Freie Software bei der Dortmunder Wirtschaftsförderung und die enge Zusammenarbeit mit den ortsansäßigen Hochschulen auf diesem Gebiet.

SPD, Thomas Westphal

Logo der SPD (© SPD)

1. Es trifft ohne Zweifel zu, dass seit Jahren Hardware immer kostengünstiger pro Leistung wird, während Softwareprodukte gleichzeitig bei teureren Lizensierungsmodellen immer größer, langsamer und weniger leistungsfähig werden – das Preis-Leistungsverhältnis also hier sinkt. Deswegen ist auch ein wachsender Trend zum Open Source nicht weiter überraschend und deshalb halte ich es auch für richtig, wenn die Stadt Dortmund sich hier stärker engagiert.

   Der Schritt die gemeinsame Arbeitsgruppe, der auch Sie angehören, nach der Potentialanalyse nunmehr um den CIO und weitere Akteure zu erweitern und die Entwicklungsanalyse auch durch Beteiligungsformate zu öffnen, halte ich für absolut richtig. Denn, wie Sie wissen, hängt am Ende die Qualität freier Software von der Community ab und die muss dann in Dortmund breiter einbezogen werden. Vielleicht wäre es sinnvoll, wenn sehr konkrete Problemstellungen von städtischen Usern im Rahmen solcher Open Government Konferenzen in Dortmund durch diese Community einmal exemplarisch gelöst werden, um Potentiale und Schwachstellen an eben realen Fragestellungen aufzuzeigen. Ich denke, dass beide Seiten nämlich hier noch mehr Verständnis füreinander entwickeln müssen und dazu braucht es die richtigen Formate. Als Thema für ein solches erstes Testfeld sehe ich derzeit den Bildungsbereich, bei dem nicht zuletzt die Coronakrise große Schwächen aufgezeigt hat.

2. Wie Sie wissen, besteht nicht bei allen öffentlichen Gütern automatisch gleich ein Anspruch auf kostenlose Nutzung (wir unterscheiden durchaus zum Beispiel bei Straßen zwischen PKW und LKW, also privater und kommerzieller Nutzung). In diesem Fall wäre das ähnlich aus meiner Sicht zu sehen. Wenn es zum Beispiel um öffentliche Auditierung und Verbesserung von Digitaler Infrastruktur oder öffentliche Entwicklung geht, dann wäre das so offen handzuhaben. Sollte aber zu beobachten sein, dass nicht lokale oder regionale Unternehmen etwas kommerziell nutzen, dann müsste man von Fall zu Fall entscheiden, wie man damit umgehen will.

3. Open Source ist bei der Wirtschaftsförderung natürlich ein Thema, allerdings weitaus stärker in Bezug auf Entwicklung in Unternehmen und das ist für die Dortmunder Digitalwirtschaft auch der deutlich größere Markt. Für diese Digitalunternehmen sind bei Open Source im Bereich der Stadt weitaus mehr die Kenntnis über potentielle Schnittstellen und daraus resultierende Anwendungen interessant. Natürlich besteht seitens der Wirtschaftsförderung das Interesse, dass solche Potentiale dann auch lokal ausgeschöpft werden. Nicht zu unterschätzen ist hierbei allerdings, dass durchaus auch Anbieter aus anderen Regionen und Ländern hier sofort aktiv werden, so dass ohne intensive Netzwerkarbeit und Etablierung von Dortmunder Plattformen eben kein Automatismus zur Stärkung der lokalen Digitalwirtschaft besteht. Das ist aber wiederum die bundesweit anerkannte Stärke der Vernetzungsarbeit des Standorts Dortmund gewesen, so dass bei entsprechender Entscheidungen der Politik, dieses sofort auch umsetzbar wäre.

   
   Soweit im gesetzlichen Rahmen möglich verzichtet der Autor auf alle Urheber- und damit verwandten Rechte an diesem Werk.
   Es kann beliebig genutzt, kopiert, verändert und veröffentlicht werden.
   Für weitere Informationen zur Lizenz, siehe hier.

   The post Alle Dortmunder OB-Kandidat*innen wollen Freie Software appeared first on Do-FOSS.