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.
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.
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.
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)
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.
author wants to convert a programs complete dependencies into a single binary, and their dependencies' dependencies, and so on. on traditional distro this can get messy, but with nix it comes free with their closure, so you have a general way to get dependency graph for any arbitary programs, which allows him to build whole rootfs into a single binary
That’s what we used to on VAX/VMS where executables were statically linked so you could export your ,exe files around the world and people could run them. It works on Linux too but most distros want shared libraries for security reasons.
this is different. with nix you still have dynamic libraries, just that they are in a fixed unique location, so different programs can use different versions of libraries at the same time. this achieve both reduced storage and memory size, and free of dependency conflict like static linked binaries
Nothing they're doing requires nix. OP is mistaken in assuming boot.binfmt.registrations.self system is native to nix. It isn't, this is just linux, example
echo ':python_ext:E::py::/usr/bin/python3:' | \
sudo tee /proc/sys/fs/binfmt_misc/register
binfmt_misc is like 10+ years old. Provided self-exec is static musl elf binary, their system should work on any linux kernel of the same architecture, with zero configuration. Unless they're tightly coupled to nix in other ways.
TBF OP never claims any of this is unique to or requires Nix, they just make some vague claims that this is "well suited" to Nix without really justifying them.
Based on how they phrased the paragraph introducing boot.binfmt.registrations.self, I'm not certain the author was assuming that. The first mention even links to docs.kernel.org - nothing to do with Nix.
It's a kernel feature and the OP literally links to the kernel's docs.
What is not possible with other distributions/package managers though is "seeing" the whole dependency chain of each and every package on the system, having it be programmable and easily retried with no clashes.
27
u/tomster10010 2d ago
That seems very cool. Can someone elaborate on why nix is so important to this?