Helios：为 Oxide Rack 提供动力的 Illumos 发行版
Oxide Computer 新近开源的 Helios 操作系统是一个基于 Illumos 的发行版，为一个垂直整合的机架级服务器平台提供底层支持，目标是在客户自己的数据中心里提供类似 AWS 的体验。评论者权衡了选择 Illumos 与 bhyve hypervisor 而非 Linux 与 KVM 的技术和商业取舍，指出其在整体一致性、可观测性、与 ZFS 的集成以及全栈控制方面的优势，同时也提出了对生态熟悉度、供应商依赖、缺少 GPU 以及容器原生特性的担忧。许多人认为，这一产品对于传统本地部署方案以及日益昂贵或受限的云和 VMware 方案来说，是一个利基但及时的替代选择，尤其适合大型企业和研究机构。
产品与架构
- Helios 是一个基于 illumos 的操作系统发行版，为 Oxide 垂直整合的机架级系统提供动力。
- 该操作系统在很大程度上只是内部实现细节：客户通过 API 来部署虚拟机；他们通常不会直接与 Helios 交互，也不会在 illumos 上部署应用。
- Hypervisor 栈使用基于 bhyve 的 VMM（Propolis）。机架被设计为整体性的软硬件单元（共享电源、集成交换机、定制固件、基于 Rust 的控制平面）。
为什么选择 illumos 而不是 Linux
- 提到的主要原因包括：团队对其深度熟悉、能够“掌控整个技术栈”，以及更适合构建和维护一个完整发行版（内核 + 库 + 用户态），而不是拼装众多 Linux 组件。
- illumos/ZFS/DTrace 的技术传承、代码质量和整体一致性被视为长期维护和调试的优势。
- 有人认为 Linux 更大的生态和更高的熟悉度会让招聘和供应商集成更容易；也有人反驳说，应该招聘具有学习能力的人，并把所需专业知识内化到团队中。
工作负载模型：虚拟机、容器、兼容性
- 窄腰是虚拟机：Helios 可以原样运行 Linux、Windows、*BSD 等作为来宾操作系统。
- 容器/Kubernetes 通常会运行在 Linux 虚拟机内部；目前还没有内建的一方容器平台。
- 目前不支持嵌套虚拟化或 GPU，这限制了某些工作负载（例如 kubevirt、Firecracker、WSL2、GPU/LLM 使用场景）。
客户价值主张与市场契合度
- 定位为“在你自己的数据中心中提供云式 API”：面向本地部署的交钥匙基础设施，集成计算、存储和网络。
- 目标客户包括必须或偏好本地部署的组织（大型企业、研究实验室、金融机构），以及希望拥有单一供应商、紧密集成方案来替代自建硬件 + VMware/OpenStack 的用户。
- 成本竞争力存在争议；有人认为这些机架可以在多年时间尺度上压过公有云支出，尤其适用于数据密集型工作负载。
顾虑：锁定、风险、利基
- 有人担心依赖一家规模较小、拥有自定义操作系统/Hypervisor 的供应商，并且 illumos/bhyve 方面的广泛经验不足。
- 也有人认为供应商特定的 hypervisor 本就很常见（AWS Nitro、Azure 的主机操作系统、ESXi），而 Oxide 的开放性以及虚拟机可移植性可缓解锁定风险。
- 该产品仍处于早期且较为利基；一些人认为国家实验室和大型金融机构是自然的早期采用者。
开源、许可与社区
- Helios 采用 MPL 2.0 许可；公司政策倾向于新代码使用 MPL，但在生态中已有主流许可的情况下会例外（例如 Rust crate 使用 Apache/MIT）。
- 固件和硬件设计计划随着时间开放，以降低如果公司失败后变成“镇纸”的风险。
- 讨论中提到了 illumos 的构建复杂度和开发者上手难度；维护者承认存在权衡和资源有限的问题，但表示通过多个发行版仍在积极开发。