AOSC

AOSC OS 调研

0 引言

这次调研是继 Clear Linux OS 之后的第二次 OS 调研.

本次探索的对象是安同 OS, 其生态位官方开篇就点出了.

安同 OS(英译: AOSC OS)是一款以 “简明可靠” 为设计及维护目标的 Linux 发行版. 本系统主要面向有一定 Linux 使用经验的用户, 针对个人桌面设备优化体验, 致力于为用户提供开箱即用和简便可靠的工作环境.(https://aosc.io/aosc-os)

通过章节一, 我们可以了解到 AOSC 整体的风格是如何的, 面向的群体又是哪些.

通过章节二三, 我们可以了解到 AOSC 的生态软件, 它着重强调一个跨发行版和通用性, 笔者认为正是这些特性才应了我结尾的思考.

PS: 这里官网十分出戏, 封面较为简洁清新. 初看不太正经, 像是一群二次元开发者的民间杰作. 可喜的是网页给我的感受是访问速度很快很简洁

1 AOSC 的全局观

1.1 系统特性

• 高效工作, 以开箱即用作为主要设计目标, 按照官方的说明来讲笔者认为应该是办公类的软件部署较为快捷, 兼容的比较多.

• 易于管理, 管理工具全面, 简洁易用.

• 高兼容性, 兼容多个发行版的生态, 软件支持广泛.

• 随处可用, 这里指的是兼容平台广泛, 从台式机, 单片机到服务器都有支持.

以上源自对: https://aosc.io/aosc-os#features 的理解

总而言之, 笔者认为 AOSC 把握的更多是民用桌面级的用户(对于老旧设备他们甚至提供了一个子系统星霞 OS, 基于 AOSC 开发), 并且他们可能想拉拢更多平台的用户(这里从随处可用可以感受到), 因为单纯看 AOSC 的介绍能感受到他们提倡的是一种通用简洁性, 这里的单片机、服务器场景是否只是一种附属品, 或者说广泛拉拢用户的手段呢? 这里能感受到 openEuler 社区主营的是企业级的场景, 偏服务器、边缘设备部署, 因此和 AOSC 不在一个竞争位上. 做个比较的话, 笔者认为 openEuler 的定位更像华为的 Mate/P 系列, AOSC 则是小米系列.

1.2 设计理念

1. 软件包的生态绝对是一个发行版最受瞩目的部分之一, 这里 AOSC 对软件包的看法是 “如非必要不切分软件包, 即每个应用一个软件包”

   这里拿 openEuler 和 Ubuntu 举例. 我们分别执行包管理器的 search 命令.

   # openEuler
   # 这里 openEuler 的包反而没那么多, 除去 debuginfo, source 这些包
   # 只有最小运行时的一些包(当然也可能是因为支持不够全面)
   vim.src : Vim is a highly configurable text editor for efficiently creating and changing any kind of text.
   beakerlib-vim-syntax.noarch : Files for syntax highlighting BeakerLib tests in VIM editor
   protobuf2-vim.riscv64 : Vim syntax highlighting for Google Protocol Buffers descriptions
   texlive-context-vim.noarch : Generate Context syntax highlighting code from vim
   texlive-context-vim-doc.noarch : Documentation for context-vim
   vim-X11.riscv64 : Vim for the X Window System i.e.gvim
   vim-common.riscv64 : This contains some common files to use vim editor.
   vim-debuginfo.riscv64 : Debug information for package vim
   vim-debugsource.riscv64 : Debug sources for package vim
   vim-enhanced.riscv64 : This is a package containing enhanced vim editor.
   vim-filesystem.noarch : The vim filesystem.
   vim-minimal.riscv64 : This package provides the basic and minimal functionalities of vim editor.
   # Ubuntu
   # 这里 Ubuntu 下除了我展示的还有更多的包
   ...
   vim-autopep8/noble,noble 1.2.0-3 all
   vim plugin to apply autopep8
   
   vim-bitbake/noble,noble 0~git20220408-2 all
   Vim plugin to interact with Yocto bitbake-based recipes
   
   vim-command-t/noble 5.0.5-1ubuntu1 amd64
   open files with a minimum number of keystrokes
   
   vim-common/noble-updates,noble-updates,noble-security,noble-security,now 2:9.1.0016-1ubuntu7.9 all [已安装, 自动]
   Vi IMproved - Common files
   ...

   在 AOSC 下, 一个包等于一个软件, 比如 vim 所有组件都在一个 vim 包里.

2. “为不同语言的用户提供良好的开箱体验”.

   AOSC 开机默认支持多语言, 中文环境完善(能理解, 毕竟中国贡献者占大头). 核心的理念就是开箱即用.

3. “对开源和闭源软件一视同仁”, 这里指的是收录开源闭源的软件, 按照网友们的讨论来看, AOSC 支持的软件包确实非常齐全. 但是这里笔者存在一些疑惑, 所谓的一视同仁会不会只是一个噱头, 开源闭源软件的采用不是很多发行版都能做到的吗? 官方既然把它拿出来作为一个宣传, 不禁让人思考它能做到什么样的程度, 不过我们可以看到官方对开源和闭源的态度(或许有些发行版对某些闭源软件的采纳更多是一种妥协?).

4. “重视系统可靠性, 在不同架构上提供相近的功能和体验” 笔者认为这两句都在描述 AOSC 对软件包的版本把控上.

   首先 AOSC 的软件包更新采用的是滚动更新, 没错, 这种更新就像 Clear Linux OS 和 Arch Linux 一样. 当然, 这里也是笔者困惑的地方, 作为一个追求稳定的发行版, 不应该同 openEuler 这样每过一定周期出一个新的版本吗? 这与 AOSC 追求的可靠是否相违背?

   就笔者的感官而言, 滚动更新意味着软件总是在变化, 如果要做到可靠, 那么 AOSC 必须要花费十足的精力去 “work around test”.

   这里 AOSC 采取了一个平衡的策略, 他们将仓库进行分级, 以各个包的更新分支, stable 分支为两类, 只有在各个包的分支经过社区的自动化测试验证后才能推送到 stable(或许 AOSC 的测试和审查工具真的是社区的特点? 我们后面观察他们的软件包仓库时再得出结论.).

   仓库的软件维护指南, 这里探讨了 AOSC 软件包更新的思路变更, 在最新的系统中每个软件包都有自己独立的分支, 完成后再 merge 到 stable: https://wiki.aosc.io/developer/packaging/topic-based-maintenance-guideline/

以上源自对: 官方提供的文档 安同适合我吗? 的理解, 更多信息也可以访问这个链接, 该链接中官方很清晰地罗列了自身的优缺点以及使用场景(并且是中文), 但是绕来扰去的议题大多都是在强调自身的简洁可靠.

2 软件生态与构建体系

这里很有趣的现象是, 貌似 AOSC 总是倾向于 rust. 通过观察他们的软件仓库可以发现他们的主流工具都使用了 rust, 并且把 rust 当作一个主语言.

2.1 libLoL(LoongArch on LoongArch)

• 项目文档

• 项目仓库

首先要明确的是这是一个转为 LoongArch 设计的兼容层软件. 这个软件由 AOSC 社区维护, 但是目标群体却是为 LoongArch 公开.

该软件的目的是在新世界系统中为旧世界程序提供运行时的兼容.

举个例子我有一个旧世界的软件, 它是旧世界的ABI编译的, 那么我装了一个新世界的系统, 不通过这个兼容层的软件就无法运行旧世界的软件.

旧世界是指最早在龙芯中科内部适配的、随着 LoongArch 公开一并发布的那个 LoongArch 软件生态. 新世界是指龙芯中科与社区同仁一道, 以典型开源社区协作模式打造的, 完全开源的 LoongArch 软件生态(https://areweloongyet.com/docs/old-and-new-worlds/)

总的来说这是一个因为 ABI 前后不统一产生的产物, 其他架构如果未来出现这种新旧 ABI 的转变是否可以参照这个系统呢?

2.2 oma

• 项目仓库

oma 的中文是小熊猫包管理器(看了一下仓库, 基于 rust 打造), 是 AOSC 默认的包管理器, 是基于 dpkg 的发行版设计的软件包管理器前端(由此看来我们可以跟 Ubuntu 对比一下 apt).

也就是说, 只要是基于 dpkg 的发行版, 我们都可以安装 oma 进行包的管理.

• oma 的一个核心卖点就是命令行式(CMD)和交互式(TUI)的操作(apt无 TUI 的包管理方式). 这里笔者比较好奇的点是, 既然存在 TUI, 为什么不提供一个 GUI 的交互方式呢? 既然作为一个桌面级的 OS 我认为 GUI 的包管理方式是合理的.

• 另外 oma 提供 undo 的操作, 防止误更改.

• oma 的包下载速度更快(多线程下载技术).

• oma 还可以提前安装指定测试软件的分支, 提前试用新包.

那么问题来了, 类比一下 openEuler 是否也存在有升级 dnf 的这样一种可能性? 或者说是否有必要做这样的一项工作?

我的看法是, 可以做但是从利益的角度上来说没必要专门花心思去做, 可以看到虽然 oma 对比 apt 来说是一个全面的升级, 但是他并不是一个新的包管理体系. 简单来说, oma 只是在重新定义 apt, 尽管它更强大, 但是并不至于取代 apt(笔者认为想要所有社区都自发去改成 oma 是一个需要花极大代价去推动的事情), apt 对于我们现阶段来讲是足够去使用的了.

可以看出 AOSC 至少是希望并尝试把 oma 推出社区的 https://aosc.io/news/2025-10-20-oma-on-termux-official

我们也可以看到 oma 是 AOSC 长期在重点发展的一个项目.

图片源自社区用户公告: https://aosc.io/news/list/advisories

2.3 打包软件

• 软件包打包

AOSC 是滚动发版的(仓库只有 stable 一个面向用户的分支, 而 openEuler 实际上有着十分繁杂的版本控制, 笔者认为可能随着版本的更新, 最后的仓库会变得难以维护), 整体发行的时候不使用版本号, 维护着有一个软件包树(aosc-os-abbs, References 已经给出了链接). 软件包树(类似openEuler 的 src-openEuler)里面存放了包的元信息, 包括补丁. AOSC 打包工具就是根据这棵树去构建整个系统. 软件包树里面有核心的组件不能随意更新, 这里并未说明原因, 笔者认为应该是这些工具链的版本可能会对程序的编译以及兼容性造成影响.

对比 ASOC 的软件包树和 openEuler 的 src-openEuler. 可以看到 ASOC 出了 stable 分支以外都是各个软件包自己的测试分支, 而 openEuler 版本比较鲜明.

但与其他滚动发行版不同, aosc-os-abbs 树中有一组特殊的, 包含核心运行时 (GNU C 库等）和工具链（GCC 等）的软件包, 我们将它们统称为 AOSC OS Core. AOSC OS Core 整体以版本号表示组件更新(Core 7.0.1, 7.0.2, 7.1.1 等). (https://wiki.aosc.io/zh/developer/packaging/basics/)

Ciel, ACBS, Autobuild4 被官方用来维护 AOSC 的软件包.

ciel 给打包提供隔离环境, ACBS 提供自动化打包构建功能. 笔者认为 openEuler 的 os_build 貌似本质上自己就会创建隔离环境, ciel 是把 os_build 抽离出来的一种形式产物.

2.3.1 Ciel

• 项目仓库

ciel 被用来创建隔离的打包环境(本质上是利用systemd-nspawn来构建容器环境).

Ciel 的主要功能为管理独立的 AOSC OS 构建环境(通称 BuildKit), 因此 Ciel 不一定需要在 AOSC OS 上运行. 如果您使用的是 Arch Linux, 可以通过 AUR 安装 Ciel. (https://wiki.aosc.io/zh/developer/packaging/basics/)

2.3.2 ACBS

• 项目仓库

ACBS(AOSC Build System) 是管理软件包树以及配置信息的.

看了仓库之后, 笔者的理解是 ACBS 就类似 openEuler 的 obs_build, 可以集成化构建软件包.

ACBS is still under heavy development, but is currently deployed for packaging for AOSC OS.

2.3.3 Autobuild4

• 项目仓库

笔者将 autobuild4 类比为 openEuler 的 rpmbuild. 这里很难区分他们之间的优劣, 前者打包 .deb, 后者打包 .rpm.

不过这里值得一提的是 autobuild4 做了一些有趣的尝试.

• 提供了 API 接口(这里颇为有趣, 这体现了命令行, 库调用两种使用方式, 给了用户多种选择权).

• 还有它的前身 autobuild3 更为有趣, 因为它的设计之初被作为一个通用的跨发行版的打包工具.

  Autobuild3 is distribution neutral and supports various backends: DPKG, the most “native” backend of all, using dpkg-deb and Autobuild variables to control the generation of DPKG control files, and henceforth building the packages.
  RPM, using Autobuild variables to generate .spec files, and invoking rpmbuild to build RPM packages.
  PKGBUILD (coming soon), using Autobuild variables to generate PKGBUILD files, using a temporary install root, to provide makepkg with a fake binary packaging process. (https://wiki.aosc.io/developer/packaging/autobuild3-manual/)

• 支持多种构建工具, cmake, python, rust 等(不过这有时候并非好事, 当支持多种构建方式的时候难免会不便于平台的管理).

3 社区正在做的

3.1 软件本地化

AOSC 作为一个中国群体为主的社区, 十分重视软件的本地化工作, 坚持维护上游的本地化, 并肩负维护《大陆简中自由软件本地化工作指南》 的工作.

3.2 星霞 OS

该 OS 是安同 OS 的精简版. 在优化之后能够跑在各类的老旧设备上. 致力于为各类老旧设备提供持续软件和技术更新.

星霞 OS 支持已经年近三旬的设备, 如搭载 486 处理器的 PC 机和 m68k 处理器麦金塔 (Macintosh) 电脑, 也支持较新的设备, 如来自 2010 年前后搭载的 Intel 凌动 (Atom) 上网本或 PowerPC 处理器的 Mac. 通过配置调优和特性分级等手段, 星霞 OS 可确保各类老旧设备上良好的使用体验.

对 星霞 OS, 这个竞争点也是比较独特的, 在大家都在努力释放机器性能的时候, 这样一个反其道而行之的 OS 设计确实很难有第二个竞品了.

4 总结

笔者认为 AOSC 在主流桌面发行版竞争中处于相对弱势, 理由是他们的目标是桌面级用户.

对于桌面级用户, 首先为什么不用 Windows/MacOS? 有桌面需求并且使用 Linux 的一类人感觉更多是有 Linux 需求的开发者, 但是这里已经有几个广为人知并且持续发展的几类系统, 笔者认为 Ubuntu 已经算是 Linux 社区的一个佼佼者(至少我在使用, 还有 Arch Linux 很火, 因为它确实有创新性质的理念), 目前 AOSC 没有很吸引眼球的设计理念, 只是在其他常见的发行版上对一些工艺进行简化, 因此该发行版整体只适合一些发烧友使用.

相较于 openEuler 社区, AOSC 给笔者的感觉是风格更趋近社区化与民间化, 整体氛围轻松, 缺乏企业级推广的严肃风格. 更明了的说, AOSC 是纯粹爱好者的聚集地, 因此社区的推手不够强大(这里可能主观想法比较多).

但是社区内的软件是否值得去学习呢? 答案是肯定的.

社区始终贯穿着通用, 易用的思想. 可以看到社区里的很多软件的设计之初就作出了一些很有趣的事情. 在笔者看来他们的野心不止是维护的自己的 OS, 他们更多想做的可能是想打造一条通用的软件生态链, 比如 liblol 支持许多发行版, autobuild 系列最初也是面向跨发行版, oma 面向的是 .deb 的生态…

最后一句话总结: AOSC 的软件总是愿意给用户提供多种选择.

5 References

• 社区官网: https://aosc.io/

• AOSC 的软件包树: https://github.com/AOSC-Dev/aosc-os-abbs

• AOSC Wiki: https://wiki.aosc.io/zh/

• AOSC 愚人节公告(可以看出社区较为融洽的氛围): https://aosc.io/news/2019-04-01-april-update

• AOSC 安装体验视频: https://www.bilibili.com/video/BV1yy411e7s4/?spm_id_from=333.337.search-card.all.click