Mozilla stellt dem Mozilla Data Collective weitere fünf Millionen USD zur Verfügung. Die Datenplattform will damit ihr Angebot an Datensätzen für die Entwicklung von Künstlicher Intelligenz ausbauen.

Datensätze für mehr als 450 Sprachen

Über das Mozilla Data Collective können Organisationen und Einzelpersonen Datensätze zur Verfügung stellen, ohne die Kontrolle darüber abzugeben. Sie entscheiden selbst, wer die Daten unter welchen Bedingungen nutzen darf und ob sie dafür eine Vergütung verlangen. Auch die Datensätze von Mozilla Common Voice werden über die Plattform angeboten.

Seit dem Start ist das Angebot des Mozilla Data Collective auf über 1.700 Datensätze für mehr als 450 Sprachen gewachsen. Rund 350 Organisationen wurden als Anbieter zugelassen.

Nach Angaben von Mozilla nutzen bereits große KI-Labore, Tausende KI-Startups und wachsende Unternehmen sowie Dutzende Unternehmen mit einer Bewertung von mindestens einer Milliarde Dollar Datensätze der Plattform. Auch wirtschaftlich entwickle sich das Mozilla Data Collective schneller als erwartet: Der auf ein Jahr hochgerechnete Umsatz liege beim Neunfachen des für diese Wachstumsphase gesetzten Ziels.

Weitere Investition für neue Datensätze und Funktionen

Im Mai 2026 erklärte die Mozilla Foundation, bis zu zehn Millionen USD für die Entwicklung des Mozilla Data Collective zugesagt zu haben. Mit den nun angekündigten zusätzlichen fünf Millionen USD möchte Mozilla Data Collective unter anderem kulturelle Videodatensätze sowie größere Textsammlungen für europäische, afrikanische und südasiatische Sprachen erschließen. Geplant sind außerdem neue Lizenzmodelle und günstigere Abonnements für Startups sowie Funktionen, mit denen Organisationen größere Datenbestände kontrollierter bereitstellen können.

Dabei sieht Mozilla auch in der Regulierung einen wichtigen Faktor: Vorschriften wie der AI Act der Europäischen Union lenken mehr Aufmerksamkeit auf die Herkunft von KI-Trainingsdaten sowie auf Lizenzen und die Zustimmung derjenigen, die Daten bereitstellen. Auf diese Punkte legt Mozilla Data Collective bei der Prüfung und Bereitstellung seiner Datensätze bereits Wert.

Der Beitrag Mozilla investiert weitere fünf Millionen USD in Mozilla Data Collective erschien zuerst auf soeren-hentzschel.at.

Mozilla und das kanadische KI-Forschungsinstitut Mila haben eine neue Initiative für vertrauenswürdige Open-Source-KI angekündigt. Mit Unterstützung der kanadischen Regierung soll eine offene KI-Grundlage entstehen, die Organisationen lokal betreiben und vollständig kontrollieren können.

Open-Source-KI einfacher in Betrieb nehmen

Bereits im März hatten Mozilla und Mila eine strategische Partnerschaft angekündigt, um offene und souveräne KI voranzubringen. Nun bauen die beiden Organisationen ihre Zusammenarbeit aus. Auf der kanadischen KI- und Technologiekonferenz ALL IN wurde eine neue gemeinsame Initiative vorgestellt.

Open-Source-Modelle stehen zwar längst zur Verfügung. Ein solches Modell sicher, zuverlässig und in bestehende Systeme integriert produktiv einzusetzen, erfordert aber häufig ein spezialisiertes Entwicklerteam und mehrere Monate Arbeit. Genau an dieser Stelle setzt die Initiative an: Unternehmen und andere Organisationen sollen ein einsatzbereites KI-Paket erhalten, das sie privat und unter eigener Kontrolle betreiben können. Damit sollen sie weder selbst ein komplexes Gesamtsystem entwickeln noch vollständig von proprietären KI-Diensten abhängig sein, bei denen jede Anfrage Kosten verursacht.

Offener Standard und Referenz-Implementierung

Die geplante Grundlage besteht aus zwei Teilen. Ein offener Standard soll in Form klar definierter Schnittstellen veröffentlicht werden. Dadurch sollen sich einzelne Bestandteile des KI-Systems jederzeit gegen bessere Alternativen austauschen lassen.

Dazu kommt eine funktionierende Referenz-Implementierung, die Organisationen auf eigener oder selbst gewählter Infrastruktur installieren können. Dabei sollen sie selbst entscheiden können, welche Modelle und Kontrollmechanismen sie einsetzen und mit welchen eigenen Daten das System arbeitet. Funktionen für die Verwaltung des Systems und von Zugriffsrechten sollen von Anfang an integriert sein.

Als mögliches Einsatzszenario nennt Mozilla einen kleineren Produktionsbetrieb. Ein privater KI-Assistent könnte dort Handbücher, Arbeitsabläufe und frühere Projektdateien durchsuchen, beim Verfassen von Berichten helfen, technische Fragen beantworten oder die Softwareentwicklung unterstützen. Da das System lokal betrieben werden kann, bleiben vertrauliche Unternehmensdaten in der eigenen Umgebung. Neben Unternehmen richtet sich das Projekt unter anderem auch an Krankenhäuser, gemeinnützige Organisationen und Behörden.

Sechs Millionen Dollar als Anschubfinanzierung

Mila übernimmt die technische Umsetzung und Koordination des Projekts, während Mozilla seine technische Expertise einbringt und fünf Millionen Dollar als Anschubfinanzierung bereitstellt. Der kanadische Hardware-Anbieter Hypertec investiert im ersten Jahr eine weitere Million Dollar, um erste Installationen bei kanadischen Unternehmen und Institutionen zu beschleunigen. Unterstützt wird die Initiative außerdem von der kanadischen Regierung. Weitere Unternehmen, Forschungseinrichtungen, Geldgeber, Regierungen und Entwickler sind eingeladen, sich an dem Projekt zu beteiligen.

An der Architektur und der Auswahl geeigneter Open-Source-Komponenten arbeiten Mozilla und Mila bereits seit sechs Monaten. Innerhalb der kommenden sechs Monate sollen erste funktionierende Referenz-Implementierungen für Unternehmen, Behörden und gemeinwohlorientierte Anwendungsfälle veröffentlicht werden. Das weiter gefasste Ziel für die kommenden zwei Jahre ist es, Open-Source-KI so einfach einsetzbar zu machen, dass sie überall und von jedem genutzt werden kann.

Dass hier noch eine Lücke besteht, zeigt Mozillas „State of Open Source AI“-Bericht: Zwar setzen 79 Prozent der Entwickler, die KI-Funktionen integrieren, auf offene Modelle. In den produktiven Einsatz schaffen es jedoch nur 53 Prozent der Teams. Als größte Hürden gelten Kosten, Sicherheit, Integration und Wartung.

Der Beitrag Mozilla und Mila starten neue Open-Source KI-Initiative erschien zuerst auf soeren-hentzschel.at.

Was ist BTRFS

Weil ich mich gerade intensiv mit BTRFS beschäftige und dazu einige Recherchen durchführe, um für mich Licht in dieses Thema zu bringen, hier eine Auflistung meiner Funde, Erklärungen und Anleitungen. Wenn du Anmerkungen dazu hast, bin ich im Fediverse (About Seite) zu finden. Ansonsten hoffe ich wie immer, dass dieser Artikel dem einen oder der anderen hilft ebenfalls mehr Klarheit in das Thema zu bringen. Und … schreibt selbst mehr Blogartikel!

BTRFS steht für B-Tree File System und ist ein modernes Copy-on-Write-Dateisystem, das ursprünglich 2007 von Chris Mason bei Oracle entwickelt und 2009 in den Linux Kernel 2.6.29 aufgenommen wurde. Es wird heute von verschiedenen Distributionen und Unternehmen unterstützt, darunter Debian, SUSE, Red Hat, Fujitsu und Intel.

Der wesentliche Unterschied zu klassischen Dateisystemen wie ext4 oder NTFS besteht darin, dass BTRFS Daten nicht überschreibt. Wird eine Datei geändert, schreibt BTRFS die neue Version an eine andere Stelle, während die alte Version erhalten bleibt, bis sie nicht mehr benötigt wird.

Daraus ergeben sich mehrere Funktionen:

• Snapshots: Momentaufnahmen des Dateisystems zu einem bestimmten Zeitpunkt, die anfangs kaum zusätzlichen Speicherplatz belegen.
• Datenintegrität: BTRFS berechnet Prüfsummen für Daten und Metadaten. Fehler durch defekten RAM oder alternde Datenträger werden erkannt und können bei vorhandener Redundanz (z.B. RAID1) korrigiert werden.
• Subvolumes: Das Dateisystem lässt sich in logische Teile gliedern, ähnlich Partitionen, aber flexibler.
• Transparente Komprimierung: Daten können on-the-fly komprimiert werden (z.B. mit zstd).
• Integrierte RAID-Unterstützung für RAID 0, 1, 10, 5 und 6.

Was sind Snapshots

Ein Snapshot ist eine Momentaufnahme des Dateisystems. Der aktuelle Zustand eines Ordners wird festgehalten und kann später wiederhergestellt werden.

Durch Copy-on-Write belegt ein frischer Snapshot zunächst kaum zusätzlichen Speicherplatz. Er verweist auf dieselben Datenblöcke wie das Original. Erst wenn Änderungen vorgenommen werden, entstehen neue Blöcke, während die alte Version im Snapshot erhalten bleibt. Der zusätzliche Platzverbrauch entspricht also der Differenz zwischen Original und Snapshot.

Daraus ergeben sich typische Einsatzbereiche:

• Vor System-Updates: Snapshot anlegen, Update durchführen, bei Problemen zurückrollen.
• Automatische Backups: Tools wie Snapper können in festen Intervallen Snapshots erstellen und alte automatisch löschen.
• Experimente: Änderungen lassen sich testen und bei Bedarf vollständig rückgängig machen.

Wichtig: Ein Snapshot ist kein Backup. Bei einem Hardware-Ausfall sind Original und Snapshot verloren. Snapshots schützen vor logischen Fehlern wie fehlerhaften Updates oder versehentlichem Löschen, nicht vor Hardware-Ausfällen. Für echte Backups werden Snapshots mit btrfs send und btrfs receive auf ein anderes Medium übertragen.

Hinweise

Snapshots sind kein Ersatz für Backups. Einige Punkte sind zu beachten:

• Platzverbrauch: Alte Snapshots können über die Zeit viel Platz belegen, da sie die Differenzen zu späteren Änderungen halten. Automatische Bereinigung ist daher sinnvoll.
• Performance: Bei sehr großen Datenmengen oder Datenbanken kann Copy-on-Write bremsen. Für solche Fälle können Dateien oder Subvolumes mit dem nodatacow-Attribut markiert werden.
• Kernel und Bootloader: Wird /boot in den Snapshot einbezogen, kann ein Rollback problematisch werden, wenn Kernel und Module nicht mehr zusammenpassen. Viele Distributionen schließen /boot daher aus oder behandeln den Kernel separat.

Snapshots mit btrfs “tool”

Snapshots lassen sich vollständig ohne zusätzliche Werkzeuge wie Snapper oder Timeshift erstellen und verwalten. Die notwendigen Befehle sind Teil von btrfs-progs, das auf jedem System mit Btrfs-Unterstützung vorhanden ist.

Snapshot erstellen

Ein Snapshot wird mit btrfs subvolume snapshot erstellt. Der Befehl benötigt ein Quell-Subvolume und ein Zielverzeichnis für den Snapshot.

Schreibgeschützter Snapshot (empfohlen für Backups):

sudo btrfs subvolume snapshot -r /home /snapshots/home/home_snapshot_$(date +%Y%m%d_%H%M%S)

Die Option -r erzeugt einen schreibgeschützten Snapshot. Dieser kann nicht versehentlich verändert werden und eignet sich für die spätere Übertragung mit btrfs send.

Schreibbarer Snapshot (für Tests oder Klone):

sudo btrfs subvolume snapshot /home /snapshots/home/home_snapshot_ro

Ohne -r entsteht ein beschreibbarer Snapshot, der wie eine vollständige Kopie des Dateisystems genutzt werden kann.

Wichtig: Snapshots können nur von Subvolumes erstellt werden, nicht von normalen Verzeichnissen. Wenn die Quelle kein Subvolume ist, gibt Btrfs einen Fehler zurück. Das Zielverzeichnis /snapshots/home/ muss dabei auf einem eigenen Subvolume liegen oder außerhalb des Quell-Subvolumes, damit keine rekursive Struktur entsteht.

Snapshot auflisten

Alle Subvolumes und Snapshots lassen sich mit folgendem Befehl anzeigen:

sudo btrfs subvolume list /

Die Ausgabe zeigt unter anderem die ID, die übergeordnete ID und den Pfad jedes Subvolumes. Mit der Option -s werden nur Snapshots aufgelistet, mit -r nur schreibgeschützte.

Eine typische Ausgabe von sudo btrfs subvolume list / sieht so aus:

ID 256 gen 12345 top level 5 path @
ID 257 gen 12340 top level 5 path @home
ID 258 gen 12200 top level 5 path @snapshots
ID 259 gen 12050 top level 5 path snapshots/home/home_snapshot_2026-03-14
ID 260 gen 11980 top level 5 path snapshots/home/home_snapshot_ro

Die Spalten im Einzelnen:

• ID: Die eindeutige Nummer des Subvolumes. Diese wird intern von Btrfs verwendet und ist nicht mit der Snapshot-Nummer von Snapper zu verwechseln.
• gen: Die Generation, also ein Zähler, der bei jeder Transaktion im Dateisystem erhöht wird. Ein höherer Wert bedeutet, dass das Subvolume später zuletzt geändert wurde.
• top level: Die ID des übergeordneten Subvolumes. Der Wert 5 steht für das Top-Level-Subvolume, also die Wurzel des Btrfs-Dateisystems.
• path: Der Pfad des Subvolumes relativ zum Top-Level-Subvolume. Hier wird sichtbar, wo das Subvolume im Baum hängt.

In diesem Beispiel erkennt man:

• @ ist das Root-Subvolume (ID 256).
• @home ist ein separates Subvolume für /home (ID 257).
• @snapshots ist ein eigenes Subvolume (ID 258).
• snapshots/home/home_snapshot_2026-03-14 und snapshots/home/home_snapshot_ro sind die Snapshots, die unter dem Pfad /snapshots/home/ angelegt wurden.

Hinweis: Die Ausgabe zeigt die Pfade relativ zum Top-Level-Subvolume, nicht relativ zum gemounteten Root. Wenn /snapshots als separates Subvolume eingebunden ist, erscheint der Snapshot-Pfad entsprechend unter snapshots/home/.... Wird /snapshots nicht separat gemountet, liegen die Snapshots innerhalb des Root-Subvolumes und tauchen als @/snapshots/home/... auf.

Mit der Option -s werden nur Snapshots angezeigt:

sudo btrfs subvolume list -s /

Mit der Option -r nur schreibgeschützte Subvolumes:

sudo btrfs subvolume list -r /

Mit der Option -t wird zusätzlich die Art des Subvolumes ausgegeben (snapshot oder subvolume):

sudo btrfs subvolume list -t /

Snapshot löschen

Ein Snapshot wird nicht mit rm -rf entfernt, sondern mit:

sudo btrfs subvolume delete /snapshots/home/home_snapshot_ro

Das entsprechende Verzeichnis wird sofort entfernt, die eigentlichen Datenblöcke werden jedoch im Hintergrund gelöscht. Der Befehl kehrt sofort zurück, ohne auf den Abschluss der Datenlöschung zu warten.

Soll gewartet werden, bis die Löschung vollständig abgeschlossen ist:

sudo btrfs subvolume sync /snapshots/home

Snapshot zurückrollen

Für das Zurückrollen auf einen Snapshot wird das aktuelle Subvolume verschoben und der Snapshot an seine Stelle kopiert:

## Aktuelles Subvolume als Backup umbenennen
sudo mv /mnt/btrfs_root/@home /mnt/btrfs_root/@home_backup_$(date +%Y%m%d)

## Snapshot als neues Subvolume kopieren
sudo btrfs subvolume snapshot \
  /snapshots/home/home_snapshot_20260301 \
  /mnt/btrfs_root/@home

Nach einem erneuten Einbinden steht der wiederhergestellte Zustand zur Verfügung. Der alte Zustand bleibt unter @home_backup_... erhalten, bis er manuell gelöscht wird.

Snapshots sichern mit send/receive

Für echte Backups außerhalb des Systems dienen btrfs send und btrfs receive. Beide Operationen erfordern schreibgeschützte Snapshots.

Initiales Backup:

sudo btrfs send /snapshots/home/home_snapshot_ro | btrfs receive /backupvol

Inkrementelles Backup (nur Änderungen seit dem letzten Snapshot):

sudo btrfs send -p /snapshots/home/home_snapshot_ro /snapshots/home/home_snapshot_20260314 | btrfs receive /backupvol

Die Option -p gibt den vorherigen Snapshot als Parent an. Übertragen werden nur die Differenzen zwischen beiden Snapshots.

@snapshots anlegen, konfigurieren und verwenden

Der Speicherort für Snapshots wird im Btrfs-Subvolume-Layout und in /etc/fstab festgelegt, nicht in Snappers Konfigurationsdatei. In Snappers Konfiguration gibt SUBVOLUME lediglich an, für welches Verzeichnis Snapshots erstellt werden sollen (z. B. /). Ob die Snapshots im selben Subvolume verbleiben oder ausgelagert werden, entscheidet die Konfiguration über die Btrfs-Subvolume-Struktur und die Mount-Einträge in /etc/fstab.

In der Snapper Konfiguration wird Bezug auf die @snapshots Definitionen in der /etc/fstab genommen.

Btrfs-Optionsliste

subvol=NAME / subvolid=ID Legt fest, welches Subvolume unter dem Einhängepunkt erscheint. subvol=@ mountet das Subvolume @ als Root. Ohne diese Option wird das Standard-Subvolume verwendet .

compress=TYPE / compress-force=TYPE Aktiviert transparente Kompression. Mögliche Typen: zlib (Standard), lzo, zstd. compress-force komprimiert auch schlecht komprimierbare Dateien. Wichtig: Komprimierung ist mit nodatacow unvereinbar – bei aktivem nodatacow wird compress ignoriert .

nodatacow Deaktiviert Copy-on-Write für das gesamte Dateisystem. Wichtig: Diese Option wirkt sich auf das ganze Dateisystem aus, nicht nur auf ein Subvolume. Nur die Optionen des zuerst gemounteten Subvolumes sind wirksam . nodatacow impliziert nodatasum – es werden keine Prüfsummen mehr berechnet .

nodatasum Deaktiviert Prüfsummen für Daten. Wird automatisch bei nodatacow aktiviert .

autodefrag / noautodefrag Aktiviert automatische Defragmentierung bei kleinen, zufälligen Schreibvorgängen. Nicht geeignet für Datenbanken oder VM-Images . Warnung: Kann bei Snapshots/Reflinks die Extent-Freigabe zerstören und den Speicherverbrauch stark erhöhen .

commit=SECONDS Setzt das Intervall für periodische Commits. Standard: 30 Sekunden. Höhere Werte verzögern das Schreiben auf persistente Speicherung – bei Systemabsturz gehen mehr Daten verloren .

ssd / nossd Teilt dem Dateisystem mit, dass es auf einem SSD läuft. Btrfs optimiert dann die Block-Allokation. Auf modernen Kerneln oft automatisch erkannt .

discard / nodiscard / discard=async discard aktiviert synchrones TRIM bei jedem Löschen – kann die Performance beeinträchtigen. discard=async (seit Kernel 5.6) sammelt freigegebene Blöcke und führt TRIM asynchron aus – die bevorzugte Methode. Alternativ: nodiscard und periodisches fstrim .

space_cache / space_cache=v1 / space_cache=v2 / nospace_cache Steuert den Free-Space-Cache. v2 (Standard seit Kernel 4.5) ist für große Dateisysteme deutlich performanter. nospace_cache deaktiviert den Cache .

acl / noacl Aktiviert/deaktiviert POSIX ACLs. Standard: acl .

barrier / nobarrier barrier (Standard) stellt sicher, dass I/O-Operationen durch den Geräte-Cache gehen und persistent gespeichert werden. nobarrier kann die Performance erhöhen, führt bei Stromausfall aber mit Sicherheit zu Datenverlust .

degraded Erlaubt das Mounten mit fehlenden Geräten (z. B. bei RAID). Ein Read-Write-Mount kann fehlschlagen, wenn zu viele Geräte fehlen .

skip_balance Überspringt die automatische Wiederaufnahme einer unterbrochenen Balance-Operation .

