可执行文件就是一个 SQLite 数据库

原文 ↗ Hacker News 讨论 ↗

把可执行文件变成 SQLite 数据库格式，既带来了对其创造性的赞赏，也引来了对其实用性的怀疑。评论者指出，这种做法可能统一工具链、让二进制可用 SQL 查询，甚至可作为代码、数据和插件的容器，但他们也强调了严重的取舍，例如失去基于 `mmap` 的共享、更高的内存使用，以及调整 SQLite 存储布局所带来的复杂性。讨论进一步延伸到系统设计中的一个反复出现的想法——用数据库支持的抽象来替换或支撑文件系统、可执行文件甚至操作系统服务——同时也在追问这种“万物 SQLite 化”的趋势应该止步于何处。

总体反应

  • 很多读者觉得这个项目有趣、巧妙，而且是一个“很棒的黑客项目”，尤其是对动态库和 ELF 内部机制的运用。
  • 也有人欣赏它的创意，但认为它并没有解决普通用户的迫切问题；对那些已经在处理 ELF 二进制的人来说，它的价值更明显。
  • 还有几位将其与现有想法进行了比较：Smalltalk/Lisp/Forth 镜像、zip/JAR 风格容器、redbean、DBOS、AS/400/PICK，以及“万物皆数据库”的操作系统概念。

可执行文件格式与性能取舍

  • 主要担忧：文本段是从 SQLite B 树中复制出来的，而不是通过 mmap 映射。
    • 这会阻止不同进程之间共享文本页，并损害内存和交换空间效率，尤其是在大量依赖动态库的系统上。
  • 有些人建议：
    • 对 BLOB 进行对齐和填充，使其成为页对齐、可 mmap 的区域。
    • 增大 SQLite 页大小（例如 64 KB），以获得更大的连续区域。
    • 编写自定义 SQLite VFS，将头部与数据分离。
    • 在加载时进行 SELF→ELF 转换，使运行中的二进制变成普通 ELF。
  • 几位评论者指出，避免复制并启用 mmap 才是可执行文件格式的“核心意义”，因此这种取舍并不简单。

SQLite 作为容器 / 文件系统 / 接口

  • 大家对 SQLite 作为一种通用、工具丰富的容器格式用于可执行文件、文档、图像等表现出浓厚兴趣；并将其与临时拼凑的二进制格式以及 ZIP+XML（OOXML/ODF）进行对比。
  • 有人认为文件系统本身就已经是可组合的“数据库”，目录就像子数据库；而 SQLite 的平面命名空间不太适合这一点。
  • 另一些人喜欢那种由数据库支持的文件系统：对用户仍呈现层级树状结构，但又能对丰富元数据进行类似 SQL 的查询。

替代设计与相关工具

  • 多位评论者建议保留 ELF，并通过 SQL 虚拟表来暴露它，而不是改变磁盘格式。
  • 提到的工具包括：osquery、nushell、Steampipe、用于挂载文件系统的 SQLite 虚拟表，以及此前将 SQLite 用作嵌入式应用容器的工作。

批评、问题与歧义

  • 有人觉得这个项目只是把 SQLite 当作一把“趁手的锤子”，而不是一种有原则的新对象格式。
  • 一位评论者质疑文章中关于 SQLite 会“intern”字符串的说法；他们观察到磁盘上存在重复字符串，并表示必须显式进行驻留。
  • 也有人设想在 SQLite 可执行文件内部引入更丰富的插件和重新链接机制，但这些仍停留在推测阶段。

元话题：标题与研究文化

  • HN 标题过滤器删除“Your”引发了人们对更智能、或由 LLM 辅助的去点击诱饵处理的呼声，或者直接把“Your”改写为“My”。
  • 作者提到学术反馈很严厉，这引发了关于低层次、带有“艺术性”的系统工作相较于纯性能指标是否被低估的讨论。