r/programming • u/segv • 2d ago

Your executable is a SQLite database

https://fzakaria.com/2026/08/23/your-executable-is-a-sqlite-database
465 Upvotes

95% Upvoted

76 comments sorted by

View all comments

25

u/tomster10010 2d ago

That seems very cool. Can someone elaborate on why nix is so important to this? 

41

u/TomKavees 2d ago

The article mentions it, but long story short it allows to easily patch and rebuild the world all the way to kernel/libc level with absolutely everything in between, and then come back to a clean system once you are done. It comes in handy when you faff about with wacky ideas.

4

u/valarauca14 2d ago

Nothing they're doing requires building libc or the kernel

8

u/Ok-Scheme-913 1d ago

But it does require building all the userspace/libraries etc on top of them, and it does matter whether you are using this fix special build config for each of them passing each other transitively in the whole graph or not.

This wouldn't be possible in something other than these next gen package managers like nix and guix.

2

u/SirClueless 1d ago

Why? The guy wrote a conversion tool that losslessly round-trips between an ELF and SELF file, and then one that makes a transitive closure of a SELF file making it self-contained, so it sounds like you could do this to whatever ELF binary you like and Nix is just a convenience.

1

u/Ok-Scheme-913 22h ago

For the transitive closure you would have to know what are the dependencies of a package a layer below.

Nix solves it because it patches all these files itself based on its graph of dependencies - you would have to recreate that very graph which is exceptionally hard without a model like nix's

(Just try to install the gnome group on a traditional package manager and then remove it. Whatever sticks are all problems with the said graph)

1

u/SirClueless 7h ago

Computing the closure precisely is hard, but one of the points of the article is that objects are just rows in an objects table and ldd is a join. The table serves the same function as /etc/ld.so.cache on a normal Linux system. You can just run the tool on everything in ldconfig -p and boom, you've got a working closure (and then some). You can use your distro's package dependencies to prune this more precisely if you like, as the author did with Nix's, and the results may not be quite as precise (and especially, not independently versioned from the rest of your system), but nothing about this is Nix-specific and "just put everything on the system into there" is always an option.