Optionen für spezielle Einsatzzwecke

Swapfile auf Btrfs Ein Swapfile muss folgende Bedingungen erfüllen :

• Muss vorgelagert (preallocated) sein, keine Holes
• Muss NODATACOW sein (impliziert NODATASUM) - mehr im nächsten Kapitel
• Keine Kompression
• Das enthaltende Subvolume darf nicht snapshottet werden, solange das Swapfile aktiv ist
• Nur ein einziges Gerät und ein einziges Datenprofil

Beispiel für ein Swap-Subvolume in der fstab:

UUID=... /swap btrfs subvol=@swap,nodatacow,noatime 0 0

/etc/stab Praktisches Beispiel

Hier eine Beispiel fstab mit den wichtigsten Optionen.

##                                                                                    
UUID=xxxxxxxx-xxxx-xxxx-xxxx   /               btrfs   subvol=@,compress=zstd:3,noatime,ssd,discard=async,space_cache=v2   0       1
UUID=xxxxxxxx-xxxx-xxxx-xxxx   /home           btrfs   subvol=@home,compress=zstd:3,noatime,ssd,discard=async,space_cache=v2  0       2
UUID=xxxxxxxx-xxxx-xxxx-xxxx   /.snapshots     btrfs   subvol=@snapshots,noatime,ssd,space_cache=v2                        0       0

Kritische Einschränkungen zu nodatacow und compress

1. Optionen gelten für das gesamte Dateisystem: nodatacow, nodatasum und compress können nicht pro Subvolume über Mount-Optionen gesteuert werden. Nur die Optionen des ersten gemounteten Subvolumes zählen .

2. chattr +C - Um Copy-on-Write nur für bestimmte Daten zu deaktivieren, ohne das gesamte Dateisystem zu beeinträchtigen, ist das Setzen des C-Attributs auf Datei- oder Verzeichnisebene der richtige Weg

3. nodatacow + compress schließen sich aus: Wird nodatacow gesetzt, ist Kompression automatisch deaktiviert .

4. nodatacow und Snapshots: Snapshots funktionieren weiterhin, aber beim ersten Schreiben nach einem Snapshot wird CoW erzwungen, um die alten Blöcke zu bewahren. Der Vorteil von nodatacow ist damit eingeschränkt .

5. nodatacow entfernt Datenintegrität: Ohne nodatasum gibt es keine Prüfsummen. Auf Multi-Disk-Systemen (RAID1) kann nach einem Absturz nicht festgestellt werden, welche Kopie korrekt ist – mit etwa 50% Wahrscheinlichkeit wird die beschädigte Kopie gelesen .

6. autodefrag bei Snapshots vermeiden: Auto-Defragmentierung bricht Reflink- und Snapshot-Verbindungen auf und kann den Speicherverbrauch erheblich steigern .

chattr +C statt nodatacow

Um Copy-on-Write nur für bestimmte Daten (z. B. VM-Images oder Datenbanken) zu deaktivieren, ohne das gesamte Dateisystem zu beeinträchtigen, ist das Setzen des C-Attributs auf Datei- oder Verzeichnisebene der richtige Weg

## Neues, leeres Verzeichnis erstellen (oder ein bestehendes umbenennen)
sudo mkdir /var/lib/libvirt/images_nocow
sudo chattr +C /var/lib/libvirt/images_nocow

Alle neu erstellten Dateien in diesem Verzeichnis erben das NOCOW-Attribut

Für bereits existierende Dateien ist ein Workaround nötig:

# Verzeichnis umbenennen, neu erstellen, Attribut setzen, Daten zurückkopieren
sudo mv /var/lib/libvirt/images /var/lib/libvirt/images_old
sudo mkdir /var/lib/libvirt/images
sudo chattr +C /var/lib/libvirt/images
sudo cp -a --reflink=never /var/lib/libvirt/images_old/. /var/lib/libvirt/images/
sudo rm -rf /var/lib/libvirt/images_old

Der Parameter --reflink=never ist entscheidend, da cp sonst standardmäßig eine CoW-Kopie (Reflink) erstellt, die das Attribut nicht übernimmt.

Wichtige Einschränkung: Snapshots

Auch mit chattr +C gibt es eine Einschränkung: Wenn ein Snapshot erstellt wird, bricht dieser die NOCOW-Eigenschaft teilweise auf. Beim ersten Schreiben in eine Datei nach einem Snapshot wird CoW erzwungen, um die alten Blöcke für den Snapshot zu bewahren. Danach greift wieder NOCOW, bis der nächste Snapshot erstellt wird.

Für VM-Images oder Datenbanken, die von Snapshots ausgeschlossen werden sollen, empfiehlt es sich daher, sie in eine eigene Partition mit mit nodatacow oder eventuell anderem Dateisystem anzulegen.

Das Standard-Layout bei Manjaro

Manjaro legt bei der automatischen Partitionierung eine große Btrfs-Partition mit mehreren Subvolumes an. Die Namenskonvention beginnt traditionell mit einem @-Zeichen.

Obwohl die genauen Namen je nach Installer-Version variieren können, entspricht das typische Layout dem, was auch in der Manjaro-Wiki als Konvention beschrieben wird:

• @: Das Root-Dateisystem (/).
• @home: Das Verzeichnis für Benutzerdaten (/home).
• @snapshots (optional): In der Wiki wird dieses Subvolume als Beispiel für einen möglichen Snapshot-Speicherort erwähnt, aber es ist nicht Teil der Standard-Installation.

Das bedeutet: Bei einer Standard-Manjaro-Installation liegen alle Snapshots, die du beispielsweise mit Timeshift oder Snapper erstellst, standardmäßig innerhalb des @-Subvolumes unter /.snapshots. Ein separates Subvolume für Snapshots wird nicht erstellt.

Das Standard-Layout bei TUXEDO OS (Debian-Basis)

TUXEDO OS nutzt Btrfs und Snapper standardmäßig, um automatische Snapshots vor und nach Paket-Updates zu erstellen.

TUXEDO gibt an, dass bei der Installation sechs Subvolumes angelegt werden, die als getrennte Namensräume innerhalb einer Btrfs-Partition fungieren. Die genauen Namen dieser sechs Subvolumes werden in der offiziellen Ankündigung jedoch nicht explizit aufgeführt.

Was aus den offiziellen TUXEDO-Dokumenten bekannt ist:

• Snapper ist vorkonfiguriert und erstellt automatisch Snapshots.
• Ein grafisches Tool namens Btrfs Assistant ist installiert, um Subvolumes und Snapshots zu verwalten.
• Der erste Snapshot wird bereits beim ersten Bootvorgang erstellt und als „Factory Image“ bezeichnet.

Automatisierung ohne externe Tools

Für regelmäßige Snapshots genügt ein Eintrag in der Crontab. Ein einfaches Shell-Skript erstellt einen zeitgestempelten Snapshot:

#!/bin/bash
NOW=$(date +"%Y-%m-%d_%H:%M:%S")
mkdir -p /snapshots/home
sudo btrfs subvolume snapshot -r /home "/snapshots/home/home_snapshot_${NOW}"

Dieses Skript kann per cron oder systemd-timer in festen Intervallen ausgeführt werden.

• Snapshots sind keine Backups. Sie liegen auf demselben Dateisystem. Bei einem Hardware-Ausfall sind Original und Snapshot verloren. Für echte Backups müssen Snapshots auf ein anderes Medium übertragen werden, etwa mit btrfs send.
• Alte Snapshots regelmäßig löschen. Snapshots belegen Speicherplatz, auch wenn sie anfangs kaum zusätzlichen Platz benötigen. Mit der Zeit sammeln sich Differenzen an. Ein regelmäßiges Aufräumen ist notwendig.
• Nested Subvolumes beachten. Wenn ein Subvolume ein anderes Subvolume enthält, wird dieses beim Snapshot nicht mitgesichert. Der Verzeichniseintrag bleibt leer. Für vollständige Sicherungen müssen verschachtelte Subvolumes separat behandelt werden.

Tool: Snapper - Snapshotverwaltung

Snapper ist ein Werkzeug zur Verwaltung von Dateisystem-Snapshots unter Linux. Es wurde ursprünglich von SUSE entwickelt und ist heute in vielen Distributionen verfügbar.

Snapper automatisiert das Erstellen, Verwalten und Bereinigen von BTRFS-Snapshots. Es legt Snapshots manuell, oder auch automatisch bei Paket-Updates oder auch zeitgesteuert an.

List

Mit snapper geht es komfortabler. Snapshots auflisten mit

snapper list

Eine typische Ausgabe von snapper list sieht so aus:

 # | Typ   | Vor # | Datum                        | Benutzer | Bereinigung | Beschreibung
---+-------+-------+------------------------------+----------+-------------+---------------------------
 0 | single|       |                              | root     |             | current
 1 | single|       | 2026-09-20 08:15:03 +0200    | root     | timeline    | timeline
 2 | pre   |       | 2026-09-22 19:40:11 +0200    | root     | number      | zypp(packagekitd)
 3 | post  |     2 | 2026-09-22 19:41:57 +0200    | root     | number      | zypp(packagekitd)
 4 | single|       | 2026-09-23 03:00:01 +0200    | root     | timeline    | timeline
 5 | pre   |       | 2026-09-25 14:02:33 +0200    | root     | number      | zypp(zypper)
 6 | post  |     5 | 2026-09-25 14:03:12 +0200    | root     | number      | zypp(zypper)

Die Spalten im Einzelnen:

• #: Die Nummer des Snapshots. Diese wird für snapper delete, snapper diff oder snapper undochange verwendet.
• Typ: single für eigenständige Snapshots, pre und post für Paare vor und nach einer Änderung.
• Vor #: Bei einem post-Snapshot die Nummer des zugehörigen pre-Snapshots. Bei single und pre bleibt die Spalte leer.
• Datum: Zeitpunkt der Erstellung.
• Benutzer: Der Benutzer, der den Snapshot ausgelöst hat (meist root).
• Bereinigung: Die Cleanup-Strategie. timeline für zeitgesteuerte Snapshots, number für eine feste Anzahl, empty-pre-post für verwaiste Paare.
• Beschreibung: Freitext, bei Paketoperationen etwa zypp(zypper) oder zypp(packagekitd).

An diesem Beispiel sieht man auch, warum Pre/Post-Paare gemeinsam gelöscht werden sollten: Snapshot 5 und 6 gehören zusammen, ebenso 2 und 3. Ein snapper delete 5-6 entfernt das Paar 5 und 6, ein snapper delete 2-3 entsprechend das Paar 2 und 3.

Änderungen - diff

Um Änderungen zwischen zwei Snapshots zu sehen, dient snapper diff:

sudo snapper -c root diff 1..3

Die Ausgabe zeigt, welche Dateien zwischen den Snapshots hinzugefügt, gelöscht oder geändert wurden.

Löschen

Bei Verwendung von snapper erfolgt das Löschen über:

sudo snapper -c root delete NUMBER

Dabei ist NUMBER die Nummer des Snapshots aus snapper list. Automatisch erstellte Pre/Post-Paare – etwa vor und nach einem Paket-Update – sollten immer gemeinsam gelöscht werden, da sie zusammengehören. Snapper kann das mit einem Befehl erledigen:

sudo snapper -c root delete NUMBER1-NUMBER2

Damit werden beide Snapshots des Paares in einem Schritt entfernt.

Lösch Strategie

Es gibt Situationen, in denen nur der post-Snapshot entfernt wird, während der pre-Snapshot erhalten bleibt. Sinnvoll ist das zum Beispiel, wenn:

• Der Pre-Snapshot als Rollback-Punkt dienen soll: Vor einem Update wird ein pre-Snapshot angelegt. Nach dem Update wird der post-Snapshot normalerweise nur zur Dokumentation der Änderungen benötigt. Will man den Rollback-Punkt behalten, aber die Vergleichsbasis nicht mehr, löscht man nur den post.
• Speicherplatz knapp wird: Der pre-Snapshot markiert den Zustand vor der Änderung und ist damit der eigentlich wertvolle. Der post-Snapshot ist oft entbehrlich, wenn die Änderung erfolgreich war.
• Snapper bei number-Cleanup nicht greift: Snapper löscht bei der Cleanup-Strategie number bevorzugt ganze Paare. Bleibt ein einzelner Snapshot übrig – etwa weil der pre manuell als schützenswert markiert wurde – muss der post unter Umständen manuell entfernt werden.

In der Praxis ist das Löschen nur des post-Snapshots eher die Ausnahme. Üblich ist, dass beide gemeinsam entfernt werden, weil der pre-Snapshot ohne zugehörigen post bei der Bereinigung als verwaist gilt und dann über die Strategie empty-pre-post automatisch entfernt wird.

Zurückrollen

Snapper bietet zwei Varianten:

1. Einzelne Dateien wiederherstellen: Mit snapper undochange werden Änderungen zwischen zwei Snapshots rückgängig gemacht. Die Snapshots selbst liegen unter /.snapshots/NUMBER/snapshot/ und können auch direkt eingesehen werden.
2. Komplettes System zurückrollen: Mit snapper rollback wird das Root-Subvolume auf einen früheren Snapshot zurückgesetzt. Voraussetzung ist, dass zuvor in den gewünschten Snapshot gebootet wurde.

Wiederherstellen einzelne Dateien

Ein Snapshot verhält sich wie ein normales Verzeichnis. Bei Verwendung von Snapper liegen die Snapshots unter /.snapshots/NUMBER/snapshot/:

##### Snapshot-Inhalt ansehen
ls /.snapshots/5/snapshot/home/hoergen/

##### Einzelne Datei aus dem Snapshot zurückkopieren
sudo cp /.snapshots/5/snapshot/home/hoergen/.bashrc /home/hoergen/.bashrc

Alternativ kann snapper undochange verwendet werden, um Änderungen zwischen zwei Snapshots rückgängig zu machen:

##### Änderungen zwischen Snapshot 5 (pre) und 6 (post) rückgängig machen
sudo snapper -c root undochange 5..6

Sollen nur bestimmte Dateien zurückgesetzt werden, können diese explizit angegeben werden:

sudo snapper -c root undochange 5..6 /etc/fstab /etc/default/grub

Komplettes System wiederherstellen - Rollback

Für das vollständige Zurückrollen des Root-Dateisystems bietet Snapper den Befehl snapper rollback. Voraussetzung ist, dass das System zuvor in den gewünschten Snapshot gebootet wurde. Dies geschieht über das Boot-Menü, das Snapper zusammen mit grub-btrfs bereitstellt. Im GRUB-Menü erscheint ein Eintrag „BTRFS Snapshots", aus dem ein beliebiger Snapshot als Root-Subvolume gebootet werden kann.

Nach dem Booten in den Snapshot ist das Dateisystem schreibgeschützt eingebunden. Der Rollback wird dann mit folgendem Befehl ausgeführt:

sudo snapper rollback

Optional mit Beschreibung:

sudo snapper rollback -d "Rollback nach fehlerhaftem Update"

Snapper erstellt dabei automatisch einen Snapshot des Zustands vor dem Rollback. Nach einem Neustart ist das System auf dem Stand des gewählten Snapshots.

Wichtig: snapper rollback funktioniert nur für das Root-Subvolume /. Andere Subvolumes wie /home werden nicht mit zurückgesetzt.

Automatisierung mit Snapper

Manuelles Erstellen von Snapshots ist auf Dauer unpraktisch. Snapper kann automatisch Timeline-Snapshots anlegen (z.B. stündlich, täglich, wöchentlich) und alte nach definierten Regeln löschen, damit der Speicherplatz nicht vollläuft.

Typische Konfiguration unter /etc/snapper/configs/root:

TIMELINE_CREATE="yes"
TIMELINE_CLEANUP="yes"
TIMELINE_LIMIT_HOURLY="6"
TIMELINE_LIMIT_DAILY="7"
TIMELINE_LIMIT_WEEKLY="4"
TIMELINE_LIMIT_MONTHLY="6"
TIMELINE_LIMIT_YEARLY="2"
FREE_LIMIT="0.2"    # Mindestens 20% frei lassen

Aktivierung der Timer:

sudo systemctl enable --now snapper-timeline.timer
sudo systemctl enable --now snapper-cleanup.timer

Damit laufen die automatischen Snapshots und die Bereinigung. Vor einem pacman -Syu oder apt upgrade kann zusätzlich ein manueller Snapshot mit Beschreibung angelegt werden:

sudo snapper -c root create --description "vor dem Update"

Nach dem Update lässt sich mit snapper diff nachvollziehen, was sich geändert hat. Bei Bedarf kann zurückgerollt werden.

Tool: grub-btrfs

grub-btrfs ist ein eigenständiges Tool, das die von Snapper erstellten Snapshots in das GRUB-Menü einbindet. Nach der Installation erscheint im GRUB-Menü ein Eintrag „BTRFS Snapshots", aus dem heraus ein beliebiger Snapshot als Root-Subvolume gebootet werden kann. Dies ist die Voraussetzung für den Rollback mit snapper rollback.

Defragmentierung: Möglichkeiten und Probleme

Der Befehl btrfs filesystem defragment ermöglicht die Defragmentierung von Dateien und Verzeichnis-Metadaten im laufenden Betrieb.

Die Anwendung ist jedoch mit erheblichen Einschränkungen verbunden, insbesondere beim Einsatz von Snapshots oder Reflink-Kopien.

Ein Reflink (kurz für „Reference Link“) ist eine spezielle Art von Dateikopie, die moderne Dateisysteme wie Btrfs oder XFS unterstützen. Sie nutzt das Copy-on-Write-Prinzip (CoW), um eine Kopie zu erstellen, die zunächst keinen zusätzlichen Speicherplatz belegt und nahezu augenblicklich fertig ist

Fragmentierung prüfen

Bevor eine Defragmentierung durchgeführt wird, sollte geprüft werden, ob überhaupt eine relevante Fragmentierung vorliegt. Btrfs meldet Fragmentierung nicht automatisch. Der zuverlässigste Weg ist die Messung der Extents pro Datei mit filefrag sowie die Beobachtung des tatsächlichen Performance-Verhaltens.

Es gibt keine Möglichkeit ein ganzes Volume zu prüfen. Es geht nur über filefrag

Ein ganzes Btrfs-Volume lässt sich nicht direkt als Ganzes auf seinen Fragmentierungsgrad prüfen. Es gibt keinen Befehl, der eine einzelne Zahl oder einen Prozentsatz für die Fragmentierung des gesamten Dateisystems ausgibt.

Der Grund liegt in der Arbeitsweise von Btrfs. Fragmentierung ist ein Zustand, der sich auf einzelne Dateien bezieht, nicht auf das Volume als Ganzes. Ein Volume kann Tausende von Dateien enthalten, von denen einige stark fragmentiert und andere gar nicht fragmentiert sind. Es gibt keine sinnvolle einzelne Kennzahl, die das zusammenfassen würde.

Es gibt einen indirekten Ansatz über den Speicherverbrauch. Wenn btrfs filesystem df eine große Diskrepanz zwischen Size (allokierter Platz) und Used (tatsächlich belegter Platz) zeigt, deutet das auf fragmentierte oder verwaiste Extents hin. Das ist aber keine Messung der Fragmentierung, sondern eine Reaktion auf eine vermutete Ursache.

Fragmentierung einzelner Dateien messen

filefrag ist Teil des Pakets e2fsprogs und funktioniert dank FIEMAP-Unterstützung auch auf Btrfs. Eine Datei mit einem einzigen Extent ist nicht fragmentiert; je mehr Extents, desto stärker die Fragmentierung.

## Fragmentierung einer einzelnen Datei prüfen
filefrag /home/hoergen/.bashrc

Beispielausgabe:

/home/hoergen/.bashrc: 3 extents found

Die am stärksten fragmentierten Dateien finden

Für einen Überblick über ein Verzeichnis kann die Ausgabe sortiert werden. Die Zahl der Extents steht in der zweiten Spalte:

## Top 10 der fragmentiertesten Dateien im aktuellen Verzeichnis
filefrag * | sort -nr -k 2 | head -10

sort -nr -k 2 die Zeilen also nach der Extent-Anzahl, absteigend, mit der höchsten Zahl oben.

• -n: Numerische Sortierung. Ohne diese Option würde sort alphabetisch sortieren, sodass z. B. 10 vor 2 käme. Mit -n wird der Zahlenwert interpretiert.

• -r: Umgekehrte Reihenfolge (reverse). Statt aufsteigend wird absteigend sortiert, also die größte Zahl zuerst.

• -k 2: Sortierschlüssel ist die zweite Spalte. Standardmäßig trennt sort Spalten an Leerzeichen. In der Ausgabe von filefrag ist die zweite Spalte die Anzahl der Extents.

