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

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

Osiris, eine Plattform, die sich selbst als offene Alternative zu Analysewerkzeugen wie Palantir versteht und verschiedene öffentlich zugängliche Datenquellen in einer einheitlichen Kartenoberfläche vereint.

Das Projekt ist ambitioniert. Ein Blick auf die Möglichkeiten.

Was Osiris bietet

Die Plattform integriert eine breite Palette von Informationsbereichen. Die Daten werden in Echtzeit auf einer interaktiven Karte dargestellt, die mit WebGL gerendert wird. Das sorgt für eine flüssige Darstellung, selbst wenn viele Datenpunkte gleichzeitig angezeigt werden.

Das Dashboard zeigt unter anderem:

• Luftfahrtdaten über kommerzielle, private und militärische Flüge vom OpenSky Network
• Schifffahrt mit Daten zu 39 globalen Häfen und 10 strategischen Engpässen
• Über 17.000 öffentliche CCTV-Kameras aus verschiedenen Quellen
• Echtzeit-Erdbebenmeldungen ab Stärke 2.5 vom USGS
• Aktive Waldbrand-Hotspots über NASA FIRMS
• 24/7 Nachrichtenfeeds von mehr als 25 globalen Sendern
• Weltraumwetter und Satellitenpositionen
• CVE-Bedrohungen und Schwachstellenscanning
• 13 aktive Konfliktzonen
• Kryptowährungs-Wallet-Verfolgung für BTC und ETH mit Sanktionslisten-Abgleich
• Telegram-OSINT-Layer für die geografische Auswertung öffentlicher Kanalposts

Das RECON Toolkit

Neben der Kartenansicht bietet Osiris ein RECON Toolkit mit zusätzlichen Funktionen. Damit wird die Plattform von einem reinen Visualisierungstool zu einer vollwertigen Workstation für OSINT-Recherchen.

Das Toolkit umfasst:

• Port-Scans mit Service-Erkennung
• DNS-Abfragen für vollständige Record-Auflösung
• WHOIS-Suchen für Domain- und IP-Registrierungsdaten
• SSL/TLS-Inspektion für Zertifikatsketten
• IP-Intelligence mit Geolokalisierung und Threat-Reputation
• Schwachstellenscans mit CVE-Abfragen gegen die NVD-Datenbank
• Sanktionsabfragen gegen OpenSanctions

Technische Architektur

Osiris basiert auf Next.js 16 und MapLibre GL. Alle Kartendaten werden über WebGL gerendert, was eine flüssige Darstellung auch bei vielen gleichzeitigen Entitäten ermöglicht. Die Architektur ist in drei Ebenen unterteilt:

• Die Client-Ebene mit der Kartenoberfläche, Bedienelementen und dem RECON-Toolkit
• Die API-Routen von Next.js als Verbindungsschicht
• Die externen Datenquellen, die größtenteils ohne API-Schlüssel genutzt werden

Betrieb und Nutzung

Die Plattform ist als Open-Source-Software unter der MIT-Lizenz veröffentlicht. Sie kann lokal betrieben oder per Docker-Container bereitgestellt werden. Die meisten Kernfunktionen arbeiten ohne API-Schlüssel, lediglich für das RECON-Toolkit ist ein separater Backend-Scanner erforderlich.

Die Dokumentation enthält detaillierte Anleitungen zur Installation und Konfiguration. Für den Betrieb mit Docker Compose sind nur wenige Schritte nötig:

Das Docker-Image ist für amd64 und arm64 verfügbar und hat eine Größe von etwa 220 MB.

Einordnung des Projekts

Osiris ist ein ernsthaftes Open-Source-Softwareprojekt mit einer vollständigen Codebasis und aktiver Entwicklung. Die Plattform bietet eine beeindruckende Vielfalt an integrierten OSINT-Datenquellen und stellt diese in einer modernen, leistungsfähigen Oberfläche dar.

Die Selbsteinschätzung als Alternative zu kommerziellen Intelligence-Plattformen ist ambitioniert, wird aber durch den offenen Quellcode und die umfangreichen Funktionen untermauert. Das Projekt richtet sich an Entwickler, Sicherheitsforscher und alle, die sich für Echtzeit-OSINT interessieren und die Plattform selbst hosten oder weiterentwickeln möchten.

Quellen

• Webseite: https://osirisai.live/
• GitHub: https://github.com/simplifaisoul/osiris
• Docker-Image: ghcr.io/aiacos/osiris:latest

Osiris, eine Plattform, die sich selbst als offene Alternative zu Analysewerkzeugen wie Palantir versteht und verschiedene öffentlich zugängliche Datenquellen in einer einheitlichen Kartenoberfläche vereint.

Das Projekt ist ambitioniert. Ein Blick auf die Möglichkeiten.

