چرا برای بعضی برنامه‌ها از Snap و Flatpak به‌جای deb و rpm استفاده می‌کنیم؟

فرض کنید سیستم‌عامل یک نسخهٔ LTS است و برای چند سال قرار نیست عوض شود؛ اما برنامهٔ تدوین ویدئو یا پیام‌رسان باید نسخهٔ تازه داشته باشد. حالا نسخهٔ جدید برنامه به کتابخانه‌ای نیاز دارد که در مخزن این سیستم نیست. ارتقای کل سیستم برای یک برنامه، همیشه تصمیم مناسبی نیست.

Snap و Flatpak به این مسئله پاسخ می‌دهند: جداکردن محیط و زمان انتشار برنامه از محیط پایهٔ توزیع. با این حال، این روند به معنی کناررفتن dpkg و RPM از لینوکس نیست؛ باید ببینیم هر ابزار کدام بخش سیستم را مدیریت می‌کند و هزینهٔ این جدایی چیست.

۱. مقایسه را در لایهٔ درست انجام دهیم#

deb و rpm قالب بسته‌اند؛ dpkg و RPM ابزارهای پایین‌تر نصب و ثبت وضعیت‌اند؛ APT و DNF مخزن و وابستگی‌ها را مدیریت می‌کنند. Snap و Flatpak بخش‌های بیشتری از انتشار و محیط اجرای برنامه را یکجا پوشش می‌دهند.

بنابراین روی یک لپ‌تاپ می‌توان هم‌زمان deb یا rpm برای سیستم و Flatpak برای برنامهٔ گرافیکی داشت. Flatpak طبق تعریف پروژه برای محیط دسکتاپ طراحی شده و انتخاب طبیعی مدیریت سرویس یک سرور headless نیست. دامنهٔ کاربرد Flatpak

۲. مدل سنتی چه چیزی را خوب حل می‌کند؟#

مخزن یک توزیع فقط انبار فایل نیست. نگه‌دارندگان مجموعه‌ای از نسخه‌ها، patchها، وابستگی‌ها و سیاست‌های سازگاری را کنار هم نگه می‌دارند. برنامه‌ها از کتابخانه‌های مشترک استفاده می‌کنند و ابزارهای مدیریت بسته وضعیت کل سیستم را می‌شناسند.

این مدل برای یک سرور اهمیت زیادی دارد: نسخهٔ کتابخانه، سرویس و ابزارهای عملیاتی باید با سیاست همان انتشار هماهنگ باشند. یک شمارهٔ نسخهٔ قدیمی نیز لزوماً یعنی فقدان اصلاحیهٔ امنیتی نیست؛ توزیع ممکن است اصلاحیه را backport کند.

از نگاه مدیر سیستم، یکپارچگی فایل‌ها، پشتیبانی توزیع و امکان مدیریت مخزن داخلی مزیت‌اند. مسئله از جایی آغاز می‌شود که سازندهٔ برنامه بخواهد سرعت انتشارش را از این مجموعه مستقل کند.

۳. مسئلهٔ سازنده: چند نسخه برای چند توزیع#

برنامه‌ای را در نظر بگیرید که روی نسخه‌ای از یک کتابخانه ساخته شده است. در توزیع دیگر ممکن است نام بسته، نسخهٔ کتابخانه، ABI یا تنظیم build متفاوت باشد. پشتیبانی از Debian، Ubuntu و چند نسخهٔ Enterprise Linux، تنها تغییر پسوند خروجی نیست.

یک بستهٔ app به همراه محیط اجرایی مشخص می‌تواند تعداد ترکیب‌هایی را که ناشر باید پوشش دهد کاهش دهد. ناشر همچنان باید معماری‌ها، امکانات کرنل و یکپارچگی میزبان را آزمایش کند؛ «یک بار build برای همهٔ لینوکس‌ها» را تضمین بدون شرط ندانید. هدف‌های انتشار Flatpak ، انتشار چندتوزیعی Snap

برای تیم کوچک، کاهش این ماتریس می‌تواند تفاوت میان انتشار رسمی روی لینوکس و اتکا به بسته‌های داوطلبانه باشد. البته هر Snap یا Flatpak را خود سازنده نگه‌داری نمی‌کند؛ ناشر واقعی را باید جدا بررسی کرد.

۴. نسخهٔ تازه روی پایهٔ پایدار#

در یک انتشار پایدار، ارتقای بزرگ کتابخانه می‌تواند برنامه‌های دیگری را تحت‌تأثیر قرار دهد. بنابراین مخزن توزیع معمولاً هر نسخهٔ تازهٔ upstream را فوراً وارد نمی‌کند. این انتخاب بخشی از قرارداد پایداری آن است.

