
Toolkit de rede unificado para Linux — Python 3 + PySide6
Um kit de ferramentas de rede unificado para Linux e macOS — inspecione, conecte, diagnostique.
NMLinux é uma GUI única e unificada que reúne 29 módulos de rede em uma só janela: monitoramento de interfaces, Wi-Fi, DNS, terminal SSH, visualizador de firewall, mapa de topologia, traceroute e muito mais. Construído do zero em Python e PySide6 (Qt 6), com 8 idiomas de interface e sem dependências externas além das ferramentas padrão do sistema.
[!NOTE] O NMLinux não tem relação com o daemon do sistema Linux
/usr/bin/NetworkManager(NetworkManager da Red Hat/GNOME). O NMLinux é um projeto independente construído do zero em Python e PySide6.
Construído com Claude Code (Anthropic) e a contribuição de seu autor.
O NMLinux é construído com assistência de IA — Claude Code, especificamente — e isso não está escondido em nenhum lugar deste repositório. Quase todo projeto de software sério hoje usa IA em algum ponto do seu pipeline, quer admita ou não. Então "a IA esteve envolvida" não é a pergunta interessante. A pergunta interessante é: existe algo que a detecte quando a IA erra?
Aqui está o que existe, caso você prefira verificar em vez de acreditar na minha palavra:
pytest tests/ -v. Lógica pura mais alguns testes reais de widgets Qt (menus, tabelas), sem simular as partes interessantes.docs/Decisions-Techniques.md — cada decisão técnica não óbvia, as alternativas que foram rejeitadas e os bugs (incluindo os introduzidos por IA) que foram encontrados e corrigidos, com o raciocínio documentado.docs/Architecture.md e docs/Carte-des-Modules.md — a estrutura real do código, mantida em sincronia com o que é distribuído.Nada disso existe porque a IA não é confiável. Existe porque nada deveria ser lançado sem um processo que o verifique — incluindo código escrito à mão. Julgue o resultado e como ele é verificado, não a ferramenta que ajudou a escrevê-lo.
Encontrou um bug mesmo assim? Isso é útil, não vergonhoso — abra uma issue.
As GitHub Discussions estão abertas — compartilhe feedback, reporte ideias, faça perguntas ou apenas diga olá. O autor tem mais de 30 anos em infraestrutura e operações, e construiu esta ferramenta porque software bom, gratuito e simples também deveria existir para Linux.
Capturas de tela do Linux da v1.2.7 — capturas de tela do macOS da v1.3.5. O aplicativo agora tem 29 módulos e 8 idiomas de interface (FR/EN/ES/DE/IT/PT/JA/ZH).
Linux (KDE)
| Dashboard | Topologia |
|---|---|
![]() | ![]() |
| Traceroute | Wi-Fi |
|---|---|
![]() | ![]() |
macOS
| Dashboard | Traceroute |
|---|---|
![]() | ![]() |
libpython3.14.so.1.0, compilado contra a glibc 2.44 da máquina de desenvolvimento Arch Linux) ainda exigia símbolos da glibc mais recentes do que os disponíveis na máquina de teste do catálogo AppImageHub (Ubuntu 22.04, glibc 2.35), então o AppImage continuava travando logo na inicialização. O build-appimage.sh agora compila o pacote PyInstaller dentro de um contêiner ubuntu:22.04 (via podman) em vez de no host, para que cada binário embutido seja vinculado exatamente à versão da glibc que o AppImage precisa suportar.build-appimage.sh estava empacotando bibliotecas compartilhadas (libz.so.1, libstdc++.so.6, libX11.so.6, libfontconfig.so.1 e outras) diretamente da glibc muito recente da máquina de compilação Arch Linux. Em distribuições mais antigas, o AppImage travava imediatamente na inicialização (GLIBC_ABI_DT_RELR' not found), detectado pelo teste automatizado do catálogo AppImageHub. Essas bibliotecas agora são removidas do pacote para que o AppImage use as cópias do próprio sistema hospedeiro, que é a abordagem padrão para AppImages.