Was Osiris bietet

Die Plattform integriert eine breite Palette von Informationsbereichen. Die Daten werden in Echtzeit auf einer interaktiven Karte dargestellt, die mit WebGL gerendert wird. Das sorgt für eine flüssige Darstellung, selbst wenn viele Datenpunkte gleichzeitig angezeigt werden.

Das Dashboard zeigt unter anderem:

• Luftfahrtdaten über kommerzielle, private und militärische Flüge vom OpenSky Network
• Schifffahrt mit Daten zu 39 globalen Häfen und 10 strategischen Engpässen
• Über 17.000 öffentliche CCTV-Kameras aus verschiedenen Quellen
• Echtzeit-Erdbebenmeldungen ab Stärke 2.5 vom USGS
• Aktive Waldbrand-Hotspots über NASA FIRMS
• 24/7 Nachrichtenfeeds von mehr als 25 globalen Sendern
• Weltraumwetter und Satellitenpositionen
• CVE-Bedrohungen und Schwachstellenscanning
• 13 aktive Konfliktzonen
• Kryptowährungs-Wallet-Verfolgung für BTC und ETH mit Sanktionslisten-Abgleich
• Telegram-OSINT-Layer für die geografische Auswertung öffentlicher Kanalposts

Das RECON Toolkit

Neben der Kartenansicht bietet Osiris ein RECON Toolkit mit zusätzlichen Funktionen. Damit wird die Plattform von einem reinen Visualisierungstool zu einer vollwertigen Workstation für OSINT-Recherchen.

Das Toolkit umfasst:

• Port-Scans mit Service-Erkennung
• DNS-Abfragen für vollständige Record-Auflösung
• WHOIS-Suchen für Domain- und IP-Registrierungsdaten
• SSL/TLS-Inspektion für Zertifikatsketten
• IP-Intelligence mit Geolokalisierung und Threat-Reputation
• Schwachstellenscans mit CVE-Abfragen gegen die NVD-Datenbank
• Sanktionsabfragen gegen OpenSanctions

Technische Architektur

Osiris basiert auf Next.js 16 und MapLibre GL. Alle Kartendaten werden über WebGL gerendert, was eine flüssige Darstellung auch bei vielen gleichzeitigen Entitäten ermöglicht. Die Architektur ist in drei Ebenen unterteilt:

• Die Client-Ebene mit der Kartenoberfläche, Bedienelementen und dem RECON-Toolkit
• Die API-Routen von Next.js als Verbindungsschicht
• Die externen Datenquellen, die größtenteils ohne API-Schlüssel genutzt werden

Betrieb und Nutzung

Die Plattform ist als Open-Source-Software unter der MIT-Lizenz veröffentlicht. Sie kann lokal betrieben oder per Docker-Container bereitgestellt werden. Die meisten Kernfunktionen arbeiten ohne API-Schlüssel, lediglich für das RECON-Toolkit ist ein separater Backend-Scanner erforderlich.

Die Dokumentation enthält detaillierte Anleitungen zur Installation und Konfiguration. Für den Betrieb mit Docker Compose sind nur wenige Schritte nötig:

Das Docker-Image ist für amd64 und arm64 verfügbar und hat eine Größe von etwa 220 MB.

Einordnung des Projekts

Osiris ist ein ernsthaftes Open-Source-Softwareprojekt mit einer vollständigen Codebasis und aktiver Entwicklung. Die Plattform bietet eine beeindruckende Vielfalt an integrierten OSINT-Datenquellen und stellt diese in einer modernen, leistungsfähigen Oberfläche dar.

Die Selbsteinschätzung als Alternative zu kommerziellen Intelligence-Plattformen ist ambitioniert, wird aber durch den offenen Quellcode und die umfangreichen Funktionen untermauert. Das Projekt richtet sich an Entwickler, Sicherheitsforscher und alle, die sich für Echtzeit-OSINT interessieren und die Plattform selbst hosten oder weiterentwickeln möchten.

Quellen

• Webseite: https://osirisai.live/
• GitHub: https://github.com/simplifaisoul/osiris
• Docker-Image: ghcr.io/aiacos/osiris:latest

Einleitung

Ich habe hier sehr verkürzt die “General Resolution: LLM usage in Debian”, den Verantwortungsvollen Umgang mit generativer KI in Debian auf deutsch übersetzt, da sich nicht jeder gleich ganz tief in das etwas lange Dokument eintauchen will. Wie gesagt ist alles verkürzt und wenn du es genau wissen willst, dann ist unten der Originalartikel verlinkt.

Verantwortungsvoller Umgang mit generativer KI in Debian

Die Debian-Resolution zum verantwortungsvollen Umgang mit generativer KI legt klare Regeln für Mitwirkende fest. Der Grundsatz ist, dass KI-Werkzeuge verwendet werden dürfen, aber die menschliche Verantwortung an erster Stelle steht.