• head -10 gibt standardmäßig die ersten zehn Zeilen der Eingabe aus. Da die Eingabe zuvor absteigend nach Extent-Anzahl sortiert wurde, stehen hier die zehn am stärksten fragmentierten Dateien des Verzeichnisses.

Für das Home-Verzeichnis entsprechend:

## Top 10 der fragmentiertesten Dateien in /home/hoergen
cd /home/hoergen
filefrag * | sort -nr -k 2 | head -10

Für Snapshots unter /snapshots/home/... ist eine Prüfung nur dann sinnvoll, wenn dort tatsächlich Dateien liegen, die stark verändert wurden. Da Snapshots in der Regel schreibgeschützt sind, ändert sich ihre Fragmentierung nach der Erstellung nicht mehr.

Typische Kandidaten prüfen

Bestimmte Verzeichnisse neigen aufgrund ihres Nutzungsmusters stärker zur Fragmentierung und eventuell mount Option nodatacow in Betracht ziehen

## Log-Verzeichnis prüfen
filefrag /var/log/journal/* | sort -nr -k 2 | head -10

## Temporäres Verzeichnis prüfen
filefrag /tmp/* 2>/dev/null | sort -nr -k 2 | head -10

Performance als eigentlicher Indikator

Die reine Extent-Zahl sagt noch nichts über die tatsächliche Leistung aus. Eine Defragmentierung ist erst dann sinnvoll, wenn eine spürbare Verlangsamung auftritt. Beispiele:

• Eine Datenbank unter /home/hoergen/db/ reagiert merklich langsamer bei Abfragen.
• Eine Logdatei unter /var/log/ verlangsamt den Systemstart.

Ohne solche wahrnehmbaren Effekte überwiegen bei Systemen mit Snapshots die Risiken der Defragmentierung (Verlust der Extent-Freigabe, erhöhter Speicherverbrauch) den Nutzen.

Einschränkung bei Snapshots und Reflinks

Bevor eine Datei defragmentiert wird, sollte geprüft werden, ob sie mit einem Snapshot oder einer Reflink-Kopie verbunden ist. Ist das der Fall, bricht eine Defragmentierung diese Verbindung auf und der Speicherverbrauch steigt. Eine gezielte Prüfung, ob eine Datei mit einem Snapshot geteilt wird, ist mit Bordmitteln nicht direkt möglich. In der Praxis bedeutet das: Dateien, die in den üblichen Snapshot-Pfaden wie /snapshots/home/... oder /.snapshots/NUMBER/snapshot/ enthalten sind, sollten nicht defragmentiert werden.

Möglichkeiten der Defragmentierung

Defragmentierung kann die I/O-Performance verbessern, indem fragmentierte Dateien in zusammenhängende Blöcke umgeschrieben werden. Der Befehl unterstützt verschiedene Optionen:

## Einzelne Datei defragmentieren
sudo btrfs filesystem defragment /pfad/zur/datei

## Verzeichnis rekursiv defragmentieren
sudo btrfs filesystem defragment -r /pfad/zum/verzeichnis

## Mit Kompression (zstd, zlib oder lzo)
sudo btrfs filesystem defragment -r -czstd /pfad

Wichtig: Ohne die Option -r werden nur Metadaten defragmentiert, nicht die Dateiinhalte . Für eine vollständige Dateisystem-Defragmentierung ist -r erforderlich.

Automatische Defragmentierung (autodefrag)

Die Mount-Option autodefrag aktiviert eine Online-Defragmentierung, die bei kleinen, zufälligen Schreibvorgängen automatisch eingreift . Diese Option eignet sich für Desktop-Systeme mit normaler Nutzung, wird aber nicht für große Datenbanken oder VM-Images empfohlen .

Aktivierung in /etc/fstab:

UUID=... / btrfs defaults,autodefrag,compress=zstd 0 0

Das zentrale Problem: Verlust der Extent-Freigabe

Der kritischste Nachteil betrifft Systeme mit Snapshots oder Reflink-Kopien. Die offizielle Btrfs-Dokumentation stellt klar fest:

Defragmentation does not preserve extent sharing, e.g. files created by cp --reflink or existing on multiple snapshots. Due to that the data space consumption may increase.

Was das konkret bedeutet:

Wenn eine Datei defragmentiert wird, die gerade von einem Snapshot oder einem Reflink-Klon mitbenutzt wird, bricht der Befehl diese gemeinsame Nutzung auf. Er erstellt eine neue, private Kopie der Daten für die defragmentierte Datei, während der Snapshot weiterhin auf die alten Datenblöcke verweist. Da beide Kopien nun separat existieren, verdoppelt sich der Speicherplatzbedarf für diese Daten .

Ein Beispiel: Bei einem System mit Snapper, das stündliche Snapshots erstellt, kann eine Defragmentierung von / dazu führen, dass der Speicherverbrauch drastisch ansteigt, weil jede defragmentierte Datei ihre Verbindung zu allen bestehenden Snapshots verliert .

Defrag - Fazit

Für Systeme mit Snapper oder Timeshift gilt: Defragmentierung sollte vermieden werden, es sei denn, sie wird gezielt auf Dateien angewendet, die nachweislich nicht in Snapshots enthalten sind. Der Speicherplatzgewinn durch Snapshots wiegt den Performance-Verlust durch Fragmentierung in den meisten Fällen auf.

Defragmentieren mit Vorteilen & Risiko - Backup

Um dann doch defragmentieren zu können, wenn es wirklich notwendig sein sollte, wäre eine nicht wirklich komplett durchdachte Idee

1. ein Backup zu erstellen
2. danach alle Snapshots zu löschen
3. defragmentieren
4. neue Snapshots zu erstellen
5. nochmal ein Backup erstellen

Fazit & Best Practice

BTRFS mit Snapshots ist eine praktische Möglichkeit, Systemänderungen abzusichern. Die manuellen Befehle sind überschaubar, und mit Snapper lässt sich der Prozess automatisieren. Für Systeme, auf denen häufig Updates oder Experimente durchgeführt werden, ist das eine sinnvolle Einrichtung. Ein Umstieg von ext4 ist nicht trivial, aber bei einer Neuinstallation oder einem Zweitsystem eine Überlegung wert.

Best Practice

1. Standard-Layout mit @ und @home (oder wie vom Installer vorgegeben)
2. Snapper für automatische Snapshots verwenden
3. Vor kritischen Aktionen manuell einen Snapshot anlegen
4. grub-btrfs installieren für snapper rollback, weil es die Snapshots ins GRUB-Menü einbindet.
5. fstab-Optionen sparsam setzen
6. Geschwindigkeit: Aktuelle Performancetests zeigen, dass BTRFS mit XFS, ext4 und anderen noch nicht mithalten kann, aka teilweise extrem langsamer ist. Wer Performance braucht, sollte aktuell auf ein anderes FS setzen.

Vorsicht

1. nodatacow global setzen
2. autodefrag in der fstab
3. Defragmentierung auf Systemen mit Snapshots

Quellen

Offizielle Btrfs-Dokumentation

• btrfs(5) Manpage – Mount-Optionen, Kompression, Swapfile, Einschränkungen - https://manpages.debian.org/unstable/btrfs-progs/btrfs.5.en.html

• btrfs(8) Manpage (Debian) – Werkzeugkasten zur Btrfs-Verwaltung – https://manpages.debian.org/trixie/btrfs-progs/btrfs.8.en.html

• btrfs(8) Manpage (Ubuntu) – Subvolume-, Device- und Filesystem-Befehle – https://manpages.ubuntu.com/manpages/noble/man8/btrfs.8.html

• Btrfs readthedocs – Technische Dokumentation, Zoned Mode, Dateiattribute – https://btrfs.readthedocs.io/

• Filesystem Performance - File System Performance Comparison Statistics 2026 https://commandlinux.com/statistics/file-system-performance-comparison-statistics-ext4-xfs-btrfs-zfs/

Snapper-Dokumentation

• snapper-configs(5) Manpage – Alle Konfigurationsvariablen – https://manpages.opensuse.org/Tumbleweed/snapper/snapper-configs.5.en.html
• snapper(8) Manpage – Befehlsreferenz, Berechtigungen, Dateipfade – https://manpages.opensuse.org/Tumbleweed/snapper/snapper.8.en.html
• openSUSE Snapper Manpages – Übersicht aller Snapper-Manpages – https://en.opensuse.org/SDB:Snapper_Manpages
• SUSE Snapper Basic Concepts (PDF) – Snapshot-Typen, Default-Einstellungen, Speicherplatz – https://documentation.suse.com/smart/systems-management/pdf/snapper-basic-concepts_en.pdf

Distributionen und Praxisanleitungen

• Manjaro Wiki – Btrfs – Subvolume-Konzepte, Snapshots, RAID, Speicherplatz – https://wiki.manjaro.org/index.php/Btrfs
• openSUSE Leap Reference (HTML) – Snapshot-Archivierung, chattr +C, Snapper auf LVM – https://doc.opensuse.org/documentation/leap/reference/html/book-reference/cha-snapper.html
• Oracle Linux Btrfs Docs – Send/Receive-Workflow für Backups – https://docs.oracle.com/en-us/iaas/oracle-linux/btrfs/ol-btrfs-creating-backups-and-using-the-btrfs-send-receive-feature.htm

Am Dienstag wird Mozilla Firefox 157 veröffentlichen und damit hält auch das neue Nova-Design in Firefox Einzug. Dieser Artikel gibt eine Vorschau auf das neue Firefox-Design, neue Funktionen und Nutzer-Optionen, die damit einhergehen, und geht auch auf Unterschiede im Vergleich zu den ersten Mockups ein.

Was ist „Nova”?

Am Dienstag, den 29. September 2026, wird Mozilla Firefox 157 veröffentlichen. Damit wird sich auch das Aussehen von Firefox verändern. Das neue Design hört intern auf den Projektnamen „Nova”. Anfang März hatte ich weltweit als erstes über das neue Design von Firefox berichtet.

Mozilla nimmt Abstand vom geplanten „Insel”-Design

Die ersten Mockups des neuen Nova-Designs konnte man durchaus als mutig bezeichnen. Denn die Abgrenzung einzelner Bereiche als eine Art von „Inseln” war eine drastische Abkehr vom gewohnten Erscheinungsbild, was einerseits modern und frisch wirkte, aber natürlich auch nicht jedem gefiel. Mozilla hatte dieses Konzept in Vorab-Versionen von Firefox auch schon implementiert. Aber insbesondere die Anforderungen an „Fitts’ Gesetz” stellten eine Herausforderung dar, weil es dadurch Lücken gab, in denen der Nutzer nicht „blind” mit der Oberfläche interagieren konnte. Während dies zwar ein technisch grundsätzlich lösbares Problem gewesen wäre, hat sich Mozilla dazu entschieden, von dieser Idee Abstand zu nehmen und es doch bei einer traditionelleren Darstellung zu belassen.

„Nova” bringt mehr Farbe und Rundungen in Firefox

Charakteristisch für das Nova-Design von Firefox sind vor allem die starken Rundungen: Tabs, Adressleiste und Schaltflächen sind sehr viel runder als bisher. Auch zahlreiche Icons wurden erneuert. Wo bislang Grau oder Blau als Akzentfarbe eingesetzt worden ist, setzt Mozilla nun auf Violett-Töne. Und während Flächen bislang einfarbig und graue Farben dominant waren, setzt Mozilla mit „Nova” auf mehr Farbe und teilweise auch auf dezente Verläufe.

Ein solcher Verlauf zeigt sich vor allem in der Tab-Leiste, welche von links nach rechts in einer subtilen Weise den Farbton verändert. Anders als in den ersten Mockups, in denen die Navigations- und Lesezeichenleiste eine weiße Fläche und damit einen starken Kontrast zur Tableiste gehabt hätten, ähnlich zum Grau im aktuellen Firefox-Design, zieht sich der Verlauf der Tab-Leiste auch über die Navigations- und Lesezeichen-Leiste, allerdings mit einer reduzierten Deckkraft im Vergleich zur Tab-Leiste. Dies sorgt weiterhin für eine Abgrenzung, aber ergibt ein stimmigeres und vor allem farbenfroheres Gesamtbild.

Einen Verlauf hat auch die Kontur um den aktiven Tab erhalten, welcher sich damit besser sichtbar von der Tab-Leiste abgrenzt, als es bisher der Fall war.

Verschiedene Themes für unterschiedliche Farbstimmungen

Mit „Nova” setzt Mozilla nicht auf ein einziges Farbschema, sondern gibt dem Anwender gleich zwölf verschiedene Themes, zwischen denen jederzeit gewechselt werden kann. Diese sind nicht nur im Themes-Bildschirm von about:addons auswählbar, sondern auch direkt über die Startseite. Neue Nutzer können den Farbton auch schon bei der Ersteinrichtung auswählen.

Die Auswahl eines Farbschemas beeinflusst auch die Hintergrundfarbe der Firefox-Startseite.

Der Nutzer entscheidet, ob ein helles oder dunkles Theme genutzt wird

Ebenfalls neu und in den vorherigen Screenshots zu sehen: Überall, wo die Themes zur Auswahl stehen, kann der Nutzer jetzt auch direkt auswählen, ob er ein helles oder dunkles Theme nutzen möchte, was Auswirkungen auf Teile der Oberfläche wie Menü, Panels und die Startseite hat. Effektiv werden aus den zwölf standardmäßig inkludierten „Nova”-Themes damit 24 Farb-Optionen für den Nutzer, die Mozilla von Haus aus mitliefert. Aber auch mit anderen Themes funktioniert diese Option.

Spezielle Farb-Option für Linux-Nutzer

Linux-Nutzer haben bei Verwendung des Standard-Themes von Firefox eine neue Option erhalten, um das Linux-Theme anstelle des Firefox-Themes zu verwenden. Dies wirkt sich auf die Farbgebung aus, insbesondere auf die Verwendung der violetten Akzent-Farbe an manchen Stellen der Oberfläche.

Neue Einstellung für Dichte der Oberfläche

Mit „Nova” bekommt auch ein früheres Feature sein Comeback: Eine Einstellung zur Dichte erlaubt es, den Abstand rund um Fensterelemente wie Symbolleiste, Tabs und Seitenleiste anzupassen. Während dies in den letzten Jahren nur über eine versteckte Option möglich war und nicht mehr offiziell unterstützt wurde, handelt es sich jetzt wieder um eine offiziell unterstützte Konfiguration, die sich in den Einstellungen unter „Erscheinungsbild” vornehmen lässt.

Neben dem automatischen Modus, der eine entsprechende Systemeinstellung berücksichtigt, stehen die Optionen Standard, Kompakt sowie Touch zur Verfügung. Bei kompakter Darstellung werden Elemente platzsparender angeordnet, während die Touch-Option für größere Flächen sorgt.

Icons für Vorschläge in Adressleiste

Bei Vorschlägen aus der Adressleiste überlagerte für Lesezeichen bereits ein Stern-Symbol das sogenannte Favicon der jeweiligen Website. Mit „Nova” zeigt Firefox auch für Vorschläge aus der Chronik ein Uhr-Symbol und für Seiten, die bereits als Tab geöffnet sind, ein Tab-Icon an.

Bessere Darstellung von Tab-Umgebungen in „Alle Tabs auflisten”-Menü

Das Menü „Alle Tabs auflisten” stellt Tab-Umgebungen mit „Nova” klarer dar, weil diese nicht länger nur durch einen Strich in Farbe der jeweiligen Tab-Umgebung dargestellt werden, sondern mit dem dazugehörigen Symbol.

Info-Schaltfläche für private Fenster

Überarbeitet wurde auch die Optik privater Fenster. Neben Farben und überarbeiteten Texten auf der Startseite wurde der Schriftzug „Privater Modus” am rechten Rand der Tab-Leiste durch ein Symbol ersetzt, auf dessen Klick eine Erklärung erscheint, was der Anwendungsfall für private Fenster ist.

Der Beitrag Große Vorschau auf das neue Nova-Design von Firefox 157 erschien zuerst auf soeren-hentzschel.at.

Von Thundermail, dem E-Mail-Dienst der Thunderbird-Macher, gibt es auch eine Weboberfläche. Diese hat zahlreiche Neuerungen erhalten.

Das ist Thundermail

Thunderbird ist vor allem für seinen kostenlosen E-Mail-Client für Windows, macOS und Linux bekannt. Seit November 2024 gibt es Thunderbird auch für Android, Thunderbird für iOS ist in Entwicklung. Doch dabei soll es nicht bleiben: Die MZLA Technologies Corporation möchte ein Ökosystem aus Clients und Diensten als Alternative zu denen der Tech-Giganten wie Google Mail und Microsoft Office 365 etablieren, welches Open Source ist.

Unter dem Namen Thundermail bündelt MZLA ein neues Angebot, bestehend aus Postfach, Dienst zum Versand von Dateien sowie Tool zur Termin-Vereinbarung. Aktuell befindet sich Thundermail noch in einer Testphase, für welche man sich auf eine Warteliste setzen kann.

Vor etwas mehr als zwei Monaten wurde die erste Alpha-Version einer Weboberfläche für den E-Mail-Dienst gestartet.

Neuerungen für den Webmailer

Eben jene Weboberfläche hat zahlreiche Neuerungen erhalten, die sich in drei Kategorien aufteilen lassen: Postfach, Verfassen von E-Mails, Adressbuch.

Neuerungen im Postfach

Nachrichten können jetzt mit einem Stern markiert werden. In einem anderen Programm markierte Nachrichten wurden bereits entsprechend gekennzeichnet, jetzt funktioniert das Setzen und Entfernen der Markierung auch aus dem Webmailer heraus.

Über eine eigene Schaltfläche lassen sich Entwürfe jetzt als Tab minimieren.

Außerdem wurden die Tastatur-Kommandos überarbeitet. Dafür kann der Anwender aus zwei Voreinstellungen wählen: Kommandos, die konsistent mit den entsprechenden Befehlen in Thunderbird sind, oder Kommandos, die webkompatibler sind und nicht in Konflikt mit gängigen Browser-Kommandos stehen.

Neuerungen für das Schreiben von E-Mails

Das Fenster zum Schreiben von E-Mails hat eine Autovervollständigung für E-Mail-Adressen erhalten.

Außerdem lassen sich jetzt auch CC sowie BCC setzen.

Eine neue Schaltfläche zum Hochladen von Dateianhängen wurde hinzugefügt.

Darüber hinaus gibt es jetzt die Möglichkeit, eine E-Mail für den späteren Versand einzuplanen.

Neuerungen für das Adressbuch

Es können jetzt mehrere Adressbücher erstellt werden.

Für gelöschte Kontakte gibt es ab sofort einen eigenen Papierkorb.

Der Beitrag Webmail-Version von Thundermail erhält zahlreiche Neuerungen erschien zuerst auf soeren-hentzschel.at.

Die MZLA Technologies Corporation hat mit Thunderbird 156.0.1 eine neue Version seines Open Source E-Mail-Clients für Windows, Apple macOS und Linux veröffentlicht.

Neuerungen von Thunderbird 156.0.1

Mit Thunderbird 156.0.1 hat die MZLA Technologies Corporation ein Update für seinen Open Source E-Mail-Client veröffentlicht. Die neue Version behebt eine potenzielle Absturzursache beim Speichern von Nachrichten.

Der Beitrag Thunderbird 156.0.1 veröffentlicht erschien zuerst auf soeren-hentzschel.at.

Die MZLA Technologies Corporation hat mit Thunderbird 23.1 ein Update für die Android-Version seines E-Mail-Clients veröffentlicht.

Download Thunderbird für Android

Die MZLA Technologies Corporation hat Thunderbird 23.1 für Android veröffentlicht. Das Update behebt das Problem, dass Dateinamen von Anhängen mit Nicht-ASCII-Zeichen falsch dekodiert und gespeichert worden sind.

Der Beitrag Thunderbird 23.1 für Android veröffentlicht erschien zuerst auf soeren-hentzschel.at.

Mozilla hat mit Firefox 156.0.1 ein Korrektur-Update veröffentlicht. Dieser Artikel beschreibt die Änderungen des neuesten Updates.

Download Mozilla Firefox 156.0.1

Unter macOS 27 wurden Fenster umgehend wieder maximiert, nachdem diese durch Doppelklick auf die Titelleiste auf ihre vorherige Größe gebracht werden sollten.

Elemente zeigten innerhalb eines Links beim Anklicken nicht ihre CSS-Stile für den :active-Zustand an.

Auf Websites, die eine CSS Anker-Positionierung verwenden, konnte es dazu kommen, dass Firefox nicht mehr reagierte.

Aufrufe von confirm(), alert() und prompt() funktionierten nicht mehr im Kontext von WebExtension-Pop-ups.

Die Screenreader-Software NVDA sagte die Schaltflächen in der Adressleiste nicht an, wenn der Mauszeiger darüber bewegt wurde.

Ein Freigabe-Problem von System-Handles beim Starten und Beenden von Inhaltsprozessen unter Windows wurde behoben.

Außerdem wurden zwei potenzielle Absturzursachen aus der Welt geschafft.

Der Beitrag Mozilla veröffentlicht Firefox 156.0.1 erschien zuerst auf soeren-hentzschel.at.

Installation NeoVim in Manjaro

Hinweis: Wenn du es wesentlich einfacher haben willst, aber dennoch das Vim oder Neovim Feeling nicht missen willst, dann kannst du auch diesen Rust Editor benutzen: Zed - Your last next editor - https://zed.dev/

Manjaros offizielle Repositories bieten in der Regel eine aktuelle Version von Neovim.

Mit pacman

sudo pacman -Syu
sudo pacman -S neovim lua51

Nach der Installation kannst du die Version mit folgendem Befehl prüfen:

nvim --version

Installation Rust

Was ist Rustup - Toolchain

Vorteil von Rustup

Rustup ist der offizielle Toolchain-Manager für Rust. Ohne Rustup installierst du Rust einmalig über die Paketverwaltung deiner Distribution und bist an diese eine Version gebunden. Rustup bietet darüber hinaus folgende Vorteile:

Mehrere Toolchains parallel

Du kannst gleichzeitig die stable, beta und nightly Version von Rust installieren und zwischen ihnen wechseln:

rustup install nightly
rustup install beta
rustup default stable
rustup override set nightly   # nur für aktuelles Projekt

Das ist besonders nützlich, da einige Crates (Programme oder Bibliotheken) z. B. für experimentelle Features nur auf nightly laufen.

Projektbezogene Versionen

Mit einer rust-toolchain.toml Datei im Projektordner legst du fest, welche Rust-Version das Projekt verwendet:

[toolchain]
channel = "1.75.0"
components = ["rustfmt", "clippy"]

Sobald du in den Ordner wechselst, aktiviert Rustup automatisch die passende Version. Das stellt sicher, dass alle Teammitglieder und CI-Systeme dieselbe Version verwenden.

Pinning auf exakte Versionen

Du kannst gezielt eine bestimmte Rust-Version installieren, um reproduzierbare Builds zu gewährleisten:

rustup install 1.75.0
rustup default 1.75.0

Komponenten nachinstallieren

Zusätzliche Werkzeuge wie rustfmt, clippy, rust-analyzer oder rust-src lassen sich jederzeit ergänzen oder entfernen:

rustup component add clippy
rustup component remove rust-docs

Target-Unterstützung

Für Cross-Compilation kannst du Ziele für andere Plattformen hinzufügen:

rustup target add aarch64-unknown-linux-gnu
rustup target add x86_64-pc-windows-gnu

Updates

Rustup aktualisiert die Toolchains mit einem Befehl:

rustup update

Im Gegensatz dazu hängst du bei der Installation über pacman von den Update-Zyklen der Distribution ab, die oft Monate hinterherhinken.

Vorteil einer Toolchain

Eine Toolchain ist das eigentliche Rust-Komplettpaket und besteht aus mehreren Komponenten:

• rustc: der Compiler
• cargo: der Build-Manager und Package-Manager
• rust-std: die Standardbibliothek
• rust-docs: die lokale Dokumentation
• optionale Komponenten wie rustfmt und clippy

Warum das wichtig ist

Der Vorteil liegt darin, dass alle Komponenten einer Toolchain aufeinander abgestimmt sind. Der Compiler, die Standardbibliothek und die Werkzeuge stammen aus derselben Version. Das vermeidet Versionskonflikte, wie sie bei manuell zusammengestellten Installationen auftreten können.

Kanal statt Version

Eine Toolchain wird über einen Kanal referenziert (stable, beta, nightly) oder über eine exakte Version (1.75.0). Dadurch kannst du entweder immer die neuesten stabilen Features nutzen oder auf eine feste Version setzen, wenn dein Projekt das erfordert.

Vergleich: Rustup vs. Paketmanager

Wann reicht der Paketmanager?

Wenn du Rust nur gelegentlich nutzt, keine projektbezogenen Versionen brauchst und mit der Version deiner Distribution zufrieden bist, ist die Installation über pacman ausreichend. Für die professionelle Entwicklung ist Rustup jedoch die klar bessere Wahl.

Rustup installieren

Schritt 1: base-devel & Rustup aus dem Repository installieren

sudo pacman -S base-devel rustup

Schritt 2: Toolchain aktivieren

rustup default stable

Wichtig: Das rustup-Paket aus den Arch-Repositories installiert standardmäßig keine Toolchain. Die Binaries (rustc, cargo) sind symbolische Links auf rustup, daher muss die Toolchain manuell aktiviert werden.

Schritt 3: Installation überprüfen

rustc --version

cargo --version

Entwicklungswerkzeuge

Nach der Installation von Rustup kannst du zusätzliche Komponenten hinzufügen:

rustup component add rustfmt         # Code-Formatierung
rustup component add clippy          # Statische Analyse
rustup component add rust-analyzer   # Language Server für IDEs

Rust Installation testen

cargo new hello_world
cd hello_world
cargo run

NeoVim 4 Rust

Um Rust in Neovim zu programmieren, brauchst du im Wesentlichen Rust selbst (erledigt) , den Language Server rust-analyzer und eine Neovim-LSP-Konfiguration.

LSP - Language Server rust-analyzer

1. rust-analyzer (der LSP-Server): Das ist das Herzstück für Code-Vervollständigung, Fehlerprüfung und Navigation. Der beste Weg ist, ihn über rustup als Komponente hinzuzufügen .

2. rustup component add rust-analyzer
   

Weil es hier und da Probleme mit dem Aufruf von rust-analyzer gibt, sollte noch folgende Anpassung gemacht werden.

Sollte der Aufruf nicht funktionieren

rust-analyzer --version

installiere explizit und danach rufe den oberen Befehle nochmal auf

sudo pacman -S rust-analyzer

Das Ganze hat mit einem kaputten Symlink/Proxy zu tun. Eventuell später mehr dazu. Es soll jetzt erstmal funktionieren!

Neovim Konfiguration

# Übersicht der Verzeichnisse

~/.config/nvim/
├── init.lua                          # Einstiegspunkt, lädt config.lazy
└── lua/
    ├── config/
    │   └── lazy.lua                  # Bootstrap & Setup für lazy.nvim
    └── plugins/
        ├── init.lua                  # Platzhalter, verhindert Fehler
        ├── rust.lua                  # rustaceanvim
        └── completion.lua            # blink.cmp

1. Lege das Konfigurationsverzeichnis an

mkdir -p ~/.config/nvim

2. Installiere Plugin Manager lazy.vim

Bevor du beginnst, stelle sicher, dass auf deinem System Neovim (>= 0.8.0) und Git (>= 2.19.0) installiert sind.

nvim --version | head -n 1 && git --version

Falls Git noch nicht installiert ist:

sudo pacman -S git

3. Konfigurationsdateien anlegen

Erstelle zuerst die benötigten Ordner und Dateien in deinem Neovim-Konfigurationsverzeichnis.

mkdir -p ~/.config/nvim/lua/config && mkdir -p ~/.config/nvim/lua/plugins

4. init.lua erstellen oder anpassen

Erstelle die Datei ~/.config/nvim/init.lua (falls sie noch nicht existiert) und füge diese Zeile ein:

nvim ~/.config/nvim/init.lua

require("config.lazy")

5. Bootstrap-Datei für lazy.nvim erstellen

Damit lazy.nvim keine Fehlermeldung zurück gibt, muss in ~/.config/nvim/lua/plugins/ eine leere init.lua angelegt werden.

echo "return {}" > ~/.config/nvim/lua/plugins/init.lua

6. Erstelle die Datei ~/.config/nvim/lua/config/lazy.lua

nvim ~/.config/nvim/lua/config/lazy.lua

mit folgendem Inhalt. Dieser Code in lazy.lua lädt das Plugin lazy.nvim automatisch herunter, falls es noch nicht vorhanden ist:

-- ~/.config/nvim/lua/config/lazy.lua

-- Bootstrap lazy.nvim
local lazypath = vim.fn.stdpath("data") .. "/lazy/lazy.nvim"
if not (vim.uv or vim.loop).fs_stat(lazypath) then
  local lazyrepo = "https://github.com/folke/lazy.nvim.git"
  local out = vim.fn.system({ "git", "clone", "--filter=blob:none", "--branch=stable", lazyrepo, lazypath })
  if vim.v.shell_error ~= 0 then
    vim.api.nvim_echo({
      { "Failed to clone lazy.nvim:\n", "ErrorMsg" },
      { out, "WarningMsg" },
      { "\nPress any key to exit..." },
    }, true, {})
    vim.fn.getchar()
    os.exit(1)
  end
end
vim.opt.rtp:prepend(lazypath)

-- Leader-Tasten müssen vor lazy.nvim gesetzt werden
vim.g.mapleader = " "
vim.g.maplocalleader = "\\"

-- lazy.nvim Setup
require("lazy").setup({
  spec = {
    { import = "plugins" },
  },

  -- LuaRocks-Unterstützung mit hererocks
  rocks = {
    enabled = true,
    hererocks = true,
  },

  -- Farbschema beim Installieren
  install = { colorscheme = { "habamax" } },

  -- Automatische Update-Prüfung
  checker = { enabled = true },

  -- Performance
  performance = {
    rtp = {
      disabled_plugins = {
        "gzip",
        "matchit",
        "matchparen",
        "netrwPlugin",
        "tarPlugin",
        "tohtml",
        "tutor",
        "zipPlugin",
      },
    },
  },
})

7. Installation prüfen

Nachdem du die Konfiguration gespeichert hast, starte Neovim neu. Das Plugin lazy.nvim sollte sich nun automatisch installieren.

lazy.nvim öffnen: Gib den Befehl :Lazy ein, um die grafische Oberfläche zu öffnen.

Sobald lazy.nvim läuft, kannst du mit dem nächsten Schritt fortfahren: der Einrichtung von rustaceanvim in deiner Plugin-Konfiguration.

9. Plugin rustaceanvim installieren

Für die Konfiguration gibt es zwei gängige Wege. Der einfachste und modernste Weg ist ein spezielles Plugin für Rust.

Dieses Plugin ist eine Art “Rundum-sorglos-Paket” für Rust in Neovim. Es verbindet sich automatisch mit rust-analyzer und bringt viele nützliche Funktionen mit, ohne dass du den LSP-Server manuell konfigurieren musst .

Der rustaceanvim-Eintrag kommt nicht in die lazy.lua, sondern in eine separate Datei im plugins-Ordner. Die lazy.lua ist nur für den Bootstrap und die globale Konfiguration von lazy.nvim zuständig. Deine eigentlichen Plugins gehören in ~/.config/nvim/lua/plugins/.

Erstelle eine neue Datei:

nvim ~/.config/nvim/lua/plugins/rust.lua

Die Datei muss eine Tabelle zurückgeben. Der rustaceanvim-Eintrag steht in dieser Tabelle:

-- ~/.config/nvim/lua/plugins/rust.lua
return {
  {
    "mrcjkb/rustaceanvim",
    version = "^9", -- Version 9 für aktuelle Neovim-Versionen
    lazy = false,   -- Wichtig: Lädt das Plugin sofort
  },
}

1. Speichere die Datei.
2. Starte Neovim neu.
3. gib :Lazy ein und eventuell U zum Updaten
4. lazy.nvim erkennt die neue Datei und installiert rustaceanvim automatisch.
5. Öffne eine .rs-Datei. rustaceanvim startet dann rust-analyzer.

Plugin blink.cmp - autocompletion

Installation

Erstelle folgende Datei :

nvim ~/.config/nvim/lua/plugins/completion.lua

Mit folgendem Inhalt

return {
  {
    'saghen/blink.cmp',
    -- Optional: Stellt Snippets für die Snippet-Vervollständigung bereit
    dependencies = { 'rafamadriz/friendly-snippets' },

    -- Nutzt einen Release-Tag, um vorgebaute Binärdateien herunterzuladen.
    -- Das ist der empfohlene Weg für die beste Performance.
    version = '1.*',

    ---@module 'blink.cmp'
    ---@type blink.cmp.Config
    opts = {
      -- 'default' verwendet Tastenkürzel, die denen der eingebauten
      -- Vervollständigung ähneln (z.B.  zum Akzeptieren)
      keymap = { preset = 'default' },

      appearance = {
        -- 'mono' für 'Nerd Font Mono', um Icons korrekt auszurichten
        nerd_font_variant = 'mono'
      },

      -- Standardmäßig werden Vorschläge von LSP, Dateipfaden,
      -- Snippets und dem aktuellen Buffer verwendet.
      sources = {
        default = { 'lsp', 'path', 'snippets', 'buffer' },
      },

      -- Nutzt die Rust-Implementierung für den Fuzzy-Matcher (schneller),
      -- fällt aber automatisch auf die Lua-Implementierung zurück.
      fuzzy = { implementation = "prefer_rust_with_warning" }
    },
    opts_extend = { "sources.default" }
  }
}

Shortcuts

blink.cmp verwendet standardmäßig das default-Preset, das sich an der eingebauten Neovim-Vervollständigung orientiert . Die wichtigsten Tastenkürzel im Insert-Modus sind:

• : Menü öffnen oder Dokumentation umschalten .
• : Ausgewählten Vorschlag akzeptieren .
• : Menü schließen (und Vorschau rückgängig machen) .
• / (oder Pfeil runter/hoch): Nächsten oder vorherigen Eintrag auswählen .
• : Signatur-Hilfe umschalten (sofern aktiviert) .
• / : In der Dokumentationsvorschau scrollen .
• / : Zwischen Snippet-Platzhaltern springen .

Möchtest du ein anderes Verhalten, kannst du in deiner blink.cmp-Konfiguration einfach ein anderes Preset wählen, z. B. keymap = { preset = 'super-tab' } für Tab-zum-Akzeptieren .

Neben den von mir genannten Shortcuts gibt es bei blink.cmp noch einige weitere, die je nach Konfiguration und Kontext (z.B. in der Kommandozeile) verfügbar sind.

Presets

Presets sind bei blink.cmp vorgefertigte Tastaturbelegungen, die festlegen, wie du das Vervollständigungsmenü bedienst. Sie sind sozusagen „Pakete“ von Tastenkürzeln für bestimmte Arbeitsweisen.

Die wichtigsten Presets im Überblick

Du wählst ein Preset über keymap = { preset = 'name' } in deiner Konfiguration .

• default: Orientiert sich an der eingebauten Neovim-Vervollständigung. Du bestätigst einen Vorschlag mit (wie „Yes“) .
• super-tab: Orientiert sich an VS Code. Die Tab-Taste akzeptiert den ausgewählten Vorschlag .
• enter: Verwendet die Enter-Taste () zum Akzeptieren. Die Tab-Taste bleibt für die Navigation zwischen Snippet-Platzhaltern reserviert .
• cmdline: Ist speziell für die Kommandozeile (:) optimiert. Die Tab-Taste zeigt das Menü, fügt den ersten Eintrag ein oder wählt den nächsten aus .

Gemeinsame Tasten in allen Presets

Unabhängig vom gewählten Preset sind einige Tasten immer gleich belegt, zum Beispiel :

• : Menü öffnen oder Dokumentation umschalten.
• / (oder Pfeiltasten): Nächsten oder vorherigen Eintrag auswählen.
• : Menü schließen.

Die wichtigsten Presets im Vergleich

blink.cmp bringt verschiedene vordefinierte Tastaturbelegungen mit, die sogenannten Presets. Deine aktuell genutzten Shortcuts (, , etc.) gehören zum default-Preset. Andere Presets ändern die Belegung grundlegend:

Wenn du also z.B. möchtest, dass Tab den Vorschlag akzeptiert (wie in VS Code), änderst du keymap = { preset = 'super-tab' } in deiner Konfiguration .

Weitere nützliche Standard-Shortcuts

Unabhängig vom Preset gibt es einige Befehle, die in den meisten Konfigurationen zu finden sind:

• : Schaltet die Signatur-Hilfe um (sofern aktiviert) .
• / : Scrollt in der Dokumentationsvorschau nach oben/unten .
• : Zeigt das Vervollständigungsmenü oder die Dokumentation an .
• : Schließt das Menü (und macht eine automatische Vorschau rückgängig) .

Shortcuts in der Kommandozeile (cmdline)

Wenn du in der Neovim-Kommandozeile (:) tippst, gelten oft andere Regeln. Das cmdline-Preset ist speziell dafür optimiert :

• : Zeigt das Menü, fügt das erste Element ein oder wählt das nächste aus.
• : Wählt das vorherige Element aus.
• / : Navigiert wie in der normalen Vervollständigung durch die Vorschläge.

Eigene Shortcuts definieren

Du kannst die Belegung jederzeit anpassen. Wenn du zum Beispiel (Enter) zum Akzeptieren nutzen möchtest, änderst du in deiner blink.cmp-Konfiguration den Eintrag keymap:

keymap = { preset = 'enter' },

Oder du definierst komplett eigene Kombinationen, indem du ein preset = 'none' setzt und die Tasten selbst belegst .

Beispiel:

-- ~/.config/nvim/lua/plugins/completion.lua
return {
  {
    'saghen/blink.cmp',
    dependencies = { 'rafamadriz/friendly-snippets' },
    version = '1.*',
    opts = {
      keymap = { preset = 'enter' }, -- Hier wird das Preset gewählt
      -- ... restliche Optionen wie appearance, sources, fuzzy
    },
  },
}

Installation Script für Neovim, Rust und Plugins unter Manjaro

Für Ungeduldige mit Risikobereitschaft: Hier ist ein vollständiges Bash-Skript, das alle Schritte aus deinem Leitfaden automatisiert. Es installiert Neovim, Rust (via Rustup), die Rust-Komponenten und richtet die komplette Neovim-Konfiguration mit lazy.nvim, rustaceanvim und blink.cmp ein.

#!/usr/bin/env bash
### ### install_neovim_rust.sh
### Installiert Neovim, Rust (Rustup) und richtet die Neovim-Konfiguration
### mit lazy.nvim, rustaceanvim und blink.cmp unter Manjaro ein.
### ### Autor: hoergen (Vorlage), automatisiert
### Datum: 2026-09-22
### 
set -euo pipefail

### ------------------------------------------------------------------
### Farben für Ausgaben
### ------------------------------------------------------------------
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
RED='\033[0;31m'
NC='\033[0m' # No Color

info()  { echo -e "${GREEN}[INFO]${NC}  $*"; }
warn()  { echo -e "${YELLOW}[WARN]${NC}  $*"; }
error() { echo -e "${RED}[ERROR]${NC} $*" >&2; }

### ------------------------------------------------------------------
### 0. Voraussetzungen prüfen
### ------------------------------------------------------------------
if [[ $EUID -eq 0 ]]; then
  error "Bitte NICHT als root ausführen. Das Skript nutzt sudo wo nötig."
  exit 1
fi

if ! command -v pacman &>/dev/null; then
  error "pacman nicht gefunden. Dieses Skript ist für Manjaro/Arch gedacht."
  exit 1
fi

### ------------------------------------------------------------------
### 1. System aktualisieren und Neovim + Lua installieren
### ------------------------------------------------------------------
info "Aktualisiere Paketdatenbank und System ..."
sudo pacman -Syu --noconfirm

info "Installiere Neovim, Lua 5.1, git, base-devel und rustup ..."
sudo pacman -S --noconfirm --needed \
  neovim \
  lua51 \
  git \
  base-devel \
  rustup

### ------------------------------------------------------------------
### 2. Rust-Toolchain aktivieren
### ------------------------------------------------------------------
info "Aktiviere Rust stable Toolchain ..."
if ! rustup toolchain list | grep -q '^stable'; then
  rustup default stable
else
  info "stable Toolchain ist bereits aktiv."
fi

### ------------------------------------------------------------------
### 3. Rust-Komponenten installieren
### ------------------------------------------------------------------
info "Installiere Rust-Komponenten: rustfmt, clippy, rust-analyzer ..."
rustup component add rustfmt   || warn "rustfmt konnte nicht installiert werden."
rustup component add clippy    || warn "clippy konnte nicht installiert werden."
rustup component add rust-analyzer || warn "rust-analyzer (rustup) konnte nicht installiert werden."

### Fallback: rust-analyzer aus den Repos, falls der rustup-Aufruf nicht klappt.
if ! command -v rust-analyzer &>/dev/null; then
  warn "rust-analyzer nicht im PATH gefunden. Installiere aus den Repos ..."
  sudo pacman -S --noconfirm --needed rust-analyzer
fi

### ------------------------------------------------------------------
### 4. Versionen prüfen
### ------------------------------------------------------------------
info "Überprüfe Installationen ..."
nvim --version | head -n 1
rustc --version
cargo --version
rust-analyzer --version 2>/dev/null || warn "rust-analyzer --version nicht verfügbar."

### ------------------------------------------------------------------
### 5. Neovim-Konfigurationsverzeichnis anlegen
### ------------------------------------------------------------------
NVIM_CONFIG="$HOME/.config/nvim"
NVIM_LUA="$NVIM_CONFIG/lua"
NVIM_PLUGINS="$NVIM_LUA/plugins"

info "Lege Neovim-Konfigurationsverzeichnisse an ..."
mkdir -p "$NVIM_CONFIG"
mkdir -p "$NVIM_LUA/config"
mkdir -p "$NVIM_PLUGINS"

### ------------------------------------------------------------------
### 6. init.lua erstellen
### ------------------------------------------------------------------
info "Erstelle $NVIM_CONFIG/init.lua ..."
cat > "$NVIM_CONFIG/init.lua" <<'EOF'
require("config.lazy")
EOF

### ------------------------------------------------------------------
### 7. Plugin-Init (leer, damit lazy.nvim keine Fehler wirft)
### ------------------------------------------------------------------
info "Erstelle $NVIM_PLUGINS/init.lua ..."
cat > "$NVIM_PLUGINS/init.lua" <<'EOF'
return {}
EOF

### ------------------------------------------------------------------
### 8. lazy.lua Bootstrap-Datei erstellen
### ------------------------------------------------------------------
info "Erstelle $NVIM_LUA/config/lazy.lua ..."
cat > "$NVIM_LUA/config/lazy.lua" <<'EOF'
-- ~/.config/nvim/lua/config/lazy.lua

-- Bootstrap lazy.nvim
local lazypath = vim.fn.stdpath("data") .. "/lazy/lazy.nvim"
if not (vim.uv or vim.loop).fs_stat(lazypath) then
  local lazyrepo = "https://github.com/folke/lazy.nvim.git"
  local out = vim.fn.system({ "git", "clone", "--filter=blob:none", "--branch=stable", lazyrepo, lazypath })
  if vim.v.shell_error ~= 0 then
    vim.api.nvim_echo({
      { "Failed to clone lazy.nvim:\n", "ErrorMsg" },
      { out, "WarningMsg" },
      { "\nPress any key to exit..." },
    }, true, {})
    vim.fn.getchar()
    os.exit(1)
  end
end
vim.opt.rtp:prepend(lazypath)

-- Leader-Tasten müssen vor lazy.nvim gesetzt werden
vim.g.mapleader = " "
vim.g.maplocalleader = "\\"

-- lazy.nvim Setup
require("lazy").setup({
  spec = {
    { import = "plugins" },
  },

  -- LuaRocks-Unterstützung mit hererocks
  rocks = {
    enabled = true,
    hererocks = true,
  },

  -- Farbschema beim Installieren
  install = { colorscheme = { "habamax" } },

  -- Automatische Update-Prüfung
  checker = { enabled = true },

  -- Performance
  performance = {
    rtp = {
      disabled_plugins = {
        "gzip",
        "matchit",
        "matchparen",
        "netrwPlugin",
        "tarPlugin",
        "tohtml",
        "tutor",
        "zipPlugin",
      },
    },
  },
})
EOF

### ------------------------------------------------------------------
### 9. rustaceanvim Plugin-Konfiguration
### ------------------------------------------------------------------
info "Erstelle $NVIM_PLUGINS/rust.lua ..."
cat > "$NVIM_PLUGINS/rust.lua" <<'EOF'
-- ~/.config/nvim/lua/plugins/rust.lua
return {
  {
    "mrcjkb/rustaceanvim",
    version = "^9", -- Version 9 für aktuelle Neovim-Versionen
    lazy = false,   -- Wichtig: Lädt das Plugin sofort
  },
}
EOF

### ------------------------------------------------------------------
### 10. blink.cmp Plugin-Konfiguration
### ------------------------------------------------------------------
info "Erstelle $NVIM_PLUGINS/completion.lua ..."
cat > "$NVIM_PLUGINS/completion.lua" <<'EOF'
-- ~/.config/nvim/lua/plugins/completion.lua
return {
  {
    'saghen/blink.cmp',
    -- Optional: Stellt Snippets für die Snippet-Vervollständigung bereit
    dependencies = { 'rafamadriz/friendly-snippets' },

    -- Nutzt einen Release-Tag, um vorgebaute Binärdateien herunterzuladen.
    -- Das ist der empfohlene Weg für die beste Performance.
    version = '1.*',

    ---@module 'blink.cmp'
    ---@type blink.cmp.Config
    opts = {
      -- 'default' verwendet Tastenkürzel, die denen der eingebauten
      -- Vervollständigung ähneln (z.B.  zum Akzeptieren)
      keymap = { preset = 'default' },

      appearance = {
        -- 'mono' für 'Nerd Font Mono', um Icons korrekt auszurichten
        nerd_font_variant = 'mono'
      },

      -- Standardmäßig werden Vorschläge von LSP, Dateipfaden,
      -- Snippets und dem aktuellen Buffer verwendet.
      sources = {
        default = { 'lsp', 'path', 'snippets', 'buffer' },
      },

      -- Nutzt die Rust-Implementierung für den Fuzzy-Matcher (schneller),
      -- fällt aber automatisch auf die Lua-Implementierung zurück.
      fuzzy = { implementation = "prefer_rust_with_warning" }
    },
    opts_extend = { "sources.default" }
  }
}
EOF

### ------------------------------------------------------------------
### 11. Plugins headless installieren (lazy.nvim sync)
### ------------------------------------------------------------------
info "Installiere Plugins über lazy.nvim (headless) ..."
if nvim --headless "+Lazy! sync" +qa 2>/dev/null; then
  info "Plugins erfolgreich synchronisiert."
else
  warn "Headless-Sync fehlgeschlagen. Bitte Neovim manuell starten und ':Lazy sync' ausführen."
fi

### ------------------------------------------------------------------
### 12. Fertig
### ------------------------------------------------------------------
info "Fertig! Zusammenfassung:"
echo "  - Neovim-Version:       $(nvim --version | head -n 1)"
echo "  - Rust-Version:         $(rustc --version)"
echo "  - Cargo-Version:        $(cargo --version)"
echo "  - rust-analyzer:        $(rust-analyzer --version 2>/dev/null || echo 'nicht verfügbar')"
echo "  - Neovim-Konfig:        $NVIM_CONFIG"
echo
info "Starte Neovim mit 'nvim' und prüfe mit ':Lazy', ob alle Plugins installiert sind."
info "Öffne eine .rs-Datei, um rustaceanvim und rust-analyzer zu testen."

Verwendung

1. Datei speichern als z. B. install_neovim_rust.sh.

2. Ausführbar machen:

   chmod +x install_neovim_rust.sh
   

3. Starten (nicht als root):

   ./install_neovim_rust.sh
   

Was das Skript macht

Hinweise

• Das Skript verwendet bewusst das default-Preset für blink.cmp. Die Custom-Shortcuts (z. B. super-tab oder enter) sind nicht enthalten – du kannst sie später in ~/.config/nvim/lua/plugins/completion.lua anpassen.
• rust-analyzer wird zuerst über rustup installiert. Falls das fehlschlägt oder der Befehl nicht im PATH landet, wird automatisch das Paket aus den Manjaro-Repos nachinstalliert.
• Die Plugin-Installation läuft headless. Sollte das fehlschlagen, kannst du Neovim einfach normal starten und :Lazy sync ausführen.

Ich mag den Editor Vim sehr und ich möchte ihn auch zum Programmieren benutzen. Allerdings ist das mit dem originalen Vim ziemlich kompliziert. Daher habe ich mir mal NeoVim häher angeschaut. Ein modernerer Fork von Vim. Einfach mal die Grundsätzlichen Unterschiede rausgesucht, um zu sehen, welchen ich nun nehmen muss, oder ob ich einfach “beide” weiter benutzen kann. Spoiler Alert: Ich kann einfach beide weiter benutzen.

Und ich werde versuchen mir ein Developement Environment in Rust aufzubauen, das einfach nachvollziehbar ist und das How-To dazu werde ich natürlich auch hier veröffentlichen.

Die wichtigste praktische Konsequenz

Die Wahl hängt stark von meinem Arbeitsumfeld ab:

• Wenn ich viel auf Remote-Servern arbeite (SSH): Vim ist die sichere Bank, weil es fast überall vorinstalliert ist
• Wenn ich lokal eine moderne, IDE-ähnliche Erfahrung mit Plugins und LSP will: Neovim bietet die leistungsfähigere und modernere Basis

Parallelinstallation - Ja!

Problemlos machbar. Vim und Neovim sind völlig eigenständige Programme mit unterschiedlichen Binärnamen (vim vs. nvim), getrennten Konfigurationsverzeichnissen und eigenen Plugin-Ordnern. Sie behindern sich gegenseitig nicht.

Getrennte Konfigurationen

Da beide komplett getrennte Pfade verwenden, kann ich in beiden unterschiedliche Plugins, Themes und Einstellungen haben, ohne dass es zu Konflikten kommt.

Mögliche Überschneidung

Es gibt ein kleines Detail: Manche Distributionen bieten ein Paket namens vim an, das eigentlich ein Symlink auf neovim ist (oder umgekehrt). Das ist aber selten und nur bei bewusst so konfigurierten Systemen der Fall. Normalerweise gilt:

• vim startet Vim
• nvim startet Neovim

Ich kann das mit which vim und which nvim prüfen.

Praktischer Tipp: Standard Editor

Wenn ich beide parallel nutze, lohnt es sich, Neovim als Standard-Editor zu setzen (z. B. über $EDITOR oder alternatives) und Vim als Fallback für Server/SSH zu behalten. So habe ich lokal die moderne Umgebung und auf Servern trotzdem immer einen funktionierenden Editor.

Superflexibel als Alias

Wenn du häufig zwischen beiden wechselst, kannst du dir Aliase in deiner ~/.bashrc anlegen. Zum Beispiel bei Debian/Ubuntu:

alias vim='nvim'
alias vim-old='/usr/bin/vim.basic'

Auf Arch und Manjaro wäre der Alias für den originalen Vim einfach alias vim-old='vim', weil vim dort noch auf den originalen Vim zeigt.

Permanent - Debian & Ubuntu

Für Ubuntu und Debian nutzt du update-alternatives, um Neovim systemweit als Standard zu registrieren.

#### Neovim als Alternative für vi, vim, view und vimdiff registrieren
sudo update-alternatives --install /usr/bin/vi vi /usr/bin/nvim 60
sudo update-alternatives --install /usr/bin/vim vim /usr/bin/nvim 60
sudo update-alternatives --install /usr/bin/view view /usr/bin/nvim 60
sudo update-alternatives --install /usr/bin/vimdiff vimdiff /usr/bin/nvim 60

Die 60 am Ende ist die Priorität. Da Neovim in der Regel mit einer niedrigeren Priorität installiert wird als Vim, sorgt dieser Befehl dafür, dass vim und vi auf nvim zeigen .

Um zu prüfen, ob es funktioniert hat:

which vim
#### sollte /usr/bin/nvim ausgeben

Falls du die Zuordnung später wieder ändern möchtest, kannst du sudo update-alternatives --config vim ausführen und interaktiv auswählen .

Auf Ubuntu gibt es zusätzlich den Befehl sudo select-editor, der dir eine Liste der verfügbaren Editoren anzeigt und dich auswählen lässt . Das ist der einfachste Weg, wenn du nicht manuell in Konfigurationsdateien eingreifen möchtest.

Permanent - Arch & Manjaro

Für Manjaro und Arch Linux setzt du stattdessen die Umgebungsvariablen. Das ist auch der sauberere Weg, weil es unabhängig von der Distribution funktioniert.

#### Systemweit für alle Benutzer
sudo tee -a /etc/environment <EDITOR=nvim
VISUAL=nvim
EOF

Die Variablen werden beim nächsten Login für alle Benutzer aktiv . Ein Vorteil: Programme, die auf $EDITOR oder $VISUAL zugreifen, nutzen dann automatisch Neovim.

Als sudo Editor

Ein Hinweis für sudo: Wenn du sudo visudo oder ähnliches ausführst, werden die Umgebungsvariablen aus /etc/environment standardmäßig nicht übernommen, weil sudo die Umgebung aus Sicherheitsgründen bereinigt . In dem Fall kannst du sudo -E visudo nutzen oder die Variable in der sudoers-Datei mit Defaults env_keep += "EDITOR VISUAL" ergänzen.

sudo -E visudo - temporär

Der -E-Parameter (für --preserve-env) sorgt dafür, dass sudo die Umgebung für diesen einen Befehl komplett beibehält. Du müsstest also immer sudo -E visudo tippen .

Das ist unpraktisch, wenn du es oft brauchst. Der Eintrag in /etc/sudoers ist die dauerhafte Lösung, damit du einfach sudo visudo nutzen kannst und trotzdem Neovim bekommst.

sudoers - permanent

Die Zeile Defaults env_keep += "EDITOR VISUAL" trägst du in die Datei /etc/sudoers ein. Das machst du niemals direkt, sondern immer über den Befehl sudo visudo. Das Tool prüft die Syntax, bevor die Änderung gespeichert wird, und verhindert so, dass du dir das System zerschießt.

Wenn du sudo visudo ausführst, öffnet sich die /etc/sudoers in einem Editor. Du suchst die Zeile, die mit Defaults beginnt, und fügst darunter oder am Ende der Defaults-Sektion deine Zeile hinzu.

Ein Ausschnitt aus der Datei sieht dann so aus:

## Override built-in defaults
Defaults    env_reset
Defaults    env_keep += "EDITOR VISUAL"

Die Zeile Defaults env_reset ist meist schon vorhanden. Sie sorgt dafür, dass sudo eine saubere Umgebung nutzt. Mit Defaults env_keep += "EDITOR VISUAL" sagst du sudo, dass es die Variablen EDITOR und VISUAL aus deiner Umgebung behalten soll .

Warum das nötig ist

Standardmäßig bereinigt sudo die Umgebung. Wenn du also EDITOR=nvim gesetzt hast und dann sudo visudo ausführst, sieht sudo diese Variable nicht mehr. Es fällt dann auf den Standard-Editor zurück, oft vi oder nano .

Mit dem env_keep-Eintrag überlebt deine EDITOR-Variable den sudo-Aufruf, und visudo öffnet sich mit Neovim (oder was auch immer du eingestellt hast).

Quellen

• Vim – Offizielles Repository: GitHub – vim/vim, https://github.com/vim/vim
• Vim – Offizielle Website: vim.org, https://www.vim.org
• Vim – Benutzerhandbuch: Vim User Manual, https://vimhelp.org/usr_toc.txt.html
• Vim – Hilfe-Dokumentation: Vim help files, https://vimhelp.org/
• Neovim – Offizielle Website: neovim.io, https://neovim.io
• Neovim – GitHub-Repository: GitHub – neovim/neovim, https://github.com/neovim/neovim
• Neovim – Benutzerdokumentation: Neovim User Documentation, https://neovim.io/doc/user/index.html
• Neovim – Unterschiede zu Vim: Neovim vim_diff, https://neovim.io/doc/user/vim_diff/

Was Folds überhaupt sind

In Vim sind Folds zusammen- und ausklappbare Bereiche in einem Textdokument. Du kannst damit ganze Absätze, Funktionen oder Codeblöcke zusammenklappen, so dass nur die erste Zeile sichtbar bleibt. Das macht das Navigieren in umfangreichen Dateien deutlich einfacher.

Die Eselsbrücke für den Befehl ist einfach. Alle Fold-Kommandos beginnen mit z, weil das z aussieht wie ein gefaltetes Stück Papier von der Seite betrachtet.

Die sechs Fold-Methoden

Vim bietet sechs verschiedene Methoden, wie Faltungen erstellt werden. Du stellst sie mit :set foldmethod=METHODE ein oder trägst sie dauerhaft in deine ~/.vimrc ein.

• manual - Du erstellst Faltungen selbst mit zf, für unstrukturierte Texte:
• indent - Einrückung bestimmt die Faltungstiefe, ideal für Programmcode
• expr - Faltungen werden durch einen Ausdruck definiert, für Log-Dateien oder spezielle Filter
• syntax - Syntax-Highlighting definiert die Faltungen, ideal für Programmcode
• diff - Unveränderter Text wird gefaltet
• marker - Marker im Text wie {{{ und }}} definieren Faltungen

Für den Alltag sind indent für Code und manual für alles andere die praktischsten Methoden.

foldlevel - Die Faltungstiefe steuern

Die Option foldlevel legt fest, wie viele Ebenen von Faltungen gleichzeitig geöffnet oder geschlossen sind. Sie ist die zentrale Steuerung für die Faltungstiefe im aktuellen Fenster .

Die typischen Werte

• foldlevel=0 - Alle Faltungen sind geschlossen. Du siehst nur die äußerste Struktur, zum Beispiel Kapitelüberschriften oder Top-Level-Funktionen
• foldlevel=1 - Nur die oberste Ebene ist aufgeklappt, darunterliegende Faltungen bleiben geschlossen. Gut für einen Überblick über die Hauptblöcke
• foldlevel=2 - Zwei Ebenen sind sichtbar, tiefere Faltungen bleiben zu. Praktisch für verschachtelte Code-Strukturen
• foldlevel=99 - Praktisch alles ist geöffnet. Nur explizit geschlossene Faltungen bleiben zu

foldlevel vs. foldlevelstart

Ein wichtiger Unterschied: foldlevel gilt für das aktuelle Fenster und wirkt sofort. foldlevelstart legt fest, mit welcher Faltungstiefe eine Datei geöffnet wird .

Wenn du also möchtest, dass eine Datei beim Öffnen komplett aufgeklappt ist, setzt du foldlevelstart=99 in deiner ~/.vimrc .

Wichtige Befehle

• :set foldlevel? zeigt den aktuellen Wert an
• :setlocal foldlevel=1 setzt die Tiefe nur für das aktuelle Fenster
• 2zM schliesst alle Faltungen bis Ebene 2, lässt Ebene 1 offen

Faltungen dauerhaft speichern

Ein wichtiger Punkt, den viele nicht wissen. Wenn du eine Datei schliesst, gehen manuell erstellte Faltungen verloren. Vim merkt sich den Zustand nicht automatisch.

Dafür gibt es die Befehle :mkview und :loadview. Mit :mkview speicherst du den aktuellen Zustand inklusive der Faltungen. Wenn du die Datei später wieder öffnest, lädst du mit :loadview alles zurück. Du kannst bis zu zehn verschiedene Ansichten pro Datei speichern.

Speicherort Faltungen

Vim speichert die Ansichten in dem Verzeichnis, das in der Option viewdir definiert ist. Der Standardwert hängt von deinem Betriebssystem ab:

• Linux und Unix (auch macOS): ~/.vim/view
• Windows: $VIM/vimfiles/view

In diesem Ordner legt Vim für jede Datei eine eigene View-Datei ab. Der Dateiname wird dabei aus dem Pfad der Originaldatei generiert, wobei Sonderzeichen durch Gleichheitszeichen (=) ersetzt werden .

Den aktuellen Speicherort herausfinden

Du kannst dir den Pfad direkt in Vim anzeigen lassen:

:set viewdir?

Die Ausgabe zeigt dir, wo Vim aktuell sucht oder speichert .

Speicherort ändern

Wenn du den Standardpfad ändern möchtest (zum Beispiel um dein Home-Verzeichnis sauber zu halten), kannst du die Option in deiner ~/.vimrc anpassen:

set viewdir=~/.vim/meine-views

Bei neueren Vim-Versionen respektiert der Standardwert mittlerweile auch die XDG_CONFIG_HOME-Umgebungsvariable und nutzt dann ~/.config/vim/view .

View-Dateien löschen

Da es keinen eingebauten Befehl zum Löschen gibt, musst du die Dateien manuell entfernen. Navigiere dazu einfach in den oben genannten Ordner und lösche die entsprechenden Dateien .

Die wichtigsten Befehle für den Alltag

Die grundlegenden Befehle solltest du kennen, dann kommst du schon sehr weit.

Öffnen und Schliessen

• zo öffnet eine Faltung unter dem Cursor (open)
• zc schliesst eine Faltung unter dem Cursor (close)
• za klappt die Faltung um, öffnet wenn geschlossen, schliesst wenn offen (alternate)
• zR öffnet alle Faltungen im Dokument (Reset)
• zM klappt alle Faltungen zu im Dokument (Minimize)

Navigation zwischen Faltungen

Kombination mit den klassischen Navigationsbefehlen:

• zj springt zur nächsten Faltung
• zk springt zur vorherigen Faltung
• [z springt zum Anfang der aktuellen Faltung
• ]z springt zum Ende der aktuellen Faltung

Erstellen und Löschen

• zf gefolgt von einer Bewegung erstellt eine Faltung, zum Beispiel zfap für einen ganzen Absatz (fold)
• zd löscht die Faltung unter dem Cursor, der Text bleibt erhalten (delete)
• zE löscht alle Faltungen im Fenster (Eliminate)

Praktische Beispiele - Faltungsmethoden

Vim bietet sechs verschiedene Methoden, um Faltungen zu erstellen. Welche du wählst, hängt davon ab, was du bearbeitest und wie viel Kontrolle du haben möchtest.

manual - Manuelles Falten mit zf

Die direkteste Methode. Du markierst einen Bereich und faltest ihn mit zf. Das funktioniert visuell, mit Bewegungen oder mit Klammern.

Visuell markieren und falten

1. Markiere den Bereich mit v (zeichenweise), V (zeilenweise) oder Strg-v (blockweise)

2. Drücke zf

Vim erstellt daraus eine Faltung. Der Text bleibt erhalten, wird nur versteckt .

Mit Bewegungen falten

• zfap faltet einen ganzen Absatz (absatz packen - a paragraph)
• zfG faltet vom Cursor bis zum Ende der Datei (Ganz unten - Go to end)
• zfgg faltet vom Dateianfang bis zum Cursor (geh ganz hoch)

Zwischen Klammern falten

Der eleganteste Weg für Code. Setz den Cursor auf eine öffnende Klammer wie { oder [ und drücke zf%. Vim springt zur passenden schliessenden Klammer und faltet alles dazwischen .

Ein Beispiel in einer JavaScript-Datei:

function berechneSumme(a, b) {
  const ergebnis = a + b;
  console.log(ergebnis);
  return ergebnis;
}

Mit dem Cursor auf der öffnenden { und zf% sieht es danach so aus:

+-- 4 lines: function berechneSumme(a, b) {

indent - Faltung durch Einrückung

Für Code die praktischste Methode. Vim erstellt automatisch Faltungen basierend auf der Einrückungstiefe .

:set foldmethod=indent

Jede Ebene der Einrückung wird zu einer Faltungsebene. Beim Öffnen einer Datei mit foldlevel=1 sind alle Funktionen eingeklappt und du siehst nur die Struktur auf einen Blick.

marker - Faltung durch Marker

Du setzt spezielle Markierungen in den Text, die Vim als Faltungsgrenzen erkennt. Die Standard-Marker sind {{{ und }}} .

:set foldmethod=marker

Ein Beispiel:

<div class="container">
  <p>Erste Zeilep>
  <p>Zweite Zeilep>
div>

Der Text zwischen den Markern wird zu einer Faltung. Der Vorteil: Die Faltung bleibt beim erneuten Öffnen der Datei erhalten. Der Nachteil: Du veränderst die Datei selbst.

syntax - Faltung durch Syntax

Vim nutzt die vorhandenen Syntax-Regeln, um Faltungen zu erstellen. Für die meisten Programmiersprachen sind diese Regeln bereits vorhanden .

:set foldmethod=syntax

Bei Ruby-Code werden beispielsweise alle Methoden automatisch gefaltet. Du musst nichts weiter konfigurieren.

expr - Faltung durch Ausdruck

Die flexibelste Methode. Du definierst einen Ausdruck, der für jede Zeile entscheidet, ob sie gefaltet wird .

:set foldmethod=expr
:set foldexpr=getline(v:lnum)=~'ERROR'

Dieses Beispiel faltet alle Zeilen, die nicht das Wort ERROR enthalten. Ideal für Log-Dateien, um nur die Fehler sichtbar zu lassen.

diff - Faltung durch diff

Wenn du zwei Versionen einer Datei vergleichst, werden unveränderte Bereiche automatisch gefaltet. Diese Methode wird meist automatisch aktiviert, wenn du vimdiff oder :diffthis verwendest.

Praktische Anwendung

Für Code-Dateien nutze ich meist foldmethod=indent in Kombination mit foldlevel=1. Dann sind beim Öffnen einer Datei alle Funktionen eingeklappt und ich sehe nur die Struktur auf einen Blick. Mit za klappe ich dann die Funktion auf.

Für längere Textdokumente ist foldmethod=manual oft besser. Dann kann ich selbst entscheiden, welche Absätze ich zusammenklappe.

Und wenn dir die Faltungen mal zu viel werden, dann hilft zR oder zn, um alles wieder zu öffnen.

Quellen

Vim ist als Open-Source-Software verfügbar.

• Webseite: https://www.vim.org/
• Vim Dokumentation Folding: https://vimhelp.org/fold.txt.html
• Vim User Manual Folding: https://vimhelp.org/usr_28.txt.html
• Vim Folding Wiki: https://vim.fandom.com/wiki/Folding

Alte Views löschen - Vimscript

Hier ist ein Vimscript, das verwaiste View-Dateien findet und löscht, sowie eine Anleitung zum Einbinden.

Das Skript nutzt die Funktionen readdir() zum Auflisten des View-Ordners und delete() zum Löschen der Dateien . Die Umkehrung der Namenskonvention (=+ zu /) ist der Kern der Prüfung.

Die Umkehrung der Namenskonvention

Das ist der entscheidende Punkt. Vim speichert View-Dateien nicht unter dem Originalnamen, sondern kodiert den vollständigen Pfad in den Dateinamen. Dabei wird jeder Schrägstrich (/) durch die Zeichenfolge =+ ersetzt.

Ein Beispiel. Die Originaldatei /home/user/test.txt wird zu einer View-Datei mit dem Namen =+home=+user=+test.txt im View-Ordner.

" Funktion zum Bereinigen verwaister View-Dateien
function! s:CleanOrphanedViews()
    " Ermittle das View-Verzeichnis (Standard: ~/.vim/view)
    let view_dir = expand(&viewdir)
    
    " Prüfe, ob das View-Verzeichnis existiert
    if !isdirectory(view_dir)
        echohl WarningMsg
        echo "View-Verzeichnis nicht gefunden: " . view_dir
        echohl None
        return
    endif

    let orphaned_count = 0
    
    " Alle Dateien im View-Verzeichnis auflisten
    for view_file in readdir(view_dir)
        let view_path = view_dir . '/' . view_file
        
        " Nur Dateien verarbeiten (keine Unterordner)
        if !filereadable(view_path)
            continue
        endif

        " Den Dateinamen zurück in einen Pfad umwandeln
        " Vim ersetzt '/' durch '=+' im Dateinamen
        let original_path = substitute(view_file, '=+', '/', 'g')
        
        " Prüfen, ob die Originaldatei noch existiert
        " filereadable() ist robuster als glob() bei Berechtigungsproblemen 
        if !filereadable(original_path)
            " Datei existiert nicht mehr -> View löschen
            if delete(view_path) == 0
                let orphaned_count += 1
                echom "Verwaiste View gelöscht: " . view_file
            else
                echohl WarningMsg
                echom "Fehler beim Löschen: " . view_file
                echohl None
            endif
        endif
    endfor

    " Zusammenfassung ausgeben
    if orphaned_count > 0
        echom "Bereinigung abgeschlossen: " . orphaned_count . " verwaiste View(s) gelöscht."
    else
        echom "Keine verwaisten View-Dateien gefunden."
    endif
endfunction

" Befehl zum Aufrufen der Funktion definieren
command! CleanViews call s:CleanOrphanedViews()

Wie das Skript funktioniert

1. Verzeichnis ermitteln: Das Skript liest die globale Option &viewdir aus, die standardmäßig auf ~/.vim/view (Unix) oder $VIM/vimfiles/view (Windows) zeigt.
2. Dateien auflisten: Mit readdir() werden alle Einträge im View-Ordner gelesen .
3. Pfad rekonstruieren: Der entscheidende Schritt. Vim kodiert den Originalpfad im View-Dateinamen, indem es jeden Schrägstrich (/) durch die Zeichenfolge =+ ersetzt. Die Funktion substitute() macht diese Ersetzung rückgängig.
4. Existenzprüfung: filereadable() prüft, ob die so rekonstruierte Originaldatei noch vorhanden und lesbar ist . Dies ist robuster als eine reine glob()-Prüfung, falls Berechtigungen im Spiel sind .
5. Löschen: Wenn die Originaldatei fehlt, wird die View-Datei mit der eingebauten delete()-Funktion entfernt .

Einbindung in die Vim-Konfiguration

Du hast zwei Möglichkeiten, das Skript dauerhaft zu nutzen.

Option 1: Direkt in die .vimrc einfügen

Kopiere den gesamten Codeblock in deine ~/.vimrc (oder ~/.config/nvim/init.vim). Nach dem Speichern und Neustarten von Vim kannst du den Befehl :CleanViews verwenden.

Option 2: Als separates Plugin (empfohlen für Ordnung)

1. Erstelle eine Datei namens cleanviews.vim im Verzeichnis ~/.vim/plugin/.
2. Füge den Code dort ein.
3. Vim lädt Dateien in ~/.vim/plugin/ beim Start automatisch.

In beiden Fällen steht der Befehl :CleanViews zur Verfügung. Er gibt nach dem Lauf eine Meldung aus, wie viele verwaiste View-Dateien gelöscht wurden.

Mit Common Voice stellt Mozilla den weltweit größten öffentlichen Datensatz menschlicher Stimmen bereit – kostenlos und für jeden nutzbar. Mozilla hat Version 27 seines Datensatzes veröffentlicht.

Der Markt für Spracherkennung wird von den ganz großen Namen kommerzieller Anbieter dominiert: Amazon, Apple, Google, Microsoft. Darum hat Mozilla im Jahr 2017 das Projekt Common Voice gestartet. Mit Common Voice bietet Mozilla eine kostenlose Alternative an, zu der jeder beitragen kann und die jedem zur Verfügung steht. Damit möchte Mozilla Innovation und Wettbewerb in der Sprachtechnologie auf Basis von Maschinenlernen fördern.

Mozilla Common Voice 27

Der nun veröffentlichte Datensatz Common Voice Scripted Speech 27 beinhaltet für die deutsche Sprache 1.492 Stunden an Daten und ist 34,82 GB groß. In Summe waren 20.558 Menschen am deutschsprachigen Datensatz beteiligt. Der Datensatz Common Voice Spontaneous Speech 5 für spontane Sprache kommt für Deutsch auf 1,47 Stunden an Daten und ist 38,71 MB groß, beigetragen von 28 Personen.

Insgesamt deckt Mozilla Common Voice mit der neuen Version, die wieder Unterstützung für eine neue Sprache bringt, 295 Sprachen mit insgesamt 42.593 aufgenommenen Stunden ab, was Mozilla Common Voice zum vielfältigsten mehrsprachigen Sprachkorpus der Welt macht. Die Anzahl der unterstützten Sprachen für spontane Sprache ist von 78 auf 80 Sprachen gewachsen.

Zum Download der Mozilla Common Voice Datensätze
Zu Mozilla Common Voice beitragen

Der Beitrag Mozilla veröffentlicht Common Voice 27 erschien zuerst auf soeren-hentzschel.at.

Dieser Post umfasst eine kurze Problembeschreibung und verweist auf die Lösung, die ich dazu im Internet gefunden und implementiert habe.

Er dient mir als Dokumentation und ich freue mich, wenn er euch ebenfalls hilft, wenn ihr von dem gleichen Problem betroffen seid.

Problembeschreibung

Ein Server mit einer Intel-Netzwerkkarte, welche den Treiber e1000e nutzt, verliert plötzlich die Netzwerkanbindung. Im Protokoll des Servers finden sich dazu wiederholt folgende Meldungen:

kernel: e1000e 0000:00:1f.6 eno1: Detected Hardware Unit Hang:

Remote-Verbindungen werden unterbrochen und es ist nur noch ein Zugriff über eine lokale Konsole möglich. Das kann unpraktisch sein, wenn sich der Server in einem hunderte Kilometer entfernten Standort befindet.

Lösung

Die Lösung habe ich bei der Internetrecherche im Blog von Ruhani Rabin gefunden: https://rabin.blog/fix-intel-e1000e-detected-hardware-unit-hang-on-proxmox/#solution-summary-proxmox-intel-e1000e-hardware-unit-hang-fix

Ruhani hat eine systemd.unit erstellt, welche die problematischen Funktionen des Treibers deaktiviert. Zusätzlich wird ein Watchdog eingerichtet, welcher helfen soll, das Problem bei erneutem Auftreten selbst zu lösen.

Bitte schaut in Ruhanis Blog-Artikel für alle Details zur Lösung. Er hat diese wirklich gut beschrieben.

Ich dokumentiere in den folgenden Code-Blöcken lediglich die systemd.units, die ich auf meinem Host implementiert habe:

# /etc/systemd/system/disable-nic-offload-eno1.service

[Unit]
Description=Disable NIC offloading for Intel e1000e interface eno1
After=network-pre.target
Wants=network-pre.target

[Service]
Type=oneshot
ExecStart=/sbin/ethtool -K eno1 gso off gro off tso off tx off rx off rxvlan off txvlan off sg off
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Und der Watchdog:

# /etc/systemd/system/e1000e-eno1-watchdog.timer
[Unit]
Description=Run e1000e eno1 watchdog every 2 minutes

[Timer]
OnBootSec=2min
OnUnitActiveSec=2min
AccuracySec=30s
Unit=e1000e-eno1-watchdog.service

[Install]
WantedBy=timers.target

# /etc/systemd/system/e1000e-eno1-watchdog.service
[Unit]
Description=Watch for Intel e1000e hardware hangs and reset eno1
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/e1000e-eno1-watchdog

Watchdog-Skript:

#!/usr/bin/env bash
set -u
set -o pipefail

IFACE="eno1"
LOOKBACK="5 minutes ago"
LOCK="/run/e1000e-${IFACE}-watchdog.lock"
STAMP="/run/e1000e-${IFACE}-last-reset"
MIN_RESET_INTERVAL_SECONDS=600

exec 9>"$LOCK"
flock -n 9 || exit 0

if ! journalctl -k --since "$LOOKBACK" --no-pager \
  | grep -Eqi "e1000e .*${IFACE}: Detected Hardware Unit Hang|Detected Hardware Unit Hang"; then
  exit 0
fi

now="$(date +%s)"
last=0
[ -f "$STAMP" ] && last="$(cat "$STAMP" 2>/dev/null || echo 0)"

if [ $((now - last)) -lt "$MIN_RESET_INTERVAL_SECONDS" ]; then
  logger -t e1000e-watchdog "hardware hang detected on ${IFACE}, but reset suppressed by rate limit"
  exit 0
fi

logger -t e1000e-watchdog "hardware hang detected on ${IFACE}; resetting NIC"

if ! ip link set "$IFACE" down; then
  logger -t e1000e-watchdog "failed to bring ${IFACE} down; NIC reset incomplete"
  exit 1
fi

sleep 2

if ! ip link set "$IFACE" up; then
  logger -t e1000e-watchdog "failed to bring ${IFACE} up; NIC reset incomplete"
  exit 1
fi

# Re-apply the offload mitigation after link reset, just in case.
ethtool -K "$IFACE" gso off gro off tso off tx off rx off rxvlan off txvlan off sg off 2>/dev/null || \
  logger -t e1000e-watchdog "warning: unable to re-apply offload mitigation on ${IFACE}"

date +%s >"$STAMP"

logger -t e1000e-watchdog "NIC reset completed for ${IFACE}"

Bugtracker

Laut des KI-Agenten meines geringsten Misstrauens ist das Problem in folgenden Trackern dokumentiert:

• https://bugzilla.kernel.org/show_bug.cgi?id=219489
• https://bugzilla.kernel.org/show_bug.cgi?id=205047

Zum Erscheinungsdatum dieses Beitrags befinden sich beide im Status ‚NEW‘.

Wer auf fryboyter.de aktuell die Suchfunktion verwendet, lädt erst einmal eine JSON-Datei herunter. An sich eine feine Sache, da die Suche somit lokal erfolgt. Allerdings wird diese Index-Datei immer größer. Aktuell über einem Megabyte.

Ich habe mich daher schon vor längerer Zeit überlegt eine andere Lösung zu nutzen. Schlussendlich bin ich bei Pagefind gelandet. Der damit erzeugte Index besteht nicht aus einer großen Datei, sondern aus mehreren kleinen Dateien von denen nur die geladen werden die für die jeweilige Suche benötigt werden. Es spart also Bandbreite für den jeweiligen Nutzer.

Mit Pagefind gab es bei meinen bisherigen Tests allerdings ein Problem. Die Artikelüberschrift wurde zweimal genannt. Einmal als Titel des Suchergebnisses in Form eines Links. Und einmal sozusagen im angezeigten Artikeltest. Also beispielsweise so.

Neuer Betreuer für das Hugo-Theme Ananke gesucht

Betreuer für das Hugo-Theme Ananke gesucht. Blablabla. Veröffentlicht am 16. September 2024 |

Das ist jetzt nicht unbedingt schlimm aber es ist irgendwie nervig. Eine Lösung hatte ich bisher nicht gefunden. Was aber an mir und nicht an Pagefind lag. Im Grunde ist die Lösung ziemlich einfach. Bisher sieht die Datei single.html, mit der die einzelnen Artikel angezeigt werden, wie folgt aus.

{{ define "head" }}
{{ partial "head.html" . }}
{{ end }}
{{ define "main" }}

	

		
{{ .Title }}
		{{ partial "metadata.html" . }}
		{{- .Content }}
		{{- partial "taxonomy.html" . }}
		{{- partial "related.html" . }}
	

{{ end }}

Ändert man diese Datei nun folgendermaßen, wird die Überschrift nur einmal angezeigt, so wie es sein soll.

{{ define "head" }}
{{ partial "head.html" . }}
{{ end }}
{{ define "main" }}

	

		
="title">{{ .Title }}
		{{ partial "metadata.html" . }}
		

			{{- .Content }}
		
		{{- partial "taxonomy.html" . }}
		{{- partial "related.html" . }}
	

{{ end }}

Entscheidend ist hierbei in dem Fall hauptsächlich, dass man der Artikelüberschrift data-pagefind-meta=“title” zuweist und erhält dann beispielsweise folgende Anzeige.

Neuer Betreuer für das Hugo-Theme Ananke gesucht

der MIT-Lizenz) für den statischen Website-Generator Hugo. Für dieses Theme wird nun

Einige werden sich nun fragen, warum der Artikeltext im Suchergebnis mit “der MIT-Lizenz)” anfängt. Pagefind zeigt in der Standardkonfiguration die Zeile an, in der der Suchbegriff das erste Mal erscheint. Ich bin mir nicht sicher, ob mir das so gefällt.

Alternativ könnte man auch das anzeigen, was im Tag steht. Was ich für wesentlich besser halte. Nur habe ich diesen Eintrag bisher nie erstellt. Also seit 2009. Das nachzuholen würde einige hundert Artikel betreffen. Worauf ich manuell keine Lust habe. Daher bin ich aktuell dabei eine Lösung zu testen die mir anhand zweier lokaler LLM eine sinnvolle Beschreibung liefert. Welche ich aber selbstverständlich prüfen werde, falls ich diese Lösung nutzen werde. Aber das ist Stoff für einen anderen Artikel. Vielleicht.

Was lässt sich nach knapp einem halben Jahr über NixOS sagen? Ist es für den "Normalo" zu schwierig? Wie performt es?

Vor einem halben Jahr bin ich zu NixOS gewechselt und nutze es auf allen meinen Rechnern. Zeit für eine ehrliche Zwischenbilanz.

Das Fazit zuerst

Starkoch Nixos kocht noch immer. Die Küche ist aufgeräumt, die Speisekarte als einzige Quelle der Wahrheit ist der Königsweg – und das in drei Restaurants gleichzeitig.

Die beste Erfahrung: NixOS hat mich in den letzten sechs Monaten nie im Stich gelassen, obwohl ich nicht zimperlich mit ihm umgegangen bin. Kein einziger Paketkonflikt, obwohl ich fast alles aus dem Unstable-Branch beziehe – kein zerschossenes System, obwohl ich massiv an der Konfiguration gebastelt habe – der Grundstock ist nach wie vor die Erstinstallation. Ich hatte wirklich immer einen voll arbeitsfähigen Rechner, was mich zwar maximal erfreute, aber es irritierte mich zu Beginn auch irgendwie. Denn nach meiner bisherigen Erfahrung mit Basteln an Linux wäre so stümper- und laienhaftes Schrauben am System unweigerlich mit einem einsam blinkendem Curser auf schwarzem Grund bestraft worden. Mittlerweile ist es mir zur beruhigenden Gewissheit geworden, dass ich immer auch einen Schritt zurück machen kann (1-Klick-Rollback beim Reboot), sollte die neue Konfiguration noch nicht passen.

Ich hatte Probleme, nicht wenige(!), aber diese hatten weniger mit NixOS, als überwiegend mit Git bzw. Codeberg zu tun. NixOS ist ein absolut großartiges Desktop-Linux, aber noch beeindruckender sind die Möglichkeiten, die diese Distribution für eine Multi-Host-Umgebung (also eine Nix-Konfiguration für mehrere Rechner) bietet. Ich hatte die dahingehenden Möglichkeiten von Flakes in Teil 2, Teil 3 und einem weiteren Beitrag in meinem Setup-Guide beschrieben. An Git führt dann aber kein Weg vorbei. Nur ... – Git ist so eine Bit**, es duldet nur die 100%ige und vollständige Unterwerfung vor den Regeln – schlecht, wenn man diese noch nicht so drauf hat. Zum Glück ist NixOS selbst aber extrem robust und stabil, es hat sich durch meine wilde Lernkurverei nie aus der Bahn werfen lassen.

Wenn ich in NixOS mehr verändern möchte, als nur ein Paket zu installieren, schaue ich immer zuerst in die Dokumentation (Wiki und die Options), damit ich den Grundgedanken der Konfiguration in der Nix-Sprache verstehe. Das Suchen in Foren war immer eine Sackgasse. Dagegen lasse ich mir meinen Entwurf für veränderte Konfigurationsdateien (.nix, ich nenne sie liebevoll "Nixen") immer von einer freundlichen KI gegenchecken. Gleiches gilt für die Interpretation von Fehlermeldungen, welche ich oft als Reaktion auf meine Experimente zurückbekam. Diese Fehlermeldungen (generiert vom Nix-Evaluator) sind übrigens bemerkenswert, da sie ziemlich ausführlich, konkret und präzise ausfallen, keineswegs nur eine Fehlernummer mit Benennung. Mit dem beschriebenen Vorgehen bin ich als Novize gut gefahren.

Ich schrieb ja schon ziemlich zu Beginn, also voll in meiner Anfangseuphorie, dass Distro-Hopping durch NixOS ein Ende gefunden hat. Daran hat sich tatsächlich nichts geändert, nach einem halben Jahr mit NixOS gibt es kein Zurück mehr. Die Idee des Deklarativen (siehe Teil 1 meines Setup-Guides) hat sich eingebrannt und begeistert mich bis heute ungebrochen.

Was brillant funktioniert

Das Versprechen der Reproduzierbarkeit. Ich betreibe mittlerweile drei Rechner mit NixOS: einen Dell 5320, einen Dell Pro Plus und ein Surface Go 2 (welches mein altes Lenovo ersetzte). Alle drei laufen mit der gleichen Basis-Konfiguration. Wenn ich auf einem Rechner etwas ändere, landen die Änderungen via Codeberg auf allen anderen – mit einem einzigen Befehl. Das klingt nach einem kleinen Kunststück – aber genau das ist NixOS.

Rollbacks retten Leben. Zweimal bootete ein Rechner nach einem Rebuild (mit von mir verursachten Konfigurationsfehlern) nicht mehr – einmal der Dell 5320 wegen einer falschen UUID in der hardware-configuration.nix, einmal das Surface wegen eines von mir verursachtem Kernel-Konflikts. Beide Male: Neustart – ältere Generation im Bootmenü wählen – fertig. Auf anderen Systemen wäre das eine Neuinstallation geworden. Bei NixOS war es ein Klick. Und das ist schon beeindruckend – und ungemein beruhigend. Der Arbeitstag kann dann in jedem Fall erstmal normal weiter laufen.

Das Update-Skript. Von Beginn an erstellte ich mir kleine Skripte für die Shell (in meinem Fall die Fish-Shell), welche Arbeitsschritte zusammenfassen. Klar, ein Update funktioniert bei NixOS tatsächlich mit nur einem Befehl, aber wenn man wie in meinem Fall Flakes nutzt, muss es ja noch über Git zu Codberg und committet werden. Was als einfaches nixos-rebuild switch begann, ist heute eine vollständige Fish-Funktion namens update, die automatisch erkennt, ob ein Rechner hinter Codeberg zurückliegt oder lokale Änderungen hat – und dann das Richtige tut. Kein Nachdenken mehr darüber, ob ich eine aktualisierte Konfiguration auch wirklich via Git zu Codeberg transferiert hatte.
Konkret funktioniert das so: Mein Skript update vergleicht zunächst den lokalen Git-Stand mit dem auf Codeberg. Hängt der aktuelle Rechner hinter Codeberg zurück – zum Beispiel, weil auf einem anderen Rechner Änderungen gemacht wurden – holt es automatisch den aktuellen Stand und baut das System neu. Hat der aktuelle Rechner hingegen neue lokale Änderungen, aktualisiert es die Paketversionen, baut das System, bereinigt den Nix-Store und sichert alles auf Codeberg. Sind beide Seiten auf dem gleichen Stand, wird trotzdem ein Update der Pakete angestoßen – damit kein Rechner aus Versehen veraltet.
Darunter liegen drei Funktionen, die ich zunächst als separate Skripte hatte: update-push für das bewusste Aktualisieren und Sichern, pull-update für das Holen und Bauen vom Codeberg-Stand, und rebuild für den schnellen lokalen Neuaufbau ohne Git.

Und die Weiterentwicklung in Form des Skripts update steht auch Dir zur Verfügung. Die verlinkten Konfigurationsdateien aus dem Teil 2 meines Setup-Guides habe ich seither aktualisiert.

Multi-Host-Setup. Durch das mehrfach verbesserte und nun finale Update-Skript konnte ich meine selbst- und hausgemachten Git- und Codeberg-Probleme überwinden. Seither ist die Freude an der Multi-Host-Performance von NixOS ungetrübt. Kleines Beispiel: Ich hatte meine Tochter immer um ihr schickes kleines Surface Go 3 beneidet, deshalb kaufte ich mir nach dem Tod meines alten Lenovo (ich berichtete HIER von der Einbindung) ein gebrauchtes Go 2 mit M3-Prozesser. Unter den Ultra-Portablen PCs mit Tablet-Funktion, ist die Surface-Go-Serie in meinen Augen ein herausragend wunderbares Stück Hardware – einen kleinen portablen Rechner brauche ich einfach auch (hauptsächlich für den Urlaub). Trotz einer abgespeckten Programmauswahl und weniger Verknüpfungen mit Netzwerklaufwerken, lässt sich der kleine Rechner dennoch super in die gemeinsame Grundkonfiguration einbinden und auch dort verwalten. Die oben verlinkte Anleitung beschreibt das Vorgehen. Die für das Go 2 angepassten "Nixen" verlinke ich ganz unten.

Performance. Beispielsweise das erwähnte Surface Go 2 (mit dem M3-Prozessor) läuft mit dem Standard-NixOS-Kernel (einen angepassten Surface-Kernel braucht es nicht) unter NixOS um Welten flüssiger, als das leicht bessere Go 3 meiner Tochter mit dem i3 unter Ubuntu.
Generell muss ich sagen, dass NixOS extrem flüssig auf jeder meiner Maschinen läuft. Auf dem Dell5320 hatte ich ja vorher CachyOS, das lief keine Spur besser.

Wo es wirklich gehapert hat

Git und Codeberg waren mein Erzfeind, mein Endgegner, "aarrrrghh". Der SSH-Key für root fehlte. Branches liefen auseinander. Push-Fehler wegen nicht-linearer Historie. Falsche UUIDs in der hardware-configuration.nix die irgendwann beim falschen Rechner gelandet waren. Ich habe mindestens ein Dutzend Mal sudo git reset --hard origin/master eingegeben – manchmal notgedrungen, manchmal weil ich es schlicht vergessen hatte vorher zu pullen. Aus diesen selbst eingebrockten Frust-Momenten entstand das Skript update, welches mich vor eigenen Fehlern im Umgang mit Git schützt.

Die ehrliche Diagnose: Die Git-Workflows bei einem Multi-Host-Setup sind nicht trivial. Man muss verstehen, dass Codeberg die Quelle der Wahrheit ist – und immer dann, wenn man das vergisst, rächt es sich. Ich habe es oft vergessen.

Die flake.nix ist nicht fehlerverzeihend. Ein fehlendes Anführungszeichen, ein falscher Attributname, ein home-manager.users.retorix das für zwei von drei Rechnern vergessen wurde – und das System baut nicht, oder schlimmer, es baut aber lässt danach alle Programme verschwinden. Der Nix-Evaluator gibt aber geduldig so lange erläuternde Fehlermeldungen, bis man den Dreh (evtl. mit KI-Unterstützung) raus hat.

Der fehlerhafte Nextcloud-Client. Ausgerechnet der für mich so wichtige Nextcloud-Client machte als normales Paket Probleme. Das selektive Auswählen von Synchronisationsordnern war im Paket fehlerhaft. Die Internet-Recherche ergab, dass es ein bekanntes Problem ist, die Flatpak-Version aber fehlerfrei sein soll. Somit musste ich in den sauren Apfel beißen (ich mag keine Container) und nur für dieses eine Programm auf meinem System Flathub einrichten. Tatsächlich waren damit dann aber auch die Probleme mit dem Nextcloud-Client gelöst.

Zeitaufwand für ein Update. Das ist nur eine Anmerkung, nichts was einschränkt, oder gar störend ist – ich möchte es aber erwähnen. Da NixOS ja bei jedem Update den Nix-Store neu sortiert, das System nach der geänderten Deklaration neu baut und den alten Ballast von Bord wirft, dauert ein Update länger, als z.B. ein sudo pacman -Syu auf einem Arch-Linux-System. Parallel weiterarbeiten ist aber kein Problem. Dafür ist das System aber stets frisch und clean gebaut, so als wäre es eine Neuinstallation.

Was ich gelernt habe

NixOS ist nicht das superschwierige Nerd-System. Die Konfigurationsdateien folgen einer glasklaren Logik, die man einmal verstehen muss – und dann läuft es, auch wenn es zu Beginn manchmal ruckelt.
Was ich unterschätzt hatte: die Werkzeuge rund um NixOS (Git, Codeberg, Flakes, Home-Manager) bilden zusammen ein Ökosystem, das man erst kennenlernen muss – da stecken die steilen Rampen in der Lernkurve - aber eben nur dann, wenn man ein Multi-Host-Setup anstrebt.

In Teil 2 schrieb ich:

Es gibt viele technische Gründe für die "Gewaltenteilung" im System, mich persönlich überzeugt aber ein eher philosophischer Grund am meisten: Semantische Klarheit: configuration.nix beschreibt, was das System ist, home.nix beschreibt, was Du bist. Das ist keine technische Notwendigkeit, sondern eine gedankliche Ordnung, die sich auszahlt, sobald die Konfiguration dann doch mal wächst.

Dazu stehe ich auch heute noch, würde aber nach meinem wilden Ritt mit Git und Codeberg heute dazu anmerken:
Gib der deklarativen Idee von NixOS unbedingt eine Chance, bleib aber bei nur einem oder zwei Rechnern erstmal bei der ausschließlichen Konfiguration über die configuration.nix, so wie in Teil 1 meiner Setup-Reihe beschrieben.

Wenn jemand aufgrund meiner Impulse ebenfalls bei NixOS gelandet ist, würde ich mich über einen Kommentar freuen; aber jeder andere Beitrag zu NixOS interessiert mich natürlich ebenso.

Ressourcen

Hier die Konfigurationsdateien für das Go 2. In der flake.nix (siehe Download in Teil 2) ist das Surface natürlich als Teil des Multi-Host-Setups ebenfalls mit aufgeführt:
surface-system.nix
home-surface.nix

Die MZLA Technologies Corporation hat mit Thunderbird 156 eine neue Version seines Open Source E-Mail-Clients für Windows, Apple macOS und Linux veröffentlicht.

Neuerungen von Thunderbird 156

Mit Thunderbird 156 hat die MZLA Technologies Corporation ein Update für seinen Open Source E-Mail-Client veröffentlicht. Die neue Version bringt Verbesserungen für bestimmte Authentifizierungs-Szenarien in Zusammenhang mit Yandex sowie OAuth. Debug-Informationen für PGP lassen sich in der Browserkonsole ausgeben. Die Unterstützung für mehrere neue Unternehmensrichtlinien wurde ergänzt. Ansonsten gab es auch wieder eine ganze Reihe von Verbesserungen unter der Haube und Fehlerkorrekturen, welche sich wie immer in den Release Notes (engl.) nachlesen lassen. Auch Sicherheitslücken wurden im neuesten Update wieder behoben.

Der Beitrag Thunderbird 156 veröffentlicht erschien zuerst auf soeren-hentzschel.at.

Mozilla und Mistral haben gemeinsam eine Partnerschaft angekündigt, um offene, private und mehrsprachige KI für diejenigen Nutzer in den Browser zu bringen, die KI im Browser nutzen wollen. Dabei setzt Mozilla natürlich, wie auch bisher, auf eine optionale und freiwillige Nutzung.

Wie Mozilla und das französische KI-Unternehmen Mistral gemeinsam angekündigt haben, arbeitet man für KI-Funktionen in Firefox zusammen. Konkret geht es dabei um die sogenannten intelligenten Fenster, die bereits schrittweise für Nutzer in den USA, Kanada und Frankreich ausgerollt werden. Über eine eigene Oberfläche können unter anderem komplexe Recherchen zusammengefasst, zuvor besuchte Inhalte wiedergefunden und Informationen aus geöffneten Tabs aufbereitet werden. Eine Ausrollung in Deutschland sowie Großbritannien soll noch in diesem Jahr folgen.

Mozilla stellt für die intelligenten Fenster unter anderem Mistral Small 4 als Modell zur Verfügung. Das Besondere an Mistral: Die Modelle von Mistral sind genau wie Firefox Open Source. Sprache, Dialekte und kulturelle Besonderheiten werden in den Modellen von Mistral von Beginn an berücksichtigt, statt eine primär englischsprachige Lösung lediglich nachträglich zu übersetzen. Und auch der Datenschutz ist ein wichtiger Aspekt: Unterhaltungen werden nicht auf Mozilla-Servern gespeichert und Mistral verpflichtet sich zur Nichtaufbewahrung übermittelter Daten.

Der Beitrag Mozilla und Mistral kündigen Partnerschaft an erschien zuerst auf soeren-hentzschel.at.

Mozilla hat Firefox 156 für Windows, Apple macOS und Linux veröffentlicht. Dieser Artikel fasst die wichtigsten Neuerungen zusammen.

Download Mozilla Firefox für Microsoft Windows, Apple macOS und Linux

Neuerungen in Firefox 156

Wie auf Windows gibt es nun auch auf macOS eine Einstellung, die aktiviert werden kann, damit Firefox mit dem Starten des Systems direkt mit gestartet werden kann.

In den Einstellungen für die Tab-Umgebungen wurde die neue Option „Keine Tab-Umgebungen für Links verwenden, die von externen Apps geöffnet werden” hinzugefügt.

Auch in Deutschland, Frankreich und Italien können nun direkt in der Adressleiste Vorschläge von Wikipedia oder gesponserte Vorschläge angezeigt werden, was in den Einstellungen zur Suche ein- und ausgeschaltet werden kann.

Der PDF-Betrachter startet jetzt bis zu 45 Prozent schneller. Die Nutzung von CPU und RAM wurde verbessert, wenn große JPEG-Dateien herunterskaliert werden. Und auf Geräten mit ARM64-CPU und Windows gibt es jetzt Hardware-Unterstützung für das Decoding von H.264 in WebRTC-Kommunikation.

Auch in Firefox 156 wurden wieder mehrere Sicherheitslücken geschlossen. Alleine aus Gründen der Sicherheit ist ein Update auf Firefox 156 daher für alle Nutzer dringend empfohlen.

Darüber hinaus gab es diverse Korrekturen, welche in den offiziellen Release Notes näher beschrieben werden, darunter auch das Problem, dass Firefox für manche Nutzer in Zusammenhang mit dem integrierten VPN oder DNS-over-HTTPS Probleme beim Laden von Websites haben konnte. Verbesserungen der Webplattform lassen sich in den MDN web docs nachlesen.

Der Beitrag Mozilla veröffentlicht Firefox 156 erschien zuerst auf soeren-hentzschel.at.

Ich kopiere regelmäßig Dateien auf USB-Sticks oder SD-Karten, die mit FAT32 formatiert sind. Und jedes Mal gibt es Ärger mit Dateinamen, die Zeichen enthalten, die FAT32 nicht erlaubt. Doppelpunkte, Fragezeichen, Sternchen, alles was unter Linux völlig normal ist, wird auf FAT32 zum Problem.

Also habe ich mir ein Bash-Skript geschrieben, das die Arbeit übernimmt. Es durchsucht den aktuellen Ordner, ersetzt alle ungültigen Zeichen und kümmert sich auch um führende oder abschließende Leerzeichen und Punkte. Kollisionen werden vermieden, indem ein Zähler angehängt wird.

Was das Skript macht

Das Skript arbeitet in mehreren Schritten. Zuerst werden alle Dateien im aktuellen Ordner durchlaufen. Für jede Datei wird der Name geprüft und bereinigt.

Die FAT32-verbotenen Zeichen sind der Backslash, der Slash, der Doppelpunkt, das Sternchen, das Fragezeichen, die Anführungszeichen, die spitzen Klammern und die Pipe. Alle diese Zeichen werden durch einen Unterstrich ersetzt.

Zusätzlich werden Steuerzeichen entfernt, also Zeichen mit den Codes 0x00 bis 0x1F. Die tauchen selten auf, aber wenn doch, machen sie Probleme.

Dann werden führende und abschließende Leerzeichen und Punkte entfernt. FAT32 mag das nicht, auch wenn es auf anderen Dateisystemen kein Problem ist.

Wenn der Name danach leer ist, wird ein Notfallname vergeben.

Und schließlich wird geprüft, ob bereits eine Datei mit dem neuen Namen existiert. Falls ja, wird ein Zähler angehängt, um Kollisionen zu vermeiden.

Wie du es verwendest

Speichere das Skript im Ordner, in dem du es verwenden willst unter einem Namen wie z.B. fat32-rename.sh und starte es

bash fat32-rename.sh

Das Skript arbeitet nur im aktuellen Ordner. Unterordner werden nicht durchsucht. Wenn du auch Unterordner bereinigen möchtest, müsstest du es mit find kombinieren oder eine rekursive Variante schreiben.

Was du beachten solltest

Das Skript benennt Dateien um. Wenn du sichergehen möchtest, dass nichts schiefgeht, solltest du vorher ein Backup machen oder zumindest testen, was das Skript tun würde, bevor du es auf wichtige Daten loslässt.

Das Skript überschreibt keine Dateien. Wenn eine Datei mit dem neuen Namen bereits existiert, wird ein Zähler angehängt, sodass der neue Name eindeutig ist.

Das Skript verarbeitet nur Dateien, keine Ordner. Wenn du auch Ordner umbenennen möchtest, müsstest du die Bedingung [ -f "$f" ] entsprechend anpassen.

Fazit

Das Skript hat mir schon viel Zeit gespart. Statt Dateien einzeln umzubenennen, lasse ich es einfach über den Ordner laufen und danach kopiere ich die Dateien auf den FAT32-Datenträger. Das funktioniert zuverlässig und ich muss mir keine Gedanken mehr über ungültige Zeichen machen.

Wenn du häufig mit FAT32 zu tun hast, ist das eine kleine Hilfe, die sich schnell bezahlt macht.

Das Skript

#!/usr/bin/env bash
# Ersetzt FAT32-ungültige Zeichen in Dateinamen im aktuellen Ordner
# Autor: hoergen
# 15.09.2026

for f in *; do
    [ -f "$f" ] || continue

    # FAT32-verbotene Zeichen ersetzen:
    #   \ / : * ? " < > |   ->  _
    # Zusätzlich entfernen: Steuerzeichen (0x00–0x1F) am Anfang/Ende
    new=$(echo "$f" \
        | tr '\\/:*?"<>|' '_________' \
        | tr -d '\000-\037')

    # Führende/abschließende Leerzeichen und Punkte entfernen
    # (FAT32 mag das nicht)
    new=$(echo "$new" | sed -e 's/^[ .]*//' -e 's/[ .]*$//')

    # Leerer Name -> Notfallname
    [ -z "$new" ] && new="unnamed"

    if [ "$f" != "$new" ]; then
        # Kollisionen vermeiden
        if [ -e "$new" ]; then
            base="${new%.*}"
            ext="${new##*.}"
            [ "$base" = "$ext" ] && ext=""
            n=1
            while [ -e "${base}_$n${ext:+.$ext}" ]; do
                n=$((n+1))
            done
            new="${base}_$n${ext:+.$ext}"
        fi
        mv -- "$f" "$new"
        echo "OK  $f -> $new"
    fi
