RFC-0002：Asterinas NixOS

狀態：已批准
拉取請求：https://github.com/asterinas/asterinas/pull/2584
提交日期：2025-11-14
批准日期：2025-12-01

摘要

本 RFC 正式提議建立 Asterinas 散佈版，作為 Asterinas 的全新頂級子專案。我們打算利用 NixOS 的卓越訂製能力與豐富的軟體包生態系統來打造此散佈版。因此，我們提議將此新子專案命名為 Asterinas NixOS (AsterNixOS)。

In the context of operating systems (OSes), a “distribution” (or “distro”) typically refers to a complete OS built around a kernel, complemented by userspace tools, libraries, and applications managed via a package management system. A Linux distro, for example, combines the Linux kernel with a rich userspace. Similarly, an Asterinas distro will pair the Asterinas kernel with a comprehensive userspace environment. For the purpose of this discussion, “distro” will refer broadly to either a Linux or Asterinas-based distro.

短期策略優勢

Achieving a Minimum Viable Product (MVP) milestone is crucial for Asterinas’s maturation. Reaching MVP means that Asterinas is ready for evaluation by early adopters, who expect a seamless experience comparable to mainstream OSes. This includes easy application installation and out-of-the-box functionality. Simply providing a kernel is insufficient; we must deliver a user-friendly experience, which necessitates a full-fledged distro complete with an intuitive package manager.

Furthermore, direct control over an Asterinas distro offers a pragmatic approach to addressing Linux compatibility challenges. While Asterinas is committed to a high degree of Linux compatibility, achieving perfect parity in the near term is impractical. A dedicated distro allows us to configure or patch specific packages to circumvent reliance on advanced or bleeding-edge Linux features that do not have high priority in Asterinas. This significantly reduces pressure on Asterinas kernel developers to implement complex features prematurely, enabling a more focused and stable development roadmap.

Beyond external users, Asterinas developers themselves will greatly benefit from a dedicated distro. Testing complex applications with intricate dependencies is a significant hurdle. While “Hello World” or even medium-sized projects like Nginx or Redis can be manually built and integrated into a disk image, this approach does not scale for complex applications such as Spark, PyTorch, or Chromium. Identifying, understanding, and building every dependency for such projects would divert critical kernel development resources. A distro, by its very nature, abstracts this complexity through its package manager, streamlining the testing and development workflow for all Asterinas developers.

長期生態系統願景

展望未來，我們預見一個蓬勃發展的 Asterinas 散佈版生態系統。這個最初由內核開發者維護的散佈版將作為至關重要的參考實現，促進各種基於 Asterinas 的散佈版誕生。雖然 Linux 世界擁有眾多的散佈版，但針對 Asterinas 的散佈版將不可或缺，主要原因有二：

首先，Asterinas 優先考慮的是外部 ABI 層級的 Linux 相容性，而非內部內核模組介面。這意味著 Asterinas 無法載入 Linux 內核模組（.ko 檔案）。Asterinas 散佈版將確保所有系統程式僅載入 Asterinas 內核模組。

其次，Asterinas 最終將提供 Linux 所不具備的功能與價值主張——例如，全新的系統呼叫、檔案系統以及裝置驅動程式。只有當應用程式能夠偵測並利用這些優勢時，這些效益才會真正實現。

Asterinas 散佈版是實現此目標的自然載體。它可以提供專為 Asterinas 編寫的新軟體包，並對現有軟體包進行修補，使其具備「Asterinas 感知」能力，確保使用者空間能有效地利用內核的獨特功能。

In essence, establishing Asterinas distros is paramount for Asterinas’s long-term success and differentiation. This RFC lays the groundwork for that future by proposing our foundational distro.

設計

為什麼選擇 NixOS 作為基礎散佈版？

從零開始建置第一個 Asterinas 散佈版將是一項巨大的工程，會分散核心內核開發的精力。因此，基於現有的 Linux 散佈版是最理性的前進方向。這引出了一個關鍵問題：應該選擇哪一個 Linux 散佈版作為我們的基礎？

Linux 散佈版的版圖非常廣闊，其中包含許多著名的名稱，例如 Arch、CentOS、Debian 和 Gentoo。雖然理論上其中任何一個都可以使用，但我們發現 NixOS 是一個特別吸引人且具有獨特優勢的選擇。

在大多數的散佈版中，軟體包配方（package recipes）主要圍繞著外殼腳本（例如 Arch Linux 中的 PKGBUILD 或 Debian 軟體包中的 rules 檔案）。然而，NixOS 使用一種專門用於建置的純函式型語言，稱為 Nix，它為定義軟體包配方提供了無與倫比的表達能力與靈活性。

A core requirement for our base distro is the ability to easily tweak existing package recipes to work around Asterinas’s limitations or customize the new distro’s look or behavior. The Nix language excels in this regard.

For instance, consider overriding specific attributes of an existing Nix package, such as xfdesktop, with minimal code:

{ pkgs }:
{
  xfdesktop = pkgs.xfce.xfdesktop.overrideAttrs (oldAttrs: {
    version = "4.16.0";
    patches = (oldAttrs.patches or []) ++ [
      ./patches/xfdesktop4/0001-Fix-not-using-consistent-monitor-identifiers.patch
    ];
  });
}

This Nix file creates a customized xfdesktop package without requiring intrusive modifications to its original recipe. This capability, known as the override design pattern in Nix, is uniquely feasible due to Nix’s first-class functions and lazy evaluation.