Menschliche Verantwortung

Jede Person, die einen Beitrag zu Debian einreicht, bleibt vollständig verantwortlich für diesen Beitrag, unabhängig davon, ob generative KI bei der Erstellung geholfen hat. Das bedeutet, dass Sie KI-generierte Inhalte verstehen, prüfen, testen und bei Bedarf anpassen müssen, bevor Sie sie einreichen. Das blinde Übernehmen von KI-Ausgaben ist nicht erlaubt.

Gleiche Qualitätsstandards

Für Beiträge, die mit KI-Unterstützung erstellt wurden, gelten dieselben Anforderungen wie für alle anderen Beiträge. Insbesondere müssen sie die Standards in Bezug auf Qualität, Korrektheit, Wartbarkeit und rechtliche Konformität erfüllen. Es gibt weder Erleichterungen noch zusätzliche Hürden für KI-assistierte Arbeiten.

Schutz vertraulicher Informationen

Es ist untersagt, vertrauliche oder nicht-öffentliche Informationen an externe KI-Dienste weiterzugeben. Dazu zählen private Kommunikation, nicht-öffentliche Sicherheitslücken, kryptografische Schlüssel und Zugangsdaten. Diese Regelung schützt die Sicherheit und Integrität des Debian-Projekts.

Kontrollierte Massenänderungen

Große automatisierte Aktionen mit KI-Unterstützung, wie das massenhafte Einreichen von Patches oder Fehlerberichten, sind nur nach vorheriger Absprache erlaubt. Solche Vorhaben müssen in den entsprechenden Projektkanälen diskutiert und abgestimmt werden und benötigen eine menschliche Aufsicht.

Offenlegung der KI-Nutzung

Es besteht keine Pflicht, die Nutzung von KI zu kennzeichnen. Das Projekt ermutigt jedoch ausdrücklich zur Transparenz, etwa durch einen Hinweis im Commit-Kommentar. Dies wird als Akt der Höflichkeit gegenüber anderen Mitwirkenden betrachtet und erleichtert die Zusammenarbeit.

Umgang mit rechtlichen Fragen

Die Resolution trifft keine endgültige Entscheidung über die komplexen rechtlichen Fragen rund um generative KI, wie Urheberschaft oder Lizenzierung von KI-Ausgaben. Mitwirkende werden aufgefordert, hier mit besonderer Sorgfalt und eigenem Urteilsvermögen zu handeln. Inhalte, deren rechtlicher Status nicht geklärt ist, sollten nicht eingebracht werden.

Kernbotschaft

Die Entscheidung von Debian lautet weder für noch gegen den Einsatz generativer KI. Der zentrale Grundsatz ist, dass Sie KI-Werkzeuge nutzen können, aber die volle Verantwortung für das Endergebnis tragen. Entscheidend ist die Qualität und Integrität des Beitrags, nicht das verwendete Werkzeug.

• Debian: General Resolution: LLM usage in Debian

Das Problem

Ich benutze Linux. Genauer gesagt das Tuxedo OS, das eine Abwandlung von Kubuntu ist.

Ich habe seit mindestens über einem Jahr das Problem, dass das Drag’n’Drop von und nach Bitwig-Studio nicht funktioniert. Vor einiger Zeit fing es dann auch noch an, dass Copy’n’Paste innerhalb Bitwig-Studio nicht mehr funktionierte. Das hatte ich auch schon vor langer Zeit an Bitwig gemeldet.

Ich weiss dass es bei der Umstellung von X11 auf Wayland hier und da Probleme gibt und gab, aber bei Copy’N’Paste & Drag’N’Drop gehe ich davon aus, dass dieses Problem nicht wirklich lange existiert, da es sich dabei um wirklich wichtige Funktionen geht.

Das Problem ist Bitwig schon lange bekannt, allerdings erreichte mich keiner dieser unten aufgeführten Infos. Ich hätte mir gewünscht, dass so ein Thema im Newsletter erwähnt wird, so dass es alle BenutzerInnen erreichen kann.

Die Lösungen

Die Lösung des Problems liegt irgendwo tief im System beim ibus verbgraben. In Kurz: ibus stürzt einfach manchmal ab und steht dann nicht mehr zur Verfügung.

Betroffene Versionen laut github (link unten): Der Fehler tritt in den IBus-Versionen 1.5.32~rc2-1, 1.5.32-1 und 1.5.32-2 auf, die in aktuellen Distributionen wie Ubuntu 25.04 und Fedora 42 enthalten sind.

Auf lange Sicht sollte das Problem durch eine Aktualisierung der korrigierten Version von IBus in den Distributionen von selbst lösen.

