SELF 把可执行文件做成会写自己的 SQLite，部署简单了，边界也混在一起了
工程师 Farid Zakaria 展示了 SELF 格式的新概念验证：一个文件既是 SQLite 数据库，也是 Linux 可执行程序；运行中的程序还可以把网站内容、访问日志和按钮状态事务性地写回自己。
作者：林岚｜OC 开发者生态编辑
工程师 Farid Zakaria 展示了 SELF 格式的新概念验证：一个文件既是 SQLite 数据库，也是 Linux 可执行程序；运行中的程序还可以把网站内容、访问日志和按钮状态事务性地写回自己。
一句话结论：SELF 最有趣的不是把程序“塞进数据库”，而是让二进制分析、内容打包、状态存储、差异审计和部署都落到 SQL；但代码与数据合成一个可变文件后，备份、签名和并发更新也必须重新设计。
SELF 的起点是把传统 ELF 可执行文件的段、符号和重定位信息存进 SQLite 表。Linux 的 binfmt_misc 允许系统遇到这种文件时调用自定义解释器；解释器读取 segments 表，把需要的内容映射到内存，再跳到入口地址。对调用者来说，它仍然可以像普通二进制一样执行。
新演示 self-httpd 更进一步。一个名为 server 的 SQLite 文件里同时包含程序代码、三条路由、网站正文、访问记录和按钮点击状态。程序启动后根据 argv[0] 找到自己的文件路径，重新打开数据库，用 SQL 查询路由，并把访问写回 visits 和 presses 表。因为 SQLite 支持事务，更新页面内容可以提交或回滚，不必重启服务器。
这让很多工具“免费”出现。sqldiff 可以比较昨天和今天的程序，区分代码段、网页和数据各自变化了多少；FTS5 可以给文件内的文本路由建立全文搜索；SQLite 的备份、检查、事务和查询工具都能直接复用。单文件部署也更接近人们怀念的 scp 时代，却比单纯压缩包多了结构化查询能力。
但先别急着把 /var、/tmp 和 /home 全删掉。SELF 目前是概念验证，依赖 Linux、binfmt_misc 和自定义解释器。代码、配置与运行状态放在一起，会让不可变部署原则失效：同一个文件在启动后就可能发生变化，内容哈希与代码签名不再稳定；回滚程序版本时，是否连用户数据一起回滚也变成难题。
并发和故障恢复同样需要明确。SQLite 的 WAL 能提供成熟事务语义，但正在执行的映射来自哪个快照、程序更新自身代码时如何避免一半新一半旧、备份时如何处理外部 WAL 文件，都不能只用“单文件”概括。容器和包管理器也通常假设可执行文件只读，安全扫描工具需要重新理解这种格式。
SELF 因而更像一块值得研究的边界实验，而不是马上替代 ELF 的产品。它提示开发者：部署复杂度有一部分来自我们把程序、内容、配置和状态分散到不同格式；把它们统一进可查询容器，确实能消掉很多胶水，但不会消掉系统设计本身。
关键事实
- 格式：SQLite 数据库中保存可映射执行的程序段和相关元数据。
- 启动方式：Linux
binfmt_misc调用解释器加载并跳转到程序入口。 - 演示：self-httpd 在同一文件保存程序、路由、网页、日志和点击状态。
- 能力：运行时 SQL 更新、事务回滚、差异比较与全文搜索。
OC 判断
SELF 是一个好工程想法，因为它没有发明一整套新工具链，而是借用 SQLite 已经成熟的能力。它离生产格式还很远，最值得继续验证的正是代码签名、并发升级和数据恢复，而不是再加几个炫技查询。
为什么重要
- 对开发者：单文件不再只能是归档包，也可以是结构化、可审计的运行容器。
- 对运维：部署变简单的同时，备份和不可变性边界会发生变化。
- 对安全团队：扫描器必须区分文件里的可执行代码、状态与动态内容。
评论
围绕这篇文章补充信息、提出问题或分享观察。