در Flatpak، برنامه می‌تواند runtime خودش را داشته باشد. در Snap، base و کتابخانه‌های بسته‌بندی‌شده محیط موردنیاز را فراهم می‌کنند. نتیجه این است که برنامهٔ جدید الزاماً به تعویض کتابخانهٔ پایهٔ میزبان نیاز ندارد.

Stable host OS
  |
  +-- native packages --> host libraries
  |
  +-- application A --> selected runtime / base
  |
  +-- application B --> another supported runtime / base

این استقلال نسبی است: برنامه هنوز روی کرنل و امکانات واقعی دستگاه اجرا می‌شود. runtime جدید مشکل یک درایور ناسازگار یا backend ناقص portal را خودکار برطرف نمی‌کند.

۵. انتشار مستقیم و کانال آزمایش#

در مدل مستقیم، ناشر می‌تواند نسخهٔ برنامه را با زمان‌بندی خودش منتشر کند و فاصلهٔ release تا دسترسی کاربر را کم کند. اما اگر بسته را جامعه نگه‌داری کند، تأخیر به فرایند همان نگه‌دارنده وابسته است؛ نوع قالب به‌تنهایی سرعت را تضمین نمی‌کند.

Snap کانال‌ها را با ترکیبی از track، سطح ریسک و در صورت نیاز branch معرفی می‌کند. سطوحی مانند stable، candidate، beta و edge به ناشر اجازه می‌دهند نسخهٔ آزمایشی و پایدار را جدا ارائه کند. Flatpak نیز branch و remoteهای مجزا دارد؛ نام branch فقط یک نام است و کیفیت محتوا را تضمین نمی‌کند. کانال‌های Snap ، شناسه و branch در Flatpak

برای سازمان، اصل مهم همان انتشار کنترل‌شده است: نسخهٔ مشخص را آزمایش کنید و بعد همان خروجی را به کاربران هدف برسانید. صرف اینکه برنامه از یک Store آمده، جای staging و آزمون رفتار برنامه را نمی‌گیرد.

۶. sandbox؛ محدودکردن دسترسی در زمان اجرا#

نصب بستهٔ رسمی از مخزن معتبر، دربارهٔ منبع نرم‌افزار اطمینان می‌دهد؛ اما به‌خودی‌خود محیط اجرای آن را محدود نمی‌کند. برنامهٔ معمول کاربر غالباً می‌تواند فایل‌هایی را بخواند که آن کاربر به آن‌ها دسترسی دارد.

Snap در حالت strict و Flatpak با مجوزهای محدود می‌توانند دسترسی را کاهش دهند. مثلاً برنامه فقط به فایل انتخاب‌شده یا یک دستگاه مشخص دسترسی بگیرد. این قابلیت برای برنامه‌های دسکتاپ، افزونه‌ها و فایل‌های ورودی نامطمئن مفید است.

اما مرز به مجوز واقعی بستگی دارد. Snap با classic همان محدودسازی strict را ندارد؛ Flatpak با دسترسی گسترده به home یا سرویس‌های حساس نیز حفاظت کمتری دارد. مجوزها، backend امنیتی و رفتار برنامه را بررسی کنید. confinement در Snap ، مجوزهای Flatpak

همچنین یک برنامهٔ بومی می‌تواند با systemd، AppArmor یا SELinux محدود شود. sandbox مزیت مهم این قالب‌هاست، اما انحصار آن‌ها نیست.

۷. به‌روزرسانی با مسئولیت متفاوت#

Snap معمولاً به‌روزرسانی را خودکار مدیریت می‌کند و امکان تنظیم زمان یا نگه‌داشتن refresh را دارد. این مدل برای دستگاه‌هایی که کاربر نگه‌دارندهٔ دائمی ندارند جذاب است؛ مدیر باید پنجرهٔ تغییر، restart سرویس و سیاست نگه‌داری را بشناسد. مدیریت به‌روزرسانی Snap

در Flatpak، flatpak update برنامه و runtimeها را تازه می‌کند؛ خودکارشدن می‌تواند توسط محیط دسکتاپ یا سیاست مدیریتی انجام شود. رفتار همهٔ توزیع‌ها را یکسان فرض نکنید.

جداشدن برنامه از سیستم یک نتیجهٔ عملی دارد: به‌روزرسانی APT یا DNF الزاماً برنامه‌های Snap و Flatpak را تازه نمی‌کند. اکنون چند مسیر به‌روزرسانی دارید و باید همهٔ آن‌ها را پایش کنید.

