Haiku OS 的 arm64 版本已经能在 M1 MacBook Air 上裸机启动，并进入桌面。
这里最容易看错的一点是：这不是在 Mac 上开一个 UTM/QEMU 虚拟机跑 Haiku。开发者 smrobtzz 在 Haiku 社区论坛确认，这次是通过 m1n1 与 u-boot 处理 Apple Silicon 特有启动流程，再从 USB 启动 UEFI 镜像。
所以，这条进展很有意思，但不能写成 Haiku 已经支持 Apple Silicon。更准确的说法是：M1 MacBook Air 上的早期移植跑通了第一段路，离日常可用还很远。
M1 裸机启动已经打通，但范围很窄
这次最硬的事实，是 Haiku arm64 能在真实 M1 MacBook Air 上进桌面，并确认 8 个 CPU 核心运行。
这说明启动链路已经可行。对替代操作系统社区来说，这一步不小。Apple Silicon 不是普通 ARM 笔电，启动流程、硬件初始化、显示路径都需要额外适配。
但范围也要说清楚。目前材料只明确到 M1 MacBook Air，不能外推到所有 M1、M2、M3 Mac，也不能外推到其他 ARM64 笔电。
| 场景 | 当前状态 | 主要限制 | 该怎么理解 |
|---|---|---|---|
| M1 MacBook Air 裸机 | 已启动到桌面，8 核运行 | USB 勉强可用，显示刚做初步修正 | 移植路径打通，不等于可日用 |
| UTM/QEMU | Haiku arm64 也能启动 | 鼠标移动慢，体验卡顿 | 适合验证系统，不适合当体验环境 |
| 其他 ARM64 设备 | 未确认支持 | Pinebook Pro 这类设备仍需有人适配 | 不能因为 arm64 就默认能跑 |
显示问题也能看出这次移植的阶段。早期画面有明显颜色异常，后来开发者加入了色彩空间转换。M1 原生显示格式被描述为 32-bit RGB、每通道 10-bit，这不是简单改个分辨率就能解决的事。
这对普通用户的结论很直接：如果你只是想找一个能在 M1 Mac 上尝鲜的桌面系统，现在应该观望。不要拿它替代 macOS，也别指望它能当备用工作环境。
真正卡住可用性的，是 USB、包和开发环境
能进桌面，只是证明机器会亮。
现在更卡人的地方在系统周边。USB 目前只到 barely functional 的程度。UTM 中虽然也能启动 Haiku arm64，但鼠标移动慢，而且卡顿。对桌面系统来说，这些不是小毛病。
包管理和开发环境更关键。当前 nightly 镜像缺少 git、gcc 等开发包，想直接在系统里拉代码、编译、调试，并不顺手。
还有用户反馈，pkgman 安装包时会遇到 operation not supported。维护者判断，这可能和镜像构建时缺少 OpenSSL 支持有关。arm64 仓库里的可用包也有限，因为还没有稳定的 haikuports builder 在持续产包。
这影响最大的不是普通玩家，而是想参与移植的人。
他们现在更现实的做法，是把 M1 裸机环境当成测试目标，而不是主开发环境。工具链要尽量放在交叉编译或 bootstrap 流程里，别把希望都压在 nightly 镜像自带包上。
换句话说，当前的 Haiku arm64 更像一台会亮屏的工程样机。它能证明方向，但还不能降低参与门槛。
接下来要看构建流水线，而不是下一张截图
后续最该看的，不是桌面截图能不能更漂亮，而是 arm64 生态能不能自己供血。
开发者提到，bootstrap image 可以交叉构建 gcc 等开发工具。理论上，也可以继续用 haikuporter 构建更多 arm64 包。
维护者 PulkoMandy 也提到，未来可能需要给 haikuports 设置 buildbot。如果能在原生 ARM 系统或 ARM 虚拟化环境上跑，构建速度会比纯 CPU 仿真更现实。
这里的判断标准很简单：
- nightly 镜像里能不能补上 git、gcc 这类基础开发包；
- pkgman、OpenSSL、仓库包安装能不能稳定下来；
- haikuports 是否出现面向 arm64 的持续构建能力；
- M1 MacBook Air 之外的设备，是否有人愿意做具体适配。
这些条件不满足，Haiku 在 M1 上启动就仍是早期移植进展。满足其中几项，它才有机会从“能跑”走向“能被维护”。
Linux 在 Apple Silicon 上已有 Asahi Linux 这样的专门项目，投入多年仍要逐步补 GPU、音频、电源管理等细节。Haiku 的社区规模更小，更不能跳过这些脏活累活。
能启动是门槛。能长期产包、修驱动、跑回归，才是系统。