Hi,
I’ve spent few days trying to figure out how exactly Nix achieves the isolation to being able to have two different versions of the same software running on the same “machine”.
I do know that other distros (like Fedora Silverblue) tend to offer a container based solutions like toolbx OR distrobox. But I do believe this is not the case Nix. Right?
If anyone can point to an article, video or a piece of could that could help understands how this “magic” works that would great! 
Non whatsoever. We just install the binaries and all the libraries they depend on in different unique paths and hardcoded the full path to libraries in the binaries.
Once you let go of the idea that libs go in /usr/lib and bins in /usr/bin you can have as many library and binary versions installed in parallel as you want. It’s just directories.
Ok. So you’re saying that IF a certain package has N references to N libraries the “nix script” will at some point need to go through ALL the necessary files and patch the references with Nix Store based ones?
Nix is starting to sound like a pre-pre-compiler step/tool of sorts.
Nix is a build system, and most packages are built from source, so that level of “patching” is not needed per se.
Maybe you’re looking for the Nix thesis by Eelco Dolstra.
It would be great if we got people to stop thinking “package manager” or “build system” when they think “Nix”.
Nix is a tool to force Unix processes to behave (mostly) like pure functions that operate on file system trees. The Nix language allows composing these functions, and also conveniently offers first class support for file system paths and string interpolation.
Today’s process isolation when running the builder executable of a derivation is a homegrown sandbox, because Nix pre-dates contemporary commonplace technologies by many years.
If I made Nix today from scratch, I’d build a pluggable interface for isolating the cached execve() and have containers or VMs by default, and would use a string templating language extension for Haskell instead of inventing a new language.
Yes. This is exactly how it works. We do this by passing the right amount of flags to package builds such that these paths are all static during compile time. It’s not some Post-Processing phase but a question of passing around the right flags to your build system to find libraries at these hardcoded paths.
I think I’m starting to get a grasp of what’s going on. Thank you everyone for the replies! Really appreciate it :]