در دنیای deb و rpm، برنامه معمولاً به مجموعهٔ کتابخانه‌های همان توزیع وصل می‌شود. این مدل برای ساخت یک سیستم هماهنگ بسیار مفید است؛ اما سازندهٔ یک برنامهٔ دسکتاپ باید با انتشارهای مختلف، نسخه‌های متفاوت کتابخانه‌ها و زمان‌بندی مخازن کنار بیاید. Snap و Flatpak از تلاش برای کم‌کردن این فاصله بیرون آمدند.

در این نوشته ابتدا تاریخچه را می‌بینیم و سپس ساختار هرکدام را باز می‌کنیم: چه چیزی دانلود می‌شود، برنامه کجا اجرا می‌شود و ارتباطش با میزبان چگونه برقرار می‌ماند؟ نام درست پروژهٔ دوم Flatpak است؛ آن را یک کلمه می‌نویسیم.

۱. چند نام که باید از هم جدا کنیم#

ناممعنی
Snapقالب بسته و فناوری انتشار و اجرای آن
snapابزار خط فرمان کاربر
snapdسرویس مدیریت نصب، اجرا و به‌روزرسانی Snap
Snapcraftابزار ساخت Snap
Snap Storeسرویس اصلی انتشار و دریافت Snap
Flatpakفناوری و ابزار نصب و اجرای برنامه‌های بسته‌بندی‌شده
flatpak-builderابزار ساخت برنامه از manifest
Flathubیک مخزن بزرگ و عمومی برای Flatpak

Flatpak و Flathub یک چیز نیستند. می‌توان Flatpak داشت و از مخزن دیگری استفاده کرد. همچنین Snapcraft ابزار ساخت است، نه سرویسی که برای اجرای همهٔ برنامه‌ها روی کلاینت لازم باشد.

۲. ریشهٔ Snap: تجربهٔ موبایل و Ubuntu Core#

Canonical در ۹ دسامبر ۲۰۱۴، Ubuntu Core با به‌روزرسانی‌های snappy را معرفی کرد. در آن اعلامیه، تجربهٔ Ubuntu Phone به‌عنوان یکی از ریشه‌های طراحی مطرح بود: اجزای مستقل، محتوای فقط‌خواندنی و به‌روزرسانی‌ای که تغییر یک برنامه را از بقیهٔ سیستم جدا کند. اعلام اولیهٔ Ubuntu Core

در ۱۴ ژوئن ۲۰۱۶، انتشار Snap روی چند توزیع لینوکس به‌صورت عمومی اعلام شد. از اینجا Snap فقط قالب یک سیستم مبتنی بر Ubuntu Core نبود و برای برنامه‌های دسکتاپ، ابزارهای خط فرمان و سرویس‌ها نیز مطرح شد. اعلام انتشار چندتوزیعی Snap

این ریشه هنوز در طراحی دیده می‌شود: مدیریت سرویس، کانال انتشار و کنترل به‌روزرسانی بخش مهمی از Snap هستند. در Ubuntu Core، دامنهٔ Snap از برنامه فراتر می‌رود و اجزای سیستم را هم در بر می‌گیرد؛ این وضعیت با Ubuntu Desktop معمولی که همچنان بسته‌های deb دارد یکسان نیست.

۳. ریشهٔ Flatpak: مسئلهٔ انتشار برنامهٔ دسکتاپ#

Alexander Larsson پیش از Flatpak روی چارچوب‌های bundling مانند Glick کار کرده بود. کار روی xdg-app در دسامبر ۲۰۱۴ شروع شد، نخستین نسخه در مارس ۲۰۱۵ آمد و در مه ۲۰۱۶ نام پروژه به Flatpak تغییر کرد. تاریخچهٔ رسمی Flatpak

در مه ۲۰۱۷، Flathub به‌صورت اولیه راه افتاد و در اوت ۲۰۱۸ نسخهٔ Flatpak 1.0 منتشر شد. این دو مسیر را باید جدا دید: Flatpak فناوری اجرای برنامه است و Flathub زیرساخت انتشار و کشف برنامه را فراهم می‌کند. روایت سازندهٔ پروژه نیز مسیر رسیدن از آزمایش‌های اولیه به xdg-app را توضیح می‌دهد. روایت تاریخچه به قلم Alexander Larsson

