设计分层的桌面与开发环境

分层设计的目标#

桌面、系统服务与开发环境由 Nix 定义；需要不同运行时、发行版工具链或专属应用的部分，选择 Flatpak、Distrobox 或虚拟机承担。分层的目标是让依赖、状态、权限和恢复路径清楚，而不是宣称所有层都有绝对隔离。

第一层：宿主机与开发基础#

宿主机保留桌面、终端、网络、输入法、Git 和必要的系统集成。项目编译器、交叉工具链与语言依赖进入项目级 devShell，固定 inputs 和 lock；使用 Python 环境管理器时也应明确其可写目录和锁文件，避免把项目依赖混入系统 profile。

验证时分别检查系统 closure、项目 shell 内的工具版本与实际编译结果。配置可构建只说明声明有效，不能证明硬件访问和桌面会话正常。

第二层：Flatpak 应用与权限#

需要独立应用运行时的桌面软件可以交给 Flatpak。应用包、remote、覆盖权限和用户数据应由明确的管理层负责。services.flatpak.packages 与 services.flatpak.overrides 常见于第三方 nix-flatpak 模块，不是所有 NixOS 配置自带的原生选项；先导入并锁定该模块再使用。

针对每个应用只开放必要目录，并分别核对 Wayland/X11、D-Bus、portal、网络和输入法接入。声明权限不代表 100% 安全；应用版本、运行时及 portal 行为也会改变实际权限边界。用以下只读命令核对实际状态：

flatpak info --show-permissions <APP_ID>
flatpak override --show <APP_ID>

第三层：Distrobox 兼容环境#

Distrobox 提供可变发行版用户空间，适合已有发行版包、特殊插件或难以直接适配的工具。创建前决定容器镜像、版本、独立 HOME 与共享目录，避免默认把宿主机整个 HOME 暴露给不需要的应用。

# 示例：使用单独 HOME；实际 image 应锁定版本或 digest
distrobox create --name compat-dev --image <CONTAINER_IMAGE> --home ~/containers/compat-dev
distrobox enter compat-dev
# 在容器内，按需导出桌面入口
distrobox-export --app <APPLICATION>

Distrobox 为方便使用会集成宿主机目录、显示、音频和设备；它不是针对不可信软件的安全边界。容器内安装软件改变容器状态，不能替代宿主机 Nix 配置。记录容器建立步骤和包状态，并分别测试导出的入口、硬件权限和 GUI 启动。

第四层：KVM 与专属应用虚拟机#

仅能在其他操作系统运行的应用可以放入 KVM/QEMU 虚拟机。按负载分配 vCPU、内存与存储，先验证完整 VM 的启动、许可证、驱动和应用，再考虑共享目录、剪贴板或 RDP 窗口集成。

WinApps 等 RDP 集成工具可把客体应用窗口呈现到宿主机桌面；兼容性取决于客体系统、RDP 服务、工具版本和 compositor，不应保证任意应用都像原生程序一样工作。共享目录、设备直通与远程显示都会减少原本的隔离范围。

第五层：独立服务器任务#

适合长时间运行的服务可部署到独立服务器，本地保留受控的管理入口。分离配置、运行数据、密钥和备份；云服务故障、网络中断与费用属于新增加的运行约束。将部署 build、test、switch 与运行观测分别记录，不把本地终端能连接当成服务已正确工作。

验收与恢复#