I'll be honest, the first few times I tried using Nix I just couldn't get into. It was too complex for the benefits I was getting. But that was using Nix on another OS.
I recently switched to NixOS because I wanted what they were selling and the experience this time around was way better. Having no other option but to figure it out made me learn the essentials real quick (like an exchange program to a foreign country that speaks another language).
If you think about it, when you used Ubuntu or Fedora or RHEL for the first time, and probably for a very long time, you could get by without learning the deep intricacies of what is going on behind the scenes. The same is true with NixOS. The things you need to learn are different, but once you get a basic setup with home-manager setup you're off to the races. (Btw, I used this "book" to get started and it was great: https://nixos-and-flakes.thiscute.world/)
The best part about using NixOS so far is that things just work. Setting up my graphics card was as simple setting enabled = true. Same for configuring specific audio frameworks. And I had tried many times to get Davinci Resolve working on other distros and always encountered issues leading me to need to dual-boot Windows so I could do video editing. Now I just enabled Davinci Resolve and it works! No more Windows.
If you're brand new to linux on the desktop, I wouldn't recommend it. But if you've been doing that for years, maybe try NixOS in 2024.
Having been on NixOS exclusively for a couple years now, it's inconceivable for me to go back to a non-declarative OS. It would be analogous to from from Git to unversioned source code. My operating environment is a piece of compiled software itself now, and is remarkably reliable and predictable. Yes, it's difficult to learn and takes more work, but it's similar to Git in that respect - powerful tools are worth the effort if it's your vocation.
I have had a great experience using the Nix package manager on other Linux distros. It's super easy to try out software with `nix-shell -p somepackage`. (It's a little rockier on macOS.)
Another neat trick is reproducible shell scripts that use Nix to declare their dependencies in a sort of extended shebang line.
I think the idea is good but execution is poor to reach mass adoption because:
1. It tries to replace ALL package managers due its extreme philosophy. I had a lot of issues when it tries to replace Cargo for example
2. It uses a functional language, which will lose 95% of users
3. It never had a great user experience especially if you’re new and trying to learn or if you’re not using linux or if you bring your own tools (e.g. vscode)
I think something like that could totally exist one day, but it’ll have to restart from scratch on a cleaner base IMO
What exactly would this "cleaner base" look like? A main goal of Nix is a completely reproducible deployment, and many tools are not built for declarative usage, so Nix must add a layer on top in order to make them declarative. If you only go part way, then the entire point of Nix is nullified. Might as well use Ansible.
That being said, it's really not that difficult to use tools in their original form on Nix is you want. You can create temporary FHS shells in which tools just work. I do this with Python, as I can't be bothered to do it the "right" way when I just want to run some random script from github.
> What exactly would this "cleaner base" look like?
My interpretation would be something like: the abandonment of software that is so poorly designed that it is difficult to package and/or run under Nix.
This commit message (from one of my commits) details some of the struggles supporting Ruby under Nix:
1. Some unmotivated contrivance in Bundler, where the maintainers refused to make their stuff less needlessly broken, or
2. Ruby programmers in general not programming with packaging in mind (haven't touched Ruby/Rails professionally in a while, but when I did, it was par for the course to rsync/capistrano files around -- no one saw the utility of any sort of packaging)
And the two really reinforce each other. Bundler is the de facto way to declare and pin dependencies at the app level, but then Bundler makes it nearly impossible (see the commit message for details) to package software using Bundler, which reinforces the "fuck it, we'll just rsync files around over SSH", which means no one pressures Bundler to Do The Right Thing.
It's the same thing everywhere else. There are complaints elsewhere in this comment section about the nodejs/npm experience on Nix: same underlying problem. The design behind npm is so unnecessarily shit-tacular that it kinda sorta just barely works on its tier 1 platforms. I don't envy the brave souls that have worked on supporting npm packages on Nix.
My experience with Nix is that my own tools didn't work, even with the help of Nix experts. Then, after months of debugging we figured out that I had to quit vscode completely, and then start it from the console using the nix command with the -i option to clean up any environment variable (without that option it wouldn't work). There were some nix plugins for vscode, which would have been awesome if they had worked, but they didn't.
If you don't want to fully commit to the OS or the Package Manager, you can use Nixpkgs alongside your OS and other package managers by installing Nixpkgs on your Mac or Linux OS.
For the functional language and UX, I agree there's room for improvement. If you don't want to dive into learning Nix, you could use a wrapper that simplifies the UX for creating projects. We built one called Devbox (https://jetpack.io/devbox), which uses JSON for it's config format and has a CLI inspired by more familiar tools like Yarn.
I don't think points 1 and 2 are really that valid, but 3 is why I'm a Nix hater. They've managed to design an arcane solution to an everyday problem.
Nix solves real problems that Cargo can't/won't. And the 95% use case worth optimizing for isn't someone authoring flakes, but people just looking for the proper incantation to get the software they need for their environment.
I need to do some reading up on Nix, because I don't think I understand it. I thought NixOS was an operating system and Nix an operating system-level package manager, so why is it trying to replace Cargo, a package manager for a specific programming language in Rust?
The same reason Bazel builds avoid using Cargo when building Rust software, so I'll describe why Bazel would do this:
- Bazel wants to cache remote resources, like each respective crate's source files.
- Bazel then wants to build each crate in a sandbox, and cache the build artifacts. Because bazel owns this process, instead of Cargo, it can trivially distribute those build artifacts to other developers, or in CI, etc -- instead of everyone having to build everything from scratch.
This is an established practice, and Nix wants to drive the build for the same reasons.
For the same reason debian's APT manages rust dependencies for its packages - an OS-level package manager needs to support all its languages.
Language-specific package managers fall short as they don't (and often can't) consider cross-language dependencies.
I’ve encountered NixOS through Replit and thought it was such a fantastic way to manage environments, when I’m using things like ASDF and Bash scripts for installs, I’d love this.
Then comes the question “I won’t commit to something like this and I don’t know why”, and you just articulated it for me.
I work on Nix and think this paradigm has already impacted and will continue to influence software devopment in general. I want to make it easier for organizations/companies/groups to adopt it. Ideas and questions are welcome.
I'd start with getting some sort of working governance structure going. The sheer number of duplicate libraries all competing with each other has to be hurting Nix. Trying to figure out a TS/NodeJS build was an utter nightmare a year ago as I ended up going through five different projects, including the new "internal" solution, none of which worked reliably.
I contributed to the community for about a year and have since left for a number of reasons, but this is near the top.
Governance has been a difficult thing to make progress on. I can say that we did discuss recently cleaning up some of these old solutions and making official approaches clearly marked as such.
I run NixOS on a VPS at work. It currently hosts a noVNC dashboard for monitoring. I didn’t nixify the app yet.
I allocated a Debian and ran nixos-infect on it and started from scratch, even though I have done this for two other machines, because I’m still experimenting with the basic setup.
I’ll need to make noVNC a part of the deployment (not just its dependencies, like python3).
I should deploy using AWS AMIs, and make a config for the dashboard.
But the NixOS on Hetzner docs are not nearly as easy to guess the best path through. Can you recommend a way to boot NixOS on a Hetzner VPS that is better than nixos-infect?
I have step-by-step video guides (with accompanying git repos) for booting NixOS from zero on both Hetzner VPS instances[1] and bare metal Robot instances[2] with nixos-anywhere[3]. I used to use nixos-infect but now I'm 100% sold on nixos-anywhere.
I think the fastest path to adoption is to build a front-end for nix so that non-technical users can use it like they would Ubuntu. Users could select packages and edit system config through a GUI, which would be built/deployed when the the user clicks "save" or whatever, with an "advanced" mode where users could edit and add extra text config if they wished. SnowflakeOS [1] and Fleek [2] are admirably starting to work towards that, but there isn't enough of a concerted community effort to make it a first class feature of NixOS. If/when something like this were mature, you could then take it to the next level, where you could have something similar to an "app marketplace" where users could share flakes or sets of config that do things, like "Jake's blinged out desktop" or "Home router setup", essentially adding an additional layer of easy composability on top of base packages that most systems support.
Apologies if there is already something like this in work by the core nix devs.
I like the idea of nixos. Having one file responsible for all packages installed on the system is way better than what traditional distro use. I just don't like the quality of the packages. It would be nice if someone could do something like a os wide packages.json but for a mature packages repository like Debian.
And gentoo has /var/lib/portage/world, and pacman has "pacman -Qe", and apt has "apt-mark showmanual".
...I sometimes wonder how the world would be if the "explicitly installed packages" functionality was better exposed and advertised. I never see any guide for "installing development dependencies" use things like "pacman -S --asdeps" so you can clean them up later.
I am not a (current) developer, though I have more dev experience than most laypeople. I have enough experience with languages to pick up a new one relatively easily but I’ve never done anything with a functional language. I installed NixOS after playing around with nix (the package manager) in Fedora.
1. While the WHAT of NixOS was obvious from the start, I have never had a more difficult time understanding HOW to get there with a piece of technology. The documentation is hilariously inconsistent.
2. I have also never encountered a more satisfying, useful, and time-saving piece of technology. I had a computer crash and it took me 15 minutes to be back to where I was on a completely different machine with about 2 commands.
3. Time-saving other than the vast learning curve anyway.
4. Unlike some tech projects, it’s not hard because it’s incomplete or poorly structured. It’s hard because it’s doing something different. (It’s arguable how different it is in 2024, but that’s a different conversation.)
5. To create my child’s account, I spent about 10 minutes editing a copy of my config to pick and choose the packages he needs, and it deployed (on the first go) in about 10 minutes, fully configured.
Projects like fleek that put a simplified face on nix are incredibly valuable, because they can unlock 65% of the benefit of the platform with almost zero effort. I can’t tell you if the time investment for the extra 35% is worth it for someone managing family computers, but, y’all, I spend less time fiddling with them now and they break less often. That’s a … plus?
NixOS is honestly the single most game-changing thing I've been introduced to in my last decade of experience in tech.
If you're interested in trying out NixOS I highly recommend either running it as an WSL2 VM[1] if you have a Windows machine or deploying it on a cheap VPS[2] to play around with.
I personally still use a Win11 desktop for compat with Adobe software and a few other bits and pieces, but I do all my serious work on a NixOS WSL2 VM.
I keep seeing this from people online but I have yet to see Nix in the wild at any large organization. For such a "game-changing" thing, it certainly doesn't have the meat space following you see online.
To me, I tried Nix, got frustrated with packages, realized I'm just using someone else's abstractions for defining configuration files (with the same kind of quality you'd find on Ansible galaxy), and realized it's not solving a problem I have.
It can be game changing for individuals - it was for me. But is hard to deploy at scale, at least to workstations, unless everyone on the team is motivated and skilled enough to do it, or the team started from the beginning with it. It also has a steep learning curve. There are several quant and defense firms that use it as their main workstation and deployment OS, where most individuals are highly skilled and rigorous accurate deployments are a must.
Readit News
I recently switched to NixOS because I wanted what they were selling and the experience this time around was way better. Having no other option but to figure it out made me learn the essentials real quick (like an exchange program to a foreign country that speaks another language).
If you think about it, when you used Ubuntu or Fedora or RHEL for the first time, and probably for a very long time, you could get by without learning the deep intricacies of what is going on behind the scenes. The same is true with NixOS. The things you need to learn are different, but once you get a basic setup with home-manager setup you're off to the races. (Btw, I used this "book" to get started and it was great: https://nixos-and-flakes.thiscute.world/)
The best part about using NixOS so far is that things just work. Setting up my graphics card was as simple setting enabled = true. Same for configuring specific audio frameworks. And I had tried many times to get Davinci Resolve working on other distros and always encountered issues leading me to need to dual-boot Windows so I could do video editing. Now I just enabled Davinci Resolve and it works! No more Windows.
If you're brand new to linux on the desktop, I wouldn't recommend it. But if you've been doing that for years, maybe try NixOS in 2024.
Another neat trick is reproducible shell scripts that use Nix to declare their dependencies in a sort of extended shebang line.
1. It tries to replace ALL package managers due its extreme philosophy. I had a lot of issues when it tries to replace Cargo for example
2. It uses a functional language, which will lose 95% of users
3. It never had a great user experience especially if you’re new and trying to learn or if you’re not using linux or if you bring your own tools (e.g. vscode)
I think something like that could totally exist one day, but it’ll have to restart from scratch on a cleaner base IMO
That being said, it's really not that difficult to use tools in their original form on Nix is you want. You can create temporary FHS shells in which tools just work. I do this with Python, as I can't be bothered to do it the "right" way when I just want to run some random script from github.
My interpretation would be something like: the abandonment of software that is so poorly designed that it is difficult to package and/or run under Nix.
This commit message (from one of my commits) details some of the struggles supporting Ruby under Nix:
https://github.com/NixOS/nixpkgs/commit/b6c06e216bb3bface40e...
Each of those problems is due to either:
1. Some unmotivated contrivance in Bundler, where the maintainers refused to make their stuff less needlessly broken, or
2. Ruby programmers in general not programming with packaging in mind (haven't touched Ruby/Rails professionally in a while, but when I did, it was par for the course to rsync/capistrano files around -- no one saw the utility of any sort of packaging)
And the two really reinforce each other. Bundler is the de facto way to declare and pin dependencies at the app level, but then Bundler makes it nearly impossible (see the commit message for details) to package software using Bundler, which reinforces the "fuck it, we'll just rsync files around over SSH", which means no one pressures Bundler to Do The Right Thing.
It's the same thing everywhere else. There are complaints elsewhere in this comment section about the nodejs/npm experience on Nix: same underlying problem. The design behind npm is so unnecessarily shit-tacular that it kinda sorta just barely works on its tier 1 platforms. I don't envy the brave souls that have worked on supporting npm packages on Nix.
For the functional language and UX, I agree there's room for improvement. If you don't want to dive into learning Nix, you could use a wrapper that simplifies the UX for creating projects. We built one called Devbox (https://jetpack.io/devbox), which uses JSON for it's config format and has a CLI inspired by more familiar tools like Yarn.
Nix solves real problems that Cargo can't/won't. And the 95% use case worth optimizing for isn't someone authoring flakes, but people just looking for the proper incantation to get the software they need for their environment.
- Bazel wants to cache remote resources, like each respective crate's source files.
- Bazel then wants to build each crate in a sandbox, and cache the build artifacts. Because bazel owns this process, instead of Cargo, it can trivially distribute those build artifacts to other developers, or in CI, etc -- instead of everyone having to build everything from scratch.
This is an established practice, and Nix wants to drive the build for the same reasons.
See:
- https://github.com/bazelbuild/rules_rust
- https://github.com/google/cargo-raze
I’ve encountered NixOS through Replit and thought it was such a fantastic way to manage environments, when I’m using things like ASDF and Bash scripts for installs, I’d love this.
Then comes the question “I won’t commit to something like this and I don’t know why”, and you just articulated it for me.
I contributed to the community for about a year and have since left for a number of reasons, but this is near the top.
I allocated a Debian and ran nixos-infect on it and started from scratch, even though I have done this for two other machines, because I’m still experimenting with the basic setup.
I do commit changes to git and fork it on company git. But I don’t redeploy remotely: https://discourse.nixos.org/t/deploy-nixos-configurations-on...
I’ll need to make noVNC a part of the deployment (not just its dependencies, like python3).
I should deploy using AWS AMIs, and make a config for the dashboard.
But the NixOS on Hetzner docs are not nearly as easy to guess the best path through. Can you recommend a way to boot NixOS on a Hetzner VPS that is better than nixos-infect?
https://nixos.wiki/wiki/Install_NixOS_on_Amazon_EC2
http://jackkelly.name/blog/archives/2020/08/30/building_and_...
[1]: https://www.youtube.com/watch?v=wr22CyoyRo4
[2]: https://www.youtube.com/watch?v=nlX8g0NXW1M&t=952s
[3]: https://github.com/nix-community/nixos-anywhere
Cloud-init can be clumsy to get going, but it’s possible.
Apologies if there is already something like this in work by the core nix devs.
[1] https://snowflakeos.org/
[2] https://getfleek.dev/
I'm not a fan of nix but I'd say the nixos repository is fairly mature.
...I sometimes wonder how the world would be if the "explicitly installed packages" functionality was better exposed and advertised. I never see any guide for "installing development dependencies" use things like "pacman -S --asdeps" so you can clean them up later.
source: https://repology.org/
Alpine also sounds like a nice system but I'd bet it has an even worse issue with bad packages because of musl.
Dead Comment
1. While the WHAT of NixOS was obvious from the start, I have never had a more difficult time understanding HOW to get there with a piece of technology. The documentation is hilariously inconsistent.
2. I have also never encountered a more satisfying, useful, and time-saving piece of technology. I had a computer crash and it took me 15 minutes to be back to where I was on a completely different machine with about 2 commands.
3. Time-saving other than the vast learning curve anyway.
4. Unlike some tech projects, it’s not hard because it’s incomplete or poorly structured. It’s hard because it’s doing something different. (It’s arguable how different it is in 2024, but that’s a different conversation.)
5. To create my child’s account, I spent about 10 minutes editing a copy of my config to pick and choose the packages he needs, and it deployed (on the first go) in about 10 minutes, fully configured.
Projects like fleek that put a simplified face on nix are incredibly valuable, because they can unlock 65% of the benefit of the platform with almost zero effort. I can’t tell you if the time investment for the extra 35% is worth it for someone managing family computers, but, y’all, I spend less time fiddling with them now and they break less often. That’s a … plus?
Deleted Comment
If you're interested in trying out NixOS I highly recommend either running it as an WSL2 VM[1] if you have a Windows machine or deploying it on a cheap VPS[2] to play around with.
I personally still use a Win11 desktop for compat with Adobe software and a few other bits and pieces, but I do all my serious work on a NixOS WSL2 VM.
[1]: https://github.com/LGUG2Z/nixos-wsl-starter
[2]: https://github.com/LGUG2Z/nixos-hetzner-cloud-starter
To me, I tried Nix, got frustrated with packages, realized I'm just using someone else's abstractions for defining configuration files (with the same kind of quality you'd find on Ansible galaxy), and realized it's not solving a problem I have.
https://idx.dev/blog/post/nix-in-the-wild-project-idx
"How we went from supporting 50 languages to all of them"
https://blog.replit.com/nix