IBus steht für Intelligent Input Bus und ist im Kern ein Framework für Eingabemethoden . Es fungiert als eine Art “Übersetzer” zwischen deiner Tastatur und den Anwendungen, mit dem Ziel, die Eingabe von komplexen Zeichen zu ermöglichen, die nicht auf einer Standardtastatur vorhanden sind

Schnelle Lösung

Es gibt die einfache Lösung, die bei mir (Tuxedo OS/KDE Plasma) geklappt hat. Damit ging Copy/Paste und Drag/Drop sofort wieder.

Und zwar gibt es in untem rechts am Bildschirm die Systemleiste. Dort wo auch sich die Uhrzeit, das Lautsprechersymbol usw befindet. Dort befindet sich auch das Zwischenablage/Clipboard Programm Klipper.

1. Rechtsklick auf das Klipper Symbol und “Verlauf löschen” anklicken.
2. Und dann auch noch das Popupfenster bestätigen.

Ich habe mir eine Tastenkombination angelegt Strg+Meta+Backspace, so kann ich das ohne Klicken eben schnell machen. Klipper deaktivieren ist für mich keine Option, da ich diesen exzessiv benutze.

Es gibt noch die Möglichkeit das Widget Klipper zeitweise zu deaktivieren.

1. Dazu ganz rechts unten vor der Uhrzeit/Datum auf den Pfeil nach oben klicken
2. und dann die Settings oben rechts öffnen (2 waagrechte Striche mit zwei Punkten).
3. In der Suche “Clipboard” oder “Zwischenspeicher” eingeben, das Widget finden
4. und die Einstellung auf “Never show (disabled)” oder “Nicht anzeigen (deaktiviert)” stellen.
5. Nach der Session wieder auf den vorherigen Status zurück stellen.

Workaround

Und es gibt einen weiteren Workaround, der bei einigen Leuten geholfen hat

Wenn der Bug auf deinem System weiterhin auftritt, gibt es eine mögliche Lösung: Du kannst Bitwig ohne IBus starten.

Das geschieht, indem du die Umgebungsvariablen für IBus deaktivierst, z.B. mit den Werten GTK_IM_MODULE=none, QT_IM_MODULE=none und XMODIFIERS=@im=none . Das hat bei anderen Nutzern bereits geholfen.

GTK_IM_MODULE=none QT_IM_MODULE=none XMODIFIERS=@im=none bitwig-studio

Rückkehr zu X11

Eine “Lösung”, die noch genannt wird, ist zu X11 zurück zu kehren. Das ist allerdings keine Option für mich.

Quellen

• Thread im Fedivers
• Crash when using Bitwig Studio · Issue #2817 · ibus/ibus
• Github - ibus-x11 assert failure: realloc(): invalid next size when typing in Zed #2789
• Klipper leeren

Video

Das Problem

Ich benutze Linux. Genauer gesagt das Tuxedo OS, das eine Abwandlung von Kubuntu ist.

Ich habe seit mindestens über einem Jahr das Problem, dass das Drag’n’Drop von und nach Bitwig-Studio nicht funktioniert. Vor einiger Zeit fing es dann auch noch an, dass Copy’n’Paste innerhalb Bitwig-Studio nicht mehr funktionierte. Das hatte ich auch schon vor langer Zeit an Bitwig gemeldet.

Ich weiss dass es bei der Umstellung von X11 auf Wayland hier und da Probleme gibt und gab, aber bei Copy’N’Paste & Drag’N’Drop gehe ich davon aus, dass dieses Problem nicht wirklich lange existiert, da es sich dabei um wirklich wichtige Funktionen geht.

Das Problem ist Bitwig schon lange bekannt, allerdings erreichte mich keiner dieser unten aufgeführten Infos. Ich hätte mir gewünscht, dass so ein Thema im Newsletter erwähnt wird, so dass es alle BenutzerInnen erreichen kann.

Die Lösungen

Die Lösung des Problems liegt irgendwo tief im System beim ibus verbgraben. In Kurz: ibus stürzt einfach manchmal ab und steht dann nicht mehr zur Verfügung.

Betroffene Versionen laut github (link unten): Der Fehler tritt in den IBus-Versionen 1.5.32~rc2-1, 1.5.32-1 und 1.5.32-2 auf, die in aktuellen Distributionen wie Ubuntu 25.04 und Fedora 42 enthalten sind.

Auf lange Sicht sollte das Problem durch eine Aktualisierung der korrigierten Version von IBus in den Distributionen von selbst lösen.

IBus steht für Intelligent Input Bus und ist im Kern ein Framework für Eingabemethoden . Es fungiert als eine Art “Übersetzer” zwischen deiner Tastatur und den Anwendungen, mit dem Ziel, die Eingabe von komplexen Zeichen zu ermöglichen, die nicht auf einer Standardtastatur vorhanden sind

