NMLinux · v1.7.14

Универсальный сетевой инструментарий для Linux и macOS — инспекция, подключение, диагностика.

NMLinux — это единый унифицированный графический интерфейс, объединяющий 29 сетевых модулей в одном окне: мониторинг интерфейсов, Wi-Fi, DNS, терминал SSH, просмотр брандмауэра, карта топологии, traceroute и многое другое. Написан с нуля на Python и PySide6 (Qt 6), поддерживает 8 языков интерфейса и не требует внешних зависимостей помимо стандартных системных утилит.

[!NOTE] NMLinux не связан с системным демоном Linux /usr/bin/NetworkManager (NetworkManager от Red Hat/GNOME). NMLinux — это самостоятельный проект, написанный с нуля на Python и PySide6.

Создан с помощью Claude Code (Anthropic) и при участии его автора.

Процесс разработки

NMLinux создаётся с использованием ИИ — в частности, Claude Code — и это нигде в данном репозитории не скрывается. Практически каждый серьёзный программный проект сегодня где-то использует ИИ в своём конвейере, признаётся он в этом или нет. Поэтому вопрос «участвовал ли ИИ» — не самый интересный. Интересный вопрос: есть ли что-то, что ловит ошибки, когда ИИ ошибается?

Вот что для этого есть, если вы предпочитаете проверить, а не верить мне на слово:

162 теста — pytest tests/ -v. Чистая логика плюс несколько реальных тестов виджетов Qt (меню, таблицы), без подмены моками интересных частей.
docs/Decisions-Techniques.md — каждое неочевидное техническое решение, отвергнутые альтернативы и баги (включая внесённые ИИ), которые были найдены и исправлены, с записанным обоснованием.
docs/Architecture.md и docs/Carte-des-Modules.md — фактическая структура кода, синхронизированная с тем, что поставляется.
Проверка согласованности i18n, запускаемая перед каждым релизом, чтобы выявить отсутствующие ключи перевода во всех 8 поддерживаемых языках.

Ничего из этого не существует потому, что ИИ нельзя доверять. Это существует потому, что ничто не должно выпускаться без процесса, который его проверяет — включая написанный вручную код. Судите по результату и по тому, как он проверяется, а не по инструменту, который помог его написать.

Всё же нашли баг? Это полезно, а не стыдно — откройте issue.

Сообщество

GitHub Discussions открыты — делитесь отзывами, предлагайте идеи, задавайте вопросы или просто поздоровайтесь. У автора более 30 лет опыта в инфраструктуре и эксплуатации, и он создал этот инструмент потому, что хорошее, бесплатное и простое программное обеспечение должно существовать и для Linux.

Скриншоты

Скриншоты Linux из v1.2.7 — скриншоты macOS из v1.3.5. Сейчас в приложении 29 модулей и 8 языков интерфейса (FR/EN/ES/DE/IT/PT/JA/ZH).

Linux (KDE)

Панель управления	Топология

Traceroute	Wi-Fi

macOS

Панель управления	Traceroute

Список изменений

v1.7.14 — 2026-09-30

AppImage — исправление падения при запуске, попытка 2: исправление из v1.7.13 (удаление встроенных системных библиотек) оказалось недостаточным — сам встроенный интерпретатор Python (libpython3.14.so.1.0, собранный против glibc 2.44 сборочной машины Arch Linux) всё ещё требовал символы glibc новее, чем есть на тестовой машине каталога AppImageHub (Ubuntu 22.04, glibc 2.35), поэтому AppImage продолжал падать прямо при запуске. Теперь build-appimage.sh собирает пакет PyInstaller внутри контейнера ubuntu:22.04 (через podman), а не на хосте, так что каждый встроенный бинарник слинкован именно с той версией glibc, которую AppImage должен поддерживать.

v1.7.13 — 2026-09-30

AppImage — исправление падения при запуске (неполное, см. v1.7.14): build-appimage.sh включал в пакет разделяемые библиотеки (libz.so.1, libstdc++.so.6, libX11.so.6, libfontconfig.so.1 и другие) прямо из очень свежей glibc сборочной машины Arch Linux. На более старых дистрибутивах AppImage падал сразу при запуске (GLIBC_ABI_DT_RELR' not found), что было выявлено автоматическим тестом каталога AppImageHub. Теперь эти библиотеки удалены из пакета, чтобы AppImage использовал собственные копии хост-системы — это стандартный подход для AppImage.

nmlinux

Популярное