done

tmuxp - ein Session-Manager für tmux, der Sessions über deklarative YAML- oder JSON-Dateien lädt, einfriert und konvertiert.

Das Projekt basiert auf libtmux und wird aktiv auf GitHub entwickelt. Die Idee ist simpel. Statt jeden Morgen fünf Fenster manuell zu öffnen und Befehle einzutippen, definierst du deine Arbeitsumgebung einmal als Datei und lädst sie mit einem Befehl.

Was tmuxp macht

tmuxp verwaltet tmux-Sessions auf Basis von Konfigurationsdateien. Du beschreibst darin, welche Fenster und Panes geöffnet werden sollen und welche Befehle darin ausgeführt werden. Beim Laden baut tmuxp die Session genau so auf, wie du sie definiert hast.

Das funktioniert mit YAML und JSON. tmuxp unterstützt auch die Formate von tmuxinator und teamocil, was den Umstieg erleichtert, wenn du bereits eine dieser Lösungen nutzt.

Installation

tmuxp lässt sich auf verschiedene Weisen installieren. Je nach System und Vorliebe gibt es mehrere Wege.

Unter Debian und Ubuntu läuft es über apt.

sudo apt install tmuxp

Für Manjaro

sudo pamac install tmuxp

Andere Installationsarten sind auf github beschrieben.