Schnelle Lösung

Es gibt die einfache Lösung, die bei mir (Tuxedo OS/KDE Plasma) geklappt hat. Damit ging Copy/Paste und Drag/Drop sofort wieder.

Und zwar gibt es in untem rechts am Bildschirm die Systemleiste. Dort wo auch sich die Uhrzeit, das Lautsprechersymbol usw befindet. Dort befindet sich auch das Zwischenablage/Clipboard Programm Klipper.

1. Rechtsklick auf das Klipper Symbol und “Verlauf löschen” anklicken.
2. Und dann auch noch das Popupfenster bestätigen.

Ich habe mir eine Tastenkombination angelegt Strg+Meta+Backspace, so kann ich das ohne Klicken eben schnell machen. Klipper deaktivieren ist für mich keine Option, da ich diesen exzessiv benutze.

Es gibt noch die Möglichkeit das Widget Klipper zeitweise zu deaktivieren.

1. Dazu ganz rechts unten vor der Uhrzeit/Datum auf den Pfeil nach oben klicken
2. und dann die Settings oben rechts öffnen (2 waagrechte Striche mit zwei Punkten).
3. In der Suche “Clipboard” oder “Zwischenspeicher” eingeben, das Widget finden
4. und die Einstellung auf “Never show (disabled)” oder “Nicht anzeigen (deaktiviert)” stellen.
5. Nach der Session wieder auf den vorherigen Status zurück stellen.

Workaround

Und es gibt einen weiteren Workaround, der bei einigen Leuten geholfen hat

Wenn der Bug auf deinem System weiterhin auftritt, gibt es eine mögliche Lösung: Du kannst Bitwig ohne IBus starten.

Das geschieht, indem du die Umgebungsvariablen für IBus deaktivierst, z.B. mit den Werten GTK_IM_MODULE=none, QT_IM_MODULE=none und XMODIFIERS=@im=none . Das hat bei anderen Nutzern bereits geholfen.

GTK_IM_MODULE=none QT_IM_MODULE=none XMODIFIERS=@im=none bitwig-studio

Rückkehr zu X11

Eine “Lösung”, die noch genannt wird, ist zu X11 zurück zu kehren. Das ist allerdings keine Option für mich.

Quellen

• Thread im Fedivers
• Crash when using Bitwig Studio · Issue #2817 · ibus/ibus
• Github - ibus-x11 assert failure: realloc(): invalid next size when typing in Zed #2789
• Klipper leeren

Einleitung

Ich habe hier sehr verkürzt die “General Resolution: LLM usage in Debian”, den Verantwortungsvollen Umgang mit generativer KI in Debian auf deutsch übersetzt, da sich nicht jeder gleich ganz tief in das etwas lange Dokument eintauchen will. Wie gesagt ist alles verkürzt und wenn du es genau wissen willst, dann ist unten der Originalartikel verlinkt.

Verantwortungsvoller Umgang mit generativer KI in Debian

Die Debian-Resolution zum verantwortungsvollen Umgang mit generativer KI legt klare Regeln für Mitwirkende fest. Der Grundsatz ist, dass KI-Werkzeuge verwendet werden dürfen, aber die menschliche Verantwortung an erster Stelle steht.

Menschliche Verantwortung

Jede Person, die einen Beitrag zu Debian einreicht, bleibt vollständig verantwortlich für diesen Beitrag, unabhängig davon, ob generative KI bei der Erstellung geholfen hat. Das bedeutet, dass Sie KI-generierte Inhalte verstehen, prüfen, testen und bei Bedarf anpassen müssen, bevor Sie sie einreichen. Das blinde Übernehmen von KI-Ausgaben ist nicht erlaubt.

Gleiche Qualitätsstandards

Für Beiträge, die mit KI-Unterstützung erstellt wurden, gelten dieselben Anforderungen wie für alle anderen Beiträge. Insbesondere müssen sie die Standards in Bezug auf Qualität, Korrektheit, Wartbarkeit und rechtliche Konformität erfüllen. Es gibt weder Erleichterungen noch zusätzliche Hürden für KI-assistierte Arbeiten.

Schutz vertraulicher Informationen

Es ist untersagt, vertrauliche oder nicht-öffentliche Informationen an externe KI-Dienste weiterzugeben. Dazu zählen private Kommunikation, nicht-öffentliche Sicherheitslücken, kryptografische Schlüssel und Zugangsdaten. Diese Regelung schützt die Sicherheit und Integrität des Debian-Projekts.

Kontrollierte Massenänderungen

