Executable Is a SQLite Database
Points and comments are a snapshot, not live.
An experimental prototype replaces ELF with SQLite as an executable format.
The author proposes SELF (Structured Executable & Linkable Format), which replaces ELF with SQLite as an executable format. Two tables suffice for running a binary: `self_meta` (ELF header as key/value pairs) and `segments` (load image, one row per program header). `strip(1)` becomes a `DELETE` + `VACUUM` transaction; `patchelf` becomes an `UPDATE`. A `self-ld` dynamic linker prototype implements symbol resolution entirely in SQL. `self closure` packs a binary and all its transitive dependencies into a single SQLite file. The whole userland (723 executables, 400 libraries) fits in 611.9 MiB, about 6% overhead over the original ELF files. Latency shows a fixed ~5 ms overhead plus a copy proportional to image size. The author implemented it on NixOS using `binfmt_misc` with a `self-exec` interpreter.
The prototype is on GitHub. A tool `elf2self` converts existing ELF files into SELF format via a Nix postFixup hook.
What commenters are saying
Comments were split. One camp appreciated the inventiveness but found the idea niche, mostly useful for people dealing with ELF internals. Another camp explored deeper implications: replacing the filesystem with a database (with a counterpoint that hierarchical filesystems are fine as a user metaphor). Several commenters noted the copied vs. mapped memory situation as the main dealbreaker, with suggestions around page-aligned blobs or a new SQLite VFS. The thread also discussed parallels to Smalltalk/Lisp images, Forth, and TCL starpacks, noting that self-modifying executables can trigger virus checker suspicion.
One commenter suggested putting the SQLite driver in kernel space for a unikernel; another argued execve should be a userspace operation.