Eine Session laden

Das Herzstück von tmuxp ist der load-Befehl. Du definierst eine Session in einer YAML-Datei und lädst sie damit.

Ein einfaches Beispiel sieht so aus.

# yaml Datei
session_name: my-project
windows:
  - window_name: editor
    panes:
      - shell_command:
          - vim
      - shell_command:
          - git status

Diese Datei speicherst du als my-project.yaml und lädst sie dann.

tmuxp load my-project.yaml

Erklärung:

1. tmuxp baut daraufhin eine Session mit dem Namen my-project auf.
2. Darin befindet sich ein Fenster namens editor, das in zwei Panes aufgeteilt ist.
3. Im ersten Pane läuft vim
4. im zweiten wird git status ausgeführt.

Komplexere Konfiguration

tmuxp kann deutlich mehr als nur einfache Fenster. Du kannst Layouts definieren, Befehle vor dem Start aller Panes ausführen und mehrere Panes mit unterschiedlichen Aufgaben bestücken.

Ein Beispiel mit vier Panes und einem vordefinierten Layout.

session_name: 4-pane-split
windows:
  - window_name: dev window
    layout: tiled
    shell_command_before:
      - cd ~/
    panes:
      - shell_command:
          - cd /var/log
          - ls -al | grep \.log
      - echo second pane
      - echo third pane
      - echo fourth pane