Große automatisierte Aktionen mit KI-Unterstützung, wie das massenhafte Einreichen von Patches oder Fehlerberichten, sind nur nach vorheriger Absprache erlaubt. Solche Vorhaben müssen in den entsprechenden Projektkanälen diskutiert und abgestimmt werden und benötigen eine menschliche Aufsicht.

Offenlegung der KI-Nutzung

Es besteht keine Pflicht, die Nutzung von KI zu kennzeichnen. Das Projekt ermutigt jedoch ausdrücklich zur Transparenz, etwa durch einen Hinweis im Commit-Kommentar. Dies wird als Akt der Höflichkeit gegenüber anderen Mitwirkenden betrachtet und erleichtert die Zusammenarbeit.

Umgang mit rechtlichen Fragen

Die Resolution trifft keine endgültige Entscheidung über die komplexen rechtlichen Fragen rund um generative KI, wie Urheberschaft oder Lizenzierung von KI-Ausgaben. Mitwirkende werden aufgefordert, hier mit besonderer Sorgfalt und eigenem Urteilsvermögen zu handeln. Inhalte, deren rechtlicher Status nicht geklärt ist, sollten nicht eingebracht werden.

Kernbotschaft

Die Entscheidung von Debian lautet weder für noch gegen den Einsatz generativer KI. Der zentrale Grundsatz ist, dass Sie KI-Werkzeuge nutzen können, aber die volle Verantwortung für das Endergebnis tragen. Entscheidend ist die Qualität und Integrität des Beitrags, nicht das verwendete Werkzeug.

• Debian: General Resolution: LLM usage in Debian

Pacman oder Pamac

Bei der Nutzung von Manjaro Linux stellt sich die Frage, ob für die Paketverwaltung auf der Konsole der klassische Pacman oder der modernere Pamac die bessere Wahl ist. Beide Werkzeuge haben ihre Daseinsberechtigung. Ich möchte hier die Unterschiede aufzeigen und eine Entscheidungshilfe geben.

Die Grundlagen

Pacman ist der ursprüngliche Paketmanager von Arch Linux und bildet das Herzstück der Paketverwaltung in Manjaro. Das Programm ist schlank, schnell und zuverlässig.

Pamac hingegen wurde von den Manjaro-Entwicklern geschaffen und bietet auch eine grafische Oberfläche sowie eine erweiterte Kommandozeilen-Variante. Pamac baut auf Pacman auf und erweitert es um wichtige Funktionen.

Die Unterschiede im Detail

Der wichtigste Unterschied liegt in der Benutzerfreundlichkeit und den zusätzlichen Funktionen. Pacman arbeitet puristisch und ausschliesslich mit den offiziellen Paketquellen.

Pamac hingegen unterstützt von Haus aus das Arch User Repository, kurz AUR, und kann auch Flatpak- und Snap-Pakete verwalten.

Bei der Geschwindigkeit hat Pacman klare Vorteile. Das Programm arbeitet direkt mit der Datenbank und führt nur die notwendigsten Prüfungen durch.

Pamac ist etwas langsamer, da es mehr Sicherheitschecks und Abhängigkeitsanalysen vornimmt. Dieser Unterschied zeigt sich vor allem bei grossen Updates.

Die Abhängigkeitsauflösung ist bei beiden Werkzeugen gut. Pamac zeigt beim Entfernen von Paketen jedoch übersichtlicher an, welche weiteren Pakete betroffen sind. Das erweist sich als hilfreich, besonders beim Deinstallieren grösserer Pakete wie ganzer Desktop-Umgebungen.

Einsatz von Pacman

Für die tägliche Systempflege und wichtige Updates eignet sich Pacman besonders gut. Der Befehl sudo pacman -Syu stellt den zuverlässigsten Weg dar, das System auf den neuesten Stand zu bringen. Pacman ist hier schneller und weniger fehleranfällig als die grafische Variante.

Bei Systemproblemen oder Abstürzen von Pamac kommt keine Alternative an Pacman vorbei. Das Programm stellt die letzte Instanz dar und funktioniert immer, auch wenn die grafische Oberfläche nicht mehr startet. Für Skripte und Automatisierungen ist Pacman ebenfalls die bessere Wahl.

Einsatz von Pamac

Für die Installation neuer Software bietet sich Pamac an. Der Befehl pamac search liefert übersichtlichere Ergebnisse, und pamac install kann automatisch AUR-Pakete einbinden, ohne dass zusätzliche Parameter erforderlich sind.

Besonders beim Entfernen von Paketen schätze ich die klare Darstellung der Abhängigkeitsbäume. Pamac zeigt genau, welche Pakete mit entfernt werden, wenn ein Programm deinstalliert wird. Das hilft, böse Überraschungen zu vermeiden.

Für Einsteiger erweist sich Pamac durch die grafische Oberfläche und die besseren Fehlermeldungen als zugänglicher. Die Integration von AUR macht es zum vielseitigen Werkzeug der Paketverwaltung.

