با چه روشی تو سیستم لینوکسی خودمون برنامه نصب کنیم؟

[seyal]

اوایل همیشه این سوال فکرم رو درگیر می‌کرد که از بین این‌همه روش مختلف برای نصب برنامه در لینوکس، بالاخره کدوم رو باید انتخاب کنم؟ نسخه مخازن رسمی، فلت‌پک (Flatpak)، اسنپ (Snap)، دیستتروباکس (Distrobox) یا روش‌های دیگه؟ اصلاً چرا باید این‌همه تنوع در روش‌های نصب نرم‌افزار وجود داشته باشه؟
بعد از کلی آزمایش، دست‌کاری سیستم و خوندن فروم‌ها و مقالات مختلف، بالاخره تونستم به یک دسته‌بندی و نتیجه‌گیری منطقی برسم که می‌خوام تو این مقاله باهاتون به اشتراک بذارم.

اصل طلایی: سیستم رو خراب نکنید! (Don't Break Debian)
قبل از بررسی روش‌ها، باید مهم‌ترین اصل بازی رو یاد بگیریم؛ اصلی که تو ویکی دبیان به زیبایی با عنوان «دبیان را خراب نکنید!» (Don't Break Debian) اومده. این قانون فقط مخصوص دبیان نیست و شامل حال تمام توزیع‌ها میشه.
وقتی از سیستم‌عامل به صورت روزمره استفاده می‌کنید، هماهنگی پکیج‌ها و عدم تداخلشون حرف اول رو میزنه. به عبارت ساده‌تر: ما هرگز کمی بروزتر بودن رو فدای break شدن (از کار افتادن) سیستم نمیکنیم.
یکی از مهم‌ترین عادت‌های یک کاربر یا توسعه‌دهنده موفق لینوکس، احترام به پایداری سیستم اصلیه. اگر پکیج اضافه‌ای از یک مخزن خاص می‌خواید یا کاربردهای ویژه‌ای مد نظرتونه، به جای دست‌کاری و ناپایدار کردن سیستم‌عامل پایه، باید سراغ راه‌حل‌های ایزوله مثل Distrobox (که مثل داکر اما برای زیرسیستم شخصی عمل می‌کنه)، Flatpak و... برید. همیشه اول باید بتونید برنامه رو روی یک نسخه پایدار بسازید و اجرا کنید، بعد در صورت نیاز اون رو به نسخه‌های جدیدتر آپدیت کرده و مطابقت بدید.
با در نظر گرفتن این اصل، بریم سراغ بررسی روش‌های نصب:

۱. مخازن پیش‌فرض توزیع (Official Repositories)
مطمئن‌ترین و بی‌دردسرترین روش، استفاده از پکیج‌منیجر پیش‌فرض خود توزیعه؛ ابزارهایی مثل apt ،dnf یا pacman که هر کدوم معماری و توزیع‌های مشخصی رو پوشش میدن.
کاربرد اصلی: نصب ابزارها و برنامه‌های پایه سیستم (Core Utilities) مثل ادیتورهای متنی، زبان‌های برنامه‌نویسی و ابزارهای سیستمی.
چرا این روش؟ چون برای این ابزارها، پایداری و سازگاری حداکثری با سیستم‌عامل بسیار حیاتی‌تر از «آخرین نسخه بودن» است.
یک نکته مهم: اگر واقعاً برای ابزارهای پایه هم مکرراً به آخرین نسخه نیاز دارید، به جای دست‌کاری مخازن، بهتره کلاً توزیع خودتون رو عوض کنید و سراغ توزیع‌هایی برید که نسخه‌های بروزتر رو رسماً انتشار میدن؛ مثلاً اوبونتو یا فدورا، و اگر باز هم بروزتر می‌خواید، توزیع‌های غلطان (Rolling Release) مثل اوپن‌سوزه تامبلوید (OpenSUSE Tumbleweed) یا آرچ لینوکس (Arch Linux).
پس چرا همه فقط از پکیج‌منیجر توزیع خودشون استفاده نمی‌کنند؟
چون در کنار تمام مزایا، با چند چالش مواجه می‌شیم:
بروز نبودن برخی برنامه‌ها (به دلیل سیاست‌های پایداری توزیع).
محدود بودن برنامه‌های پشتیبانی شده
خطر به‌هم‌ریختن توزیع، کثیف شدن سیستم و بروز مشکل هنگام دریافت و اعمال آپدیت‌ها در صورت افزودن مخازن غیررسمی.
همین مشکلات باعث شد روش‌های جدیدتری توسعه پیدا کنند که در ادامه بررسی می‌کنیم.

۲. مخازن بک‌پورت دبیان (Debian Backports)
اگر از دبیان پایدار (Debian Stable) استفاده می‌کنید، این مخازن پل امنی هستند برای اینکه نرم‌افزارهای انتخابی خودتون رو بروز کنید، بدون اینکه مجبور باشید پایداری کل سیستم رو با رفتن به شاخه‌های Testing یا Unstable به خطربندازید.
سناریوی واقعی: فرض کنید دبیان استیبل رو روی یک سرور یا سیستم سیستم روزمره نصب کردید و همه چیز عالی کار می‌کنه. اما یک کارت گرافیک جدید خریدید که هسته (Kernel) ۲ سال پیشِ دبیان استیبل اون رو نمی‌شناسه!
راه‌حل: به جای ارتقای کل سیستم‌عامل به یک نسخه ناپایدار، مخزن Backports رو فعال می‌کنید.
نحوه کار: توسعه‌دهندگان دبیان، برنامه یا کربل جدید رو از شاخه‌های Testing/Sid می‌گیرند و اون رو با کتابخانه‌های قدیمی و امنِ Debian Stable مجدداً کامپایل می‌کنند.
نتیجه: شما می‌تونید فقط کربل یا مثلاً LibreOffice رو به آخرین نسخه ارتقا بدید، در حالی که ۹۹٪ سیستم‌عامل شما کاملاً دست‌نخورده، دست‌نیافتنی و پایدار باقی می‌مونه.

۳. مخازن شخص ثالث و PPAها (PPA / AUR / Copr)
در اوبونتو با PPA، در آرچ با AUR و در فدورا با Fedora Copr طرف هستیم. این مخازن در نگاه اول بسیار جذاب به نظر می‌رسند، اما استفاده مداوم و بی‌درنگ از اون‌ها دقیقاً اصل اول یعنی «دبیان (سیستم) را خراب نکنید» رو زیر سوال می‌بره.
دیدگاه تجربی من درباره این روش: تا جایی که امکان داره برای نصب پکیج‌ها سراغ Third-partyها نرید و ترکیب پیش‌فرض سیستم‌عامل رو دست‌کاری نکنید؛ چرا که این کار موقع آپدیت، ریکاوری و حفظ امنیت، باگ‌ها و مشکلات غیرمنتظره‌ای ایجاد می‌کنه.
چه زمانی مجاز هستیم؟ فقط زمانی که پکیجی واقعاً ارزشش رو داشته باشه، وابستگی‌ها (Dependencies) و کتابخانه‌های سنگینی به سیستم اضافه نکنه که پایداری رو تهدید کنه، و مهم‌تر از همه بدانید چطور در صورت نیاز تمیز حتماً پاکش کنید (Clean Uninstall).
مثال شخصی: من خودم برای نصب افزونه better blur در محیط KDE یا نصب ابزار starship (برای زیباسازی ترمینال) از این روش استفاده کردم. این روش بیشتر به درد پکیج‌های سبک و خاصی می‌خوره که در مخازن رسمی نیستند و شما به نوعی "فن" اون پکیج هستید!
(نکته: این قابلیت در همه توزیع‌ها یکسان نیست؛ مثلاً در دبیان پایدار مفهوم PPA به شکل اوبونتو وجود نداره).

۴. شاخه‌های تست و ناپایدار (Debian Testing / Sid - Unstable)
تقریباً اکثر توزیع‌ها چنین شاخه‌هایی دارند، اما استفاده از اون‌ها به عنوان پکیج‌منیجر سیستمِ استفاده روزمره (Daily Driver) اصلاً توصیه نمیشه.
چرا دبیان Sid (Unstable) برای استفاده روزمره مناسب نیست؟
مکانیزم کار: وقتی توسعه‌دهنده‌ای نسخه جدیدی از یک نرم‌افزار رو منتشر می‌کنه، اون پکیج ابتدا وارد Sid میشه.
ریسک بالا: Sid هیچ لایه امنیتی یا لایه‌ی تستِ تاخیری نداره. اگر پکیجی با یک باگ بحرانی آپلود بشه که محیط گرافیکی یا روند بوت سیستم رو بشکنه، کاربر Sid همان لحظه اون شکست رو تجربه خواهد کرد!
مشکل دانگرید (Downgrade): اگر در دبیان استیبل مخازن Sid رو فعال و سیستم رو آپگرید کنید، سیستم از حالت اورجینال خارج میشه. فرایند Downgrade هم به طور پیش‌فرض پشتیبانی نمیشه. تنها راه برگشت اینه که یا سیستم رو از نو نصب کنید یا مخازن رو به Stable برگردونید و منتظر بمونید تا نسخه جدید دبیان (هر دو سال یک‌بار!) منتشر بشه تا پکیج‌های پایدار روی پکیج‌های Sid شما Overwrite بشن. البته اگه کسی Sid را وارد Stable کرده باشد، لزوماً با انتشار نسخه بعدی Debian مشکلش حل نمی‌شه و در بسیاری از موارد نصب مجدد سیستم یا عملیات Downgrade پیچیده لازمه.
اگرچه تو فروم‌ها کاربرانی رو می‌بینیم که میگن «من چند ماهه دارم بدون مشکل از Sid استفاده می‌کنم»، اما حقیقت اینه که این شاخه‌ها برای تست‌های اتوماتیک، توسعه‌دهندگان مخازن و کسانی ساخته شده که عاشق نرم‌افزارهای Bleeding-edge هستند و دانش کافی برای رفع مشکلات سیستم از طریق ترمینال رو دارند.

(پایان بخش اول - در بخش بعدی سراغ روش‌های مدرن‌تر مثل Flatpak، Snap، AppImage و Distrobox خواهیم رفت...)

[seyal]

فلت‌پک (Flatpak): برجسته‌ترین گزینه برای کاربر دسکتاپ
از پادشاه برنامه‌های دسکتاپ صحبت کنیم: فلت‌پک (Flatpak).
برای اکثر کاربران دسکتاپ لینوکس، فلت‌پک یکی از بهترین گزینه‌ها برای نصب نرم‌افزارهای گرافیکی است. چه نرم‌افزارهای آزاد و متن‌باز (Open-Source) و چه نرم‌افزارهای اختصاصی (Proprietary).
ممکنه خیلی‌ها اشکال بگیرند که «فلت‌پک فضای زیادی از دیسک رو اشغال می‌کنه». اما واقعیت اینه که مزایای فلت‌پک به قدری زیاده که این عیب رو به چشم نمی‌آره. بعلاوه، هرچقدر برنامه‌های فلت‌پک بیشتری نصب کنید، به دلیل به اشتراک‌گذاری Runtimeهای مشترک بین برنامه‌ها، حجم استفاده‌شده در نصب‌های بعدی به شدت کاهش پیدا می‌کنه.
من خودم شخصاً اغلب برنامه‌های دسکتاپم رو با همین روش نصب می‌کنم.

چرا فلت‌پک فوق‌العاده است؟ (مزایا)
امنیت و عدم کثیف شدن سیستم (Sandbox): اپلیکیشن‌ها در محیطی ایزوله (Sandbox) و بدون نیاز به دسترسی root اجرا می‌شوند، بنابراین احتمال آسیب به سیستم و تداخل با کتابخانه‌های اصلی رو به شدت کاهش می‌ده.
مدیریت راحت دسترسی‌ها با Flatseal: به کمک برنامه گرافیکی Flatseal، می‌تونید به ساده‌ترین شکل ممکن دسترسی‌های هر برنامه فلت‌پک (مثل دسترسی به فایل‌ها، شبکه یا کامپوننت‌ها) و محل ذخیره تنظیماتشون رو مدیریت و کنترل کنید.
آپدیت‌های بی‌دردسر: با زدن یک دستور ساده مثل flatpak update -y تمام برنامه‌ها به راحتی بروز می‌شوند و نیازی به جستجوی دستی نیست.
اکوسیستم ساده برای نصب پلاگین‌ها:
مثال واقعی: فرض کنید می‌خواید پلاگین معروف Resynthesizer رو برای برنامه‌ای مثل GIMP نصب کنید. اگر بخواید از گیت‌هاب سورس اون رو بگیرید، باید ابزارهای توسعه رو روی سیستم نصب کرده و اون رو دستی کامپایل کنید؛ کاری که هم دردسر داره و هم به مرور سیستم رو کثیف می‌کنه. اما در فلت‌پک، پلاگین‌ها به صورت بسته‌های آماده (مثل org.gimp.GIMP.Plugin.Resynthesizer) ارائه میشن و با یک کلیک بدون آسیب به سیستم نصب میشن.
کاملاً متن‌باز (هم سمت کلاینت هم سرور): برعکس برخی رقبا، فلت‌پک هم در سمت کلاینت و هم سمت سرور متن‌بازه. این یعنی اگر روزی نخواستید از مرجع اصلی یعنی Flathub استفاده کنید، حتی خودتون می‌تونید یک سرور مخزن فلت‌پک جداگانه بسازید!

معایب فلت‌پک:
مصرف بالاتر فضای دیسک: به دلیل به دلیل نگهداری Runtimeها و کتابخانه‌های جدا از سیستم، معمولاً فضای بیشتری نسبت به بسته‌های بومی اشغال می‌کنه.
یکپارچگی ضعیف‌تر با سیستم (کمرنگ‌شده): در گذشته برخی برنامه‌ها با تم‌های سیستم یا بزرگ‌نمایی (Scaling) هماهنگ نمی‌شدند. البته این مشکل در نسخه‌های جدید گنوم (GNOME) و KDE به شدت کمرنگ شده و تقریباً حل شده است.
عدم کاربرد برای ابزارهای سیستمی: فلت‌پک مطلقاً برای مدیریت سیستم، ابزارهای خط فرمان (CLI) یا ابزارهای هسته مناسب نیست.

بررسی یک کیس واقعی: GIMP را با Flatpak نصب کنیم یا مخازن؟
شاید برای شما هم سوال پیش اومده باشه که برنامه‌ای مثل GIMP یا Krita رو از مخازن رسمی توزیع نصب کنیم یا فلت‌پک؟ من بعد از کلی جستجو و تجربه به این نتیجه رسیدم که نصب با فلت‌پک گزینه به مراتب بهتریه.
اما چرا؟
نرم‌افزارهای ادیت سنگین مثل GIMP و Krita وابستگی‌ها (Dependencies) و کتابخانه‌های بسیار زیادی دارند. مشکل زمانی شروع می‌شود که بخواید نسخه‌ای بسیار جدیدتر از نرم‌افزار را روی یک توزیع پایدار نصب کنید. با توجه به آپدیت‌های سریع این برنامه‌ها، احتمالش بسیار بالاست که نسخه‌های جدیدتر این کتابخانه‌ها با کتابخانه‌های حیاتی سیستم‌عامل شما دچار تداخل بشن.
بیاید ببینیم تداخل دقیقاً چطور باعث ناپایداری میشه: فرض کنید نسخه جدیدی از GIMP منتشر شده و به نسخه‌های جدیدتری از چند کتابخانه نیاز داره، در حالی که سیستم دبیان پایدار (Debian Stable) شما هنوز از نسخه‌های قدیمی‌تر همون کتابخانه‌ها استفاده می‌کنه.
اگر برای داشتن این GIMP جدید، بیاید مخزن Sid (Unstable) رو به سیستم Stable اضافه کنید، مدیر بسته سیستم (APT) مجبور میشه تعداد زیادی از کتابخانه‌های اصلی سیستم رو هم ارتقا بده. در نتیجه، بخشی از سیستم روی نسخه Stable و بخش دیگر روی Sid قرار می‌گیره! این ملغمه باعث ناسازگاری، بروز خطاهای نامشخص و حتی از کار افتادن سیستم‌عامل میشه (همون زیر پا گذاشتن اصل Don't Break Debian).
امّا وقتی GIMP رو با فلت‌پک نصب می‌کنید، تمام کتابخانه‌های جدیدش در کانتینرِ خودش حمل میشن و هیچ کاری به کتابخانه‌های اصلی سیستم شما ندارند. علاوه بر این، همیشه بدون ترس از خراب شدن سیستم، به آخرین آپدیت‌های رسمی برنامه دسترسی دارید.

چرا آینده فدورا و رد‌هت (Red Hat) به فلت‌پک گره خورده؟
جالبه بدونید پروژه فدورا (Fedora) رسماً داره به این سمت حرکت می‌کنه که برنامه‌های گرافیکی (GUI) دسکتاپ رو به طور پیش‌فرض از طریق Flatpak ارائه بده و ابزار dnf رو فقط برای ابزارهای سیستمی، ابزارهای ترمینالی و کتابخانه‌های پایه نگه داره.
دلایل فدورا برای برتری دادن فلت‌پک در برنامه‌هایی مثل GIMP:
حل مشکل کدک‌ها (Codecs): نسخه GIMP در مخازن dnf فدورا به دلیل مسائل مربوط به گواهی‌نامه‌ها و پتنت‌ها، اغلب از فرمت‌های جدیدی مثل AVIF یا HEIC/HEIF پشتیبانی نمیکنه. اما نسخه Flathub این کدک‌ها رو به صورت داخلی و آماده همراه خود داره.
پایان دردسر وابستگی‌های قدیمی: در نسخه‌های جدید فدورا، نصب پلاگین‌های قدیمی یا مبتنی بر پایتون برای GIMP از طریق dnf معمولاً به خطاهای سنگین وابستگی یا دورزدن‌های کثیف پایتون ۲ ختم میشه، در حالی که فلت‌پک این پلاگین‌ها رو به راحتی مدیریت می‌کنه.
چرا شرکتی مثل Red Hat از Flathub حمایت می‌کنه؟
زیرا فلت‌پک یک چالش بزرگ تجاری رو برای رد‌هت حل می‌کنه! لینوکس Red Hat Enterprise Linux (RHEL) برای سرورها و ایستگاه‌های کاری سازمانی طراحی شده، جایی که «پایداری» همه‌چیز است.
با واگذاری بسته‌بندی نرم‌افزارهای دسکتاپی سریع‌التغییر و سنگین (مثل GIMP ،LibreOffice و Inkscape) به Flathub، مهندسان رد‌هت دیگر مجبور نیستند وقت گران‌بهای شرکت رو صرف کامپایل، تست و آپدیت مداوم برنامه‌های دسکتاپ کنند؛ در عوض تمام تمرکز خود رو روی پایداری هسته اصلی لینوکس میزارن.

[seyal]

۱. دیستروباکس (Distrobox):
قبلا تو این پست یک مقدار راجع بهش نوشته بودم: لینک
به نظر من Distrobox دقیقاً همون شکافی که بین مخازن رسمی، فلت‌پک و اسنپ وجود داشت برای کاربران با نیازهای خاص پر کرد. این ابزار فوق‌العاده است، خیلی روان کار می‌کنه و با اصل «سیستم خود را خراب نکنید» همسو است.
دیستروباکس کنترل عمیقی روی برنامه‌ها به شما میده؛ حتی اجازه میده کانتینری با دسترسی root بسازید یا کلاً اون رو در حالت ایزوله نگه دارید. اگرچه دیستروباکس بیشتر یک ابزار تخصصی برای توسعه‌دهندگان (Developers) به حساب میاد، اما برای نصب برنامه‌هایی که نیاز به نصب سیستمی دارند ولی در پکیج‌منیجر اصلی سیستم شما نیستند بسیار کاربردیه.
سناریوهای کاربردی دیستروباکس:
نصب پکیج‌های .deb یا .rpm (با دستور dpkg / rpm): من به شخصه به هیچ عنوان نصب مستقیم فایل‌های .deb یا .rpm متفرقه رو روی سیستم‌عامل اصلی نمی‌پسندم؛ چون احتمال تداخل کتابخانه‌ها یا عدم پاک‌سازی کاملشون وجود داره. اما نصب این فایل‌ها داخل کانتینر دیستروباکس فوق‌العاده است!
مثال واقعی: من خودم نرم‌افزار Cherry Studio (نسخه .deb) رو داخل یک کانتینر دبیان ۱۳ در دیستروباکس نصب کردم و به راحتی و بدون هیچ مشکلی از اون تو توزیع فدورا استفاده می‌کنم.
زنده کردن نرم‌افزارهای قدیمی یا متروکه (Legacy Software): اگر به نرم‌افزاری نیاز دارید که چند سال پیش توسعه‌اش متوقف شده، احتمالاً روی فدورای جدید شما اجرا نمیشه چون به کتابخانه‌های قدیمی نیاز داره. با دیستروباکس می‌تونید یک کانتینر از اوبونتو ۱۸.۰۴ بسازید؛ برنامه از کتابخانه‌های قدیمی داخل کانتینر استفاده می‌کنه اما روی هسته (Kernel) جدید سیستم اصلی شما با حداکثر سرعت اجرا میشه!
عبور از محدودیت‌های ایزوله‌سازی فلت‌پک: برخی برنامه‌های پیچیده (مثل برنامه‌های مبتنی بر الکترون یا ابزارهایی که نیاز به دسترسی عمیق به ترمینال و فایل‌های سیستمی دارند) داخل محیط ایزوله (Sandbox) فلت‌پک کار نمی‌کنند یا کُند می‌شوند. دیستروباکس دسترسی سیستمی و عملکرد نیتیو (Native) رو به این برنامه‌ها میده.
دور زدن محدودیت‌های شبکه و مدیریت میرورها: فرض کنید دسترسی به اینترنت بین‌الملل محدود شده و به یک پکیج خاص نیاز دارید، اما توزیع شما میرور داخلی نداره یا نمی‌خواید به کانفیگ‌های شبکه سیستم اصلی دست بزنید. کافیه میرور داکر را برای دریافت ایمیج‌های دیستروباکس تنظیم کنید. سپس داخل کانتینر ساخته‌شده هر میروری خواستید اضافه و ادیت کنید. اگر همه چیز به‌هم ریخت، خیلی راحت کل کانتینر را پاک می‌کنید، بدون اینکه سیستم اصلی آسیبی ببیند!

۲. اپ‌ایمیج (AppImage)
فایل‌های AppImage بیشتر برای امتحان کردن یک برنامه یا داشتن یک نسخه پرتابل (Portable) عالی هستند تا استفاده مداوم روزمره.
مزایا: بی‌نهایت برای تست سریع مناسبند. مثلاً زمانی که می‌خواید روی نسخه لایو (Live) یک توزیع کار کنید، یا برنامه‌ای رو سریع بین چند ماشین مجازی (VirtualBox) اجرا کنید بدون اینکه حجم سنگین اولیه فلت‌پک یا دردسر نصب سیستمی رو تحمل کنید.
معایب: آپدیت‌ها باید به صورت دستی انجام بشن. همچنین ممکنه با برخی سیستم‌ها مشکل اجرا داشته باشند. بعلاوه، خیلی از نرم‌افزارهایی که در سال‌های اخیر منتشر شده‌اند کلاً نسخه AppImage ارائه نمی‌دهند.

۳. نسخه‌های باینری لینوکس (Executable Binaries)
همون روش معروف اعطای دسترسی اجرا با دستور chmod +x و سپس اجرای فایل با .yourapp/...
این روش هم تا حد زیادی شبیه AppImage حس یک برنامه پرتابل رو میده. من برای برنامه‌های مختلفی از این روش استفاده می‌کنم:
کلاینت‌های v2ray مثل Throne
ابزار کامپایل اسناد ConTeXt (بدون نیاز به کامپایل سنگین یا نصب از طریق Snap)
ابزار scrcpy (برای کنترل گوشی در لینوکس)
ویژگی‌های این روش:
این روش به‌خصوص برای پروژه‌های open-source موجود در گیت‌هاب (GitHub) عالیه. شما بدون کثیف کردن سیستم به جدیدترین نسخه برنامه با عملکرد کامل دسترسی دارید و هر زمان برنامه رو نخواستید، کافیه فول더ش رو پاک کنید.
چند نکته مهم موقع استفاده از باینری‌ها:
فایل‌های تنظیمات: با اینکه برنامه پرتابل است، اما فایل‌های کانفیگ خود رو معمولاً در مسیر Home/ قرار میده.
احتیاط در اجرا با sudo: اگر برنامه‌ای برای اجرا به دسترسی روت نیاز داره، حتماً بررسی کنید که قراره چه تغییری در سیستم ایجاد کنه.
مثال: در برنامه‌های v2ray اگر حالت TUN Mode فعال باشه و سیستم ناگهانی ریستارت بشه، اینترنت معمولی سیستم قطع میشه! برای حلش باید دوباره برنامه رو باز کنید و TUN Mode رو غیرفعال کنید.
کتابخانه‌های پیش‌نیاز: این باینری‌ها برای اجرا به یک‌سری کتابخانه‌های پایه روی سیستم شما نیاز دارند. اگر برنامه‌ای اجرا نشد، حتماً اون رو از طریق ترمینال با دستور yourapp./ اجرا کنید تا دقیقاً ببینید کمبود چه پکیج یا کتابخانه‌ای باعث اجرا نشدنش شده.

۴. محیط‌های مجازی پایتون (venv.) و ابزارهای جدید
شاید بپرسید محیط مجازی پایتون چه ربطی به نصب برنامه روی سیستم‌عامل داره؟ ربطش جلوگیری از بریک شدن سیستم است!
بسیاری از پکیج‌منیجرهای مهم توزیع‌ها (مثل dnf در فدورا) شدیداً به کتابخانه‌های داخلی پایتون وابسته هستند. اگر شما بیایید و کتابخانه‌های جانبی پایتون رو به صورت سراسری (Global) با دستورات قدیمی مثل pip نصب یا آپدیت کنید، یک ناسازگاری کوچک در نسخه کتابخانه‌ها می‌تواند پکیج‌منیجر و در نهایت کل سیستم‌عامل شما رو از کار بیندازد!
راه‌حل: همیشه برای پروژه‌ها و برنامه‌های پایتونی از محیط مجازی (venv.) استفاده کنید.
یک پیشنهاد به‌روز: به جای ابزار قدیمی pip سراغ ابزار فوق‌العاده سریع و جدید uv بروید. اگر می‌خواید برنامه‌ها و محیط‌های پایتونی رو مدام جابه‌جا کنید، uv کار رو بی‌نهایت راحت‌تر و امن‌تر می‌کنه.

[seyal]

همیشه این سوال تو ذهنم بود که «چرا این‌قدر جبهه‌گیری و دوگانگی در جامعه متن‌باز (Open-Source) در برابر اسنپ وجود داره؟ اگر واقعاً بده، چرا حذفش نمی‌کنند یا اصلاحش نمیکنند؟»
اینجاست که داستان خیلی جذاب میشه...

اسنپ ابزار پکیج‌بندی شرکت کانونیکال (Canonical) سازنده اوبونتو هست که هدفی مشابه فلت‌پک داره (حمل همه وابستگی‌ها همراه برنامه).
اما اسنپ برای کاربر دسکتاپ معمولاً انتخاب محبوبی نیست.

۴ دلیل اصلی که کاربران دسکتاپ از اسنپ شاکی هستند:
سرعت بسیار پایین در اولین اجرا (Cold Boot Delay): اسنپ از ایمیج‌های SquashFS و لایه‌های ایزوله‌سازی مختلف استفاده می‌کنه که می‌تونن باعث افزایش زمان اولین اجرای برنامه بشن.
شلوغ کردن خروجی ترمینال: اسنپ برای هر برنامه‌ای که نصب می‌کنه یک درایو مجازی می‌سازه. وقتی تو ترمینال دستور استاندارد df -h رو برای دیدن وضعیت هارد می‌زنید، با ده‌ها سطر شلوغ و ساختگی /dev/loop مواجه میشید که دیدن وضعیت هارد اصلی رو کلافه‌کننده می‌کنه.
یکپارچگی ضعیف با تم و ظاهر سیستم: در برخی توزیع‌ها و تم‌ها هنوز به خوبی Flatpak نیست.
انحصارطلبی کانونیکال (بسته بودن سمت سرور): برعکس فلت‌پک که هر کسی می‌تونه براش استور شخصی بزنه، سمت سرورِ اسنپ‌استور کاملاً کدبسته (Closed-source) و در انحصار کانونیکال است. این موضوع یکی از مهم‌ترین انتقادهای بخشی از جامعهٔ لینوکس به اسنپ است.

شاید بگید پس چرا بقیه همه نمیان سراغ فلت‌پک با سرور شخصی خودشون؟ جدا از اینکه راه‌اندازی و نگهداری یک سرور فلت‌پک نیاز به دانش فنی، هزینه و منابع زیادی داره، باید محدودیت‌های ذاتی فلت‌پک رو بشناسیم:
چرا فلت‌پک برای ابزارهای سیستمی و پایه (Core/CLI) مناسب نیست؟
فلت‌پک اصولا برای برنامه‌های گرافیکی دسکتاپ (GUI) ساخته شده است. فلت‌پک:
به هسته (Kernel) دسترسی نداره و نمی‌تونه ماژول‌ها یا درایورها رو مدیریت کنه.
توانایی ساخت سرویس‌های پس‌زمینه سیستمی (Systemd Daemons) رو نداره.
دسترسی به سخت‌افزار و دایرکتوری ریشه (/) رو برای حفظ امنیت مسدود می‌کنه.
اینجاست که نقش واقعی اسنپ مشخص میشه!
کانونیکال اسنپ رو فراتر از یک ابزار دسکتاپ طراحی کرد. اسنپ علاوه بر حالت‌های ایزوله (Strict و Devmode)، حالتی به اسم Classic Confinement داره که ایزوله‌سازی رو کلاً کنار می‌ذاره و مثل بسته‌های سنتی، دسترسی کامل به دایرکتوری ریشه و سخت‌افزار میده!
به همین دلیل اسنپ در موارد زیر کارایی بالایی داره:
ابزارهای خط فرمان (CLI) و برنامه‌های سروری: مثل ابزارهای شبکه (v2ray/Xray)، سرویس Gitea یا کامپایلرهایی مثل Go.
سرویس‌های پس‌زمینه (Daemons): اسنپ می‌تونه سرویس‌هایی بسازه که با بالا آمدن لینوکس در پس‌زمینه اجرا بشن.

جدای از این انتشار برنامه در اسنپ‌استور برای توسعه‌دهندگان بسیار ساده‌تر از فلت‌پک است.

اگر چند تکهٔ دیگه از پازل روش تجاری کانونیکال رو کنار هم بذاریم، همه‌چیز روشن‌تر میشه: بخش مهمی از بازار هدف اسنپ اصلاً کاربر دسکتاپ نیست!
بخش قابل‌توجهی از درآمد و تمرکز کانونیکال از لینوکس‌های نصب‌شده روی کیوسک‌های شهری، دستگاه‌های ATM، تجهیزات پزشکی، تجهیزات IoT و سرورهای ابری به دست میاد. برای همین هم Snap از همون اول طوری طراحی شده که نیازهای این سیستم‌ها رو برآورده کنه؛ چون برای یک ATM اصلاً مهم نیست یه برنامه ۳ ثانیه دیرتر باز بشه یا خروجی دستور df شلوغ‌تر باشه. مهم اینه که سیستم تحت هیچ شرایطی کرش نکنه، پکیج‌ها ایزوله و قابل‌اعتماد باشن، آپدیت‌های امنیتی به‌موقع اعمال بشن و در صورت بروز مشکل هم بشه خیلی سریع به نسخهٔ قبلی برگشت؛ بدون اینکه لازم باشه کل سیستم دستکاری یا ارتقا داده بشه.
یادتونه گفتیم یکی از دلایل کندی و شلوغی اسنپ همین Loop Deviceها هستن؟ چیزی که شاید برای کاربر دسکتاپ آزاردهنده به نظر برسه، برای مدیران سرور و سیستم‌های حساس می‌تونه یک مزیت مهم باشه.
اسنپ نسخه‌های مختلف یک پکیج رو به‌صورت ایمیج‌های SquashFS نگه می‌داره و از طریق Loop Deviceها روی سیستم mount می‌کنه. به همین خاطر اگه یه آپدیت به مشکل بخوره یا خراب از آب دربیاد، می‌تونه خیلی راحت به نسخهٔ قبلی همون پکیج برگرده (Rollback)؛ بدون اینکه لازم باشه فایل‌های سیستمی دستکاری بشن یا عملیات پیچیده‌ای برای بازیابی انجام بشه. به همین دلیله که این قابلیت برای سرورها، تجهیزات صنعتی و سیستم‌های حیاتی اهمیت زیادی داره.

چرا کانونیکال اسنپ رو روی دسکتاپ اجباری می‌کنه؟
علاوه بر اینکه با استور اختصاصی کاربرانی که دنبال یک نصب سریع و مشابه ویندوز هستند رو راضی می‌کنه، اوبونتو دسکتاپ یک بیلبورد تبلیغاتی بزرگ هست.
وقتی میلیون‌ها کاربر و توسعه‌دهنده روی دسکتاپ با اسنپ کار کنند، با این اکوسیستم خو می‌گیرند و فردا در پروژه‌های بزرگ صنعتی و سروری شرکت‌هاشون هم از همین ابزار استفاده می‌کنند.

چرا سمت سرور اسنپ کدبسته است؟
کانونیکال قابلیت «مخازن خصوصی» (Private Snaps / Brand Store) رو به شرکت‌های بزرگ می‌فروشه. یک شرکت سازنده سخت‌افزار یا بانک، می‌تونه با پرداخت پول، یک نسخه اختصاصی از اسنپ‌استور اجاره کنه که فقط برنامه‌های خودش روی دستگاه‌هاش (مثل ATMها) نصب بشه و زمان آپدیت‌ها رو ۱۰۰٪ کنترل کنه. اگر کانونیکال کد سرور رو متن‌باز می‌کرد، غول‌هایی مثل Red Hat یا آمازون سریعا سرورهای اسنپ خودشان رو راه می‌انداختند و کانونیکال از این درآمد کلان محروم می‌شد.
جالبه بدونید در صفحه رسمی اسنپ‌استور، کنار توزیع‌های دسکتاپی مثل Ubuntu و Fedora، پلتفرم‌هایی مثل Raspberry Pi، CentOS و Red Hat Enterprise Linux هم دیده می‌شن. همین موضوع نشون می‌ده که بازار هدف اسنپ فراتر از دسکتاپ بوده و کانونیکال از ابتدا به سناریوهای سروری و IoT هم توجه داشته.

پس چرا بقیه شرکت‌ها نیومدند و برای مبارزه با کانونیکال یک رقیب تو همین زمینه منتشر نکردند؟
پاسخ سادست چون موضوع به تفاوت مدل‌های تجاری این شرکت‌ها برمی‌گرده و نیازی به تقلید از هم ندارند.
برای مثال بیایید یک مقایسه‌ای بین این دو شرکت مطرح داشته باشیم
اولیش کانونیکال (Ubuntu) هست که ابزار اصلیش Snapئه و جامعه هدفش رو گذاشته روی توسعه‌دهندگان خرد و متوسط، شرکت‌های IoT و کاربران دسکتاپ. مدل درآمدی و استراتژی این شرکت هم روی اجاره استور اختصاصی (Brand Store) و یکپارچه‌سازی دسکتاپ با IoT و سرور می‌چرخه.
دومیش رد‌هت (Red Hat) هست که ابزارهای اصلیش Flatpak و RPM هستن و مستقیماً ابرشرکت‌ها (Enterprises)، دیتاسنترها و بانک‌ها رو هدف گرفته. استراتژی درآمدزاییش هم اصلاً گیر دادن به فرمت پکیج نیست، بلکه روی فروش ابزارهای گران‌قیمت مدیریت زیرساخت مثل Red Hat Satellite و OpenShift تمرکز داره.

البته بی‌انصاف هم نباشیم! اسنپ فقط به نفع کانونیکال نیست.
با وجود تمام نقدها، اسنپ برای کاربرانی که تازه از ویندوز به اوبونتو آمده‌اند مزایایی هم داره:
پایان کابوس وابستگی‌ها (Dependency Hell): کاربر بدون درگیری با خطای کتابخانه‌ها، فقط روی Install کلیک می‌کنه و برنامه اجرا میشه.
جدیدترین نسخه بدون خطر شکستن سیستم: داشتن جدیدترین نسخه اسپاتیفای یا بلندر بدون نیاز به اضافه کردن PPAهای خطرناک.

و در نهایت حق انتخاب در لینوکس: اگر از اسنپ خوشتون نمیاد، لینوکس یعنی آزادی! می‌تونید با چند دستور پاکش کنید یا سراغ توزیع‌هایی مثل Linux Mint یا Pop!_OS برید که کلاً اسنپ رو به صورت پیش‌فرض حذف و فلت‌پک رو جایگزین کرده‌اند.

[seyal]

نتیجه‌گیری:
با یادگیری در مورد این پکیج‌ها آشنا شدم که واقعا نصب پکیج تو لینوکس در درازمدت اتفاقا خیلی هم راحت‌تر و استانداردتر از روش‌های ویندوزی یا اندرویدی هست. کافیه یک نگاه مقایسه‌ای بین این سه سیستم‌عامل داشته باشیم:
در ویندوز هر برنامه‌ای برای خودش فرمانروایی می‌کنه!
یک اسکریپت کوچک یا فایل نصب غیررسمی می‌تونه کل سیستم رو به فنا بده، به همین خاطر وجود آنتی‌ویروس دائمی ضروری میشه.
برنامه‌ها در درازمدت حجم عجیبی اشغال می‌کنند، چون هر برنامه مجبوره‌ تمام فایل‌های DLL و وابستگی‌های خودش رو همراه خودش بیاره (به دلیل عدم وجود یک مدیریت بسته متمرکز پیش‌فرض).
برای نصب خیلی از برنامه‌ها دسترسی Administrator لازمه که ریسک امنیتی بالایی داره.
راهکارهایی با ظرافت و بهینگی Distrobox یا حتی همین Flatpak و Snap در ویندوز وجود نداره. مایکروسافت تازه بعد از سال‌ها مجبور شد Microsoft Store رو بسازه تا حداقل برنامه‌ها یک‌بار چک بشن، اما استور فقط یکی از ده‌ها راهکار لینوکس بود!
در نهایت، بعد از چند ماه نصب و پاک کردن برنامه‌ها، سیستم سنگین میشه، باگ‌ها بروز پیدا می‌کنند و کاربر مجبور به Clean Install (نصب مجدد ویندوز) میشه.

از اون طرف در اندروید هم با راهکاری طرف هستیم که دسترسی‌های شما رو به شدت محدود می‌کنه: برای اینکه به قدرت واقعی دستگاه دسترسی داشته باشید، یا باید قید گارانتی و امنیت رو بزنید و گوشی رو Root کنید (که خطرات امنیتی زیادی داره)، یا اینکه با یک دیوایس کاملاً محدود بسازید.
پارادوکس عجیب اندروید: در لینوکس شما دسترسی کامل Root دارید، اما امنیت سیستم حتی در حالت عادی هم پایدارتر از اندرویدِ روت‌نشده است! در لینوکس شما تعیین می‌کنید برنامه چه دسترسی داشته باشه (مثلاً با Flatseal)، اما در اندروید برنامه‌ها حتی فعال بودن Developer Options رو تشخیص میدن و بهتون گیر میدن! در حالی که اصلاً به اون برنامه ربطی نداره که شما از این قابلیت برای کارهای دیگه استفاده می‌کنید.
به عبارت ساده‌تر: در اندروید برنامه تصمیم می‌گیره چطور با دستگاه شما رفتار کنه، نه شما!

یگ اشاره مجددی هم به اول مقاله داشته باشیم شاید بپرسید: «اصلاً چرا این‌قدر روی تمیز نگه داشتن سیستم و عدم استفاده از روش‌های غیراستاندارد تأکید داریم؟» پاسخ این سوال زمانی مشخص میشه که سیستم رو به مرور با روش‌های غیراستاندارد کثیف کنید. سیستم ابتدا مثل ویندوز کمی سنگین و پر از باگ‌های ریز میشه، اما وقتی که بخواید توزیعتون رو ارتقا بدید (مثلاً ارتقا از فدورا ۴۳ به نسخه ۴۴)! اونجاست که تداخل کتابخانه‌ها و جهنم وابستگی‌ها (Dependency Hell) خودش رو نشان میده. گاهی یک پکیج کوچک غیررسمی که ماه قبل نصب کردید، فرایند ارتقای کل سیستم‌عامل رو مسدود می‌کنه و پیدا کردن اون مشکل مخفی ممکنه روزها از شما وقت بگیره. نتیجه این کثیف کردن سیستم چیه؟ کاربر از فرایند ارتقای توزیع دلزده میشه، با خودش می‌گه «ابزارهای ارتقای لینوکس به درد نمی‌خورند!» و دوباره مجبور میشه سراغ روش سنتی Fresh Install (نصب از صفر) بره. در حالی که مشکل از سیستم‌عامل نبوده، بلکه از روش نصب برنامه‌ها بوده!

این بود تجارب من در روش‌های نصب نرم‌افزار در لینوکس