Erklärung:

1. Der Parameter shell_command_before führt einen Befehl in allen Panes aus, bevor die eigentlichen Befehle starten. In diesem Fall wechselt jeder Pane zuerst ins Home-Verzeichnis.
2. Der Parameter layout legt fest, wie die Panes angeordnet werden.
3. tiled bedeutet, dass alle Panes gleichmäßig verteilt werden.

Größenangaben

Die layout-Option

Die zentrale Option dafür ist layout. Du kannst entweder einen vordefinierten Namen verwenden oder einen spezifischen Layout-String, den tmux selbst generiert.

Vordefinierte Layouts sind einfach zu nutzen, geben dir aber weniger Kontrolle:

windows:
  - window_name: dev
    layout: main-horizontal
    panes:
      - vim
      - git status

Weitere gängige Namen sind tiled, even-horizontal und even-vertical.

Spezifische Größen und Positionen

Wenn du genau definieren möchtest, wie die Panes angeordnet sind, musst du den Layout-String von tmux verwenden. Dieser String ist eine kodierte Beschreibung der Aufteilung und Größe jeder Zelle.

1. Baue eine tmux-Session mit den gewünschten Pane-Aufteilungen manuell auf.
2. Frage das aktuelle Layout ab:

tmux list-windows

3. Kopiere den Layout-String (der lange Code nach layout:) in deine tmuxp-YAML-Datei.

