
مجموعة أدوات شبكات موحدة لنظام لينكس — Python 3 + PySide6
مجموعة أدوات شبكة موحّدة لنظامي 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 تحديدًا — وهذا الأمر غير مخفي في أي مكان بهذا المستودع. تكاد كل مشروع برمجي جاد اليوم يستخدم الذكاء الاصطناعي في مكان ما ضمن مساره، سواء أعلن ذلك أم لا. لذا فإن سؤال "هل كان للذكاء الاصطناعي دور" ليس السؤال المثير للاهتمام. السؤال المثير للاهتمام هو: هل هناك ما يكتشف الأخطاء عندما يخطئ الذكاء الاصطناعي؟
إليك ما يكتشفها، إن كنت تفضّل التحقق بدلًا من الأخذ بكلامي:
pytest tests/ -v. منطق خالص بالإضافة إلى حفنة من اختبارات عناصر Qt الحقيقية (القوائم، الجداول)، دون تمويه الأجزاء المهمة.docs/Decisions-Techniques.md — كل قرار تقني غير بديهي، والبدائل التي رُفضت، والأخطاء (بما فيها تلك التي أدخلها الذكاء الاصطناعي) التي اكتُشفت وأُصلحت، مع تدوين المنطق وراءها.docs/Architecture.md و**docs/Carte-des-Modules.md** — البنية الفعلية للشيفرة، مُحدَّثة بما يتوافق مع ما يُصدَر فعليًا.لا شيء من ذلك موجود لأن الذكاء الاصطناعي غير موثوق. بل هو موجود لأنه لا ينبغي إصدار أي شيء دون عملية تتحقق منه — بما في ذلك الشيفرة المكتوبة يدويًا. احكم على المخرجات وكيفية التحقق منها، لا على الأداة التي ساعدت في كتابتها.
هل وجدت خطأً رغم ذلك؟ هذا مفيد، وليس محرجًا — افتح تذكرة.
مناقشات GitHub مفتوحة — شارك ملاحظاتك، أو أبلغ عن أفكار، أو اطرح أسئلة، أو قل مرحبًا فقط. لدى المؤلف أكثر من 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 |
|---|---|
![]() | ![]() |
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 إلى دعمه.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 إلى نسخ نظام المضيف نفسه، وهو النهج القياسي لـ AppImages.traceroute يُحلّ دائمًا عبر PATH من خلال واجهة المضيف حتى عندما لم يكن لدى المضيف ثنائية traceroute حقيقية مثبَّتة، فلم يعد العامل أبدًا إلى tracepath وانتهى التتبع فورًا دون قفزات ودون عرض أي خطأ. الآن يعود إلى tracepath كلما لم يُنتج traceroute أي مخرجات قابلة للتحليل على الإطلاق، بغض النظر عن سبب فشله.DISPLAY/WAYLAND_DISPLAY مضبوطة (أي جلسة رسومية) ولا يمتلك ssh طرفية نظيفة، فقد يحاول استخدام $SSH_ASKPASS لمطالبة كلمة المرور بدلًا من الطرفية المضمَّنة — مما يفشل في المصادقة بصمت إن لم يكن مساعد askpass مثبَّتًا. الآن يفرض SSH_ASKPASS_REQUIRE=never مرور مطالبات كلمة المرور دائمًا عبر الطرفية نفسها.flatpak-spawn --host أن تصبح أبدًا مالك الطرفية المتحكِّمة للـ pty المُمرَّر (TIOCSCTTY مرفوض بـ EPERM — جلسة أخرى مختلفة وغير ذات صلة تملكه بالفعل؛ هذا حد أمني مقصود في النواة وليس خطأً). الحل الوحيد العامل (script، بتخصيص pty جديد) يصلح مطالبة كلمة المرور لكنه يكسر نشر تغيير حجم الطرفية الحيّ لتلك الجلسة — ورُئي أنه مقايضة أسوأ من عدم شحن Flatpak إطلاقًا. AUR و AppImage هما مسارا التثبيت المدعومان على Linux من الآن فصاعدًا.packaging/flatpak/ يستهدف KDE Linux وتوزيعات Flatpak فقط الأخرى. تُجسَّر أدوات سطر الأوامر الخاصة بالمضيف التي يستدعيها nmlinux (nmcli، pkexec، mount.cifs، ssh، nmap، …) عبر واجهات flatpak-spawn --host على PATH بدلًا من عزل كل واحدة منها على حدة؛ يأتي PySide6 من io.qt.PySide.BaseApp الخاص بـ Flathub بدلًا من حزمة PyPI. غير منشور على Flathub — تُبنى حزمة .flatpak واحدة عبر packaging/flatpak/build-bundle.sh وتُرفق بكل إصدار بدلًا من ذلك، بالطريقة نفسها التي يُرفق بها AppImage بالفعل. أُوقف في v1.7.12 — انظر أعلاه.