随着我使用的电子产品越来越多，跨度涉及 Linux 桌面/服务器，Android。我发现，备份还原的操作系统配置是有极限的，极限在于它未曾理解，也无法理解数据的意义。
DNS hosts 与软件数据库缓存，在它眼里看来，都是一样的“文件”。
目录
过去
这带来一个想法，就是代码即架构，也就是 Ansible、Terraform 等，但是它们在“代码”，这个概念的理解上，却出了大差错。软件代码，在软件停止运行后，软件的大部分副作用会消失，而那一小部分副作用也可以以测试代码的形式覆盖。
现状
操作系统，并不会随着 Ansible 或者 Terraform 停止运行而关机，其副作用，也不会因为我删除了 Ansible 里的一行代码并重新运行就会消失，于是这时候，便产生了所谓的“配置偏移”，这些传统的代码即架构的软件以“幂等性”来“自欺欺人”式的解决了这个问题，确实“幂等性”很重要，它会避免重复配置或者不必要的重复导致的错误，但是并不能解决这个回滚问题。
然而，大部分操作都是可以回滚的，甚至配置得当，文件删除也是可以回滚的。现代操作系统已经为我们提供了很多回滚工具，git、文件系统快照、甚至最简单的文件回收站。但是，因为从运维角度编码，可复现与回滚，直接萎缩成了一次性快照，也就是 OCI 与 NixOS 之流。
未来
我在这里提出一个新的构建系统，也就是从程序员的角度运维。为一切可以回滚的操作添加支持，如果你在配置代码中删除了一个操作，那么在下次运行时将会对那一个特定操作进行自动回滚。
此外，我也认为安装软件，维护系统这种经验，应该作为群体智慧被编程的方式保留下来，而不是让人们一次又一次的去重复学习简单的劳动。
运维的未来应当像 NixOS，面向功能，而绝非面向软件与包。
这个系统应当满足以下特性：
- 面对终端的普通用户
- 面对目标，也就是面对一些“单元测试”，因为操作系统应当为功能服务，而不是软件这个概念
- 可回滚
- 单机应用，可以远程运行，但是应当首要支持单机运行
- 与现有的运维技术兼容，并尽量使用现有的运维技术进行配置（初版暂定使用 Ansible），我们的世界不需要更多轮子了
- 可自动检查一个现有的，已经配置的操作系统，并生成配置代码
- 逻辑代码应当灵活，这个项目提出的一部分原因就是希望推进 Gentoo 的发展。（源码的自由是选择的自由，也是保证自由的基石）
对于 Android
而这个系统在 Android 上的体现会是 UpgradeAll
因为我希望 UpgradeAll 可以拥有这些特性：
- 从源码编译（你可以随意使用开发者没有合并的分支与功能）
- 面对开发者友好（你可以编程你的更新流程）
- 面对用户友好（你可以只考虑需要什么功能，而不是寻找应用，这应该让开发者来做，参考 quickenergy）
- 促进 Android 应用开放化（Android 应用的封闭性在我看来有很大部分是因为深刻骨髓的二进制分发，tui）