There is likely a mass of devs that is probably, hmmm, 10x the number of Nix devs from over a year ago, who know exactly what Nix offers and why it is cool, but couldn't be bothered to master it until AI came along and basically "solved the problem".
So I'd expect AI to rapidly accelerate Nix adoption. Hopefully, because it is amazing.
Yeah, even you understand nix and make packages it was still a PITA to use sometimes. If something isn't in nixpkgs or you need a different version, it might be as easy as writting 20 lines of nix, or 2000.
Now you can just send this to agent "port dis <repo link>" and 20 minutes later you get a working package, or 20 working packages what were required for that package to work.
Fixing stuff also easy, just today for some reason my machine wouldn't wake up monitors after sleeping them, a few minutes later claude fixed my configuration. Making QuickShell things with it also easy. For years I've avoide all GUIs for networkmanager and bluetooth on linux because they all looked awful and unusable, now QuickShell things made just for me, exactly the way I wanted.
I've been using nix before you could use AI to write ok code with it and it was a struggle knowing how to configure nix sometimes. Especially when dealing with less popular software which happens from time to time. Still stuck to it as I've felt that once it was working it was pretty amazing. But using Claude with nix is super cool. It's really good and I don't care much about the quality of my nix config at this point, it's just for me and I just want my computer to do what I want it to do and Claude can figure it out most of the time.
Heck i used Claude when it sucked just to ask it questions. It was wrong on 50% of the questions back then but it still was easier than randomly searching for the solutions. Claude helped unblock me when i got stuck on obtuse nix errors, foreign compilation issues, etc.
These days it's magical, but it was even a huge boon when it was barely functional. Nix just had a way of leaving me super confused and stranded.
I tried using various configurations tools and to this day, unless it’s needed for a project, my strategy is “don’t bother”. When I use a program for a while, I backup the config somewhere and perhaps write a few notes, but my daily setup vary enough and last enough that I wouldn’t replicate it.
My mac setup hasn’t been replaced since 2021 or something, and it was copied from my old mac. I have a dotfiles git repo, which I drag around and have multiple branches for my daily driver. For temp setup, I just copy files and edit.
most of us are not interested in doing extra unnecessary manual work to maintain these things or synchronize them across different computers or resurrect them after a certain amount of time not touching them
I think that ratio is possible, and certainly I’m counted among those numbers. However, it is not so much the case that I longed to use Nix and agents made it more feasible. What happened is that I wanted an agent to manage my machine’s configuration without giving it much access.
It’s not the only thing that agents have changed for me - I also went back to using neovim and tmux; partly because of how I use remote development servers but also because now I can get my setup working perfectly for me without a lot of hassle.
Open source and code managing all the things has always been a great idea but now it feels crazy to do anything else.
Nix is amazing in many ways, but its discoverability and transparency are sometimes very poor. Its module system is anything but lean and straightforward.
I don't find Nix the language particularly weird. But pick an arbitrary .nix file, see a bunch of stuff passed to the derivation, and try to find out whence it comes, and what types / attributes are expected there. The only definitely working solution I know is a full-text search over the file tree.
Now compare it even to Haskell, to say nothing about e.g. Typescript.
Guix is a nice idea. But the few last times I read about it, users uniformly noted that it's soooo slow in man cases. Nix can be slow, but most of the time is very fast, it just has to check a lot of files.
(I say this as somebody who deeply loves the concepts in most functional languages, and loves the concepts in nix, but recognises that the developer-experience of both is about as pleasant as reading somebody else's code-golfed perl)
It isn’t a compliment, just a fact. Of course it all depends on what you are familiar with, but that is a fact about you, not Nix.
The concepts in functional languages are not fully realized in any multi-paradigm languages. So you can admire all you want, but don’t knock it until you’ve actually tried it.
And I understand because it took me TEN YEARS to come around.
I worked with a very forward-thinking functional programmer around 2012 and even back then she was raving about it. And of course, people thought she was a raving lunatic.
I give her credit to this day. It took me having one too many problems caused by NOT using Nix, to cause me to finally dive in.
And there's no going back. Which is what happens with the best technologies.
Me too. I’ve known about Nix for a long time but resisted the idea of learning a new language just to manage my system. In retrospect, it would have been worth it, but now I don’t have to.
"We have this system that is so amazing that... it requires a paid subscription to an LLM provider or a $5000 GPU for most people to understand and configure".
Pre-LLM: Nix is "high effort, moderate reward". The cost is: you have to learn a tool which does things apparently completely different to how other tools do things.. you have to put up with a lot of friction, pay all the pain upfront, and the benefit is that may be later it's easier to get the package again.
It's just not a practical trade-off for most developers.
With LLMs, the cost-benefit trade-off changes.
You can use this cloud provider's LLM to get you a good result. You get the benefits, and the cost is 'just' "ask the LLM to do it".
Similarly: it's easier to assess whether produced code does the right thing, than to come up with that code from scratch.
Without LLMs? The inaccessibility also comes from being a niche tool. Not many use it, so not many software projects accommodate it or consider it, and you might have to come up with workarounds yourself.
This doesn't really do anything to dissuade me from my point of view. So it was a complex system with an extremely high barrier of entry that even nix proponents admitted.
It remains so, only now you want people to blindly trust LLM output for this system.
Some tools are good even though they have a high barrier to entry.
That people use resources to help them use tools they don't understand too well is hardly new. e.g. Classically you might copy-paste from StackOverflow after finding an error, or some people watch YouTube videos about it.
I'd say LLMs make it easier to get to the point where you can understand it, though. So it's an accessibility increase.
> It remains so, only now you want people to blindly trust LLM output for this system.
This isn't related to Nix, though. You could ask an LLM to create the most mainstream Python code ever and blindly trusting it would make as much sense.
For system management, Nix has the advantage of being declarative. e.g. For NixOS you get to read the code and review what it's doing.
Is the high barrier to entry essential though? Is there something about the nix domain that would mean any solution would have as high a barrier to entry? Or is it something they could have simplified greatly, and just never did? (Asking as an outsider, I've always been curious about this).
I went into Nix thinking I would understand the whole thing and then distill a very simplified version, but as it turns out, a significant amount of the complexity is basically required for it to work like it’s supposed to, given how builds and runtimes and dependencies across various languages work, which is unfortunate
Here's a rough sketch: the Nix expression language is really configuration oriented; it's a "JSON + functions" kind of language. You write Nix to describe how a package is built; the ideal case being "./configure && make && make install" as such. The resulting packages are put in a Nix store. (Almost) every dependency is put in the Nix store; so your program links against libraries in the Nix store, or runs other sources from the Nix store.
- Nix is "just" declarations of those instructions which output into directories and everything gets symlinked. But, it can take time to build an intuition for how to do things.
- There's some fundamental friction where most Linux systems assume shared libraries are available globally in a typical place on Linux. -- e.g. Python's "wheels" come with precompiled dependencies which assume shared libraries are available in a global place. Nix doesn't provide that.
- "Why not just provide globals?" For one, by having everything not be global, you can have multiple versions available at the same time.
- Since Nix is quite 'strict' by default about everything coming from the Nix store, it practically means 'paying' for all the difficulties up front. (There's a trade-off where you could write packages in a less strict manner; this is great for iterating, but bad for maintainability).
- Since Nix is strict about symlinking all dependencies, often if upstream software does things in a "quick and dirty manner" (e.g. hardcodes "/bin/bash", hardcodes paths for binaries to run, etc.) then it can be difficult to describe how to package that software with Nix. -- Fundamentally, you're taking something which works loosely, and bringing it into a stricter system.
- Upthread the comment mentions "flakes". Flakes provide both dependency management (i.e. being able to declare other Nix codebases you'll use), as well as a standard entrypoint into a Nix codebase. -- Without flakes, the UX is a bit cumbersome..
- The majority of packages which people use come from "Nixpkgs" package repository. This has a lot of organic complexity to it, coming from multiple contributors, with competing ideas for achieving results.
- With Nix being a "json + functions" language.. not sure I'm articulating this right, but it means that practically a large codebase is built as a single 'expression' (i.e. soft boundaries between bits of code).. and the tooling for troubleshooting problems is ... not very good.
- The Nix expression language is functional and lazy. This can be rough for people who don't have this background.
- Since Nix adds a layer of abstraction, it means you might need to have both a broad and a deep understanding to get something working (e.g. understanding how to drive Python or Linux in non-conventional ways). -- A kind of "do everything properly" which more conventional systems don't require.
So ... some aspects could be easier. But I think there's a fundamental friction to it.
It really depends on the person, for me I have my own setup script that works on both Mac and Linux, installing all of my core software using whichever method is best for each system, I basically have a csv with columns of “program” “install command Linux” and “install command Mac” and it just works.
Then all of my dotfiles are backed up, with any important other config, in a big gig repo. And all of my documents/photos/etc live on a separate hard drive which gets backed up to the cloud.
All of that to say, with the right setup nix is mostly unnecessary, and honestly the benefit of not using it is that I can wipe my system anytime and restart it with just my usual important programs ready to go. Any mess made along the way gets purged automatically in every fresh install
Before AI, there was virtually no documentation, and there are so many ways to do any single thing that it makes it brutal to figure out what any given configuration was trying to do.
Is `nix` amazing though? Eh... if it were implemented better, it could be amazing. It's like python virtual environments or `pyproject.toml` for general software. It solves a real problem, but it does so by introducing a possibly even bigger problem.
I use an agent to author my nix config - personally I don't have the determination to have picked Nix up entirely on my own so I find it to be a godsend. I can code review config changes and keep it all in git - also makes it easy to pick up the entire config and deploy it on a different machine.
LLMs can be deterministic too! People just don't bother because the applications of this aren't widely known yet. See https://lukechampine.com/repligraphs
I was just reading Michael Lynch's posts about Sia[0] and I came across this.
Its a very curious project, but don't you end up pinning repligraph usability on model weights? Since you take indeterminism out of the equation, a repligraph's notability is as significant as the producing model's weights, and since there is no dice rolls to be made, the eyeball problem:
> Our blind spots, while not perfectly correlated, have substantial overlap
is entirely replicated. Models that are diffused from one another can have the same blind spots, the same loose statistical reality that exists with humans. This is partially addressed in steering:
> A repligraph proves that a model generated some artifact. It does not prove that the model did a good job, or that the artifact is safe.
but I think the "Peer Review" solution is inadequate, and with some jailbreaking prompts' innocuous looks considered, "the attacker just needs to find one prompt" might be much easier than it appears.
Batching seems to be a huge economic turn off for proprietary model determinism, but I think its entirely viable for consumer models. Trustless evals are brilliant and should've been our reality. Nice project, good luck on your endeavor.
Thank you for the kind words! It's funny how much staying power those blog posts have, haha. Michael has some arcane ability to consistently hit the front page of HN.
True, I expect models to be pretty correlated with each other as well. But you can at least attempt to quantify that correlation in a rigorous way, by running experiments (e.g. by pointing each model at a big project and comparing the sets of bugs they each find).
And yeah, the "double-edged sword" aspect of determinism is definitely the biggest bullet that you have to bite. For me, it's better than the alternative; without determinism, such jailbreaking attacks are still possible, just harder to detect. But I certainly would not want people to go around thinking "it's deterministic, therefore it's safe."
Deterministic systems like tracing GCs, JIT compilers, PGO data, machine learning optimising passes that vary their output, depending on program behaviours?
"What is this superpower, and why is nobody else using it?"
The "Undo" time-travelling debugger for C/C++ has been around for 20+ years. So I guess the answer is simply that most people chase shiny new things instead of using established, reliable, and, hence, boring tools.
I'd love to become a Nix user one day. I tried to write a rather complex flake one day; it ended up with Nix (nix command) deleting itself: I immediately lost trust with it.
This sounds like a total nightmare. I am very interested in Nix and was strongly considering setting it up on my new travel laptop as a daily driver but stories like these give me pause. I would love to get a more detailed explanation of what happened here. Either way I am past the phase where I'm comfortable or patient enough to beta test software so Debian / Ubuntu it is for me.
Nix daily driver for years here. I don't know what they did to screw up their system like that, but it's unusual IME. Normally you can just reboot and load the previous profile. Even in the absolute worst case, as long as you have your config, you could boot the installer and then load your config and your system comes back exactly as it was. It's definitely not beta software.
FWIW, I used Debian more than anything over decades, and also have little patience when it comes to unstable computers. NixOS is a breath of fresh air and has reinvigorated my love of Linux. I haven't found it less stable than Debian, and also have a higher degree of confidence when making changes. It has its quirks, but ultimately I've found it a joy to use, and I'm never going back to a distro that doesn't have similar capabilities.
If you boot default Debian and apt install a handful of packages from the primary channel, it probably doesn't matter much, but if you enjoy even a modest amount of customizing, NixOS really shines. From one Linux user to another, I encourage you to try it! I have no affiliation, just an old head stoked on Nix.
I used nix years ago on a Mac just as a sort of alternative to what I’d otherwise use homebrew for and I really liked it, so I decided a few times that i would try nixos for my laptop. Each time I was stopped by the awful documentation and the weird “flakes are experimental but kinda required” state of the project and I gave up.
This year I decided to give it another try and set it up on an ancient laptop using Claude to factor the config and it’s gone so well that I now use the same nix config to manage three different machines and it’s insanely liberating to know how easy it is to screw everything up and roll it back trivially. I now regularly make edits on one machine and then just routinely commit them and go apply on the other machines with zero friction. It’s kind of amazing.
Also Nix first tries to find a derivation in a remote cache and sets a very long timeout, so when you have a limited connection (e. g. a corporate limited network setup), it's painful.
I find myself moving more and more non-build things into nix builds because I don't want to roll my own cache invalidation. Seems like this is yet another reason to do so.
Dude, this is amazing stuff. Farid really is putting out banger after Nix banger haha. This sounds like a mini/less capable Antithesis runtime, but running on your machine.
I had the exact same thought about Antithesis while reading this. I wonder if this could be used for concurrency bug hunting by setting up preconditions and grinding until failure to capture a bug you’re looking for.
As far as I can tell, that is only one piece of the puzzle. I think the bulk of the work is on the hypervisor side (KVM) to eliminate/stub out sources of randomness in HW, patch out RDRAND, etc
One vCPU on stock KVM, so code in the VM runs on the real CPU. The VM's kernel carries a small Rewind platform: interrupts arrive only when the VM hands control to Rewind, time moves only then, and the timestamp counter and hardware RNG are hidden. A step is one of those handoffs.
3. Keep keyframes
Every quarter second of wall time, Rewind snapshots the machine using KVM's dirty-page [aka Memory Pages that have been written to since the last snapshot] log. Pages go into a content-addressed store (BLAKE3, zstd), so a page shared by keyframes, runs and forks is stored once."
Now, that's some brilliant engineering right there!
While I like the product name "Rewind VM" (and yes, that's what it allows the user to do!), it could just as easily be called "Deterministic VM" and that name would have been wholly appropriate, as well!
Future OS and VM engineers should study Rewind VM. Those are some great engineering ideas there, and determinism, or at least optional determinism, should it be desired, when it is desired -- is the one thing that is completely non-existent in most OS's, most VM's, and most other program runtime environments...
Anyway, a great article on using Rewind VM (never knew about it before this article!) with Nix builds.
My eyes glazed over even the examples which seem to have a good premise, but almost immediately devolve into the prose I have to sit through every day.
Wow, that looks like a lazy and disrespectful attack.
Rewind VM appears to be made solely by fzakaria, the author of the submitted article. I don't see any connection to peter_d_sherman, who is clearly not a sock puppet account. It took 10 seconds to check that info.
God forbid people on HN get excited about a technology.
You, on the other hand, clearly have an axe to grind against LLM usage. Which is fine and all as a personal preference, but not a reason to post such a comment.
No, but you don't have admonish them or accuse of self-promotion. Use the flag button if you feel so inclined. You don't have to try to negate their excitement about something that seems genuinely novel, especially when not really engaged on the content of the project / post. Which it doesn't seem like you even really looked at.
So I have to be excited about every project, go and read through every Claude-authored text, and not form any opinion at all except visible and eager excitement?
I honestly have no idea what point you are making.
If you are in fact worried about the amount of work involved then I don't see why you would bother to comment at all, which is just more calories burned.
Anyway, cynically asking whether people are self-promoting (without any attempt at evidence) is far more than just sharing your opinion.
And it's clear you didn't force yourself to read through all that "Claude-authored text", otherwise you would not be left wondering if peter_d_sherman was self-promoting. (I don't know any of these people but it's clear they're all different).
My point was to tell you that you are exhibiting unacceptable behavior for a civil discussion. That's an example of sharing an opinion with justification.
There is likely a mass of devs that is probably, hmmm, 10x the number of Nix devs from over a year ago, who know exactly what Nix offers and why it is cool, but couldn't be bothered to master it until AI came along and basically "solved the problem".
So I'd expect AI to rapidly accelerate Nix adoption. Hopefully, because it is amazing.
Yeah, even you understand nix and make packages it was still a PITA to use sometimes. If something isn't in nixpkgs or you need a different version, it might be as easy as writting 20 lines of nix, or 2000.
Now you can just send this to agent "port dis <repo link>" and 20 minutes later you get a working package, or 20 working packages what were required for that package to work.
Fixing stuff also easy, just today for some reason my machine wouldn't wake up monitors after sleeping them, a few minutes later claude fixed my configuration. Making QuickShell things with it also easy. For years I've avoide all GUIs for networkmanager and bluetooth on linux because they all looked awful and unusable, now QuickShell things made just for me, exactly the way I wanted.
I've been using nix before you could use AI to write ok code with it and it was a struggle knowing how to configure nix sometimes. Especially when dealing with less popular software which happens from time to time. Still stuck to it as I've felt that once it was working it was pretty amazing. But using Claude with nix is super cool. It's really good and I don't care much about the quality of my nix config at this point, it's just for me and I just want my computer to do what I want it to do and Claude can figure it out most of the time.
Heck i used Claude when it sucked just to ask it questions. It was wrong on 50% of the questions back then but it still was easier than randomly searching for the solutions. Claude helped unblock me when i got stuck on obtuse nix errors, foreign compilation issues, etc.
These days it's magical, but it was even a huge boon when it was barely functional. Nix just had a way of leaving me super confused and stranded.
I tried using various configurations tools and to this day, unless it’s needed for a project, my strategy is “don’t bother”. When I use a program for a while, I backup the config somewhere and perhaps write a few notes, but my daily setup vary enough and last enough that I wouldn’t replicate it.
My mac setup hasn’t been replaced since 2021 or something, and it was copied from my old mac. I have a dotfiles git repo, which I drag around and have multiple branches for my daily driver. For temp setup, I just copy files and edit.
most of us are not interested in doing extra unnecessary manual work to maintain these things or synchronize them across different computers or resurrect them after a certain amount of time not touching them
but you go with your time wasting self
I think that ratio is possible, and certainly I’m counted among those numbers. However, it is not so much the case that I longed to use Nix and agents made it more feasible. What happened is that I wanted an agent to manage my machine’s configuration without giving it much access.
It’s not the only thing that agents have changed for me - I also went back to using neovim and tmux; partly because of how I use remote development servers but also because now I can get my setup working perfectly for me without a lot of hassle.
Open source and code managing all the things has always been a great idea but now it feels crazy to do anything else.
Nix is amazing in many ways, but its discoverability and transparency are sometimes very poor. Its module system is anything but lean and straightforward.
I say this as a daily user of Nix.
Is mainly the language. Is not just weird like APL , that insanely make sense. is weird.
I don't find Nix the language particularly weird. But pick an arbitrary .nix file, see a bunch of stuff passed to the derivation, and try to find out whence it comes, and what types / attributes are expected there. The only definitely working solution I know is a full-text search over the file tree.
Now compare it even to Haskell, to say nothing about e.g. Typescript.
That... is all on the language. In fact the main trouble now that you spelled out is the major blow against nix: is terrible at modularity!
https://guix.gnu.org/ might fix the language by replacing it with a real one.
Guix is a nice idea. But the few last times I read about it, users uniformly noted that it's soooo slow in man cases. Nix can be slow, but most of the time is very fast, it just has to check a lot of files.
The problem is that an immutable build architecture really requires a functional language to be aligned with it
I don’t find it weird compared to other functional languages.
That's not the compliment that you think it is...
(I say this as somebody who deeply loves the concepts in most functional languages, and loves the concepts in nix, but recognises that the developer-experience of both is about as pleasant as reading somebody else's code-golfed perl)
It isn’t a compliment, just a fact. Of course it all depends on what you are familiar with, but that is a fact about you, not Nix.
The concepts in functional languages are not fully realized in any multi-paradigm languages. So you can admire all you want, but don’t knock it until you’ve actually tried it.
This is exactly me and I've fallen in love with nix
And I understand because it took me TEN YEARS to come around.
I worked with a very forward-thinking functional programmer around 2012 and even back then she was raving about it. And of course, people thought she was a raving lunatic.
I give her credit to this day. It took me having one too many problems caused by NOT using Nix, to cause me to finally dive in.
And there's no going back. Which is what happens with the best technologies.
Me too. I’ve known about Nix for a long time but resisted the idea of learning a new language just to manage my system. In retrospect, it would have been worth it, but now I don’t have to.
I find this take baffling.
"We have this system that is so amazing that... it requires a paid subscription to an LLM provider or a $5000 GPU for most people to understand and configure".
When instead Nix could've focused on releasing flakes 10 years ago with probably the same effect. And fix issues like this: https://news.ycombinator.com/item?id=50040083
It's not so strange.
Pre-LLM: Nix is "high effort, moderate reward". The cost is: you have to learn a tool which does things apparently completely different to how other tools do things.. you have to put up with a lot of friction, pay all the pain upfront, and the benefit is that may be later it's easier to get the package again.
It's just not a practical trade-off for most developers.
With LLMs, the cost-benefit trade-off changes.
You can use this cloud provider's LLM to get you a good result. You get the benefits, and the cost is 'just' "ask the LLM to do it".
Similarly: it's easier to assess whether produced code does the right thing, than to come up with that code from scratch.
Without LLMs? The inaccessibility also comes from being a niche tool. Not many use it, so not many software projects accommodate it or consider it, and you might have to come up with workarounds yourself.
This doesn't really do anything to dissuade me from my point of view. So it was a complex system with an extremely high barrier of entry that even nix proponents admitted.
It remains so, only now you want people to blindly trust LLM output for this system.
Some tools are good even though they have a high barrier to entry.
That people use resources to help them use tools they don't understand too well is hardly new. e.g. Classically you might copy-paste from StackOverflow after finding an error, or some people watch YouTube videos about it.
I'd say LLMs make it easier to get to the point where you can understand it, though. So it's an accessibility increase.
> It remains so, only now you want people to blindly trust LLM output for this system.
This isn't related to Nix, though. You could ask an LLM to create the most mainstream Python code ever and blindly trusting it would make as much sense.
For system management, Nix has the advantage of being declarative. e.g. For NixOS you get to read the code and review what it's doing.
Is the high barrier to entry essential though? Is there something about the nix domain that would mean any solution would have as high a barrier to entry? Or is it something they could have simplified greatly, and just never did? (Asking as an outsider, I've always been curious about this).
I went into Nix thinking I would understand the whole thing and then distill a very simplified version, but as it turns out, a significant amount of the complexity is basically required for it to work like it’s supposed to, given how builds and runtimes and dependencies across various languages work, which is unfortunate
Some parts could be smoother.
Here's a rough sketch: the Nix expression language is really configuration oriented; it's a "JSON + functions" kind of language. You write Nix to describe how a package is built; the ideal case being "./configure && make && make install" as such. The resulting packages are put in a Nix store. (Almost) every dependency is put in the Nix store; so your program links against libraries in the Nix store, or runs other sources from the Nix store.
- Nix is "just" declarations of those instructions which output into directories and everything gets symlinked. But, it can take time to build an intuition for how to do things.
- There's some fundamental friction where most Linux systems assume shared libraries are available globally in a typical place on Linux. -- e.g. Python's "wheels" come with precompiled dependencies which assume shared libraries are available in a global place. Nix doesn't provide that.
- "Why not just provide globals?" For one, by having everything not be global, you can have multiple versions available at the same time.
- Since Nix is quite 'strict' by default about everything coming from the Nix store, it practically means 'paying' for all the difficulties up front. (There's a trade-off where you could write packages in a less strict manner; this is great for iterating, but bad for maintainability).
- Since Nix is strict about symlinking all dependencies, often if upstream software does things in a "quick and dirty manner" (e.g. hardcodes "/bin/bash", hardcodes paths for binaries to run, etc.) then it can be difficult to describe how to package that software with Nix. -- Fundamentally, you're taking something which works loosely, and bringing it into a stricter system.
- Upthread the comment mentions "flakes". Flakes provide both dependency management (i.e. being able to declare other Nix codebases you'll use), as well as a standard entrypoint into a Nix codebase. -- Without flakes, the UX is a bit cumbersome..
- The majority of packages which people use come from "Nixpkgs" package repository. This has a lot of organic complexity to it, coming from multiple contributors, with competing ideas for achieving results.
- With Nix being a "json + functions" language.. not sure I'm articulating this right, but it means that practically a large codebase is built as a single 'expression' (i.e. soft boundaries between bits of code).. and the tooling for troubleshooting problems is ... not very good.
- The Nix expression language is functional and lazy. This can be rough for people who don't have this background.
- Since Nix adds a layer of abstraction, it means you might need to have both a broad and a deep understanding to get something working (e.g. understanding how to drive Python or Linux in non-conventional ways). -- A kind of "do everything properly" which more conventional systems don't require.
So ... some aspects could be easier. But I think there's a fundamental friction to it.
Flakes are not less confusing to me. Why do you have to git stage a flake.nix for it to apply? I ran into that footgun so many times.
there is a legitimate reason why this is the case; it is probably instructive to have you look it up or ask an LLM
Yes, this just confirms nämy view that Nix, as it is right now, is bad.
And yet, it matches reality.
Flake stabilisation probably hasn't gotten any easier/more likely by LLMs, but it does make it quicker for people to pickup technology.
Technology sometimes has that odd effect. (And it will apply to different technologies in different contexts at different rates.)
Yeah I tried to daily drive Nix at one point pre AI and the ergonomics were just not a good match for me - perhaps I should try it again.
It really depends on the person, for me I have my own setup script that works on both Mac and Linux, installing all of my core software using whichever method is best for each system, I basically have a csv with columns of “program” “install command Linux” and “install command Mac” and it just works.
Then all of my dotfiles are backed up, with any important other config, in a big gig repo. And all of my documents/photos/etc live on a separate hard drive which gets backed up to the cloud.
All of that to say, with the right setup nix is mostly unnecessary, and honestly the benefit of not using it is that I can wipe my system anytime and restart it with just my usual important programs ready to go. Any mess made along the way gets purged automatically in every fresh install
I promise you that it will be worth it. Try again.
I love the combination.
I use devenv (yet another nix flake dev environments) and opencode.
It is quite a synergy : my nix usage profits from the agent and the agent profits from being able to install just anything.
I even vibecoded a plugin for personal use that runs all bash tool calls through devenv and uses the supplied nix lsp package:
https://github.com/riedel/opencode-devenv
Also being able to use wsl on my windows based work laptop added a lot to nixos affordance : https://nix-community.github.io/NixOS-WSL/install.html
Before AI, there was virtually no documentation, and there are so many ways to do any single thing that it makes it brutal to figure out what any given configuration was trying to do.
Is `nix` amazing though? Eh... if it were implemented better, it could be amazing. It's like python virtual environments or `pyproject.toml` for general software. It solves a real problem, but it does so by introducing a possibly even bigger problem.
No.
it's more like, it definitively solves a problem forever, like nothing else.
It's like when you have immutable data and it permanently solves a class of problems that can result from mutable data.
It's sort of like that.
I still cannot be bothered, even after reading this article.
[flagged]
Seeing Nix these days is such a whiplash experience. We have fully deterministic systems and then we have LLMs. God ;)
I use an agent to author my nix config - personally I don't have the determination to have picked Nix up entirely on my own so I find it to be a godsend. I can code review config changes and keep it all in git - also makes it easy to pick up the entire config and deploy it on a different machine.
Plus if it messes up, you can just roll back.
I don't vibe code my config but this is still my favorite part. If I had it working at some point, I can always get my full system back to there
LLMs can be deterministic too! People just don't bother because the applications of this aren't widely known yet. See https://lukechampine.com/repligraphs
I was just reading Michael Lynch's posts about Sia[0] and I came across this.
Its a very curious project, but don't you end up pinning repligraph usability on model weights? Since you take indeterminism out of the equation, a repligraph's notability is as significant as the producing model's weights, and since there is no dice rolls to be made, the eyeball problem:
> Our blind spots, while not perfectly correlated, have substantial overlap
is entirely replicated. Models that are diffused from one another can have the same blind spots, the same loose statistical reality that exists with humans. This is partially addressed in steering:
> A repligraph proves that a model generated some artifact. It does not prove that the model did a good job, or that the artifact is safe.
but I think the "Peer Review" solution is inadequate, and with some jailbreaking prompts' innocuous looks considered, "the attacker just needs to find one prompt" might be much easier than it appears.
Batching seems to be a huge economic turn off for proprietary model determinism, but I think its entirely viable for consumer models. Trustless evals are brilliant and should've been our reality. Nice project, good luck on your endeavor.
[0]: https://mtlynch.io/tags/sia/
Thank you for the kind words! It's funny how much staying power those blog posts have, haha. Michael has some arcane ability to consistently hit the front page of HN.
True, I expect models to be pretty correlated with each other as well. But you can at least attempt to quantify that correlation in a rigorous way, by running experiments (e.g. by pointing each model at a big project and comparing the sets of bugs they each find).
And yeah, the "double-edged sword" aspect of determinism is definitely the biggest bullet that you have to bite. For me, it's better than the alternative; without determinism, such jailbreaking attacks are still possible, just harder to detect. But I certainly would not want people to go around thinking "it's deterministic, therefore it's safe."
Deterministic systems like tracing GCs, JIT compilers, PGO data, machine learning optimising passes that vary their output, depending on program behaviours?
If those systems are changing the semantics, they are buggy. If an LLM is changing the semantics, it's a tuesday.
The configuration can be sloppy and vibed, as long as it behaves the same every time nix retains its power :)
"What is this superpower, and why is nobody else using it?"
The "Undo" time-travelling debugger for C/C++ has been around for 20+ years. So I guess the answer is simply that most people chase shiny new things instead of using established, reliable, and, hence, boring tools.
Methinks debugger devs are awful at marketing their software. I didn't even know such a debugger even existed, and I've debugged quite a few programs.
I kind of confused what nix has to do with this considering it seems to basically be reimplementing rr?
I'd love to become a Nix user one day. I tried to write a rather complex flake one day; it ended up with Nix (nix command) deleting itself: I immediately lost trust with it.
This sounds like a total nightmare. I am very interested in Nix and was strongly considering setting it up on my new travel laptop as a daily driver but stories like these give me pause. I would love to get a more detailed explanation of what happened here. Either way I am past the phase where I'm comfortable or patient enough to beta test software so Debian / Ubuntu it is for me.
Nix daily driver for years here. I don't know what they did to screw up their system like that, but it's unusual IME. Normally you can just reboot and load the previous profile. Even in the absolute worst case, as long as you have your config, you could boot the installer and then load your config and your system comes back exactly as it was. It's definitely not beta software.
FWIW, I used Debian more than anything over decades, and also have little patience when it comes to unstable computers. NixOS is a breath of fresh air and has reinvigorated my love of Linux. I haven't found it less stable than Debian, and also have a higher degree of confidence when making changes. It has its quirks, but ultimately I've found it a joy to use, and I'm never going back to a distro that doesn't have similar capabilities.
If you boot default Debian and apt install a handful of packages from the primary channel, it probably doesn't matter much, but if you enjoy even a modest amount of customizing, NixOS really shines. From one Linux user to another, I encourage you to try it! I have no affiliation, just an old head stoked on Nix.
I used nix years ago on a Mac just as a sort of alternative to what I’d otherwise use homebrew for and I really liked it, so I decided a few times that i would try nixos for my laptop. Each time I was stopped by the awful documentation and the weird “flakes are experimental but kinda required” state of the project and I gave up.
This year I decided to give it another try and set it up on an ancient laptop using Claude to factor the config and it’s gone so well that I now use the same nix config to manage three different machines and it’s insanely liberating to know how easy it is to screw everything up and roll it back trivially. I now regularly make edits on one machine and then just routinely commit them and go apply on the other machines with zero friction. It’s kind of amazing.
Also Nix first tries to find a derivation in a remote cache and sets a very long timeout, so when you have a limited connection (e. g. a corporate limited network setup), it's painful.
I believe the default at least changed so it should be better now!
I find myself moving more and more non-build things into nix builds because I don't want to roll my own cache invalidation. Seems like this is yet another reason to do so.
Dude, this is amazing stuff. Farid really is putting out banger after Nix banger haha. This sounds like a mini/less capable Antithesis runtime, but running on your machine.
Curious: how does Rewind deal with randomness?
I had the exact same thought about Antithesis while reading this. I wonder if this could be used for concurrency bug hunting by setting up preconditions and grinding until failure to capture a bug you’re looking for.
The kernel's RNG is seeded from a seed passed at boot.
As far as I can tell, that is only one piece of the puzzle. I think the bulk of the work is on the hypervisor side (KVM) to eliminate/stub out sources of randomness in HW, patch out RDRAND, etc
[flagged]
The following page explains how Rewind VM works:
https://rewindvm.dev/#how
...of which the following are most important:
2. Run deterministically
One vCPU on stock KVM, so code in the VM runs on the real CPU. The VM's kernel carries a small Rewind platform: interrupts arrive only when the VM hands control to Rewind, time moves only then, and the timestamp counter and hardware RNG are hidden. A step is one of those handoffs.
3. Keep keyframes
Every quarter second of wall time, Rewind snapshots the machine using KVM's dirty-page [aka Memory Pages that have been written to since the last snapshot] log. Pages go into a content-addressed store (BLAKE3, zstd), so a page shared by keyframes, runs and forks is stored once."
Now, that's some brilliant engineering right there!
While I like the product name "Rewind VM" (and yes, that's what it allows the user to do!), it could just as easily be called "Deterministic VM" and that name would have been wholly appropriate, as well!
Future OS and VM engineers should study Rewind VM. Those are some great engineering ideas there, and determinism, or at least optional determinism, should it be desired, when it is desired -- is the one thing that is completely non-existent in most OS's, most VM's, and most other program runtime environments...
Anyway, a great article on using Rewind VM (never knew about it before this article!) with Nix builds.
Are you tooting your own horn?
There could be great ideas in Rewind VM, but the page is littered with Claude-ish which is immediately off-putting.
>There could be great ideas in Rewind VM, but the page is littered with Claude-ish which is immediately off-putting.
Then don't use it.
Many people won't, that being one of the reasons.
My eyes glazed over even the examples which seem to have a good premise, but almost immediately devolve into the prose I have to sit through every day.
Wow, that looks like a lazy and disrespectful attack.
Rewind VM appears to be made solely by fzakaria, the author of the submitted article. I don't see any connection to peter_d_sherman, who is clearly not a sock puppet account. It took 10 seconds to check that info.
God forbid people on HN get excited about a technology.
You, on the other hand, clearly have an axe to grind against LLM usage. Which is fine and all as a personal preference, but not a reason to post such a comment.
There are probably thousands of AI-produced projects submitted to HN each day. Should I get excited about all of them?
No, but you don't have admonish them or accuse of self-promotion. Use the flag button if you feel so inclined. You don't have to try to negate their excitement about something that seems genuinely novel, especially when not really engaged on the content of the project / post. Which it doesn't seem like you even really looked at.
So I have to be excited about every project, go and read through every Claude-authored text, and not form any opinion at all except visible and eager excitement?
I honestly have no idea what point you are making.
If you are in fact worried about the amount of work involved then I don't see why you would bother to comment at all, which is just more calories burned.
Anyway, cynically asking whether people are self-promoting (without any attempt at evidence) is far more than just sharing your opinion.
And it's clear you didn't force yourself to read through all that "Claude-authored text", otherwise you would not be left wondering if peter_d_sherman was self-promoting. (I don't know any of these people but it's clear they're all different).
My point was to tell you that you are exhibiting unacceptable behavior for a civil discussion. That's an example of sharing an opinion with justification.
so this is like redux but for the whole VM?
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]