Ein Beispiel für einen solchen String sieht so aus:

layout: 382a,80x60,0,0[80x10,0,0,0,80x10,0,11,1,80x10,0,22,2,80x8,0,33,3]

Die Zahlen kodieren Breite x Höhe und Position jedes Panes. Das ist präzise, aber nicht besonders lesbar.

Alternative % für einfache Anpassungen

Wenn du nur die Höhe des Haupt-Panes bei Layouts wie main-horizontal oder main-vertical anpassen möchtest, kannst du die Option main-pane-height verwenden. Diese kann in Zeilen oder seit tmuxp 1.46.0 auch in Prozent angegeben werden.

windows:
  - window_name: rust-study
    layout: main-horizontal
    options:
      main-pane-height: 67%
    panes:
      - vim
      - cargo run

Das ist oft der praktischere Weg, wenn du nur das Größenverhältnis zwischen Haupt- und Nebenpanes steuern willst.

Projekte und Konfigurationsverzeichnisse

tmuxp sucht nach Konfigurationen in verschiedenen Verzeichnissen. Wenn du eine Datei mit dem Namen .tmuxp.yaml oder .tmuxp.json in einem Projektordner ablegst, kannst du sie direkt über den Ordnerpfad laden.

tmuxp load path/to/my/project/

Für benutzerweite Konfigurationen durchsucht tmuxp mehrere Verzeichnisse automatisch. Das ist praktisch, wenn du deine Sessions von überall aus laden möchtest, ohne den vollständigen Pfad anzugeben.

