NixOS and my descent into insanity(ersei.net)
ersei.net
NixOS and my descent into insanity
https://ersei.net/en/blog/its-nixin-time
119 comments
I agree that NixOS (and Nix) is difficult to learn and the documentation is generally poor, which I realise is what you’re getting at in your comment,
But I do think we should keep in mind what an incredible project NixOS is. NixOS isn’t just some other Linux distro, repeating pretty much what every distro has done for 40 years. It’s a complete rethink of how a Linux distribution and package manager should work, from first principles, in a way that I don’t think has ever been done before. That’s an incredibly bold thing to do. That alone, as a research project, would be an impressive achievement. But it hasn’t just ended up as some researcher’s PhD thesis. It works in the real world, and it’s built a large community despite its learning curve.
So despite the terrible docs and UX, I have trouble agreeing that it “sucks”!
But I do think we should keep in mind what an incredible project NixOS is. NixOS isn’t just some other Linux distro, repeating pretty much what every distro has done for 40 years. It’s a complete rethink of how a Linux distribution and package manager should work, from first principles, in a way that I don’t think has ever been done before. That’s an incredibly bold thing to do. That alone, as a research project, would be an impressive achievement. But it hasn’t just ended up as some researcher’s PhD thesis. It works in the real world, and it’s built a large community despite its learning curve.
So despite the terrible docs and UX, I have trouble agreeing that it “sucks”!
Oh, I agree. It's why I put up with NixOS. I love what I can accomplish with it. It's a tool for making your own distro. It basically makes the impossible possible. What I'd like to see now is to make the difficult things easy.
The new installer is pretty great. My son’s desktop got hosed recently from ignoring updates and getting too far behind, so I used the visual Nix installer to put a Gnome desktop on there for him. He installs everything from Flathub anyway, so he hasn’t even noticed. Every once in a while I’ll hop on and update it. Silverblue would work about as well, I’d imagine.
It would probably function way smoother if it didn't have to be built on top of Linux. But then nobody would use it, of course.
The dystopian future of OS dev: Linux, Linux, Linux
I get that backwards compatibility is really important, but still. Gotta be POSIX compatible at least or else next to no one is going to use it as a daily driver.
For example:
> Coming up with a custom shell language was fun, but ultimately does not solve any real problems for us.
> Having a POSIX compliant shell would allow us to, well, run POSIX shell scripts. (This currently requires installing a 3rd party shell.)
https://github.com/SerenityOS/serenity/issues/6847
Where's some variety? I hope to get into the field myself eventually, so maybe I should take it upon myself to create interesting things that might be useful.
I get that backwards compatibility is really important, but still. Gotta be POSIX compatible at least or else next to no one is going to use it as a daily driver.
For example:
> Coming up with a custom shell language was fun, but ultimately does not solve any real problems for us.
> Having a POSIX compliant shell would allow us to, well, run POSIX shell scripts. (This currently requires installing a 3rd party shell.)
https://github.com/SerenityOS/serenity/issues/6847
Where's some variety? I hope to get into the field myself eventually, so maybe I should take it upon myself to create interesting things that might be useful.
> It’s a complete rethink of how a Linux distribution and package manager should work, from first principles, in a way that I don’t think has ever been done before.
Not just Linux but the OS in general.
Not just Linux but the OS in general.
I'm currently trying (and failing, lol) to switch to Nickel Nix. Nix OS/Pkgs is just amazing, but i'm near being entirely done with Nix Lang. Lazy + Dynamic is just a recipe for an awful developer experience.
As far as i can tell no one (thus far) has been able to explain a reasonable and concrete way to tell what any given variable is within a Nix source file. `nix repl` works decently for some cases, but many not - since it seems to mostly help you inspect the output of a Nix expression. So hypothetically it could work, but for any given variable you'd have to recreate the entire value/function/etc stack that produced that value in that state.
All around after ~16 months i think i'm finally done with Nix. It's Nickel or the highway for me. Not that i even love Nickel that much, but it's the bare bones of what Nix should have been in my view.
Not sure if it's a hot take or not.. but it feels like you can have Lazy or Dynamic, but never both. The DX is terrible with both.
As far as i can tell no one (thus far) has been able to explain a reasonable and concrete way to tell what any given variable is within a Nix source file. `nix repl` works decently for some cases, but many not - since it seems to mostly help you inspect the output of a Nix expression. So hypothetically it could work, but for any given variable you'd have to recreate the entire value/function/etc stack that produced that value in that state.
All around after ~16 months i think i'm finally done with Nix. It's Nickel or the highway for me. Not that i even love Nickel that much, but it's the bare bones of what Nix should have been in my view.
Not sure if it's a hot take or not.. but it feels like you can have Lazy or Dynamic, but never both. The DX is terrible with both.
What the nix language needs is support for first-class breakpoint instructions.
That is, I ought to be able to do something along the lines of
`let x = break (...)`
The semantics here is that, when x is evaluated (i.e., forced into WHNF), I get placed into a debugger where I can examine the context and either (1) choose to return a new value for `x` or (2) let it fall through and let `x` take on the value of `(...)`. The main issue with nix is debuggability
That is, I ought to be able to do something along the lines of
`let x = break (...)`
The semantics here is that, when x is evaluated (i.e., forced into WHNF), I get placed into a debugger where I can examine the context and either (1) choose to return a new value for `x` or (2) let it fall through and let `x` take on the value of `(...)`. The main issue with nix is debuggability
Yes, anyone who has spent any serious amount of time maintaining Nix code has felt this pain. I also have come to dislike the Nix language, but it was the daily debugging that eventually drove me away. In my case, it was for production systems, and there's nothing more agonizing then having to debug a Nix stack trace on a deadline.
looks like that was added last year: https://github.com/NixOS/nix/blob/4a880c3cc085841a1537040405...
https://www.zknotes.com/note/5970
https://www.zknotes.com/note/5970
Agreed, though i prefer types to solve this - but i imagine what you suggest would even benefit a typed language like Nickel. Really would be a useful inspection tool.
Nix is just a massive blob of difficult to debug code. Really awful experience for me.
Nix is just a massive blob of difficult to debug code. Really awful experience for me.
I tend to agree. I was trying to follow the guide on how to install NixOS with root-on-zfs[0]. I’ve followed it before with my own tweaks just fine, but recently it was updated to include some random guy’s modules that automate a couple steps. They’re mostly shallow abstractions on first-party NixOS modules, but following it was such a pain. I’ve been putting off reverse engineering the guy’s code so I can understand exactly what it’s doing. Apart from the code quality, it would probably be a lot easier to see what was going on in a typed language, with a debugger. Hopefully one day it gets there.
[0]: https://openzfs.github.io/openzfs-docs/Getting%20Started/Nix...
[0]: https://openzfs.github.io/openzfs-docs/Getting%20Started/Nix...
I've been using root on ZFS for two years, but without using a specific module for it. Some info and links here: https://www.reddit.com/r/NixOS/comments/ops0n0/big_shoutout_...
What module do you mean? I didn’t find it in your link.
The repo in step one of this sub-page:
https://openzfs.github.io/openzfs-docs/Getting%20Started/Nix...
For building packages, don't you kind of need it to be lazy? I don't want to compile and install all of nixpkgs.
When you're programming in any old non-lazy language, your functions don't get automatically called, it's only when you put that call in code that's being executed. If you don't mention a thing in your main, that thing has no reason to get executed.
Nix is lazy because the whole point of the original work was "what if package management, but FP". The resulting /nix/store etc system has very little to do with FP and is, in fact, built by imperative bash scripts.
Nix is lazy because the whole point of the original work was "what if package management, but FP". The resulting /nix/store etc system has very little to do with FP and is, in fact, built by imperative bash scripts.
Depends, i imagine like most things - the answer is nuanced, or at the very least depends on the specific other decisions.
For example, i don't see why a configuration would install actual packages - if that's what you mean. Besides, i am not advocating against lazy by itself. I'm just saying that something which is both lazy and untyped is a huge PITA. Nickel adds typing, validation, etc - information, by which you can still have Lazy and a better DX by way of types. At least in theory, i've not used it much.
My biggest gripe is dynamic Nix, fwiw.
For example, i don't see why a configuration would install actual packages - if that's what you mean. Besides, i am not advocating against lazy by itself. I'm just saying that something which is both lazy and untyped is a huge PITA. Nickel adds typing, validation, etc - information, by which you can still have Lazy and a better DX by way of types. At least in theory, i've not used it much.
My biggest gripe is dynamic Nix, fwiw.
> has been able to explain a reasonable and concrete way to tell what any given variable is within a Nix source file
That’s the problem with the anemic and ad hoc libraries nixpkgs uses, not the language. There is a magic buildWhateverXPackage function that needs some magic attributes and you are done. The problem is that there is no interface to aid in how that should be used - but it is the same way in JavaScript as well.
Also, you are writing a description of something, it won’t be a traditional program with an event loop or whatnot - here lazyness does make sense.
That’s the problem with the anemic and ad hoc libraries nixpkgs uses, not the language. There is a magic buildWhateverXPackage function that needs some magic attributes and you are done. The problem is that there is no interface to aid in how that should be used - but it is the same way in JavaScript as well.
Also, you are writing a description of something, it won’t be a traditional program with an event loop or whatnot - here lazyness does make sense.
> As far as i can tell no one (thus far) has been able to explain a reasonable and concrete way to tell what any given variable is within a Nix source file. `nix repl` works decently for some cases, but many not - since it seems to mostly help you inspect the output of a Nix expression. So hypothetically it could work, but for any given variable you'd have to recreate the entire value/function/etc stack that produced that value in that state.
It's certainly not ergonomic, but from what I can tell so far, `builtins.trace` and `builtins.traceVerbose` are about as good as it's gonna get. It quite literally lets you inspect any arbitrary Nix expression, but it's just such a friggin' hassle to wrap things with it & reevaluate just to do what literally any real debugger can do in two keystrokes.
> All around after ~16 months i think i'm finally done with Nix. It's Nickel or the highway for me. Not that i even love Nickel that much, but it's the bare bones of what Nix should have been in my view.
I'm curious. Have you messed around with Dhall? It's suspiciously similar to Nickel (even mentioned on their site), but it's been around longer so it's probably a bit more viable to actually make your config in Dhall. Dhall or Nickel, it'll still insanely janky and more trouble than it's worth. Personally, I've found that what's worked surprisingly well for me is just really focusing on building a good understanding of the Nix language in an effort to avoid needing to debug as much as possible. "Just don't write bugs" as the saying goes. I've been using Nix for a while, and I'm still loath to debug it.
It's certainly not ergonomic, but from what I can tell so far, `builtins.trace` and `builtins.traceVerbose` are about as good as it's gonna get. It quite literally lets you inspect any arbitrary Nix expression, but it's just such a friggin' hassle to wrap things with it & reevaluate just to do what literally any real debugger can do in two keystrokes.
> All around after ~16 months i think i'm finally done with Nix. It's Nickel or the highway for me. Not that i even love Nickel that much, but it's the bare bones of what Nix should have been in my view.
I'm curious. Have you messed around with Dhall? It's suspiciously similar to Nickel (even mentioned on their site), but it's been around longer so it's probably a bit more viable to actually make your config in Dhall. Dhall or Nickel, it'll still insanely janky and more trouble than it's worth. Personally, I've found that what's worked surprisingly well for me is just really focusing on building a good understanding of the Nix language in an effort to avoid needing to debug as much as possible. "Just don't write bugs" as the saying goes. I've been using Nix for a while, and I'm still loath to debug it.
I have not tried Dhall, i should give it a look. Currently i'm exploring transpiling to Nix or possibly type annoations inside Nix. I just need something where the time investment in researching Nix types and sources can actually be reused, rather than forgotten.
edit: ooo, looks like someone made a similar program with Dhall. https://www.haskellforall.com/2017/01/typed-nix-programming-...
edit: ooo, looks like someone made a similar program with Dhall. https://www.haskellforall.com/2017/01/typed-nix-programming-...
Have you tried https://github.com/nickel-lang/nickel-nix ?
I didn't use it yet, but looks like this supposed to do it.
I didn't use it yet, but looks like this supposed to do it.
I've been trying today, looks to be very incomplete. Eventually it may work, but sounds like not now.
I'm now exploring transpiling to Nix lol. I'm moderately dedicated in my distaste of Nix hah.
I'm now exploring transpiling to Nix lol. I'm moderately dedicated in my distaste of Nix hah.
I use uBlue https://universal-blue.org/ with a custom image. It's basically Fedora Silverblue & co, except I can declare my default packages and Flatpaks and stuff in a YML file and then just rebase to the custom image that was built. I use Nix home-manager for configuring my shell and GTK, and plan to do as much with it as possible. It's genuinely one of the most stable feeling Linux systems I've run, especially with the Nvidia drivers being built in the cloud and my computer just getting the latest version automatically. Being Fedora, it's very up-to-date and uses new technologies like Wayland and Pipewire out of the box.
Once Nix can install without disabling selinix, it could be holy grail territory.
I personally moved from UBlue to NixOS because I was a bit bored of running my whole life in Distrobox, and didn’t like being so dependent on GitHub. NixOS gives me everything I liked from Silverblue with the flexibility of something like Arch. Plus, Home Manager is amazing. The big downside of container-based images is that you can never touch your home directory. Now instead of Silverblue plus Chezmoi plus like 7 Bash scripts and a Distrobox, it’s all just one Nix config.
I personally moved from UBlue to NixOS because I was a bit bored of running my whole life in Distrobox, and didn’t like being so dependent on GitHub. NixOS gives me everything I liked from Silverblue with the flexibility of something like Arch. Plus, Home Manager is amazing. The big downside of container-based images is that you can never touch your home directory. Now instead of Silverblue plus Chezmoi plus like 7 Bash scripts and a Distrobox, it’s all just one Nix config.
> You have to learn a new OS because a lot of your prior Linux knowledge no longer applies.
This is what confused me the most.
Nix (CLI tools / language syntax)
NixOS (A Linux distro that has CLI tools, but also some CLI tools that are only available on this distro and not others, aka "nix" doesn't really work on Debian)
Flakes vs "configuration"
I just wanted to like "terraform apply" a system configuration on my Debian install.
People are obsessed with Nix because you can manage your config for their local system
Ok... Ansible has existed for 12 years? And you can use it on Debian/don't need a full OS/distro from the ground up (NixOS)
But people will come out of the woodworks to tell you how you don't understand, you're wrong, you're missing the point, Nix is the greatest.
This is what confused me the most.
Nix (CLI tools / language syntax)
NixOS (A Linux distro that has CLI tools, but also some CLI tools that are only available on this distro and not others, aka "nix" doesn't really work on Debian)
Flakes vs "configuration"
I just wanted to like "terraform apply" a system configuration on my Debian install.
People are obsessed with Nix because you can manage your config for their local system
Ok... Ansible has existed for 12 years? And you can use it on Debian/don't need a full OS/distro from the ground up (NixOS)
But people will come out of the woodworks to tell you how you don't understand, you're wrong, you're missing the point, Nix is the greatest.
Ansible does not even begin to accomplish what Nix does.
I’d be curious to learn more if you could share please
What Ansible does is just one part of the Nix picture. Nix brings a lot more:
- Language agnostic software packaging
- Package manager
- Ephemeral dev environments
- A purely functional config language (it has lambdas - you can build abstractions)
- Closures - Nix knows every single dependency your system needs down to git revisions
- Binary caching. Everything is built from source, but you can safely download binaries that are known to be built from the exact same deps you need.
- Ergonomic cross-compilation
- NixOS modules allow for composable, modular system config. For instance, my home computers all import a shared scanner.nix file that sets up scanner drivers and installs scanner software. Sharing config across machines is so easy with Nix.
- Rollbacks - you can edit your system (even swapping out gfx drivers or the kernel) and if it doesn't work, trivially rollback. As in you can restart your computer and choose to boot into the previous config.
- Easily modify _any_ dependency. You can apply patches, point at a fork, or just tweak its packaging.
- I am surely forgetting stuff! It does a lot.
- Language agnostic software packaging
- Package manager
- Ephemeral dev environments
- A purely functional config language (it has lambdas - you can build abstractions)
- Closures - Nix knows every single dependency your system needs down to git revisions
- Binary caching. Everything is built from source, but you can safely download binaries that are known to be built from the exact same deps you need.
- Ergonomic cross-compilation
- NixOS modules allow for composable, modular system config. For instance, my home computers all import a shared scanner.nix file that sets up scanner drivers and installs scanner software. Sharing config across machines is so easy with Nix.
- Rollbacks - you can edit your system (even swapping out gfx drivers or the kernel) and if it doesn't work, trivially rollback. As in you can restart your computer and choose to boot into the previous config.
- Easily modify _any_ dependency. You can apply patches, point at a fork, or just tweak its packaging.
- I am surely forgetting stuff! It does a lot.
The only way ansible could be somewhat like nix is if you reinstalled the same exact version of the target OS each time before you run your playbook. The problem is that ansible, puppet, salt, chef, et al, are simply tools to mutate the giant bag of state that is a Linux OS. Even then getting to the same end state is a suspect proposition unless you're extremely diligent in pinning things like exact package versions and ensure tasks run in the exact same order every time.
While these tools are good at making certain changes, and are even pretty good at detecting and eliding already-done work, they are _not_ idempotent. There are nearly no modules that properly handle unmaking their changes, so once you mutate that bag of state you're left with a state vector that is barely better than completely undefined.
If you're familiar with these tools you have no doubt deployed undo-this-change tasks that you leave in the tasklist until you're fairly confident it's run on every system the do-this-change tasks ran on. Even if a module does attempt to offer an undo-the-state functionality, you can't just remove it, you have to first configure it to run in the "undo" configuration before you remove it.
While these tools are good at making certain changes, and are even pretty good at detecting and eliding already-done work, they are _not_ idempotent. There are nearly no modules that properly handle unmaking their changes, so once you mutate that bag of state you're left with a state vector that is barely better than completely undefined.
If you're familiar with these tools you have no doubt deployed undo-this-change tasks that you leave in the tasklist until you're fairly confident it's run on every system the do-this-change tasks ran on. Even if a module does attempt to offer an undo-the-state functionality, you can't just remove it, you have to first configure it to run in the "undo" configuration before you remove it.
Not the person that said, but let me try. First, Nix isn't for configuration management, it can do bunch of other things, but even when it comes to configuration management it is still superior to the popular tools:
Ansible/Chef/Puppet/Saltstack
They try to be declarative (following less popular CFEngine) but they are still iterative. Saltstack is closest as originally the order of operation was based on the declared dependencies.
They still ultimately come down to just perform iterative steps, with the difference that operations are idempotent.
The biggest drawback they do have is coming from the fact that they have system with a state and they modify the system state to get selected files/services/packages/etc in new state.
Nix lives up to its name, and when configuration happens it starts from nothing and then builds everything based on the configuration.
The result of it is, let say you use the traditional CM tool to install a package. Then later on you decide the package is no longer needed so you remove "pkg.installed" declaration. What actually happens though is that the existing systems will continue to have the package installed (until you add "pkg.removed"). What's even worse is that any new instance you spin up will not have the package installed, so everything will be drifting. This is the primary reason why there was the immutable system movement. That's all to avoid those scenarios.
In contrast, in Nix, if you remove package from list of installed packages, or you remove file that you declared by nix config, they will be gone from the system. The configuration is basically describing your system.
Now, as mentioned above, that's just one piece of things Nix can do. I primarily use it for reproducible builds I really like that if a package won't build on your computer it probably will fail to build on mine as well (it's something that docker promised, but IMO failed to deliver), but let's stick to configuration management.
Another big thing is that all changes are atomic, you either get your change or the change did not apply due to error, you will not get in a in-between state, like frequently happens with CM.
Another thing is (and what I wrote above is prerequisite for this to work correctly) is that you can do rollbacks. And it works with things that are considered hard. For example NixOS by default use X11, but you can enable Wayland with some configuration changes. Then you can just revert the config back and get back to your old X11 installation.
This also makes system upgrades less dreadful.
Let's say you have your setup, but you need to use different version of openssl or maybe compile it with different flags. In traditional OS you probably would not do that or if there was a vulnerability you would wait for help from vendor as there might need to be multiple packages updated. But if it is something smaller, maybe you need python package, you would build your own version, you would place it in artifactory, then have ansible task to upgrade it on your instances.
With nix you will use overrides[1]. Nix then will see it, and if the compiled version is not in its cache it will pull all dependencies and recompile it automatically then place it in its cache.
If you set up a binary cache yourself (you can either use SaaS solution, or even just set up an S3 bucket) you can have your machines automatically pull the compiled version from it. Nix doesn't care about versions of packages either (the versions are only for the user) instead it uses cryptographic hash generated from things like source code, package dependencies, architecture, compile options, etc) this means if you cache compiled version and modify package to add some other options, it won't accidentally use the other package it will either pull the right one or recompile the code.
[1] https://nixos.org/manual/nixpkgs/stable/#chap-overrides
Ansible/Chef/Puppet/Saltstack
They try to be declarative (following less popular CFEngine) but they are still iterative. Saltstack is closest as originally the order of operation was based on the declared dependencies.
They still ultimately come down to just perform iterative steps, with the difference that operations are idempotent.
The biggest drawback they do have is coming from the fact that they have system with a state and they modify the system state to get selected files/services/packages/etc in new state.
Nix lives up to its name, and when configuration happens it starts from nothing and then builds everything based on the configuration.
The result of it is, let say you use the traditional CM tool to install a package. Then later on you decide the package is no longer needed so you remove "pkg.installed" declaration. What actually happens though is that the existing systems will continue to have the package installed (until you add "pkg.removed"). What's even worse is that any new instance you spin up will not have the package installed, so everything will be drifting. This is the primary reason why there was the immutable system movement. That's all to avoid those scenarios.
In contrast, in Nix, if you remove package from list of installed packages, or you remove file that you declared by nix config, they will be gone from the system. The configuration is basically describing your system.
Now, as mentioned above, that's just one piece of things Nix can do. I primarily use it for reproducible builds I really like that if a package won't build on your computer it probably will fail to build on mine as well (it's something that docker promised, but IMO failed to deliver), but let's stick to configuration management.
Another big thing is that all changes are atomic, you either get your change or the change did not apply due to error, you will not get in a in-between state, like frequently happens with CM.
Another thing is (and what I wrote above is prerequisite for this to work correctly) is that you can do rollbacks. And it works with things that are considered hard. For example NixOS by default use X11, but you can enable Wayland with some configuration changes. Then you can just revert the config back and get back to your old X11 installation.
This also makes system upgrades less dreadful.
Let's say you have your setup, but you need to use different version of openssl or maybe compile it with different flags. In traditional OS you probably would not do that or if there was a vulnerability you would wait for help from vendor as there might need to be multiple packages updated. But if it is something smaller, maybe you need python package, you would build your own version, you would place it in artifactory, then have ansible task to upgrade it on your instances.
With nix you will use overrides[1]. Nix then will see it, and if the compiled version is not in its cache it will pull all dependencies and recompile it automatically then place it in its cache.
If you set up a binary cache yourself (you can either use SaaS solution, or even just set up an S3 bucket) you can have your machines automatically pull the compiled version from it. Nix doesn't care about versions of packages either (the versions are only for the user) instead it uses cryptographic hash generated from things like source code, package dependencies, architecture, compile options, etc) this means if you cache compiled version and modify package to add some other options, it won't accidentally use the other package it will either pull the right one or recompile the code.
[1] https://nixos.org/manual/nixpkgs/stable/#chap-overrides
> I just wanted to like "terraform apply" a system configuration on my Debian install.
I think 'like Terraform, but for the system configuration' is an apt description of NixOS. -- i.e. NixOS is a Linux distribution built around using Nix to generate the system config.
The Nix package manager itself happily works on other Linux distributions. (And on macOS).
> ... Ansible ...
Nix's main focus is on packages. It happens to incidentally do package-related stuff quite well, which is why nix also gets used to declare development environments, build Docker/VM images, or used to configure NixOS.
An interesting set of terms related to Ansible vs NixOS: Ansible is 'congruent', in that it tries to get a system to a desired state by comparing what's there with what it expects. Whereas, NixOS is 'congruent', in that the system is built to be in the desired state.
https://flyingcircus.io/blog/thoughts-on-systems-management-...
I think 'like Terraform, but for the system configuration' is an apt description of NixOS. -- i.e. NixOS is a Linux distribution built around using Nix to generate the system config.
The Nix package manager itself happily works on other Linux distributions. (And on macOS).
> ... Ansible ...
Nix's main focus is on packages. It happens to incidentally do package-related stuff quite well, which is why nix also gets used to declare development environments, build Docker/VM images, or used to configure NixOS.
An interesting set of terms related to Ansible vs NixOS: Ansible is 'congruent', in that it tries to get a system to a desired state by comparing what's there with what it expects. Whereas, NixOS is 'congruent', in that the system is built to be in the desired state.
https://flyingcircus.io/blog/thoughts-on-systems-management-...
> The Nix package manager itself happily works on other Linux distributions. (And on macOS).
But not the "Nix system config manager", which is grouped under the same set of CLI tools, is that right?
> Nix's main focus is on packages.
Packages or system configuration or both?
But not the "Nix system config manager", which is grouped under the same set of CLI tools, is that right?
> Nix's main focus is on packages.
Packages or system configuration or both?
> But not the "Nix system config manager", which is grouped under the same set of CLI tools, is that right?
The `nixos-rebuild` command is what you'd use to apply a NixOS configuration (that's NixOS only). (I believe it's possible to run the command to build a configuration on non-NixOS).
Whereas, the other nix CLI programs are mainly `nix-build`, `nix-shell`, etc. which are now grouped under a single `nix` command.
> Packages or system configuration or both?
I'd say packages.
That people like NixOS for its declarative system configuration is incidental.
Nix's key idea is symlinking everything. You put a package in some directory under /nix/store, where the address is computed from that package's inputs. (e.g. what compiler to use, what compiler flags to use).
If you build the same package with different inputs (e.g. different compiler versions), these packages can exist alongside each other in /nix/store. Nix can then build a PATH using whichever package you want to use. It's able to come up with ~/.nix-profile/bin and ~/.nix-profile/include (and share, etc.), symlinking to the stuff in /nix/store.
NixOS essentially 'just' applies that idea, but symlinks stuff under /etc to whatever /nix/store package has the system configuration. (Plus uses systemd services, and a few other things).
e.g. when I `readlink /etc/hosts`, it resolves to `/nix/store/n5ijm9zzkcm7qglsqrfvnixih0q7dskb-host`, or /etc/fstab to /nix/store/xb7jmzd0wy0wy4vihh0q17m81kmqgc7y-etc-fstab.
The `nixos-rebuild` command is what you'd use to apply a NixOS configuration (that's NixOS only). (I believe it's possible to run the command to build a configuration on non-NixOS).
Whereas, the other nix CLI programs are mainly `nix-build`, `nix-shell`, etc. which are now grouped under a single `nix` command.
> Packages or system configuration or both?
I'd say packages.
That people like NixOS for its declarative system configuration is incidental.
Nix's key idea is symlinking everything. You put a package in some directory under /nix/store, where the address is computed from that package's inputs. (e.g. what compiler to use, what compiler flags to use).
If you build the same package with different inputs (e.g. different compiler versions), these packages can exist alongside each other in /nix/store. Nix can then build a PATH using whichever package you want to use. It's able to come up with ~/.nix-profile/bin and ~/.nix-profile/include (and share, etc.), symlinking to the stuff in /nix/store.
NixOS essentially 'just' applies that idea, but symlinks stuff under /etc to whatever /nix/store package has the system configuration. (Plus uses systemd services, and a few other things).
e.g. when I `readlink /etc/hosts`, it resolves to `/nix/store/n5ijm9zzkcm7qglsqrfvnixih0q7dskb-host`, or /etc/fstab to /nix/store/xb7jmzd0wy0wy4vihh0q17m81kmqgc7y-etc-fstab.
Genuine question: If Ansible on Debian works perfectly for your use cases, why are you checking out Nix/NixOS at all?
I am also mostly an Ansible-on-Debian user, and know for a fact that NixOS has a few things that might be interesting to me in the future. But I don't want to be yet another person "coming out of the woodwork" :) But for a lot of people, Ansible-on-Debian should solve their problems pretty well!
I am also mostly an Ansible-on-Debian user, and know for a fact that NixOS has a few things that might be interesting to me in the future. But I don't want to be yet another person "coming out of the woodwork" :) But for a lot of people, Ansible-on-Debian should solve their problems pretty well!
Prior Linux knowledge still applies and is required, it is just managed differently.
Another language won't change much.
Debian reliability is outside of core packages a myth and Debian has no way to properly migrate configuration. Every major update is a wild rollercoaster ride were things might break in the middle.
Another language won't change much.
Debian reliability is outside of core packages a myth and Debian has no way to properly migrate configuration. Every major update is a wild rollercoaster ride were things might break in the middle.
> Another language won't change much.
Why do you think Guix+Guile isnt a substantial positive change?
Why do you think Guix+Guile isnt a substantial positive change?
Why do you think it is? The problem with Nix is not the language, it is mostly the ad hoc, grown over time “standard library” for packaging programs. It is just hard to know what that magic buildXPackage function does, or sometimes even where it is. You basically have to grep through the nixpkgs repo to find these things.
The language is very small and is a great fit for its domain.
The language is very small and is a great fit for its domain.
NixOS looks like just about the only sane option besides containerizing everything like Snaps and flatpacks, which seems to also suck.
I used to love Linux, about 10 years ago, but it seems to be stagnating.
Stuff basically never breaks on Android, so it's clear you can totally make a computer that actually works. But even mint occasionally has random fussy problems, and so much of the internals are built around manual admin.
I mean, debian packages can randomly decide they need to ask a question during setup!
Plus Nix seems to have modern packages. Other linuxes have a huge repo, but a lot of it is nonsense, unmaintained, or obsolete, or something only of interest to unix fans. With nix ever fairly obscure stuff that normally needs a ppa seems to be there.
I used to love Linux, about 10 years ago, but it seems to be stagnating.
Stuff basically never breaks on Android, so it's clear you can totally make a computer that actually works. But even mint occasionally has random fussy problems, and so much of the internals are built around manual admin.
I mean, debian packages can randomly decide they need to ask a question during setup!
Plus Nix seems to have modern packages. Other linuxes have a huge repo, but a lot of it is nonsense, unmaintained, or obsolete, or something only of interest to unix fans. With nix ever fairly obscure stuff that normally needs a ppa seems to be there.
> with a better language, documentation on par with Arch, and the reliability of Debian.
I grok the first two, but what do you mean about the reliability of Debian?
I grok the first two, but what do you mean about the reliability of Debian?
> NixOS is awful except for everything else out there.
Except Qubes OS that allows using original GNU/Linux distributions virtualized with a convenient interface.
Except Qubes OS that allows using original GNU/Linux distributions virtualized with a convenient interface.
I have enjoyed using Qubes in the past, it's definitely a cool feeling having everything controllable via an abstraction that its author probably wasn't designing for. Feels powerful.
But at the end of the day, those VM images, and any snapshots made, are opaque blobs of bits. Whatever shape they're in, you have nowhere to look to determine why they are the way they are--no recipe for recreating that state and sharing it with others (unless you want to share it ALL with others, and then only with others on the same architecture). You've got a lot of control, but only over these chunks of whatever happened to be there at that time.
You're sort of trapped in one dimension. You can use snapshots to move backwards and forwards in time, but if the following paths don't lead to the same system state in some subtle way you're not going to know about the difference:
path one:
> add foo | add bar | remove foo
path two:
> add bar
But at the end of the day, those VM images, and any snapshots made, are opaque blobs of bits. Whatever shape they're in, you have nowhere to look to determine why they are the way they are--no recipe for recreating that state and sharing it with others (unless you want to share it ALL with others, and then only with others on the same architecture). You've got a lot of control, but only over these chunks of whatever happened to be there at that time.
You're sort of trapped in one dimension. You can use snapshots to move backwards and forwards in time, but if the following paths don't lead to the same system state in some subtle way you're not going to know about the difference:
path one:
> add foo | add bar | remove foo
path two:
> add bar
> no recipe for recreating that state and sharing it with others
Did you consider to use the Salt Stack, which is integrated into Qubes? https://forum.qubes-os.org/t/saltstack-challenges-and-experi...
Did you consider to use the Salt Stack, which is integrated into Qubes? https://forum.qubes-os.org/t/saltstack-challenges-and-experi...
No, I was using Qubes in 2019 before that integration occurred. That does seem like it would scratch the itch.
Do Qubes users treat Salt Stack formulae as packages these days?
Do Qubes users treat Salt Stack formulae as packages these days?
Not precisely, but a lot is going on in this direction: https://github.com/QubesOS/qubes-issues/issues/1939.
And what exactly do you run as those distributions? They will have all the same problems.
That’s the same idea that Docker has — containers don’t solve packaging, they only push the problem down a layer.
That’s the same idea that Docker has — containers don’t solve packaging, they only push the problem down a layer.
Which the same problems? For example I do not worry that something can be broken, because I have, e.g., automatic system snapshots and dedicated VMs for testing.
I run Fedora and Debian, but you can run many other distros: https://www.qubes-os.org/doc/#operating-system-guides.
> they only push the problem down a layer
This is an interesting interpretation. For me Qubes fully solves, e.g., both the problems of system stability and flexibility.
I run Fedora and Debian, but you can run many other distros: https://www.qubes-os.org/doc/#operating-system-guides.
> they only push the problem down a layer
This is an interesting interpretation. For me Qubes fully solves, e.g., both the problems of system stability and flexibility.
I don’t associate convenience and QubesOS. Maybe convenient security, but thats about it.
Security is just one feature of Qubes OS. Another one is convenient separation of contexts. Works well for me: you do not see VMs but colorful windows with simple exchange of clipboard and files whenever needed.
I am curious, what is inconvenient in it for you?
I am curious, what is inconvenient in it for you?
I can now see why someone's quipped that the promise of NixOS is that "it will change everything but mutate nothing".
Le sigh, another day, another group of people turned off on NixOS for completely legitimate learning curve, documentation, and support reasons that are nonetheless heartbreakingly fixable. It’s never the user’s fault.
Home manager is a well-intentioned and technically well-executed piece of software that is nonetheless a disaster as the “how to do dots on Nix” story, especially for newcomers. We need “Home Manager Light” or something.
I’m a fucking serious Nix-head and I procrastinate doing anything serious to my dots like getting a root canal.
Home manager is a well-intentioned and technically well-executed piece of software that is nonetheless a disaster as the “how to do dots on Nix” story, especially for newcomers. We need “Home Manager Light” or something.
I’m a fucking serious Nix-head and I procrastinate doing anything serious to my dots like getting a root canal.
On the contrary for me, playing around with nix and nixos is how I procrastinate everything. It's incredibly effective.
My favorite was going through the Nix reference manual. Section 4.2, Profiles
> If the profile doesn’t exist, it will be created automatically.
Nope! If it doesn't exist then running the commands this tells you to will bork your installation completely, and unrecoverably with the knowledge you have gained up until that point in the book, at least without starting from scratch again.
Search for issue - closed in 2018, wontfix as "It's documented correctly and quite clearly." by someone who apparently didn't read or understand that the literal reference manual tells people to break their installation.
I have never touched Nix/NixOS since, because clearly they don't want or need people without 100% of their lives to dedicate themselves to it.
> If the profile doesn’t exist, it will be created automatically.
Nope! If it doesn't exist then running the commands this tells you to will bork your installation completely, and unrecoverably with the knowledge you have gained up until that point in the book, at least without starting from scratch again.
Search for issue - closed in 2018, wontfix as "It's documented correctly and quite clearly." by someone who apparently didn't read or understand that the literal reference manual tells people to break their installation.
I have never touched Nix/NixOS since, because clearly they don't want or need people without 100% of their lives to dedicate themselves to it.
I find nix incredible but the thing that I struggle with is trying to figure out how to do things on nixpkgs, and home manager in particular while not using nixos.
This is a critical use case for the apprehensive crowd like me who is averse to distro hopping, let alone willing to take on the paradigm shift of Linux-to-nixos.
The documentation for either is all but non-existent and the pages I can find are glorified source or man pages. Given how scalable nix, in the right use case, can make things, that's just not the modern experience it should or could be.
This is a critical use case for the apprehensive crowd like me who is averse to distro hopping, let alone willing to take on the paradigm shift of Linux-to-nixos.
The documentation for either is all but non-existent and the pages I can find are glorified source or man pages. Given how scalable nix, in the right use case, can make things, that's just not the modern experience it should or could be.
I completely agree. I'm also trying to wrap my head around Nix on a non-NixOS system. My requirements are to just manage my dotfiles (successful with home-manager) and configuring my system/installing certain packages, so everyone on the host can e. g. start a docker container with Docker installed by Nix. Ideally all with flakes.
I suppose, I can't have the second part without NixOS, though ...
I suppose, I can't have the second part without NixOS, though ...
I like YADM for managing my dot files and expect that even if I switched to NixOS, I would keep using it because it works well and I have no complaints about it.
> There is one notable exception to programs I am not managing with home-manager, and that's SSH. Although it's pretty easy to use home-manager to manage SSH configurations, I'd prefer the security-through-obscurity of people not knowing my SSH aliases (since, y'know, I'm making my nix configuration public).
Tip I use for this:
End your ~/.ssh/config with Include ~/.ssh/config.local . Write ~/.ssh/config with whatever you're happy being public. Write your aliases into ~/.ssh/config.local. SSH will just ignore it if it's missing.
Tip I use for this:
End your ~/.ssh/config with Include ~/.ssh/config.local . Write ~/.ssh/config with whatever you're happy being public. Write your aliases into ~/.ssh/config.local. SSH will just ignore it if it's missing.
> At this point I had a home.nix that spanned a couple of thousand lines. This is a bad idea, mostly because it's hard to manage.
This has also been my experience with home-manager. The promise is great - it's like DLC for Nix that just Does More™. Then you get into it, and realize the modules are a lot more fragile and most of them are outdated. Then you're a few hundred lines in with workarounds, DBUS declarations and all sorts of declarative ricing and go "is it worth it?".
Since then I just removed all the home-manager stuff and relied on NixOS' native config. Things are much more stable and easier to define, and I haven't found a whole lot of things that are truly undoable without it. It's slower and non-declarative, sure, but my sanity is all the better for it. I hope I'm not the only one out there.
This has also been my experience with home-manager. The promise is great - it's like DLC for Nix that just Does More™. Then you get into it, and realize the modules are a lot more fragile and most of them are outdated. Then you're a few hundred lines in with workarounds, DBUS declarations and all sorts of declarative ricing and go "is it worth it?".
Since then I just removed all the home-manager stuff and relied on NixOS' native config. Things are much more stable and easier to define, and I haven't found a whole lot of things that are truly undoable without it. It's slower and non-declarative, sure, but my sanity is all the better for it. I hope I'm not the only one out there.
Sad to see the Nix team can't get UX right.
Their technology is on point.
Their technology is on point.
There's a massive push to improve UX but it'll take time for things to happen and it's only really just in the last few years that nix has gained the popularity in industry for there to be more than just a few groups spending engineering hours towards improving things.
I think this is the right path. Get the guts working right and stable, then make the useful thing usable. That last bit is by far the hardest, but trying to make something usable useful is impossible.
It's been said many times and many ways, but the big thing will be the push to flakes. If they can bump that to stable before the project and it's integrations lose momentum, Nix might just become the defacto build system for Unix software.
The development experience of flakes is just unreal. Having seen it in-use at work was eye opening:
- You get all the Nix goodness, including package/dependency caching for multiple OS/arches with minimal configuration. Build times are practically reduced to automated searching and downloading.
- Dev environments are much cleaner and not spread across READMEs and makefiles. Adding a build dependency is one (1) SLOC in flake.nix. Adding environment variables is trivial, and it all gets shared with your branch.
- Invoking a quick 'nix develop' drops you into a shell w/ build dependencies, `nix build` builds the program, `nix profile install` adds it to your current environment, etc.
The list goes on. It will clean up shop once dev teams find out how little configuration is required to get this all working, if Nix move fast enough to ship this.
The development experience of flakes is just unreal. Having seen it in-use at work was eye opening:
- You get all the Nix goodness, including package/dependency caching for multiple OS/arches with minimal configuration. Build times are practically reduced to automated searching and downloading.
- Dev environments are much cleaner and not spread across READMEs and makefiles. Adding a build dependency is one (1) SLOC in flake.nix. Adding environment variables is trivial, and it all gets shared with your branch.
- Invoking a quick 'nix develop' drops you into a shell w/ build dependencies, `nix build` builds the program, `nix profile install` adds it to your current environment, etc.
The list goes on. It will clean up shop once dev teams find out how little configuration is required to get this all working, if Nix move fast enough to ship this.
I think you’re likely right, but as has also been said many time and many ways, the documentation is truly terrible. I don’t know why there isn’t a good documentation set that takes you from nix to nixos to flakes. When do I choose nix shell? Flakes? nix-env? I’ve got a few months between gigs and I’ve been flirty with nix for a year or so so I plan to dig in and master it, but it is mind bogglingly hard to get started.
Ironically, the Nix team is the one providing the best UX to me. It's more that many community solutions are stale and broken, despite being well-made and thoughtfully designed. I'd like to make home-manager work for me, but I struggle to in practice.
Well, for most other distro you also Google around and back someone together all the time, we just got used to it.
I want to try nix, but honestly can't justify the time investment when pop_os just works for me.
> Now to figure out what a "flake" is…
Flake is a worthwhile addition to Nix that is worth learning. But like anything Nixian, it's not straightforward.
Have you checked out any of the tools that aim to simplify Nix experience? We built Devbox (https://github.com/jetpack-io/devbox) with this in mind.
Flake is a worthwhile addition to Nix that is worth learning. But like anything Nixian, it's not straightforward.
Have you checked out any of the tools that aim to simplify Nix experience? We built Devbox (https://github.com/jetpack-io/devbox) with this in mind.
Well this is enough to put anyone off Nix. Such a shame because the abstract idea is obviously a good one. But every time Nix/NixOS comes up the story is the same.
Terrible UX. Terrible documentation.
Is Guix any better?
Terrible UX. Terrible documentation.
Is Guix any better?
Over half the blogpost is the user describing how they were able to get nix set up on a machine they don't have admin permissions to, and had a 4 GiB disk quota limit.
Those constraints don't really apply if you have admin control of your machine.
(And the troubles in the first half were caused by zealously diving deeper with Nix, after an initial simple setup went well).
Those constraints don't really apply if you have admin control of your machine.
(And the troubles in the first half were caused by zealously diving deeper with Nix, after an initial simple setup went well).
My Guix experience wasn't great. IMHO the people that love it will give you a non realistic view of it, so I recommend you listening to those that didn't like it that much but still like it.
I installed it on Debian, and there's no uninstall. Sure, at that point I was already frustrated, but IMHO that's just a sample. It wasn't for me.
I installed it on Debian, and there's no uninstall. Sure, at that point I was already frustrated, but IMHO that's just a sample. It wasn't for me.
I tried and found it even worse. Impenetrable language, worse documentation, less packages unless you use nixpkgs anyway...
Ironically, there are lots of blog posts documenting how people worked around the poor documentation, but seemingly few fixes being made in the upstream docs themselves.
The excellent Arch Linux Wiki demonstrates that high-quality community-maintained docs are possible.
The excellent Arch Linux Wiki demonstrates that high-quality community-maintained docs are possible.
I think the problem is people are assuming that Nix is just one another tool.
In reality Nix is a programming language. It is a relatively simple language, but it is also functional and lazily evalated. And while the language is simple, its stdlib (nixpkgs) is actually puts another abstraction layer on top of it which is quite complex.
I do think though that Nix should do the same thing other programming languages do: identify what the nix stdlib is, move it to a separate repo with its own release schedule and ensure that whatever is added to it/removed from it is documented.
This won't help author of this blog, but it would be a great help for anyone who is willing to go through Nix Pills.
In reality Nix is a programming language. It is a relatively simple language, but it is also functional and lazily evalated. And while the language is simple, its stdlib (nixpkgs) is actually puts another abstraction layer on top of it which is quite complex.
I do think though that Nix should do the same thing other programming languages do: identify what the nix stdlib is, move it to a separate repo with its own release schedule and ensure that whatever is added to it/removed from it is documented.
This won't help author of this blog, but it would be a great help for anyone who is willing to go through Nix Pills.
Tbh I don't understand why they created a new programming language. Why not use something like Starlark or even just sandboxed JavaScript?
It's the usual argument for any domain-specific language.
Personally I loathe DSLs unless you genuinely need something really fast and really simple. Otherwise please just pick something off the shelf and save everyone the headache.
Personally I loathe DSLs unless you genuinely need something really fast and really simple. Otherwise please just pick something off the shelf and save everyone the headache.
Well, Guix started as Nix with established language, and that didn't really made it better.
The Nix language is functional and lazily evaluated, it closely matches how Nix works builds packages, which basically makes it less verbose.
Even if they used python (or python like language like starlark), and then proceed to build an abstractions on top of it, barely documenting the function. Leaving old ones with the new ones, you would still be confused and frustrated needing to look at the source code.
The Nix language is functional and lazily evaluated, it closely matches how Nix works builds packages, which basically makes it less verbose.
Even if they used python (or python like language like starlark), and then proceed to build an abstractions on top of it, barely documenting the function. Leaving old ones with the new ones, you would still be confused and frustrated needing to look at the source code.
Feels like the problem people have is they are approaching Nix as a tool, instead of a programming language. I see author just dismissed tutorial, because it was "too technical" for him. I think if you don't have patience to get through nix pills, nix is likely not for you. You won't have enough patience.
Also few things:
- he decided to manage sway via home-manager, then got suprprised that after he made changes to its configuration and run "home-manager switch" it restarted the service
- when searching for installing nix on another machine, he tried nix-user-chroot, nix-portable, proot. He pointed out that nix-user-chroot is abandoned. The reason is that it is no longer needed, what he wanted to do can be done with statically built nix[1]
[1] https://youtu.be/6Le0IbPRzOE?t=4282 - I recommend watching the whole video (especially once he starts doing demo at 14 minutes) as you can do a lot of things you might not even know it was possible.
Also few things:
- he decided to manage sway via home-manager, then got suprprised that after he made changes to its configuration and run "home-manager switch" it restarted the service
- when searching for installing nix on another machine, he tried nix-user-chroot, nix-portable, proot. He pointed out that nix-user-chroot is abandoned. The reason is that it is no longer needed, what he wanted to do can be done with statically built nix[1]
[1] https://youtu.be/6Le0IbPRzOE?t=4282 - I recommend watching the whole video (especially once he starts doing demo at 14 minutes) as you can do a lot of things you might not even know it was possible.
Last time I did nix things, the language docs were not good. I’m fairly comfortable bashing my head into hard things for long periods of time but it was very hard to squeeze answers out of the internet.
For me it took some time. Finishing Nix Pills was enough knowledge to start looking into nix and nixpkgs manual and understanding it.
I still get frustrated that some new features that are being added are undocumented, though I also noticed that the nixpkgs documentation by default is set to last stable version. This means changes could be delayed by even 6 months. And given how rapidly nixpkgs change that could be the reason.
I still get frustrated that some new features that are being added are undocumented, though I also noticed that the nixpkgs documentation by default is set to last stable version. This means changes could be delayed by even 6 months. And given how rapidly nixpkgs change that could be the reason.
> Home-manager needs to add a channel to install it. This will not do.
FWIW, I see that nix-portable does support nix flakes, and home-manager also supports nix flakes. (And flakes are a feature which replaces use of channels).
FWIW, I see that nix-portable does support nix flakes, and home-manager also supports nix flakes. (And flakes are a feature which replaces use of channels).
Yea, i'm using home manager with flakes. Though i forget what initial setup is like. I've found bootstrapping new systems to be a bit odd with Nix + Flakes.
> It looked cool, and I was getting kinda sick of Zsh being slow in big Git repositories.
Sorry, what? If your zsh is slow in a big git repository, that's on you, not zsh. I honestly have a hard time taking anything else in this article seriously after reading that.
edit: the article is good. I was being harsh. Nix is horrible, and yet I refuse to use anything else.
Sorry, what? If your zsh is slow in a big git repository, that's on you, not zsh. I honestly have a hard time taking anything else in this article seriously after reading that.
edit: the article is good. I was being harsh. Nix is horrible, and yet I refuse to use anything else.
The author acknowledges this in the next sentence. A charitable reading would be that “Zsh” means “my Zsh”.
> I was getting kinda sick of [my Zsh] being slow in big Git repositories. Instead of fixing [my Zsh], I decided to give Fish a shot.
> I was getting kinda sick of [my Zsh] being slow in big Git repositories. Instead of fixing [my Zsh], I decided to give Fish a shot.
That’s a shame because the rest of it was pretty insightful and descends into a deep hole of interesting hopelessness. I think you took things too seriously, they clearly are lark hunting - which is beautiful to watch because that’s where learning happens.
NixOS is by far the most stable piece of software I used.
Yeah, it can be hard to get something working, but once you do, you can be sure it will work anywhere.
Yeah, it can be hard to get something working, but once you do, you can be sure it will work anywhere.
I'm 100% sold on the idea that the Nix model is, generally, the best way forward. But time and time again I hear the same thing: the documentation and UX suck.
Until I hear differently, I'm just gonna stick with my battle-tested shell scripts and symlinks. Sure, it's not the same degree of reproducibility, but also I've not yet had a practical reason to need whatever remaining percentage of the diminishing returns Nix offers that I'm not getting, at least when using my scripts combined with the use of other tools such as venv, nvm, cargo, etc, or even just building a lot of software from source.
Until I hear differently, I'm just gonna stick with my battle-tested shell scripts and symlinks. Sure, it's not the same degree of reproducibility, but also I've not yet had a practical reason to need whatever remaining percentage of the diminishing returns Nix offers that I'm not getting, at least when using my scripts combined with the use of other tools such as venv, nvm, cargo, etc, or even just building a lot of software from source.
As a fish user interested in Nix this put me off looking into it.
You can always take the easy way out and just symlink stuff. This is what I actually prefer. Then I can edit those files in their native format and just check the updates into my .config/home-manager git repo
home.file.".gitconfig".source = config.lib.file.mkOutOfStoreSymlink ./dotfiles/git/.gitconfig;
xdg.configFile."nvim" = {
recursive = true;
source = config.lib.file.mkOutOfStoreSymlink ./dotfiles/nvim;
};I prefer this approach for most of my configs. Saves having to look up options how to set options in two places.
As a fish user on NixOS, I'd say nix is still worth looking at.
The fish-related issues came from trying to manage the whole of the fish configuration with Nix.
I think that's a fairly niche thing to want to do.
The fish-related issues came from trying to manage the whole of the fish configuration with Nix.
I think that's a fairly niche thing to want to do.
But isn’t that the Nix promise? That I can have a fully reproducible system defined by a few configuration files?
Generally, Nix's strength is allowing for reproducing software behaviour, yeah.
I'd say NixOS's declarative config more/less covers the config files, where on non-NixOS you'd edit the files under /etc (and hope you didn't break anything).
Whereas, Home Manager's declarative config is more/less the stuff underneath $HOME or the XDG config dir.
Turns out that a few things with fish shell don't work with a purely declarative config. (e.g. the universal environment variables are stateful).
For myself, I don't rely on writing all my configuration in Nix files. I configure fish shell using config.fish. (Though I do use HM to symlink the config file).
I'd say NixOS's declarative config more/less covers the config files, where on non-NixOS you'd edit the files under /etc (and hope you didn't break anything).
Whereas, Home Manager's declarative config is more/less the stuff underneath $HOME or the XDG config dir.
Turns out that a few things with fish shell don't work with a purely declarative config. (e.g. the universal environment variables are stateful).
For myself, I don't rely on writing all my configuration in Nix files. I configure fish shell using config.fish. (Though I do use HM to symlink the config file).
re: everything in Nix, i use normal configuration most of the time.
Ie with Home Manager, i just have Nix copy (link) my config files to the place apps look for them. I only would even consider recreating them in Nix if i needed programmatic construction of them or if i was trying to distribute them as a Nix package or something.
But for just me, and my own use - i see zero reason to recreate config files which are already managed by Nix. It's just extra work with no benefit as far as i can tell. Especially because i detest the Nix language. It also makes it very difficult to search for, because if you want to figure out how to configure X feature of Y app, you need to search for that and then mentally map it to Z Nix configuration which may or may not support it. It's just layers of needless abstraction for a single-use configuration.
Ie with Home Manager, i just have Nix copy (link) my config files to the place apps look for them. I only would even consider recreating them in Nix if i needed programmatic construction of them or if i was trying to distribute them as a Nix package or something.
But for just me, and my own use - i see zero reason to recreate config files which are already managed by Nix. It's just extra work with no benefit as far as i can tell. Especially because i detest the Nix language. It also makes it very difficult to search for, because if you want to figure out how to configure X feature of Y app, you need to search for that and then mentally map it to Z Nix configuration which may or may not support it. It's just layers of needless abstraction for a single-use configuration.
What I've come to realize is while yes nix leads to absolutely bullet proof "reproducible" environments, there is seemingly very little care or thought about anything that comes before the build, i.e. the user experience for creating a configuration.
Just don't use home-manager and you'll be fine. I've been using NixOS for 5 years and still haven't gotten around to trying home-manager.
I have tons of complaints about Nix lang itself, but i actually got Home Manager working fairly quickly. I use Flakes, not sure if that helps though. I also don't recreate all my configs in Nix unless they absolutely need to be very programmable for some reason.
I think Nix is cool as a dev tool, but I have near zero interest in NixOS. The newer immutable distros (CoreOS, Silverblue, etc.) get you the actually important features and it's still good old Linux. I'm talking about (easy) declarative config, atomic upgrades, and guaranteed rollbacks. I don't need any more than that.
If I understand it right, https://getfleek.dev/ will turn a simpler yaml config into home-manager/nix/flake config. Might be a simpler way to get started.
Haven't started down into the Nix abyss myself though…
Haven't started down into the Nix abyss myself though…
YAML appears simpler but usually isn’t if you want to do anything hard
https://www.jetpack.io/devbox converts a simple json config into a nix dev environment.
Not the best thing to see pop up on the day that I'm supposed to get my new work laptop that I plan to nixify using home manager... I guess since I'm going to be running nix inside of MacOS it's a little less disastrous if I have to just pack it in and uninstall.
I don't really have a need for home-manager on a single-user NixOS system. Whatever configuration home-manager would typically manage is now contained in my global configuration.nix.
Home-manager has a lot of options for configuring packages available through it though. You have to manually write config files in your global configuration.nix for “what color should be the fg in this terminal”, while home-manager will provide an attribute even for that.
Also, you can use home-manager from within your configuration.nix, that’s how I use it! Then you don’t have to deal with it separately and everything is at one place.
Also, you can use home-manager from within your configuration.nix, that’s how I use it! Then you don’t have to deal with it separately and everything is at one place.
Yeah, I admit that home-manager is already decked out with all of these options. There's some more manual effort that goes into using configuration.nix here. That being said, I've been seeing more software being packaged up as nixos modules. For example, you can configure a git installation globally now.
I'm a single user and still use home-manager. And I wouldn't be surprised that's the majority of cases.
The thing is that while NixOS configuration.nix also contains modules for software, it primarily concentrates on global services and might not have modules for programs that are meant to be run under user.
The thing is that while NixOS configuration.nix also contains modules for software, it primarily concentrates on global services and might not have modules for programs that are meant to be run under user.
This is a shame to read, I've thought of learning Nix for basic devops tasks and avoid tools like Ansible. Is this critique true for Nix in general or just NixOS?
As with anything, "it depends." I think Nix and NixOS is great for personal and hobby stuff, but I cannot in good faith recommend it for anything professional. I personally run my daily driver on NixOS and haven't had any desire to change, but I'd prefer to never have to write an actual line of Nix code again.
> I cannot in good faith recommend it for anything professional.
What separates the professional from the 'personal and hobby stuff': the need for (timely) reliability, and that you want other people to be able to maintain it.
With Nix, because it's so strict, it's more difficult to quickly kludge a solution. If something doesn't work as you expect, it may demand understanding of different parts of the solution stack.
That Nix isn't widely adopted means it's harder to find e.g. StackOverflow answers for problems.
In the blogpost, an example of a problem they had to work around was that fish's configuration expected to work statefully in a way which didn't work well with Nix's Home Manager's declarative nature.
What separates the professional from the 'personal and hobby stuff': the need for (timely) reliability, and that you want other people to be able to maintain it.
With Nix, because it's so strict, it's more difficult to quickly kludge a solution. If something doesn't work as you expect, it may demand understanding of different parts of the solution stack.
That Nix isn't widely adopted means it's harder to find e.g. StackOverflow answers for problems.
In the blogpost, an example of a problem they had to work around was that fish's configuration expected to work statefully in a way which didn't work well with Nix's Home Manager's declarative nature.
To me, it reads like the author tried the tool, thought it was really neat, and discusses the problems they ran into (& how they fixed them). Once they got a simple setup that solved their needs, the author was enthusiastic to apply the tool to everything they had. -- Not sure I'd describe that as a 'critique'.
That said, I think the experience is demonstrative.
When Nix works, it's amazing, & you'll want to have Nix everywhere.
When something goes wrong with what you're trying to do, Nix can be very challenging, and will typically demand you have a good understanding of what's going on (with what you're trying to do, with Linux, with Nix in order to fix it.
That said, I think the experience is demonstrative.
When Nix works, it's amazing, & you'll want to have Nix everywhere.
When something goes wrong with what you're trying to do, Nix can be very challenging, and will typically demand you have a good understanding of what's going on (with what you're trying to do, with Linux, with Nix in order to fix it.
To me it sounds like criticism of someone who jumped on it but did not want to read documentation, then also spent second time of the blog trying to have Nix run on an unprivileged account with small quota.
As for devops task, if it is something that you plan to do and many other users already did than it should be fine. If you are not happy with existing solutions and want things done your way, or it is an uncharted territory then you will need to go through the steep learning curve.
As for devops task, if it is something that you plan to do and many other users already did than it should be fine. If you are not happy with existing solutions and want things done your way, or it is an uncharted territory then you will need to go through the steep learning curve.
Well... note that this is a critique but the conclusion encourages using Nix anyway. The whole "Nix sucks but everything else sucks worse" idea.
Yep, UX is a terrible issue. FWIW, I went through this too and after swapping to flakes and getting familiar with the ecosystem, I feel like I just "get it" more. There are still idiosyncracies of the language and the magic that is done in Nix core libraries that are frustrating to work through, but for 99% of daily tasks I feel better. I had a similar learning curve with Rust. It's worth it for me! So tl;dr don't be too put off by the learning curve, it's not impossible, just more than it should be.
Would Chatgpt help in accelerating the learning process? Does it understand Nix well enough to be useful?
I tried using Google Bard, another LLM for learning Rust, and it had no awareness that solutions were specific to certain versions of software. So it would give me confidently wrong solutions for outdated versions of the software.
My experience has been it generally does but not with newer more emergent things like flakes.
But, man, it's so slick when you get it working. It's so easy to understand your system and how it's set up. There's no weird stuff changing between updates that you don't know about. You don't have to merge new configurations. It's so easy to try something new without changing your system. Rollbacks are awesome. It's easy to move your config to a new machine or keep multiple machines in sync. My machines were constantly getting out of sync as far as packages, versions, config, etc. and it was a headache to maintain them all the way I like. Not anymore. It's so easy to maintain working NixOS systems. I have the same packages, users, and config on my machines without having to think about it. I have automatic updates going where I get a new system when I reboot. It basically works like an appliance I don't have to think about except it's set up the way I want it instead of how someone else decided it should work.
There are so many nice things about NixOS, but it sucks. It's the worst thing out there except for everything else. I hate it and I feel like I can't go back either. I would love a NixOS-like system with a better language, documentation on par with Arch, and the reliability of Debian.