I switched over to Nix about a year ago. I was a Windows user before that for 30 years and tried Linux a couple of times, but it never stuck. Now I know I will never touch Windows again. With NixOS I've finally found a system that actually works for me — and the full OS configuration is in a repo. My god, I love it so much.
Sometimes I even prefer nix-shells over uv for quick one-off Python scripts.
I cannot sufficiently convey how absolutely barbaric everything else feels in comparison. Not having Nix would be like having to work on code without Git — absolutely unacceptable.
And it really isn't that much work — you do it once. The next time you set up a new system, without Nix, you'll have to do the full configuration all over again.
Have you heard of any good projects for running isolated containers in NixOS that are cheaply derived from your own NixOS config? Because that is what I want. I want a computer where I can basically install every non stock app in its own little world, where it thinks "huh, that is interesting, I seem to be the only app installed on this system".
Basically, I want to be able to run completely unverified code off of the internet on my local machine, and know that the worst thing it can possibly due is trash its own container.
I feel like NixOS, is one path toward getting to that future.
Can you do those ad-hoc though? I was looking into this too. I feel like it requires a system config change, apply, and then you need to do container start + machinectl login to actually get a shell.
That's definitely what I want... most of the time.
* declarative mode, where your guest config is defined within your host config, or
* imperative mode, where your guest NixOS config is defined in a separate file. You can choose to reuse config between host and guest config files, of course.
> I want a computer where I can basically install every non stock app in its own little world, where it thinks "huh, that is interesting, I seem to be the only app installed on this system".
NixOS containers are the most convenient way to do this, but those will map the entire global nix store into your container. So while only one app would be in your PATH, all other programs are still accessible in principle. From a threat-modelling perspective, this isn't usually a deal-breaker though.
There's also dockerTools, which lets you build bespoke docker/podman images from a set of nix packages. Those will have a fully self-contained and minimal set of files, at the expense of copying those files into the container image instead of just mapping them as a volume.
If containers are safe enough for ur use case then just use nixos containers they just a few more lines to setup in a regular nixos config
If it isn't enough
there's microvm.nix which is pretty much the same in difficulty /complexity, but runs inside a very slim and lightweight VM with stronger isolation than a container
depends whether you consider rootless Docker "cheap". I tried running ZeroClaw in a Nix-derived Docker (spoiler - it was a bad idea to use ZeroClaw at all since the harness is very buggy) and there is still a potential for container escape zero-days, but that's the best I've found. also, Nix's own containerization is not as hermetic as Docker; they warn about that in docs
That's hard given most apps have dependencies and often share them.
It will always look like curl is available or bash or something
What's wrong with another user account for such isolation?
They can be isolated to namespaces and cgroups. Docker and Nix are just wrappers around a lot of OS functionality with their own semantics attempting to describe how their abstraction works.
Every OS already ships with tools for control users access to memory, disk, cpu and network.
Nix is just another chef, ansible, cfengine, apt, pacman
Building ones own distro isn't hard anymore. If you want ultimate control have a bot read and build the LFS documentation to your needs.
Nothing more powerful than the raw git log and source. Nix and everything else are layers of indirection we don't need
Not only is it composable, but it is generalizable. So yes there is also chef, ansible, apt, uv, nodeenv, etc... or there is just nix. It is able to be the "one tool" to rule them all, often with better reproducibility guarantees.
I almost switched back to Fedora Bazzite to get a working gamescope, but realized I can get HDR in sway and its actually more stable than Valve's mess of gamescope. Even though I have to use "--unsupported-gpu" flag, my Nvidia card works wonders in Sway, where as gamescope gives me a blinking cursor and segfaults.
Not the greatest fan of python, but when I've got to run a python script, I do `nix-shell -p 'python3.withPackages (ps: [ps.requests])' --command 'python3 your-script.py'` Note that there is one argument to -p and one argument to --command -- both are quoted. The argument to -p is a nix expression that will provide a python3 command, referring to a python3 with the requests package. The argument to --command is a bash script that will run python3 with the argument "your-script.py" i.e. it will run your-script.py with the python3 that has the requests package.
I think there's ways you can autoderive a python3 with specific packages from python dependency files, but I can't help you there. I do find AI to be reasonably helpful for answering questions like this: it just might sometimes require a bit of help that you want to understand the answer rather than receive a perfect packaged shell.nix file.
Do you have to figure this out? Sure, it's nice and "pure" if everything is configured through Nix but there is something to be said about being pragmatic. Personally, I just enabled nix-ld[0] and use uv to install and handle my Python versions and package dependencies. Much, much easier.
Easier and largely compatible with the rest of the world. Solving problems with "If we all switched to NixOS..." is a non-starter in most organizations.
My rule of thumb: keep a strict separation between my projects (which change constantly) and my operating system (which I set up once and periodically update). Any hard nix dependency inside the project is a failure of abstraction IMO. Collaborating with people on other operating systems isn't optional!
In practice this means using language-specific package management (uv, cargo, etc) and ignoring the nix way.
