跳至正文

代码即操作系统(UpgradeAll 2 开发计划)

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

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

Table of Contents

过去

这带来一个想法,就是代码即架构,也就是 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)

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据

🌍 Language