thongor77/nmlinuxEinheitliches Netzwerk-Toolkit für Linux — Python 3 + PySide6
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.
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:
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.md und docs/Carte-des-Modules.md — die tatsächliche Struktur des Codes, synchron gehalten mit dem, was ausgeliefert wird.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.
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.
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 |
|---|---|
 |  |
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.sh baut das PyInstaller-Bundle jetzt in einem ubuntu:22.04-Container (via podman) statt auf dem Host, sodass jede eingebettete Binärdatei gegen genau die glibc-Version gelinkt ist, die die AppImage unterstützen muss.build-appimage.sh bündelte Shared Libraries (libz.so.1, libstdc++.so.6, libX11.so.6, libfontconfig.so.1 und 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.