If you don't mind a very limited set of software, the way tinycorelinux is setup can also allow multiple different tcz installed
These two Linux distros essentially allow two different versions of same software/libraries (glibc/python whatever) installed
(Gobolinux explicitly states that whereas I find it to be an unintended but elegant consequence for tinycorelinux but I recommend taking a look at Gobolinux)
This is a simple reflection of the fact that Nix has a steep learning curve. People who persist generally have deep-enough interest or a compelling-enough use case to power through.
I feel like it's more of an indictment than praise; it implies Nix is relatively inaccessible to interested but time-constrained dabblers, which puts a hard cap on Nix's ability to outgrow its niche.
That binary feels forced when plenty bounce off it, return six months later, and only get it after a third round of pain. You need to be comfortable reading stack traces. If you want things 'just working' out of the box, Nix still has a talent for making you debug other people's build scripts for an hour, swear at it, and then come back anyway.
I'm the inbetween. I stuck with it for a couple of months, but ended up dropping it. It's just too slow and incurs a massive complexity penalty that I'm not happy about. I'd rather just deal with tarball rootfses and union mounts if I want an immutable system (and overwhelmingly I do not.) The reproducible builds are nice and all, but I'm not in a position to really take advantage of it. I'm sure Nix is killer for a modern sysadmin.
I'd much prefer just Plan 9. WORM filesystem and first-class namespaces.
This is niche and HN is full of these back and forth comments. One thing which a particular type of crowd will appreciate is being able to apply simple patches to constantly-up-to-date packages.
For an example, I love atuin but it, by default, skips commands starting with space. Currently it's not configurable and while I wait for time to submit a PR or for the issue to be resolved, make a single line `patch` which just removes the part of the `if` statement which checks if it starts with space. So easy, took 5 minutes (also had to comment out 1 test).
And now on home-manager debian or nixos server, I get up to date atuin with that one patch. It downloads rust, etc, compiles, and then that's garbage collected away
Same but with kernel. What lead me to nixos: company gave me a laptop with iGPU that wasn't supported by any released linux kernel. There were patches waiting to be merged, with nixOS making an installer image that supports my machine was simple.
I'm just curious what your motivation for the patch is, because I too use atuin and see the space-prefix as a feature. It's been around for a while (longer than atuin) to keep certain commands out of my history on purpose, like when running some one-off command with credentials as an arg.
Other than that I very much agree, patching stuff is wonderful in nix-land! Especially when things in nixpkgs-unstable break.
Although I’ve never committed to using nix system-wide, I do enjoy nix-based using https://devenv.sh/ for the very reasons described in the article. It’s much easier than local containers for development.
devenv also has tasks/services. For example you need to start redis, then your db, then seed it, and only then start the server. All of that could be aliases, yeah, but if you define them as aliases you can have them all up with `devenv up`. It even supports dependencies between tasks ("only run the db after migrations ran")
“Needed” is too strong, but this does not provide services, does not provide project-specific scripts, does not setup LSP, does not setup git hooks, can't automatically dockerize your build, does not support multiple profiles (e.g. local and CI), etc.
Modules let you express the system in smaller, composable, reusable parts rather than express everything in one big file. (There are other popular tools which support modules: NixOS, home-manager, flake-parts).
That devenv also provides "batteries included" modules for popular languages (including linters, LSPs) is also a benefit.
The UX is the big benefit, especially on teams who may not even know what nix is. I held off on exposing my nix setups for a long time, but devenv has made it possible to check things in without losing a ton of time to tech support.
home-manager manages your whole user's environment & desktop.
devenv does not do any user-level change (you will not be able to make it configure your WM), but works at the directory level.
For instance I'm currently working on a Rust + C++ project, and my devenv, whenever I enter this project folder: make CMake/g++/cargo/cbindgen available, enable a couple scripts to longer CMake invokations, set-up everything required for C++ and Rust LSPs, and create a couple git hooks to validate formatting etc.
I've never really understood how version pinning is meant to work with devenv.sh or Nix more generally. If I whack a .tool-versions file in my repo, everyone who works on it can use install the exact same versions of the relevant tools using asdf. That's low tech and imperfect (and certainly not a replacement for all of Nix's features), but it works as far as it goes. None of the examples on the devenv.sh page demonstrate pinning of tools/packages to specific versions.
As best I can tell, Nix enthusiasts think that this is an XY problem and that I shouldn't want to pin individual tools/packages to arbitrary versions. But the thing is that I am a rude barbarian who very much does want to do this, however philosophically misguided it might be.
If you use the flake system (which is technically still experimental, but everyone is already using it anyway), all your flake 'inputs' are automatically pinned in a flake.lock file that can be committed to git for reproducibility. So if you add nixpkgs as a flake input, your nix expressions will always be referring to the same exact package versions until you update the lock file.
The downside is that flake inputs refer to other flakes, not individual packages, so if you update the nixpkgs input it will upgrade all of your packages at once. For some packages such as Python, nixpkgs tracks multiple major versions so you can loosely pin to that version. You can also include nixpkgs as an input multiple times under different git tags/commits and only use that input for some of your packages to effectively pin them. You could keep using one nixpkgs but override the package's source to build it for a specific version/commit, but this setup could break in the future, because the derivation (and therefore build instructions) will keep evolving while your package's version will not. Or, if you really wanted to, you could straight up just copy the derivation from nixpkgs into your local repository and use that instead.
Nix is quite flexible so there's more options than just these, it just takes a little getting used to to find out what's possible. I don't use devenv myself, but some quick googling reveals it works just fine with flakes, so I would try that to see if it suits your needs.
It does, but its implicit (and so may not be the exact patch version you have in mind). See my other comment for how to handle if you _do actually care_ about pinning to a specific version explicitly.
If you care about the _exact version you are pinning_ (even though you will guarantee the pin between team members without needing to do this step), you can either pin nixpkgs repo to the state that had that version, source the target version directly, or for some ecosystems (eg ruby) you can just specify a version with a number and it has tooling to resolve that using "traditional" approaches.
In general though when working on a team, you dont really care about the _exact semver version_, you care about the major and handle version bumps by bumping the pin of nix packages.
The way to do it is to find the `nixpkgs` version which contains the version of the tool you care about. There's a web site[1] that makes this pretty easy, and it's of course also doable by looking at the Git history for the program's derivation.
Then you create a named input using that nixpkgs version: either add it as a channel, import it with fetchTarball in a derivation, or add it as an input in your flake, depending on what you're doing. Then you use that named nixpkgs (or other input in the flake case) for that version of the package.
Edit: One issue with depending on things like git tags or semver versions is that sometimes people re-use versions or edit tags. Using the actual git commit hashes of the package's derivation avoids this potential ambiguity. This is why we can't have nice things.
I don’t any experience with Nix - but how does it handle software which runs its own updating processes outside the package manager? Specifically thinking about software like Discord, Slack, Docker Desktop, Jetbrains Toolbox, etc.
Is the Nix-ism to just reject using such software?
Except if you go look at nixpkgs half of the technologies grandparent listed are either missing entirely or in a hilariously broken state.
The true answer is that there is just some software that is antithetical to the philosophy of nix. It’s not necessarily nix’s fault that this is the case, but their purism towards resisting opaque binary blobs going into the store reflects on the actual state of what’s available in nix.
You need some impure, nonreproducible way of managing that software. So on nix Darwin I let these opaque binary blobs manage themselves via homebrew and use nix for every other case possible
right now I have bought into the Nix koolaid a bit.
I have NixOS Linux machines and then nix-darwin on my Mac.
I use Nix to install Brew and then Brew to manage casks for things like Chrome what I'm sure updates itself. So the "flake.lock" probably isn't super accurate for the apps you described.
That's not much different than other distros, because the way auto-update usually works, is it can't use root permissions or the system package manager (in any distro), so it has to install the newer version in $HOME. Once the update is installed, the system package becomes a trampoline to that.
I tried Discord, and this one seems to download some updates on first run, but the version sticks to the one from the system (0.0.127, latest is 0.0.129). So I assume it just doesn't update, or it tries to and fails.
So Discord, and quite a lot of software like this has actually two layers of updates. There's updates of the web page (which is basically writing a bunch of JS to the home directory) which NixOS does nothing to prevent, and then there's updates of the host program (i.e. Electron) which NixOS disables.
Jetbrains Toolbox is in a sort of different category with tools like Rustup, since it's a package manager of its own. If you manage your IDEs with Toolbox, then your IDE versions are "outside Nix" and not managed by Nix. It's just packaged into its own pretend FHS environment and then doesn't know anything about it being on Nix. That said, updates of Toolbox itself will need to happen through your package manager.
As a last comment, why run Docker Desktop on Linux at all? Like I understand on Windows and Mac - docker is inherently tied to Linux so the Windows/Mac apps abstract away the fact that it's running a VM and doing a bunch of port mapping and filesystem mounting under the hood so you can pretend it's not running on a VM, but on Linux I've always just installed docker straight onto the host.
Regarding Docker Desktop on Linux - yeah definitely not strictly necessary. Sometimes it’s just convenient to have a UI instead of fumbling around trying to remember some cli incantation to check for dangling volumes or what-have-you. I think ideally I want to move to Podman anyways - but I’m using pop_os as my dev distro at the moment and am stuck on an older version which doesn’t have their native `podman compose` implementation yet
There’s more to Docker Desktop than just “oh it’s just docker underneath”
1. Unified experience across Windows, Mac, Linux
2. The security posture is much stronger by default. Many people, who would probably be considered the “target audience” for Docker Desktop, don’t bother to make docker-ce rootless, or don’t use podman, so running it in a VM is better, though admittedly often annoying.
3. Not everybody is a CLI warrior. Docker Desktop gives a decent GUI, ways to monitor and control containers visually, and even deploy kubernetes with a single click.
For a personal desktop environment, I just install them normally when there's no up to date nixified option.
For some things I've vibe-coded a nix module on github that uses a scheduled github action to check for underlying app updates and then it generates a new hash and tags a release.
I've done that for claude code and cursor, which is also an opportunity to let me manage their config files from my nix config.
I run NixOS and the number of times ive been able to install something 'normally' (not via nixpkgs/flake) is approximately zero. You cant go to a website and download a binary and just run it. Almost every program references a shared library and wont be able to find it.
Nixpkgs is very complete in my experience, and in the instances where its not, someone usually has made a flake. The only times ive had to custom-make a flake were extremely new programs, or extremely old ones. Often the newer programs had PRs waiting on nixpkgs anyway, and were only a few days away from building properly in nixos-unstable.
They said Nix, so I was thinking about macOS + nix-darwin when I wrote that.
You're right. When I tried using NixOS as my main desktop experience for a few months, I ended up with a custom derivation for various apps I used. That's probably why I made the claude code and cursor modules in the first place.
But I'm also remembering I made my own keepassxc module because keepassxc wants to be able to write to its config file, but I also want to configure it from nix, so I had to make my module use an activation-time script to merge nix config into the keepassxc config file.
I lost interest in NixOS for day to day personal computing, though vibe-coding modules like that wasn't as big of a dealbreaker as there being almost zero laptops that compete with a Macbook.
The other pain is Linux desktop environment stuff in general like dealing with interactions between a Steam game, wayland, and wayland-satellite. Though NixOS helped there since it was easy for an AI agent to investigate the issue, inspect the nix config, and make a targeted, commented patch that shows up in git.
> the number of times ive been able to install something 'normally' (not via nixpkgs/flake) is approximately zero. You cant go to a website and download a binary and just run it
Personally, I don’t see the need for this with NixOS. Setting aside the fact that Omarchy is way too opinionated (Basecamp installed by default?), NixOS is already quite composable, so you can easily build a well-formed experience out of isolated NixOS modules.
Why? Most people’s system configurations are publicly accessible on GitHub. Stuff like Omarchy only makes sense* when the system must be configured imperatively and there is a cost to trying things (accumulation of application residue). When you build your system declaratively you can just copy the bits you like from other people’s configs, or even just run their config as-is.
* IMO Omarchy doesn’t make sense anyway, far too much opinion and too little utility. It’s not a distro it’s some guy’s overly promoted pile of crufty scripts and dotfiles.
Yep disk space and learning curve are the two major downsides to Nix. The former has never been a problem for me in practice, just run garbage collection once a month. The latter was a big problem, but is now mitigated for most people by LLMs.
Yes, however the space is not „used up” in a classic sense. It’s a cache, so you can give up some of it and reclaim your space. Fresh after a full cleanup it won’t take much more than a regular distro.
Yes, but you can also reclaim your space. I've configured nix to only store two latest revisions and have a ./switch.sh file that automatically clears everything up after applying nix.
I had issues when giving boot partition only 512mb, so I'd recommend going with 1G.
The idea is so good it’s as close to platonic as it gets. The user experience of writing your own nix expressions is so bad that it makes me angry every time I try. Not only that, but at some point the beginner help (!) meta became »use flakes, don’t do what the existing tutorials tell you, yes flakes are unstable beta and there are no tutorials but use it I beg you«. No, please, let me choose my own way to learn!
I haven’t given it a shot in the LLM age yet though, and trying out NixOS in a VM is not only easy, it is practical – in the sense that when you’re happy, you can simply boot that same config/OS anywhere else by just installing that config. And I’ll never forget that one time where I completely borked my everything in the VM, did a kernel rollback with like 3 command line args and a reboot, and the OS was, well, rolled back. As I said, almost platonic.
What I can recommend is using nix-the-package-manager. Whenever I need the newest version of something, `nix-env -i <whatever>` and it’s there and works. If it doesn’t, roll back. If I need a different version, that’s on nixpkgs as well, with the same negligible amount of friction.
Obligatory Guix plug. I've found it way easier to understand, but it has teething issues that NixOS doesn't (latest for me was a few problems with DMs). And according to an acquaintance of mine, it works reasonably well with an LLM.
Flakes are de facto standard at this point. Expressions are easy once you get used to them - in fact the Nix language grows on many of us, including myself, once you internalize it.
Using AI to generate Nix config is a superpower. Because the entire system is declared in a single set of config, you can basically spell cast any system you want. I one-shotted a Linux distro with custom branding for boot, installation screen, and login screen, and VPN and dev tools installed and configured by default, at a fortune 500 tech company.
I'm not sure if I live in some kind of parallel world, because I never had any problems grokking Nix or NixOS. I started with this book[0] and haven't ever really been confused.
I haven't tried it in almost a year, but using Claude Code for setting up my nix config back then worked amazingly well. I've only dabbled in NixOS, and I'm very tempted to it for my workstation when I reinstall it in the next month.
Given how much Claude Code + Opus have improved in the last year, I'd give it a fighting chance to make a nice Nix config. I'll probably start setting up a spare laptop to get the base configs dialed in before switching over to it.
Flakes are the defacto standard and you're leaving one huge point out. Flake files come with flake lock files. You cannot get lockfiles without using flakes.
Nix in CI seems like a really excellent match. I don’t care much about the ATproto space - but Tangled has built their CI system on Nix and I find that really compelling. CI Caching is just awful with GitHub actions - so it made me disappointed that Forgejo went that route.
The problem I have with nix is that I just don't need another hobby. Keeping everything up to date in an ever changing environment like an os just looks like chore. I install my system and image it every week and keep maybe the initial and a monthly snapshot. Why would nix be better in my case? Maybe I am missing something essential but I also don't bork my system that often tbh.
nixos updates tend to be a lot less eventful than others distro, in fact the way it largely prevent system borking when updating, is spiritually freeing.
Imo it's the opposite. Since the system is defined in config files, an AI agent can look at live system state/errors vs. the config file and do all the work of figuring out the issue.
Also, using higher level modules like home manager makes things more declarative and less fiddly since someone else is maintaining the lower level.
Maybe nix is a downgrade for what you do. But I loved nix so much that I also migrated to nix on macOS (nix-darwin). No more homebrew.
For me, it's the difference between taking your medicine a bit at a time on your own schedule or taking it all at once as an unwelcome surprise. Sure, setting up file system mounts or adding udev entries is easier to do once in Ubuntu than in NixOS, but I only need to do it the one time with NixOS. Thereafter, the config serves as both documentation and backup. For a hobby self hoster like me who occasionally shoots himself in the foot and has to rebuild a system, it is ideal. I don't know if it really saves me time, but I do know it saves my sanity.
I am no nix whiz, but it's the only OS I run outside of containers. Anything I can't easily get with my nix config I shove into a container, run it as a quadlet, and call it good.
Nix isn't really much of a hobby. It does require some learning because it's different, and front-loading the work to build your config, but after that it's amazingly reliable and easily extendable. You can keep everything up to date with a single command.
The advantages:
- Declarative code describes your system. Maybe your install + imaging flow is good enough, but there are many reasons why it's technically inferior. There's no need for imaging Nix, because it's always reproducible by default. Rollbacks are rebooting to a previous config, not a timestamped blob of snowflake state.
- It replaces whatever tools and glue you have to build your system. You don't need to worry about bootstrapping tools, or config management tools' version compatibility, or bespoke ordering of imperative steps to build the system. All the management tools are built into the system. Everything "just works" automatically.
- If you manage multiple machines the benefits are compounding.
- There are other interesting bits that are covered in the article, that you get for free just due to the nature of nix. It's good for building, and has no friction to experimenting with specific tools or environments, without polluting your system.
It's a commitment to get past the initial learning and config build, but afterwards it significantly lessens the "hobby" aspects of computer management. There are just entire classes of problems that don't exist for Nix. Either your config works, or it doesn't, and the rollback guarantee is explicit and built-in.
no thank you, there are things I do not want Claude to have rwx on. like my entire f*cking system. I run llms in a docker container with just the folder I'm working in.
If you grant access to the Nix daemon socket but not writing outside the current directory, that's an effective sandbox. It allows evaluating derivations but not actually installing them.
Claude Code has to be actively steered, because while it knows some nixpkgs it surely doesn’t know it enough. E.g. it was absolutely incapable of fixing lldap settings after system upgrade from 25.05 to 25.11. It just prodded around blindly, producing meaningless configs instead learning how the module works.
NixOS docs work for me, but I tend to just go for the nixpkgs source instead. Manuals document options but not how those are actually plumbed through, nor what remains behind the scenes like all systemd unit settings). Claude can do this too, but it goes quite weird roundabout ways with a lot of weird `find /nix/store` and `nix eval`s to get to it, slow and token-hungry (and not always accurate).
This said, Claude is very helpful at checking logs and providing a picture of what’s going on - saves ton of time this way. Plus it can speed up iterating on changes after it’s fed enough knowledge (but don’t expect it to do things right, that’s still on you). It has breadth of it, but not the depth, and that shows at almost any non-trivial task.
You don't have Claude Code git clone nixpkgs and home-manager for local reference?
I feel you on the nix store + nix eval death loop, though it gleans real info. If I weren't on the Claude Max plan I'd probably feel more of the pain. And context is now 1MM tokens which means you're not running out just as it's starting to piece things together, heh.
I do, but it somehow tends to forget how to do things right now and then - despite having notes in memories system - and starts to do them in its own weird ways.
I’m going to experiment with skills next, or maybe make it build a few helper scripts for itself to quickly get some module source from nixpkgs matching flake.lock without having to think of it all. I’m positive about Claude for nix management, merely saying it’s not something that “just works” for now and reading nix code is still on the human part of the tandem.
This said, to be fair - when it gets the approach right, it excels. I was setting up Ente for photos backup and sharing, and it produced a nice overlay with custom patches for my needs from just “figure out why /shared-albums/ redirects wrong and fix”. Found the module, the package, pulled source, analyzed it, proposed a patch (settings weren’t enough), did it - I only had to test, and only because I haven’t provided it with a browser. Felt amazing.
I would have never become a power user of Linux were I used LLM to do the installation of Gentoo once upon a time. :( So do you guys not know much about the distro you are using, or how does this work? I honestly thought your comment was sarcasm, but apparently it is not.
The things to know about the OS are high level things. The rest of its idiosyncrasies you learn just in time through daily exposure like anything else.
Nothing about this changes with Nix nor AI agents.
You can read documentation on an as-needed basis or to your heart's content.
The point is that the majority of the day to day changes I make to my desktop environment aren't so critical that I need to do more than read an AI agent's proposed changes to my config and accept them when they look reasonable.
And I don't think looking up the exact config options to NixOS' networking system does anything to increase my knowledge of the OS. It's just a triviality.
Coming from Ansible with hand-written config templates this was honestly a friction point for me - I felt like NixOS is trying to actively hide what it's actually going to configure. It's gotten better now that I read some nixpkg service sources but from time to time I still feel the urge to just directly manage my systemd units, sshd configs and whatnot. Like, sure it simplifies the setup but at the same time also puts another abstraction between me and the software I'm using.
I agree with the many levels of abstraction, but at the same time, directly managing systemd units is also so much easier with Nix then any other distro I've tried.
You hate that I couldn't remember whether nix has array delimiters on the spot?
Jeez, tough crowd.
Though it also kinda represents this pride over triviality that some people latch on to in the AI world which is odd since it's also only a mistake a human would make. Had I run my hand-written comment through a proofreading clanker, I would have spared you the negative emotional reaction.
In the pre-AI world, you would have probably not been so harsh since it's understandable that someone make that mistake with such an idiosyncratic language like nix that almost nobody writes full-time. Yet in the AI world, you demand more from humans.
Well, there's layers. When I started using nixOS I read through the guide and wiki but I also used LLM assistance to help create a stable starting point. Then over time I've incrementally added new things to my configuration through a mix of LLM assistance and reading online material.
I think the initial migration towards nixOS is the hardest point, since it requires learning a bunch of new things all at once in order to get the system into a usable state that matches your expectations and preferences. The key benefit of using an LLM is that it makes it really easy to get your system into a useful initial state, and then you can safely learn and experiment incrementally with a mix of tools.
When I started off I didn't understand everything, but at this point I feel I have a very good understanding of everything in my configuration file.
I'm glad that I'm not the only one. I don't want to move from "Microsoft knows best" to "Claude knows best but hey, at least you review the output by looking up the not so good documentation".
Kind of an interesting thing here where if this is how you view it, it kind shows in itself why you don't actually need it.
Like what is ultimately the difference here for you vs a non-nix user who, as author says, is just dealing with some big ambiguous pile of state? It kind of takes away any upside to using nix, and probably just creates more friction for your AI than just running ubuntu/apt stuff.
The idea is you can keep configuration "in your head" such that you can reason and iterate and fully know what your system is like at any moment. If you actually don't care about that, you aren't getting anything out of it!
The upside of Nix config is that it's the state of my system in a declarative config file.
I have these packages installed and these firewall settings and these users with these permissions and this folder served over Samba and these hotkeys that do these things and these Obsidian vaults synced over SyncThing and these devices in my SyncThing network and Neovim installed with these plugins and ...
This is difference between me and a non-nix user, not whether we can rattle off the exact state of our live system from memory.
The non-nix user has to query live system state, if such query tools even exist for their question, and I get to read a config file. And I get to maintain my system config in git, and I get to deploy my config on all of my machines.
But if you are not reading or comprehending the config file, why does it make any difference? You ask AI to purge ffmpeg from your system, it will probably know more about doing that with apt than with nix, right? And if the input on your end is "remove ffmpeg from my system" or whatever either way, what's the need for nix? You will be much happier just editing /etc files and such in the standard way, rather than hoping your AI knows the (sometimes sadly inconsistent) way nixos handles the particular module/service/whatever you are dealing with.
For me, the difference is that there is no way in hell that I want to give an AI assistant full access to configure my system live. With a declarative config, the only access it needs is to an isolated git repo.
But if the declaritive file is not read/understood, what is the difference? At some point, you're gonna run sudo nixos-rebuild, and that is the whole system on the line.
This whole thing has been about explicitly using LLM instead of learning nix. So sure, definitely agree with about the niceness of using nix in general if that is all you are saying, but also not sure what you are trying to argue for anymore.
On the contrary, the model doesn't actually add any lock-in. When GP wants to switch to free model the config files are still there. There's no lock-in, as I see it.
It is not about lock-in, it is about free software being usable without resorting to non-free software. One of the free models is usable for this would be a better shift and that might be workable but I'm not sure about how well they'd work.
It doesn't help that there are two NixOS wikis. nixos.wiki and wiki.nixos.org.
wiki.nixos.org claims that nixos.wiki is outdated and unofficial. But both appear to receive updates, and which one wins the SEO game is a coinflip whenever i google a nixos question.
You know, I used to agree, but what I realized, is I am a software engineer, and I'm used to working in large projects with source-code as the only documentation.
And that's what's great about NixOS, you just clone nixpkgs and treat it like any other underdocumented software you might work on.
> I'm used to working in large projects with source-code as the only documentation.
As a software engineer I have an opposing attitude towards this. I work on projects with terrible documentation because somebody pays me to do so or there is a significant potential that I can unlock.
There are significant alternatives to NixOS like bootable containers and OSTree which are more useful and better documented. If Nix project really cares about being competitive and adopt users, they have to document their stuff. They are already going against the grain and ain't nobody has time to put up with their weird language and their subpar documentation.
> I work on projects with terrible documentation because somebody pays me to do so or there is a significant potential that I can unlock.
I mean, I'd argue there is significant potential, but really, for me it's just easy because I've been doing it for 20 years, and documentation is always fundamentally worse than code in some important ways.
> If Nix project really cares about being competitive and adopt users, they have to document their stuff.
This is one of the good/bad things about OSS.. most users don't provide positive value to the project. So do they really want to adopt users? Shrugs but the project is certainly competitive.
I love Nixos. Having a deterministic system is such a great way to know what your system is capable of. The only thing that bothers me is that when I rebuild my system after updating the lock file, if a package is broken the whole upgrade become impossible.
I switched over to Nix about a year ago. I was a Windows user before that for 30 years and tried Linux a couple of times, but it never stuck. Now I know I will never touch Windows again. With NixOS I've finally found a system that actually works for me — and the full OS configuration is in a repo. My god, I love it so much.
Sometimes I even prefer nix-shells over uv for quick one-off Python scripts.
I cannot sufficiently convey how absolutely barbaric everything else feels in comparison. Not having Nix would be like having to work on code without Git — absolutely unacceptable.
And it really isn't that much work — you do it once. The next time you set up a new system, without Nix, you'll have to do the full configuration all over again.
Have you heard of any good projects for running isolated containers in NixOS that are cheaply derived from your own NixOS config? Because that is what I want. I want a computer where I can basically install every non stock app in its own little world, where it thinks "huh, that is interesting, I seem to be the only app installed on this system".
Basically, I want to be able to run completely unverified code off of the internet on my local machine, and know that the worst thing it can possibly due is trash its own container.
I feel like NixOS, is one path toward getting to that future.
depends whether you consider rootless Docker "cheap". I tried running ZeroClaw in a Nix-derived Docker (spoiler - it was a bad idea to use ZeroClaw at all since the harness is very buggy) and there is still a potential for container escape zero-days, but that's the best I've found. also, Nix's own containerization is not as hermetic as Docker; they warn about that in docs
If containers are safe enough for ur use case then just use nixos containers they just a few more lines to setup in a regular nixos config
If it isn't enough
there's microvm.nix which is pretty much the same in difficulty /complexity, but runs inside a very slim and lightweight VM with stronger isolation than a container
Can you do those ad-hoc though? I was looking into this too. I feel like it requires a system config change, apply, and then you need to do container start + machinectl login to actually get a shell.
That's definitely what I want... most of the time.
* declarative mode, where your guest config is defined within your host config, or
* imperative mode, where your guest NixOS config is defined in a separate file. You can choose to reuse config between host and guest config files, of course.
That's hard given most apps have dependencies and often share them.
It will always look like curl is available or bash or something
What's wrong with another user account for such isolation?
They can be isolated to namespaces and cgroups. Docker and Nix are just wrappers around a lot of OS functionality with their own semantics attempting to describe how their abstraction works.
Every OS already ships with tools for control users access to memory, disk, cpu and network.
Nix is just another chef, ansible, cfengine, apt, pacman
Building ones own distro isn't hard anymore. If you want ultimate control have a bot read and build the LFS documentation to your needs.
Nothing more powerful than the raw git log and source. Nix and everything else are layers of indirection we don't need
> I want a computer where I can basically install every non stock app in its own little world, where it thinks "huh, that is interesting, I seem to be the only app installed on this system".
NixOS containers are the most convenient way to do this, but those will map the entire global nix store into your container. So while only one app would be in your PATH, all other programs are still accessible in principle. From a threat-modelling perspective, this isn't usually a deal-breaker though.
There's also dockerTools, which lets you build bespoke docker/podman images from a set of nix packages. Those will have a fully self-contained and minimal set of files, at the expense of copying those files into the container image instead of just mapping them as a volume.
I almost switched back to Fedora Bazzite to get a working gamescope, but realized I can get HDR in sway and its actually more stable than Valve's mess of gamescope. Even though I have to use "--unsupported-gpu" flag, my Nvidia card works wonders in Sway, where as gamescope gives me a blinking cursor and segfaults.
Not the greatest fan of python, but when I've got to run a python script, I do `nix-shell -p 'python3.withPackages (ps: [ps.requests])' --command 'python3 your-script.py'` Note that there is one argument to -p and one argument to --command -- both are quoted. The argument to -p is a nix expression that will provide a python3 command, referring to a python3 with the requests package. The argument to --command is a bash script that will run python3 with the argument "your-script.py" i.e. it will run your-script.py with the python3 that has the requests package.
I think there's ways you can autoderive a python3 with specific packages from python dependency files, but I can't help you there. I do find AI to be reasonably helpful for answering questions like this: it just might sometimes require a bit of help that you want to understand the answer rather than receive a perfect packaged shell.nix file.
Do you have to figure this out? Sure, it's nice and "pure" if everything is configured through Nix but there is something to be said about being pragmatic. Personally, I just enabled nix-ld[0] and use uv to install and handle my Python versions and package dependencies. Much, much easier.
Easier and largely compatible with the rest of the world. Solving problems with "If we all switched to NixOS..." is a non-starter in most organizations.
My rule of thumb: keep a strict separation between my projects (which change constantly) and my operating system (which I set up once and periodically update). Any hard nix dependency inside the project is a failure of abstraction IMO. Collaborating with people on other operating systems isn't optional!
In practice this means using language-specific package management (uv, cargo, etc) and ignoring the nix way.
After having done the switch to nixOS, I can confidently say that managing a system any other way (like with apt/brew + 20 handwritten bash scripts) really is neanderthal technology and nix is superior in every single way.
It's also great for the AI era, copilot is really good with that stuff.
Yeah, I've been using Unixey stuff for almost twenty years now (most of it Linux, and fell for the siren song of macOS for about four of them).
I liked Arch and Ubuntu and Mint and OpenSUSE well enough when I used them first, but once I actually tried NixOS it felt so obviously correct that it started to bother me that it's not the default for everything.
Being able to temporarily install things with nix-shell is game changing, and being able to trivially see what's actually installed on my computer by quickly looking at my configuration.nix is so nice. "Uninstalling" things boils down to "remove from configuration.nix and rebuild".
The automatic snapshots upon each build allows me to be a lot "braver" when playing with configurations than I was with Arch. I was always afraid to mess with video card or wifi drivers, because if I screwed something up and if I didn't know how to get back to where I was, I might be stuck reinstalling to get back to a happy state. This didn't happen that often but often enough to have made me a bit weary about futzing with boot parameters or kernel modules. Because of the automatic snapshots with NixOS, it's much easier (and more fun) to poke with the lower level stuff, because if I do break something in a way that I don't know how to fix, the worst case scenario is that I reboot and choose an older generation.
This is a bigger deal than it sounds. For example, with my current laptop, there was a weird quirk with my USB devices having to "wake up" after not being used for more than thirty seconds, meaning that I might start typing and the first three or four words wouldn't go through. After some digging, I found out that the solution is to add "usbcore.autosuspend=-1" to the kernel params. I did that and it worked.
If I had still been running Arch or Ubuntu, I probably would have just learned to put up with it, because I would have been afraid to edit kernel parameters because of the risk of breaking things in a way that I don't know how to fix.
I love NixOS. I have no desire to leave, or at least I have no desire to abandon the model. I've considered changing to GNU Guix System since I like Lisp more than I like the Nix language, but those FSF-approved distros can be a real headache for people who actually have to use their computers.
> those FSF-approved distros can be a real headache for people who actually have to use their computers.
This is now a tired discussion; the use of nonguix (https://gitlab.com/nonguix/nonguix) is well documented, there is no practical difference after initial setup between using a regular distro and one of “those FSF-approved distros”
I am sure you don't do it on purpose, but could you stop spreading FUD? (specially given you acknowledge “ I've considered changing to GNU Guix System”, so you're here relaying 3rd party opinions, not your own)
My experience using NixOS on desktop is that it's 95% wonderful, 5% very painful.
If you run into friction with NixOS, you may need to have a wider/deeper understanding of what you're trying to do, compared to the more typical Linux OSs which can be beaten into shape.
Such a pity that the article didnt touch on running rust nightly or the sometimes statefull nature of user configs of some programs. The 5% painful part was just around the corner.
> like with apt/brew + 20 handwritten bash scripts
I just use apt, been doing it for 20 years, it works great. I've never in my time, heard of or knew anyone who wrote 20 (or any) bash script wrappers around apt. The one year I was painfully forced to use a Mac for work, brew worked similarly to apt, just used it, no need to wrap it with shell scripts.
Comparing highly functional and capable systems like apt and brew to neanderthal technology sounds like hype.
> It's also great for the AI era
That also sounds like more hype, similar to the pro-nix other comments so far which tout AI and similar to the article which I did read, also sounds like hype.
You know, I'm not going to say I'm enamored with the language, but I think the Stockholm Syndrome has kicked in because I really don't hate the language so much anymore.
I mean, I'm only ever using it for configurations, and I think I'd still prefer writing Nix than YAML. I probably wouldn't like writing a full "program" with Nix, but I don't think anyone does that?
Sounds like every programming language on the planet. Just skip the "i'm unfamiliar with it, so i hate it" phase, and everything will be fine. People spend more time repeating that simple POV, using thousands of varying words, than is healthy. Just shut up, and do the work. And if you're not going to put in the work, just shut up, and let everyone else get to work.
I mean I don't know that I agree with that completely. Languages can still be actively awful even if you do learn them.
I have written a lot of PHP. In order to learn it I bought several books, I've done a dozen or so projects with it at various jobs, I've written both trivial and non-trivial things, and I have come to the conclusion that PHP is an actively terrible language [1]. It's inconsistent and hard to write in any kind of maintainable way with an ugly syntax and generally-crappy performance for any kind of logic beyond CRUD.
[1] At least version 5, which is the last version I've used. I've heard 7 is better but I'll never know because I swore an oath in blood that I would not do PHP again for less than a million dollars a year.
There are so many people complaining about the Nix language while offering zero constructive criticism. I was a little skeptical about them using a custom language at first. But then as I used it more it grew on me and I understand why it is the way it is.
People just seem to want to complain because it doesn't look like any of their favorite languages and they aren't familiar with functional languages. At this point, I can't imagine using any other language in place of Nix. The code would have so much noise and be much harder to read.
nix & nixos are by far the worst way to manage system configuration, except for any other way that's been tried. imagine if there was something with declarative system configuration _not_ written in an insane undebuggable recursive nightmare of a language/stdlib? oh well, I'll keep using it, because what other options are there?
I mean it's pretty wild to take s-expressions and not call them extremely terrible to read. The nix language sucks really badly, but I gladly take it over writing S-expressions.
It reads almost the exact same as any functional C-style language. Not to mention that specifically for Guix, you're going to be writing the (name value) form for 99% of it.
That link isn't working for me (something about AI detection), but as a point of accuracy, those aren't derivations, they're simple source files. Derivations are generated out of them.
As for the closing braces, would it be better if you had a newline between each?
> This is not a language that is optimizing for being written by humans
I've taken a look at the code - having never written a line of Guix in my life - and it seems very readable to me. It's cleanly structured and makes good use of indentation.
The string "))))))))))", which you claim you're seeing 'regularly', appears exactly twice in 4,580 lines of code. It's the longest parens string that appears in the file. Seems to me like you deliberately searched for the most atypical example, that you're now misrepresenting as 'regular', when it is highly atypical.
And honestly, what would that look like in some 'more normal' language?
);
}
);
];
};
)()();
Better?
I will never understand this fear response some people have to seeing `(fn a b)` instead of `fn(a, b)`.
I indeed searched for the longest chain. Something that happens in 4.5k lines twice is hardly rare. And even if you take away a brace it occurs even more frequently.
And yes your example is better, but still terrible. The point is not the formatting. The point is that there is that 10 deep nested code is just not easy to understand. I would also say a line of c/python that does 10 nested function calls as unreadable. But they do not encourage this, whereas with lisp its modus operandi to write such incantation.
> Something that happens in 4.5k lines twice is hardly rare.
Provided you don't consider the context, sure. One of them is software with buggy tests, the other is one that provides a custom test suite that basically has to be reimplemented in the package definition. How often do you think either of those things happen?
Looking at a lot of nix package expression: Quite a bit. Besides, just taking a way a single brace gives 7 hits. Still a ridiculous level of nesting. So I don't go with your reasoning that these are some kind of super special cases. If something happens so often in 4500 lines of code you cease the right to claim it is special.
It happens 1/2290 (0.04%) of the time. You are significantly more likely to guess a stranger's birthday totally at random (0.27%) twice in a row (0.07%). If you don't consider that exceedingly rare, then you and I need to hit up Vegas immediately.
You are projecting a programming style onto Lisps that's quite alien to them. Lisps tend towards small, discrete functions that are composed together. It is the ordinary languages that tend towards deep branching and nesting; Lisps generally favour recursion and function composition instead.
There are 101 `(package` definitions and 58 out of them have more than 6 nest level, which I would consider more than excessive. That's an incidence of over 50%.
Beside I don't think I'm alien to the functional way of writing things. I write mostly Haskell professionally. But Haskell doesn't casually suffer from making insane expression nesting the default.
Lisp programmers have used editors that count the parens for them for decades. Many use something like paredit that simply automatically adds the final paren. I've written significant amounts of Lisp and you simply don't see the parens. You might as well complain about French having all those accents. It's just a different language. Learn it and you'll see why.
I can write lisp. That a lot of lisp programmers require special editors to handle it should tell you enough. It's not that the language is unworkable. You can definitely write stuff in it. The point is that it is quite far from something that should be written by people, in my opinion.
Are you really going to argue that a good programming language is one where you can construct it character by character, by hand? Emacs has existed for decades and it runs basically anywhere. Nobody is programming in ed (well, apart from Dave Beazley[0]). With LLMs the world is finally catching up to the fact that programming isn't typing characters one by one. Lisp programmers have been at this for decades.
I consider it essential for a programming language for people that it is easy to understand things by looking at things locally. Requiring/strongly encouraging extremely deep nesting is not conducive to that.
This is not some weird opinion I have. There is a reason "flat is better than nested" is part of the pretty popular zen of Python.
> you're going to be writing the (name value) form for 99% of it.
That's exactly the part that is wrong with Guix, and Scheme in general. Scheme has associated lists, they are written as '((name . value) ...), but since that's too ugly everybody makes macro wrappers around them to get them down to just (name value). But that means you aren't dealing with an obvious data type anymore, but with whatever the macro produces and if you want to manipulate that you need special tools yet again. And then you have record-type and named arguments which are different things yet again, but all serve the same name->value function as an associated list. Names themselves are sometimes symbols, sometimes keywords, and sometimes actual values. Same with lambda, sometimes you need to supply a function, other times there is a macro that allows you to supply a block of code.
It's like the opposite of the Zen of Python, there are always three different ways to do a thing and none of them as any real advantage over the other, they are just different for no good reason and intermixed in the same code base.
+1, Guix is quite good with some tricks up it's sleeve compared to Nix.
I am not a fan of S-expressions but using scheme is more reasonable than nix+bash to me.
On the negative side, guix can be slow. It is also not a very pragmatic os. NixOS does non-free firmware and drivers without issue. You need to jump through some hoops for this with Guix. This is not an issue if you plan to run guix in a VM though.
NixOS kind of extends the idea of reproducible builds. Any snapshot could be a guarantee that things just work. This can also be extended onto the user base - if one user has solved a problem, it should be solved for all of them. So we can jump from guarantee to guarantee here.
My only gripe with NixOS is Nix. I think that this is also the biggest drawback of NixOS. I don't have an alternative; but perhaps it may be better to allow any format to be used, rather than force nix onto everyone.
Another issue is that, for a reason I don't quite understand, a few years ago NixOS' quality appears to have gone down, e. g. nobody cares about documentation anymore. This is probably not a huge obstacle per se, but I did not feel I should invest that much into nix (which I dislike) when the documentation leaves a lot to be desired. Ironically this also means that the whole idea behind NixOS, falls flat, if the documentation is poor. They really should make the same guarantees for their documentation, just as they do for the software ecosystem too.
Nobody cares about documentation anymore though - AI has won. Just try finding high quality documentation via google search; it is slop world now.
I tried NixOS and failed miserably. I've pointed at to the Fedora Atomic distros, which are also immutable, and apparently incomparably easier to setup.
I'm tempted to give it a shot, with the extra bonus that I've never dabbed with a fedora-based distro.
I tried fedora silverblue for a while, but the way it works is that it builds a new root fs image whenever you change the installed packages, this makes system package changes take comparatively long vs a traditional os. They suggest installing most apps via flatpak, which is okay as long as you can deal with flatpak idiosyncrasies.
I also tried fedora coreos for a vm + container host, but found the recommended method to configure the system with ignition files and one shot systemd units to be too involved for making a one off system, and it’s probably better for a cloud deployment with many identical nodes.
I’ve been driving Bluefin DX for a year or two. On the plus side, it works absolutely flawlessly. This is the longest I’ve ever run a Linux distro without a Nvidia driver update causing the whole thing to explode. It truly is the year of Linux on the desktop.
But I can’t say I recommend it for dev work. It wants you to do everything inside devcontainers, which I like in theory but in practice come with so many annoyances. It wants you to install Flatpaks but Flathub is pretty sparse. I ended up downloading raw Linux binaries into my home directory (which actually works surprisingly well. Maybe this is the future, hah)
I think next time I’ll just go with vanilla Fedora.
> There is also community-maintained support for FreeBSD, though I have not used it personally
I have tried to use the nix package manager on FreeBSD recently. I tried doing some basic things without success. Seems quite broken and unusable, which is a pity because nix on macOS seems decent. FreeBSD is much closer to Linux so there is no technical reason why nix can't be a success on FreeBSD.
nix on FreeBSD just needs more contributors to fix bugs and make popular packages work ! I wonder if it will ever happen. FreeBSD is niche and nix is somewhat niche (still). It's a double niche problem !
One thing I love about NixOS is how easy it is to run packages from different sources. For example, I needed an old package that's been removed from nixpkgs several years ago. To run it I just had to add an old release of nixpkgs as input to my flake.nix and add the package from this input. It pulls all its dependencies from that old release and there's zero conflict with the other packages.
For a single machine? Yeah, NixOS' cost surely outweighs the benefits if you're not familiar with Nix.
Using Nix for per-project development dependencies is quite good. It's nice to be able to return to a project & not have to fuss over which tools/libraries need to be installed.
The author almost touches on the one more topic that I adore about Nix, but ends up just so missing it: NixOS is absolutely incredible for its ability to be configured through AI tooling. And I don't mean that it's better than other operating systems, I mean that it's the only game in town.
I've been using Nix, both the package manager and the operating system, for years by now. I agree with all of the author's points, it really does deliver, the declarative nature is superb, and there's this constant sense of "hey my stuff is not breaking by itself" when working on it. And it's that declarative, rollback-able, file-based foundation, that makes it the perfect operating system for telling a coding agent to go to town on.
Would I trust Claude to switch my audio stack from Pulseaudio to Pipewire on Ubuntu? Would I trust Codex to install Hyprland on Fedora so I can test out the session? No, in fact I would not trust any agent to do any of those things on any other operating system. But I would trust even goddamn Grok to do that on NixOS, because I can 1) audit the changes before anything is done, and 2) rollback, rollforward, roll-whatever-the-way-I-want-even-on-the-floor-if-I-want-to because of the years of built up confidence proving that IT JUST WORKS.
I concede that this is turning into an unhinged loveletter to Nix, but really, it's the only operating system that lets one operate with this level of confidence. And I know most people don't care about that, since most people don't usually bother to tweak their OSes or switch out window managers, but as someone that does that, I'm never going back to mutable distros. This security is my table-stakes now, and the others aren't willing to pay up.
So for the developers out there on the lookout for their "Year of the Linux Desktop 2026" -distribution, if you're already using AI assistants, give NixOS a try. Maybe start with this in an empty Git repository: "Hey Claude, I wanna try NixOS. Make me a Flake-based starter config using Gnome that I can demo in a virtual machine. If nix isn't yet installed, install it via determinate-systems installer. Include a "vm" target in the flake for building the image, and a small bash script that builds and launches the VM using whatever virtualization is available on my platform."
As a NixOS user for 3 years, and a Claude user for 1+ year, I agree with you that it's an ideal fit. I've been very happy with, for example, how Claude can configure GNOME via dconf settings: tweaking those settings declaratively requires cross-domain knowledge and knowing where to dig. But Claude just knows.
But trying to set up an environment for one of those perpetually running AIs, and asking it to refactor its own configuration according to some of the high-level abstractions like dendritic flake-parts, and so on, it's just clueless and will improvise without success.
What makes Nix hard for humans also makes Nix hard for AIs: Untyped lambdas that get resolved in some implied out-of-file context means you have to know if you're looking at a NixOS module, a home-manager module, a nix-darwin module, a flake-parts module, and so on. And those modules may make assumptions about what's imported in the parent scope.
So I feel like you need to supply a rather extensive context for your project that details how you want things structured, because the ecosystem is quite fragmented, people don't fully agree on what good patterns are, and so the AI can't know what the good patterns are.
Just to be absolutely clear: I think that supplying an extensive context is absolutely worth it, and I'm having great joy and success building better Nix-based project templates, Nix-based deployment templates, etc. The amount of stable, well-made projects made by other Nix users is just amazing.
I just migrated my personal website to nixos and can second all of this. There's a learning curve, but the time to provision a new server once it's all working is hilariously short.
I use debian + ansible and it requires discipline (you have to make sure you never do manual steps basically) but my entire ansible playbook makes server creation a 3 min process.
I'm sure Nix is better, I just haven't needed it yet.
> it requires discipline (you have to make sure you never do manual steps basically)
Since Nix requires a declarative configuration, you need less discipline, but more up-front specification. For example, making truly idempotent Ansible scripts requires a lot of effort and some strong assumptions about your starting state and what processes piped changes into your state, and what your state changes really mean. Also, running your playbook with newer version of the same software may lead to a different result. For example, migrating from bullseye to bookworm with a cargo-deb that contained dependencies: It turned out that there were implied dependencies taken for granted in bullseye that were removed in bookworm. With Nix this will lead to a build error rather than a deployment error or a runtime error (in most cases).
Nix requires fewer assumptions.
> my entire ansible playbook makes server creation a 3 min process
I'm a big fan of Ansible, and everything has its use.
I like to categorize deployment tools as either "bottom-up" or "top-down" depending on what assumptions you make about the world: Ansible fills the slot where you have no control of how the server got there, but you gotta make use of what you have, and start from scratch. Terraform is the canonical bottom-down tool: You assume you have perfect control of what gets provisioned, and that it won't go away or go out-of-sync without active maintenance.
In this top-down/bottom-up topology, Nix can fill the whole spectrum; most people assume Nix/NixOS is available to them, at which point their automation starts. Others deploy NixOS via various automated processes that can be integrated with both top-down or bottom-up solutions, e.g. distribute via network boot, VM image repository, or via "hostile takeover" (deploy on existing Linux machines via SSH, like Ansible, or using Ansible).
I've been trying to get nixd LSP to work with Claude Code but I got stuck as they gatekeep it behind their "plugin" system and you can't just configure it in settings.json to point to a nix store path like mcps :(
oh yeah AI realy does not seem to actually know which packages exist. I once asked AI to create a devenv for some Julia development and it pulled some packages out of its ass that just plain did not exist.
I knew my flake setup could be better but never bothered. Then one day earlier this year I threw Claude at it. Not only did it improve everything, it fixed a small bug that had been bothering me.
My confidence in doing this came from exactly what you said: If it blows everything up I can just rollback.
Sometimes it's nice to throw an LLM at some Nix stuff but I find that unless you're comfortable with the Nix language itself and have spent a tiny amount of time writing a derivation you might introduce quite a few footguns along the way. That said these days when I need a development flake I just point a LLM at the repo and it mostly figures out what's needed. It's just that Nix lends itself pretty well (sadly) to poking around in the dark (yes, I know about the REPL).
I waited for AI to get better before adopting Nix as it seemed to be rather arcane, a bit like Arch Linux, and I was worried I wouldn’t have the time for it. In preparation I shifted my development environments entirely to docker scripts where I can copy and paste working snippets from the internet.
Nix and AI is a match made in heaven and I think we’re going to see a lot of good software that’s amenable for us by AI that is both cheaper to build and easier to use.
I literally just fixed a couple of nagging config issues that I couldn't be bothered to find in my (admittedly complex) set of NixOS and HM config files by asking Claude to find and fix them.
I had Claude do the grunt work of shifting parts of my config to a new structure I started but didn't have time to fully implement.
Based on examples I provided, I had Claude use specialisations to set up a couple of different WM and DE test environments.
And the thing is that, now that I have everything set up the way I want, I don't really have to DO anything to keep the system running, other than occasionally update (I'm on unstable, so I do that manually).
Could I turn Claude loose on my .config directory, give it access to apt or dnf (etc.), and let it set up a non-NixOS environment for me? Probably, and it would probably work reasonably well, but I wouldn't trust it the way I trust NixOS.
NixOS's greatest weakness historically has been bad/missing docs, especially docs of the "I have X how do I do Y?" nature. This led to a situation where thousands of users asked those questions on forums and received answers covering a spectrum of possible paths forward. The other path was to spend a bunch of time trolling through module sources to find the options you need and understand what they were going to do and how they would interact with each other.
Anyway, it turns out this is a perfect setup for an AI bot to step in: it's got all those forum posts to learn from and it's endlessly patient when it comes to just figuring everything out from the source code.
I'm not sure how I would've configured my dotfiles without AI. The nix syntax is a bit daunting, but the rollback feature makes me feel confident in modifying my system agentically. The main setbacks are the non-fhs filesystem, which both applications and agents generally expect.
I put a Claude Code token on all my machines, local and cloud. Machines now practically fix themselves. Especially with NixOS, as soon as the basic install runs, it gets the Nix claude-code package. It's all downhill after that. OpenClaw hit a few weeks ago, so I took an ancient PC lying around, put NixOS on it, added Claude Code, and then Claude installed OpenClaw. Claude, tell me about the security posture of OpenClaw. "Would you like me to turn on the exec permissions feature and disable dangerous commands?" Claude does that and then turns around and tests that they are really turned off. My Telegram bot gets confused: "I'm sorry, I don't have a shell/exec to run that command. How did I run anything a few minutes ago?"
It's unreal. I've packaged so many super daunting packages that would take myself weeks to package (and some that I've tried and failed to package). I have 6 years of daily driving nixos...So I'm not exactly new to the distro.
Even messing with stdenv or language builders is trivialized. Any software that I want, I can get within a few hours of claude/codex just spinning unsupervised.
It's so nice! Underrated for sure.
And if you watch what it's actually doing during a session like that, it's basically exactly what a human would do: run the build, find the error, google the error, consider 2-3 possible fixes, pick one and apply it, repeat. Afterward, look at the various patches and fixups and decide if a refactor is necessary.
This feels like a very high-tech solution to a problem that doesn't really exist. Why involve an LLM to install Hyprland when "sudo dnf install hyprland" works fine? I feel like you're mistaking Nix being 'AI-ready' as a feature, when in reality, you're just forced to use an LLM because Nix is too annoying to manage manually.
I was looking at hyperland in Fedora this week. I wanted to try out the latest release (released two weeks ago give or take). It wasn't available yet (maybe it isn't still). That's ok, but I checked what would I have needed to do to build it myself, and I didn't want to mess with a bunch of dev dependencies I didn't really care about and that I would have forgotten, so I ended up not trying it
The key point is that all such tweaks to the system is managed in a one configuration file. While installing Hyprland may be a one-liner, configuring it and all other services from a single entry point is incredibly liberating.
Reverting changes are guaranteed to not leave behind any cruft, and you don't have to remember what you changed to make X or Y work: it's all visible in the (usually version controlled) system configuration.
Got a new computer? Just copy the configuration and enjoy a bit-identical system in seconds. Have an LLM tweak it and see the changes in the form of git diffs.
Sure, you can do the same with Silverblue and writing Ansible for everything, but it's not free of side effects (unlike Nix).
While nix might be free of side effects, activating a nixos configuration isn't as free as you imply. As an example, nixos keeps state around regarding user id/username mappings, to avoid giving the same user id to different users across time. So a fresh install of nixos might leave services unable to read their data files, because the file might be owned by a different user id. And if you activate and enable incus, for instance, it will probably create a bridge device: the device will remain in place after you remove incus, which will have implications for how your network/firewall works that your configuration will depend on but will not enforce or be able to reproduce.
Not an argument against using NixOS - I think the bridge device issue could reasonably be regarded as a bug rather than a fundamental design issue, and the user id/username mapping is a totally reasonable design decision which can be taken into account by forcing the user id numbers anyway.
> As an example, nixos keeps state around regarding user id/username mappings, to avoid giving the same user id to different users across time. So a fresh install of nixos might leave services unable to read their data files, because the file might be owned by a different user id.
> And if you activate and enable incus, for instance, it will probably create a bridge device: the device will remain in place after you remove incus, which will have implications for how your network/firewall works that your configuration will depend on but will not enforce or be able to reproduce.
To be clear, I don't use neither. But you can get NixOS to be almost completely stateless (if this is something you care) with a few changes. The power is there, but it is disabled by default because it is not the pragmatic choice in most cases.
How would "bit-identical" or "free of side effects" make an actual difference in practice?
Rollback is already very easy with filesystem snapshots.
Configs are already tracked by etckeeper.
New laptop: either copy the whole drive or the package list and dotfiles. Also, how often do you have to get new laptops for this to be relevant ?
The problem that exists is that you cannot just willy nilly try out entirely different desktop envs/window managers/audio frameworks on an existing install of any other distro and be certain everything will work exactly as it was when you remove it. Especially as an only moderately knowledgeable user that won't know every single piece of config that needs to be changed back. Unless you're trying everything new out on a fresh install then there's a big risk.
NixOS gives you that just by opting in to using it, and while AI also speeds up config changes and translating your existing knowledge to a new tool you're trialing in other distros as well it really shines with NixOS where you don't even have to care what it messes up while you're trying something new. You just revert and you know that nothing that was done to configure that new thing - which likely would have broken your existing configuration on other distros - has persisted.
Man, I still remember what a pain the migration from PulseAudio to Pipewire was. Sure, it's only a couple packages, disabling a few services, enabling a couple others. But I had to do this almost on the daily, while bugs in Pipewire/Wireplumber were still getting ironed out and were rendering my audio stack temporarily unusable.
Here is a simple workflow with mutable systems like Fedora that I think a lot of people are missing. AI could be brought into this workflow also for those who want that:
(1) Take a snapshot of your current system (snapper+btrfs on Linux, bectl on FreeBSD+ZFS)
(2) Make destructive changes like install a new windows manager, some drivers etc.
(3) If everything worked out well, continue
(4) If something failed badly, restore from (1) using the snapshot restore -- Your system is as good as before
This workflow replicates many of the benefits of NixOS without the complex nix scripting that can be often needed.
Of course, a declarative and textual rendition of the configuration is better than bash commands entered on the command line but sometimes you don't need that level of precision.
Fedora also offers immutable distros which are (I've heard) much more user-friendly than Nix. Sure you can make a hacky pseudo-immutable workflow on a mutable distro but that's literally more effort for a worse result.
But note that I did caveat my suggestion: "Of course, a declarative and textual rendition of the configuration is better than bash commands entered on the command line but sometimes you don't need that level of precision."
A snapshot of your build folder. Not even the sources. This is my other problem with mainstream Distros. Extending them is completely opaque. NixOS is source based and anything and everything can be updated by the user. Need some patch from kernel ML? 1 line of code. Need a Bugfix in your IDE that hasn't landed in a release? 1 line of code.
There is no distinction between package maintainers and end users. They have the same power.
In the meantime i dont expect Debian users to ever write a package themselves or to modify one.
Arch Linux also has a long history of people writing their own package specs (AUR) and is relatively simple too of course.
Let me put it differently. The documentation of NixOS treats package maintainers and users as kind of equal.
This has benefits and downsides. Benefit is that everyone is treated as a power user. Downside is that power users are horrible at writing docs and this philosophy is my main theory why NixOS docs are so .... Bad
Fedora (and RHEL) end user and developer docs are written for quite different audiences
Yes I just replied to your other comment with the same observation. It reminds me of an article by Paul Graham, I forget which, who expressed the difficulty of explaining to programmers who lack an abstraction just how good the abstraction is. Anything you can do with NixOS, you can do with any distribution, because it isn't magic. But somehow, more stuff becomes possible because it gives you a better way to think.
(As for why the docs are so bad, I think it's because of the lack of good canonical documentation. There's too many copies of it. Search engines ignore the canonical version because it's presented as one giant document. Parts of the system aren't documented at all and you have to work out what you've got by reading the code. The result is that you have no idea what to do if you want to improve the situation - it seems like your best option is to create new documentation. And now you have the same basic level of documentation that didn't help the first hundred times it was rewritten. And I don't really think submitting a PR to nixpkgs is exactly userfriendly, so it probably discourages people from doing the "I'm just trying to understand this, so I'll fix up the documentation as I learn something" thing.)
yes i think you've hit the nail on the head. I tend to view NixOS not as a distribution, but as a distribution framework. The system configuration is the sources for an immutable distribution as much as it as system configuration.
You're in no way bound by decisions of the nixpkgs contributors: as you say, we can add a patch. Or we can also decide we totally disapprove of the way they've configured such-and-such a service and write our own systemd service to run it.
Anyone can write a local debian package which adds a patch, and build and install it. And anyone can write a systemd service and use it instead of the distribution's systemd service. But on NixOS, these are equal to the rest of the system rather than outside it. Nixpkgs is just a library which your configuration uses to build a system.
That’s a great way to get one of the benefits of nix. But you still can check that snapshot into version control, share it with all your machines, etc.
You're right ... you cant check that snapshot into version control and share with your machines etc. When you need that level of control and need to scale your configuration to other machines NixOS sounds like the right choice. If it's for your own machine and you just want to try out a new windows manager non-destructively use snapshots.
I think they just mean that the fat that they can do it this way says a lot about the os. No need to get into the weeds on exactly how to install hyprland. It was an example.
People who get bogged down by the details of examples/analogies are usually missing the point of why people use examples/analogies.
I use Nix for my homelab servers, and I'm using AI to be my IT support staff essentially. I don't need to ask AI for help installing hyperland, that is trivial as you say, but setting up nginx port forwarding? samba configs? k3s or k8s? Yeah individually any one of those things isn't very hard. But instead of spending 30 minutes reading through config examples and figuring out where it's setup I can instead spend 30 seconds just telling AI what I want, skimming the output to see if it's looks reasonable, and then doing a good ol' `git commit` of the config file & kicking off the "now go do it" nix build command.
And, critically, at no point does an LLM ever have access to sudo, shell, etc.. It just works with plain text files that aren't even on the machine I'm deploying it to.
I'm not OP but that's basically right. With NixOS, nix generates the system configuration as well as making sure the packages are available. If you pin your dependencies using something like nix flakes and rely on git as your source of truth, you can get GitOps for the operating system.
But it isn't necessary. You can certainly make a change and apply it without committing it to git or relying on a CI/CD pipeline to deploy it. And it isn't necessary to use input pinning - if you don't, you can wind up making it at best archaeological work to rollback. Most people recommend flakes nowadays though, whose input pinning and purity rules should prevent any need for archaeology if you do commit before applying.
Yes. That's why I'm using NixOS as well, despite all the terrible jank it has.
Automating my homelab config with coding machines not only hides the jank, but also makes NixOS feel like some actual agentic OS Microsoft wants, or rather an ad-hoc prototype. I literally just tell it what to do and describe issues if I have any. But again I have written a ton of Nix previously and I'm able to verify what it does, most of the time it's correct but it's not perfect.
I recently fixed the pipewire audio stutters by just giving gemini my flake and asking how to fix it. It suggested a few fixes and low and behold they were gone! Here's my flake with impermanence + yubikey login: https://github.com/leonewt0n/nixos
I would just like to give this a big ol’ +1. I did not like Nix when I started. The ergonomics are hard to get around, but the power is honestly hard to overstate.
Coding agents actually help with a lot of the ergonomic issues. If you have an evaluation issue, it can be annoying to climb into nixpkgs to diagnose it. But codex will do that for you.
I’ve found agenix in particular to be really great addition for agents: secrets you can copy around without risk of accidental disclosure.
In a day I can now deploy Caddy, Authentik, Fleet, Headscale, Stalwart, jmap-webmail, Forgejo, SFTPGo, Immich, Grafana, Jaeger, PostHog, etc. and have them all work together. I can do this on a tiny VPS, and codex can actually estimate and test performance to minimize cost.
The equivalent Kubernetes setup wastes so much on isolation and a scheduler that is overkill for anything small.
I've recently switched to nix as a way to encode my environment across my server and work / private devices a bit more than just having some Brewfiles. I know it's not worth it for the computer switch every few years but having a somewhat opinionated place to centralize my config is worth it over regular dot files.
My first impression after a week of using:
- I really dislike the complexity of terraform, and this is very similar
- The UX is pretty bad, the commands and flags are hard to memorize and you basically need a shell alias for any regular commands to clean them up
- The commands you run regularly like applying your nix config to the system after adding some new packages or config options look like: "nix run nix-darwin -- switch --flake /Users/philipp/repos/github.com/dewey/nix#private"". The output is a mix between expected warnings and way to verbose for something that should essentially be the equivalent of "brew update / brew upgrade".
I'll stick with it as I didn't find anything better and LLMs are great for building up the config over time, but there's definitely room for some improvements.
I really want to like NixOS (and I mostly do) but the weirdness of the split between NixOS and HomeManager (and the fact that without HomeManager, you need another solution to manage your user-level configs) made it come up a bit short for me.
I feel the same way about Guix with nonguix channel enabled. NixOS is awesome but I prefer Guile to Nix's language and I enjoy the docs more. But definitely sister OSes.
There's nowhere near enough love for Guix. I don't understand it. It has far better foundations. I would never invest time into some "config language". Using a real programming language has huge benefits, and it's a good one (Scheme).
I tried NixOS a few months ago, when I had to choose a new OS for my laptop.
On the one hand, it's great, as so many others here and TFA have attested. Declaratively specifying your system configuration and using snapshots to keep track of everything is a complete game-changer. Similarly great is the absolutely huge universe of installable packages. The coverage here is so much better than what's on offer from Ubuntu or Fedora.
On the other hand, the current implementation is still a bit of a shit-show.
First, there's nix-the-OS and nix-the-package-manager which is pretty confusing. Effectively it means you manage your OS with one declarative system and your local/home config with another. Then there's "Flakes" which I never quite understood, that seem to offer a different modality altogether.
Second, installing packages is nice, but also confusing. Do you install a package or a service? Often both are available and the difference is not always clear. Eventually I learned to choose a service whenever one was available. In either case, the tendency of package maintainers is to install the smallest possible version of whatever you asked for. For example, I wanted KDE but what I got was a bare minimum version with plenty of missing apps and functionality that could only be fixed by adding extra components, one at a time, after debugging whatever was currently breaking.
I appreciated that services and packages can be configured in the configuration file. But the options exposed are usually a partial set of what's available -- without extending the installations scripts yourself. So now my "declarative" config is a mix of what's in my nixOS config file and what's in my manually edited /etc files.
Third, the documentation, mentioned by others, is a mess. There's all kinds of information about old and new versions. The interfaces of the command-line tools seem to have changed between the 25.05 stable that I chose and the then-upcoming 25.11, which made following-along harder than it needed to be.
I eventually gave up because I needed a working machine and not a new hobby. I was left with the impression that NixOS might be a good choice for system admins, but perhaps not yet ready for desktop Linux users.
I can completely understand how you were driven away. If you ever want to give it a go again:
> there's "Flakes" which I never quite understood
Nix never clicked for me until I started using flakes. There's a lot of internal drama surrounding them that honestly childish; that's why they are marked as experimental and not the official recommendation. You are going to have a worse time with Nix if you go with the official recommendation, flakes are significantly more intuitive. The Determinate Systems installer enables them by default, and whatever documentation they have is on the happier path (except for FlakeHub, I haven't figured that one out yet).
On the most fundamental level, flakes allow you to take /etc/nixos/nixos.nix (or whatever, it has been forever) out of /etc and into a git repository. Old-style nix may be able to do that, but I discovered flakes before trying. I did previously attempt to use git on /etc/nix, but git was falling to pieces with bizarre ownership problems.
What this means is that I could install and completely configure a machine, once booted into a nix iso, by running: nixos-install --flake https://github.com/.../repo.git. I manage all of my system config out of /home/$user/$clone
As for /home there is home-manager and, again, you are not steered towards it (the tutorial pushes you towards nix profiles/nix-env instead). Home-manager will do for your home directory what the system config does for your system, and has many program modules. You can even declare home-level systemd units and whatnot.
> manually edited /etc files.
You can use environment.etc for these files[1]. systemd.tmpfiles can be used for things outside of etc. Home-manager has the equivalent for .config, .local, .cache. [2].
Yep, i am doing the same. I have a central remote flake repo where all my machines, services, etc are defined and they all run tweaked autoupdaters to periodically do full updates. I push commits and wait and forget. It feels like maintaining your distro everywhere, no matter where you ssh in. And soon, i will migrate that repo off a central platform (github) into radicle or something and turn some of my machines into seeders. Then, with offsite data backups, my house could burn down and github go dark, i could still recover, maybe in the future even bootstrap from my smartphone. A big step towards digital sovereignity.
> Hi, I just wanted to know, where can I find the documentation to know more about this contrib.lib.file.mkOutOfStoreSymlink option ?
> Well, since is a very simple function, no documentation is really needed.
I've been gradually transitioning everything to NixOS, starting with my homelab mini PC, then my Framework laptop, and now my daily driver desktop. It's hard to imagine going back because the pros are so strong compared to the cons, but the docs situation is truly dire.
That’s my feeling when reading nixos forums. People are willing to help but don’t realize how little newbies know about nix when asking for help. The first month of nixos was a massive uphill climb for me, and that knowledge doesn’t stick well because I get to interact with nix every few months to tweak things, not weekly or daily.
It’s a solid os, and I’m enjoying it, and I love that I can’t break things while tweaking. But the docs are and discussion threads are not written for beginners (it’s really hard to write for beginners).
> I can specify the whole OS including the packages I need and the configuration in one declarative setup. That one place aspect matters to me more than it might sound at first.
It took me less than a day of experimenting with it to learn that it is one place only in theory.
The second you start googling „how do I install xyz“ you discover there are also flakes. And others have some sort of convoluted git like method. And there is a package manager thing. And the direct config file editing like in this article. And a disposable temp install of some sort. And naturally software guides don’t give you instructions for all - they’re opinionated.
Felt a lot like being on Debian and the software only comes in .rpm
That really took the wind out of my sails because like OP I liked the basic config file part
I see your point about there being different ways to install a package, but I think I can clarify a bit by explaining how I use NixOS.
If I'm running a package on a server that means I want to install it declaratively, so I find the name of the package in Nixpkgs and put it in my `configuration.nix` file. I'm using flakes, but the configuration is exactly the same, I just put the package in the output section of the flake. Any instructions you see to install a package just boils down to finding the name of the package. To me this is as simple as finding the name of a Debian package and running `apt` to install it.
If you want additional features there are other optional ways to install packages, but these are features other distros don't offer, so if you just ignore them then there's no extra complexity compared to Debian for example.
i've been tempted by NixOS for servers but keep going back to Debian. the reproducibility is amazing in theory, but when you need to debug a DKMS kernel module build at 2am on a VPS, having "just apt install" is worth a lot. maybe NixOS for dev workstations, Debian for production VPS is the right split.
The reproducibility is amazing in reality: you either just run the misbehaving server’s config in a VM (one command) or spin up a throwaway VPS and apply the config to that (one command and about 60s). One of the major benefits of reproducibility is not having to poke at production machines because that’s the one place you can manifest the issue, now you can reproduce the in-production issues in a safe environment and fix them there.
I think the most interesting use case I have seen so far was for computers that control industrial equipment where you want identical installs on potentially dozens of machines.
I love my kitchen knife and I love Emacs. More love is a good thing. Unless you're the kind of person who thinks not loving is better because you've got nothing to lose.
To me, loving inanimate "trivial" things diminishes the value of love. I love my girlfriend and my pets. I like my kitchen knife and my car. To bunch up both into the same category confuses things into "which one do I love the most", some sort of spectrum of love.
In the case of a fire, I'm sure you wouldn't prioritize your laptop with NixOS over your cat (let's imagine that the only backup is in the house that's on fire).
I liked NixOS pre-LLM era, since it allowed me to manage a couple of servers in a reproducible way. Ability to reboot back to a stable configuration felt like magic.
Nowadays I love it, since I can let Codex manage the servers for me.
“Here is the flake, here is nix module for the server, here is the project source code. Now change all of that so that wildcard certificates work and requests land through systemd socket on a proper go mux endpoint. Don’t come back until you verify it as working”
The versoining and ability roll back is game changing for SRE Agents and preventing their ability to royally take down services, being able to audit and go back to the previous good known state is gold
I keep going in circles with thinking about trying NixOS.
I see an article like this about how great it is, think I might try it, then go down a rabbit hole of all the horror stories, and then give up before starting.
I still really wish there was a NixOS, but without the quirky filesystem/linking setup.
Declarative, but not trying to solve for the "I want 5 versions of python at the same time" problem. The weird NixOS filesystem is where 90% of my Nix issues come from. And I don't feel like I benefit from it much, if at all. Bonus points if this fictional solution doesn't use a fancy new programming language. Something like HOCON would be perfect.
I just want the same OS, packages and config on all my machines without allowing long-term drift. And I want the time I spend tweaking my Linux setup to be an investment, not a waste of time that gets thrown away when I upgrade. I know I could use home-manager or similar for my user-level config, but that's not enough.
I've been experimenting with the immutable fedora-bootc images and podman+Containerfiles, which works pretty well for this. But there's no "nixos-rebuild switch" command, so changes require a reboot. Fine for daily use, but very painful when experimenting. I did discover its possible to use the older dnf4 --transient flag to temporarily install packages, which is helpful.
I guess its a trade-off between easy tinkering (Nix) but frustrating filesystem vs fussy tinkering (bootc) but standard linux filesystem once booted.
Nix is a really good good good approach to manage packages. I've configured an entire asahi setup with for my m2 and can't be happier. It's not without it's quirks and nixlang itself is a bit cumbersome to express what you want.
However, AI is a great fit to write flakes. You can easily understand the generated code and it gives a power to "review" the changes before applying them.
And while nixos is amazing, I think nixpkgs are a bit overhyped; I've encountered many packages that are abandoned and outdated.
Definitely interested! I've reinstalled Fedora Asahi Remix several times on my old M1 after fiddling my way into a broken state. NixOS sounds like a tinkerer's dream but getting started is a bit intimidating.
I started playing with NixOS recently in a VM and... while I don't have much experience with it yet, it feels _great_ for the many reasons described in the article. I really like configuring a file and knowing that the rest of the system aligns to whatever that file says: no more, no less.
The language is "interesting" and I haven't had to learn it in depth yet. Claude and Codex really make it easier to get started with Nix's weirdness -- but that's unfortunate because I feel I'm not going to learn the "real thing" otherwise. And this difficulty makes me curious about Guix though because, even though I'm not LISP expert either, at least I can read it.
Anyway. I'm just shy to "dig deeper" on NixOS because my servers are FreeBSD and I'm already feeling the temptation to swap them with NixOS, which would feel like a betrayal to these long-lived installations... ;-P
I feel like if you want to learn Nix with some hand-holding, resist the urge to use Claude Code or Codex, but instead just use the chatbot in the browser or something. Ask it questions, explicitly copy and paste in errors as they come up, and manually copy and paste out the generated stuff.
I found that this gives a good compromise of being able to learn Nix relatively well, but still having a "tutor" to help when things get tricky. I'm reasonably ok at Nix now, and can generally figure out what I need to do without AI assistance, but I'm glad I had ChatGPT when I was getting started with it.
I love NixOS and nix-darwing too. Specially now that I can use it without having to learn a bunch of stuff before even getting started. My coding agent is great at it.
dont know. you can create a config package with most distribution. i do config packages for debian. ai can help you on it. you tag it as config-smthg. you save it . you can create a config with a possible rollback organically by just uninstalling it or installing version-x.
with this you get atomic changes.
soumyaskartha | a day ago
Daunk | a day ago
Imustaskforhelp | a day ago
If you don't mind a very limited set of software, the way tinycorelinux is setup can also allow multiple different tcz installed
These two Linux distros essentially allow two different versions of same software/libraries (glibc/python whatever) installed
(Gobolinux explicitly states that whereas I find it to be an unintended but elegant consequence for tinycorelinux but I recommend taking a look at Gobolinux)
Diti | a day ago
jwiz | a day ago
That is in between "use it for very short period of time" and "use it forever"
DanielVZ | a day ago
troad | 18 hours ago
I feel like it's more of an indictment than praise; it implies Nix is relatively inaccessible to interested but time-constrained dabblers, which puts a hard cap on Nix's ability to outgrow its niche.
hrmtst93837 | 14 hours ago
dizhn | 11 hours ago
ux266478 | 6 hours ago
I'd much prefer just Plan 9. WORM filesystem and first-class namespaces.
loremm | a day ago
For an example, I love atuin but it, by default, skips commands starting with space. Currently it's not configurable and while I wait for time to submit a PR or for the issue to be resolved, make a single line `patch` which just removes the part of the `if` statement which checks if it starts with space. So easy, took 5 minutes (also had to comment out 1 test).
And now on home-manager debian or nixos server, I get up to date atuin with that one patch. It downloads rust, etc, compiles, and then that's garbage collected away
0x457 | a day ago
kiliankoe | 7 hours ago
Other than that I very much agree, patching stuff is wonderful in nix-land! Especially when things in nixpkgs-unstable break.
nehalem | a day ago
MuffinFlavored | a day ago
nehalem | a day ago
fermuch | a day ago
shakow | 22 hours ago
Cyph0n | 21 hours ago
Btw, I say this as a huge fan and heavy user of both Nix and NixOS.
rgoulter | 19 hours ago
Modules let you express the system in smaller, composable, reusable parts rather than express everything in one big file. (There are other popular tools which support modules: NixOS, home-manager, flake-parts).
That devenv also provides "batteries included" modules for popular languages (including linters, LSPs) is also a benefit.
JamesSwift | 6 hours ago
ekropotin | a day ago
shakow | 22 hours ago
devenv does not do any user-level change (you will not be able to make it configure your WM), but works at the directory level.
For instance I'm currently working on a Rust + C++ project, and my devenv, whenever I enter this project folder: make CMake/g++/cargo/cbindgen available, enable a couple scripts to longer CMake invokations, set-up everything required for C++ and Rust LSPs, and create a couple git hooks to validate formatting etc.
foldr | a day ago
As best I can tell, Nix enthusiasts think that this is an XY problem and that I shouldn't want to pin individual tools/packages to arbitrary versions. But the thing is that I am a rude barbarian who very much does want to do this, however philosophically misguided it might be.
malmeloo | a day ago
The downside is that flake inputs refer to other flakes, not individual packages, so if you update the nixpkgs input it will upgrade all of your packages at once. For some packages such as Python, nixpkgs tracks multiple major versions so you can loosely pin to that version. You can also include nixpkgs as an input multiple times under different git tags/commits and only use that input for some of your packages to effectively pin them. You could keep using one nixpkgs but override the package's source to build it for a specific version/commit, but this setup could break in the future, because the derivation (and therefore build instructions) will keep evolving while your package's version will not. Or, if you really wanted to, you could straight up just copy the derivation from nixpkgs into your local repository and use that instead.
Nix is quite flexible so there's more options than just these, it just takes a little getting used to to find out what's possible. I don't use devenv myself, but some quick googling reveals it works just fine with flakes, so I would try that to see if it suits your needs.
foldr | a day ago
> How do I set up my development environment using devenv.sh to pin nodejs to 24.14.0?
If I understand your response correctly, I can't do this in any very practical way.
JamesSwift | 19 hours ago
foldr | 12 hours ago
JamesSwift | 6 hours ago
oasisaimlessly | 6 hours ago
Novosell | 11 hours ago
JamesSwift | 6 hours ago
In general though when working on a team, you dont really care about the _exact semver version_, you care about the major and handle version bumps by bumping the pin of nix packages.
SAI_Peregrinus | 19 hours ago
The way to do it is to find the `nixpkgs` version which contains the version of the tool you care about. There's a web site[1] that makes this pretty easy, and it's of course also doable by looking at the Git history for the program's derivation.
Then you create a named input using that nixpkgs version: either add it as a channel, import it with fetchTarball in a derivation, or add it as an input in your flake, depending on what you're doing. Then you use that named nixpkgs (or other input in the flake case) for that version of the package.
Edit: One issue with depending on things like git tags or semver versions is that sometimes people re-use versions or edit tags. Using the actual git commit hashes of the package's derivation avoids this potential ambiguity. This is why we can't have nice things.
[1] https://lazamar.co.uk/nix-versions/
bikelang | a day ago
Is the Nix-ism to just reject using such software?
uncletaco | a day ago
SOLAR_FIELDS | a day ago
The true answer is that there is just some software that is antithetical to the philosophy of nix. It’s not necessarily nix’s fault that this is the case, but their purism towards resisting opaque binary blobs going into the store reflects on the actual state of what’s available in nix.
You need some impure, nonreproducible way of managing that software. So on nix Darwin I let these opaque binary blobs manage themselves via homebrew and use nix for every other case possible
zamalek | 19 hours ago
MuffinFlavored | a day ago
right now I have bought into the Nix koolaid a bit.
I have NixOS Linux machines and then nix-darwin on my Mac.
I use Nix to install Brew and then Brew to manage casks for things like Chrome what I'm sure updates itself. So the "flake.lock" probably isn't super accurate for the apps you described.
whytevuhuni | a day ago
I tried Discord, and this one seems to download some updates on first run, but the version sticks to the one from the system (0.0.127, latest is 0.0.129). So I assume it just doesn't update, or it tries to and fails.
Macha | a day ago
Jetbrains Toolbox is in a sort of different category with tools like Rustup, since it's a package manager of its own. If you manage your IDEs with Toolbox, then your IDE versions are "outside Nix" and not managed by Nix. It's just packaged into its own pretend FHS environment and then doesn't know anything about it being on Nix. That said, updates of Toolbox itself will need to happen through your package manager.
As a last comment, why run Docker Desktop on Linux at all? Like I understand on Windows and Mac - docker is inherently tied to Linux so the Windows/Mac apps abstract away the fact that it's running a VM and doing a bunch of port mapping and filesystem mounting under the hood so you can pretend it's not running on a VM, but on Linux I've always just installed docker straight onto the host.
bikelang | a day ago
Regarding Docker Desktop on Linux - yeah definitely not strictly necessary. Sometimes it’s just convenient to have a UI instead of fumbling around trying to remember some cli incantation to check for dangling volumes or what-have-you. I think ideally I want to move to Podman anyways - but I’m using pop_os as my dev distro at the moment and am stuck on an older version which doesn’t have their native `podman compose` implementation yet
k_roy | a day ago
1. Unified experience across Windows, Mac, Linux
2. The security posture is much stronger by default. Many people, who would probably be considered the “target audience” for Docker Desktop, don’t bother to make docker-ce rootless, or don’t use podman, so running it in a VM is better, though admittedly often annoying.
3. Not everybody is a CLI warrior. Docker Desktop gives a decent GUI, ways to monitor and control containers visually, and even deploy kubernetes with a single click.
hombre_fatal | a day ago
For some things I've vibe-coded a nix module on github that uses a scheduled github action to check for underlying app updates and then it generates a new hash and tags a release.
I've done that for claude code and cursor, which is also an opportunity to let me manage their config files from my nix config.
snailmailman | a day ago
Nixpkgs is very complete in my experience, and in the instances where its not, someone usually has made a flake. The only times ive had to custom-make a flake were extremely new programs, or extremely old ones. Often the newer programs had PRs waiting on nixpkgs anyway, and were only a few days away from building properly in nixos-unstable.
hombre_fatal | a day ago
You're right. When I tried using NixOS as my main desktop experience for a few months, I ended up with a custom derivation for various apps I used. That's probably why I made the claude code and cursor modules in the first place.
But I'm also remembering I made my own keepassxc module because keepassxc wants to be able to write to its config file, but I also want to configure it from nix, so I had to make my module use an activation-time script to merge nix config into the keepassxc config file.
I lost interest in NixOS for day to day personal computing, though vibe-coding modules like that wasn't as big of a dealbreaker as there being almost zero laptops that compete with a Macbook.
The other pain is Linux desktop environment stuff in general like dealing with interactions between a Steam game, wayland, and wayland-satellite. Though NixOS helped there since it was easy for an AI agent to investigate the issue, inspect the nix config, and make a targeted, commented patch that shows up in git.
gallexme | a day ago
And there's also nix alien and similar tools as alternative
But indeed usually you end up using patchelf , tell the inputs of a binary n just make a regular nix package from it
rounce | 11 hours ago
You can: https://github.com/nix-community/nix-ld
erichocean | a day ago
Cyph0n | 21 hours ago
Personally, I don’t see the need for this with NixOS. Setting aside the fact that Omarchy is way too opinionated (Basecamp installed by default?), NixOS is already quite composable, so you can easily build a well-formed experience out of isolated NixOS modules.
rounce | 8 hours ago
* IMO Omarchy doesn’t make sense anyway, far too much opinion and too little utility. It’s not a distro it’s some guy’s overly promoted pile of crufty scripts and dotfiles.
CafeRacer | 5 hours ago
My entire config is almost "omarchy", at least visually with hyprland and some other packages.
fareesh | a day ago
Valodim | a day ago
bspammer | a day ago
Pay08 | a day ago
moonlion_eth | a day ago
exitb | a day ago
dandanua | a day ago
CafeRacer | 5 hours ago
I had issues when giving boot partition only 512mb, so I'd recommend going with 1G.
quchen | a day ago
I haven’t given it a shot in the LLM age yet though, and trying out NixOS in a VM is not only easy, it is practical – in the sense that when you’re happy, you can simply boot that same config/OS anywhere else by just installing that config. And I’ll never forget that one time where I completely borked my everything in the VM, did a kernel rollback with like 3 command line args and a reboot, and the OS was, well, rolled back. As I said, almost platonic.
What I can recommend is using nix-the-package-manager. Whenever I need the newest version of something, `nix-env -i <whatever>` and it’s there and works. If it doesn’t, roll back. If I need a different version, that’s on nixpkgs as well, with the same negligible amount of friction.
Pay08 | a day ago
colordrops | a day ago
Using AI to generate Nix config is a superpower. Because the entire system is declared in a single set of config, you can basically spell cast any system you want. I one-shotted a Linux distro with custom branding for boot, installation screen, and login screen, and VPN and dev tools installed and configured by default, at a fortune 500 tech company.
MarsIronPI | a day ago
[0]: https://nixos-and-flakes.thiscute.world
bspammer | a day ago
linsomniac | a day ago
I haven't tried it in almost a year, but using Claude Code for setting up my nix config back then worked amazingly well. I've only dabbled in NixOS, and I'm very tempted to it for my workstation when I reinstall it in the next month.
Given how much Claude Code + Opus have improved in the last year, I'd give it a fighting chance to make a nice Nix config. I'll probably start setting up a spare laptop to get the base configs dialed in before switching over to it.
12345hn6789 | 23 hours ago
epolanski | a day ago
It's also simple to setup dev environments with nix.
bikelang | a day ago
Norfair | a day ago
shae | 21 hours ago
BoredPositron | a day ago
qiine | a day ago
hombre_fatal | a day ago
Also, using higher level modules like home manager makes things more declarative and less fiddly since someone else is maintaining the lower level.
Maybe nix is a downgrade for what you do. But I loved nix so much that I also migrated to nix on macOS (nix-darwin). No more homebrew.
overtone1000 | a day ago
I am no nix whiz, but it's the only OS I run outside of containers. Anything I can't easily get with my nix config I shove into a container, run it as a quadlet, and call it good.
Pay08 | a day ago
chickensong | a day ago
The advantages:
- Declarative code describes your system. Maybe your install + imaging flow is good enough, but there are many reasons why it's technically inferior. There's no need for imaging Nix, because it's always reproducible by default. Rollbacks are rebooting to a previous config, not a timestamped blob of snowflake state.
- It replaces whatever tools and glue you have to build your system. You don't need to worry about bootstrapping tools, or config management tools' version compatibility, or bespoke ordering of imperative steps to build the system. All the management tools are built into the system. Everything "just works" automatically.
- If you manage multiple machines the benefits are compounding.
- There are other interesting bits that are covered in the article, that you get for free just due to the nature of nix. It's good for building, and has no friction to experimenting with specific tools or environments, without polluting your system.
It's a commitment to get past the initial learning and config build, but afterwards it significantly lessens the "hobby" aspects of computer management. There are just entire classes of problems that don't exist for Nix. Either your config works, or it doesn't, and the rollback guarantee is explicit and built-in.
dangirsh | a day ago
A WIP NixOS config for working with agents:
https://github.com/dangirsh/tsurf
redrove | a day ago
If you’re itching to try Nix, now is the time.
hombre_fatal | a day ago
Can't imagine going back to the status quo where my system is the accumulation of terminal commands over time instead of a config file.
redrove | a day ago
edent | a day ago
Everything seems scattered around a dozen forums, a hundred old blog posts, and a thousand issues of "this work on my machine (3 releases ago)".
exe34 | a day ago
moonlion_eth | a day ago
qiine | a day ago
fragmede | 18 hours ago
exe34 | 13 hours ago
CyberShadow | 12 hours ago
qiine | 10 hours ago
hombre_fatal | a day ago
drdaeman | a day ago
Claude Code has to be actively steered, because while it knows some nixpkgs it surely doesn’t know it enough. E.g. it was absolutely incapable of fixing lldap settings after system upgrade from 25.05 to 25.11. It just prodded around blindly, producing meaningless configs instead learning how the module works.
NixOS docs work for me, but I tend to just go for the nixpkgs source instead. Manuals document options but not how those are actually plumbed through, nor what remains behind the scenes like all systemd unit settings). Claude can do this too, but it goes quite weird roundabout ways with a lot of weird `find /nix/store` and `nix eval`s to get to it, slow and token-hungry (and not always accurate).
This said, Claude is very helpful at checking logs and providing a picture of what’s going on - saves ton of time this way. Plus it can speed up iterating on changes after it’s fed enough knowledge (but don’t expect it to do things right, that’s still on you). It has breadth of it, but not the depth, and that shows at almost any non-trivial task.
hombre_fatal | a day ago
I feel you on the nix store + nix eval death loop, though it gleans real info. If I weren't on the Claude Max plan I'd probably feel more of the pain. And context is now 1MM tokens which means you're not running out just as it's starting to piece things together, heh.
drdaeman | a day ago
I’m going to experiment with skills next, or maybe make it build a few helper scripts for itself to quickly get some module source from nixpkgs matching flake.lock without having to think of it all. I’m positive about Claude for nix management, merely saying it’s not something that “just works” for now and reading nix code is still on the human part of the tandem.
This said, to be fair - when it gets the approach right, it excels. I was setting up Ente for photos backup and sharing, and it produced a nice overlay with custom patches for my needs from just “figure out why /shared-albums/ redirects wrong and fix”. Found the module, the package, pulled source, analyzed it, proposed a patch (settings weren’t enough), did it - I only had to test, and only because I haven’t provided it with a browser. Felt amazing.
johnisgood | a day ago
hombre_fatal | a day ago
Unless you're brand new to Linux or computing, it's not a mystery what a given nix config change is ever doing.
You can probably guess what this does:
The things to know about the OS are high level things. The rest of its idiosyncrasies you learn just in time through daily exposure like anything else.shevy-java | a day ago
I am not brand new - and I don't know what the heck the config is doing.
That is why I rely on documentation.
The "code is self-explanatory" is always an attempt to not have useful documentation and try to rationalise that problem away.
hombre_fatal | a day ago
You can read documentation on an as-needed basis or to your heart's content.
The point is that the majority of the day to day changes I make to my desktop environment aren't so critical that I need to do more than read an AI agent's proposed changes to my config and accept them when they look reasonable.
And I don't think looking up the exact config options to NixOS' networking system does anything to increase my knowledge of the OS. It's just a triviality.
sally_glance | 21 hours ago
frantathefranta | 18 hours ago
afishhh | 9 hours ago
Fails to parse is what it does...
Are we really living in times where people can't write a single (syntactically) well-formed line of code in a programming language they use?
I understand this doesn't really matter when just using NixOS Slop Edition™ but man I hate it.
hombre_fatal | 5 hours ago
Jeez, tough crowd.
Though it also kinda represents this pride over triviality that some people latch on to in the AI world which is odd since it's also only a mistake a human would make. Had I run my hand-written comment through a proofreading clanker, I would have spared you the negative emotional reaction.
In the pre-AI world, you would have probably not been so harsh since it's understandable that someone make that mistake with such an idiosyncratic language like nix that almost nobody writes full-time. Yet in the AI world, you demand more from humans.
Something interesting, there.
TheAceOfHearts | 23 hours ago
I think the initial migration towards nixOS is the hardest point, since it requires learning a bunch of new things all at once in order to get the system into a usable state that matches your expectations and preferences. The key benefit of using an LLM is that it makes it really easy to get your system into a useful initial state, and then you can safely learn and experiment incrementally with a mix of tools.
When I started off I didn't understand everything, but at this point I feel I have a very good understanding of everything in my configuration file.
Thanemate | 22 hours ago
beepbooptheory | a day ago
Like what is ultimately the difference here for you vs a non-nix user who, as author says, is just dealing with some big ambiguous pile of state? It kind of takes away any upside to using nix, and probably just creates more friction for your AI than just running ubuntu/apt stuff.
The idea is you can keep configuration "in your head" such that you can reason and iterate and fully know what your system is like at any moment. If you actually don't care about that, you aren't getting anything out of it!
hombre_fatal | 23 hours ago
I have these packages installed and these firewall settings and these users with these permissions and this folder served over Samba and these hotkeys that do these things and these Obsidian vaults synced over SyncThing and these devices in my SyncThing network and Neovim installed with these plugins and ...
This is difference between me and a non-nix user, not whether we can rattle off the exact state of our live system from memory.
The non-nix user has to query live system state, if such query tools even exist for their question, and I get to read a config file. And I get to maintain my system config in git, and I get to deploy my config on all of my machines.
beepbooptheory | 21 hours ago
dml2135 | 7 hours ago
beepbooptheory | 5 hours ago
dml2135 | 2 hours ago
Well the main difference is precisely that I have a clear opportunity to read and understand the declarative file.
But even if something were to sneak in there, rolling back is now trivial.
beepbooptheory | 2 hours ago
eikenberry | a day ago
MarsIronPI | 23 hours ago
eikenberry | an hour ago
snailmailman | a day ago
wiki.nixos.org claims that nixos.wiki is outdated and unofficial. But both appear to receive updates, and which one wins the SEO game is a coinflip whenever i google a nixos question.
Cyph0n | a day ago
Arelius | 22 hours ago
And that's what's great about NixOS, you just clone nixpkgs and treat it like any other underdocumented software you might work on.
Cyph0n | 21 hours ago
okanat | 19 hours ago
As a software engineer I have an opposing attitude towards this. I work on projects with terrible documentation because somebody pays me to do so or there is a significant potential that I can unlock.
There are significant alternatives to NixOS like bootable containers and OSTree which are more useful and better documented. If Nix project really cares about being competitive and adopt users, they have to document their stuff. They are already going against the grain and ain't nobody has time to put up with their weird language and their subpar documentation.
Arelius | 18 hours ago
I mean, I'd argue there is significant potential, but really, for me it's just easy because I've been doing it for 20 years, and documentation is always fundamentally worse than code in some important ways.
> If Nix project really cares about being competitive and adopt users, they have to document their stuff.
This is one of the good/bad things about OSS.. most users don't provide positive value to the project. So do they really want to adopt users? Shrugs but the project is certainly competitive.
Arelius | 18 hours ago
moonlion_eth | a day ago
voigtk | a day ago
DHolzer | a day ago
stephen_cagle | a day ago
Basically, I want to be able to run completely unverified code off of the internet on my local machine, and know that the worst thing it can possibly due is trash its own container.
I feel like NixOS, is one path toward getting to that future.
woleium | a day ago
bpavuk | a day ago
gallexme | a day ago
If it isn't enough there's microvm.nix which is pretty much the same in difficulty /complexity, but runs inside a very slim and lightweight VM with stronger isolation than a container
cpuguy83 | a day ago
whazor | a day ago
sshine | 22 hours ago
There's also nixos-shell for ad-hoc virtual machines: https://github.com/mic92/nixos-shell
rendaw | 14 hours ago
That's definitely what I want... most of the time.
furryrain | 14 hours ago
* declarative mode, where your guest config is defined within your host config, or
* imperative mode, where your guest NixOS config is defined in a separate file. You can choose to reuse config between host and guest config files, of course.
It sounds like you want imperative containers. Here's the docs: https://nixos.org/manual/nixos/stable/#sec-imperative-contai...
rendaw | 13 hours ago
ogUsername | 23 hours ago
It will always look like curl is available or bash or something
What's wrong with another user account for such isolation?
They can be isolated to namespaces and cgroups. Docker and Nix are just wrappers around a lot of OS functionality with their own semantics attempting to describe how their abstraction works.
Every OS already ships with tools for control users access to memory, disk, cpu and network.
Nix is just another chef, ansible, cfengine, apt, pacman
Building ones own distro isn't hard anymore. If you want ultimate control have a bot read and build the LFS documentation to your needs.
Nothing more powerful than the raw git log and source. Nix and everything else are layers of indirection we don't need
otabdeveloper4 | 23 hours ago
No, because Nix code is actually composable. These other tools aren't.
rounce | 19 hours ago
neobrain | 12 hours ago
NixOS containers are the most convenient way to do this, but those will map the entire global nix store into your container. So while only one app would be in your PATH, all other programs are still accessible in principle. From a threat-modelling perspective, this isn't usually a deal-breaker though.
There's also dockerTools, which lets you build bespoke docker/podman images from a set of nix packages. Those will have a fully self-contained and minimal set of files, at the expense of copying those files into the container image instead of just mapping them as a volume.
codethief | 7 hours ago
nullbyte808 | 14 hours ago
laserbeam | 13 hours ago
squiggleblaz | 11 hours ago
I think there's ways you can autoderive a python3 with specific packages from python dependency files, but I can't help you there. I do find AI to be reasonably helpful for answering questions like this: it just might sometimes require a bit of help that you want to understand the answer rather than receive a perfect packaged shell.nix file.
codethief | 7 hours ago
[0]: https://mynixos.com/nixpkgs/option/programs.nix-ld.enable
perrygeo | 6 hours ago
My rule of thumb: keep a strict separation between my projects (which change constantly) and my operating system (which I set up once and periodically update). Any hard nix dependency inside the project is a failure of abstraction IMO. Collaborating with people on other operating systems isn't optional!
In practice this means using language-specific package management (uv, cargo, etc) and ignoring the nix way.
schindlabua | a day ago
It's also great for the AI era, copilot is really good with that stuff.
tombert | 23 hours ago
I liked Arch and Ubuntu and Mint and OpenSUSE well enough when I used them first, but once I actually tried NixOS it felt so obviously correct that it started to bother me that it's not the default for everything.
Being able to temporarily install things with nix-shell is game changing, and being able to trivially see what's actually installed on my computer by quickly looking at my configuration.nix is so nice. "Uninstalling" things boils down to "remove from configuration.nix and rebuild".
The automatic snapshots upon each build allows me to be a lot "braver" when playing with configurations than I was with Arch. I was always afraid to mess with video card or wifi drivers, because if I screwed something up and if I didn't know how to get back to where I was, I might be stuck reinstalling to get back to a happy state. This didn't happen that often but often enough to have made me a bit weary about futzing with boot parameters or kernel modules. Because of the automatic snapshots with NixOS, it's much easier (and more fun) to poke with the lower level stuff, because if I do break something in a way that I don't know how to fix, the worst case scenario is that I reboot and choose an older generation.
This is a bigger deal than it sounds. For example, with my current laptop, there was a weird quirk with my USB devices having to "wake up" after not being used for more than thirty seconds, meaning that I might start typing and the first three or four words wouldn't go through. After some digging, I found out that the solution is to add "usbcore.autosuspend=-1" to the kernel params. I did that and it worked.
If I had still been running Arch or Ubuntu, I probably would have just learned to put up with it, because I would have been afraid to edit kernel parameters because of the risk of breaking things in a way that I don't know how to fix.
I love NixOS. I have no desire to leave, or at least I have no desire to abandon the model. I've considered changing to GNU Guix System since I like Lisp more than I like the Nix language, but those FSF-approved distros can be a real headache for people who actually have to use their computers.
lejalv | an hour ago
This is now a tired discussion; the use of nonguix (https://gitlab.com/nonguix/nonguix) is well documented, there is no practical difference after initial setup between using a regular distro and one of “those FSF-approved distros”
I am sure you don't do it on purpose, but could you stop spreading FUD? (specially given you acknowledge “ I've considered changing to GNU Guix System”, so you're here relaying 3rd party opinions, not your own)
rgoulter | 19 hours ago
My experience using NixOS on desktop is that it's 95% wonderful, 5% very painful.
If you run into friction with NixOS, you may need to have a wider/deeper understanding of what you're trying to do, compared to the more typical Linux OSs which can be beaten into shape.
With NixOS, you pay all the complexity up front.
throwawayqqq11 | 10 hours ago
newsoftheday | 4 hours ago
I just use apt, been doing it for 20 years, it works great. I've never in my time, heard of or knew anyone who wrote 20 (or any) bash script wrappers around apt. The one year I was painfully forced to use a Mac for work, brew worked similarly to apt, just used it, no need to wrap it with shell scripts.
Comparing highly functional and capable systems like apt and brew to neanderthal technology sounds like hype.
> It's also great for the AI era
That also sounds like more hype, similar to the pro-nix other comments so far which tout AI and similar to the article which I did read, also sounds like hype.
atcol | a day ago
tombert | 23 hours ago
I mean, I'm only ever using it for configurations, and I think I'd still prefer writing Nix than YAML. I probably wouldn't like writing a full "program" with Nix, but I don't think anyone does that?
kgwxd | 9 hours ago
tombert | 4 hours ago
I have written a lot of PHP. In order to learn it I bought several books, I've done a dozen or so projects with it at various jobs, I've written both trivial and non-trivial things, and I have come to the conclusion that PHP is an actively terrible language [1]. It's inconsistent and hard to write in any kind of maintainable way with an ugly syntax and generally-crappy performance for any kind of logic beyond CRUD.
[1] At least version 5, which is the last version I've used. I've heard 7 is better but I'll never know because I swore an oath in blood that I would not do PHP again for less than a million dollars a year.
choward | 5 hours ago
People just seem to want to complain because it doesn't look like any of their favorite languages and they aren't familiar with functional languages. At this point, I can't imagine using any other language in place of Nix. The code would have so much noise and be much harder to read.
vluft | a day ago
gausswho | a day ago
rowanG077 | a day ago
Pay08 | a day ago
rowanG077 | a day ago
I counted and you regularly see this: "))))))))))" at the end. This is not a language that is optimizing for being written by humans.
Pay08 | a day ago
As for the closing braces, would it be better if you had a newline between each?
troad | 18 hours ago
I've taken a look at the code - having never written a line of Guix in my life - and it seems very readable to me. It's cleanly structured and makes good use of indentation.
The string "))))))))))", which you claim you're seeing 'regularly', appears exactly twice in 4,580 lines of code. It's the longest parens string that appears in the file. Seems to me like you deliberately searched for the most atypical example, that you're now misrepresenting as 'regular', when it is highly atypical.
And honestly, what would that look like in some 'more normal' language?
Better?I will never understand this fear response some people have to seeing `(fn a b)` instead of `fn(a, b)`.
rowanG077 | 13 hours ago
And yes your example is better, but still terrible. The point is not the formatting. The point is that there is that 10 deep nested code is just not easy to understand. I would also say a line of c/python that does 10 nested function calls as unreadable. But they do not encourage this, whereas with lisp its modus operandi to write such incantation.
Pay08 | 13 hours ago
Provided you don't consider the context, sure. One of them is software with buggy tests, the other is one that provides a custom test suite that basically has to be reimplemented in the package definition. How often do you think either of those things happen?
rowanG077 | 11 hours ago
troad | 6 hours ago
You are projecting a programming style onto Lisps that's quite alien to them. Lisps tend towards small, discrete functions that are composed together. It is the ordinary languages that tend towards deep branching and nesting; Lisps generally favour recursion and function composition instead.
rowanG077 | 5 hours ago
Beside I don't think I'm alien to the functional way of writing things. I write mostly Haskell professionally. But Haskell doesn't casually suffer from making insane expression nesting the default.
globular-toast | 13 hours ago
rowanG077 | 11 hours ago
globular-toast | 11 hours ago
[0] https://www.youtube.com/watch?v=Rou26TpUG0Y
rowanG077 | 10 hours ago
This is not some weird opinion I have. There is a reason "flat is better than nested" is part of the pretty popular zen of Python.
bjoli | 7 hours ago
S-expressions were supposed to be replaced by a more user friendly syntax. The trade offs were not worth it and every try to replace sexprs failed.
If it is such a problem you can use wisp to write your packages.
https://www.gnu.org/software/guile/manual/html_node/SRFI_002...
grumbel | 10 hours ago
That's exactly the part that is wrong with Guix, and Scheme in general. Scheme has associated lists, they are written as '((name . value) ...), but since that's too ugly everybody makes macro wrappers around them to get them down to just (name value). But that means you aren't dealing with an obvious data type anymore, but with whatever the macro produces and if you want to manipulate that you need special tools yet again. And then you have record-type and named arguments which are different things yet again, but all serve the same name->value function as an associated list. Names themselves are sometimes symbols, sometimes keywords, and sometimes actual values. Same with lambda, sometimes you need to supply a function, other times there is a macro that allows you to supply a block of code.
It's like the opposite of the Zen of Python, there are always three different ways to do a thing and none of them as any real advantage over the other, they are just different for no good reason and intermixed in the same code base.
sidkshatriya | a day ago
I am not a fan of S-expressions but using scheme is more reasonable than nix+bash to me.
On the negative side, guix can be slow. It is also not a very pragmatic os. NixOS does non-free firmware and drivers without issue. You need to jump through some hoops for this with Guix. This is not an issue if you plan to run guix in a VM though.
accelbred | a day ago
ulbu | 13 hours ago
https://guix.gnu.org/manual/1.5.0/en/html_node/Inferiors.htm...
accelbred | 3 hours ago
shevy-java | a day ago
My only gripe with NixOS is Nix. I think that this is also the biggest drawback of NixOS. I don't have an alternative; but perhaps it may be better to allow any format to be used, rather than force nix onto everyone.
Another issue is that, for a reason I don't quite understand, a few years ago NixOS' quality appears to have gone down, e. g. nobody cares about documentation anymore. This is probably not a huge obstacle per se, but I did not feel I should invest that much into nix (which I dislike) when the documentation leaves a lot to be desired. Ironically this also means that the whole idea behind NixOS, falls flat, if the documentation is poor. They really should make the same guarantees for their documentation, just as they do for the software ecosystem too.
Nobody cares about documentation anymore though - AI has won. Just try finding high quality documentation via google search; it is slop world now.
ocimbote | a day ago
I'm tempted to give it a shot, with the extra bonus that I've never dabbed with a fedora-based distro.
ydj | a day ago
I also tried fedora coreos for a vm + container host, but found the recommended method to configure the system with ignition files and one shot systemd units to be too involved for making a one off system, and it’s probably better for a cloud deployment with many identical nodes.
Pay08 | a day ago
et1337 | 15 hours ago
But I can’t say I recommend it for dev work. It wants you to do everything inside devcontainers, which I like in theory but in practice come with so many annoyances. It wants you to install Flatpaks but Flathub is pretty sparse. I ended up downloading raw Linux binaries into my home directory (which actually works surprisingly well. Maybe this is the future, hah)
I think next time I’ll just go with vanilla Fedora.
sidkshatriya | a day ago
> There is also community-maintained support for FreeBSD, though I have not used it personally
I have tried to use the nix package manager on FreeBSD recently. I tried doing some basic things without success. Seems quite broken and unusable, which is a pity because nix on macOS seems decent. FreeBSD is much closer to Linux so there is no technical reason why nix can't be a success on FreeBSD.
nix on FreeBSD just needs more contributors to fix bugs and make popular packages work ! I wonder if it will ever happen. FreeBSD is niche and nix is somewhat niche (still). It's a double niche problem !
copirate | a day ago
sirtimbly | 23 hours ago
rgoulter | 19 hours ago
Using Nix for per-project development dependencies is quite good. It's nice to be able to return to a project & not have to fuss over which tools/libraries need to be installed.
alembic_fumes | 23 hours ago
I've been using Nix, both the package manager and the operating system, for years by now. I agree with all of the author's points, it really does deliver, the declarative nature is superb, and there's this constant sense of "hey my stuff is not breaking by itself" when working on it. And it's that declarative, rollback-able, file-based foundation, that makes it the perfect operating system for telling a coding agent to go to town on.
Would I trust Claude to switch my audio stack from Pulseaudio to Pipewire on Ubuntu? Would I trust Codex to install Hyprland on Fedora so I can test out the session? No, in fact I would not trust any agent to do any of those things on any other operating system. But I would trust even goddamn Grok to do that on NixOS, because I can 1) audit the changes before anything is done, and 2) rollback, rollforward, roll-whatever-the-way-I-want-even-on-the-floor-if-I-want-to because of the years of built up confidence proving that IT JUST WORKS.
I concede that this is turning into an unhinged loveletter to Nix, but really, it's the only operating system that lets one operate with this level of confidence. And I know most people don't care about that, since most people don't usually bother to tweak their OSes or switch out window managers, but as someone that does that, I'm never going back to mutable distros. This security is my table-stakes now, and the others aren't willing to pay up.
So for the developers out there on the lookout for their "Year of the Linux Desktop 2026" -distribution, if you're already using AI assistants, give NixOS a try. Maybe start with this in an empty Git repository: "Hey Claude, I wanna try NixOS. Make me a Flake-based starter config using Gnome that I can demo in a virtual machine. If nix isn't yet installed, install it via determinate-systems installer. Include a "vm" target in the flake for building the image, and a small bash script that builds and launches the VM using whatever virtualization is available on my platform."
sshine | 22 hours ago
But trying to set up an environment for one of those perpetually running AIs, and asking it to refactor its own configuration according to some of the high-level abstractions like dendritic flake-parts, and so on, it's just clueless and will improvise without success.
What makes Nix hard for humans also makes Nix hard for AIs: Untyped lambdas that get resolved in some implied out-of-file context means you have to know if you're looking at a NixOS module, a home-manager module, a nix-darwin module, a flake-parts module, and so on. And those modules may make assumptions about what's imported in the parent scope.
So I feel like you need to supply a rather extensive context for your project that details how you want things structured, because the ecosystem is quite fragmented, people don't fully agree on what good patterns are, and so the AI can't know what the good patterns are.
Just to be absolutely clear: I think that supplying an extensive context is absolutely worth it, and I'm having great joy and success building better Nix-based project templates, Nix-based deployment templates, etc. The amount of stable, well-made projects made by other Nix users is just amazing.
piyh | 22 hours ago
sshine | 9 hours ago
https://simonshine.dk/articles/hugo-static-site-setup/
https://simonshine.dk/articles/vendoring-hugo-themes-with-ni...
My blog is deployed here:
https://github.com/sshine/nix/blob/main/services/nginx.nix#L...
xmcqdpt2 | 9 hours ago
I'm sure Nix is better, I just haven't needed it yet.
sshine | 8 hours ago
Since Nix requires a declarative configuration, you need less discipline, but more up-front specification. For example, making truly idempotent Ansible scripts requires a lot of effort and some strong assumptions about your starting state and what processes piped changes into your state, and what your state changes really mean. Also, running your playbook with newer version of the same software may lead to a different result. For example, migrating from bullseye to bookworm with a cargo-deb that contained dependencies: It turned out that there were implied dependencies taken for granted in bullseye that were removed in bookworm. With Nix this will lead to a build error rather than a deployment error or a runtime error (in most cases).
Nix requires fewer assumptions.
> my entire ansible playbook makes server creation a 3 min process
I'm a big fan of Ansible, and everything has its use.
I like to categorize deployment tools as either "bottom-up" or "top-down" depending on what assumptions you make about the world: Ansible fills the slot where you have no control of how the server got there, but you gotta make use of what you have, and start from scratch. Terraform is the canonical bottom-down tool: You assume you have perfect control of what gets provisioned, and that it won't go away or go out-of-sync without active maintenance.
In this top-down/bottom-up topology, Nix can fill the whole spectrum; most people assume Nix/NixOS is available to them, at which point their automation starts. Others deploy NixOS via various automated processes that can be integrated with both top-down or bottom-up solutions, e.g. distribute via network boot, VM image repository, or via "hostile takeover" (deploy on existing Linux machines via SSH, like Ansible, or using Ansible).
nullbyte808 | 14 hours ago
arianvanp | 13 hours ago
redrove | 2 hours ago
mastermage | 13 hours ago
sshine | 9 hours ago
But the cut-off point in model / harness quality before it hallucinates everything but the general Nix syntax is staggeringly low.
1una | 12 hours ago
bojo | 21 hours ago
I knew my flake setup could be better but never bothered. Then one day earlier this year I threw Claude at it. Not only did it improve everything, it fixed a small bug that had been bothering me.
My confidence in doing this came from exactly what you said: If it blows everything up I can just rollback.
aquariusDue | 21 hours ago
christophilus | 21 hours ago
wasting_time | 19 hours ago
Immutability and rollbacks are merely nice side effects of the Nix model.
cjbgkagh | 20 hours ago
Nix and AI is a match made in heaven and I think we’re going to see a lot of good software that’s amenable for us by AI that is both cheaper to build and easier to use.
flkiwi | 20 hours ago
I had Claude do the grunt work of shifting parts of my config to a new structure I started but didn't have time to fully implement.
Based on examples I provided, I had Claude use specialisations to set up a couple of different WM and DE test environments.
And the thing is that, now that I have everything set up the way I want, I don't really have to DO anything to keep the system running, other than occasionally update (I'm on unstable, so I do that manually).
Could I turn Claude loose on my .config directory, give it access to apt or dnf (etc.), and let it set up a non-NixOS environment for me? Probably, and it would probably work reasonably well, but I wouldn't trust it the way I trust NixOS.
mikepurvis | 17 hours ago
Anyway, it turns out this is a perfect setup for an AI bot to step in: it's got all those forum posts to learn from and it's endlessly patient when it comes to just figuring everything out from the source code.
arikrahman | 20 hours ago
tacon | 19 hours ago
wasting_time | 19 hours ago
Hey now, LLMs are pretty good at Guix, too.
ews | 3 hours ago
geddawm | 18 hours ago
Even messing with stdenv or language builders is trivialized. Any software that I want, I can get within a few hours of claude/codex just spinning unsupervised. It's so nice! Underrated for sure.
mikepurvis | 17 hours ago
Iron_Ninja5 | 17 hours ago
riquito | 17 hours ago
wasting_time | 16 hours ago
wasting_time | 16 hours ago
Reverting changes are guaranteed to not leave behind any cruft, and you don't have to remember what you changed to make X or Y work: it's all visible in the (usually version controlled) system configuration.
Got a new computer? Just copy the configuration and enjoy a bit-identical system in seconds. Have an LLM tweak it and see the changes in the form of git diffs.
Sure, you can do the same with Silverblue and writing Ansible for everything, but it's not free of side effects (unlike Nix).
squiggleblaz | 13 hours ago
Not an argument against using NixOS - I think the bridge device issue could reasonably be regarded as a bug rather than a fundamental design issue, and the user id/username mapping is a totally reasonable design decision which can be taken into account by forcing the user id numbers anyway.
kokada | 9 hours ago
One reason to set `mutableUsers = false`: https://mynixos.com/nixpkgs/option/users.mutableUsers.
> And if you activate and enable incus, for instance, it will probably create a bridge device: the device will remain in place after you remove incus, which will have implications for how your network/firewall works that your configuration will depend on but will not enforce or be able to reproduce.
Impermanence: https://github.com/nix-community/impermanence.
To be clear, I don't use neither. But you can get NixOS to be almost completely stateless (if this is something you care) with a few changes. The power is there, but it is disabled by default because it is not the pragmatic choice in most cases.
diffeomorphism | 12 hours ago
Rollback is already very easy with filesystem snapshots. Configs are already tracked by etckeeper. New laptop: either copy the whole drive or the package list and dotfiles. Also, how often do you have to get new laptops for this to be relevant ?
Phlebsy | 16 hours ago
NixOS gives you that just by opting in to using it, and while AI also speeds up config changes and translating your existing knowledge to a new tool you're trialing in other distros as well it really shines with NixOS where you don't even have to care what it messes up while you're trying something new. You just revert and you know that nothing that was done to configure that new thing - which likely would have broken your existing configuration on other distros - has persisted.
michaelmrose | 16 hours ago
codethief | 7 hours ago
sidkshatriya | 15 hours ago
(1) Take a snapshot of your current system (snapper+btrfs on Linux, bectl on FreeBSD+ZFS)
(2) Make destructive changes like install a new windows manager, some drivers etc.
(3) If everything worked out well, continue
(4) If something failed badly, restore from (1) using the snapshot restore -- Your system is as good as before
This workflow replicates many of the benefits of NixOS without the complex nix scripting that can be often needed.
Of course, a declarative and textual rendition of the configuration is better than bash commands entered on the command line but sometimes you don't need that level of precision.
computably | 15 hours ago
exitb | 15 hours ago
sidkshatriya | 13 hours ago
But note that I did caveat my suggestion: "Of course, a declarative and textual rendition of the configuration is better than bash commands entered on the command line but sometimes you don't need that level of precision."
arianvanp | 13 hours ago
There is no distinction between package maintainers and end users. They have the same power.
In the meantime i dont expect Debian users to ever write a package themselves or to modify one.
In nixOS you do it all the time
sidkshatriya | 13 hours ago
# clone the package definition
$ fedpkg clone -a <name of package>
$ cd <name of package>
# install build dependencies
$ sudo dnf builddep ./nameofpackage.spec
# Now add your patches or modifications
# now build the package locally
$ fedpkg local
# install locally modified package
$ sudo dnf install ./the-locally-built-package.rpm
arianvanp | 12 hours ago
Let me put it differently. The documentation of NixOS treats package maintainers and users as kind of equal.
This has benefits and downsides. Benefit is that everyone is treated as a power user. Downside is that power users are horrible at writing docs and this philosophy is my main theory why NixOS docs are so .... Bad
Fedora (and RHEL) end user and developer docs are written for quite different audiences
squiggleblaz | 12 hours ago
(As for why the docs are so bad, I think it's because of the lack of good canonical documentation. There's too many copies of it. Search engines ignore the canonical version because it's presented as one giant document. Parts of the system aren't documented at all and you have to work out what you've got by reading the code. The result is that you have no idea what to do if you want to improve the situation - it seems like your best option is to create new documentation. And now you have the same basic level of documentation that didn't help the first hundred times it was rewritten. And I don't really think submitting a PR to nixpkgs is exactly userfriendly, so it probably discourages people from doing the "I'm just trying to understand this, so I'll fix up the documentation as I learn something" thing.)
dezgeg | 12 hours ago
squiggleblaz | 12 hours ago
You're in no way bound by decisions of the nixpkgs contributors: as you say, we can add a patch. Or we can also decide we totally disapprove of the way they've configured such-and-such a service and write our own systemd service to run it.
Anyone can write a local debian package which adds a patch, and build and install it. And anyone can write a systemd service and use it instead of the distribution's systemd service. But on NixOS, these are equal to the rest of the system rather than outside it. Nixpkgs is just a library which your configuration uses to build a system.
pkulak | 14 hours ago
sidkshatriya | 13 hours ago
jama211 | 16 hours ago
People who get bogged down by the details of examples/analogies are usually missing the point of why people use examples/analogies.
pkulak | 14 hours ago
programs.hyperland.enable = true
is your dnf equivalent on nix. But nix also lets you declare all your key bindings, load Noctalia with systemd, etc.
nullbyte808 | 14 hours ago
kllrnohj | 6 hours ago
And, critically, at no point does an LLM ever have access to sudo, shell, etc.. It just works with plain text files that aren't even on the machine I'm deploying it to.
charlieflowers | 15 hours ago
squiggleblaz | 15 hours ago
But it isn't necessary. You can certainly make a change and apply it without committing it to git or relying on a CI/CD pipeline to deploy it. And it isn't necessary to use input pinning - if you don't, you can wind up making it at best archaeological work to rollback. Most people recommend flakes nowadays though, whose input pinning and purity rules should prevent any need for archaeology if you do commit before applying.
orbital-decay | 14 hours ago
Automating my homelab config with coding machines not only hides the jank, but also makes NixOS feel like some actual agentic OS Microsoft wants, or rather an ad-hoc prototype. I literally just tell it what to do and describe issues if I have any. But again I have written a ton of Nix previously and I'm able to verify what it does, most of the time it's correct but it's not perfect.
nullbyte808 | 14 hours ago
vim-guru | 12 hours ago
woile | 11 hours ago
conradev | 6 hours ago
Coding agents actually help with a lot of the ergonomic issues. If you have an evaluation issue, it can be annoying to climb into nixpkgs to diagnose it. But codex will do that for you.
I’ve found agenix in particular to be really great addition for agents: secrets you can copy around without risk of accidental disclosure.
In a day I can now deploy Caddy, Authentik, Fleet, Headscale, Stalwart, jmap-webmail, Forgejo, SFTPGo, Immich, Grafana, Jaeger, PostHog, etc. and have them all work together. I can do this on a tiny VPS, and codex can actually estimate and test performance to minimize cost.
The equivalent Kubernetes setup wastes so much on isolation and a scheduler that is overkill for anything small.
dewey | 23 hours ago
My first impression after a week of using:
- I really dislike the complexity of terraform, and this is very similar
- The UX is pretty bad, the commands and flags are hard to memorize and you basically need a shell alias for any regular commands to clean them up
- The commands you run regularly like applying your nix config to the system after adding some new packages or config options look like: "nix run nix-darwin -- switch --flake /Users/philipp/repos/github.com/dewey/nix#private"". The output is a mix between expected warnings and way to verbose for something that should essentially be the equivalent of "brew update / brew upgrade".
I'll stick with it as I didn't find anything better and LLMs are great for building up the config over time, but there's definitely room for some improvements.
rounce | 11 hours ago
the_real_cher | an hour ago
rkomorn | an hour ago
sdsd | 22 hours ago
globular-toast | 13 hours ago
SirHumphrey | 12 hours ago
gradstudent | 20 hours ago
On the one hand, it's great, as so many others here and TFA have attested. Declaratively specifying your system configuration and using snapshots to keep track of everything is a complete game-changer. Similarly great is the absolutely huge universe of installable packages. The coverage here is so much better than what's on offer from Ubuntu or Fedora.
On the other hand, the current implementation is still a bit of a shit-show.
First, there's nix-the-OS and nix-the-package-manager which is pretty confusing. Effectively it means you manage your OS with one declarative system and your local/home config with another. Then there's "Flakes" which I never quite understood, that seem to offer a different modality altogether.
Second, installing packages is nice, but also confusing. Do you install a package or a service? Often both are available and the difference is not always clear. Eventually I learned to choose a service whenever one was available. In either case, the tendency of package maintainers is to install the smallest possible version of whatever you asked for. For example, I wanted KDE but what I got was a bare minimum version with plenty of missing apps and functionality that could only be fixed by adding extra components, one at a time, after debugging whatever was currently breaking.
I appreciated that services and packages can be configured in the configuration file. But the options exposed are usually a partial set of what's available -- without extending the installations scripts yourself. So now my "declarative" config is a mix of what's in my nixOS config file and what's in my manually edited /etc files.
Third, the documentation, mentioned by others, is a mess. There's all kinds of information about old and new versions. The interfaces of the command-line tools seem to have changed between the 25.05 stable that I chose and the then-upcoming 25.11, which made following-along harder than it needed to be.
I eventually gave up because I needed a working machine and not a new hobby. I was left with the impression that NixOS might be a good choice for system admins, but perhaps not yet ready for desktop Linux users.
zamalek | 19 hours ago
> there's "Flakes" which I never quite understood
Nix never clicked for me until I started using flakes. There's a lot of internal drama surrounding them that honestly childish; that's why they are marked as experimental and not the official recommendation. You are going to have a worse time with Nix if you go with the official recommendation, flakes are significantly more intuitive. The Determinate Systems installer enables them by default, and whatever documentation they have is on the happier path (except for FlakeHub, I haven't figured that one out yet).
On the most fundamental level, flakes allow you to take /etc/nixos/nixos.nix (or whatever, it has been forever) out of /etc and into a git repository. Old-style nix may be able to do that, but I discovered flakes before trying. I did previously attempt to use git on /etc/nix, but git was falling to pieces with bizarre ownership problems.
What this means is that I could install and completely configure a machine, once booted into a nix iso, by running: nixos-install --flake https://github.com/.../repo.git. I manage all of my system config out of /home/$user/$clone
As for /home there is home-manager and, again, you are not steered towards it (the tutorial pushes you towards nix profiles/nix-env instead). Home-manager will do for your home directory what the system config does for your system, and has many program modules. You can even declare home-level systemd units and whatnot.
> manually edited /etc files.
You can use environment.etc for these files[1]. systemd.tmpfiles can be used for things outside of etc. Home-manager has the equivalent for .config, .local, .cache. [2].
[1]: https://search.nixos.org/options?channel=unstable&query=envi... [2]: https://home-manager-options.extranix.com/?query=xdg.configF...
gradstudent | 18 hours ago
throwawayqqq11 | 11 hours ago
rgoulter | 19 hours ago
Flakes do 2 things:
1. Declaration of the inputs and outputs of some Nix codebase. 2. Pinning the versions of this input sources.
The dependency pinning is similar to package.json/package.lock etc. which are common in language-specific package managers.
sharts | 17 hours ago
smrq | 16 hours ago
https://discourse.nixos.org/t/how-to-manage-dotfiles-with-ho...
> Hi, I just wanted to know, where can I find the documentation to know more about this contrib.lib.file.mkOutOfStoreSymlink option ?
> Well, since is a very simple function, no documentation is really needed.
I've been gradually transitioning everything to NixOS, starting with my homelab mini PC, then my Framework laptop, and now my daily driver desktop. It's hard to imagine going back because the pros are so strong compared to the cons, but the docs situation is truly dire.
laserbeam | 13 hours ago
It’s a solid os, and I’m enjoying it, and I love that I can’t break things while tweaking. But the docs are and discussion threads are not written for beginners (it’s really hard to write for beginners).
zamalek | 19 hours ago
You can set dconf settings more declaratively: https://tangled.org/jonathan.dickinson.id/nix/blob/7c895ada8...
Havoc | 19 hours ago
It took me less than a day of experimenting with it to learn that it is one place only in theory.
The second you start googling „how do I install xyz“ you discover there are also flakes. And others have some sort of convoluted git like method. And there is a package manager thing. And the direct config file editing like in this article. And a disposable temp install of some sort. And naturally software guides don’t give you instructions for all - they’re opinionated.
Felt a lot like being on Debian and the software only comes in .rpm
That really took the wind out of my sails because like OP I liked the basic config file part
Hasnep | 14 hours ago
If I'm running a package on a server that means I want to install it declaratively, so I find the name of the package in Nixpkgs and put it in my `configuration.nix` file. I'm using flakes, but the configuration is exactly the same, I just put the package in the output section of the flake. Any instructions you see to install a package just boils down to finding the name of the package. To me this is as simple as finding the name of a Debian package and running `apt` to install it.
If you want additional features there are other optional ways to install packages, but these are features other distros don't offer, so if you just ignore them then there's no extra complexity compared to Debian for example.
bivlked | 15 hours ago
rounce | 11 hours ago
FinnKuhn | 11 hours ago
baalimago | 14 hours ago
Web3, Rust, NixOS. The holy trinity of cult-like appreciation. I do wonder what brings forth such fanaticism.
globular-toast | 13 hours ago
baalimago | 13 hours ago
In the case of a fire, I'm sure you wouldn't prioritize your laptop with NixOS over your cat (let's imagine that the only backup is in the house that's on fire).
globular-toast | 12 hours ago
baalimago | 10 hours ago
globular-toast | 9 hours ago
kgwxd | 9 hours ago
abdullin | 13 hours ago
Nowadays I love it, since I can let Codex manage the servers for me.
“Here is the flake, here is nix module for the server, here is the project source code. Now change all of that so that wildcard certificates work and requests land through systemd socket on a proper go mux endpoint. Don’t come back until you verify it as working”
5 minutes later it came back.
russellclare | 11 hours ago
marcosscriven | 10 hours ago
I see an article like this about how great it is, think I might try it, then go down a rabbit hole of all the horror stories, and then give up before starting.
iamcalledrob | 10 hours ago
Declarative, but not trying to solve for the "I want 5 versions of python at the same time" problem. The weird NixOS filesystem is where 90% of my Nix issues come from. And I don't feel like I benefit from it much, if at all. Bonus points if this fictional solution doesn't use a fancy new programming language. Something like HOCON would be perfect.
I just want the same OS, packages and config on all my machines without allowing long-term drift. And I want the time I spend tweaking my Linux setup to be an investment, not a waste of time that gets thrown away when I upgrade. I know I could use home-manager or similar for my user-level config, but that's not enough.
I've been experimenting with the immutable fedora-bootc images and podman+Containerfiles, which works pretty well for this. But there's no "nixos-rebuild switch" command, so changes require a reboot. Fine for daily use, but very painful when experimenting. I did discover its possible to use the older dnf4 --transient flag to temporarily install packages, which is helpful.
I guess its a trade-off between easy tinkering (Nix) but frustrating filesystem vs fussy tinkering (bootc) but standard linux filesystem once booted.
CafeRacer | 5 hours ago
However, AI is a great fit to write flakes. You can easily understand the generated code and it gives a power to "review" the changes before applying them.
And while nixos is amazing, I think nixpkgs are a bit overhyped; I've encountered many packages that are abandoned and outdated.
I can share my configs if anyone is interested.
jkl5xx | 3 hours ago
jmmv | 4 hours ago
The language is "interesting" and I haven't had to learn it in depth yet. Claude and Codex really make it easier to get started with Nix's weirdness -- but that's unfortunate because I feel I'm not going to learn the "real thing" otherwise. And this difficulty makes me curious about Guix though because, even though I'm not LISP expert either, at least I can read it.
Anyway. I'm just shy to "dig deeper" on NixOS because my servers are FreeBSD and I'm already feeling the temptation to swap them with NixOS, which would feel like a betrayal to these long-lived installations... ;-P
tombert | 4 hours ago
I found that this gives a good compromise of being able to learn Nix relatively well, but still having a "tutor" to help when things get tricky. I'm reasonably ok at Nix now, and can generally figure out what I need to do without AI assistance, but I'm glad I had ChatGPT when I was getting started with it.
brungarc | 4 hours ago
fridder | 3 hours ago
pouetpouetpoue | 2 hours ago