Mit ein wenig Verspätung ist Fedora 43 fertig. Ich habe in den letzten Monaten schon viel mit der Beta gearbeitet und war schon damit überwiegend zufrieden. Fedora 43 ist das erste weitgehend X-freie Release (X wie X Window System, nicht wie Twitter …), es gibt nur noch XWayland zur Ausführung von X-Programmen unter Wayland. Relativ neu ist das Installationsprogramm, auf das ich gleich näher eingehe. Es ist schon seit Fedora 42 verfügbar, aber diese Version habe ich in meinem Blog übersprungen.

Die folgenden Ausführungen beziehen sich auf Fedora 43 Workstation mit Gnome.

Installation

Das Installationsprogramm beginnt aus deutschsprachiger Sicht gleich mit einem Ärgernis: Zwar kann die Sprache mühelos auf Deutsch umgestellt werden, nicht aber das Tastaturlayout. Dazu verweist das Installationsprogramm auf die Systemeinstellungen. Dort müssen Sie nicht nur das gewünschte Layout hinzufügen, sondern auch das vorhandene US-Layout entfernen — vorher ist das Installationsprogramm nicht zufrieden. Das ist einigermaßen umständlich.

In virtuellen Maschinen wird bei der Installationsmethode (gemeint ist die Partitionierung des Datenträgers und das Einrichten der Dateisysteme) nur eine Option angezeigt: Gesamten Datenträger verwenden. Damit haben Sie weder Einfluss auf die Größe der Partitionen noch auf den Dateisystemtyp oder dessen Optionen. Das Standardlayout lautet: EFI-Partition (vfat), Boot-Partition (ext4) und Systempartition (btrfs mit zwei Subvolumes für / und /home und aktiver Komprimierung). Eine Swap-Partition gibt es nicht, Fedora verwendet schon seit einiger Zeit Swap on ZRAM.

Wenn Sie die Installation auf einem Rechner durchführen, auf dem schon Windows oder andere Linux-Distributionen installiert sind, wird die Auswahl größer:

• Die Option Share disk with other operation systems (vielleicht wird der Text bei späteren Versionen noch übersetzt) erscheint, wenn das Setup-Programm Windows oder andere Linux-Distributionen auf der SSD rkennt. In diesem Fall nutzt Fedora den verbleibenden freien Platz auf der SSD und richtet dort eine Boot- und eine Systempartition ein. Wenn es auf der SSD keinen oder zu wenig Platz gibt, sollten Sie zusätzlich die Option Zusätzlichen Speicherplatz zurückgewinnen aktivieren. Sie können dann in einem weiteren Dialog einzelne Partitionen löschen oder verkleinern.

• Gesamten Datenträger verwenden löscht alle vorhandene Partitionen und richtet dann wie oben beschreiben EFI-, Boot- und Systempartition ein.

• Zuweisung des Einhängepunkts bietet Linux-Profis die Möglichkeit, schon vorhandene Dateisysteme zu nutzen. Es gibt zwei Möglichkeiten, diese Dateisysteme einzurichten. Eine bietet der über den unscheinbaren Menü-Button erreichbare Speicher-Editor. Dort können Sie Partitionen, Logical Volumes, RAID-Setup und Dateisysteme samt Verschlüsselung einrichten. Es mangelt nicht an Funktionen, aber leider ist die Bedienung sehr unübersichtlich. Alle hier initiierten Aktionen werden sofort durchgeführt und können nicht rückgängig gemacht werden. Alternativ können Sie vorweg in einem Terminal mit parted Partitionen einrichten und dann mit mkfs.xxx darin die gewünschten Dateisysteme anlegen. Falls das Dateisystem verschlüsselt werden soll, müssen Sie sich auch darum selbst kümmern (Kommando cryptsetup). Das erfordert ein solides Linux-Vorwissen.

In der Speicher-Konfiguration können Sie das Dateisystem verschlüsseln (außer Sie haben sich im vorigen Schritt für die Zuweisung des Einhängepunkts entschieden). Zur Verschlüsselung geben Sie zweimal das Passwort an und stellen ein, welches Tastaturlayout beim Bootvorgang für die Eingabe dieses Passworts gelten soll.

Zuletzt zeigt das Installationsprogramm eine Zusammenfassung der Einstellungen ein. Ein Benutzeraccount samt Passwort wird erst später beim ersten Start von Gnome eingerichtet.

Alles in allem ist die Bedienung des neuen Programms zwar einfach, sie bietet aber zu wenig Optionen für eine technisch orientierte Distribution. Der aktuelle Trend vieler Distributionen besteht darin, den Installationsprozess auf Web-basierte Tools umzustellen. Die Sinnhaftigkeit erschließt sich für mich nicht, schon gar nicht, wenn dabei auch noch die Funktionalität auf der Strecke bleibt. Muss das Rad wirklich immer wieder neu erfunden werden?

Nach dem Neustart landen Sie in einen Assistenten, der bei der Grundkonfiguration von Gnome hilft: Sprache und Tastaturlayout noch einmal bestätigen, Zeitzone einstellen etc. Vollkommen missglückt ist das Dialogblatt zur Aktivierung von °Drittanbieter-Softwarequellen°. Gemeint sind damit die RPM-Fusion-Paketquellen mit Paketen und Treibern (z.B. für NVIDIA-Grafikkarten), die nicht dem Open-Source-Modell entsprechen. Im Zentrum des Bildschirms befindet sich ein Toggle-Button mit den Zuständen aktivieren oder deaktivieren. Es ist unmöglich zu erkennen, ob Sie den Button zur Aktivierung drücken müssen oder ob dieser den Zustand »bereits aktiv« ausdrückt. (Auflösung: Sie müssen ihn nicht drücken. Wenn mit blauem Hintergrund »aktivieren« angezeigt wird, werden die zusätzlichen Paketquellen mit Weiter eingerichtet.)

Erst jetzt werden Sie dazu aufgefordert, einen Benutzer einzurichten, der dann auch sudo-Rechte erhält. Sobald Sie alle Daten samt Passwort festgelegt haben, können Sie sich einloggen und mit Fedora loslegen.

Um den Hostname hat sich weder das Installationsprogramm noch der Setup-Assistent gekümmert. Außerdem sollten Sie gleich ein erstes Update durchführen:

sudo hostnamectl set-hostname <name>
sudo dnf update

Die Partitionierung eines zuvor leeren Systems sieht so aus:

lsblk

  NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
  zram0  251:0    0  3,8G  0 disk [SWAP]
  vda    253:0    0   32G  0 disk 
  ├─vda1 253:1    0  600M  0 part /boot/efi
  ├─vda2 253:2    0    1G  0 part /boot
  └─vda3 253:3    0 30,4G  0 part /home
                                  /

cat /etc/fstab

  UUID=8ecb5756-a227-47e4-bb45-bf7087952ff5   /         btrfs subvol=root,compress=zstd:1 0 0
  UUID=32281370-1a5c-4440-8e16-60715e191080   /boot     ext4  defaults 1 2
  UUID=E969-E24F                              /boot/efi vfat  umask=0077,shortname=winnt 0 2
  UUID=8ecb5756-a227-47e4-bb45-bf7087952ff5   /home     btrfs subvol=home,compress=zstd:1 0 0

Versionen

Die folgende Tabelle fasst die Versionen der Kernkomponenten von Fedora 43 zusammen:

Basis               Programmierung     Server
---------------     --------------     --------------------------
Kernel     6.17     bash       5.3     Apache      2.4
glibc      2.42     gcc       15.2     CUPS        2.4
Wayland    1.24     git       2.51     MariaDB   10.11 / MySQL 8.4
Gnome        49     Java        25     OpenSSH    10.0
Mesa       25.2     PHP        8.4     PostgreSQL   18
Systemd     258     Podman     5.6     Postfix    3.10
NetworkMan 1.54     Python    3.14     qemu/KVM   10.1
GRUB       2.12     Node.js     22     Samba      4.23

Die einzige Auffälligkeit ist die komplett veraltete MariaDB-Version. Aktuell ist 12.0, Debian verwendet immerhin 11.8. Die von Fedora eingesetzte Version 10.11 wurde im Februar 2023 (!!) veröffentlicht.

Dafür enthält Fedora mit Version 8.4 eine ganz aktuelle MySQL-Version. Generell steht MySQL erst seit Fedora 41 wieder regulär in Fedora zur Verfügung; ältere Versionen waren MariaDB-only.

Neuerungen

Wenn man von durch Software-Updates verbundenen optischen Änderungen absieht (z.B. in Gnome), gibt es relativ wenig technische Änderungen, und noch weniger davon sind sichtbar.

Gnome und gdm sind seit Version 49 Wayland-only. Darüber wurde in den letzten Wochen schon viel geschrieben. Seit die NVIDIA-Treiber endlich Wayland-kompatibel sind, ist der Abschied von X nicht mehr aufzuhalten. (Persönlich vermisse ich X nicht. Die meisten Linux-Anwender werden keinen Unterschied bemerken bzw. arbeiten ohnedies schon seit zwei, drei Releases mit Wayland, ohne es zu wissen …)

Fedora 43 verwendet erstmals RPM 6.0 als Basis zur Verpackung von Software-Paketen. Daraus ergeben sich neue Möglichkeiten beim Signieren von Paketen, aber an der Anwendung des rpm-Kommandos (das Sie ohnedies selten benötigen werden, es gibt ja dnf) ändert sich nichts.

Distributions-Upgrades auf die neue Fedora-Version können Sie jetzt äußerst komfortabel direkt im Gnome-Programm Software starten.

Wie bisher können Sie natürlich auch auf die folgende Kommandoabfolge zurückgreifen:

sudo dnf update
sudo dnf repolist --releasever 43
sudo dnf system-upgrade download --releasever 43
sudo dnf offline reboot

Auf UEFI-Systemen setzt das Installationsprogramm nun eine GPT-Partitionierung voraus (nicht MBR).

Die /boot-Partition wird mit 2 GiB großzügiger als bisher dimensioniert, um Platz für zukünftige neue Boot-Systeme zu schaffen.

dnf module gibt es nicht mehr, weil das Modularity-Projekt eingestellt wurde. Bei Fedora ist das weniger schade als bei RHEL, wo ich dieses Feature wirklich vermisse.

dracut, das Tool zum Erzeugen von initramfs-Dateien, verwendet nun zstd statt xz zum Komprimieren der Dateien. Das macht die Boot-Dateien größer, aber den Boot-Vorgang schneller.

Fazit

Ich habe in den letzten Monaten sehr viel unter Fedora gearbeitet. Fedora ist dabei zu meiner zweiten Lieblingsdistribution geworden (neben Arch Linux). Im Betrieb gab es eigentlich nichts auszusetzen. Auch die Distributions-Upgrades haben mehrfach gut funktioniert: Ich habe zuletzt eine physische Installation von Fedora 41 auf 42 und vorgestern auf 43 aktualisiert. Zwischenzeitlich hat sich sogar der Rechner geändert, d.h. ich habe die SSD bei einem Rechner aus- und bei einem anderen Rechner wieder eingebaut. Hat alles klaglos funktioniert.

Das neue Installationsprogramm (neu schon seit der vorigen Version, also Fedora 42) ist aber definitiv ein Rückschritt — und das alte war schon keine Offenbarung. Bevor der Installer in Zukunft unter RHEL 11 zum Einsatz kommen kann, muss Red Hat noch viel nacharbeiten. Wie soll damit ein für den Server-Einsatz übliches RAID- oder LVM-Setup gelingen?

Der oft gehörten Empfehlung, Fedora sei durchaus für Einsteiger geeignet, kann ich deswegen nur teilweise zustimmen. Im Betrieb ist Fedora in der Tat so unkompliziert und stabil wie vergleichbare Distributionen (Debian, Ubuntu etc.). Für die Installation gilt dies aber nur, wenn Sie den gesamten Datenträger — z.B. eine zweite SSD — für Fedora nutzen möchten und mit dem vorgegebenen Default-Layout einverstanden sind. Unkompliziert ist natürlich auch die Installation in eine virtuelle Maschine. Aber jeder Sonderwunsch — ext4 statt btrfs, eine getrennte /home-Partition etc. — wird sofort zum Abenteuer. Schade.

Quellen/Links

• https://www.fedoraproject.org/workstation/download
• https://docs.fedoraproject.org/en-US/fedora/latest/release-notes
• https://fedoramagazine.org/announcing-fedora-linux-43
• https://rpm.org/releases/6.0.0
• https://www.heise.de/news/Fedora-Linux-43-Adieu-X11-Hallo-WebUI-10912606.html

Es ist schon eine logistische Herausforderung, wenn ein Buch mit nunmehr zwölf Autoren auf den neuesten Stand gebracht werden soll! Das hat uns natürlich nicht abhalten können. Diese Woche wird die vierte Auflage unseres Standardwerks mit fast 1300 Seiten an die Buchhandlungen ausgeliefert. Ich glaube, wir dürfen ein wenig stolz sein :-)

Die Inhalte sind auf dem neuesten Stand, aber das Konzept ist gleich geblieben: Wir wollen in diesem Buch zeigen, wie und mit welchen Tools Hacker und Pen-Tester arbeiten. Und Ihnen in logischer Konsequenz erklären, wie Sie sich gegen Angriffe bestmöglich schützen können. Ganz bewusst lassen wir es nicht beim klassischen Netzwerk-Hacking bewenden, sondern gehen auch auf Einfallsvektoren wie Cloud, IoT, Mobile Devices usw. ein.

Für die hier vierte Auflage haben wir das Buch umfassend aktualisiert und um viele neue Inhalte erweitert. Besonders erwähnen möchten wir:

• Hacking lernen (neues Kapitel mit Fokus auf den Hacking-Einstieg)
• Absicherung von Samba (Kapitel grundlegend überarbeitet und erneuert)
• Absicherung von Microsoft 365 (neues Kapitel)
• Absicherung von KI-Anwendungen (neues Kapitel)
• Absicherung von Docker, Geoblocking mit Firewalls (nft)
• SIEM-Systeme (Wazuh, Microsoft Senitel)

Die wohl größte Neuerung im Vergleich zur vorigen Auflage besteht darin, dass KI-Tools 2022 noch exotisch waren, heute aber allgegenwärtig sind. KI-Tools werden sowohl von Hackern (Angriff) als auch zur Verbesserung der Sicherheit (Verteidigung) genutzt. Viele Kapitel enthalten Tipps und Hinweise zur Anwendung von KI-Werkzeugen.

Hier finden Sie mehr Infos zum Buch, den obligatorischen Bestell-Links sowie eine Leseprobe.

In meinem Arbeitsalltag wimmelt es von virtuellen Linux-Maschinen, die ich primär mit zwei Programmen ausführe:

• virtual-machine-manager alias virt-manager (KVM/QEMU) unter Linux
• UTM (QEMU + Apple Virtualization) unter macOS

Dabei treten regelmäßig zwei Probleme auf:

• Bei Neuinstallationen funktioniert der Datenaustausch über die Zwischenablage zwischen Host und VM (= Gast) funktioniert nicht.
• Die Uhrzeit in der VM ist falsch, nachdem der Host eine Weile im Ruhestand war.

Diese Ärgernisse lassen sich leicht beheben …

Anmerkung: Ich beziehe mich hier explizit auf die Desktop-Virtualisierung. Ich habe auch VMs im Server-Betrieb — da brauche ich keine Zwischenablage (Text-only, SSH-Administration), und die Uhrzeit macht wegen des dauerhaften Internet-Zugangs auch keine Probleme.

Zwischenablage mit Spice als Grafik-Protokoll

Wenn das Virtualisierungssystem das Grafiksystem mittels Simple Protocol for Independent Computing Environments (SPICE) überträgt (gilt per Default im virtual-machine-manager und in UTM), funktioniert die Zwischenablage nur, wenn in der virtuellen Maschine das Paket spice-vdagent installiert ist. Wenn in der virtuellen Maschine Wayland läuft, was bei immer mehr Distributionen standardmäßig funktioniert, brauchen Sie außerdem wl-clipboard. Also:

sudo apt install spice-vdagent wl-clipboard 
sudo dnf install spice-vdagent wl-clipboard
sudo pacman -S spice-vdagent wl-clipboard

Nach der Installation müssen Sie sich in der VM aus- und neu einloggen, damit die Programme auch gestartet werden. Manche, virtualisierungs-affine Distributionen installieren die beiden winzigen Pakete einfach per Default. Deswegen funktioniert die Zwischenablage bei manchen Linux-Gästen sofort, bei anderen aber nicht.

