TryNix هر نسخه‌ای از بسته‌های Nix را مستقیماً در مرورگر اجرا می‌کند

تصور کنید می‌خواهید یک ابزار قدیمی یا نسخه‌ای خاص از یک نرم‌افزار را تست کنید، اما نمی‌خواهید کل سیستم‌عامل خود را برای یک آزمایش ۵ دقیقه‌ای به هم بریزید. حالا می‌توانید با باز کردن یک تب در مرورگر، یک ماشین لینوکس کامل را بوت کنید و هر نسخه‌ای از بسته‌های Nix را فوراً اجرا کنید.

TryNix که در ۶ سپتامبر ۲۰۲۶ عرضه شد، با اجرای باینری‌های x86_64 در یک ماشین مجازی مبتنی بر وب‌اسمبلی (WebAssembly) — که شبیه به یک مترجم جهانی است و اجازه می‌دهد کدهای پیچیده در هر مرورگری اجرا شوند — نیاز به نصب محلی را به‌طور کامل حذف کرده است.

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

معماری فنی

به نقل از سازنده این پروژه، fzakaria، این سامانه بدون نیاز به سرور بک‌اند عمل می‌کند. صفحه وب از فایل‌های استاتیک تشکیل شده که سه مؤلفه اصلی را مدیریت می‌کنند:

• nixpkgs-multiverse: فهرستی از تمام نسخه‌های تمام بسته‌هایی که تا به حال در Nixpkgs عرضه شده‌اند. این سیستم مسیر دقیق ذخیره‌سازی برای بیش از ۳۱۰,۰۸۳ نسخه از بسته‌ها را فراهم می‌کند. این دستاورد نتیجه کارهای گسترده‌تری مثل grail (که به سیستم بازه‌های نسخه‌ای را آموخت) و omniflake (که اجازه داد بیش از ۱۶ هزار فلیک از یک ورودی واحد اضافه شوند) است.
• QEMU-Wasm: یک هسته لینوکس که در محیط وب‌اسمبلی اجرا می‌شود و یک محیط واقعی x86_64 را درون تب مرورگر بوت می‌کند. این بخش صرفاً به عنوان یک کنسول سریال عمل می‌کند؛ یعنی فقط برای برنامه‌های خط فرمان است و رابط گرافیکی ندارد.
• کش‌های عمومی (Public Caches): ذخیره‌سازهای باینری مانند cache.nixos.org و Cachix که فایل‌ها را با هدرهای باز CORS (یعنی access-control-allow-origin: *) ارائه می‌دهند و به مرورگر اجازه می‌دهند بسته‌های مورد نیاز را دریافت کند.

سازوکار اتصال قطعات

این مکانیزم بر یک جریان داده مشخص تکیه دارد تا یک بسته را از کش به یک شل (Shell) فعال منتقل کند. این زنجیره به ترتیب زیر است:

• صفحه وب: تب مرورگر نقش هماهنگ‌کننده (Orchestrator) را دارد.
• فهرست: صفحه از nixpkgs-multiverse استعلام می‌گیرد تا یک ویژگی (Attribute) و نسخه خاص را به یک مسیر ذخیره‌سازی (Store Path) متصل کند.
• کش: صفحه درخواست narinfo و NARها را از یک کش (مانند cache.nixos.org) ارسال می‌کند.
• ذخیره‌ساز: بسته دریافت شده و در یک ذخیره‌ساز Nix که در حافظه موقت (In-memory) قرار دارد، باز می‌شود.
• ماشین مجازی: این ذخیره‌ساز از طریق یک سیستم فایل 9p به هسته لینوکس qemu-wasm x86_64 ارائه می‌شود.
• ترمینال: ماشین مجازی خروجی را به یک شبیه‌ساز ترمینال در صفحه می‌فرستد و شل را در اختیار کاربر قرار می‌دهد.

گسترش اکوسیستم کش

یکی از مهم‌ترین یافته‌های TryNix این است که محدود به کش‌های عمومی نیست. طبق مستندات پروژه، هر سرور فایل استاتیک که هدر access-control-allow-origin: * را پشتیبانی کند، می‌تواند به عنوان یک کش باینری عمل کند.

fzakaria متوجه شد که GitHub Pages این هدر را برای تمام فایل‌ها به‌صورت رایگان ارائه می‌دهد. این یعنی کاربران می‌توانند مسیرهای ذخیره‌سازی که خودشان ساخته‌اند را به اشتراک بگذارند. برای مثال، یک نسخه تغییریافته از GNU hello که روی GitHub Pages میزبانی شده، حتی اگر در کش رسمی cache.nixos.org وجود نداشته باشد، در مرورگر بوت می‌شود.

این قابلیت نتیجه یک تلاش بلندمدت است. پنج سال پیش، fzakaria ایشو شماره ۱۵۶ را به cache.nixos.org ارسال کرد و درخواست کرد تا هدر CORS باز شود تا از یک مشخصات OpenAPI پشتیبانی شود. همان درخواست، زیربنای تبدیل مرورگر به یک کلاینت Nix واقعی و مشروع شد.

غلبه بر گلوگاه‌های عملکرد

بوت کردن یک هسته تحت شبیه‌سازی معمولاً کند است، اما TryNix از تکنیک «گرفتن عکس» (Snapshotting) استفاده می‌کند تا تجربه کاربر آنی به نظر برسد. به‌جای بوت کردن از صفر، سایت یک ماشین مجازی را که درست قبل از متصل کردن ذخیره‌ساز متوقف شده بود، از سر می‌گیرد.