Die goldene Regel

Ein wichtiger Punkt: Pacman und Pamac sollten nie gleichzeitig genutzt werden. Beide Werkzeuge greifen auf dieselbe Datenbank zu und sperren sie während der Arbeit. Bei geöffneter grafischer Oberfläche von Pamac sollte diese geschlossen werden, bevor im Terminal Pacman verwendet wird. Andernfalls erscheint eine Fehlermeldung über eine gesperrte Datenbank.

Persönliche Empfehlung

Ich nutze beide Werkzeuge für unterschiedliche Zwecke. Für die grossen Systemupdates greife ich zu Pacman. Das Programm ist schneller und zuverlässiger, und ich behalte die volle Kontrolle über den Prozess. Für die Installation und Deinstallation von Programmen verwende ich Pamac, besonders bei AUR-Paketen.

Mit der Zeit entwickelt sich sicher ein eigenes Gefühl dafür, welches Werkzeug in welcher Situation besser liegt. Beide sind hervorragende Werkzeuge, und die Kombination aus beiden macht die Paketverwaltung unter Manjaro besonders mächtig und flexibel.

Feature-Vergleich Pacman vs. Pamac

Manjaro Paket Repositories

Die Paketverwaltung unter Manjaro basiert auf einem mehrschichtigen System verschiedener Quellen. Jede dieser Quellen hat ihre eigene Funktion und ihren Platz im Ökosystem. Hier die wichtigsten Repositories und Formate, die für die Arbeit mit Pacman und Pamac relevant sind.

Um 99% der Benutzeranforderungen abzudecken, reicht das Manjaro und das Flatpak Repository.

Das offizielle Manjaro Repository

Manjaro verwendet eigene, spezialisierte Software-Repositories, um dauerhafte Stabilität und Zuverlässigkeit zu gewährleisten. Ein grundlegender Punkt ist, dass Manjaro-Systeme keinen Zugriff auf die offiziellen Arch-Repositories haben. Stattdessen werden Softwarepakete aus den Arch-Quellen zunächst umfassend getestet und gegebenenfalls angepasst, bevor sie in die eigenen, stabilen Repositories von Manjaro übernommen werden.

Die Manjaro-Entwickler unterteilen ihre offiziellen Quellen in drei Zweige mit unterschiedlichen Stabilitätsstufen:

Der Stable-Zweig stellt die Standard-Repositories für die Allgemeinheit dar. Diese Pakete haben mehrere Teststufen durchlaufen und gelten als ausgereift und sicher für den täglichen Einsatz.

Der Testing-Zweig dient als Testumgebung für Pakete, die von den Manjaro-Entwicklern gebaut wurden. Dazu gehören Kernel, Kernelmodule, Nvidia-Grafiktreiber, Software-Patches und eigene Manjaro-Anwendungen. Diese Pakete werden hier auf mögliche Fehler und Stabilitätsprobleme überprüft, bevor sie in den Stable-Zweig gelangen. Dieser Zweig richtet sich an erfahrene Nutzer, die zur Verbesserung von Manjaro beitragen möchten.

Der Unstable-Zweig wird mehrmals täglich mit den stabilen Arch-Repositories synchronisiert. Pakete aus Arch gelten grundsätzlich als stabil, da sie von der Archlinux-QA und der Community geprüft wurden. Hier finden sich die neuesten Versionen von Kerneln, Kernelmodulen, Nvidia-Treibern und Manjaro-eigenen Anwendungen. Die Nutzung dieses Zweigs kann zu Problemen führen und ist nur für versierte Anwender geeignet, die kleinere Probleme selbst lösen können.

Eine Konsequenz dieses Testprozesses ist, dass Manjaro nie ganz so aktuell ist wie Arch Linux. Software kann Tage, Wochen oder unter Umständen sogar Monate später im Stable-Zweig erscheinen. Nutzer, die immer die neuesten Versionen wünschen, können auf den Testing- oder Unstable-Zweig wechseln.

Das Arch User Repository (AUR)

Das AUR ist ein von der Arch-Linux-Benutzergemeinschaft selbst verwaltetes Repository. Obwohl dieses Repository inoffiziell ist, können Softwarepakete von hier den Weg in das offizielle Community-Repository von Arch Linux finden, wenn sie populär genug werden.

Das AUR ist besonders nützlich, wenn eine Anwendung nicht in den offiziellen Manjaro-Repositories verfügbar ist. Es handelt sich jedoch nicht um ein gewöhnliches Paket-Repository mit vorgefertigten Binärdateien, sondern um eine Sammlung von PKGBUILD-Skripten. Diese Skripte enthalten Anweisungen, um die Software aus dem Quellcode oder von anderen Quellen zu bauen (selbst komplilieren) und für die Installation vorzubereiten.