Synchronisierung der Uhrzeit

Grundsätzlich beziehen sowohl die virtuellen Maschine als auch der Virtualisierungs-Host die Uhrzeit via NTP aus dem Internet. Das klappt problemlos.

Probleme treten dann auf, wenn es sich beim Virtualisierungs-Host um ein Notebook oder einen Desktop-Rechner handelt, der hin- und wieder für ein paar Stunden inaktiv im Ruhezustand schläft. Nach der Reaktivierung wird die Zeit im Host automatisch gestellt, in den virtuellen Maschinen aber nicht.

Vielleicht denken Sie sich: Ist ja egal, so wichtig ist die Uhrzeit in den virtuellen Maschinen ja nicht. So einfach ist es aber nicht. Die Überprüfung von Zertifikaten setzt die korrekte Uhrzeit voraus. Ist diese Voraussetzung nicht gegeben, können alle möglichen Problem auftreten (bis hin zu Fehlern bei der Software-Installation bzw. bei Updates).

Für die lokale Uhrzeit in den virtuellen Maschinen ist das Programm chrony zuständig. Eigentlich sollte es in der Lage sein, die Zeit automatisch zu justieren — aber das versagt, wenn die Differenz zwischen lokaler und echter Zeit zu groß ist. Abhilfe: starten Sie chronyd neu:

sudo systemctl restart chronyd

Um die automatische Einstellung der Uhrzeit nach der Wiederherstellung eines Snapshots kümmert sich der qemu-guest-agent (z.B. im Zusammenspiel mit Proxmox). Soweit das Programm nicht automatisch installiert ist:

sudo apt install qemu-guest-agent
sudo dnf install qemu-guest-agent
sudo pacman -S qemu-guest-agent

Quellen / Links

• https://man.archlinux.org/man/spice-vdagent.1.en
• https://github.com/utmapp/vd_agent
• https://github.com/bugaevc/wl-clipboard
• https://pve.proxmox.com/wiki/Qemu-guest-agent

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?)

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.

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

Einige Wochen nach dem Release von Debian 13 »Trixie« hat die Raspberry Pi Foundation auch Raspberry Pi OS aktualisiert. Abseits der Versionsnummern hat sich wenig geändert.

Raspberry Pi Imager

Die »Installation« von Raspberry Pi OS funktioniert wie eh und je: Sie laden die für Ihr Betriebssystem passende Version des Raspberry Pi Imagers herunter und wählen in drei Schritten Ihr Raspberry-Pi-Modell, die gewünschte Distribution und schließlich das Device Ihrer SD-Karte aus. Einfacher kann es nicht sein, würde man denken. Dennoch habe ich es geschafft, auf einem Rechner mit zwei SSDs (einmal Linux, diese SSD war aktiv in Verwendung, einmal Windows) die Installationsdaten auf die Windows-SSD statt auf die SD-Karte zu schreiben. Schuld war ich natürlich selbst, weil ich nur auf das Pictogram gesehen und nicht den nebenstehenden Text gelesen habe. Der Imager hat die SSD mit dem SD-Karten-Icon garniert.

Wenn Sie möchten, können Sie im Imager eine Vorweg-Konfiguration durchführen. Das ist vor allem für den Headless-Betrieb praktisch, erspart aber auch erste Konfigurationsschritte im Assistenten, der beim ersten Start erscheint.

Versionsnummern

Raspberry Pi OS Trixie profitiert mit dem Versionssprung vom neueren Software-Angebot in Debian Trixie. Die aktuelleren Versionsnummern sind gleichzeitig das Hauptargument, auf Raspberry Pi OS Trixie umzusteigen.

Basis               Programmierung     Server
---------------     --------------     ---------------
Kernel     6.12     bash       5.2     Apache      2.4
glibc      2.41     gcc       14.2     CUPS        2.4
Wayland    1.23     git       2.47     MariaDB    11.8
NetworkMan 1.52     Java     21/25     OpenSSH    10.0
Mesa       25.0     PHP        8.4     PostgreSQL   17
Systemd     257     Python    3.13     Postfix    3.10
                                       Samba      4.22

Einheitliche Konfiguration

Die größte Änderung am Desktop »PIXEL« (vom Hintergrundbild abgesehen) betrifft die Konfiguration: Das Control Center umfasst nun auch Desktop-Einstellungen, die Bildschirm-Konfiguration und die Drucker-Konfiguration. Das ist definitiv ein Fortschritt im Vergleich zur bisher recht willkürlichen Aufteilung der Konfiguration über diverse Programme mit recht uneinheitlichem Erscheinungsbild.

gpioset

Die Syntax von gpioset hat sich geändert (vermutlich schon vor einiger Zeit, aber mir ist es erst im Rahmen meiner Tests mit Raspberry Pi OS Trixie aufgefallen):

• Der gewünschte Chip (Nummer oder Device) muss mit der Option -c angegeben werden.

• Das Kommando läuft per Default endlos, weil es nur so den eingestellten Status der GPIOs garantieren kann. Wenn Sie wie bisher ein sofortiges Ende wünschen, übergeben Sie die Option -t 0. Beachten Sie, dass -t nicht die Zeit einstellt, sondern für ein regelmäßiges Ein- und Ausschalten gedacht ist (toggle). Ich habe die Logik nicht verstanden, aber -t 0 führt auf jeden Fall dazu, dass das Kommando sofort beendet wird.

• Alternativ kann das Kommando mit -z im Hintergrund fortgesetzt werden.

Das folgende Kommando gilt für Chip 0 (/dev/gpiochip0) und somit für die »gewöhnlichen« GPIOs. Dank -t 0 wird das Kommando sofort beendet.

gpioset -c 0 -t 0  7=1   # GPIO 7 (Pin 26) auf "high" stellen
sleep 3
gpioset -c 0 -t 0  7=0   # GPIO 7 (Pin 26) auf "low" stellen

Verwenden Sie besser das Kommando pinctrl, wenn Sie GPIOs im Terminal oder in bash-Scripts verändern wollen!

Sonstiges

Raspberry Pi OS verwendet nun per Default Swap on ZRAM. Nicht benötigte Speicherblöcke werden also komprimiert und in einer RAM-Disk gespeichert. Besonders gut funktioniert das bei Raspberry-Pi-Modellen mit viel RAM.

Raspberry Pi OS wird keine Probleme mit dem Jahr 2038 haben. Die zugrundeliegenden Änderungen stammen von Debian und wurden einfach übernommen.

Dank neuer Meta-Pakete ist es einfacher, von Raspberry Pi OS Lite auf die Vollversion umzusteigen. Das ist aus Entwicklersicht sicher erfreulich, der praktische Nutzen hält sich aber in Grenzen.

Mathematica steht aktuell noch nicht zur Verfügung, die Pakete sollen aber bald nachgeliefert werden.

Auch die Software für einige HATs (KI- und TV-Funktionen) müssen erst nachgereicht werden.

Fazit

Alles in allem ist das Raspberry-Pi-OS-Release unspektakulär. Das hat aber auch damit zu tun, dass Raspberry Pi OS bereits in den letztes Releases umfassend modernisiert wurde. Zur Erinnerung: Raspberry Pi OS verwendet Wayland, PipeWire, den NetworkManager etc., verhält sich also mittlerweile ganz ähnlich wie »normale« Linux-Distributionen. Diesmal gab es einfach weniger zu tun :-)

Bei meinen bisherigen Tests sind mir keine Probleme aufgefallen. Umgekehrt gibt es aber auch so wenig Neuerungen, dass ich bei einem vorhandenen Projekt dazu rate, die Vorgängerversion Raspberry Pi OS »Bookworm« einfach weiterlaufen zu lassen. Die Raspberry Pi Foundation rät von Distributions-Updates ab, und der Nutzen einer Neuinstallation steht in keinem Verhältnis zum Aufwand. Und es nicht auszuschließen, dass mit den vielen Versions-Updates doch die eine oder andere Inkompatibilität verbunden ist.

Quellen und Links

• https://www.raspberrypi.com/software
• https://www.raspberrypi.com/news/trixie-the-new-version-of-raspberry-pi-os
• https://github.com/raspberrypi-ui/rpd-metas
• https://www.heise.de/news/Raspberry-Pi-OS-wechselt-auf-Debian-Trixie-Basis-10722458.html
• https://kofler.info/debian-13-trixie
• https://stackoverflow.com/questions/77441261/is-it-possible-for-gpioset-version-2-0-2-to-exit-immediately

Mein Raspberry Pi 5 ist mit einem SSD-Hat ausgestattet (Pimoroni, siehe Blog). Auf der SSD ist Raspberry Pi OS Bookworm installiert. Jetzt möchte ich aber Raspberry Pi OS Trixie ausprobieren. Das System habe ich mit dem Raspberry Pi Imager auf eine SD-Card geschrieben. Sowohl SSD als auch SD-Karte sind angeschlossen, die Boot-Reihenfolge ist auf SD-Card first eingestellt.