برای رسیدن به این سرعت، چندین ترفند بهینه‌سازی به کار رفته است:

• پیش‌دریافت پس‌زمینه: موتور و اسنپ‌شات ماشین مجازی قبل از اینکه کاربر روی لینک کلیک کند، در پس‌زمینه دانلود می‌شوند.
• اسنپ‌شات‌های پیش‌بوت شده: یک ماشین یک‌بار روی نسخه Native از همان QEMU بوت شده و متوقف می‌شود. بازدیدهای بعدی صرفاً این اسنپ‌شات را از کش مرورگر بازیابی می‌کنند.
• بهینه‌سازی با مدل‌های زبانی: سازنده پروژه اشاره کرد که مدل‌های زبانی بزرگ (LLM) به او کمک کردند تا گلوگاه‌های عملکردی خاص و فرصت‌های بهینه‌سازی را شناسایی کند و پروژه را از یک «ایده جالب» به یک ابزار کاربردی تبدیل کند.

سرعت اجرا همچنان یک چالش است زیرا باینری‌ها از x86_64 به وب‌اسمبلی ترجمه می‌شوند. اولین اجرای یک برنامه کند است، اما اجراهای بعدی به‌دلیل ذخیره ترجمه در حافظه، سریع‌تر می‌شوند.

محدودیت‌های حافظه و ذخیره‌سازی

کاربران توسط معماری حافظه مرورگر محدود هستند. در حال حاضر سقف سخت برای اندازه بسته (Closure size) حدود ۱.۵ گیگابایت است، زیرا وب‌اسمبلی در یک فضای آدرس ۳۲ بیتی با حداکثر ۴ گیگابایت عمل می‌کند.

به‌دلیل اینکه باینری‌های Nix وابستگی‌های خود را با مسیرهای مطلق (RUNPATH) — حتی تا سطح لودر و libc — تعریف می‌کنند، کاربران می‌توانند چندین نسخه از یک بسته — مثلاً دو نسخه مختلف از برنامه hello — را به‌طور هم‌زمان و بدون تداخل اجرا کنند. پس از شروع ماشین مجازی، کاربران می‌توانند مسیرهای ذخیره‌سازی بیشتری را بدون نیاز به ری‌بوت یا استفاده از مدیریت بسته‌هایی مثل dnf یا apt-get به ماشین در حال اجرا اضافه کنند.

فراتر از یک دمو

این مکانیزم نحوه اشتراک‌گذاری و تست نرم‌افزار توسط توسعه‌دهندگان را دگرگون می‌کند. به‌جای تکیه بر اسکرین‌شات یا کلون کردن محلی، یک بات می‌تواند در Pull Request لینکی قرار دهد که دقیقاً همان مصنوعات (Artifacts) تولید شده توسط یک خط لوله CI را بوت می‌کند. اگر یک CI خروجی را به کشی مثل Cachix بفرستد، بازبین می‌تواند با یک کلیک تست کند که آیا باگ رفع شده است یا خیر، بدون اینکه نیاز به کلون کردن مخزن (Repo) داشته باشد.

سایر کاربردهای احتمالی عبارتند از:

• مصنوعات عامل‌ها: عامل‌های هوش مصنوعی (AI Agents) می‌توانند مسیرهای ذخیره‌ساز Nix را به عنوان مصنوعات تولید کنند تا انسان‌ها یا عامل‌های دیگر آن‌ها را در تب مرورگر بوت کرده و تست‌ها را اجرا کنند.
• گزارش باگ‌های بازتولیدپذیر: عبارت «روی سیستم من کار می‌کند» تبدیل به یک URL می‌شود. گزارش باگ می‌تواند محیط خودش را برای بازتولید آنی حمل کند.
• مستندات قابل اجرا: آموزش‌ها می‌توانند به یک محیط شل پین‌شده لینک دهند که دقیقاً نسخه ابزار مورد نیاز را دارد و مرحله «نصب» را برای خواننده حذف کنند.
• باستان‌شناسی نرم‌افزاری: کاربران می‌توانند نسخه‌های تاریخی نرم‌افزارها را اجرا کنند تا رفتار آن‌ها را بررسی کنند. این شامل اجرای نسخه‌ای از پایتون سال ۲۰۱۷ یا نسخه‌ای از برنامه hello سال ۲۰۰۵ است تا تفاوت‌های آن با نسخه‌های مدرن دیده شود.

TryNix با ارائه یک محیط بازتولیدپذیر در مرورگر، فلسفه Nix مبنی بر بازتولیدپذیری مطلق را از ترمینال به وب منتقل کرد. سورس این پروژه در github.com/fzakaria/trynix در دسترس است.

گام بعدی شما

• اگر توسعه‌دهنده هستید، سعی کنید یک بسته سفارشی را روی GitHub Pages میزبانی کنید و لینک اجرای آن را با دیگران به اشتراک بگذارید.
• برای تست سریع ابزارهای خط فرمان بدون تغییر در سیستم خود، از TryNix به عنوان یک Sandbox موقت استفاده کنید.
• بررسی کنید که آیا می‌توانید در مستندات پروژه‌های خود، به‌جای دستورات نصب، لینک‌های محیط‌های آماده TryNix را قرار دهید.

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