博客

随着我使用的电子产品越来越多，跨度涉及 Linux 桌面/服务器，Android。我发现，备份还原的操作系统配置是有极限的，极限在于它未曾理解，也无法理解数据的意义。

DNS hosts 与软件数据库缓存，在它眼里看来，都是一样的“文件”。

过去

这带来一个想法，就是代码即架构，也就是 Ansible、Terraform 等，但是它们在“代码”，这个概念的理解上，却出了大差错。软件代码，在软件停止运行后，软件的大部分副作用会消失，而那一小部分副作用也可以以测试代码的形式覆盖。

现状

操作系统，并不会随着 Ansible 或者 Terraform 停止运行而关机，其副作用，也不会因为我删除了 Ansible 里的一行代码并重新运行就会消失，于是这时候，便产生了所谓的“配置偏移”，这些传统的代码即架构的软件以“幂等性”来“自欺欺人”式的解决了这个问题，确实“幂等性”很重要，它会避免重复配置或者不必要的重复导致的错误，但是并不能解决这个回滚问题。

然而，大部分操作都是可以回滚的，甚至配置得当，文件删除也是可以回滚的。现代操作系统已经为我们提供了很多回滚工具，git、文件系统快照、甚至最简单的文件回收站。但是，因为从运维角度编码，可复现与回滚，直接萎缩成了一次性快照，也就是 OCI 与 NixOS 之流。

未来

我在这里提出一个新的构建系统，也就是从程序员的角度运维。为一切可以回滚的操作添加支持，如果你在配置代码中删除了一个操作，那么在下次运行时将会对那一个特定操作进行自动回滚。

此外，我也认为安装软件，维护系统这种经验，应该作为群体智慧被编程的方式保留下来，而不是让人们一次又一次的去重复学习简单的劳动。

运维的未来应当像 NixOS，面向功能，而绝非面向软件与包。

这个系统应当满足以下特性：

1. 面对终端的普通用户
2. 面对目标，也就是面对一些“单元测试”，因为操作系统应当为功能服务，而不是软件这个概念
3. 可回滚
4. 单机应用，可以远程运行，但是应当首要支持单机运行
5. 与现有的运维技术兼容，并尽量使用现有的运维技术进行配置（初版暂定使用 Ansible），我们的世界不需要更多轮子了
6. 可自动检查一个现有的，已经配置的操作系统，并生成配置代码
7. 逻辑代码应当灵活，这个项目提出的一部分原因就是希望推进 Gentoo 的发展。（源码的自由是选择的自由，也是保证自由的基石）

对于 Android

而这个系统在 Android 上的体现会是 UpgradeAll

因为我希望 UpgradeAll 可以拥有这些特性：

1. 从源码编译（你可以随意使用开发者没有合并的分支与功能）
2. 面对开发者友好（你可以编程你的更新流程）
3. 面对用户友好（你可以只考虑需要什么功能，而不是寻找应用，这应该让开发者来做，参考 quickenergy）
4. 促进 Android 应用开放化（Android 应用的封闭性在我看来有很大部分是因为深刻骨髓的二进制分发，tui）