raspi-config verändert die Variable BOOT_ORDER, die im EEPROM gespeichert wird. Die Variable kann mit `rpi-eeprom-config´ gelesen werden:

rpi-eeprom-config

  [all]
  BOOT_UART=0
  WAKE_ON_GPIO=0
  POWER_OFF_ON_HALT=1
  BOOT_ORDER=0xf461

0xf461 bedeutet (die Auswertung erfolgt mit den niedrigsten Bits zuerst, also von rechts nach links):

1 - Try SD card
6 - Try NVMe
4 - Try USB mass storage
f - RESTART (loop back to the beginning)

Die Einstellung ist also korrekt, trotzdem bootet der Pi hartnäckig von der SSD und ignoriert die SD-Card. Warum?

Analyse

Schuld sind die Partition-UUIDs! Die SSD habe ich vor eineinhalb Jahren mit dem SD Card Copier geklont. Die Option New Partition UUIDs habe ich nicht verwendet, ich sah keinen Grund dazu. Jetzt liegt folgendes Problem vor: Die SSD und die vom Rasbperry Pi Imager erzeugte SD-Card haben die gleichen Partition-UUIDs!

lsblk -o NAME,PARTUUID,UUID,MOUNTPOINT

  NAME          PARTUUID     UUID                                   MOUNTPOINT
  mmcblk0                                                            
  ├─mmcblk0p1   8a676486-01  1E1E-DAB6                              /boot/firmware
  └─mmcblk0p2   8a676486-02  b8316dab-786b-45e8-815c-3d4bbf198d98    

  nvme0n1                                                            
  ├─nvme0n1p1   8a676486-01  1E1E-DAB6                               
  ├─nvme0n1p2   8a676486-02  b8316dab-786b-45e8-815c-3d4bbf198d98   /
  └─nvme0n1p3   8a676486-03  293896b6-33ee-43de-87d4-56944456cec6 

Deswegen sind die UUIDs in /etc/fstab und in /boot/firmware/cmdline.txt nicht eindeutig:

cat /etc/fstab

  proc                  /proc           proc    defaults          0       0
  PARTUUID=8a676486-01  /boot/firmware  vfat    defaults          0       2
  PARTUUID=8a676486-02  /               ext4    defaults,noatime  0       1


cat /boot/firmware/cmdline.txt

  console=serial0,115200 console=tty1 root=PARTUUID=8a676486-02 rootfstype=ext4 \
    fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles cfg80211.ieee80211_regdom=AT

Solange beide Datenträger verbunden sind, ist nicht vorhersehbar, welche Partitionen tatsächlich genutzt werden. Am einfachsten wäre es natürlich, das Kabel zur SSD vorübergehend zu trennen; das ist aber nicht empfehlenswert, weil es hierfür keinen richtigen Stecker gibt, sondern nur eine sehr filigrane Kabelpressverbindungen, die möglichst nicht anrührt werden sollte.

Lösung

Ich habe den Pi ohne SD-Karte neu gebootet und dann

• die Filesystem-UUIDs geändert,
• /etc/fstab angepasst und
• /boot/firmware/cmdline.txt ebenfalls angepasst.

Im Detail: Da die ursprüngliche Partitionierung der SSD von der SD-Karte übernommen wurde, liegt eine MBR-Partitionstabelle vor. In diesem Fall ergeben sich die Partition-UUIDs aus der Disk-ID plus Partitionsnummer. Die Disk-ID (Hex-Code mit 8 Stellen) kann mit fdisk geändert werden:

fdisk /dev/nvme0n1

  Welcome to fdisk (util-linux 2.38.1).
  Command (m for help): x.                   <-- aktiviert den Expertenmodus
  Expert command (m for help): i             <-- ID ändern
  Enter the new disk identifier: 0x1234fedc. <-- neue ID als Hex-Code
  Disk identifier changed from 0x8a676486 to 0x1234fedc.
  Expert command (m for help): r             <-- zurück ins Hauptmenü (return)
  Command (m for help): w                    <-- Änderungen speichern (write)

  The partition table has been altered.
  Syncing disks.

Mit fdisk -l vergewissern Sie sich, dass die Änderung wirklich funktioniert hat:

fdisk -l /dev/nvme0n1

  ...
  Disk identifier: 0x1234fedc

Weil der Datenträger in Verwendung ist, zeigt fdisk -l /dev/nvme0n1 weiter die alte UUID an. Sie müssen glauben, dass es funktioniert hat :-(

Bevor Sie einen Reboot machen, müssen Sie nun mit einem Editor auch /etc/fstab und /boot/firmware/cmdline.txt anpassen. In meinem Fall sehen die Dateien jetzt so aus:

cat /etc/fstab

  proc                  /proc           proc    defaults          0       0
  PARTUUID=1234fedc-01  /boot/firmware  vfat    defaults          0       2
  PARTUUID=1234fedc-02  /               ext4    defaults,noatime  0       1

cat /boot/firmware/cmdline.txt

  console=serial0,115200 console=tty1 root=PARTUUID=1234fedc-02 rootfstype=ext4 \
    fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles cfg80211.ieee80211_regdom=AT

Jetzt ist ein Reboot fällig, um zu testen, ob alles funktioniert. (Bei mir hat es im ersten Versuch NICHT funktioniert, weil ich bei fdisk das write-Kommando vergessen habe. Dann muss die SSD ausgebaut, ein USB-Gehäuse mit einem Computer verbunden und der Vorgang wiederholt werden.)

Ab jetzt sind die Partitions-UUIDs von SD-Karte und SSD voneinander unterscheidbar. Die Umschaltung des Boot-Systems mit raspi-config funktioniert, wie sie soll.

Quellen/Links

• https://kofler.info/raspberry-pi-5-mit-pcie-ssd/
• https://forums.raspberrypi.com/viewtopic.php?t=364985
• https://forums.raspberrypi.com/viewtopic.php?p=2189368#p2189368
• https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#BOOT_ORDER
• https://askubuntu.com/questions/1250224/how-to-change-partuuid

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/

Ganz frisch zu Java 25 erscheint diese Woche die fünfte Auflage meines Java-Grundkurses. Das Buch richtet sich an Schüler, Studentinnen und alle, die gerade Java lernen oder von einer anderen Programmiersprache auf Java umsteigen möchten. Im handlichen Taschenbuchformat fasst das Buch die Syntax von Java in seiner aktuellen Form zusammen. Das Buch berücksichtigt dabei die vielen in Java 25 endlich verfügbaren Vereinfachungen, die gerade Einsteigern sehr entgegenkommen.

100 Beispiele und Übungen (inkl. Lösungen!) führen von der Theorie in die Praxis. Alle Beispieldateien liegen in zwei Versionen vor, einmal aktuell zu Java 25 und einmal für ältere Java-Installationen, wie sie gerade im Schulbetrieb leider üblich sind.

Java ist 30 Jahre alt und feiert gerade das Release »Java 25 LTS«. LTS steht eigentlich für Long Time Support (von dem aber nur zahlende Kunden profitieren), aber aus meiner Sicht ist Java 25 eine spezielle Teacher’s Edition. ENDLICH ist es möglich, »Hello, World!« in drei kurzen Zeilen zu formulieren:

void main() {
    IO.println("Hello, World!");
}

Wenn Sie jetzt einwenden, dass das reichlich irrelevant ist, angesichts anderer, viel wichtiger Neuerungen für Java-Profis, dann haben Sie noch nie Java unterrichtet.

Java als »First Programming Language«

Persönlich bin ich der Meinung, dass Python als erste Programmiersprache für blutige Einsteiger und Einsteigerinnen, junge Schüler und schon etwa ältere Studentinnen besser geeignet ist. Fakt ist aber, dass immer noch viele Schulen, Fachhochschulen und Universitäten auf Java setzen. Zwei Argumente sprechen dafür:

• Die Features rund um die Objektorientierung und Typengenauigkeit sind in Java klarer ausgeprägt als in Python.

• Und im Unterschied zu deutlich moderneren Sprachen (mir kommen vor allem Swift und Kotlin in den Sinn) ist Java bis heute eine weitverbreitete Sprache, kein Nischenprodukt. Im Tiobe-Index, pendelt Java seit Jahren zwischen Platz zwei und vier. Das ist mehr als nur respektabel.

Was ist nun neu in Java 25, dass ich so euphorisch bin? Bisher sah das minimale Gerüst für das erste Java-Programm so aus:

public class Main {
    public static void main(String[] args) {
        System.out.println("Hello, World!");
    }
}

In der ersten Unterrichtsstunde haben Sie als Lehrer/Lektorin die Wahl: Entweder Sie präsentieren diese fünf Zeilen und sagen dazu: »Das könnt ihr noch nicht verstehen. Ich erkläre die Details später. Aber in den nächsten Stunden lernen wir zuerst einmal, was Variablen, Schleifen und Verzweigungen sind, und wir werden IMMER diesen Code verwenden und nur die mittlere Zeile durch anderen Code ersetzen. Der Rest ist magic dust, aber halt notwendig.«

Oder Sie versuchen zu erklären, dass Java eine objektorientierte Sprache ist, daher alles in Klassen formuliert werden muss. (Objekt versus Klasse) Dass es unterschiedliche Sichtbarkeitsebenen gibt (public). Dass der eigentliche Code in Methoden formuliert wird. Dass es aber zwei Arten von Methoden gibt, »normale« und statische. Dass an Methoden Parameter (Argumente) übergeben werden können. Das wollen wir jetzt gar nicht, aber die main-Methode ist besonders, und wir müssen dennoch String[] args angeben. Jetzt haben wir den Datentyp bzw. die Klasse String. Und Arrays. Na ja. Wir wollen etwas ausgeben: Methode println, das kann man verstehen. Aber was ist System? Und was, um alles in der Welt, ist out?

Wenn Sie schon seit drei Jahren oder drei Jahrzehnte mit Java arbeiten, werden Sie sich über all diese Details natürlich keine Gedanken mehr machen. Aber versuchen Sie sich in eine Person zu versetzen, die die ersten Zeilen Code schreibt.

Neu in Java 25

Im JDK Enhancement Proposal 512 ist zusammengefasst, wie Java vereinfacht werden kann, ohne alle Grundsätze über den Haufen zu werfen. Die Kurzfassung lautet so:

• In einfachen Fällen ist es erlaubt, auf die Deklaration von Klassen zu verzichten. Der Java-Compiler verpackt den Code dann in eine Standardklasse.

• In eben diesem Fall darf auch auf static verzichtet werden. Ohne explizite Klasse kein Objekt. Derart freistehende Methoden werden ohne Objekt angewendet, die Unterscheidung statisch und nicht statisch ist irrelevant.

• Auch die Zugriffsebenen sind irrelevant, wenn unser Programm keine expliziten Klassen hat. public entfällt.

• Der Parameter String[] args von main darf auch weggelassen werden. Dann können dann natürlich keine Parameter an main übergeben. Aber solange wir das gar nicht wollen, wozu das String-Array? Weg damit!

• Für System.out gibt es die Kurzschreibweise IO. Hier haben sich die Java-Entwickler schwer getan. Noch eleganter wäre es gewesen, auch IO wegzulassen. Aber Methoden werden ja auf Objekte angewendet, dieses Grundprinzip sollte erhalten bleiben. Und dann ist IO immer noch besser als System.out. Die Kurzschreibweise IO ist nur für print, println und readln erlaubt, nicht für printf oder format. Aber ich will jetzt nicht mäkeln.

• Die letzte Vereinfachung ist im Hello-World-Code nicht zu sehen. Es gilt ein Default-Import für alle Pakete aus dem java.base-Modul (unter anderem java.lang, java.util, java.io, java.nio, java.net, java.text und java.time) . Listen, Sets, Zufallszahlen können ohne import verwendet werden. Hurra!

Kurz zusammengefasst: In den ersten Unterrichtsstunden/-wochen, in denen Sie vermitteln wollen, was »Programmieren« heißt, was eine Variable ist, wie eine Schleife funktioniert, müssen Sie sich nicht mehr mit Java-Feinheiten beschäftigen, die für Ihre Zuhörer ohnedies noch unbegreiflich sind.

Also zumindest ich bin EXTREM glücklich mit Java 25.

Wenn Sie IntelliJ als Entwicklungsumgebung verwenden, müssen Sie darauf achten, dass Sie die neueste Version installieren und natürlich das JDK 25 zur Verfügung steht. Achten Sie auch auf die richtigen Projekteinstellungen!

Links / Quellen

Es gibt in Java 25 natürlich eine Menge weiterer Neuerungen. Dazu gibt es schon viele Artikel, so dass ich mir hier nicht die Mühe machen muss, alles zu wiederholen:

• https://www.oracle.com/news/announcement/oracle-releases-java-25-2025-09-16/
• https://openjdk.org/projects/jdk/25/
• https://heise.de/-10530625
• https://jax.de/blog/java-25-neuerungen-features-ueberblick/
• https://blog.jetbrains.com/idea/2025/09/java-25-lts-and-intellij-idea/
• https://www.happycoders.eu/java/java-25-features/

Mein persönlicher Favorit ist das folgende Video, das sich weniger mit Details beschäftigt und den Blick mehr auf Java als Ganzes wirft und dabei einen größeren Zeitraum berücksichtigt. Gavin Bierman (Mitglied der Java Platform Group bei Oracle) zeigt, wie sehr sich Java in den letzten fünf Jahren verändert hat. Sehenswert, vor allem wenn man Java nicht ständig im Detail verfolgt.

https://inside.java/2025/06/06/key-java-language-updates/

PS: Mein Java-Grundkurs erscheint in wenigen Tagen in der fünften Auflage, natürlich abgestimmt auf Java 25.

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

Debian 13 »Trixie« ist fertig. Mehrere RC-Releases sind bei mir schon ein paar Monate im Einsatz — bislang ohne jedes Problem. Insofern sieht es so aus, als würde Debian seinem Ruf für stabile, ausgereifte Releases einmal mehr gerecht. Dieser Artikel fasst in kompakter Form die wichtigsten Neuerungen zusammen.

Plattformen und Versionsnummern

Debian steht für sieben CPU-Plattformen zur Verfügung:

• Standard-PCs (x86): nur noch amd64 (i386 nur einzelne Pakete, nicht mehr als vollständige Plattform)
• ARM: arm64, armhf, armel
• PowerPC: ppc64el
• RISC-V: risvc64 (neu!)
• IBM System z: s390x

MIPS wird nicht mehr unterstützt, armel mit diesem Release zum letzten Mal.

Die folgende Tabelle fasst die Versionen der Kernkomponenten von Debian 13 zusammen:

Basis               Programmierung     Server
---------------     --------------     ---------------
Kernel     6.12     bash       5.2     Apache      2.4
glibc      2.41     gcc       14.2     CUPS        2.4
Wayland    1.23     git       2.47     MariaDB    11.8
Gnome        48     Java     21/25     OpenSSH    10.0
Mesa       25.0     PHP        8.4     PostgreSQL   17
Systemd     257     Podman     5.4     Postfix    3.10
NetworkMan 1.52     Python    3.13     qemu/KVM   10.0
GRUB       2.12     Node.js     20     Samba      4.22

Wenn Sie sich bei der Installation für KDE entscheiden, kommen QT 6.8, das KDE-Framework 6.13, Plasma 6.3.6, sowie KDE Gear 25.04 bzw. 24.12 (für die PIM Suite) zur Anwendung.

Bei Dovecot warnen die Release Notes von Debian, dass sich die Syntax von Version 2.3 zu 2.4 inkompatibel geändert hat, was zu Problemen führen wird, wenn eine vorhandene Konfiguration bei einem Update übernommen werden soll. Hier ist der Link in die Dovecot-Dokumentation zu diesem Thema.

Installation

Am Installationsablauf hat sich — zumindest optisch — nichts verändert. Die teilweise seit Jahrzehnten (!) bewährten Dialoge führen durch die Installation. Das ist nicht so elegant und intuitiv wie bei anderen Systemen, dafür können bei der Partitionierung wirklich alle erdenklichen Sonderwünsche realisiert werden. Im Wildwuchs anderer Systeme betrachte ich das Installationssystem zunehmend als Pluspunkt.

Technische Neuerungen

last-Kommando neu implementiert: Unter Linux können Sie mit last die Liste der zuletzt eingeloggten Personen ermitteln. last reboot verrät, wann der Rechner zuletzt neugestartet wurde.

Das alles funktioniert in Debian auch, aber die Implementierung ist neu. last ist jetzt ein symbolischer Link auf wtmpdb. Diese Neuimplementierung der last-Datenbank verwendet SQLite und wird über das Jahr 2038 hinaus funktionieren (was beim herkömmlichen last-Kommando nicht der Fall ist).

Analog wurde lastlog durch lastlog2 ersetzt. Mehr Details geben die Release Notes.

APT-Repository-Format deb822: Debian unterstützt die neuen *.sources-Dateien zur Beschreibung von Paketquellen. Anstelle von einzeiligen Paketbeschreibungen wie

deb     http://deb.debian.org/debian/ trixie main
deb-src http://deb.debian.org/debian/ trixie main

können die Paketquellen in einem besser lesbaren, mehrzeiligen Format dargestellt werden:

# Datei /etc/apt/sources.list.d/debian.sources
Types:      deb deb-src
URIs:       http://deb.debian.org/debian/
Suites:     trixie
Components: main
Signed-By:  /usr/share/keyrings/debian-archive-keyring.gpg

Anders als ab Ubuntu 24.04 ist das neue Format in Debian 13 nicht per Default aktiv. Alle vorhandenen Paketquellen können aber mit apt modernize-sources umgestellt werden, was bei meinen Tests gut funktioniert hat. Die neuen Repo-Dateien haben die Kennung *.sources anstelle *.list. Wenn gleichnamige Dateien existieren, haben die *.sources-Dateien Vorrang. In die Dateien können auch Signatur-Keys eingebettet werden, was den lästigen Key-Import erspart. Mehr Details liefert man sources.list.

/tmp im RAM: Das /tmp-Verzeichnis wird nun mit dem tmpfs-Dateisystem im RAM abgebildet. Das verspricht höhere Geschwindigkeit beim Umgang mit temporären Dateien, kann aber bei sehr großen Dateien zum Speicherproblemen führen. /tmp darf bis zu 50% des RAMs nutzen. Das Dateisytem wird durch systemd eingerichtet. Der Grenzwert kann mit systemctl edit tmp.mount verändert werden. Dazu bauen Sie im dafür vorgesehen Bereich die folgenden zwei Zeilen ein und verändern die Werte:

[Mount]
Options=mode=1777,strictatime,nosuid,nodev,size=50%%,nr_inodes=1m

Wenn Sie /tmp wie bisher als reguläres Verzeichnis auf der SSD/Festplatte wünschen, führen Sie systemctl mask tmp.mount aus und starten Ihr System neu.

Sicherheit: Debian-Pakete sind gegen ROP- und COP/JOP-Angriffe gehärtet (betrifft die amd64– und arm64-Architektur). Die Pakete sind speziell kompiliert, um Exploits durch Return-Oriented Programming (ROP) bzw. Call/Jump-Oriented Programming (COP/JOP) zu erschweren. Weitere Details und Links finden Sie in den Release Notes.

Geschwindigkeit: Laut einem Test von Phoronix ist Debian 13 rund 13 Prozent schneller als die Vorgängerversion.

Tipps und Tricks

Wenn Sie Debian in einer virtuellen Maschine verwenden und Text und Bilder über die Zwischenablage mit dem Host austauschen wollen, führen Sie apt install spice-vdagent aus und starten die VM neu.

Fazit

Das Debian-Projekt ist 32 Jahre alt (Projektgründung im August 1993, 0.9-Releases 1994 und 1995, Version 1.1 1996). Debian zählt damit zu den ältesten Linux-Distributionen überhaupt — und ist bis heute mehr als nur relevant: Überlegen Sie nur für eine Minute, wie die Linux-Landschaft ohne Debian aussähe! Nicht nur Millionen Debian-Anwender stünden im Regen, auch Ubuntu, Linux Mint, Raspberry Pi OS etc. würde die Basis entzogen.

Für Version 13 gilt: Debian bleibt Debian. Große technische Innovationen finden anderswo statt. Stattdessen gibt es Unterstützung für viele CPU-Plattformen und ein solides, stabiles Fundament für die tägliche Arbeit, sei es am Desktop oder in Server-Anwendungen. Und das alles frei von finanziellen Interessen. Dafür sollte jeder Linux-Fan der Debian-Community unendlich dankbar sein.

Quellen/Links

• https://www.debian.org
• https://www.debian.org/releases/trixie/release-notes
• https://www.linux-magazin.de/ausgaben/2025/06/deb822/
• https://repolib.readthedocs.io/en/latest/deb822-format.html
• https://manpages.debian.org/unstable/apt/sources.list.5.en.html
• https://doc.dovecot.org/main/installation/upgrade/2.3-to-2.4.html
• https://en.wikipedia.org/wiki/Debian

Andere Tests/Kurzberichte

• https://www.heise.de/news/Linux-Debian-13-kommt-als-Trixie-10515203.html
• https://distrowatch.com/table.php?distribution=debian
• https://www.golem.de/news/debian-13-im-test-architektur-entruempelt-optionen-erweitert-pakete-moderner-2508-198886.html (Paywall)

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

Auf meinen privaten Linux-Installationen gehe ich Flatpak- und Snap-Paketen meistens aus dem Weg. Aber damit mir keiner vorwirft, ich sei zu altmodisch, mache ich hin und wieder doch die Probe auf Exempel: Wie gut funktionieren die neuen Paketsysteme? Meine Testkandidaten waren diesmal Fedora 42 sowie zwei Ubuntu-Installationen (25.04 und 25.10 daily), jeweils auf x86_64-Rechnern.

Fedora + Flatpak

Red Hat setzt bekanntermaßen auf Flatpak als sekundäres Paketformat für Desktop-Pakete. Es gibt zwei Motiviationsgründe: Einerseits will Red Hat den Aufwand für die Wartung großer Pakete (LibreOffice, Gimp etc.) längerfristig reduzieren; andererseits soll die Software-Installation für Anwender einfacher werden, insbesondere für Programme, die nicht in den klassischen Paketquellen verfügbar sind.

In Fedora 42 sind Flatpaks optional. Per Default ist kein einziges Flatpak-Paket installiert. Die Flatpak-Infrastruktur ist aber vorkonfiguriert, inklusive zweier Paketquellen (flathub und fedora). Mit dem Gnome-Programm Software können Sie nach Desktop-Programmen suchen. Manche Programme stehen in mehreren Paketformaten zur Auswahl (z.B. Gimp wahlweise als RPM- oder Flatpak-Paket) — dann haben Sie die Wahl, welches Format Sie verwenden möchten. Außerhalb des Linux-Universums entwickelte Apps wie Google Chrome, IntelliJ, Postman, Spotify oder VSCode gibt es hingegen nur als Flatpaks.

Bei RHEL 10 ist die Ausgangssituation ähnlich wie bei Fedora: Die Infrastruktur ist da, aber es sind keine Flatpaks installiert. Falls Sie RHEL als Desktop-System verwenden möchten, ist der Druck hin zu Flatpak aber stärker. Beispielsweise bietet Red Hat LibreOffice nicht mehr als RPM-Paket, sondern nur als Flatpak an. (Für Fedora gilt dies noch nicht, d.h., Sie können LibreOffice weiterhin als RPM installieren. Schauen wir, wie lange das noch so bleibt …)

Mein »Referenztest« ist die Installation von Spotify in einem bisher leeren System (also ohne andere vorher installierte Flatpaks bzw. Snaps). Sie können die Installation in Software oder per Kommando durchführen. Ich ziehe zweiteres oft vor, damit ich sehe, was vor sich geht (Listing gekürzt):

sudo flatpak install flathub com.spotify.Client

  Required runtime for com.spotify.Client/x86_64/stable found in remote
  flathub. Do you want to install it? [Y/n]: y
  ...
  org.freedesktop.Platform.GL.default    24.08       155 MB
  org.freedesktop.Platform.GL.default    24.08extra  155 MB
  org.freedesktop.Platform.Locale        24.08       382 MB (partial)
  org.freedesktop.Platform.openh264      2.5.1         1 MB
  org.freedesktop.Platform               24.08       261 MB
  com.spotify.Client                     stable      208 MB

Für die Installation von Spotify ist ein Download von 1,6 GiB und Platz auf dem Datenträger im Umfang von 1,9 GiB erforderlich. Das ist einfach verrückt.

Einen Überblick über alle installierte Flatpaks samt Größenangaben erhalten Sie mit flatpak list -d. Das folgende Listing ist aus Platzgründen stark gekürzt. Irritierend ist, dass die Paketgrößen in keiner Weise mit den Angaben während der Installation übereinstimmen (siehe das vorige Listing).

flatpak list -d

  com.spotify.Client                   1.2.63.394  stable       14 MB 
  org.freedesktop.Platform             24.08.22    24.08       672 MB 
  org.freedesktop.Platform.GL.default  25.1.3      24.08       464 MB 
  org.freedesktop.Platform.GL.default  25.1.3      24.08extra  464 MB 
  org.freedesktop.Platform.openh264    2.5.1       2.5.1         1 MB 

Flatpak-Installationen landen im Verzeichnis /var/lib/flatpak. Die unzähligen dort angelegten Verzeichnisse und Dateien verwenden UUIDs und hexadezimale Codes als Namen. Für die Installation von Spotify auf einem zuvor leeren Flatpak-System werden mehr als 46.000 Verzeichnisse, Dateien und Links mit einem Platzbedarf von 1,9 GiB eingerichtet. Es ist nicht lange her, da reichte das für eine ganze Linux-Distribution aus!

sudo du -h -d 0 /var/lib/flatpak/

  1,9G  /var/lib/flatpak/

sudo find /var/lib/flatpak | wc -l

  46241

Immerhin teilen weitere Flatpaks die nun etablierte Infrastruktur von Bibliotheken und Basispakete, so dass der Platzbedarf bei der Installation weitere Flatpaks etwas langsamer steigt.

Beim Start beansprucht Spotify »nur« ca. 400 MiB im Arbeitsspeicher (gemessen mit free -m vor und nach dem Start des Audio-Players). Von den vielen installierten Bibliotheken wird also nur ein Bruchteil tatsächlich genutzt. Wenn Sie mit Ihren Ressourcen sparsamer umgehen wollen/müssen, führen Sie Spotify am einfachsten in einem Webbrowser aus :-)

Ubuntu und Snap

Canonical hat Snap-Pakete bereits tief in der Ubuntu-Infrastruktur verankert. Bei Ubuntu 25.10 (daily 2025-07-31) sind
mehrere wichtige Desktop-Programme als Snap-Pakete vorinstalliert: Firefox, das App-Zentrum, der Firmware-Aktualisierer sowie ein relativ neues Security Center zur Verwaltung von Snap-Zugriffsrechten. Dazu kommen die dafür erforderlichen Basispakete. Immerhin ist der Platzbedarf auf der SSD mit 1,1 GByte spürbar geringer als bei vergleichbaren Flatpaks. Ein wenig frech erscheint mir, dass apt install thunderbird mittlerweile ungefragt zur Installation des entsprechenden Snap-Pakets führt.

Im Unterschied zu Flatpaks, die rein für Desktop-Installationen gedacht sind, bietet Canonical auch eine Menge Snap-Pakete für den Server-Einsatz an: https://snapcraft.io/store?categories=server

Zur Installation von Desktop-Snaps verwenden Sie das App-Zentrum. Als einzige Paketquelle ist https://snapcraft.io/store vorgesehen. Weil schon einige Basispakete vorinstalliert sind, ist die Installation eines weiteren Pakets nicht mit so riesigen Downloads wie beim konkurrierenden Flatpak-System verbunden.

Im Terminal administrieren Sie Snap durch das gleichnamige Kommando. Mit snap install installieren Sie ein neues Paket. snap list zählt alle installierten Snap-Anwendungen auf. snap run startet eine Anwendung, snap refresh aktualisiert alle Snap-Pakete, snap remove name löscht ein Paket.

Mein Referenztest ist wieder die Spotify-Installation. Zusammen mit spotify werden auch die Pakete core20 und gnome-3-38 heruntergeladen. Der Platzbedarf für alle drei Pakete beträgt ca. 600 MiB. (Der Vergleich hinkt aber, weil ja schon diverse Snap-Basispakete installiert sind.) Nach dem Start von Spotify sind ca. 320 MiB zusätzlich im RAM belegt.

sudo snap install spotify

  spotify 1.2.63.394.g126b0d89 from Spotify installed

Die interne Verwaltung von Snaps erfolgt ganz anders als bei Flatpak. Snap-Anwendungen werden in Form von komprimierten *.snap-Dateien in /var/lib/snapd/snaps gespeichert:

ls -lh /var/lib/snapd/snaps

  ...   4,0K  ... bare_5.snap
  ...    64M  ... core20_2599.snap
  ...    74M  ... core22_2045.snap
  ...    13M  ... desktop-security-center_83.snap
  ...   246M  ... firefox_6565.snap
  ...    12M  ... firmware-updater_167.snap
  ...   350M  ... gnome-3-38-2004_143.snap
  ...   517M  ... gnome-42-2204_202.snap
  ...    92M  ... gtk-common-themes_1535.snap
  ...   4,0K  ... partial
  ...    15M  ... prompting-client_104.snap
  ...    51M  ... snapd_25227.snap
  ...    51M  ... snapd_25241.snap
  ...   576K  ... snapd-desktop-integration_315.snap
  ...    11M  ... snap-store_1270.snap
  ...   190M  ... spotify_88.snap

Der im Hintergrund laufende Snap-Dämon snapd bindet diese Dateien als squashfs-Dateisysteme an der Stelle /snap/xxx in den Verzeichnisbaum ein und macht die Anwendungen so zugänglich (alle Größenangaben in MiB):

sudo du -mcs /snap/*

   210    /snap/core20
   248    /snap/core22
    30    /snap/desktop-security-center
   644    /snap/firefox
    35    /snap/firmware-updater
   903    /snap/gnome-3-38-2004
  1294    /snap/gnome-42-2204
   360    /snap/gtk-common-themes
   417    /snap/spotify
   ...

Im Vergleich zu Flatpak sparen die komprimierten Flat-Images zwar Platz auf dem Datenträger. Allerdings speichert
Snap standardmäßig von jedem installierten Paket ein Backup mit der vorigen Version. Im Laufe der Zeit verdoppelt das den von Snap beanspruchten Speicherplatz! Um nicht mehr benötigte Pakete zu löschen, verfassen Sie das folgende Mini-Script. export LANG= stellt dabei die Spracheinstellungen zurück, damit die Ausgaben von snap in englischer Sprache erfolgen. Das Script entfernt alle Snap-Pakete, deren Status disabled ist.

#!/bin/bash
# Datei ~/bin/delete-snap-crap.sh
# Idee: https://superuser.com/questions/1310825
export LANG=
snap list --all | awk '/disabled/{print $1, $3}' |
    while read snapname revision; do
        snap remove "$snapname" --revision="$revision"
    done

Dieses Script führen Sie mit root-Rechten aus:

sudo bash delete-snap-crap.sh

Auf einem Testsystem mit diversen Snap-Paketen (Firefox, Gimp, LibreOffice, Nextcloud Client, VSCode) sank mit der Ausführung dieses Scripts der Platzbedarf in /var/lib/snapd/snaps von 7,6 auf 4,0 GiB.

Spotify als DEB-Paket

Spotify bietet seinen Client auch als Paket für Debian/Ubuntu an: https://www.spotify.com/us/download/linux/

Also habe ich einen Vergleich gemacht.

Download: ca. 150 MB
Platzbedarf auf der SSD: ca. 340 MB
RAM-Bedarf: ca. 350 MB

Fazit: RAM-Bedarf ist bei allen drei Varianten ähnlich, aber die RPM-Variante braucht weniger Platz am Datenträger.

Fazit

Ich sehe die Probleme, die herkömmliche Paketformate verursachen.

Ich verstehe auch den Wunsch nach einem universellem Paketformat, das für alle Distributionen funktioniert, das aus Anwendersicht einfach zu nutzen und das für den Software-Anbieter mit überschaubarem Wartungsaufwand verbunden ist.

Aus meiner Sicht bieten allerdings weder Flatpak noch Snap eine optimale Lösung für diese Probleme/Wünsche. Diese Erkenntnis ist nicht neu, ich habe sie in diesem Blog schon mehrfach formuliert. Die Weiterentwicklung beider Formate in den letzten Jahren hat diesbezüglich leider keine spürbaren Verbesserungen mit sich gebracht.

Bei Flatpak sind die Paketgrößen einfach absurd. Bei Snap sind sie auch zu groß, aber es ist nicht ganz so schlimm — zumindest, wenn alle Doppelgänger regelmäßig entfernt werden. Allerdings ist der Snap Store (also die Paketquelle) Closed Source, was die ohnedies schon geringe Akzeptanz nicht verbessert. Das Software-Angebot im Snap Store ist zwar größer als das auf Flathub, aber ich sehe dennoch die Gefahr, dass das Snap-Format eine Insellösung bleibt und Canonical auch mit dieser Eigenentwicklung Schiffbruch erleidet (ich sage nur Upstart Init System, Unity Desktop, Mir Display Server). Während Flatpaks außerhalb der Red-Hat-Welt zumindest als Option genutzt werden, scheint keine Distribution außer Ubuntu etwas mit Snaps zu tun haben wollen.

Letztlich ist meine Meinung natürlich irrelevant. Ubuntu ist aus meiner Sicht nach wie vor eine attraktive Distribution, sowohl am Desktop als auch am Server. Wer Ubuntu verwenden will, muss eben in den Snap-Apfel beißen. Auf einem Rechner mit einer ausreichend großen SSD und genug RAM funktioniert das gut.

Es ist unklar, ob Red Hat sein Flatpak-Format genauso vehement durchsetzen wird. Bis jetzt sieht es nicht so aus, aber es würde mich nicht überraschen, wenn auch Red Hat irgendwann keine Lust mehr hat, eigene RPM-Pakete für Firefox, Thunderbird, Gimp, Libreoffice usw. zu pflegen und parallel für diverse Distributionen (aktuell: RHEL 8/9/10, Fedora 40/41/42/Rawhide etc.) zu warten.

Vielleicht wir man sich / werde ich mic an den verrückten Ressourcenbedarf neuer Paketsysteme gewöhnen. Auf einem Rechner mit 32 GB RAM und 1 TB SSD — keine ungewöhnlichen Eckdaten heutzutage — spielen 10 GB mehr oder weniger für ein paar Flatpaks oder Snap-Pakete ja keine große Rolle … Mir widerspricht es trotzdem: Wenn es möglich ist, ein Auto zu bauen, das mit 5 Liter Treibstoff pro 100 km auskommt, warum dann eines verwenden, das 8 Liter braucht?

Quellen/Links

Flatpaks

• https://flathub.org/
• https://docs.flatpak.org/en/latest/introduction.html
• https://github.com/flatpak/flatpak/wiki/Sandbox
• https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/10.0_release_notes/removed-features

Snap

• https://snapcraft.io/store
• https://snapcraft.io/store?categories=server
• https://snapcraft.io/docs/the-snap-format
• https://snapcraft.io/docs/system-options
• https://documentation.ubuntu.com/core/explanation/security-and-sandboxing

Diskussion auf mastadon

• https://mastodon.social/@michaelkofler/114952907634895703

Die dritte Auflage unseres Git-Buchs wird gerade an die Buchhandlungen ausgeliefert. In dem Buch beschreiben Bernd Öggl und ich, wie git funktioniert und wie das Kommando in der Praxis angewendet wird. Natürlich beschränken wir uns nicht auf git an sich, sondern zeigen auch die Integration mit Git-Plattformen wie GitHub und Gitlab, erläutern zweckmäßige Workflows für Teams, diverse Arbeitstechniken (Hooks, Submodules, Subtrees, Etckeeper), gehen auf die Migration von SVN zu Git und beschreiben häufige Git-Probleme und ihre Lösung.

Wenn Sie meinen vorigen Blogbeitrag über Hetzner-Cloud-Benchmarks gelesen haben, ist Ihnen vielleicht aufgefallen, dass ich Alma Linux 10 in einer Hetzner-Cloud-Instanz ausgeführt habe, um dort Geekbench-Tests auszuführen. Das war nicht so einfach: Hetzner bietet Alma Linux 10 noch nicht als Installations-Image an. (Update 3.7.2025: mittlerweile schon, sowohl AlmaLinux 10 als auch Rocky Linux 10)

Also habe ich eine neue Instanz zuerst mit Alma Linux 9 eingerichtet und danach mit Elevate ein Update auf Version 10 durchgeführt. Das ist erstaunlich unkompliziert gelungen, obwohl Version-10-Updates eigentlich noch im Beta-Test sind.

Update 10.7.2025: Version-10-Updates werden jetzt offiziell unterstützt (Quelle)

Was ist LEAPP, was ist Elevate?

RHEL und alle Klone durchlaufen über reguläre Updates alle Minor-Releases. Wenn Sie also Alma Linux 9.0 installiert haben, erhalten Sie durch die regelmäßige Installation von Updates nach und nach die Versionen 9.1, 9.2 usw. Ein Update auf die nächste Major-Version ist aber nicht vorgesehen.

Mit LEAPP hat Red Hat ein Framework geschaffen, um Major-Version-Updates für RHEL durchzuführen. LEAPP wurde sehr allgemeingültig konzipiert und kümmert sich um Pre-Upgrade-Kontrollen, Paketabhängigkeiten, den Workflow zwischen verschiedenen Stadien des Upgrades usw.

Elevate ist eine Community-Erweiterung zu LEAPP, die über das eigentliche Upgrade hinaus in manchen Fällen auch einen Wechsel der Paketquellen zwischen Alma Linux, CentOS, Oracle Linux und RockyLinux durchführen kann. Sie können mit Elevate beispielsweise zuerst von CentOS 7 zu RockyLinux 8 migrieren und dann weiter zu Rocky Linux 9 upgraden.

Vorbereitungsarbeiten

Bevor Sie Elevate anwenden, müssen Sie ein vollständiges Backup durchführen und Ihren Rechner bzw. Ihre virtuelle Maschine neu starten:

dnf update
reboot

Danach richten Sie eine Paketquelle für Elevate ein und installieren das für Sie relevante Upgrade-Modul (für das Beispiel in diesem Artikel mit der Zieldistribution Alma Linux also leapp-data-almalinux).

dnf install -y http://repo.almalinux.org/elevate/elevate-release-latest-el$(rpm --eval %rhel).noarch.rpm

# für AlmaLinux
dnf install leapp-upgrade leapp-data-almalinux

# alternativ für Rocky Linux (etc.)
dnf install leapp-upgrade leapp-data-rocky

Als nächstes folgt ein Test, ob das gewünschte Upgrade (plus gegebenenfalls eine Migration zu einer anderen Distribution, hier nicht relevant) überhaupt möglich ist:

leapp preupgrade

leapp preupgrade erzeugt zwei Dateien: Einen umfassenden Bericht, der alle möglichen Probleme aufzählt, und eine answer-Datei, in die Sie gegebenenfalls Optionen eintragen müssen (z.B. mit leapp answer --section check_vdo.confirm=True). In meinem Fall — Upgrade einer Minimalinstallation von Alma Linux 9 auf 10, hat leapp preupgrade auf die folgenden Probleme hingewiesen, aber keine answer-Einträge verlangt.

• High: veraltete Netzwerkkonfiguration in /etc/sysconfig/network-scripts
• High: unbekannte Systemdateien (»Aktoren«)
• High: unbekannte Pakete (hc-utils)
• Medium: Berkeley DB (libdb) ist installiert, wird in RHEL 10 nicht mehr unterstützt
• Low: unbekannten Paket-Repositories

cat /var/log/leapp/leapp-report.txt

  Risk Factor: high (inhibitor)
  Title: Legacy network configuration found
  Summary: Network configuration files in legacy "ifcfg" format are present ...
      - /etc/sysconfig/network-scripts/ifcfg-eth0
  Related links:
      - How to migrate the connection from ifcfg to NetworkManager keyfile plugin?:
        https://access.redhat.com/solutions/7083803
      - nmcli(1) manual, describes "connection migrate" sub-command.:
        https://networkmanager.dev/docs/api/latest/nmcli.html
      ...
  Remediation: [hint] Convert the configuration into NetworkManager native "keyfile" format.

  ----------------------------------------
  Risk Factor: high 
  Title: Detected custom leapp actors or files.
  Summary: We have detected installed custom actors or files on the system. 
    These can be provided e.g. by third party vendors ... This is allowed 
    and appreciated. However Red Hat is not responsible for any issues caused 
    by these custom leapp actors ...
  The list of custom leapp actors and files:
    - /usr/share/leapp-repository/repositories/system_upgrade/\
       common/files/distro/almalinux/rpm-gpg/10/RPM-GPG-KEY-AlmaLinux-10
    - /usr/share/leapp-repository/repositories/system_upgrade/\
      common/files/rpm-gpg/10/RPM-GPG-KEY-AlmaLinux-10

  ...

Den vollständigen Report können Sie sich hier durchlesen.

Migration der Netzwerkkonfiguration

Wirklich kritisch war aus meiner Sicht nur die Netzwerkkonfiguration; die restlichen Hinweise und Empfehlungen habe ich ignoriert. Das Paket hc-utils (Hetzner Cloud Utilities) ist nur für Funktionen relevant, die in meinem Fall ohnedies nicht genutzt werden (siehe hier).

Auch die veraltete Netzwerkkonfiguration stammt vom Hetzner-Image für Alma Linux 9. Eine Umstellung auf eine *.nmconnection-Datei für den NetworkManager gelingt erstaunlich unkompliziert mit einem einzigen Kommando:

nmcli connection migrate /etc/sysconfig/network-scripts/ifcfg-eth0

Mit einem weiteren Reboot habe ich sichergestellt, dass die Umstellung auch funktioniert.

Das Upgrade

leapp upgrade initiiert nun das Upgrade auf Alma Linux 10. Dabei werden seitenweise Logging-Ausgaben produziert (siehe den kompletten Output mit ca. 3150 Zeilen):

leapp upgrade

  ==> Processing phase `configuration_phase` ...
  ==> Processing phase `FactsCollection` ...
  ...
  ==> Processing phase `TargetTransactionFactsCollection`
      Create custom repofile containing information about 
      repositories found in target OS installation ISO, if used.
      Initializes a directory to be populated as a minimal environment
      to run binaries from the target system.

      AlmaLinux 10.0 - BaseOS                         5.9 MB/s | 2.8 MB     00:00    
      AlmaLinux 10.0 - AppStream                       11 MB/s | 5.6 MB     00:00    
      AlmaLinux 10.0 - CRB                            5.0 MB/s | 2.2 MB     00:00    
      AlmaLinux 10.0 - HighAvailability               161 kB/s |  69 kB     00:00    
      AlmaLinux 10.0 - Extras                          28 kB/s |  12 kB     00:00    
      AlmaLinux 10.0 - SAP                            8.3 kB/s | 3.5 kB     00:00    
      AlmaLinux 10.0 - SAPHANA                         35 kB/s |  15 kB     00:00    
      AlmaLinux 10.0 - RT                             2.8 MB/s | 1.1 MB     00:00    
      AlmaLinux 10.0 - NFV                            2.8 MB/s | 1.1 MB     00:00    
      Dependencies resolved.

      ...
      Transaction Summary: Install  153 Packages
      ...
      Complete!

  ==> Processing phase `TargetTransactionCheck`
  ...
  Transaction Summary
  Install     63 Packages
  Upgrade    389 Packages
  Remove      18 Packages
  Downgrade    3 Packages
  Transaction test succeeded.
  Complete!

  ====> add_upgrade_boot_entry
        Add new boot entry for Leapp provided initramfs.

  A reboot is required to continue. Please reboot your system.

  Debug output written to /var/log/leapp/leapp-upgrade.log

  ============================================================
                        REPORT OVERVIEW                       
  ============================================================

  HIGH and MEDIUM severity reports:
      1. Packages not signed by Red Hat found on the system
      2. Detected custom leapp actors or files.
      3. Berkeley DB (libdb) has been detected on your system

  Reports summary:
      Errors:                      0
      Inhibitors:                  0
      HIGH severity reports:       2
      MEDIUM severity reports:     1
      LOW severity reports:        2
      INFO severity reports:       1

  Before continuing, review the full report below for details about discovered 
  problems and possible remediation instructions:

      A report has been generated at /var/log/leapp/leapp-report.txt
      A report has been generated at /var/log/leapp/leapp-report.json

  ============================================================
                     END OF REPORT OVERVIEW                   
  ============================================================

  Answerfile has been generated at /var/log/leapp/answerfile
  Reboot the system to continue with the upgrade. This might take a while 
  depending on the system configuration.
  Make sure you have console access to view the actual upgrade process.

Jetzt wird es unheimlich: Mit reboot starten Sie die nächste Phase des Upgrade-Prozesses, der im Blindflug erfolgt. Der Rechner bzw. die virtuelle Maschine wird während dieser Phase noch einmal neu gestartet. Wenn Sie nicht vor dem Rechner sitzen, sehen Sie weder, was passiert, noch haben Sie über eine SSH-Verbindung die Möglichkeit, einzugreifen.

reboot

Wenn alles gut geht, können Sie sich nach ein paar Minuten wieder einloggen. Bei mir hat es funktioniert:

ssh root@1.2.3.4

cat /etc/os-release

  NAME="AlmaLinux"
  VERSION="10.0 (Purple Lion)"
  ID="almalinux"
  ID_LIKE="rhel centos fedora"
  VERSION_ID="10.0"
  PLATFORM_ID="platform:el10"
  PRETTY_NAME="AlmaLinux 10.0 (Purple Lion)"
  ANSI_COLOR="0;34"
  LOGO="fedora-logo-icon"
  CPE_NAME="cpe:/o:almalinux:almalinux:10::baseos"
  HOME_URL="https://almalinux.org/"
  DOCUMENTATION_URL="https://wiki.almalinux.org/"
  VENDOR_NAME="AlmaLinux"
  VENDOR_URL="https://almalinux.org/"
  BUG_REPORT_URL="https://bugs.almalinux.org/"

  ALMALINUX_MANTISBT_PROJECT="AlmaLinux-10"
  ALMALINUX_MANTISBT_PROJECT_VERSION="10.0"
  REDHAT_SUPPORT_PRODUCT="AlmaLinux"
  REDHAT_SUPPORT_PRODUCT_VERSION="10.0"
  SUPPORT_END=2035-06-01

Anmerkungen und Einschränkungen

Ich habe mit diesem Experiment erreicht, was ich haben wollte: eine funktionierende, minimale Alma-Linux-10-Installation in einer im Internet erreichbaren virtuellen Maschine. Ich kann damit experimentieren. Vermutlich wird Hetzner in ein paar Wochen Alma Linux 10 als reguläres Cloud-Installations-Image anbieten. Dann werde ich diese Installation vermutlich wieder abschalten.

In der Vergangenheit habe ich Elevate auch schon auf lokale virtuelle Maschinen mit (nicht besonders wichtigen) Testumgebungen angewendet, ebenfalls zu meiner Zufriedenheit.

Aber ich würde mich niemals trauen, für ein produktiv wichtiges System auf diese Weise ein Upgrade oder womöglich eine Migration auf eine andere Distribution durchzuführen — und schon gar nicht, wenn ich keinen physischen Zugriff auf die Installation habe. Es kann dabei so viel schief gehen! Es ist unklar, ob danach überhaupt eine Reparatur möglich ist, und wenn ja, wie lange diese dauern würde.

Vergessen Sie zuletzt nicht, dass das Upgrade von Alma Linux 9 auf Version 10 aktuell noch im Beta-Test ist. Bei meinem Minimalsystem hat es funktioniert, aber das ist keine Garantie, dass das bei Ihnen auch klappt!

Kurz und gut: Die Kombination aus LEAPP und Elevate bietet eine großartige Möglichkeit, Major Upgrades für RHEL und seine Klone durchzuführen. Das ist ideal für Entwicklungs- und Testsysteme. Aber wie bei jedem Linux-Distributions-Upgrade kann dabei viel schief gehen. Der sichere Weg für produktiv wichtige Installationen ist immer eine Neuinstallation! Sie können dann in aller Ruhe sämtliche Funktionen testen, zum Schluss die Daten migrieren und mit minimaler Downtime eine Umstellung durchführen.

Quellen/Links

• https://leapp.readthedocs.io/en/stable/
• https://almalinux.org/de/elevate/
• https://almalinux.org/blog/2025-07-07-elevate-to-el-10/
• https://wiki.almalinux.org/elevate/ELevate-quickstart-guide.html
• https://wiki.almalinux.org/elevate/ELevate-NG-testing-guide.html#upgrading-almalinux-9-to-almalinux-10
• https://almalinux.org/blog/2025-04-01-elevate-updates/
• https://github.com/hetznercloud/hc-utils

Die zwei günstigsten Angebote in der Hetzner-Cloud sind Instanzen mit zwei CPU-Cores, 4 GB RAM und 40 GB Diskspace: Einmal mit virtuellen ARM-CPU-Cores (»CAX11«), einmal mit virtuellen x86-Cores (»CX22«). Der Preis ist identisch: 3,95 EUR/Monat inkl. USt (für D) plus ein Aufpreis von 0,50 EUR/Monat für eine IPv4-Adresse. Die naheliegende Frage ist: Welches Angebot gibt mehr Rechenleistung? Dieser Frage bin ich an einem verregneten Pfingstsonntag auf den Grund gegangen.

Ein »virtueller CPU-Core« heißt in diesem Zusammenhang, dass auf einem Server mehrere/viele virtuelle Maschinen laufen. Je nach Auslastung kann es sein, dass die für eine virtuelle Maschine vorgesehen CPU-Cores nicht vollständig verfügbar sind. Es gibt auch virtuelle Maschinen mit dezidierten Cores, die immer zur Verfügung stehen — aber die sind natürlich teurer.

Testbedingungen

Für meine Tests habe ich zwei Cloud-Instanzen mit Alma Linux 9 eingerichtet, einmal mit zwei ARM-CPU-Cores (CAX11), einmal mit zwei x86-CPU-Cores (CX11). Außer tar und Geekbench habe ich keine weitere Software installiert. /proc/cpuinfo lieferte die folgenden Ergebnisse:

cat /proc/cpuinfo    # CX11 / x86

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 85
model name      : Intel Xeon Processor (Skylake, IBRS, no TSX)
stepping        : 4
microcode       : 0x1
cpu MHz         : 2099.984
cache size      : 16384 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 2
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault pti ssbd ibrs ibpb fsgsbase bmi1 avx2 smep bmi2 erms invpcid avx512f avx512dq rdseed adx smap clwb avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves arat pku ospke md_clear
bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit mmio_stale_data retbleed gds bhi
bogomips        : 4199.96
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:

processor       : 1
...

cat /proc/cpuinfo   # CAX11 / ARM (Ampere)

processor   : 0
BogoMIPS    : 50.00
Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x3
CPU part    : 0xd0c
CPU revision    : 1

processor   : 1
...

Geekbench-Ergebnisse

In beiden virtuellen Maschinen habe ich mit wget Geekbench heruntergeladen, mit tar xzf ausgepackt und dann dreimal ausgeführt. Die Ergebnisse:

CX11 / x86 / Alma Linux 9

Single   Multi Core
------  -----------
   698         1203
   692         1207
   642         1205

--------------------------

CAX11 / ARM / Alma Linux 9

Single   Multi Core
------  -----------
  1082         1979
  1084         1982
  1079         1965

Zuletzt wollte ich noch wissen, ob Alma Linux 10 bei gleicher Hardware mehr Speed liefert (schnellerer Kernel, bessere Optimierung/Kompilierung der Programme etc.). Diese Tests habe ich nur auf der ARM-Instanz durchgeführt.

CAX11 / ARM / Alma Linux 10

Single   Multi Core
------  -----------
  1078         1971
  1069         1963
  1077         1974

Zusammenfassung: Bei meinen Tests boten die CAX11-Instanzen bei gleichen Kosten fast 50% mehr Leistung. Alma Linux 9 versus 10 ergibt dagegen keinen messbaren Unterschied.

PS: Geekbench ist noch nicht im IPv6-Zeitalter angekommen. Ist ja auch wirklich eine ganz neue Technologie … Wenn Sie selbst Tests durchführen wollen, müssen Sie die Instanz mit einer IPv4-Adresse konfigurieren. Weder gelingt der Download (das lässt sich umgehen), noch kann ./geekbench6 danach die Ergebnisse hochladen.

Einschränkungen

Bitte überbewerten Sie die Ergebnisse nicht! Die Hetzner-Cloud-Seite gibt keinerlei Informationen darüber, auf welchem Server bzw. auf welcher CPU Ihre virtuellen Maschinen laufen werden. Hetzner hat mehrere Rechenzentren mit unzähligen Server, mit Glück oder Pech landet Ihre virtuelle Maschine auf einem anderen, besser oder schlechter ausgestatteten Server. Das hier präsentierte Ergebnis ist nur eine Momentaufnahme, kein professionell über Wochen durchgeführter Test!

Es erscheint mir unwahrscheinlich, dass zum Testzeitpunkt (Sonntag nachmittag) die Cloud-Server besonders stark ausgelastet waren, aber es ist natürlich denkbar, dass das Ergebnis durch die Aktivität anderer virtueller Maschinen beeinflusst wurde.

Geekbench ist definitiv nicht das Maß der Dinge für Server-Benchmarks. Aber Geekbench lässt sich leicht installieren und ausführen, außerdem sind die Ergebnisse mit Desktop-Hardware vergleichbar. Sagen wir so: Um die CPU-Performance zu vergleichen, sind die Tests aus meiner Sicht gut genug.

Zu guter Letzt habe ich ausschließlich die billigsten Cloud-Angebote verglichen (die bei meinen Anwendungen aber oft ausreichen). Es gibt viele weitere Varianten, z.B. »CPX11« (2 AMD-Cores, nur 2 GB RAM, 40 GB Disk).

Kurz und gut: Dieser Test besagt NICHT, dass ARM immer mehr Leistung als x86 bietet. Zum Zeitpunkt meiner Tests und bei den von mir gewählten Randbedingungen erscheint es aber so, also würden Sie bei preisgünstige Cloud-Instanzen mit ARM-CPUs aktuell mehr Leistung bekommen als bei Instanzen zum gleichen Preis mit x86-Hardware.

Quellen/Links

• https://www.hetzner.com/de/cloud
• Geekbench ARM: https://www.geekbench.com/preview/
• Testergebnisse Alma Linux 9 + x86 Test1, Test2, Test3
• Ergebnisse Alma Linux 9 + ARM Test1, Test2, Test3
• Ergebnisse Alma Linux 10 + ARM Test1, Test2, Test3

Eine Weile hat es so ausgesehen, als wäre »Swift 5« die letzte Auflage meiner Swift-Bücher. Um so mehr freut es mich, dass »Swift — Das umfassenden Handbuch« diese Woche rundumerneuert erschienen ist! Auch wenn der Verlag von der 5. Auflage spricht — aus meiner Sicht ist das Buch praktisch komplett neu. Aus der vorigen Auflage habe ich eigentlich nur einige Grundlagenkapitel übernommen (und aktualisiert), die die Syntax von Swift beschreiben.

Vollkommen neu ist hingegen der Fokus auf SwiftUI. Diese Bibliothek wird längerfristig das UIKit ablösen. SwiftUI erfordert in vielerlei Hinsicht ein Neulernen der UI-Programmierung. Der Aufwand lohnt sich! UIKit funktioniert plattformübergreifend (macOS, iOS etc.), passt sich automatisch an den Dark Mode an, übernimmt die Font-Einstellungen aus den Systemeinstellungen usw. Endlich könnenSie die Oberflächen Ihrer Apps per Code gestalten und sind nicht auf den unübersichtlichen Story-Board-Editor angewiesen.

Geändert hat sich das Buch auch aus einem zweiten Grund: Als ich die vorige Auflage verfasst habe, gab es ChatGPT noch nicht. Mit KI-Assistenten ändert sich der Coding-Alltag aber grundlegend. Sie müssen die Konzepte und Grundlagen verstehen; Details wie die Reihenfolge der Optionen, die Syntax exotischer Klassen etc. können Sie hingegen getrost KI-Tools überlassen. Mit etwas Glück werden brauchbare KI-Werkzeuge demnächst auch in Xcode integriert. (Diesbezüglich hat Apple viel versprochen, aber bisher wenig geliefert.) Bis es so weit ist, liefern auch ChatGPT, Claude oder Gemini verblüffend gute Code-Vorschläge.

Kurz und gut: »Swift — Das umfassende Handbuch« vermittelt Ihnen das Fundament, um selbstständig oder mit KI-Unterstützung eigene Apps zu entwickeln. Mehr Details zum Buch können Sie hier nachlesen:

https://kofler.info/buecher/swift/

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

Seit vielen Jahren verwende ich Let’s Encrypt-Zertifikate für meine Webserver. Zum Ausstellen der Zertifikate habe ich in den Anfangszeiten das Kommando certbot genutzt. Weil die Installation dieses Python-Scripts aber oft Probleme bereitete, bin ich schon vor vielen Jahren auf das Shell-Script acme.sh umgestiegen (siehe https://github.com/acmesh-official/acme.sh).

Kürzlich bin ich auf einen Sonderfall gestoßen, bei dem acme.sh nicht auf Anhieb funktioniert. Die Kurzfassung: Ich verwende Apache als Proxy für eine REST-API, die in einem Docker-Container läuft. Bei der Zertifikatausstellung/-erneuerung ist Apache (der auf dem Rechner auch als regulärer Webserver läuft) im Weg; die REST-API liefert wiederum keine statischen Dateien aus. Die Domain-Verifizierung scheitert. Abhilfe schafft eine etwas umständliche Apache-Konfiguration.

Ausgangspunkt

Ausgangspunkt ist also ein »gewöhnlicher« Apache-Webserver. Dieser soll nun zusätzlich eine REST-API ausliefern, die in einem Docker-Container läuft (localhost:8880). Die erste Konfiguration sah ziemlich simpel aus:

# zusätzliche Apache-Proxy-Konfigurationsdatei 
# für einen Docker-Container 
<VirtualHost *:443>
    ServerName api.example.com

    # SSL
    SSLEngine on
    SSLCertificateFile    /etc/acme-letsencrypt/api.example.com.pem
    SSLCertificateKeyFile /etc/acme-letsencrypt/api.example.com.key

    # Proxy: localhost:8880 <-> https://api.example.com
    ProxyPreserveHost On
    ProxyPass         / http://localhost:8880/
    ProxyPassReverse  / http://localhost:8880/

    # Logging Konfiguration ...
</VirtualHost>


#  HTTP -> HTTPS
<VirtualHost *:80>
    ServerName api.example.com
    Redirect permanent / https://api.example.com
</VirtualHost>

Das Problem

Das Problem besteht darin, dass acme.sh zwar diverse Domain-Verifizierungsverfahren kennt, aber keines so richtig zu meiner Konfiguration passt:

• acme.sh ... --webroot scheitert, weil die API eine reine API ist und keine statischen Dateien ausliefert.
• acme.sh ... --standalone scheitert, weil der bereits laufende Webserver Port 80 blockiert.
• acme.sh ... --apache scheitert mit could not resolve api.example.com.well-known.

Die Lösung

Die Lösung besteht darin, die Apache-Proxy-Konfiguration dahingehend zu ändern, dass zusätzlich in einem Verzeichnis statische Dateien ausgeliefert werden dürfen. Dazu habe ich das neue Verzeichnis /var/www/acme-challenge eingerichtet:

mkdir /var/www/acme-challenge
chown www-data:www-data /var/www/acme-challenge/

Danach habe ich die Konfigurationsdatei für Apache umgebaut, so dass Anfragen an api.example.com/.well-known/acme-challenge mit statischen Dateien aus dem Verzeichnis /var/www/acme-challenge/.well-known/acme-challenge bedient werden:

# Apache-Konfiguration wie bisher
<VirtualHost *:443>
    ServerName api.example.com

    # SSL
    SSLEngine on
    SSLCertificateFile    /etc/acme-letsencrypt/api.example.com.pem
    SSLCertificateKeyFile /etc/acme-letsencrypt/api.example.com.key

    # Proxy: localhost:8880 <-> api.example.com
    ProxyPreserveHost On
    ProxyPass         / http://localhost:8880/
    ProxyPassReverse  / http://localhost:8880/

    # Logging Konfiguration ...
</VirtualHost>

# geändert: HTTP auf HTTPS umleiten, aber nicht
# für well-known-Verzeichnis
<VirtualHost *:80>
    ServerName api.example.com

    # Handle ACME challenges locally
    Alias /.well-known/acme-challenge /var/www/acme-challenge/.well-known/acme-challenge
    <Directory /var/www/acme-challenge/.well-known/acme-challenge>
        Require all granted
    </Directory>

    # Redirect everything EXCEPT ACME challenges to HTTPS
    RewriteEngine On
    RewriteCond %{REQUEST_URI} !^/.well-known/acme-challenge/
    RewriteRule ^(.*)$ https://api.example.com$1 [R=301,L]
</VirtualHost>

Nach diesen Vorbereitungsarbeiten und mit systemctl reload apache2 gelingt nun endlich das Zertifikaterstellen und -erneuern mit dem --webroot-Verfahren. Dabei richtet acme.sh vorübergehend die Datei /var/www/acme-challenge/.well-known/acme-challenge/xxx ein und testet dann via HTTP (Port 80), ob die Datei gelesen werden kann.

# Zertifikat erstmalig erstellen
acme.sh --issue --server letsencrypt -d api.example.com --webroot /var/www/acme-challenge

# Zertifikat installieren und Renew-Prozess einrichten
acme.sh --install-cert -d api.example.com \
  --key-file /etc/acme-letsencrypt/api.example.com.key \
  --fullchain-file /etc/acme-letsencrypt/api.example.com.pem \
  --reloadcmd "service apache2 reload"

# Renew-Prozess testen
acme.sh --renew -d api.example.com --force

Traefik

Eine noch elegantere Lösung besteht darin, den Docker-Container mit Traefik zu kombinieren (siehe https://traefik.io/traefik/). Bei korrekter Konfiguration kümmert sich Traefik um alles, nicht nur um die Proxy-Funktionen sondern sogar um das Zertifikatsmanagment. Aber diese Lösung kommt nur in Frage, wenn auf dem Host nicht schon (wie in meinem Fall) ein Webserver läuft, der die Ports 80 und 443 blockiert.

Links / Quellen

• https://github.com/acmesh-official/acme.sh
• https://traefik.io/traefik/

Der SSH-Dienst ist ein natürliches Angriffsziel jedes Servers. Klassische Abwehrmaßnahmen zielen darauf aus, den root-Login zu sperren (das sollte eine Selbstverständlichkeit sein) und mit Fail2ban wiederholte Login-Versuche zu blockieren. Eine weitere Sicherheitsmaßnahme besteht darin, den Passwort-Login mit einer Zwei-Faktor-Authentifizierung (2FA) zu verbinden. Am einfachsten gelingt das server-seitig mit dem Programm google-authenticator. Zusätzlich zum Passwort muss nun ein One-time Password (OTP) angegeben werden, das mit einer entsprechenden App generiert wird. Es gibt mehrere geeignete Apps, unter anderem Google Authenticator und Authy (beide kostenlos und werbefrei).

Es gibt verschiedene Konfigurationsoptionen. Ziel dieser Anleitung ist es, parallel zwei Authentifizierungsvarianten anzubieten:

• mit SSH-Schlüssel (ohne 2FA)
• mit Passwort und One-time Password (also mit 2FA)

Grundlagen: sshd-Konfiguration

Vorweg einige Worte zu Konfiguration des SSH-Servers. Diese erfolgt durch die folgenden Dateien:

/etc/ssh/sshd_config
/etc/ssh/sshd_config.d/*.conf
/etc/crypto-policies/back-ends/opensshserver.config  (nur RHEL)

Verwechseln Sie sshd_config nicht mit ssh_config (ohne d) für die Konfiguration des SSH-Clients, also für die Programme ssh und scp! opensshserver.config legt fest, welche Verschlüsselungsalgorithmen erlaubt sind.

Beachten Sie, dass bei Optionen, die in den sshd-Konfigurationsdateien mehrfach eingestellt sind, der erste Eintrag gilt (nicht der letzte)! Das gilt auch für Einstellungen, die am Beginn von sshd_config mit Include aus dem Unterverzeichnis /etc/ssh/sshd_config.d/ gelesen werden und die somit Vorrang gegenüber sshd_config haben.

Werfen Sie bei Konfigurationsproblemen unbedingt auch einen Blick in das oft übersehene sshd_config.d-Verzeichnis und vermeiden Sie Mehrfacheinträge für ein Schlüsselwort!

Weil die Dateien aus /etc/ssh/sshd_config.d/ Vorrang gegenüber sshd_config haben, besteht eine Konfigurationsstrategie darin, sshd_config gar nicht anzurühren und stattdessen alle eigenen Einstellungen in einer eigenen Datei (z.B. sshd_config.d/00-myown.conf) zu speichern. 00 am Beginn des Dateinamens stellt sicher, dass die Datei vor allen anderen Konfigurationsdateien gelesen wird.

Überprüfen Sie bei Konfigurationsproblemen mit sshd -T, ob die Konfiguration Fehler enthält. Wenn es keine Konflikte gibt, liefert sshd -T eine Auflistung aller aktuell gültigen Einstellungen. Die Optionen werden dabei in Kleinbuchstaben angezeigt. Mit grep -i können Sie die für Sie relevante Einstellung suchen:

sshd -T | grep -i permitro

  permitrootlogin yes

Änderungen an sshd_config werden erst wirksam, wenn der SSH-Server die Konfiguration neu einliest. Dazu führen Sie das folgende Kommando aus:

systemctl reload sshd       # RHEL
systemctl reload ssh        # Debian, Ubuntu

google-authenticator einrichten

Google Authenticator bezeichnet zwei unterschiedliche Programme: einerseits die App, die sowohl für iOS als auch für Android verfügbar ist, andererseits ein Linux-Kommando, um die 2FA auf einem Linux-Server einzurichten. Während der Code für die Smartphone-Apps nicht öffentlich ist, handelt es sich bei dem Linux-Kommando um Open-Source-Code. Das resultierende Paket steht für RHEL-Distributionen in der EPEL-Paketquelle zur Verfügung, bei Ubuntu in universe.

dnf install google-authenticator qrencode   # RHEL + EPEL
apt install libpam-google-authenticator     # Debian, Ubuntu

Nach der Installation führen Sie für den Account, als der Sie sich später via SSH anmelden möchten (also nicht für root), das Programm google-authenticator aus. Nachdem Sie den im Terminal angezeigten QR-Code gescannt haben, sollten Sie zur Kontrolle sofort das erste OTP eingeben. Sämtliche Rückfragen können Sie mit y beantworten. Die Rückfragen entfallen, wenn Sie das Kommando mit den Optionen -t -d -f -r 3 -R 30 -W ausführen. Das Programm richtet die Datei .google-authenticator im Heimatverzeichnis ein.

user$ google-authenticator
  Do you want authentication tokens to be time-based (y/n)
  Enter code from app (-1 to skip): nnnnnn
  Do you want me to update your .google_authenticator file? (y/n)
  Do you want to disallow multiple uses of the same
    authentication token? (y/n)
  ...

SSH-Server-Konfiguration

Das nächste Listing zeigt die erforderlichen sshd-Einstellungen. Mit der Methode keyboard-interactive wird PAM für die Authentifizierung verwendet, wobei auch eine mehrstufige Kommunikation erlaubt ist. Die ebenfalls erforderliche Einstellung UsePAM yes gilt bei den meisten Linux-Distributionen standardmäßig. Am besten speichern Sie die folgenden Zeilen in der neuen Datei /etc/ssh/sshd_config.d/00-2fa.conf. Diese wird am Beginn der sshd-Konfiguration gelesen und hat damit Vorrang gegenüber anderen Einstellungen.

# Datei /etc/ssh/sshd_config.d/00-2fa.conf
UsePAM                           yes
PasswordAuthentication           yes
PubkeyAuthentication             yes
ChallengeResponseAuthentication  yes
# Authentifizierung wahlweise nur per SSH-Key oder
# mit Passwort + OTP
AuthenticationMethods            publickey keyboard-interactive

PAM-Konfiguration

Der zweite Teil der Konfiguration erfolgt in /etc/pam.d/sshd. Am Ende dieser Datei fügen Sie eine Zeile hinzu, die zusätzlich zu allen anderen Regeln, also zusätzlich zur korrekten Angabe des Account-Passworts, die erfolgreiche Authentifizierung durch das Google-Authenticator-Modul verlangt:

# am Ende von /etc/pam.d/sshd (Debian, Ubuntu)
...
# Authenticator-Zifferncode zwingend erforderlich
auth required pam_google_authenticator.so

Alternativ ist auch die folgende Einstellung mit dem zusätzlichen Schlüsselwort nullok denkbar. Damit akzeptieren Sie einen Login ohne 2FA für Accounts, bei denen Google Authenticator noch nicht eingerichtet wurde. Sicherheitstechnisch ist das natürlich nicht optimal — aber es vereinfacht das Einrichten neuer Accounts ganz wesentlich.

# am Ende von /etc/pam.d/sshd (Debian, Ubuntu)
...
# Authenticator-Zifferncode nur erforderlich, wenn 
# Google Authenticator für den Account eingerichtet wurde
auth required pam_google_authenticator.so nullok

Wenn Sie RHEL oder einen Klon verwenden, sieht die PAM-Konfiguration ein wenig anders aus. SELinux verbietet dem SSH-Server Zugriff auf Dateien außerhalb des .ssh-Verzeichnisses. Deswegen müssen Sie die Datei .google-authenticator vom Home-Verzeichnis in das Unterverzeichnis .ssh verschieben. restorecon stellt sicher, dass der SELinux-Kontext für alle Dateien im .ssh-Verzeichnis korrekt ist.

user$ mv .google-authenticator .ssh/    (nur unter RHEL!)
user$ restorecon .ssh

In der Zeile auth required übergeben Sie nun als zusätzliche Option den geänderten Ort von .google-authenticator. Falls Sie die nullok-Option verwenden möchten, fügen Sie dieses Schlüsselwort ganz am Ende hinzu.

# am Ende von /etc/pam.d/sshd (RHEL & Co.)
...
auth required pam_google_authenticator.so secret=/home/${USER}/.ssh/.google_authenticator

Test und Fehlersuche

Passen Sie auf, dass Sie sich nicht aus Ihrem Server aussperren! Probieren Sie das Verfahren zuerst in einer virtuellen Maschine aus, nicht auf einem realen Server!

Vergessen Sie nicht, die durchgeführten Änderungen zu aktivieren. Vor ersten Tests ist es zweckmäßig, eine SSH-Verbindung offen zu lassen, damit Sie bei Problemen die Einstellungen korrigieren können.

sshd -T                   # Syntaxtest
systemctl reload sshd     # RHEL
systemctl reload ssh      # Debian + Ubuntu

Bei meinen Tests hat sich die Google-Authenticator-Konfiguration speziell unter RHEL als ziemlich zickig erwiesen. Beim Debugging können Sie client-seitig mit ssh -v, server-seitig mit journalctl -u sshd nach Fehlermeldungen suchen.

Die Anwendung von Google Authenticator setzt voraus, dass die Uhrzeit auf dem Server korrekt eingestellt ist. Die One-Time-Passwords gelten nur in einem 90-Sekunden-Fenster! Das sollten Sie insbesondere bei Tests in virtuellen Maschinen beachten, wo diese Bedingung mitunter nicht erfüllt ist (z.B. wenn die virtuelle Maschine pausiert wurde). Stellen Sie die Zeit anschließend neu ein, oder starten Sie die virtuelle Maschine neu!

Was ist, wenn das Smartphone verlorengeht?

Für den Fall, dass das Smartphone und damit die zweite Authentifizierungsquelle verlorengeht, zeigt das Kommando google-authenticator bei der Ausführung fünf Ziffernfolgen an, die Sie einmalig für einen Login verwendet können. Diese Codes müssen Sie notieren und an einem sicheren Ort aufbewahren — dann gibt es im Notfall einen »Plan B«. (Die Codes sind auch in der Datei .google_authenticator enthalten. Auf diese Datei können Sie aber natürlich nicht mehr zugreifen, wenn Sie keine Login-Möglichkeit mehr haben.)

Die App Google Authenticator synchronisiert die 2FA-Konfiguration automatisch mit Ihrem Google-Konto. Die 2FA-Konfiguration kann daher auf einem neuen Smartphone rasch wieder hergestellt werden. Schon eher bereitet Sorge, dass nur die Kenntnis der Google-Kontodaten ausreichen, um Zugang zur 2FA-Konfiguration zu erhalten. Die Cloud-Synchronisation kann in den Einstellungen gestoppt werden.

Auch Authy kann die 2FA-Konfiguration auf einem Server der Firma Twilio speichern und mit einem weiteren Gerät synchronisieren. Anders als bei Google werden Ihre 2FA-Daten immerhin mit einem von Ihnen zu wählenden Passwort verschlüsselt. Mangels Quellcode lässt sich aber nicht kontrollieren, wie sicher das Verfahren ist und ob es den Authy-Betreibern Zugriff auf Ihre Daten gewährt oder nicht. 2024 gab es eine Sicherheitspanne bei Twilio, bei der zwar anscheinend keine 2FA-Daten kompromittiert wurden, wohl aber die Telefonnummern von 35 Millionen Authy-Benutzern.

Sicherheits- und Privacy-Bedenken

Authenticator-Apps funktionieren prinzipiell rein lokal. Weder der beim Einrichten erforderliche Schlüssel bzw. QR-Code noch die ständig generierten Einmalcodes müssen auf einen Server übertragen werden. Die Apps implementieren den öffentlich standardisierten HMAC-based One-Time Password Algorithmus (OATH-HOTP).

Allerdings bieten einige OTP-Apps die Möglichkeit, die Account-Einträge über ein Cloud-Service zu sichern (siehe oben). Diese Cloud-Speicherung ist eine mögliche Sicherheitsschwachstelle.

Davon losgelöst gilt wie bei jeder App: Sie müssen der Firma vertrauen, die die App entwickelt hat. Der Code der App Google Authenticator war ursprünglich als Open-Source verfügbar, seit 2020 ist das leider nicht mehr der Fall. Wenn Sie weder Google Authenticator noch Authy vertrauen, finden Sie im Arch Linux Wiki Links zu Apps, deren Code frei verfügbar ist.

Quellen, Links

• https://de.wikipedia.org/wiki/Google_Authenticator
• https://de.wikipedia.org/wiki/HMAC-based_one-time_password
• https://www.authy.com/
• https://wiki.archlinux.org/title/Google_Authenticator
• https://9to5mac.com/2024/07/04/authy-hack/
• https://security.googleblog.com/2023/04/google-authenticator-now-supports.html
• https://futurezone.at/apps/google-authenticator-update-2-factor-authentification-cloud-synchronisierung-google-konto/402425360

Hardware-Tests sind eigentlich nicht meine Spezialität, aber wenn ich schon einmal ein neues Gerät kaufe, kann es nicht schaden, ein paar Sätze zur Linux-Kompatibilität zu schreiben. Die Kurzfassung: relativ hohe Leistung fürs Geld, inkl. Windows-Pro-Lizenz, erweiterbar. Leise, aber nie lautlos. Weitestgehend Linux-kompatibel (Ausnahmen: WLAN, Bluetooth).

Kurz die Ausgangslage: Ich besitze zwei Notebooks, ein Lenovo P1 für Linux und ein MacBook. Mein Windows-PC, den ich gelegentlich zum Testen brauche, hat dagegen seine planmäßige Lebensdauer schon lange überschritten — lahm, nur SATA-SSDs, inkompatibel zu aktuellen Windows-Releases. Zielsetzung war, dafür Ersatz zu schaffen. Aus Platzgründen kein drittes Notebook. Ich wollte ein vorinstalliertes Windows-Pro, mit dem ich mich nicht über die Maßen ärgern muss, einen Slot für eine zweite PCIe-SSD, damit ich parallel Linux installieren kann, eine AMD-CPU mit ordentlicher Rechenleistung und ausreichend RAM für Virtualisierung, Docker & Co. Ein zugängliches BIOS (leider nicht ganz selbstverständlich.) Außerdem sollte das Ding einigermaßen leise sein.

Nach etwas Recherche ist es ein Minisforum UM 870 mit AMD 8745H (Ryzen 7) geworden. 32 GB RAM, 1 TB SSD (plus 1 Slot frei), 2,5 GB Ethernet, 1xUSB-C, 4xUSB-A, HDMI, Displayport, WIFI 6, Bluetooth. Preis zum Zeitpunkt des Kaufs: EUR 550

Also im Prinzip ein »typischer« Mini-PC im mittleren Preissegment. Es gibt billigere Modelle, die aber meist eine langsamere CPU und keinen freien PCIe-Slot haben. Es gibt teurere Modelle mit noch mehr Leistung (verbunden mit mehr Lärm). Für meine Anforderungen erschien mir das Modell genau richtig.

Mehr Informationen zur Hardware:

• Minisforum
• amazon
• Testberichte ähnlicher/gleicher Rechner bei heise.de, ähnliche Modelle bei heise.de, igorslab.de, hostbor.com

Gehäuse öffnen

Das Gehäuse lässt sich mühelos mit vier Schrauben öffnen. Die Schrauben sind allerdings unter angeklebten Gumminoppen versteckt. Diese Noppen leiden bei der Demontage etwas, bleiben aber verwendbar. (Minisforum liefert zwei Ersatznoppen mit. An sich sehr nett, aber warum nicht gleich vier?) Der Einbau der zweiten SSD gelang mühelos. Die SSD war bisher in meinem Notebook im Einsatz. Dort hatte ich Ubuntu und Fedora installiert. Beim nächsten Reboot tauchten beide Linux-Distributionen im Bootmenü auf und ließen sich anstandslos starten. Das ist Linux wie ich es liebe!

Betrieb unter Windows

Windows war vorinstalliert, erfreulicherweise ohne jede Bloatware. Ein Lob an den Hersteller!

Ich habe solange Updates durchgeführt, bis ich bei 24H2 gelandet bin. Das dauert stundenlang, meine Güte! Arm ist, wer viel mit Windows arbeiten muss …

Danach Google Chrome, Nextcloud Client, VSCode, WSL, Docker, VirtualBox, Git, PowerShell, Ollama etc.

Alles in allem keine Probleme. Vielleicht sollte ich doch auf Windows umsteigen? (Kleiner Scherz …)

Betrieb unter Linux

Ich habe bisher nur Ubuntu 24.10 und Fedora 41 ausprobiert. Beide Distributionen laufen vollkommen problemlos. Das Grafiksystem verwendet Wayland.

Pech hat, wer WLAN oder Bluetooth verwenden will. Linux erkennt den WLAN/Bluetooth-Adapter (MediaTek MT7902) nicht. Das war mir schon vor dem Kauf bekannt. Eine kurze Suche zeigt, dass Linux-Treiber nicht in Sicht sind. Zum Glück sind beide Funktionen für mich nicht relevant (USB-Tastatur, Kabel-gebundenes Netzwerk). Andernfalls wäre ein USB-Dongle die einfachste Lösung. Theoretisch wäre es wohl auch möglich, den WLAN/Bluetooth-Adapter auszutauschen. Im Internet gibt es entsprechende Video-Anleitungen, die aber darauf hinweisen, dass die Neuverkabelung der Antennen ziemlich schwierig ist.

Die WLAN/Bluetooth-Probleme beweisen, dass fehlende Hardware-Treiber bis heute zum Linux-Alltag gehören. Hardware-Kauf ohne vorherige Recherche kann direkt in die Sackgasse führen.

Update 15.4.: Ich habe mit dnf system-upgrade download --releasever=42 und dnf system-upgrade reboot ein Upgrade auf Fedora 42 durchgeführt. Der Bildschirmhintergrund ist merkwürdig, sonst ist mir kein offensichtlicher Unterschied aufgefallen. Hinter den Kulissen hat sich natürlich wie immer eine Menge getan, siehe What’s new und Change set.

BIOS/EFI

In das BIOS/EFI bzw. zu den Boot-Einstellungen gelangt man mit Entf oder F7. Nicht unendlich viele Einstellungen, aber ausreichend. Secure Boot kann ausgeschaltet werden. Eine Möglichkeit, die Größe des für die GPU reservierten RAMs zu beeinflussen, habe ich hingegen nicht gefunden. (Wäre interessant für Ollama.)

Geekbench-Ergebnisse

Alle Tests mit Geekbench 6.4 und mit den Original-BIOS-Einstellungen (Balanced Mode, außerdem stünde ein Performance Mode zur Wahl). Die Lüfterlautstärke ändert sich während der Tests nur minimal. Das Gerät bleibt immer leise, aber es wird nie lautlos (auch nicht, wenn der PC längere Zeit nichts zu tun hat). Rechner, die schnell und lautlos sind, schafft anscheinend nur Apple.

Unter Ubuntu und Fedora habe ich die Gnome-Energiemodi verwendet. Zwischen Ausgeglichen und Leistung gibt es wie unter Windows keinen nennenswerten Unterschied, zumindest nicht, solange die BIOS-Einstellungen nicht verändert werden. Interessanterweise schneidet Windows bei den Geekbench-Tests ein wenig besser ab als Fedora. Noch deutlicher ist der Vorsprung zu Ubuntu.

                                      Single Core    Multi Core
----------------------------------  -------------  ------------
Windows 11 24H2 Energieeffizient             1896          9057
                Ausbalanziert                2622         13129
                Leistung                     2609         13187
Ubuntu 24.10    Ausgeglichen                 2382         12348
                Leistung                     2420         12399
Fedora 41       Ausgeglichen                 2585         13142
                Leistung                     2589         13205

Links:

• https://browser.geekbench.com/v6/cpu/11344384
• https://browser.geekbench.com/v6/cpu/11344475
• https://browser.geekbench.com/v6/cpu/11344514
• https://browser.geekbench.com/v6/cpu/11465486
• https://browser.geekbench.com/v6/cpu/11465486
• https://browser.geekbench.com/v6/cpu/11485335
• https://browser.geekbench.com/v6/cpu/11485471

Unter Windows habe ich auch Ollama ausprobiert. Mein minimalistischer Ollama-Benchmarktest liefert 12 Token/Sekunde (reine CPU-Leistung, die GPU wird nicht benutzt). Traurig, aber mehr war nicht zu erwarten.

Fazit

Die Lebensdauer kann ich noch nicht beurteilen. Die Stabilität war bisher ausgezeichnet, kein einziger Absturz unter Windows/Ubuntu/Fedora/Kali. WLAN und Bluetooth brauche ich nicht, insofern ist mir das Linux-Treiberproblem gleichgültig. Aber ein Notebook mit MT7902 wäre ein totales No-go!

Update 3.5.2025: Theoretisch sollte es möglich sein, den Computer über USB-C mit Strom zu versorgen (siehe auch diesen heise-Test). In Kombination mit meinem Monitor (LG 27UL850-W, 27 Zoll, 4k) funktioniert das aber nicht.

Ich bin ein Fan lautloser Computer. In dieser Liga spielt das Gerät nicht mit. Der Computer ist leise, aber man vergisst keine Minute, dass der PC eingeschaltet ist.

Davon abgesehen bin ich zufrieden. Das Gerät wäre theoretisch auf 64 GB RAM erweiterbar (unwahrscheinlich, dass ich so viel RAM je brauche). Die beiden PCIe-Slots geben auch beim Speicherplatz viel Flexibilität. Eine zweite USB-C-Buchse und eine SD-Karten-Slot wären nett, aber ich kann ohne leben.

Den neuen Apple Mini mit M4-CPU kenne ich nicht aus eigener Erfahrung, ich beziehe mich also auf Infos aus dem Netz. Der Vergleich drängt sich aber auf. Bei etwa gleichem Preis bietet Apples Mini-PC in Minimalausstattung im Geekbench-Test eine deutlich höhere Single-Core-Leistung (ca. 3700), eine unwesentlich höhere Multi-Core-Leistung (ca. 14.700), macht weniger Lärm, ist kleiner, braucht auch kein externes Netzteil, hat aber nur halb so viel RAM und nur 1/4 des Speicherplatzes. Das RAM ist nicht erweiterbar, die SSD nur kompliziert und relativ teuer. (Zur Einordnung: Ein Mac Mini mit 32 GB RAM und 1 TB SSD würde absurde EUR 1500 kosten.) Und natürlich läuft ohne Virtualisierung weder Windows noch Linux. Ich gebe schon zu: Das ist ein Vergleich zwischen Äpfel und Birnen. Beide PC-Varianten haben Ihre Berechtigung. Apple zeigt, was technisch möglich ist, wenn Geld keine Rolle spielt. Aus Linux- oder Windows-Perspektive bieten Mini-PCs wie das hier präsentierte Modell aber viel Leistung für wenig Geld.

Vor einem dreiviertel Jahr haben Bernd Öggl, Sebastian Springer und ich das Buch Coding mit KI geschrieben und uns während dieser Zeit intensiv mit diversen KI-Tools und Ihrer Anwendung beschäftigt.

Was hat sich seither geändert? Wie sieht die berufliche Praxis mit KI-Tools heute aus? Im folgenden Fragebogen teilen wir drei unsere Erfahrungen, Wünsche und Ärgernisse. Sie sind herzlich eingeladen, in den Kommentaren eigene Anmerkungen hinzuzufügen.

Bei welchen Projekten hast du KI-Tools im letzten Monat eingesetzt? Mit welchem Erfolg?

Bernd: KI-Tools haben in meine tägliche Programmierung Einzug gehalten und sparen mir Zeit. Oft traue ich der Ki zu wenig zu und stelle Fragen, die nicht weit genug gehen. Zum „vibe-coding“ bin ich noch nicht gekommen :-) Ich verwende KI-Tools in diesen Projekten:

1. ein großes Code Repo mit Angular und C#: Einsatz sowohl in VSCode (Angular) und Visual Studio (C#, die Unterstützung ist überraschend gut).
2. ein kleines Projekt (HTML, JS, MongoDB (ca. 20.000 MongoDocs)).
3. zwei verschiedene Flutter Apps für Android
4. für eine größere PHP/MariaDB Codebase

Sebastian: Ich setze mittlerweile verschiedene KI-Tools flächendeckend in den Projekten ein. Wir haben das mittlerweile auch in unsere Verträge mit aufgenommen, dass das explizit erlaubt ist.

Die letzten Projekte waren in JavaScript/TypeScript im Frontend React, im Backend Node.js, und es waren immer mittelgroße Projekte mit 2 – 4 Personen über mehrere Monate.

Die verschiedenen Tools sind mittlerweile zum Standard geworden und ich möchte nicht mehr darauf verzichten müssen, gerade bei den langweiligen Routineaufgaben helfen sie enorm.

Michael: Ich habe zuletzt einige Swift/SwiftUI-Beispielprogramme entwickelt. Weil Swift und insbesondere SwiftUI ja noch sehr dynamisch in der Weiterentwicklung ist, hatten die KI-Tools die Tendenz, veraltete Programmiertechniken vorzuschlagen. Aber mit entsprechenden Prompts (use modern features, use async/await etc.) waren die Ergebnisse überwiegend gut (wenn auch nicht sehr gut).

Ansonsten habe ich in den letzten Monaten immer wieder kleinere Mengen Code in PHP/MySQL, Python und der bash geschrieben bzw. erweitert. Mein Problem ist zunehmend, dass ich beim ständigen Wechsel die Syntaxeigenheiten der diversen Sprachen durcheinanderbringe. KI-Tools sind da meine Rettung! Der Code ist in der Regel trivial. Mit einem sorgfältig formulierten Prompt funktioniert KI-generierter Code oft im ersten oder zweiten Versuch. Ich kann derartige Routine-Aufgaben mit KI-Unterstützung viel schneller erledigen als früher, und die KI-Leistungen sind diesbezüglich ausgezeichnet (besser als bei Swift).

Welches KI-Tool verwendest du bevorzugt? In welchem Setup?

Michael: Ich habe in den vergangenen Monaten fast ausschließlich Claude Pro verwendet (über die Weboberfläche). Was die Code-Qualität betrifft, bin ich damit sehr zufrieden und empfand diese oft besser als bei ChatGPT.

In VSCode läuft bei mir Cody (Free Tier). Ich verwende es nur für Vervollständigungen. Es ist OK.

Ansonsten habe ich zuletzt den Großteil meiner Arbeitszeit in Xcode verbracht. Xcode ist im Vergleich zu anderen IDEs noch in der KI-Steinzeit, die aktuell ausgelieferten KI-Werkzeuge in Xcode sind unbrauchbar. Eine Integration von Claude in Xcode hätte mir viel Hin und Her zwischen Xcode und dem Webbrowser erspart. (Es gibt ein Github-Copilot-Plugin für Xcode, das ich aber noch nicht getestet habe. Apple hat außerdem vor fast einem Jahr Swift Code angekündigt, das bessere KI-Funktionen verspricht. Leider ist davon nichts zu sehen. Apple = Gute Hardware, schlechte Software, zumindest aus Entwicklerperspektive.)

Für lokale Modelle habe ich aktuell leider keine geeignete Hardware.

Sebastian: Ich habe über längere Zeit verschiedene IDE-Plugins mit lokalen Modellen ausprobiert, nutze aber seit einigen Monaten nur noch GitHub Copilot. Die Qualität und Performance ist deutlich besser als die von lokalen Modellen.

Für Konzeption und Ideenfindung nutze ich ebenfalls größere kommerzielle Werkzeuge. Aktuell stehen die Gemini-Modelle bei mir ganz hoch im Kurs. Die haben mit Abstand den größten Kontext (1 – 2 Millionen Tokens) und die Ergebnisse sind mindestens genauso gut wie bei ChatGPT, Claude & Co.

Lokale Modelle nutze ich eher punktuell oder für die Integration in Applikationen. Gerade wenn es um Übersetzung, RAG und ähnliches geht, wo es entweder um Standardaufgaben oder um Teilaufgaben geht, wo man mit weiteren Tools wie Vektordatenbanken die Qualität steuern kann. Bei den lokalen Modellen hänge ich nach wie vor bei Llama3 wobei sich auch die Ergebnisse von DeepSeek sehen lassen können.

Für eine kleine Applikation habe ich auch europäische Modelle (eurollm und teuken) ausprobiert, wobei ich da nochmal deutlich mehr Zeit investieren muss.

Für die Ausführung lokaler Modelle habe ich auf die Verfügbarkeit der 50er-Serie von NVIDIA gewartet, wobei mir die RTX 5090 deutlich zu teuer ist. Ich habe seit Jahresbeginn ein neues MacBook Pro (M4 Max) das bei der Ausführung lokaler Modelle echt beeindruckend ist. Mittlerweile nutze ich das MacBook deutlich mehr als meinen Windows PC mit der alten 3070er.

Bernd: Ich verwende aus Interesse vor allem lokale Modelle, die auf meinem MacBook Pro (M2/64GB) wunderbar schnell performen (aktuell gemma3:27b und deepseek-r1:32b, aber das ändert sich schnell). Am MacBook laufen die über ollama. Ich muss aber beruflich auch unter Windows arbeiten und arbeite eigentlich (noch) am liebsten unter Linux mit neovim.

Dazu ist das Macbook jetzt immer online und im lokalen Netz erreichbar. Unter Windows verwenden ich in VSCode das Continue Plugin mit dem Zugriff auf die lokalen Modelle am MacBook. In Visual Studio läuft CoPilot (die „Gratis“-Version). Unter Linux verwende ich sehr oft neovim (mit lazyvim) mit dem avante-Plugin. Während ich früher AI nur für code-completion verwendet habe, ist es inzwischen oft so, dass ich Code-Blöcke markiere und der AI dazu Fragen stelle. Avante macht dann wunderbare Antworten mit Code-Blöcken, die ich wie einen git conflict einbauen kann. Sie sagen es ist so wie cursor.ai, aber das habe ich noch nicht verwendet.

Daneben habe ich unter Linux natürlich auch VSCode mit Continue. Und wenn ich gerade einmal nicht im Büro arbeite (also das Macbook nicht im aktuellen Netz erreichbar ist), so wie gerade eben, dann habe ich Credits für Anthropic und verwende Claude (3.5 Sonnet aktuell) für AI support.

Wo haben dich KI-Tools in letzter Zeit überrascht bzw. enttäuscht?

Sebastian: Ich bin nach wie vor enttäuscht wie viel Zeit es braucht, um den Kontext aufzubauen, damit dir ein LLM wirklich bei der Arbeit hilft. Gerade wenn es um neuere Themen wie aktuelle Frameworks geht. Allerdings lohnt es sich bei größeren Projekten, hier Zeit zu investieren. Ich habe in ein Test-Setup für eine Applikation gleich mehrere Tage investiert und konnte am Ende qualitativ gute Tests generieren, indem ich den Testcase mit einem Satz beschrieben habe und alles weitere aus Beispielen und Templates kam.

Ich bin sehr positiv überrascht vom Leistungssprung den Apple bei der Hardware hingelegt hat. Gerade das Ausführen mittelgroßer lokaler LLMs merkt man das extrem. Ein llama3.2-vision, qwq:32b oder teuken-7b funktionieren echt gut.

Bernd: Überrascht hat mich vor allem der Qualitäts-Gewinn bei lokalen Modellen. Im Vergleich zu vor einem Jahr sind da Welten dazwischen. Ich mache nicht ständig Vergleiche, aber was die aktuellen Kauf-Modelle liefern ist nicht mehr so ganz weit weg von gemma3 und vergleichbaren Modellen.

Michael: Ich musste vor ein paar Wochen eine kleine REST-API in Python realisieren. Datenbank und API-Design hab‘ ich selbst gemacht, aber das Coding hat nahezu zu 100 Prozent die KI erledigt (Claude). Ich habe mich nach KI-Beratung für das FastAPI-Framework entschieden, das ich vorher noch nie verwendet habe. Insgesamt ist die (einzige) Python-Datei knapp 400 Zeilen lang. Acht Requests mit den dazugehörigen Datenstrukturen, Absicherung durch ein Time-based-Token, komplette, automatisch generierte OpenAPI-Dokumentation, Wahnsinn! Und ich habe wirklich nur einzelne Zeilen geändert. (Andererseits: Ich wusste wirklich ganz exakt, was ich wollte, und ich habe viel Datenbank- und Python-Basiswissen. Das hilft natürlich schon.)

So richtig enttäuscht haben mich KI-Tools in letzter Zeit selten. In meinem beruflichen Kontext ergeben sich die größten Probleme bei ganz neuen Frameworks, zu denen die KI zu wenig Trainingsmaterial hat. Das ist aber erwartbar und insofern keine Überraschung. Es ist vielmehr eine Bestätigung, dass KI-Tools keineswegs von sich aus ‚intelligent‘ sind, sondern zuerst genug Trainingsmaterial zum Lernen brauchen.

Was wäre dein größter Wunsch an KI-Coding-Tools?

Bernd: Gute Frage. Aktuell nerven mich ein bisschen die verschiedenen Plugins und die Konfigurationen für unterschiedliche Editoren. Wie gesagt, neovim ist für mich wichtig, da hast du, wie in OpenSource üblich, 23 verschiedene Plugins zur Auswahl :-) Zum Glück gibt es ollama, weil da können alle anbinden. Ich glaub M$ versucht das eh mit CoPilot, eine Lösung, die überall funktioniert, nur ich will halt lokale Modelle und nicht Micro$oft….

Sebastian: Im Moment komme ich mit dem Wünschen ehrlich gesagt gar nicht hinterher, so rasant wie sich alles entwickelt. Microsoft hat GitHub Copilot den Agent Mode spendiert, TypeScript wird “mehr copiloty” und bekommt APIs die eine engere Einbindung von LLMs in den Codingprozess erlauben. Wenn das alles in einer ausreichenden Qualität kommt, hab ich erstmal keine weiteren Wünsche.

Michael: Ich bin wie gesagt ein starker Nutzer der webbasierten KI-Tools. Was ich dabei über alles schätze ist die Möglichkeit, mir die gesamte Konversation zu merken (als Bookmark oder indem ich den Link als Kommentar in den Code einbaue). Ich finde es enorm praktisch, wenn ich mir später noch einmal anschauen kann, was meine Prompts waren und welche Antworten das damalige KI-Modell geliefert hat.

Eine vergleichbare Funktion würde ich mir für IDE-integrierte KI-Tools wünschen. Eine KI-Konversation in VSCode mit GitHub Copilot oder einem anderen Tool sowie die nachfolgenden Code-Umbauten sind später nicht mehr reproduzierbar — aus meiner Sicht ein großer Nachteil.

Beeinflusst die lokale Ausführbarkeit von KI-Tools deinen geplanten bzw. zuletzt durchgeführten Hardware-Kauf?

Bernd: zu 100%! Mein MacBook Pro (gebraucht gekauft, M2 Max mit 64GB) wurde ausschließlch aus diesem Grund gekauft und es war ein großer Gewinn.

Ich habe jetzt ein 2.100 EUR Thinkpad und ein 2.200 EUR MacBook. Rate mal was ich öfter verwende :-) . Die Hardware beim Mac (besonders das Touchpad) ist besser und ich habe quasi alle Linux-Tools auch am Mac (fish-shell, neovim, git, Browser, alle anderen UI-Programme). Wenn ich unter Linux arbeite, denke ich mir oft: »Ah, das kann ich jetzt nicht ollama fragen, weil das nur am MacBook läuft«. Natürlich könnte ich Claude verwenden, aber irgend etwas im Kopf ist dann doch so: »Das muss man jetzt nicht über den großen Teich schicken.«

4000 EUR für die Nvidia-Maschine, die ich zusätzlich zum Laptop mitnehmen muss, ist kein Ding für mich. Ich möchte einen Linux Laptop, der die LLMs so schnell wie der Mac auswerten kann (und noch ein gutes Touchpad hat). Das ist der Wunsch ans Christkind …

Michael: Ein ärgerliches Thema! Ich bin bei Hardware eher sparsam. Vor einem Jahr habe ich mir ein Apple-Notebook (M3 Pro mit 36 GB RAM) gegönnt und damit gerade mein Swift-Buch aktualisiert. Leider waren mir zum Zeitpunkt des Kaufs die Hardware-Anforderungen für lokale LLMs zu wenig klar. Das Notebook ist großartig, aber es hat zu wenig RAM. Den Speicher brauche ich für Docker, virtuelle Maschinen, IDEs, Webbrowser etc. weitgehend selbst, da ist kein Platz mehr für große LLMs.

Aus meiner Sicht sind 64 GB RAM aktuell das Minimum für einen Entwickler-PC mit lokalen LLMs. Im Apple-Universum ist das sündhaft teuer. Im Intel/AMD-Lager gibt es wiederum kein einziges Notebook, das — was die Hardware betrifft — auch nur ansatzweise mit Apple mithalten kann. Meine Linux- und Windows-Rechner kann ich zwar billig mit mehr RAM ausstatten, aber die GPU-Leistung + Speicher-Bandbreite sind vollkommen unzureichend. Deprimierend.

Ein externer Nvidia-Mini-PC (kein Notebook, siehe z.B. die diversen Ankündigungen auf notebookcheck.com) mit 128 GB RAM als LLM-Server wäre eine Verlockung, aber ich bin nicht bereit, dafür plus/minus 4000 EUR auszugeben. Da zahle ich lieber ca. 20 EUR/Monat für ein externes kommerzielles Tool. Aber derartige Rechner, wenn sie denn irgendwann lieferbar sind, wären sicher ein spannendes Angebot für Firmen, die einen lokalen LLM-Server einrichten möchten.

Generell bin ich überrascht, dass die LLM-Tauglichkeit bis jetzt kein großes Thema für Firmen-Rechner und -Notebooks zu sein scheint. Dass gerade Apple hier so gut performt, war ja vermutlich auch nicht so geplant, sondern hat sich mit den selbst entwickelten CPUs als eher zufälliger Nebeneffekt ergeben.

Sebastian: Ursprünglich war mein Plan auf die neuen NVIDIA-Karten zu warten. Nachdem ich aber im Moment eher auf kommerzielle Tools setze und sich mein neues MacBook zufällig als richtige KI-Maschine entpuppt, werde ich erstmal warten, wie sich die Preise entwickeln. Ich bin auch enttäuscht, dass NVIDIA den kleineren karten so wenig Speicher spendiert hat. Meine Hoffnung ist, dass nächstes Jahr die 5080 mit 24GB rauskommt, das wär dann genau meins.

Soeben ist die dritte Auflage unseres Photovoltaik-Buchs erschienen. Für diese Auflage haben wir das Buch an die aktuellen gesetzlichen Richtlinien und Förderungen angepasst. Gerade bei den Förderungen sieht es ja aktuell so aus, als würde die Politik einen Schritt zurück machen. In Österreich läuft die Umstatzsteuerbefreiung für private PV-Anlangen und -Komponenten ironischerweise genau heute aus. Schade!

Unser Buch Coding mit KI wird gerade übersetzt. Heute musste ich diverse Fragen zur Übersetzung beantworten und habe bei der Gelegenheit ein paar Beispiele aus unserem Buch mit aktuellen Versionen von ChatGPT und Claude noch einmal ausprobiert. Dabei ging es um die Frage, ob KI-Tools technische Diagramme (z.B. UML-Diagramme) zeichnen können. Die Ergebnisse sind niederschmetternd, aber durchaus unterhaltsam :-)

UML-Diagramme

Vor einem halben Jahr habe ich ChatGPT gebeten, zu zwei einfachen Java-Klassen ein UML-Diagram zu zeichnen. Das Ergebnis sah so aus (inklusive der falschen Einrückungen):

+-------------------------+
|         Main            |
+-------------------------+
| + main(args: String[]): void |
| + initializeQuestionPool(): List<Question> |
+-------------------------+

+-------------------------+
|        Question         |
+-------------------------+
| - text: String          |
| - answers: List<Answer> |
| - correctAnswers: List<Answer> |
+-------------------------+
| + Question(text: String, answers: List<Answer>, 
|            correctAnswers: List<Answer>) |
| + askQuestion(): void   |
| - validateAnswer(userInput: String): boolean |
+-------------------------+

Dabei war ChatGPT schon damals in der Lage, PlantUML- oder Mermaid-Code zu liefern. Der Prompt Please generate PlantUML code instead liefert brauchbaren Code, der dann in https://www.planttext.com/ visualisiert werden kann. Das sieht dann so aus:

Heute habe ich das ganze Beispiel noch einmal ausprobiert. Ich habe also den Java-Code für zwei Klassen an ChatGPT übergeben und um ein UML-Diagramm gebeten. Vorbei sind die ASCII-Zeiten. Das Ergebnis sieht jetzt so aus:

Leider kann ich hier keinen Link zum ganzen Chat-Verlauf angeben, weil ChatGPT anscheinend nur reine Text-Chat-Verläufe teilen kann.

Visualisierung eines Docker-Setups

Beispiel zwei ergibt sich aus zwei Prompts:

Prompt: I want to build a REST application using Python and Django. The application will run in a Docker container. Do I need a proxy server in this case to make my application visible to the internet?

Prompt: Can you visualize the setup in a diagram?

In der Vergangenheit (Mitte 2024) lieferte ChatGPT das Diagramm als ASCII-Art.

+---------------------------+
|      Client Browser       |
+-----------+---------------+
            |
            v
+-----------+---------------+
|       Nginx Reverse Proxy |
|  (Handles SSL, Load       |
|   Balancing, etc.)        |
+-----------+---------------+
            |
            v
+-----------+----------------+
| Docker Container Network   |
|                            |
|  +----------+   +---------+|
|  |  Web     |   |  DB     ||
|  | Container|   |Container||
|  +----------+   +---------+|
|   (Django)       (Postgres)|
+----------------------------+

Erst auf die explizite Bitte liefert es auch Mermaid-Code, der dann unter https://mermaid.live/ gezeichnet werden kann.

Heute (Dez. 2024) gibt sich ChatGPT nicht mehr mit ASCII-Art ab sondern leitet den Diagrammwunsch an DALL-E weiter. Das Ergebnis ist eine Katastrophe.

Auch Claude.ai zeichnet selbstbewusst ein Diagramm des Docker-Setups. Dabei wird intern Mermaid verwendet.

Fazit

Die Diagramme haben durchaus einen hohen Unterhaltungswert. Aber offensichtlich wird es noch ein wenig dauern, bis KI-Tools brauchbare technische Diagramme zeichnen können. Der Ansatz von Claude wirkt dabei erfolgsversprechender. Technische Diagramme mit DALL-E zu erstellen wollen ist doch eine sehr gewagte Idee von OpenAI.

Die besten Ergebnisse erzielen Sie weiterhin, wenn Sie ChatGPT, Claude oder das KI-Tool Ihrer Wahl explizit um Code in PlantUML oder Mermaid bitten. Den Code können Sie dann selbst visualisieren und bei Bedarf auch weiter optimieren.