
nmlinux v1.7.11
Einheitliches Netzwerk-Toolkit für Linux — Python 3 + PySide6
NMLinux · v1.7.14
Ein einheitliches Netzwerk-Toolkit für Linux und macOS — inspizieren, verbinden, diagnostizieren.
NMLinux ist eine einzige, einheitliche GUI, die 29 Netzwerkmodule in einem Fenster vereint: Interface-Überwachung, Wi-Fi, DNS, SSH-Terminal, Firewall-Viewer, Topologie-Karte, Traceroute und mehr. Von Grund auf in Python und PySide6 (Qt 6) entwickelt, mit 8 Oberflächensprachen und keinen externen Abhängigkeiten außer Standard-Systemtools.
[!NOTE] NMLinux steht in keiner Verbindung zum Linux-Systemdaemon
/usr/bin/NetworkManager(NetworkManager von Red Hat/GNOME). NMLinux ist ein eigenständiges Projekt, das von Grund auf in Python und PySide6 entwickelt wurde.
Entwickelt mit Claude Code (Anthropic) und der Mitwirkung seines Autors.
Entwicklungsprozess
NMLinux wird mit KI-Unterstützung entwickelt — konkret mit Claude Code — und das wird in diesem Repo nirgends verheimlicht. Heutzutage nutzt fast jedes ernsthafte Softwareprojekt irgendwo in seiner Pipeline KI, ob es das zugibt oder nicht. Die Frage „war KI beteiligt" ist also nicht die interessante. Die interessante Frage ist: Fällt es auf, wenn die KI etwas falsch macht?
Hier ist, was das tut, falls Sie lieber nachprüfen möchten, statt mir einfach 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 Bugs (einschließlich der von KI eingeführten), mit schriftlich festgehaltener Begründung.docs/Architecture.mdunddocs/Carte-des-Modules.md— die tatsächliche Struktur des Codes, synchron gehalten mit dem, was ausgeliefert wird.- Eine i18n-Konsistenzprüfung, die vor jedem Release ausgeführt wird, um fehlende Übersetzungsschlüssel über die 8 unterstützten Sprachen hinweg aufzuspüren.
Nichts davon existiert, weil der KI nicht zu trauen wäre. Es existiert, weil nichts ausgeliefert werden sollte, ohne dass ein Prozess es prüft — handgeschriebener Code eingeschlossen. Beurteilen Sie das Ergebnis und wie es verifiziert wird, nicht das Tool, das beim Schreiben geholfen hat.
Trotzdem einen Bug gefunden? Das ist nützlich, nicht peinlich — eröffnen Sie ein Issue.
Community
GitHub Discussions sind offen — teilen Sie Feedback, melden Sie Ideen, stellen Sie Fragen oder sagen Sie einfach Hallo. Der Autor hat über 30 Jahre Erfahrung in Infrastruktur und Betrieb und hat dieses Tool gebaut, weil es auch für Linux gute, freie und einfache Software geben 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 | Wi-Fi |
|---|---|
![]() | ![]() |
macOS
| Dashboard | Traceroute |
|---|---|
![]() | ![]() |
Changelog
v1.7.14 — 2026-09-30
- AppImage — Startabsturz behoben, zweiter Versuch: Der Fix aus v1.7.13 (Entfernen gebündelter Systembibliotheken) reichte nicht aus — der eingebettete Python-Interpreter selbst (
libpython3.14.so.1.0, gebaut gegen die glibc 2.44 der Arch-Linux-Entwicklungsmaschine) benötigte weiterhin glibc-Symbole, die neuer sind als die der Testmaschine des AppImageHub-Katalogs (Ubuntu 22.04, glibc 2.35), sodass die AppImage weiterhin direkt beim Start abstürzte.build-appimage.shbaut das PyInstaller-Bundle jetzt in einemubuntu:22.04-Container (viapodman) statt auf dem Host, sodass jede eingebettete Binärdatei gegen genau die glibc-Version gelinkt ist, die die AppImage unterstützen muss.
v1.7.13 — 2026-09-30
- AppImage — Startabsturz behoben (unvollständig, siehe v1.7.14):
build-appimage.shbündelte Shared Libraries (libz.so.1,libstdc++.so.6,libX11.so.6,libfontconfig.so.1und andere) direkt aus der sehr aktuellen glibc der Arch-Linux-Build-Maschine. Auf älteren Distributionen stürzte die AppImage sofort beim Start ab (GLIBC_ABI_DT_RELR' not found), erkannt durch den automatisierten Test des AppImageHub-Katalogs. Diese Bibliotheken werden jetzt aus dem Bundle entfernt, sodass die AppImage auf die eigenen Kopien des Host-Systems zurückgreift — der Standardansatz für AppImages.





