NMLinux · v1.7.12

Ein vereinheitlichtes Netzwerk-Toolkit für Linux und macOS – untersuchen, verbinden, diagnostizieren.

NMLinux ist eine einzige, vereinheitlichte GUI, die 29 Netzwerkmodule in einem Fenster vereint: Schnittstellenüberwachung, WLAN, DNS, SSH-Terminal, Firewall-Ansicht, Topologiekarte, Traceroute und mehr. Von Grund auf in Python und PySide6 (Qt 6) entwickelt, mit 8 Oberflächensprachen und ohne externe Abhängigkeiten über die Standard-Systemwerkzeuge hinaus.

[!NOTE] NMLinux ist nicht mit dem Linux-Systemdaemon /usr/bin/NetworkManager (NetworkManager von Red Hat/GNOME) verwandt. NMLinux ist ein eigenständiges Projekt, das von Grund auf in Python und PySide6 entwickelt wurde.

Entwickelt mit Claude Code (Anthropic) und dem Beitrag seines Autors.

Entwicklungsprozess

NMLinux wird mit KI-Unterstützung entwickelt – konkret mit Claude Code – und das wird in diesem Repo nirgendwo versteckt. Heutzutage nutzt fast jedes ernsthafte Softwareprojekt irgendwo in seiner Pipeline KI, ob es das zugibt oder nicht. Also ist „war KI beteiligt" nicht die interessante Frage. Die interessante Frage ist: Fängt irgendetwas es ab, wenn die KI etwas falsch macht?

Das hier fängt es ab, falls du lieber selbst prüfst, als mir aufs Wort zu glauben:

162 Tests — pytest tests/ -v. Reine Logik plus eine Handvoll echter Qt-Widget-Tests (Menüs, Tabellen), ohne die interessanten Teile wegzumocken.
docs/Decisions-Techniques.md — jede nicht offensichtliche technische Entscheidung, die verworfenen Alternativen und die gefundenen und behobenen Fehler (einschließlich KI-bedingter) – mit dokumentierter Begründung.
docs/Architecture.md und docs/Carte-des-Modules.md — die tatsächliche Struktur des Codes, synchron gehalten mit dem, was ausgeliefert wird.
Ein i18n-Konsistenzcheck, der vor jedem Release läuft, um fehlende Übersetzungsschlüssel in den 8 unterstützten Sprachen zu finden.

Nichts davon existiert, weil KI nicht vertrauenswürdig wäre. Es existiert, weil nichts veröffentlicht werden sollte, ohne einen Prozess, der es prüft – handgeschriebener Code eingeschlossen. Beurteile das Ergebnis und wie es verifiziert wird, nicht das Werkzeug, das beim Schreiben geholfen hat.

Trotzdem einen Fehler gefunden? Das ist nützlich, nicht peinlich – eröffne ein Issue.

Community

GitHub Discussions sind geöffnet — teile Feedback, melde Ideen, stelle Fragen oder sag einfach Hallo. Der Autor hat über 30 Jahre Erfahrung in Infrastruktur und Betrieb und hat dieses Werkzeug entwickelt, weil gute, kostenlose und einfache Software auch für Linux existieren sollte.

Screenshots

Linux-Screenshots aus v1.2.7 – macOS-Screenshots aus v1.3.5. Die App hat jetzt 29 Module und 8 Oberflächensprachen (FR/EN/ES/DE/IT/PT/JA/ZH).

Linux (KDE)

Dashboard	Topologie

Traceroute	WLAN

macOS

Dashboard	Traceroute

Änderungsprotokoll

v1.7.12 — 2026-08-12

Traceroute – Korrektur: Unter Flatpak (v1.7.11, siehe unten – inzwischen entfernt) wurde traceroute über den Host-Shim immer auf PATH aufgelöst, selbst wenn auf dem Host kein echtes traceroute-Binärprogramm installiert war; daher griff der Worker nie auf tracepath zurück und die Trace endete sofort ohne Hops und ohne angezeigten Fehler. Jetzt wird immer dann auf tracepath zurückgegriffen, wenn traceroute keinerlei auswertbare Ausgabe erzeugt – unabhängig davon, warum es fehlgeschlagen ist.
SSH-Terminal – Askpass-Korrektur: Wenn DISPLAY/WAYLAND_DISPLAY gesetzt sind (jede GUI-Sitzung) und ssh kein sauberes tty hat, kann es für die Passwortabfrage $SSH_ASKPASS statt des eingebetteten Terminals verwenden – was die Authentifizierung stillschweigend scheitern lässt, wenn kein Askpass-Helfer installiert ist. SSH_ASKPASS_REQUIRE=never erzwingt nun, dass Passwortabfragen immer über das Terminal selbst laufen.
Flatpak-Paketierung entfernt: Das in v1.7.11 mitgelieferte lokale KDE-Linux-Manifest wird nicht weitergeführt. Die Untersuchung des obigen SSH-Passwortabfrage-Fehlers deckte eine Kernel-Grenze auf: Ein Prozess, der über flatpak-spawn --host vermittelt wird, kann niemals Eigentümer des Steuerterminals des weitergeleiteten pty werden (TIOCSCTTY wird mit EPERM verweigert – eine andere, nicht verwandte Sitzung besitzt es bereits; das ist eine beabsichtigte Kernel-Sicherheitsgrenze, kein Fehler). Der einzige funktionierende Workaround (script, das ein frisches pty anlegt) behebt die Passwortabfrage, bricht aber die Live-Größenänderungs-Weitergabe des Terminals für diese Sitzung – ein schlechterer Kompromiss, als auf Flatpak ganz zu verzichten. AUR und das AppImage sind künftig die unterstützten Linux-Installationswege.

v1.7.11 — 2026-08-03

Flatpak-Paketierung (KDE Linux): Ein lokales Build-Manifest unter packaging/flatpak/ zielt auf KDE Linux und andere reine Flatpak-Distributionen. Host-CLI-Werkzeuge, die nmlinux extern aufruft (nmcli, pkexec, mount.cifs, ssh, nmap, …), werden über flatpak-spawn --host-Shims auf PATH angebunden, statt einzeln zu sandboxen; PySide6 stammt von Flathubs io.qt.PySide.BaseApp statt vom PyPI-Rad. Nicht auf Flathub veröffentlicht – stattdessen wird ein einzelnes .flatpak-Bundle mit packaging/flatpak/build-bundle.sh erstellt und wie bereits beim AppImage jedem Release beigefügt. In v1.7.12 eingestellt – siehe oben.

nmlinux v1.7.11