Back to updates
New releaseAug 3, 2026

nmlinux v1.7.9

Unified network toolkit for Linux — Python 3 + PySide6

Share

NMLinux · v1.7.12

Version Python License: GPL-2.0 Platform Languages Donate Bitcoin

A unified network toolkit for Linux and macOS — inspect, connect, diagnose.

NMLinux is a single, unified GUI that brings together 29 network modules in one window: interface monitoring, Wi-Fi, DNS, SSH terminal, firewall viewer, topology map, traceroute, and more. Built from scratch in Python and PySide6 (Qt 6), with 8 interface languages and no external dependencies beyond standard system tools.

[!NOTE] NMLinux is not related to the Linux system daemon /usr/bin/NetworkManager (NetworkManager by Red Hat/GNOME). NMLinux is a standalone project built from scratch in Python and PySide6.

Built with Claude Code (Anthropic) and the contribution of its author.


Development process

NMLinux is built with AI assistance — Claude Code, specifically — and that's not hidden anywhere in this repo. Almost every serious software project today uses AI somewhere in its pipeline, whether it says so or not. So "was AI involved" isn't the interesting question. The interesting question is: does anything catch it when the AI gets something wrong?

Here's what does, if you'd rather check than take my word for it:

  • 162 tests — pytest tests/ -v. Pure logic plus a handful of real Qt widget tests (menus, tables), no mocking away the interesting parts.
  • docs/Decisions-Techniques.md — every non-obvious technical call, the alternatives that got rejected, and the bugs (including AI-introduced ones) that were found and fixed, with the reasoning written down.
  • docs/Architecture.md and docs/Carte-des-Modules.md — the actual structure of the code, kept in sync with what ships.
  • An i18n consistency check run before every release to catch missing translation keys across the 8 supported languages.

None of that exists because AI can't be trusted. It exists because nothing should ship without a process that checks it — hand-written code included. Judge the output and how it's verified, not the tool that helped write it.

Found a bug anyway? That's useful, not embarrassing — open an issue.


Community

GitHub Discussions are open — share feedback, report ideas, ask questions, or just say hello. The author has 30+ years in infrastructure and operations, and built this tool because good, free, and simple software should exist for Linux too.


Screenshots

Linux screenshots from v1.2.7 — macOS screenshots from v1.3.5. The app now has 29 modules and 8 interface languages (FR/EN/ES/DE/IT/PT/JA/ZH).

Linux (KDE)

DashboardTopology
DashboardTopology
TracerouteWi-Fi
TracerouteWi-Fi

macOS

DashboardTraceroute
macOS DashboardmacOS Traceroute

Changelog

v1.7.12 — 2026-08-12

  • Traceroute — fix: under Flatpak (v1.7.11, see below — now removed), traceroute always resolved on PATH via the host shim even when the host had no real traceroute binary installed, so the worker never fell back to tracepath and the trace finished instantly with no hops and no error shown. It now falls back to tracepath whenever traceroute produces no parseable output at all, regardless of why it failed.
  • SSH terminal — askpass fix: when DISPLAY/WAYLAND_DISPLAY are set (any GUI session) and ssh doesn't have a clean tty, it can try $SSH_ASKPASS for the password prompt instead of the embedded terminal — silently failing auth if no askpass helper is installed. SSH_ASKPASS_REQUIRE=never now forces password prompts to always go through the terminal itself.
  • Flatpak packaging removed: the local KDE Linux manifest shipped in v1.7.11 is discontinued. Investigating the SSH password-prompt bug above surfaced a kernel-level limitation: a process relayed via flatpak-spawn --host can never become the controlling-terminal owner of the forwarded pty (TIOCSCTTY refused with EPERM — a different, unrelated session already owns it; this is an intentional kernel security boundary, not a bug). The only working around (script, allocating a fresh pty) fixes the password prompt but breaks live terminal-resize propagation for that session — judged a worse trade-off than not shipping Flatpak at all. AUR and the AppImage are the supported Linux install paths going forward.

v1.7.11 — 2026-08-03

  • Flatpak packaging (KDE Linux): a local build manifest under packaging/flatpak/ targets KDE Linux and other Flatpak-only distros. Host CLI tools nmlinux shells out to (nmcli, pkexec, mount.cifs, ssh, nmap, …) are bridged via flatpak-spawn --host shims on PATH instead of sandboxing each one individually; PySide6 comes from Flathub's io.qt.PySide.BaseApp rather than the PyPI wheel. Not published on Flathub — a single .flatpak bundle is built with packaging/flatpak/build-bundle.sh and attached to each release instead, the same way the AppImage already is. Discontinued in v1.7.12 — see above.

v1.7.10 — 2026-08-03

  • SSH terminal — fix: fixed a race condition where the PTY could start at the wrong (default 24×80) size if the terminal widget's actual size wasn't known yet when the session launched, silently dropping the resize request. This desynced remote full-screen apps (e.g. Claude Code CLI, htop, vim) from the real window size, causing stale/leftover text at the bottom of the screen that only cleared as new output scrolled past it. Reported by the user; reproduced with a real interactive session

v1.7.9 — 2026-08-02

Categories