۸. هزینهٔ کتابخانه‌های همراه برنامه#

اگر چند برنامه کتابخانهٔ مشترک میزبان را مصرف کنند، اصلاح آن کتابخانه می‌تواند همگی را پوشش دهد. اگر هرکدام نسخهٔ خودش را همراه داشته باشد، ناشر هر برنامه باید نسخهٔ اصلاح‌شده را بسته‌بندی و منتشر کند.

runtimeهای مشترک Flatpak و base یا contentهای Snap بخشی از تکرار را کم می‌کنند؛ ولی کتابخانه‌های bundled همچنان مسئولیت ناشر برنامه‌اند. runtime منقضی یا بسته‌ای با وابستگی قدیمی، با جدیدبودن تاریخ نصب امن نمی‌شود. مدیریت وابستگی‌های Flatpak

این معامله است: استقلال بیشتر در برابر تعداد بیشتر محیط‌هایی که باید پشتیبانی شوند. برای سازمان، فهرست نرم‌افزار باید runtime و base و ناشر را هم پوشش دهد، نه فقط نام برنامه را.

۹. دیسک، دانلود و یکپارچگی دسکتاپ#

نخستین برنامه ممکن است runtime یا base بزرگی دانلود کند. برنامه‌های بعدی می‌توانند بعضی از همان محتوا را استفاده کنند، اما داشتن چند نسل runtime و revisionهای قبلی همچنان هزینه دارد. اندازهٔ download، فضای اشغال‌شده و حافظهٔ مصرفی سه معیار جدا هستند.

در اجرا نیز theme، فونت، file chooser، GPU و دسترسی USB می‌توانند با نسخهٔ بومی فرق کنند. بخشی از مشکل از مجوز یا بسته‌بندی است و بخشی از میزبان؛ نمی‌توان از روی فرمت به‌تنهایی حکم داد همهٔ برنامه‌ها کندتر یا بهترند.

برای انتخاب، نسخهٔ مشخص یک برنامه را روی دستگاه مقصد بسنجید: شروع سرد و گرم، بازکردن فایل، نمایش درست، اتصال دستگاه و به‌روزرسانی. نتیجهٔ یک برنامه را به همهٔ Snapها و Flatpakها تعمیم ندهید.

۱۰. اعتماد از توزیع به چه کسی منتقل می‌شود؟#

در مخزن رسمی توزیع، به سیاست و نگه‌داری همان توزیع تکیه می‌کنید. با افزودن Store یا remote دیگر، ناشر و سیاست انتشار تازه‌ای وارد زنجیره می‌شود. امضا نشان می‌دهد محتوا از مرجع مورداعتماد آمده؛ تضمین کیفیت کد نیست.

در Flatpak می‌توان مخزن مستقل و امضاشده داشت. در Snap، مسیر اصلی توزیع حول Snap Store و مدل سرویس Canonical شکل گرفته؛ نصب محلی و راهکارهای سازمانی نیز وجود دارند، اما معادل افزودن آزادانهٔ چند remote در Flatpak نیستند. میزبانی مخزن Flatpak ، معماری Snap

این تغییر صرفاً فنی نیست. باید معلوم باشد چه کسی بسته را build می‌کند، چه کسی وابستگی آسیب‌پذیر را اصلاح می‌کند و در صورت قطع دسترسی به منبع، انتشار بعدی چگونه انجام می‌شود.

۱۱. چه زمانی مدل بومی مناسب‌تر است؟#

برای کرنل، درایور، کتابخانهٔ پایه، سرویس سیستمی تحت پشتیبانی توزیع و ابزار عملیاتی سرور، بستهٔ بومی معمولاً نقطهٔ شروع منطقی است. برای برنامهٔ دسکتاپی که نسخهٔ تازه و محیط مستقل می‌خواهد، Flatpak یا Snap می‌تواند مناسب‌تر باشد.

یک IDE با نیاز گسترده به SDK و ابزارهای میزبان ممکن است داخل sandbox اصطکاک بیشتری داشته باشد؛ باید بستهٔ رسمی، مجوزها و workflow واقعی آن را سنجید. در یک دستگاه Ubuntu Core نیز Snap جزئی از طراحی محصول است و انتخاب را در همان معماری ارزیابی می‌کنیم.

دلیل استفاده از این دو فناوری، «خراب‌بودن dpkg و RPM» نیست. مسئله این است که انتشار هماهنگ سیستم‌عامل و انتشار مستقل برنامه دو نیاز متفاوت‌اند. انتخاب خوب، برای هر بخش ابزار متناسب با مسئولیت و چرخهٔ پشتیبانی آن می‌گذارد.