تمرکز Flatpak از ابتدا مسئلهٔ برنامهٔ دسکتاپ بود: اجرای یک برنامه با محیط کتابخانه‌ای مشخص، بدون اینکه لازم باشد کتابخانه‌های اصلی میزبان را مطابق آن عوض کنیم.

۴. داخل Snap چه ساختاری داریم؟#

یک فایل .snap ایمیج فشردهٔ SquashFS است. snapd آن را به‌صورت فقط‌خواندنی mount می‌کند؛ نصب آن مانند بازکردن تمام فایل‌های بسته در /usr میزبان نیست. متادیتای meta/snap.yaml برنامه‌ها، فرمان‌ها، سرویس‌ها و نیازهای اجرایی را توصیف می‌کند.

Publisher --> Snap Store --> snapd
                               |
                         revision mounted read-only
                               |
                         app + base + interfaces
                               |
                         writable application data

هر بار انتشار در Store یک revision دارد؛ revision را با نسخهٔ قابل‌خواندن برنامه یکی نگیرید. در یک میزبان معمول، فایل‌های دریافت‌شده زیر /var/lib/snapd/snaps/ نگه‌داری و نسخه‌های mountشده معمولاً از مسیر /snap/<name>/<revision>/ دیده می‌شوند. چیدمان بعضی توزیع‌ها متفاوت است. معماری سیستم Snap

بخش قابل‌نوشتن از محتوای بسته جداست: دادهٔ سیستمی معمولاً زیر /var/snap/<name>/ و دادهٔ کاربر زیر ~/snap/<name>/ قرار می‌گیرد. پس فقط‌خواندنی‌بودن ایمیج به معنی نداشتن تنظیمات یا دادهٔ قابل‌تغییر نیست.

۵. base و content در Snap#

برنامه می‌تواند کتابخانه‌های لازم را در بستهٔ خودش داشته باشد. یک base snap نیز محیط پایهٔ اجرا را فراهم می‌کند؛ بنابراین «خودبسنده» به معنی قراردادن تمام جهان در یک فایل نیست. با content interface هم می‌توان محتوایی مانند مجموعهٔ کتابخانه‌ها را میان بسته‌ها به اشتراک گذاشت.

برای ساخت، ناشر در snapcraft.yaml مراحل دریافت source، build و بسته‌بندی را تعریف می‌کند. خروجی برای معماری مقصد ساخته می‌شود؛ یک فایل x86_64 صرفاً به دلیل Snap بودن روی ARM اجرا نمی‌شود.

این جدایی وابستگی به کتابخانه‌های میزبان را کم می‌کند، اما وابستگی به کرنل، امکانات امنیتی و بعضی اجزای میزبان باقی می‌ماند. سازگاری چندتوزیعی نیازمند آزمون است.

۶. محدودسازی Snap: strict، classic و devmode#

حالتمفهوم
strictمحدودسازی دسترسی با سازوکارهای امنیتی و interfaceهای مجاز
classicدسترسی گسترده‌تر، نزدیک‌تر به برنامهٔ معمول میزبان
devmodeحالت توسعه که محدودیت‌ها را برای تشخیص نیاز برنامه اعمال نمی‌کند

در strict، سازوکارهایی مانند AppArmor، seccomp و namespaceها به محدودسازی کمک می‌کنند. interface مسیر تعریف‌شدهٔ ارتباط با قابلیت میزبان است؛ برای مثال شبکه یا بعضی دستگاه‌ها. دامنهٔ محدودسازی به پشتیبانی توزیع و پیکربندی میزبان نیز وابسته است. مدل confinement در Snap

وجود برنامه در Store به‌تنهایی نمی‌گوید strict است. classic را با همان انتظار امنیتی یک برنامهٔ strict نصب نکنید؛ حالت confinement و دسترسی‌ها را بخوانید.

۷. ساختار Flatpak: app، runtime و SDK#

در Flatpak سه جزء کلیدی داریم:

جزءنقش
Appفایل‌ها و متادیتای برنامه
Runtimeمحیط کتابخانه‌ای مشترک برای اجرای برنامه
SDKمحیط و ابزارهای توسعه و ساخت