Die Nutzung des AUR birgt potenzielle Risiken. Da es von der Community gepflegt wird, gibt es keine Garantie für die Funktionstüchtigkeit oder Sicherheit der Pakete. Mögliche Probleme sind:

• Mehrere Versionen desselben Pakets
• Veraltete Pakete
• Beschädigte oder nur teilweise funktionierende Pakete
• Falsch konfigurierte Pakete mit unnötigen oder fehlenden Abhängigkeiten
• In extrem seltenen Fällen bösartige Pakete

Daher sollte vor der Installation eines AUR-Pakets die entsprechende Seite auf der AUR-Website aufgerufen werden, um die Kommentare von Nutzern und Paketentwicklern zu lesen, die wertvolle Warnungen oder Problemlösungen enthalten können. Das Manjaro-Team gewährt für Probleme, die aus AUR-Installationen resultieren, keinen Support. Auch kann es vorkommen, dass AUR-Pakete nach einem Manjaro-Update nicht mehr funktionieren. Mit Pamac lässt sich das AUR in den Einstellungen unter “Drittanbieter” oder “AUR” aktivieren. Für die Installation mit Pamac wird der Befehl pamac build paketname verwendet.

Flatpak

Flatpak ist ein Format zur Verteilung von Anwendungen, das weitgehend unabhängig von der darunterliegenden Linux-Distribution ist. Der Hauptvorteil von Flatpak liegt in der Unabhängigkeit von den Systembibliotheken. Eine Flatpak-Anwendung bringt ihre eigenen Abhängigkeiten mit, was Konflikte mit dem Basissystem vermeidet und oft aktuellere Versionen ermöglicht.

Ein weiterer Vorteil ist die gute Sandbox-Umgebung, die eine Kontrolle der Berechtigungen der Anwendung erlaubt. Der Haupt-Repository für Flatpak-Anwendungen ist Flathub. Die Integration von Flatpak in Manjaro erfolgt über Pamac. In den Einstellungen von Pamac kann unter “Drittanbieter” die Flatpak-Unterstützung aktiviert werden.

Die Zugriffsberechtigung von Flatpakpaketen kann sehr einfach mit dem Programm Flatseal bearbeitet werden. Klassischerweise fehlt z.B. der Zugriff auf die eigenen User Dateien. Um das für alle Flatpak Pakete zu machen, kann das im ersten Eintrag bei Flatseal “All Applications” eingestellt werden. Oder eben bei jedem Paket einzeln.

Snap

Wirklich nur nutzen, wenn es gar keine andere Möglichkeit gibt!

Snap ist ein von Canonical entwickeltes Paketformat, das ähnlich wie Flatpak auf Container-Isolation und Unabhängigkeit vom Basissystem setzt. Um Snap in Manjaro zu nutzen, muss das Paket snapd installiert und der dazugehörige Systemdienst aktiviert werden. Snap-Pakete werden oft über das Snap-Store installiert, können aber auch über die Kommandozeile mit sudo snap install paketname bezogen werden.

Einige Snap-Pakete haben eine strikte Isolation, was den Zugriff auf die Dateisysteme oder bestimmte Geräte einschränken kann. Die Zugriffsrechte kann mit dem Befehl snap verändert werden. Zudem ist die Paketgröße häufig größer als bei vergleichbaren Pacman-Paketen. Auch Snap kann in Pamac aktiviert werden, ebenfalls in den Einstellungen unter “Drittanbieter”.

Repositories aktiveren/deaktivieren

Das Aktivieren benötigt 2 Schritte

Schritt 1 - Konfiguration

Auf der Konsole/im Terminal können die Repositories folgendermaßen aktiviert oder deaktiviert werden. Dazu folgende Datei editieren

sudo vim /etc/pamac.conf

und Folgendes muss eingetragen werden. Oder auskommentiert mit #zum Entfernen.

# Kommentar 

EnableAUR
EnableFlatpak
#EnableSnap

Schritt 2 - Support installieren

AUR-Paketverwaltung

Die Pakete base-devel und git müssen installiert sein

pamac install base-devel git

Installieren

pamac build paketname

Flatpak - Paketverwaltung

pamac install flatpak

flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

Installation mit pamac. Installiert automatisch aus Flatpak, falls verfügbar

pamac install paketname

oder direkt mit flatpak

flatpak install flathub paketname

SNAP - Paketverwaltung

pamac install snapd

sudo systemctl enable --now snapd.socket

Für klassische Snap-Unterstützung

sudo ln -s /var/lib/snapd/snap /snap

Installation von Paketen. Installiert automatisch aus Snap, falls verfügbar

pamac install paketname

Oder direkt über Snap

sudo snap install paketname