thongor77/nmlinuxKit de herramientas de red unificado para Linux — Python 3 + PySide6
Un conjunto de herramientas de red unificado para Linux y macOS — inspecciona, conecta, diagnostica.
NMLinux es una única interfaz gráfica unificada que reúne 29 módulos de red en una sola ventana: monitorización de interfaces, Wi-Fi, DNS, terminal SSH, visor de cortafuegos, mapa de topología, traceroute y más. Construido desde cero en Python y PySide6 (Qt 6), con 8 idiomas de interfaz y sin dependencias externas más allá de las herramientas estándar del sistema.
[!NOTE] NMLinux no está relacionado con el demonio del sistema Linux
/usr/bin/NetworkManager(NetworkManager de Red Hat/GNOME). NMLinux es un proyecto independiente construido desde cero en Python y PySide6.
Construido con Claude Code (Anthropic) y la contribución de su autor.
NMLinux se construye con asistencia de IA — Claude Code, concretamente — y eso no se oculta en ningún lugar de este repositorio. Casi todos los proyectos de software serios hoy en día usan IA en algún punto de su flujo de trabajo, lo digan o no. Así que "¿hubo IA involucrada?" no es la pregunta interesante. La pregunta interesante es: ¿hay algo que lo detecte cuando la IA se equivoca?
Esto es lo que lo hace, si prefieres comprobarlo en lugar de creerme:
pytest tests/ -v. Lógica pura más un puñado de tests reales de widgets Qt (menús, tablas), sin simular las partes interesantes.docs/Decisions-Techniques.md — cada decisión técnica no obvia, las alternativas que se descartaron y los errores (incluidos los introducidos por IA) que se encontraron y corrigieron, con el razonamiento documentado.docs/Architecture.md y docs/Carte-des-Modules.md — la estructura real del código, mantenida en sincronía con lo que se publica.Nada de eso existe porque no se pueda confiar en la IA. Existe porque nada debería publicarse sin un proceso que lo verifique — incluido el código escrito a mano. Juzga el resultado y cómo se verifica, no la herramienta que ayudó a escribirlo.
¿Encontraste un error de todas formas? Eso es útil, no vergonzoso — abre una incidencia.
GitHub Discussions está abierto — comparte comentarios, reporta ideas, haz preguntas o simplemente saluda. El autor tiene más de 30 años de experiencia en infraestructura y operaciones, y construyó esta herramienta porque también debería existir software bueno, gratuito y sencillo para Linux.
Capturas de Linux de la v1.2.7 — capturas de macOS de la v1.3.5. La aplicación ahora tiene 29 módulos y 8 idiomas de interfaz (FR/EN/ES/DE/IT/PT/JA/ZH).
Linux (KDE)
| Panel | Topología |
|---|---|
 |  |
| Traceroute | Wi-Fi |
|---|---|
 |  |
macOS
| Panel | Traceroute |
|---|---|
 |  |
libpython3.14.so.1.0, compilado contra la glibc 2.44 de la máquina de desarrollo con Arch Linux) seguía requiriendo símbolos de glibc más recientes que los que tiene la máquina de pruebas del catálogo de AppImageHub (Ubuntu 22.04, glibc 2.35), por lo que el AppImage seguía fallando justo al arrancar. build-appimage.sh ahora construye el paquete de PyInstaller dentro de un contenedor ubuntu:22.04 (mediante podman) en lugar de en el host, de modo que cada binario embebido se enlaza exactamente contra la versión de glibc que el AppImage necesita soportar.build-appimage.sh estaba incluyendo bibliotecas compartidas (libz.so.1, libstdc++.so.6, libX11.so.6, libfontconfig.so.1 y otras) directamente desde la glibc muy reciente de la máquina de compilación con Arch Linux. En distribuciones más antiguas el AppImage fallaba inmediatamente al arrancar (GLIBC_ABI_DT_RELR' not found), detectado por la prueba automatizada del catálogo de AppImageHub. Estas bibliotecas ahora se eliminan del paquete para que el AppImage recurra a las copias propias del sistema anfitrión, que es el enfoque estándar para los AppImage.