برنامه به runtime مشخصی مانند خانوادهٔ Freedesktop، GNOME یا KDE متصل می‌شود. کتابخانه‌ای که در runtime نیست می‌تواند همراه خود برنامه بسته‌بندی شود. SDK معمولاً برای ساخت لازم است؛ کاربر عادی صرفاً برای اجرای برنامه به نصب SDK نیاز ندارد. مفاهیم پایهٔ Flatpak

Manifest + SDK --> build --> application repository
                                      |
                                Flatpak install
                                      |
                              app + required runtime
                                      |
                              sandbox + desktop portals

manifest دستور ساخت و مجوزهای موردنیاز را توصیف می‌کند. نام‌هایی مانند org.example.App شناسهٔ برنامه‌اند؛ یک ref کامل نوع محتوا، شناسه، معماری و branch را مشخص می‌کند. branch، شمارهٔ نسخهٔ برنامه نیست و می‌تواند نامی مثل stable داشته باشد.

۸. OSTree و محل نصب Flatpak#

Flatpak از OSTree برای ذخیره و انتشار درخت‌های نسخه‌دار محتوا استفاده می‌کند. محتوا بر اساس checksum شناسایی می‌شود و اشتراک فایل‌های یکسان و دریافت تغییرات می‌تواند مصرف فضا و دانلود را کاهش دهد. این ساختار با یک RPM که روی فایل‌های مشترک سیستم نصب می‌شود فرق دارد. پشت صحنهٔ Flatpak

نصب می‌تواند سیستمی یا مخصوص یک کاربر باشد. مسیرهای پیش‌فرض رایج، /var/lib/flatpak/ و ~/.local/share/flatpak/ هستند؛ دادهٔ خصوصی برنامه معمولاً زیر ~/.var/app/<app-id>/ قرار می‌گیرد. دادهٔ کاربر را با deployment برنامه یکی نگیرید.

یک .flatpakref معمولاً دستور معرفی و نصب یک برنامه از مخزن است؛ .flatpakrepo مخزن را معرفی می‌کند. این فایل‌های کوچک الزاماً خود باینری برنامه نیستند. قالب bundle تک‌فایلی نیز وجود دارد، اما همهٔ نصب‌ها از آن استفاده نمی‌کنند.

۹. sandbox و portal چگونه کنار هم کار می‌کنند؟#

Flatpak با ابزارهایی مانند Bubblewrap و امکانات کرنل محیط اجرای محدود می‌سازد. داخل sandbox، برنامه و runtime محیط خودشان را می‌بینند. دسترسی به فایل‌های میزبان، شبکه، دستگاه و سرویس‌های دسکتاپ تابع مجوزهای برنامه است.

Portal یک واسطه برای درخواست مشخص است. مثلاً برنامه به‌جای دیدن کل home، از پنجرهٔ انتخاب فایل میزبان استفاده می‌کند و به فایل انتخاب‌شده دسترسی می‌گیرد. این مدل نیاز به مجوز گسترده را کاهش می‌دهد. sandbox و portalهای Flatpak

با این حال، یک برنامه می‌تواند مجوزهای ایستای گسترده داشته باشد. sandbox تضمین عمومی امنیت نیست؛ برنامه‌ای با دسترسی کامل home هنوز می‌تواند فایل‌های شخصی را بخواند. محیط Wayland، backend درست portal و رفتار خود برنامه نیز در تجربهٔ واقعی اثر دارند.

۱۰. یک بررسی کوچک روی سیستم موجود#

اگر ابزارها از قبل نصب‌اند، فرمان‌های زیر فقط وضعیت را می‌خوانند:

snap version
snap list
snap connections

flatpak --version
flatpak remotes --show-details
flatpak list --app
flatpak list --runtime

برای برنامهٔ نصب‌شده، نام واقعی را جایگزین کنید:

snap info SNAP_NAME
flatpak info --show-permissions APP_ID

نمونه‌ها در جریان نگارش روی میزبان واقعی اجرا نشده‌اند. به خروجی نگاه کنید: ناشر کدام است؟ runtime یا base چیست؟ برنامه چه دسترسی‌هایی دارد؟ از کدام کانال یا remote آمده است؟ همین اطلاعات نشان می‌دهد که قالب بسته، منبع انتشار و سیاست اجرا سه بخش جدا از یک زنجیره‌اند. استفاده از Flatpak