Coming back to Nix (and Linux in general) this year has been an absolute pleasure.
Not because it's suddenly got better, but because the learning curve has collapsed to a flat line. My problem with linux has always been how un-user friendly it is. Constant tinkering around with config files and googling how to fix problems. Now I just install claude code and tell it what I want my OS to be and how I want it to look.
In some ways this makes Jonathan Blow's talk on the Bronze Age Collapse [1] even more poignant.
There was a point where I was working heavily with Nix and increasingly frustrated with its arcane syntax and way of doing things that made a conceptually extremely simple system into one of almost nightmarish complexity; juggling strange default and environment variables and seemingly random command line tooling. Inscrutable documentation that absolutely refused to define very basic concepts but went into insane detail on irrelevant details.
I had numerous ideas around fixing this and contributing to the project, and made some small contributions.
But now... Claude lets me just work around this by figuring out how to make it work. So now I don't understand and don't have to understand. I still look at the generated flakes, etc., when I'm dealing with it, but I'm rapidly losing the motivation to do that if things are just working.
I think this is bad but for reasons I can't quite put my finger on. Except to say that having complex tools with simple interfaces (Claude) is risky.
I can relate, I was all in on Nix for a while (and it’s still the best Linux IMO) but I’m a bit afraid of the complexity of the whole stack in an extended global economic downturn.
That said: the main fear here probably comes from the enormous size of nixpkgs and the overall cost of the infrastructure. Most individual package definitions should be relatively easy to maintain. So perhaps it isn’t such a big deal, if Nix infra built packages more slowly and reduced the scope of the repo then it could probably cope with having fewer maintainer hours available and less funding.
Still, something about it feels like a Tower of Babel situation. It goes just far enough beyond most people’s understanding to feel like it has fractal complexity. (Although it really isn’t that bad once you’ve spent enough time with it.)
These days I am more interested in simple, self-contained systems like OpenBSD than impressive feats of engineering. I still prefer Nix for most “work stuff”.
> Constant tinkering around with config files and googling how to fix problems.
i realised long ago this is usually a self-inflicted problem. Some of us (myself included) cannot resist tinkering with something that works reasonably well. When we use Windows its hard to tinker so we leave well along. Linux lets you tinker so we keep trying to reach perfection, and that breaks stuff.
> Some of us (myself included) cannot resist tinkering with something that works reasonably well. When we use Windows its hard to tinker so we leave well along. Linux lets you tinker so we keep trying to reach perfection, and that breaks stuff.
I think that tinkering serves a purpose. If you don't fully understand your tooling, you won't be able to fix it when something breaks. Tinkering teaches you that.
Also, you might miss out on improved workflow by leaving things alone.
The whole reason I use FOSS is that I don't some big tech architect to decide for me how my computer should work.
Disagree. Whether it’s Raspbian on a Pi, or Fedora or Mint on a modern laptop, issues still occur, and any minor issue immediately launches you into the world of the terminal, Google, StackOverflow, and Ubuntu forums.
Claude has definitely helped to reduce this negative!
I'm on Ubuntu 24.04 LTS, and things keep breaking after updates. When the video drivers break, YouTube starts dropping frames even at 1080p. When the audio drivers break, my headphones or microphone stop working. These kinds of issues were a nightmare before the LLM era. Now things are far easier.
On Ubuntu since 2006, Kubuntu the past several years on Dell, HP and Lenovo machines (multiple, home and work) and have not experienced what you're describing, odd. Wife too, complete non-techie, Ubuntu on 2 machines so far, no issues.
The worst my family have had was an MS surface running a rolling release distro because it was the only way to get the touchscreen working which failed at a bad time. Now switched to a more stable distro and looks OK.
On the other hand most laptops and all desktops have been trouble free. Even running a rolling release distro (Manjaro) has been fine on a laptop that was designed for Linux (and sold with Linux preinstalled).
Claude is useful, but my experience when I have fewer issues than Windows users seem to. I think Raspbian and Fedora are unfair comparisons, and people using Ubuntu, Mint etc. seem to have more problems than Windows users.
On windows I assume I cannot bend the OS to my will. On Linux I know I should be able to. The biggest issue is I am often so busy asking if I can do it that I don't stop to ask if I should do it. So I end up with weird configurations and random packages installed to tweak stupid stuff.
Some of it is real pain points, and those are annoying that they aren't baked into the distro from the beginning.
Yes, but I think, especially if its a machine you rely on, you have to exercise a bit of self control.
I tinker with one ARM based tablet, which never works quite right but because its a secondary device with limited use anyway its not a problem. My work laptop does not get messed around with unless necessary.
It’s less scary because when an LLM messes up, you can roll back its changes, which is much easier to do in NixOS, as opposed to other Linux distros where you have to take filesystem snapshots.
In my experience LLMs tend to work far better when they have a tree of structured information to search through and change.
Compared to poking at a mungy ball of accidental state where every change introduces complexity for the future which every downstream agent needs to correctly find is set. Rather than just seeing the definition from a file.
Yes. It is a shame they didn't use an established programming language and instead developed their own esoteric one—the same kind of issues as CMake, for example. I still don't understand why I should use a custom, crappy language to build C++ projects cross-platform. And the tragic part is that nothing else offers better functionality.
Guix :) It's a shame its package coverage is nowhere near NixPkgs, because it's so much nicer to read and write. I guess eventually we'll have "Compile-to-Nix" languages, seemingly these sort of languages tend to crop up after a while for languages with lets say "harder UX".
Maybe it would be a good idea to translate Nix packages to Guix automatically via LLMs. Then we could close the gap in available software relatively quickly.
Nix still has its share of fiddly problems and esoteric solutions. The difference is, once you (or your LLM) figures it out, you can write down in declarative code and it's solved forever. If it doesn't work, try something else or revert. Fearless system configuration.
yeah, so it's not like Linux is better, but you have now personal assistant to help you, not sure if that's benefit of Linux
I remember trying to remap keys in Linux Mint and install Chinese language keyboard were both major PITA requiring Claude/ChatGPT, while on Windows I could do it without any help in few minutes (the keyboard in seconds)
Remember when we were told only an expert should install Linux, and everyone else should just ask an enthusiast for help? Well, now we all have an expert at hand. Might not be a world expert, up to date in the very latest changes, but more than enough to make a lot of things that seemed impossible doable.
It's the same as it ever was. You go for Windows and macOS for cohesive defaults. You go for Linux for agility. Agility comes at a cost, but it's now lower than ever before, as NixOS + the agents are the closest you can come to `import antigravity`[0].
A lot of folks have been praising the harmony of Claude code + nixOS. For those of you doing this, I would recommend you to ask your agent to switch your config to nix flakes. It's a much better paradigm for working with the versioning than the default channels interface. Additionally, you should ask your agent to look into home manager, if it hasn't done so already.
I don't want to bore my HackerNews fellows, so I'm sorry in advance, but wasn't there a lot of drama in the Nix community? I've read some time ago that a private company was buying parts of its infrastructure (or something like that) and forcing some changes upstream and people were not happy about it.
I'm interested in NixOS, but I'm at an age where I just want things to stay stable and change only when they really have to. I already have a lot of big mandatory changes from life itself, I don't need more :)
I'm writing this in good faith. I'm genuinely curious and interested in trying it again.
Have flakes stabilized? I thought those were one of the points of contention, while also being the kind of thing that I was the most interested in as a way of hopefully managing a small fleet of VMs. I had trouble getting the idea to stick because I really believed in the single-config ideal reality, but couldn't bend my config far enough in.
They are defacto stable in that everyone is using them and the interface is not really going to change at this point.
But they are still marked as an experimental feature.
To get them out of experimental, the requirements are
normalizing the CLI. Currently some options are global and some are local to a command. The plan as I understand it is to make them all local. This would make it clear which options any particular command actually take instead of guess work. They are not going to break usage, but make the usage more clear.
And fetchTree needs to be stabilized. A big criticism of flakes is that they had a nonstandard method of fetching data and repos. fetchTree is a new nix built-in that behaves the same way. This makes flakes a lot less special.
So, nix flakes are a stable experimental feature, slowly getting to the state that it won't be experimental any more.
There was, it’s mostly dried up now that a bunch of the loudest voices split off to Lix. The Nix community weathered it decently despite some people’s best efforts.
I'm getting a lot of mileage converting all my little VMs and containers over to NixOS. Entirely using AI, Claude Code is remarkably good at creating Nix flakes. The declarative OS is a good match for LLM generation of system specs. No side effects of commands to track, everything testable and reproducible by the agent. And NixOS itself works quite well. Most of the packages I need are there and if something's missing Claude doesn't seem to have any problem making it itself.
> I dislike maintaining side projects. That includes my own code, but also self-hosted services developed by someone else. I’m okay with a few minutes of maintenance here and there, but having to schedule hours of uninterrupted work to upgrade something, or spending any amount of time at all on emergency maintenance, really kills my desire to work with computers.
I've struggled with the same problem, and Coolify helped me with it. It supports auto-deployment from GitHub via a bot integration, so you don't have to manage Github Actions. It can also deploy from a Docker Compose file, which is good for self-hosting other people's projects.
Of course you still have to have a list of instructions on how to set up your server with Coolify. But at least it's a finite set of instructions, meaning you don't have to update it every time you host a new project.
Same here. Reproducible configuration is amazing. Even a moderately complex app like Forgejo is easy to set a Nix module up for, with all the needed nginx/database/backup/etc. config nailed down and easily transferable to another machine if need be.
Personally I prefer ansible plus I can easily manage multiple machines but this is a little but different use case. I have 5 micro PC like orange pi, Raspberry pi, radxa... so I prefer to bootstrap them from I laptop with a single command in am event of failure
Also everything is running in kubernetes isolation so my OS is immutable and consume much less disk space than NixOS (I don't have too much of it and future is looking bleak in this department)
RSS feeds are getting rare now days. Thankfully, Google News still has a very robust and useful RSS feed.
I have a container running on GGoogle Cloud Run within the free tier. It runs runs twice weekly as well as once a month (for monthly news summary) to parse through specifically setup Google News RSS feeds and then trigger an email with key news items I'm specifically interested.
Gemini is used for determining which articles to include and exclude from the email summary based on my predefined criteria. It works really well in being able to keep on top of specific industry/tech news I'm interested in.
> two builds from the same Dockerfile separated by time can result in rather different container images
This is true, and the same is true of shell scripts, but isn't it true of nix as well? If you update nixpkgs and then install something, you have the same chance of getting a new version of it as you do with the `sudo apt-get install` in the Dockerfile, no? I had once looked into using nix to intentionally install older versions of software and it was not as easy as I had hoped.
You can install a single package from a specific nixpkgs commit and it will pull in whatever dependencies it needs to make that work, with everything as of the time of that commit. You may have duplicated libraries but they can coexist fine, and you'd have that with docker as well (probably even worse unless you are very intentional about building layers).
I imagine people do this somewhat regularly at least to e.g. occasionally pull in a package or two from unstable when they normally run a stable system.
That is true, but in that case you change the version number of the nixpkgs URL to the previous version, run again, and you're back to the old system in seconds. Then you schedule a better time to deal with the upgrade.
If you need to build a container image as if it was a year ago, you're hosed.
If the web interface is too minimalist/archaic for you, there's plenty of alternative frontends available you can deploy along. Personally, I'm using reminiflux (inspired by Google Reader).
Same for me. I have an agent generate the Nix and a tightened systemd unit for it, and off it goes. If I later want to remove it, I just throw it out of the config.
I used Arch for about a decade before trying out NixOS unstable channel. I won't be migrating back. Everything is much tighter and saner. Only complaint that I'd have is that the pull request merges and package builds lag behind a bit, but I've grown used to that. It's up-to-date enough.
Do you have experience with gaming on NixOS, particularly the Steam/Proton ecosystem? Recent non-reproducible distros like CachyOS and Bazzite have made gaming on Linux extremely accessible. Wondering how this fares in NixOS.
One strength of nixpkgs that probably appeals to Arch users too is how much software is available and how easily you can just re-compile apps with custom patches. In fact, the latter is enabled exactly through reproducibility :)
That said, cool if pacman and AUR work for you, no need to change just for the sake of it!
The point is that you write your backup config once, and then you co-locate the service-specific part of the backup config with the configuration for the service, and a build deterministically generates systemd units and scripts that back things up.
Just adding to this since the point might be lost for people new to nix:
You can assign a value to `services.restic.backups.my_repo.paths = [ ... ]` in multiple places throughout your system configuration. When applying the config, all the values will be merged into a single list.
This is important because other standard tasks besides backup (e.g. firewall, monitoring, ...) also require per-service configuration. If every one of these tasks had only a single place where you needed to put a megalist of services (which is basically how `/etc` works on typical Linux distros!), this would quickly scatter the configuration that pertains to FreshRSS over N different files, making it hard to track where everything lives.
While i admire the nix community i don't know how people can be spending their time on it to solve the types of problems they are, when AI is shitting out bad python code quicker than anyone can keep up with that's degrading all our systems. By one token you can argue that's a way of fighting back, but maybe also a possible way to bury your head in the sand while the rest of the world burns around you.
Not because it's suddenly got better, but because the learning curve has collapsed to a flat line. My problem with linux has always been how un-user friendly it is. Constant tinkering around with config files and googling how to fix problems. Now I just install claude code and tell it what I want my OS to be and how I want it to look.
There was a point where I was working heavily with Nix and increasingly frustrated with its arcane syntax and way of doing things that made a conceptually extremely simple system into one of almost nightmarish complexity; juggling strange default and environment variables and seemingly random command line tooling. Inscrutable documentation that absolutely refused to define very basic concepts but went into insane detail on irrelevant details.
I had numerous ideas around fixing this and contributing to the project, and made some small contributions.
But now... Claude lets me just work around this by figuring out how to make it work. So now I don't understand and don't have to understand. I still look at the generated flakes, etc., when I'm dealing with it, but I'm rapidly losing the motivation to do that if things are just working.
I think this is bad but for reasons I can't quite put my finger on. Except to say that having complex tools with simple interfaces (Claude) is risky.
[1] https://news.ycombinator.com/item?id=25788317
That said: the main fear here probably comes from the enormous size of nixpkgs and the overall cost of the infrastructure. Most individual package definitions should be relatively easy to maintain. So perhaps it isn’t such a big deal, if Nix infra built packages more slowly and reduced the scope of the repo then it could probably cope with having fewer maintainer hours available and less funding.
Still, something about it feels like a Tower of Babel situation. It goes just far enough beyond most people’s understanding to feel like it has fractal complexity. (Although it really isn’t that bad once you’ve spent enough time with it.)
These days I am more interested in simple, self-contained systems like OpenBSD than impressive feats of engineering. I still prefer Nix for most “work stuff”.
i realised long ago this is usually a self-inflicted problem. Some of us (myself included) cannot resist tinkering with something that works reasonably well. When we use Windows its hard to tinker so we leave well along. Linux lets you tinker so we keep trying to reach perfection, and that breaks stuff.
I think that tinkering serves a purpose. If you don't fully understand your tooling, you won't be able to fix it when something breaks. Tinkering teaches you that.
Also, you might miss out on improved workflow by leaving things alone.
The whole reason I use FOSS is that I don't some big tech architect to decide for me how my computer should work.
Claude has definitely helped to reduce this negative!
The worst my family have had was an MS surface running a rolling release distro because it was the only way to get the touchscreen working which failed at a bad time. Now switched to a more stable distro and looks OK.
On the other hand most laptops and all desktops have been trouble free. Even running a rolling release distro (Manjaro) has been fine on a laptop that was designed for Linux (and sold with Linux preinstalled).
Some of it is real pain points, and those are annoying that they aren't baked into the distro from the beginning.
I tinker with one ARM based tablet, which never works quite right but because its a secondary device with limited use anyway its not a problem. My work laptop does not get messed around with unless necessary.
What does this have to do with Nix, though? If you’re using an LLM to run everything, you don’t even need as many layers of abstractions or tools.
Compared to poking at a mungy ball of accidental state where every change introduces complexity for the future which every downstream agent needs to correctly find is set. Rather than just seeing the definition from a file.
I remember trying to remap keys in Linux Mint and install Chinese language keyboard were both major PITA requiring Claude/ChatGPT, while on Windows I could do it without any help in few minutes (the keyboard in seconds)
[0] https://xkcd.com/353/
I'm interested in NixOS, but I'm at an age where I just want things to stay stable and change only when they really have to. I already have a lot of big mandatory changes from life itself, I don't need more :)
I'm writing this in good faith. I'm genuinely curious and interested in trying it again.
It's a thriving open source ecosystem. There are forks, there are differing opinions, and in-depth discussions.
But, universally, everyone agrees that nixpkgs, independent from any implementation, is the real value of nix.
That said, things change. OpenSSL 4, glibc 2.44, gcc 16, etc which then requires a bit of tweaking every now and then.
They are defacto stable in that everyone is using them and the interface is not really going to change at this point.
But they are still marked as an experimental feature.
To get them out of experimental, the requirements are
normalizing the CLI. Currently some options are global and some are local to a command. The plan as I understand it is to make them all local. This would make it clear which options any particular command actually take instead of guess work. They are not going to break usage, but make the usage more clear.
And fetchTree needs to be stabilized. A big criticism of flakes is that they had a nonstandard method of fetching data and repos. fetchTree is a new nix built-in that behaves the same way. This makes flakes a lot less special.
So, nix flakes are a stable experimental feature, slowly getting to the state that it won't be experimental any more.
I've struggled with the same problem, and Coolify helped me with it. It supports auto-deployment from GitHub via a bot integration, so you don't have to manage Github Actions. It can also deploy from a Docker Compose file, which is good for self-hosting other people's projects.
Of course you still have to have a list of instructions on how to set up your server with Coolify. But at least it's a finite set of instructions, meaning you don't have to update it every time you host a new project.
Also everything is running in kubernetes isolation so my OS is immutable and consume much less disk space than NixOS (I don't have too much of it and future is looking bleak in this department)
I have a container running on GGoogle Cloud Run within the free tier. It runs runs twice weekly as well as once a month (for monthly news summary) to parse through specifically setup Google News RSS feeds and then trigger an email with key news items I'm specifically interested.
Gemini is used for determining which articles to include and exclude from the email summary based on my predefined criteria. It works really well in being able to keep on top of specific industry/tech news I'm interested in.
This is true, and the same is true of shell scripts, but isn't it true of nix as well? If you update nixpkgs and then install something, you have the same chance of getting a new version of it as you do with the `sudo apt-get install` in the Dockerfile, no? I had once looked into using nix to intentionally install older versions of software and it was not as easy as I had hoped.
I imagine people do this somewhat regularly at least to e.g. occasionally pull in a package or two from unstable when they normally run a stable system.
If you need to build a container image as if it was a year ago, you're hosed.
Miniflux homepage really undersells it.
If the web interface is too minimalist/archaic for you, there's plenty of alternative frontends available you can deploy along. Personally, I'm using reminiflux (inspired by Google Reader).
That said, cool if pacman and AUR work for you, no need to change just for the sake of it!
https://github.com/NixOS/nixpkgs/blob/nixos-26.05/nixos/modu...
https://github.com/Xophmeister/backer-upper/
I believe there are NixOS options to do this periodically -- which is even easier -- but I specifically wanted on-shutdown backups.
You can assign a value to `services.restic.backups.my_repo.paths = [ ... ]` in multiple places throughout your system configuration. When applying the config, all the values will be merged into a single list.
This is important because other standard tasks besides backup (e.g. firewall, monitoring, ...) also require per-service configuration. If every one of these tasks had only a single place where you needed to put a megalist of services (which is basically how `/etc` works on typical Linux distros!), this would quickly scatter the configuration that pertains to FreshRSS over N different files, making it hard to track where everything lives.
Can never tell with these submissions.