SELF makes a 51-file executable experiment queryable with SQL
selfdb asks a strange, useful question: what if a Linux executable were a SQLite database instead of an ELF file? commit e63f7c4 stores program segments, symbols, relocations, and dependency information as rows. The 51-file repository includes Python converters in converter/, C loaders in loader/, a schema, Nix integration, benchmarks, and shell tests. A converted file can answer SQL queries about its libraries, and optional sections can be deleted with a transaction before it still runs.
The idea is easier to understand through the included self-httpd example. Its program code, web pages, and visitor log share 1 database file. Updating a route means changing a row. That is a memorable demonstration of the format, though it should not be mistaken for a reason to turn an ordinary service into a self-modifying executable. The project is most useful as executable-format research you can inspect and run.
Three loader modes make this a Linux project
The README describes 3 execution paths. The memfd mode rebuilds an ELF image and executes it. Native mode maps segments before handing control to the system dynamic loader. The selfld mode performs eager binding from SQL data for a limited closure. A separate LD_AUDIT library lets stock glibc resolve converted shared libraries through a database. These are substantial systems components, far beyond the small Python converter that our sandbox built.
The platform boundary is firm. The README names Linux and NixOS, and the quick start begins with nix develop. Running a SELF file directly requires a binfmt_misc registration, while the supplied VM gives the experiment a controlled NixOS host. DESIGN.md says the self-ld route covers a curated freestanding closure, has no dlopen, and leaves general glibc programs to the audit-based path. Issue #3 asks whether a single file could hold more than 1 architecture.
What happened when we ran it
Our sandbox installed the Python converter at commit e63f7c4 in 17 seconds. The process added 37 packages and occupied 49 MB on disk. Its build then succeeded in 1 second. The checkout itself was 0.2 MB with about 3,932 source lines, so this part of the project is small enough to inspect without first unpacking a large framework. Pip-audit reported 0 known vulnerabilities in the installed Python set.
Pytest failed with exit code 5 after 2 seconds, reporting 0 passed and 0 failed because no tests ran. That log does not show a broken converter or a passing one. The repository has a tests/ directory, but it contains 10 shell scripts at the root rather than Python tests under converter/. Our configured run did not execute the README's nix develop -c bash tests/all.sh command, so we have no end-to-end test result to report.
Ten shell scripts cover work that pytest never reached
The root suite has 10 scripts covering round trips, loader behavior, the audit resolver, closure packing, preloading, self-ld, the server example, and the combined demo. That shape fits the project: meaningful checks must compile binaries, convert them, invoke Linux loaders, and sometimes use a Nix environment. A conventional Python unit suite would only cover part of the behavior. Still, a default pytest run that collects 0 cases can mislead contributors working inside the converter.
The quick path also assumes more host control than pip install suggests. Registering an executable format changes how the Linux kernel dispatches matching files. The NixOS VM is the safer place to learn the flow because it confines that registration and supplies the expected tools. Nothing in our 17-second converter install exercised the C loader, the VM, binfmt_misc, or the live server example. Budget review time for those parts before trusting a modified executable.
Issue 2 limits what an editable symbol table means
Open issue #2 points to a specific gap in the native and memfd stories. The reporter says those modes copy existing ELF linker tables inside stored segments instead of reconstructing them from SELF's symbols and relocations tables. If that report holds for your path, changing those SQL tables will not necessarily change how the rebuilt image links. The 1 database file remains inspectable, but some execution truth still lives in embedded ELF-era data.
SQL editability is the project's central claim. Before building tooling around it, test which tables each of the 3 loaders reads and which remain descriptive. DESIGN.md is candid about adjacent limits: sections are not used by the loader, M3b uses eager binding, and its no-libc scope excludes a general glibc replacement. The format is interesting partly because the boundaries are visible rather than hidden behind a finished-product claim.
No release and no license keep it in the lab
GitHub recorded the last push on August 25, 2026, and all 3 open issues were created or updated that month. The repository had 550 stars when fetched. That is recent activity for a project created in August, but there is no tagged release. Pin the e63f7c4 commit or another reviewed revision if you reproduce the experiment, since main is the only published version boundary available.
More important, GitHub detects no license and issue #1 simply asks for one. Public source code is readable without automatically granting permission to redistribute or incorporate it into another product. That makes the decision easy for now: study selfdb, run it in a disposable NixOS VM, and cite the design. Do not ship its code or a derived tool until the author states the license.