Another powerful example of NixOS’s flexibility is how easily we can create an Asterinas distro ISO installer by customizing an existing NixOS installer ISO. Consider the following iso-image.nix file:

{ lib, pkgs, ... }:
let
  asterinas_kernel = builtins.path { path = "asterinas_bin"; };
  auto_install_script = pkgs.replaceVarsWith {
    src = "./auto_install.sh";
    isExecutable = true;
    replacements = {
      shell = "${pkgs.bash}/bin/sh";
      inherit asterinas_kernel;
    };
  };
  configuration = {
    imports = [
      "${pkgs.path}/nixos/modules/installer/cd-dvd/installation-cd-minimal.nix"
      "${pkgs.path}/nixos/modules/installer/cd-dvd/channel.nix"
    ];

    services.getty.autologinUser = lib.mkForce "root";
    environment.loginShellInit = "${auto_install_script}";
  };
in (pkgs.nixos configuration).config.system.build.isoImage

This file defines a new installer ISO that differs from the original in two key ways. First, it ships with the Asterinas kernel (asterinas_kernel). Second, instead of dropping the user into an interactive shell, the ISO’s init process immediately runs an automatic installation script (auto_install.sh).

A notable NixOS feature relevant to our design is /etc/nixos/configuration.nix, the primary configuration file that determines all system-wide states of a NixOS installation, including the kernel, installed software, and configuration. A minimal configuration.nix for our distro might look like this:

{ config, pkgs, lib, ... }:
{
  # Do not edit the following system configuration for Asterinas NixOS
  nixpkgs.overlays = [ (import ./asterinas.nix) ];

  # Edit this list to add or remove installed software
  environment.systemPackages = with pkgs; [
    gcc
    python33
    vim
  ];
}

Here, the sample configuration.nix uses a NixOS feature called overlays to customize and extend Nixpkgs without modifying its upstream source. Overlays apply globally within the configuration, so our Asterinas-specific changes to vanilla NixOS can be expressed cleanly as reusable overlays rather than as ad-hoc patches scattered throughout the system.

NixOS 的一個顯著優勢在於它的軟體包管理器 Nix（以及它所使用的 Nix 語言）具備高度的可移植性，可跨多種 Linux 散佈版甚至在 macOS 上運作。

Unlike most package managers, which are tightly coupled to their parent distros (e.g., pacman for Arch, dpkg for Debian, rpm for Red Hat-based systems), Nix operates independently. Nix packages are installed in the /nix/store directory, ensuring they do not conflict with native packages. This portability is invaluable for debugging: if a package in our NixOS-based distro encounters an issue, we can replicate the exact same package environment on any Linux development machine, greatly simplifying troubleshooting.

The New Top-Level Sub-Project

Given these compelling rationales, we propose the creation of a new top-level sub-project named Asterinas NixOS (AsterNixOS). This sub-project will reside in a new distro/ directory at the project root.

Initially, AsterNixOS will share version numbers with the Asterinas kernel, emphasizing its early development stage and close coupling. Every kernel release will be accompanied by a compatible distro release. In the long term, once both the kernel and the distro achieve maturity and stability, AsterNixOS will adopt its own independent versioning scheme, likely following a “YY.MM” format (e.g., 25.12).

Drawbacks, Alternatives, and Unknowns

缺點

Nix/NixOS 的學習曲線： 這可說是最大的障礙。儘管功能極其強大，但 Nix 生態系統（包括 Nix 語言及其函式型範式）與傳統的軟體包管理器和建置系統相比，學習曲線更為陡峭。這可能會對新貢獻者以及不熟悉 Nix 的現有 Asterinas 開發者造成初步門檻。因此，投入資源建立清晰的文件與入職資源將至關重要。
Maintenance overhead of Nixpkgs overlay: While the override pattern offers flexibility, maintaining a dedicated overlay for Asterinas-specific patches and configurations within the vast nixpkgs repository will still require continuous effort. Keeping pace with upstream nixpkgs changes, resolving potential conflicts, and ensuring compatibility will be an ongoing challenge requiring dedicated resources.

Alternatives

Embedded Linux distros: Buildroot and Yocto are established and highly capable tools for building embedded Linux distros, offering extensive customization for toolchains and root filesystems from scratch.
- Why NixOS is superior: While powerful for embedded use cases, Buildroot and Yocto are less oriented toward a general-purpose desktop/server distro, which is our primary initial target. Furthermore, their configuration languages are generally less expressive and composable than the Nix language, limiting the flexibility we seek for deep customization and elegant overriding.
Direct port of Debian/Arch/etc.: This approach would involve directly modifying the build systems of a more traditional distro like Debian or Arch to target Asterinas.
- Why NixOS is superior: As elaborated, traditional packaging systems are less flexible for the granular, targeted patching and configuration required when adapting to a new kernel. More critically, their package managers (e.g., dpkg, pacman, rpm) are inherently tied to their parent distros, making cross-distro development and debugging significantly more complex. The Nix package manager’s portability offers a clear advantage here.

Prior Art and References

The NixOS project itself serves as the most prominent piece of prior art, demonstrating the viability and advantages of a purely functional approach to OS configuration and package management. Its design principles, particularly around atomic upgrades, rollbacks, and reproducible builds, have been thoroughly proven since its inception in 2003. Other projects, like GNU Guix, also follow a similar functional package management paradigm.

The Asterinas Book