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”.
Last month I bought a flet.dev subscription (and tokens 3 times over --- the recent update seems to be far more efficient in terms of what one gets for a given token spend?) and have been using it to try to make some small apps for CNC work and I am currently dismantling one based on converting the generated .md documentation and re-writing it with the source code inserted at appropriate places and with added commentary and documentation and links --- I'm confident that when I'm done I'll have a tool which I understand and which if need be, could be re-created w/o AI help, or ported to some different UI toolkit/build system.
But why don't we ask Claude to design a more sane version of Nix? And translate all the Nix files (or whatever they're called) to this user-friendly version?
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.
Unfortunately guix currently has banned LLM contributions. Its not set in stone but the developers intent to maintain a human based hacker environment. Nothing wrong with carving out ones own subculture of course!
There may be a sizable enough community interested in employing LLM usage to get together and create a dedicated channel for packages developed with them, or make a soft fork.
That being said, having worked on guix packages. Automated conversation is not so simple. The bottleneck for me is compilation time and cost. even with superdooper intelligence, you have to trial and error builds, fix mysterious test race conditions and match versions.
A powerful $5000 build server plus another several thousand per year for
The electricity cost would go a long way to speeding up this process.
Old second hand computers are not viable because the electricity cost for constantly building software on them is not cost effective.
It makes me kinda buthurt when some racist rich people can raise millions for some crappy arch skin distro soft fork, but serious, novel, from the ground up projects have to scratch around in the dirt for pennies.
The project may not have truly demonstrated it's worth to justify replacing nix, but I feel it's unique and special enough that it is deserving of some money falling from the sky. It's 1 of only 2 of this style of functional packaging distribution.
Guix being ideologically opposed to supporting macOS is what keeps me using Nix on my daily driver box. My NixOS box is there to run Steam, which I suspect is something Guix would also regard as anathema.
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.
Admittedly I haven't been in the C++ space for about a decade, but back in the day I used to love premake for this exact reason. You wrote your build config in a completely standard real scripting language: lua.
I know about Premake, and I completely agree that the Lua it uses is a far more pleasant language than CMake. Still, unfortunately, AFAIK, the build system itself isn't as feature-complete as CMake, and it doesn't have as extensive support in programming editors or across the broader C++ ecosystem.
The only thing that's really wrong with the nix language is that it's not statically typed, which can let errors pop up far from the mistake that created them
I don't like the attribute dot syntax. On the positive side, it's very readable. and the left-to-right syntax is a very clear and strong organization technique.
That said, it has a problem with 'rootedness' as in 'what is the root of this attribute string'.
Firstly, 'with' keyword allows you to silently slice off the front end when the attribute string originates from a passed-in argument variable.
Secondly, when you arrive at foo in foo.bar, you have no concept of what the ancestor path looks like; someone is going to do an import of this file, likely store it in a named variable in the context it is needed, and then dispose it. Every time we need foo, it's being referenced from some ephemeral external context. So it's impossible to say or know "foo has 5 references" via static analysis unless we are just grepping it.
Thirdly, (related to above), when you declare services.tailscale.enable = true; you are relying on some ephemeral other location to find meaning in services-dot as declared in the current file. Metaphorically, we can't actually turn and face upstream looking up the call stack to easily see how we arrived (nor how many times we expect to arrive) at this site.
'Self' in the context of flakes is another great example of emphemeral-ness and non-discoverability...what is accessible under 'self'? It takes a PHD to describe it.
Allowing strings mixed in (foo.bar."baz".biz) and the expectation that you might be interpolating (foo.bar."${baz}".biz) is a whole nother ball of wax...
> 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.
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.
> 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.
IMO most of linux issues come from "my distro ancient package registry does not have package X, let me google magic commands I need to run to installed version I need"
If I have issue with nixos, its 99 out of 100 times going to be package I pulled either from nixpkgs-unstable or 3d party flake.
NixOS make it less of a problem because I can alwasy switch to previous generation and build all of my hosts before switching any of them.
Some distros are worse then others though. Ubuntu (used to?) for some reasons loved switching nvidia drivers OSS version that does not work every update or break keyboard layout switcher. I never had such issues with NixOS, but with NixOS I have "kernel updated, reboot required" issue that I had setup alert for[1].
[1]: Only issue on a host that has nvidia card because nvidia being nvidia.
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.
I only do tinkering once. After that, it usually stays that way for as long as the option/setting exists and doesn't break.
For example, in 1996 I tweaked the buttons on Total Commander's main button bar (was called Windows Commander back then). I still use that same button bar today, 30 years later. Only some icons had to be replaced. I try to do the same in Linux, but...
There are some programs where this just doesn't work. Firefox for example has a bad habit of deprecating settings and adding new ones (with wrong defaults, because... money probably). It needs tinkering all the time.
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.
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.
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.
Its much easier for the agent to look at a nixos module and decide that it should do `services.nginx.enable = true` vs reverse engineering everything it should do to install nginx on the system.
And likewise if theres an issue then its much more straightforward for it to unwind what it did in nixos vs a traditional software install and not accidentally mess with other users/services on the system.
I have to agree, I've been using Fedora Bluefin and had some issues and Claude was able to troubleshoot it all. Would have taken me a bunch of time to untangle it myself.
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.
"World expert" might not even be that bad of a characterization. It's familiar with the ins-and-outs and every major distribution, every DE, is fluent in debugging at any level (knows every network utility, container technology, systemd option, sysctl, how various subsystems plug together and how to use them in practice, etc.), knows how to look up what it doesn't know if it's not up to date to within the literal last month or two, and if it came down to it, could patch/fix things, including reverse engineering hardware drivers.
I wouldn't be surprised if it could better deal with Linux issues than Linus.
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].
I'm having kinda the opposite experience, but it's less to do with Linux and more to do with hardware, firmware and manufacturers.
MiniPC network device doesn't have a Linux driver. At all. Had to get a vibe-coded, reverse engineered one. This was a first for me.
NAS (ugreen) was a pain in the ass to install my own OS on (I didn't trust theirs, wanted OpenSUSE, and had to get a reverse engineered LED controller driver so I could display hard drive health)
ASUS Laptop will not sleep properly, and would drain the battery flat in a day or do. Myself & Claude gave up after days of trying various tricks workarounds (up to BIOS hacks). The best I can do is hibernate (after about 5 minutes of sleep) but man, the hacky bullshit required to get there was incredible.
Different laptop sleeps fine but will not, under any circumstances, hibernate. Even though I have all the crazy tricks up my sleeve from the ASUS that won't sleep properly and needs to hibernate. Different hardware, totally different bullshit problems.
And then I recently got an Macbook M1 Max for local LLM hacking and everything just fucking works. I don't like MacOS but the hardware is amazing and the OS just fucking works with it (and I like that).
14 years on macOS, now running Debian on a Framework.
It can be clunky at times but I have no regrets. I’m now toying with the idea of multi-booting with Silverblue or a derivative, and guess what? I actually can do that if I want.
You expect Linux to work on anything you deicde install it on. That is the wrong approach. Get hardware that is well supported, then Linux works well too.
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.
Yes, there is constant drama but the ecosystem is healthy and you have a choice of multiple upstream "vendors" to hitch your wagon to in terms of your nix experience, and for the the most part they all compile down to the same set of hydra packages so its not really an issue.
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.
It's also decreased the friction of finding software that hasn't been given a package for Nix yet but can't run on it.
I just go into the directory with the software and tell Claude Code to make me a Nix shell or a Nix flake that can run the software. Then usually within a couple minutes it'll work out what it needs to run and build it.
I recently did the same thing with ComfyUI which I was running through Conda. I had Claude code go through and figure out how to make it run just in a plain nix shell with a venv. (I always struggled getting it to recognize my NVIDIA GPU without Conda)
+1. I personally have always wanted to write down my thoughts on NixOS in a long-ish form post.
But it’s just really hard to articulate. NixOS is such a step above any other distro that it becomes hard to convey exactly why this is the case. It is also because so many pieces work together in tandem - both above and below the covers so to speak - to make this the case.
There is really only one talk I have found that somewhat captures this, What Nix Can Do (and Can’t) by Matthew Croughan: https://youtu.be/6Le0IbPRzOE. Keep in mind that it’s a rapid fire-style talk with a ton of breadth, so it is natural to feel overwhelmed while watching if new to Nix :)
Also, here is a random dump of features that I have found both valuable and very difficult to achieve on other distros:
* Config rollback in bootloader to undo mistakes without needing to boot from recovery media
* Flake lockfiles to pin all config and packages
* Config layering: base config that applies to all machines, per-machine overrides, etc
* NixOS module system, very useful to conditionally enable functionality (e.g. subset of machines run Syncthing)
* Rebuild a host over SSH by copying over packages via nixos-rebuild
* Image builders i.e. Packer-lite (now in nixpkgs)
* Build a live CD/USB custom installer to quickly boot from with your own packages, user, dotfiles, etc
* NixOS integration testing framework (extremely powerful), makes package and config stability better under the hood in nixpkgs
* Build and run your config as a QEMU VM
* nixos-anywhere to convert a running Linux machine into NixOS, very useful for VPS/cloud machines
* Out of the box support for cross compilation and static linking via pkgsCross and pkgsStatic
* Stylix for centralized theming config across apps
* Natively build a Docker image from your package using dockerTools
Your title is verbatim how Nix made me feel when I first started years ago. It does so many small things in a pure format that it was hard to immediately come up with the "key ROI" the larger industry expected. Did it just speed up dev envs? Did it just make my builds faster? Back then, a lot of folks barely cared or understood the impact of the deterministic and reproducible foundation using Nix sets. I used to hear a lot of "but that's a day 100 issue", "docker/(insert other tool) solved all of this already".
"less afraid" was the easiest way to put it :)
Disclosure, fully Nix pilled Ron here from flox.dev and the NixOS foundation.
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 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)
It depends how you do it. Everything is a tradeoff. Do you want everything to get assembled on your laptop and pushed to your machines? That means your laptop ends up holding a copy of every package that's going to any machine. Do you want each machine to do its own config build, merely being "puppeted" by your laptop? That could be slow if your machines are small embedded devices. Or maybe you want to run the builds on a beefy remote server because you are doing custom builds from source instead of using the cache... All of this is possible with Nix, but there are real design considerations.
> 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.
Agree, I quickly ran into broken behaviors with Coolify (e.g. marketplace search filters straight up do nothing) and that didn't inspire trust. Komodo has been solid so far.
It's a similar trade-off to using Terraform to manage a resource, compared to just modifying some cloud resource directly.
You pay a higher upfront cost, but you end up with declarative code which has advantages for maintenance.
With NixOS, rollbacks from changes to system state are trivial; and the whole system is configured from a single starting point, which makes it easy to track down why things are a certain way.
For a personal workstation, it's not necessarily a practical trade-off.
If you manage 3-10+ machines, it's very convincing. 7 steps multiplied by 5 machines, or one edit to my Nix config?
It's even better with flakes. I can keep dozens of projects on-disk, and their dev environment is always versioned + synced with my workstation. I've torched entire weekends trying to get the same workflow out of direnv and pamac/homebrew. On Nix systems, it all lives in one or two git-synced files.
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.
> 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.
My recollection from trying this is that it's not so easy to find that specific nixpkgs commit. It's doable if you're determined, but it's not a 1 click thing, but my information may not be up to date.
If you `git blame` the software you're interested in, I can't imagine it should take too long to find the last commit that had the version you want. Then you could either use that, or for the first commit with the new version, use commit~. Or anywhere in between depending on whether dependencies are important to you (that's at the limit of my git-fu, but I imagine you could do some kind of restricted blame to then find the dependency version you care about if you do care, and recursively do that until you have exactly what you want).
If you have a CI system that's building containers (e.g. using flakes), you can have the nixpkgs version you're using pinned in your own config, so you can just look at your own (smaller) history.
This should all be way easier than trying to do it on any other distribution.
If you’re using flakes, as long as you don’t update the lock file, you will always install the exact same package. This holds across machines using the same config.
I've had NixOS on my machines now for about 3 years.
I'm also less afraid to make promising but risky changes. I have "broken" my machines multiple times, but each time this happens, I just boot back into the previous working iteration, with no real interruption to my work (or fun, depending on what that machine was for).
I can do things like try out new bleeding edge kernels and GPU drivers, important system libraries etc... getting the benefit of these things basically risk free.
There is also one server running NixOS serving up part of what runs Tunnelmole in production.
Initially LLMs were not good at writing Nix, but now they're much better and a good coding agent can do a write/build loop until their config works.
The point is that you write the general part of the restic config (like the schedule and the S3 endpoint) once, in one place (i.e restic.nix). Then each service-specific part of the restic config, like the line above, lives next to other configs for the freshrss service (i.e. freshrss.nix, not restic.nix). Then a build step generates scripts and systemd units for restic from the merged config. This makes it very easy to remove any service and all traces of it, even when it has “cross-cutting” configs.
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.
Thanks. I’ve edited my comment it so our answers complement each other better.
Aside from services, this pattern is everywhere once you start recognizing it. For example, my Claude Code config in Nix adds CLAUDE.local.md to the global gitignore, my Git config adds aliases to my shell, and my terminal config adds a monospace font to the system fonts.
What sort of backups are you after? For a system-wide backup, I don't bother. I have the git config for the system in a remote repo. Rebuilding the system is a matter of bootstrapping and then just pointing nix at the config. For my data that is outside the scope of nix, i just have a rclone cron that syncs to/from a remote store.
Given the flake for freshrss doesn't have any sort of explicit "backup" option, my hunch is the author is doing something similar. Point the data dir to a location that gets automatically sync'd elsewhere.
Just remember that NixOS is only for personal and hobby use cases, as it is maintained by a large community of people that can ship any code they want without review, anchored on the honor system. Think wikipedia anons managing your browser and password manager.
If you want high supply chain security appropriate for production use, it is a lot more work that a lot fewer people are willing to do, which means far fewer packages. Though probably the packages you need for a server or build system or minimalist workstation.
> Just remember that NixOS is only for personal and hobby use cases, as it is maintained by a large community of people that can ship any code they want without review, anchored on the honor system.
This is somewhat inaccurate, and loosely written.
It would be more meaningful to talk about the nixpkgs repository. If you wanted to, you could use Nix with your own vetted nixpkgs codebase.
Whether there are any contributors who can merge without review I'm not sure, but the typical path for contributions is to go through review.
It is permitted to merge code from anonymous people, who could be alter-egos of the maintainer themselves, or whoever stole their credentials. Code signing is not enforced and never will be. I authored the rejected RFC for enforcing code and review signing myself. It is at odds with the community honor system volunteer hobby contributors wish to maintain.
Review is entirely honor system in the nix ecosystem.
This is a hard truth I really need those promoting it for high security use cases to understand.
I used to run freshrss on nixos and moved to hosted debian with docker-compose and neveer had a breakage either while using docker compose. says a lot about freshrss not about because running on nixos is being more "stable"
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.
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.
Yes. I run NixOS on 5 machines, one of which is a gaming laptop with an Nvidia card that makes heavy use of Steam and Proton. It works fantastic and is so much less of a headache than Windows.
Gaming works extremely well. You can even get a SteamOS-like experience via Jovian, which is basically an overlay that provides a curated set of packages and configs.
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!
Yes, AUR is one of the things that brought me to Arch back in the day. I was really tired of building and maintaining my own .debs.
I'd say Nix is even easier than pacman/AUR from a maintenance perspective because you can create overlays for whatever you'd like to change and not worry about the mechanics of building your own packages. The overrides are just maintained in the flake or nix config. Also there are already a huge amount of packages in the nixpkgs repo (probably more than base Arch + AUR.)
I'm on Arch too, but after installing NixOS on two side laptops I have, I kinda fell in love. I don't want to go through reconfiguring everything, but once this laptop dies, I'm going to switch.
Arch is really great, but using the system now for ~5 years I cannot remember where every configuration is, which packages are installed and why, and things just get messy. I'm sure that some issues the system has are do to things I screwed up along the way, and these will be solved if I just reinstall. But with NixOS it feels so easy to find what changes you've done to the system, to leave a comment saying why etc. It feels to me much more maintainable.
all good points, i think it really is just a preference thing, i keep config files in github via chezmoi and then just chezmoi apply on different machines.
i agree things get a bit messy but i try to keep the OS in a state where I can reinstall at any time without any trouble.
config files on github, pacman -S any tools i need, important docs all in the cloud already, couldnt get much simpler than that imo
i do get the desire to have a reproducible OS, just dont know that its something i need
Similar on my arch setup but using gnu stow + git-store-meta, and a little wrapper that reminds me if a particular config previously applied has had new files added to it and should be re-stow'd
I've spent the last few years deep diving Nix / NixOS and I can definitely say that you do not want to run the unstable channel nor using flakes. Just stick with stable and if you must; add very limited unstable packages via flake configuration. Keep 99.99% on stable and do not use the latest Linux kernel either.
Using unstable will result in breaking changes giving you a headache. Trying to run a bleeding edge modern laptop with some of the absolute latest software versions is only going to blow up on you and you'll be stuck trying to work around upstream breaking changes that are not even the fault of NixOS.
Lately, I use NixOS on servers mostly without flakes and use flakes and Home Manager on Win11 WSL & macOS Darwin. However, NixOS on my laptop and workstation blew up on me with a blank black screen on every boot. There were no code changes just updating stable / unstable nixpkgs and it refused to boot. A.I. couldn't figure out what the problem was. It wasn't the video drivers; it was some kind of kernel bug with the latest kernel that bit me. I ended up with a bricked system even after burning a new ISO and wiping it out, the new installation failed in the exact same way. Trying an older kernel didn't fix it either. It would boot from flash ISO install everything, but first boot resulted in the black screen. It was eventually fixed 2-3 days later but I had a need to fix that laptop urgently.
I decided to give Omarchy a spin and was impressed; I replaced NixOS on my laptop and primary desktop workstation with Omarchy. Servers are still NixOS. While I built most things myself in NixOS, having that out of box experience with Omarchy and the fact that I can just tell the A.I. to fix and configure stuff was a game changer.
In the last year or so, A.I. has gotten much better with configuring NixOS. Omarchy provides skills.md files to train Omarchy on how to configure and fix things. This improves the overall A.I. experience on Omarchy. Without any A.I. skills the frontier A.I. agents have gotten much better at working with NixOS.
If the NixOS Community writes some skills for A.I. agents, it should vastly improve the quality of using A.I. agents to configure NixOS.
Where NixOS really shines is in solving software development problems. Writing a flake.nix file and dropping it into your repo then any users with Nix installed will execute that flake.nix via direnv when changing directories into the cloned project directory. Thus, installing all the of the project's dependencies including the language. Therefore, Node.js / Python / Ruby can be installed per project instead of per user or globally on the system. Imagine you have an old Python project that won't run with the latest Python. This is no longer a problem because when you change directories into project1 and it installs the versions you need then when you exit the project folder all the dependencies are de-referenced from the /nix/store and the environment destroyed. Change to project2 and it spins up an entirely different set of dependencies. This instantly solves many problems from a newbie developer joining the team and being immediately able to clone and build a project to ensure all the devs have the same flake.nix so they all immediately reproduce the project perfectly ensuring all the proper dependencies are working. You can also put the flake.nix in your CI / CD pipeline to ensure nightly builds are working same as the developers. Spread this across Production, QA / Test, & Development environments. You can create a custom ISO installer including your configuration in the ISO and you can PXE network boot it too. You can have a variety of computer configurations in the same Nix set of configuration files.
Nix the package manager can be installed on any Linux distribution. I am likely going to install Nix on Omarchy so I can use it for development purposes. I find Nix more robust over MISE which Omarchy depends upon for most of their development tooling.
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.
> container image [...] no guarantee the same thing works six months down the line when reinstalling, unless we wrote down which exact container image we downloaded
Then you should write down the exact image you downloaded. Images are tagged and hashed, you're guaranteed to download the same thing again if you ask for it.
I always explicitly request a version tag for every container image I configure in my system. If I want to upgrade, it's obvious what I'm going from and to, so I can check the changelog for breaking changes.
Are people seriously running :latest everywhere? No wonder the author thinks it's not stable.
As I mentioned, personally I request versioned tags. That's the level of specificity that I desire to prevent surprise breaking changes. There is nothing to preclude you from requesting a hash if you want, it works just as well.
Typically I am installing images from large, established projects whose release practices I can trust to not re-use an old version tag and slip in a breaking change. It's technically possible, but why would they do that? Unless they've been hijacked, then it becomes about security posture which I see as a separate discussion to this one about breaking changes.
Someone like the author, or maybe yourself, may not trust their software repository and want a hash like Nix's lockfile, which is totally fine. My point is that you can do that just fine with container images, so the author's statement is not the complete picture.
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.
[1] https://news.ycombinator.com/item?id=25788317
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”.
Or just document things well enough that they are explained and can be re-created from scratch?
https://news.ycombinator.com/item?id=47300747
c.f.,
http://literateprogramming.com/
Last month I bought a flet.dev subscription (and tokens 3 times over --- the recent update seems to be far more efficient in terms of what one gets for a given token spend?) and have been using it to try to make some small apps for CNC work and I am currently dismantling one based on converting the generated .md documentation and re-writing it with the source code inserted at appropriate places and with added commentary and documentation and links --- I'm confident that when I'm done I'll have a tool which I understand and which if need be, could be re-created w/o AI help, or ported to some different UI toolkit/build system.
But why don't we ask Claude to design a more sane version of Nix? And translate all the Nix files (or whatever they're called) to this user-friendly version?
nix actually very simple. as simple as go.
there are some bad things, but there is nix language version which fixes edge cases.
nickel as language seems good alternative for nix btw.
Guix already uses a real language instead.
Just wanted to chime in and say that is a very good talk, and I recommend people give it the time.
Nix as a concept is amazing, Nix as a language sucks. Combining it with a LLM really is a cheatcode.
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.
Unfortunately guix currently has banned LLM contributions. Its not set in stone but the developers intent to maintain a human based hacker environment. Nothing wrong with carving out ones own subculture of course! There may be a sizable enough community interested in employing LLM usage to get together and create a dedicated channel for packages developed with them, or make a soft fork.
That being said, having worked on guix packages. Automated conversation is not so simple. The bottleneck for me is compilation time and cost. even with superdooper intelligence, you have to trial and error builds, fix mysterious test race conditions and match versions.
A powerful $5000 build server plus another several thousand per year for The electricity cost would go a long way to speeding up this process. Old second hand computers are not viable because the electricity cost for constantly building software on them is not cost effective.
It makes me kinda buthurt when some racist rich people can raise millions for some crappy arch skin distro soft fork, but serious, novel, from the ground up projects have to scratch around in the dirt for pennies. The project may not have truly demonstrated it's worth to justify replacing nix, but I feel it's unique and special enough that it is deserving of some money falling from the sky. It's 1 of only 2 of this style of functional packaging distribution.
Guix being ideologically opposed to supporting macOS is what keeps me using Nix on my daily driver box. My NixOS box is there to run Steam, which I suspect is something Guix would also regard as anathema.
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.
Admittedly I haven't been in the C++ space for about a decade, but back in the day I used to love premake for this exact reason. You wrote your build config in a completely standard real scripting language: lua.
https://premake.github.io/docs/What-Is-Premake
I know about Premake, and I completely agree that the Lua it uses is a far more pleasant language than CMake. Still, unfortunately, AFAIK, the build system itself isn't as feature-complete as CMake, and it doesn't have as extensive support in programming editors or across the broader C++ ecosystem.
I use nix-darwin and nix on CachyOS (and pretty much everything else, including a little NixOS for fun), daily.
I can confirm all of your comments, and someone will come up with something similar that's easier on the eyes.
The only thing that's really wrong with the nix language is that it's not statically typed, which can let errors pop up far from the mistake that created them
I don't like the attribute dot syntax. On the positive side, it's very readable. and the left-to-right syntax is a very clear and strong organization technique.
That said, it has a problem with 'rootedness' as in 'what is the root of this attribute string'.
Firstly, 'with' keyword allows you to silently slice off the front end when the attribute string originates from a passed-in argument variable.
Secondly, when you arrive at foo in foo.bar, you have no concept of what the ancestor path looks like; someone is going to do an import of this file, likely store it in a named variable in the context it is needed, and then dispose it. Every time we need foo, it's being referenced from some ephemeral external context. So it's impossible to say or know "foo has 5 references" via static analysis unless we are just grepping it.
Thirdly, (related to above), when you declare services.tailscale.enable = true; you are relying on some ephemeral other location to find meaning in services-dot as declared in the current file. Metaphorically, we can't actually turn and face upstream looking up the call stack to easily see how we arrived (nor how many times we expect to arrive) at this site.
'Self' in the context of flakes is another great example of emphemeral-ness and non-discoverability...what is accessible under 'self'? It takes a PHD to describe it.
Allowing strings mixed in (foo.bar."baz".biz) and the expectation that you might be interpolating (foo.bar."${baz}".biz) is a whole nother ball of wax...
> 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.
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!
The difference is on Windows when I have an issue it’s usually just straight up not fixable.
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.
I think its very dependent on hardware.
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.
> 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.
Yes, it has benefits, but it also has a cost.
I also find the people developing FOSS give me more choices and my computer works closer to what I want by default.
IMO most of linux issues come from "my distro ancient package registry does not have package X, let me google magic commands I need to run to installed version I need"
If I have issue with nixos, its 99 out of 100 times going to be package I pulled either from nixpkgs-unstable or 3d party flake.
NixOS make it less of a problem because I can alwasy switch to previous generation and build all of my hosts before switching any of them.
Some distros are worse then others though. Ubuntu (used to?) for some reasons loved switching nvidia drivers OSS version that does not work every update or break keyboard layout switcher. I never had such issues with NixOS, but with NixOS I have "kernel updated, reboot required" issue that I had setup alert for[1].
[1]: Only issue on a host that has nvidia card because nvidia being nvidia.
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.
I only do tinkering once. After that, it usually stays that way for as long as the option/setting exists and doesn't break.
For example, in 1996 I tweaked the buttons on Total Commander's main button bar (was called Windows Commander back then). I still use that same button bar today, 30 years later. Only some icons had to be replaced. I try to do the same in Linux, but...
There are some programs where this just doesn't work. Firefox for example has a bad habit of deprecating settings and adding new ones (with wrong defaults, because... money probably). It needs tinkering all the time.
That is the way to do it. There is a danger of getting carried away with and never stopping tinkering.
But I love tinkering!
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.
curiosity is good
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 I few the same way about cloud services, impossible to humanly-parse AWS articles are finally _useful_.
> Now I just install claude code and tell it what I want my OS to be and how I want it to look.
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.
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.
Its much easier for the agent to look at a nixos module and decide that it should do `services.nginx.enable = true` vs reverse engineering everything it should do to install nginx on the system.
And likewise if theres an issue then its much more straightforward for it to unwind what it did in nixos vs a traditional software install and not accidentally mess with other users/services on the system.
This. Claude Code made NixOS affordable in term of time for us mere mortals.
I have to agree, I've been using Fedora Bluefin and had some issues and Claude was able to troubleshoot it all. Would have taken me a bunch of time to untangle it myself.
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.
"World expert" might not even be that bad of a characterization. It's familiar with the ins-and-outs and every major distribution, every DE, is fluent in debugging at any level (knows every network utility, container technology, systemd option, sysctl, how various subsystems plug together and how to use them in practice, etc.), knows how to look up what it doesn't know if it's not up to date to within the literal last month or two, and if it came down to it, could patch/fix things, including reverse engineering hardware drivers.
I wouldn't be surprised if it could better deal with Linux issues than Linus.
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].
[0] https://xkcd.com/353/
installing chinese keyboard in English Windows and remapping default keys doesn't strike ma as cohesive defaults
>Now I just install claude code and tell it what I want my OS to be and how I want it to look.
What could possibly go wrong.
I'm having kinda the opposite experience, but it's less to do with Linux and more to do with hardware, firmware and manufacturers.
MiniPC network device doesn't have a Linux driver. At all. Had to get a vibe-coded, reverse engineered one. This was a first for me.
NAS (ugreen) was a pain in the ass to install my own OS on (I didn't trust theirs, wanted OpenSUSE, and had to get a reverse engineered LED controller driver so I could display hard drive health)
ASUS Laptop will not sleep properly, and would drain the battery flat in a day or do. Myself & Claude gave up after days of trying various tricks workarounds (up to BIOS hacks). The best I can do is hibernate (after about 5 minutes of sleep) but man, the hacky bullshit required to get there was incredible.
Different laptop sleeps fine but will not, under any circumstances, hibernate. Even though I have all the crazy tricks up my sleeve from the ASUS that won't sleep properly and needs to hibernate. Different hardware, totally different bullshit problems.
And then I recently got an Macbook M1 Max for local LLM hacking and everything just fucking works. I don't like MacOS but the hardware is amazing and the OS just fucking works with it (and I like that).
I moved back from MacOS after 10 years because I had constant issues and was running into their bugs.
Almost 10 months on Fedora Asahi, so somewhat experimental platform, and had very little issues, nearly none.
14 years on macOS, now running Debian on a Framework.
It can be clunky at times but I have no regrets. I’m now toying with the idea of multi-booting with Silverblue or a derivative, and guess what? I actually can do that if I want.
You expect Linux to work on anything you deicde install it on. That is the wrong approach. Get hardware that is well supported, then Linux works well too.
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.
There is drama, yes. But it is getting a lot better recently.
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.
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.
Flakes are neither stable or unstable...
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.
"Experimental does not mean unstable" (2023) https://determinate.systems/blog/experimental-does-not-mean-...
I know not everyone is a fan of DS, but this post has a nice, concise explanation of how to think about the state of flakes.
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.
Yes, there is constant drama but the ecosystem is healthy and you have a choice of multiple upstream "vendors" to hitch your wagon to in terms of your nix experience, and for the the most part they all compile down to the same set of hydra packages so its not really an issue.
[dead]
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.
It's also decreased the friction of finding software that hasn't been given a package for Nix yet but can't run on it.
I just go into the directory with the software and tell Claude Code to make me a Nix shell or a Nix flake that can run the software. Then usually within a couple minutes it'll work out what it needs to run and build it.
I recently did the same thing with ComfyUI which I was running through Conda. I had Claude code go through and figure out how to make it run just in a plain nix shell with a venv. (I always struggled getting it to recognize my NVIDIA GPU without Conda)
Similar here, but I'm running rootless podman containers in Guix like this:
+1. I personally have always wanted to write down my thoughts on NixOS in a long-ish form post.
But it’s just really hard to articulate. NixOS is such a step above any other distro that it becomes hard to convey exactly why this is the case. It is also because so many pieces work together in tandem - both above and below the covers so to speak - to make this the case.
There is really only one talk I have found that somewhat captures this, What Nix Can Do (and Can’t) by Matthew Croughan: https://youtu.be/6Le0IbPRzOE. Keep in mind that it’s a rapid fire-style talk with a ton of breadth, so it is natural to feel overwhelmed while watching if new to Nix :)
Also, here is a random dump of features that I have found both valuable and very difficult to achieve on other distros:
* Config rollback in bootloader to undo mistakes without needing to boot from recovery media
* Flake lockfiles to pin all config and packages
* Config layering: base config that applies to all machines, per-machine overrides, etc
* NixOS module system, very useful to conditionally enable functionality (e.g. subset of machines run Syncthing)
* Rebuild a host over SSH by copying over packages via nixos-rebuild
* Image builders i.e. Packer-lite (now in nixpkgs)
* Build a live CD/USB custom installer to quickly boot from with your own packages, user, dotfiles, etc
* NixOS integration testing framework (extremely powerful), makes package and config stability better under the hood in nixpkgs
* Build and run your config as a QEMU VM
* nixos-anywhere to convert a running Linux machine into NixOS, very useful for VPS/cloud machines
* Out of the box support for cross compilation and static linking via pkgsCross and pkgsStatic
* Stylix for centralized theming config across apps
* Natively build a Docker image from your package using dockerTools
> Rebuild a host over SSH by copying over packages via nixos-rebuild
+1! This is immensely useful when running on hardware where builds can take a long time due to limited resources, like a Raspberry Pi.
I recently came across https://github.com/halfwhey/nix-apple-container which allowed me to configure nix to build for Pi using containers on MacOS.
Your title is verbatim how Nix made me feel when I first started years ago. It does so many small things in a pure format that it was hard to immediately come up with the "key ROI" the larger industry expected. Did it just speed up dev envs? Did it just make my builds faster? Back then, a lot of folks barely cared or understood the impact of the deterministic and reproducible foundation using Nix sets. I used to hear a lot of "but that's a day 100 issue", "docker/(insert other tool) solved all of this already". "less afraid" was the easiest way to put it :) Disclosure, fully Nix pilled Ron here from flox.dev and the NixOS foundation.
If you’re curious about FreshRSS please also evaluate miniflux. A fraction of the resource consumption and a better overall experience IMO.
Miniflux homepage really undersells it.
Seconding miniflux, happy user here for ~2 years.
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).
What RSS feeds are people following? Mostly tech stuff?
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)
> plus I can easily manage multiple machines
> I prefer to bootstrap them from I laptop with a single command
Nix is great at that kind of stuff
Nix will install me clickhouse on 2 devices at once, create restricted networking between 6 devices?
It can. For instance I have a flake where I define all of my machines, share some confit between them and have clearly defined customisation points.
Form that configuration I can build everything on one of my machines and push the builds to the others. Or each machine can do its own builds.
Have a look at projects like NixOps or Colmena to see some more automation on top of standard builds targeting other machines.
And how much disk space this takes?
It depends how you do it. Everything is a tradeoff. Do you want everything to get assembled on your laptop and pushed to your machines? That means your laptop ends up holding a copy of every package that's going to any machine. Do you want each machine to do its own config build, merely being "puppeted" by your laptop? That could be slow if your machines are small embedded devices. Or maybe you want to run the builds on a beefy remote server because you are doing custom builds from source instead of using the cache... All of this is possible with Nix, but there are real design considerations.
Depending on your specific requirements, yes. And quite elegantly.
There are several ways to do this. For one, see: https://github.com/nix-community/colmena
Sure. I do this in my homelab with ~20 devices, most are very small/embedded, a few are bigger including the build machine.
Everything you said here can be done with nix as well
> 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.
wasnt a big fan of coolify but i love https://komo.do/
Agree, I quickly ran into broken behaviors with Coolify (e.g. marketplace search filters straight up do nothing) and that didn't inspire trust. Komodo has been solid so far.
9 or 20 lines of nixos vs 7 steps on another OS vs some copy/paste with docker. It's not very convincing
It's a similar trade-off to using Terraform to manage a resource, compared to just modifying some cloud resource directly.
You pay a higher upfront cost, but you end up with declarative code which has advantages for maintenance.
With NixOS, rollbacks from changes to system state are trivial; and the whole system is configured from a single starting point, which makes it easy to track down why things are a certain way.
For a personal workstation, it's not necessarily a practical trade-off.
If you manage 3-10+ machines, it's very convincing. 7 steps multiplied by 5 machines, or one edit to my Nix config?
It's even better with flakes. I can keep dozens of projects on-disk, and their dev environment is always versioned + synced with my workstation. I've torched entire weekends trying to get the same workflow out of direnv and pamac/homebrew. On Nix systems, it all lives in one or two git-synced files.
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.
> 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.
My recollection from trying this is that it's not so easy to find that specific nixpkgs commit. It's doable if you're determined, but it's not a 1 click thing, but my information may not be up to date.
If you `git blame` the software you're interested in, I can't imagine it should take too long to find the last commit that had the version you want. Then you could either use that, or for the first commit with the new version, use commit~. Or anywhere in between depending on whether dependencies are important to you (that's at the limit of my git-fu, but I imagine you could do some kind of restricted blame to then find the dependency version you care about if you do care, and recursively do that until you have exactly what you want).
If you have a CI system that's building containers (e.g. using flakes), you can have the nixpkgs version you're using pinned in your own config, so you can just look at your own (smaller) history.
This should all be way easier than trying to do it on any other distribution.
I’ve never used it but https://trynix.dev/ should allow you to find the versions of nixpkgs with specific versions of a set of packages
https://nixmultiverse.com
If you’re using flakes, as long as you don’t update the lock file, you will always install the exact same package. This holds across machines using the same config.
[dead]
I've had NixOS on my machines now for about 3 years.
I'm also less afraid to make promising but risky changes. I have "broken" my machines multiple times, but each time this happens, I just boot back into the previous working iteration, with no real interruption to my work (or fun, depending on what that machine was for).
I can do things like try out new bleeding edge kernels and GPU drivers, important system libraries etc... getting the benefit of these things basically risk free.
There is also one server running NixOS serving up part of what runs Tunnelmole in production.
Initially LLMs were not good at writing Nix, but now they're much better and a good coding agent can do a write/build loop until their config works.
How do you configure the backups with NixOS? Didn't see that explained in the article at all
You would add something like:
The point is that you write the general part of the restic config (like the schedule and the S3 endpoint) once, in one place (i.e restic.nix). Then each service-specific part of the restic config, like the line above, lives next to other configs for the freshrss service (i.e. freshrss.nix, not restic.nix). Then a build step generates scripts and systemd units for restic from the merged config. This makes it very easy to remove any service and all traces of it, even when it has “cross-cutting” configs.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.
Thanks. I’ve edited my comment it so our answers complement each other better.
Aside from services, this pattern is everywhere once you start recognizing it. For example, my Claude Code config in Nix adds CLAUDE.local.md to the global gitignore, my Git config adds aliases to my shell, and my terminal config adds a monospace font to the system fonts.
Not op, but I have a similar setup. I declare systemd services and timers as Nix config to run a restic backup every night.
https://github.com/NixOS/nixpkgs/blob/nixos-26.05/nixos/modu...
What sort of backups are you after? For a system-wide backup, I don't bother. I have the git config for the system in a remote repo. Rebuilding the system is a matter of bootstrapping and then just pointing nix at the config. For my data that is outside the scope of nix, i just have a rclone cron that syncs to/from a remote store.
Given the flake for freshrss doesn't have any sort of explicit "backup" option, my hunch is the author is doing something similar. Point the data dir to a location that gets automatically sync'd elsewhere.
I set up a systemd job to run at shutdown to run Borg. The hardest part wasn't the Nix setup, but getting the right systemd magic words.
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.
Just remember that NixOS is only for personal and hobby use cases, as it is maintained by a large community of people that can ship any code they want without review, anchored on the honor system. Think wikipedia anons managing your browser and password manager.
If you want high supply chain security appropriate for production use, it is a lot more work that a lot fewer people are willing to do, which means far fewer packages. Though probably the packages you need for a server or build system or minimalist workstation.
See https://stagex.tools for contrast.
> Just remember that NixOS is only for personal and hobby use cases, as it is maintained by a large community of people that can ship any code they want without review, anchored on the honor system.
This is somewhat inaccurate, and loosely written.
It would be more meaningful to talk about the nixpkgs repository. If you wanted to, you could use Nix with your own vetted nixpkgs codebase.
Whether there are any contributors who can merge without review I'm not sure, but the typical path for contributions is to go through review.
It is permitted to merge code from anonymous people, who could be alter-egos of the maintainer themselves, or whoever stole their credentials. Code signing is not enforced and never will be. I authored the rejected RFC for enforcing code and review signing myself. It is at odds with the community honor system volunteer hobby contributors wish to maintain.
Review is entirely honor system in the nix ecosystem.
This is a hard truth I really need those promoting it for high security use cases to understand.
Supposedly Dutch government is looking to create a new distri off of Nix for their purposes.
Wonder how they'll manage the supply chain risk.
Meh, this is not any different than pypi, npm, crates, and every single other code repository.
Not every. This is why I created stagex.
I used to run freshrss on nixos and moved to hosted debian with docker-compose and neveer had a breakage either while using docker compose. says a lot about freshrss not about because running on nixos is being more "stable"
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.
I need a new linux flavour. How is nix is for you desktop?
The default is a bare-bones GNOME desktop manger (think Ubuntu if you're not familiar).
But of course you could customize it to look like any distro or even something totally new; I use hyprland with a pretty unique setup.
[dead]
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.
> NixOS ad or Claude Code ad
Can never tell with these submissions.
I really don't understand how "need to pay for an LLM subscription to be usable" isn't a large indictment of the tool.
It's always been a matter of skill issue. An LLM subscription being necessary or not says more about the user than the tool.
Blurting out skill issue has always been about ego jousting. Making collectively understandable software is something different to that.
Based on other testimonies here about the flake syntax, I seriously doubt that's the case.
It takes a certain kind of wizard to be able to master Nix overlays: https://nixos.wiki/wiki/Overlays
OK, but what's the init system again?
the absolute best one: systemd
AAAAAAAAAAAAAAAAA
im sure nixos is fantastic but honestly i just love arch so much i cant imagine ever using anything else.
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.
Yes. I run NixOS on 5 machines, one of which is a gaming laptop with an Nvidia card that makes heavy use of Steam and Proton. It works fantastic and is so much less of a headache than Windows.
Gaming works extremely well. You can even get a SteamOS-like experience via Jovian, which is basically an overlay that provides a curated set of packages and configs.
Steam (and games) all work flawlessly. Even streaming VR to my Quest 2 and flatscreen to my TV works perfect.
pacman and AUR are just so peak, nix os is cool but if you dont care a ton about reproducible builds, idk
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!
Yes, AUR is one of the things that brought me to Arch back in the day. I was really tired of building and maintaining my own .debs.
I'd say Nix is even easier than pacman/AUR from a maintenance perspective because you can create overlays for whatever you'd like to change and not worry about the mechanics of building your own packages. The overrides are just maintained in the flake or nix config. Also there are already a huge amount of packages in the nixpkgs repo (probably more than base Arch + AUR.)
I'm on Arch too, but after installing NixOS on two side laptops I have, I kinda fell in love. I don't want to go through reconfiguring everything, but once this laptop dies, I'm going to switch.
Arch is really great, but using the system now for ~5 years I cannot remember where every configuration is, which packages are installed and why, and things just get messy. I'm sure that some issues the system has are do to things I screwed up along the way, and these will be solved if I just reinstall. But with NixOS it feels so easy to find what changes you've done to the system, to leave a comment saying why etc. It feels to me much more maintainable.
all good points, i think it really is just a preference thing, i keep config files in github via chezmoi and then just chezmoi apply on different machines.
i agree things get a bit messy but i try to keep the OS in a state where I can reinstall at any time without any trouble.
config files on github, pacman -S any tools i need, important docs all in the cloud already, couldnt get much simpler than that imo
i do get the desire to have a reproducible OS, just dont know that its something i need
Similar on my arch setup but using gnu stow + git-store-meta, and a little wrapper that reminds me if a particular config previously applied has had new files added to it and should be re-stow'd
Giving your LLM a copy of nixpkgs and a nix executable is really great for getting something workable
I've spent the last few years deep diving Nix / NixOS and I can definitely say that you do not want to run the unstable channel nor using flakes. Just stick with stable and if you must; add very limited unstable packages via flake configuration. Keep 99.99% on stable and do not use the latest Linux kernel either.
Using unstable will result in breaking changes giving you a headache. Trying to run a bleeding edge modern laptop with some of the absolute latest software versions is only going to blow up on you and you'll be stuck trying to work around upstream breaking changes that are not even the fault of NixOS.
Lately, I use NixOS on servers mostly without flakes and use flakes and Home Manager on Win11 WSL & macOS Darwin. However, NixOS on my laptop and workstation blew up on me with a blank black screen on every boot. There were no code changes just updating stable / unstable nixpkgs and it refused to boot. A.I. couldn't figure out what the problem was. It wasn't the video drivers; it was some kind of kernel bug with the latest kernel that bit me. I ended up with a bricked system even after burning a new ISO and wiping it out, the new installation failed in the exact same way. Trying an older kernel didn't fix it either. It would boot from flash ISO install everything, but first boot resulted in the black screen. It was eventually fixed 2-3 days later but I had a need to fix that laptop urgently.
I decided to give Omarchy a spin and was impressed; I replaced NixOS on my laptop and primary desktop workstation with Omarchy. Servers are still NixOS. While I built most things myself in NixOS, having that out of box experience with Omarchy and the fact that I can just tell the A.I. to fix and configure stuff was a game changer.
In the last year or so, A.I. has gotten much better with configuring NixOS. Omarchy provides skills.md files to train Omarchy on how to configure and fix things. This improves the overall A.I. experience on Omarchy. Without any A.I. skills the frontier A.I. agents have gotten much better at working with NixOS.
If the NixOS Community writes some skills for A.I. agents, it should vastly improve the quality of using A.I. agents to configure NixOS.
Where NixOS really shines is in solving software development problems. Writing a flake.nix file and dropping it into your repo then any users with Nix installed will execute that flake.nix via direnv when changing directories into the cloned project directory. Thus, installing all the of the project's dependencies including the language. Therefore, Node.js / Python / Ruby can be installed per project instead of per user or globally on the system. Imagine you have an old Python project that won't run with the latest Python. This is no longer a problem because when you change directories into project1 and it installs the versions you need then when you exit the project folder all the dependencies are de-referenced from the /nix/store and the environment destroyed. Change to project2 and it spins up an entirely different set of dependencies. This instantly solves many problems from a newbie developer joining the team and being immediately able to clone and build a project to ensure all the devs have the same flake.nix so they all immediately reproduce the project perfectly ensuring all the proper dependencies are working. You can also put the flake.nix in your CI / CD pipeline to ensure nightly builds are working same as the developers. Spread this across Production, QA / Test, & Development environments. You can create a custom ISO installer including your configuration in the ISO and you can PXE network boot it too. You can have a variety of computer configurations in the same Nix set of configuration files.
Nix the package manager can be installed on any Linux distribution. I am likely going to install Nix on Omarchy so I can use it for development purposes. I find Nix more robust over MISE which Omarchy depends upon for most of their development tooling.
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.
[flagged]
> container image [...] no guarantee the same thing works six months down the line when reinstalling, unless we wrote down which exact container image we downloaded
Then you should write down the exact image you downloaded. Images are tagged and hashed, you're guaranteed to download the same thing again if you ask for it.
I always explicitly request a version tag for every container image I configure in my system. If I want to upgrade, it's obvious what I'm going from and to, so I can check the changelog for breaking changes.
Are people seriously running :latest everywhere? No wonder the author thinks it's not stable.
Do you request a version tag or a hash? In principle Docker tags are mutable
As I mentioned, personally I request versioned tags. That's the level of specificity that I desire to prevent surprise breaking changes. There is nothing to preclude you from requesting a hash if you want, it works just as well.
Typically I am installing images from large, established projects whose release practices I can trust to not re-use an old version tag and slip in a breaking change. It's technically possible, but why would they do that? Unless they've been hijacked, then it becomes about security posture which I see as a separate discussion to this one about breaking changes.
Someone like the author, or maybe yourself, may not trust their software repository and want a hash like Nix's lockfile, which is totally fine. My point is that you can do that just fine with container images, so the author's statement is not the complete picture.