thongor77/nmlinuxUnified network toolkit for Linux — Python 3 + PySide6
Un toolkit di rete unificato per Linux e macOS — ispeziona, connetti, diagnostica.
NMLinux è un'unica GUI unificata che riunisce 29 moduli di rete in una sola finestra: monitoraggio delle interfacce, Wi-Fi, DNS, terminale SSH, visualizzatore del firewall, mappa della topologia, traceroute e altro ancora. Costruito da zero in Python e PySide6 (Qt 6), con 8 lingue dell'interfaccia e nessuna dipendenza esterna oltre agli strumenti di sistema standard.
[!NOTE] NMLinux non è correlato al demone di sistema Linux
/usr/bin/NetworkManager(NetworkManager di Red Hat/GNOME). NMLinux è un progetto autonomo costruito da zero in Python e PySide6.
Costruito con Claude Code (Anthropic) e il contributo del suo autore.
NMLinux è costruito con l'assistenza dell'IA — Claude Code, nello specifico — e questo non è nascosto da nessuna parte in questo repo. Quasi ogni progetto software serio oggi utilizza l'IA da qualche parte nella sua pipeline, che lo dichiari o no. Quindi "l'IA è stata coinvolta" non è la domanda interessante. La domanda interessante è: c'è qualcosa che lo intercetta quando l'IA sbaglia qualcosa?
Ecco cosa lo fa, se preferisci verificare piuttosto che credermi sulla parola:
pytest tests/ -v. Logica pura più una manciata di test reali sui widget Qt (menu, tabelle), senza fare mocking delle parti interessanti.docs/Decisions-Techniques.md — ogni scelta tecnica non ovvia, le alternative scartate e i bug (inclusi quelli introdotti dall'IA) che sono stati trovati e corretti, con il ragionamento messo per iscritto.docs/Architecture.md e docs/Carte-des-Modules.md — la struttura effettiva del codice, mantenuta sincronizzata con ciò che viene distribuito.Niente di tutto ciò esiste perché l'IA non è affidabile. Esiste perché nulla dovrebbe essere distribuito senza un processo che lo verifichi — incluso il codice scritto a mano. Giudica l'output e come viene verificato, non lo strumento che ha aiutato a scriverlo.
Hai comunque trovato un bug? È utile, non imbarazzante — apri una issue.
Le GitHub Discussions sono aperte — condividi feedback, segnala idee, fai domande o semplicemente saluta. L'autore ha oltre 30 anni di esperienza in infrastrutture e operations, e ha costruito questo strumento perché un software buono, gratuito e semplice dovrebbe esistere anche per Linux.
Screenshot Linux dalla v1.2.7 — screenshot macOS dalla v1.3.5. L'app ora ha 29 moduli e 8 lingue dell'interfaccia (FR/EN/ES/DE/IT/PT/JA/ZH).
Linux (KDE)
| Dashboard | Topology |
|---|---|
 |  |
| Traceroute | Wi-Fi |
|---|---|
 |  |
macOS
| Dashboard | Traceroute |
|---|---|
 |  |
libpython3.14.so.1.0, compilato contro la glibc 2.44 della macchina di sviluppo Arch Linux) richiedeva ancora simboli glibc più recenti di quelli disponibili sulla macchina di test del catalogo AppImageHub (Ubuntu 22.04, glibc 2.35), quindi l'AppImage continuava a bloccarsi proprio all'avvio. build-appimage.sh ora compila il bundle PyInstaller all'interno di un container ubuntu:22.04 (tramite podman) invece che sull'host, così ogni binario incorporato è linkato esattamente alla versione di glibc che l'AppImage deve supportare.build-appimage.sh includeva nel bundle librerie condivise (libz.so.1, libstdc++.so.6, libX11.so.6, libfontconfig.so.1 e altre) direttamente dalla glibc molto recente della macchina di build Arch Linux. Su distribuzioni più vecchie l'AppImage si bloccava immediatamente all'avvio (GLIBC_ABI_DT_RELR' not found), rilevato dal test automatizzato del catalogo AppImageHub. Queste librerie ora vengono rimosse dal bundle, così l'AppImage utilizza le copie proprie del sistema host, che è l'approccio standard per le AppImage.