• $TMUXP_CONFIGDIR, falls gesetzt
• $XDG_CONFIG_HOME, üblicherweise $HOME/.config/tmuxp/
• $HOME/.tmuxp/

Wenn deine Konfiguration unter ~/.config/tmuxp/mysession.yaml liegt, reicht folgender Befehl.

tmuxp load mysession

Du kannst auch mehrere Sessions gleichzeitig laden.

tmuxp load mysession ./another/project/

Oder der Session einen eigenen Namen geben.

tmuxp load -s session_name ./mysession.yaml

Sessions einfrieren (speichern)

Manchmal hast du eine tmux-Session bereits aufgebaut und möchtest sie als Konfiguration speichern. Dafür gibt es den freeze-Befehl.

tmuxp freeze session-name

tmuxp erstellt dann eine YAML- oder JSON-Datei, die den aktuellen Zustand der Session beschreibt. Layout, Pane-Pfade, Fensternamen und Sessionnamen werden übernommen. Das ist praktisch, wenn du eine Session spontan aufgebaut hast und sie später reproduzieren möchtest.

Der tmuxp freeze-Befehl speichert die Datei standardmäßig nicht in einem festen Verzeichnis. Stattdessen wirst du beim Ausführen gefragt, wo die Datei gespeichert werden soll.

Wo speichern

Wenn du tmuxp freeze session-name ausführst, bietet dir tmuxp an, den Zustand als .yaml- oder .json-Datei zu speichern .

Beim Ausführen von tmuxp freeze wirst du interaktiv gefragt, wo die Datei gespeichert werden soll. Du kannst den Speicherort dann angeben oder einen vorgeschlagenen Pfad bestätigen

Speicherorte für Konfigurationen

Wenn du deine gefrorene Session später bequem über den Namen laden möchtest, solltest du sie in einem der folgenden Verzeichnisse ablegen :

• ~/.tmuxp/ – das klassische Verzeichnis
• ~/.config/tmuxp/ – der XDG-Standardpfad
• Projektlokal – als .tmuxp.yaml oder .tmuxp.json im Projektordner

Eigenen Pfad angeben

Du kannst den Speicherort auch direkt mit dem -o oder --save-to Parameter festlegen .

tmuxp freeze my-session -o /pfad/zur/datei.yaml

Konvertieren zwischen Formaten

Wenn du eine Konfiguration von YAML nach JSON oder umgekehrt umwandeln möchtest, geht das mit dem convert-Befehl.

tmuxp convert filename

tmuxp zeigt dir die neue Datei an und fragt nach Bestätigung. Wenn du den Prompt automatisch bestätigen möchtest, kannst du den Parameter -y verwenden.

tmuxp convert -y filename

Die tmuxp-Shell

Seit Version 1.6.0 gibt es den Befehl tmuxp shell. Damit startest du eine Python-Konsole, die mit dem aktuellen Server, der Session und dem Fenster als libtmux-Objekte vorgeladen ist.

tmuxp shell

Das ist nützlich, wenn du tmux-Sessions skripten oder automatisieren möchtest.

Plugins und Erweiterungen

tmuxp hat ein Plugin-System, mit dem du eigenes Verhalten hinzufügen kannst. Das ist interessant, wenn du spezielle Anforderungen hast, die über die Standardfunktionen hinausgehen.

Ein Pre-Load-Hook erlaubt es dir, benutzerdefinierte Skripte auszuführen, bevor tmux geladen wird. Das kann zum Beispiel genutzt werden, um Projektabhängigkeiten zu installieren.

Debugging

Wenn beim Laden einer Session etwas schiefgeht, kannst du die Ausgabe in eine Logdatei schreiben.

tmuxp load --log-file  .

Für Bugreports gibt es den Befehl tmuxp debug-info, der Systeminformationen sammelt.

tmuxp debug-info

Load im Hintergrund

Wenn du eine Session laden möchtest, ohne dich direkt daran anzuhängen, kannst du den Parameter -d verwenden.

tmuxp load -d mysession.yaml

Das ist praktisch, wenn du mehrere Sessions vorbereiten möchtest und später entscheiden willst, welche du verwendest.

Fazit

tmuxp ist ein Werkzeug, das tmux für mich deutlich angenehmer macht. Statt jedes Mal die gleiche Session von Hand aufzubauen, definiere ich sie einmal und lade sie mit einem Befehl. Oder kopiere sie auf mehrere Rechner, so dass ich sie nur ein einziges Mal definieren muss. Das spart Zeit und reduziert Fehler.

Besonders praktisch finde ich die Möglichkeit, Sessions einzufrieren. Wenn ich spontan eine Session aufgebaut habe, die ich öfter brauche, speichere ich sie einfach als Konfiguration und habe sie beim nächsten Mal sofort parat.

Danke an Markus aus dem Fedivers https://social.row-social.de/@markus , der mich darauf aufmerksam gemacht hat!

Quellen und Download

tmuxp ist als Open-Source-Software unter der MIT-Lizenz verfügbar.

• Webseite: https://tmuxp.git-pull.com/
• GitHub: https://github.com/tmux-python/tmuxp
• Dokumentation: https://tmuxp.git-pull.com/
• PyPI: https://pypi.org/project/tmuxp/

Die MZLA Technologies Corporation hat mit Thunderbird 23 ein Update für die Android-Version seines E-Mail-Clients veröffentlicht.

Download Thunderbird für Android

Die MZLA Technologies Corporation hat Thunderbird 23 für Android veröffentlicht. Das Problem wurde behoben, dass das Signaturfeld in den Einstellungen nur einzeiligen Text akzeptierte. Daneben gab es auch wieder eine Reihe von Verbesserungen unter der Haube.

Der Beitrag Thunderbird 23 für Android veröffentlicht erschien zuerst auf soeren-hentzschel.at.

Firefox bietet eine Integration gleich mehrerer KI-Chatbots. Microsoft Copilot ist nicht länger eine Option.

Seit Firefox 135 integriert Mozillas Browser mehrere KI-Chatbots. Dabei stehen Google Gemini, ChatGPT, Anthropic Claude, Mistral Vibe – und bislang auch Microsoft Copilot – zur Verfügung. Die Chatbots können direkt über die Sidebar genutzt werden.

Microsoft Copilot wurde erst später in Firefox 143 hinzugefügt und jetzt von Mozilla wieder entfernt. Als Begründung nennt Mozilla, dass Microsoft die Unterstützung für die Copilot-Sidebar am 18. August eingestellt habe. Das Datum passt auch zu einer ganzen Reihe weiterer Features, die Microsoft ab diesem Tag für Copilot gestrichen hat.

Der Beitrag Microsoft Copilot ist nicht länger Chatbot-Option in Firefox erschien zuerst auf soeren-hentzschel.at.

Die MZLA Technologies Corporation hat mit Thunderbird 155.0.1 ein Update für seinen Open Source E-Mail-Client veröffentlicht.

Neuerungen von Thunderbird 155.0.1

Mit Thunderbird 155.0.1 hat die MZLA Technologies Corporation ein Update für seinen Open Source E-Mail-Client veröffentlicht und behebt damit das Problem, dass leere Eingaben im Filter Treffer für jede Nachricht ergaben.

Der Beitrag Thunderbird 155.0.1 veröffentlicht erschien zuerst auf soeren-hentzschel.at.

Btop - Der moderne Systemmonitor für das Terminal

Btop ist ein ressourcenschonender Systemmonitor, der die Auslastung und Statistiken für Prozessor, Arbeitsspeicher, Festplatten, Netzwerk und Prozesse anzeigt. Es ist die C++-Fortsetzung von bashtop und bpytop und bietet eine Reihe von Verbesserungen und neuen Funktionen.

Besonderheiten und Funktionen

Die Oberfläche ist schnell und reaktionsschnell. Du kannst Prozesse mit den Pfeiltasten auswählen und dir detaillierte Statistiken für den markierten Prozess anzeigen lassen. Eine Filterfunktion hilft dir, bestimmte Prozesse zu finden, und du kannst zwischen verschiedenen Sortieroptionen wechseln. Die Baumansicht der Prozesse gibt dir einen Überblick über die Prozesshierarchie.

Du kannst Signale an ausgewählte Prozesse senden, die Prozessliste anhalten und alle Konfigurationsoptionen über ein UI-Menü anpassen. Die Netzwerkgraphen skalieren automatisch, und die Festplatten-E/A-Aktivitäten werden angezeigt. Ein Batteriemeter und wählbare Symbole für die Graphen runden das Bild ab.

Unterstützte Betriebssysteme

Btop läuft auf Linux, macOS, FreeBSD, NetBSD und OpenBSD.

Installation

Ubuntu und Derivate

Die einfachste Methode ist die Installation über das Paket-Repository deiner Distribution:

sudo apt install btop

Manjaro

sudo pamac btop

GPU-Unterstützung

Btop unterstützt NVIDIA-, AMD- und Intel-GPUs unter Linux x86_64. Die GPU-Unterstützung ist standardmäßig aktiviert.

Konfiguration

Alle Optionen können direkt in der Benutzeroberfläche geändert werden. Die Konfigurations- und Protokolldateien werden in $XDG_CONFIG_HOME/btop oder $HOME/.config/btop gespeichert. Die Datei btop.conf wird automatisch generiert, falls sie nicht gefunden wird.

Du kannst das Farbschema, die angezeigten Boxen, die Aktualisierungsrate, die Prozesssortierung und vieles mehr anpassen. Voreinstellungen für das Layout der Boxen können ebenfalls definiert werden.

Themes

Btop verwendet dieselben Themendateien wie bpytop und bashtop. Die Standard-Themes werden bei der Installation in /usr/local/share/btop/themes (oder dem mit PREFIX festgelegten Verzeichnis) abgelegt. Eigene Themes legst du im Benutzerverzeichnis ~/.config/btop/themes ab.

Voraussetzungen für das Terminal

Für die beste Erfahrung solltest du ein Terminal mit Unterstützung für 24-Bit-Truecolor verwenden. 256-Farben-Terminals werden durch eine Umwandlung von 24-Bit- zu 256-Farben unterstützt, wenn du in den Optionen truecolor auf False setzt oder die Argumente -lc/--low-color verwendest. Der 16-Farben-TTY-Modus wird automatisch aktiviert, wenn ein echtes TTY-Gerät erkannt wird, oder kann mit -t/--tty erzwungen werden.

Deine Schriftart sollte die Unicode-Blöcke “Braille Patterns”, “Geometric Shapes”, “Box Drawing” und “Block Elements” enthalten.

Tastenkürzel

Die vollständige Liste der Tastenkürzel findest du in der Hilfefunktion von btop (Taste h oder ?).

Wichtige Tasten sind:

• Pfeiltasten: Navigation in der Prozessliste
• Enter: Details zum ausgewählten Prozess anzeigen
• /: Prozesse filtern
• f: Prozess folgen
• p: Prozessliste anhalten/fortsetzen
• k: Signal an Prozess senden
• q: Beenden

Quelle

Projekt-Repository und Dokumentation https://github.com/aristocratos/btop

Mousehop ist ein Software-KVM für Linux, Windows & Apple, das es erlaubt, mehrere Rechner mit nur einer Maus und Tastatur zu steuern. Die gesamte Kommunikation läuft verschlüsselt über das lokale Netzwerk. Ich zeige dir hier, wie du es von der Installation bis zur fertigen Verbindung zwischen zwei Ubuntu-Rechnern einrichtest.

Installation unter Linux

Mousehop ist ein junger Fork und noch nicht in den offiziellen Paketquellen der Distributionen enthalten. Ich habe mir daher das flatpak Paket geschnappt, das auf der Release Seite zu finden ist (Link unten)

Das installiere ich dann ganz einfach im entsprechenden Download Verzeichnis mit dem Befehl

flatpak install mousehop.flatpak

Mousehop verwendet den UDP-Port 4252 für die Kommunikation. Stelle sicher, dass dieser Port in der Firewall beider Rechner für eingehende Verbindungen freigegeben ist.

Nach der Installation kannst du Mousehop ganz normal über das Startmenü starten.

Verbindung der Rechner

Die Einrichtung der Verbindung zwischen deinem Hauptrechner (Rechner A mit Maus und Tastatur) und dem Client-Rechner (Rechner B) erfolgt in zwei Schritten. Beide Rechner müssen sich im gleichen lokalen Netzwerk befinden.

Client auf Rechner B konfigurieren

Starte Mousehop auf Rechner B. In der Sektion “Outgoing Connections” klickst du auf den Add Button. Hier trägst du den Hostnamen oder die IP-Adresse deines Hauptrechners (Rechner A) ein. Du legst auch fest, auf welcher Seite sich Rechner A befindet, damit der Mauszeiger später in die richtige Richtung wechselt. Die möglichen Positionen sind left, right, top und bottom.

Verbindung auf Rechner A autorisieren

Sobald du die Verbindung auf Rechner B initiiert hast, erscheint auf Rechner A eine Anfrage in der Sektion “Incoming Connections”. Klicke hier auf den Authorize Button. In diesem Schritt wird auch entschieden, ob die Synchronisation der Zwischenablage erlaubt wird. Die Freigabe ist standardmäßig deaktiviert und muss für jede Richtung separat aktiviert werden. Aus Sicherheitsgründen wird nur Text übertragen und die Größe ist auf 4 Kilobyte begrenzt.

Nach der Autorisierung ist die Verbindung sofort aktiv. Du kannst nun die Maus über den Bildschirmrand in Richtung des Client-Rechners bewegen und sie erscheint dort.

Ebenso auf dem Rechner A muss die “Outgoing Connections” konfiguriert werden. So kann dann auch hier definiert werden, wo die Maus aus dem Bildschirm raus muss, um auf welcher Seite auf dem anderen Rechner in dessen Bildschirm rein zu fliegen.

Automatischer Start

Wenn du mousehop automatisch starten willst, dann kannst du in den “Systemeinstellungen”, auf der linken Seite ganz fast unten den Menüeintrag “Autostart” anklicken, oben rechts im Fenster auf “+ Neue hinzufügen” klicken , Applikation oder Program, auswählen, “Mousehop” auswählen und fertig.

Wechsel mit Tastenkombination

Um zu verhindern, dass der Mauszeiger versehentlich den Bildschirm verlässt, kannst du den Wechsel an eine Modifikationstaste wie Strg oder Alt koppeln. In den Einstellungen des jeweiligen Clients aktivierst du dafür die Option “Require Modifier to Cross”.

Zwischenablage und Datenschutz

Die Synchronisation der Zwischenablage ist optional und wird pro Verbindung in beide Richtungen separat gesteuert. Es gibt eine Ausschlussliste für Anwendungen wie Passwort-Manager, deren Inhalte nicht übertragen werden.

Download

Features und Dokumentation https://github.com/jondkinney/mousehop

Releases (Binaries für alle Plattformen) https://github.com/jondkinney/mousehop/releases