▲ 200 points
back
110 comments
I have been exploring nix for the past few months and my experience with nix has been both exhilarating and frustrating, simultaneously. On one hand, I find it hard to imagine not using nix now, but on the other hand, I hesitate to recommend it to other colleagues due to its steep learning curve, ux issues and potential for footguns.
I sincerely hope that nix community improves the UX to make it more accessible to new users. Though for those willing to invest time in learning it, nix is extremely useful and highly recommended.
There are two sides to this problem, the first is to improve the UX, but the second is to clearly describe a compelling reason for people to adopt. It is very tempting to only blame the first, but I think we need to also need to tell a better story and highlight the values in a better way. This would then give people a reason to get past the UX issues in the hopes of achieving those desired values.
For example; people seem to have accepted that the benefits of using terraform in spite of various difficulties - the learning of its language or needing to hire specialists. The mantra of "infrastructure as code" is enough to drive adoption. What is our mantra? We need to accept that "reproducibility" isn't quite working and that we need either a clearer message, or to explain the message.
> but the second is to clearly describe a compelling reason for people to adopt.
Build source straight from Git:
nix run github:someuser/someproject
nix run github:someuser/someproject?ref=v1.0.0
nix run \
--override-input somelib github:someotheruser/somelib \
github:someuser/someproject
git clone https://github.com/someuser/someproject
# do your changes
nix run someproject/
NixOS just feels like a distribution build from the ground up for Free Software. The "reproducibility" in every day use just means that stuff won't randomly break for no reason. And if you don't wanna go the full NixOS route, you can just install the Nix package manager itself on any other distribution.
That said, the part where Nix gets painful is when it has to interact with the rest of the software world. Things like software that wants to auto-update itself really does not fit into the Nix ecosystem at all and can be rather annoying to get to work.
There are of course numerous other pain points, missing features and all that. But being able to flip between versions, fork, compile and all that with feels just so much better than anything else.
I disagree, I think the value proposition for reproducibility is clear, it's just that the learning curve "is too damn high!" I'm highly motivated to learn and use Nix (or Guix for that matter) but I've bounced off of it three or four times now, and I'm the kind of weirdo who learns new PLs for fun.
Someone once said that you don't learn Nix, you reverse engineer it.
Two of the major differences between terraform and Nix that I see are 1. it’s possible to muddle through in terraform and 2. Hashicorp has put a non-trivial amount of effort into documentation for all levels of users. I’ve taken a stab at using Nix for Rust projects and could not even get to a point where I had something that functioned. I found plenty of material online but was it out of date, idiosyncratic, did it use flakes or not, etc etc? I suppose I could have contorted my existing project to meet the examples I found in various GitHub repos but my stuff is bog standard Rust so I don’t know that I’d be willing to. As for documentation, what should I, as a new and invested user, be looking for? Are flakes the future? Are they a distraction? Why are all the suggested docs I could find several year old guides on blogs? There’s 20 years of information floating around and the official project documentation, well, I don’t know who the audience is but it’s not learners.
It’s a shame. The promise of Nix/NixOS is really interesting — being able to deterministically create VMs with a custom user land is desirable to me — but in practice I can’t even get a simplistic project to compile, let alone something elaborate. Terraform is jank but it’s not a whole language that needs to be learned, seemingly, before the official docs start to become coherent in their underlying context.
> We need to accept that "reproducibility" isn't quite working...
I guess it doesn't sell Nix as strongly as it could..
But, it's hardly for a lack of enthusiasm on Nix user's part. -- Rather, I've seen a few "what's nix good for anyway" comments, and this results in many lengthy replies extolling nix.
Agreed, reproducibility is only one aspect of Nix and doesn't quite capture the whole picture. That's why so many newcomers see Nix as nothing more than a Docker replacement. There's also too much misconceptions about Nix the language that's scaring people off.
I'd like to see more being discussed about:
* Its unique ability to treat packages as programmable data (i.e., derivations)
* Its use case as a building block for deployment systems that knows about and integrates with packages
* Its JSON-like simplicity
They're all central to the Nix experience, and yet it's often overlooked in Nix discussions.
I wonder if the corporate backing behind Docker has anything to do with Nix being adopted less. There’s a lot of overlap between Nix and Docker, and Docker had major corporate guns behind it from early on. Reproducibility as you mentioned, is easily achieved with Docker, and there is no need to learn the Nix ecosystem.
Personally, I want to learn Nix, but Ive never forced myself to do it because it’s so much easier to make a Docker image do what I want. Nix is the pinnacle of a reproducible environment that doesn’t randomly break, but Docker is 80% of the way there and much easier.
It’s like comparing trucks (Docker) with planes (Nix) for logistics. I can pay out the wazoo for a plane to get my package there over night, or I can pay a small fraction to wait a few days.
What I see as a barrier for entry to Nix/NixOS is not the UX, but the available documentation, or lack of thereof. One may consider the docs being part of UX though. I am in the process of writing a book about NixOS, you may track the progress here:
https://drakerossman.com/blog/practical-nixos-the-book
The emphasis is on how to make it as practical as possible, plus cover the topics which may apply to Linux in general, and in great detail.
Your email form to follow the book is returning errors to me. And you have no other contact channels I can find. Might want to look into that.
Hey! We've been working at Cachix to address this using https://devenv.sh/.
It's primary targeted to improve DX and on-board users quickly.
Currently working on a graphical UX where you can create and share flakes without writing Nix code at https://mynixos.com
The site makes it easy to browse indexed flakes and configure flakes via options and packages. Hopefully the structure provided by the UI can makes it easier to get started with Nix flakes :)
What are the footguns? I feel that footgun descriptions always have the most insightful bits about technology.
The problem with Nix is that I still have to start with a Linux system--so I still need Docker, Terraform, something to give me a stable base for Nix to work against.
At that point--why should I add Nix to the mess since I still need those other things anyway?
I find there is a perfect middle ground here (applies to multiple languages like this.)
Nix + LLM.
Especially if using GPT4 for quality. You get all of the usefulness of Nix, but created or edited using plain English.
And then of course at the end you output the nix as an artifact to live in version control.
> On one hand, I find it hard to imagine not using nix now
for what specifically?
It feels so painful to go back to ‘regular’ Linux now. I'm so concerned about config file entropy and version incompatibility that Nix has solved for me. I'm happy I took the Nix Pill though and completely skipped over Docker and it's often-unnecessary overhead. Nix store is a better solution to reproducible builds, and the syntax is a lot better than LISP for Guix or whatever Skylark is trying to be.
Currently I'm setting up a second machine to distribute builds and share a cache on my local network. Overriding C flags Gentoo-style for better optimization is supported, but it can take a while to build--especially with LTO--as Hydra only builds for generic x86_64 so sharing optimized kernels and other software is great. I successfully got a shared znver3 LTO-optimized Linux 6.1.19 kernel with ZFS support yesterday! I just wish I could have built in parallel the kernel on the faster PC and the ZFS stuff on the slower one and resynced the build input derivations when it was finished after running `nixos-rebuild switch --flake ..`.
For the future, I hope distributed Nix caches become the norm like BitTorrent and we can all share optimized builds.
I resolved by distributed build issues. This works as intended.
I’d like to learn more about the project history, who started it (early contributions), and the context under which the early work was initiated. Wikipedia has exactly two sentences on the history. Is there a better version of the Nix story available?
I guess the LISA '04 article and citations / citing work are a good starting point: https://scholar.google.com/scholar?cites=1106087772774893771...
The best talk I know about this is https://www.youtube.com/watch?v=t6goF1dM3ag
Doe nix work at all? Or is it just not actually functional on top of MacOS? I've tried a dozen times over the years and I've never gotten it working.
Seriously, how is anything so hard to use still around after 20 years!
You might want to give the new installer by Determinate Systems a try: https://determinate.systems/posts/determinate-nix-installer
I ship a development environment to a fleet of ~100 engineer laptops based on Nix. If it didn't work, I'd be out of a job
It absolutely works and is the best thing since sliced bread within package managers — many UNIX tools are just simply broken on Mac (not always on the packaging side), and in case of more niche tools it is simply not a priority.
Hard to answer your question without info on what the problem is, but lots of people use it on MacOS. Maybe ask about your problem on /r/nixos or https://discourse.nixos.org/.
I’ve never had an issue with Nix itself on macOS but there are occasionally packages that are broken on macOS but work on Linux - despite upstream supporting macOS.
What I would like is to replace both Docker and docker compose for prod images and local dev, respectively for my team. Is this possible with nix today? It’s mostly a macOS box team.
I use nix flakes to manage my own configuration, but last time I played with building docker images on macOS I had to stand up a builder image on qemu or inside docker.
Further, I’ve historically run into friction between other package managers and nix. The poetry2nix and pnpm2nix kind of tools have a lot of friction [for example, private registry support for poetry is poor]. My current project has a dependency on xmlsec and it’s a bit cumbersome to handle building non wheels on M1.
20 years, is that the compile time now? ;)
Sarcasm aside, here’s a Nix manual from 2004: https://releases.nixos.org/nix/nix-0.5/manual/manual.html.
(The compile time of Nix itself is unpleasant, but not exactly exceptional among programs written in the modern C++ style. The eval time even for Nixpkgs even on a ten-year-old i5 is annoying but not a terrible problem the way it’s used now, though even on a recent Android device it’s admittedly measured in minutes.)
Hold up we're talking about Nix not Rust !
(yeah sorry couldn't resist, I know this is probably misleading)
nix is one of the things I always think would be neat to try, but I’m always scared away by the complexity.
You can get quite far without having to be aware of significant complexity.
e.g. to take a look at https://devenv.sh/ or https://www.jetpack.io/devbox/docs/installing_devbox/ which aim to leverage nix without requiring nix knowledge.
I like the principle of Nix that one can simultaneously install different versions of the same software and make layered choices of what version to use with what or depending on the use case. Nix has spearheaded that principle and that's great.
That being said, that fine-grained layering selection is done via symlinks in Nix afaik, whereas a couple newer packaging systems (e.g. OCI containers or flatpak) can do such layering with newer stuff like bind mounts and namespaces+sandboxing (and I don't just mean sandbox for build time but for run time) and thus increase the security by selectively choosing what a package is supposed to have access to. I wonder how fast Nix will adapt to such new possibilities. I think it should do so quickly (e.g. switch to OCI as the underlying layering system; I hear that the Tvix project is experimenting with that?), as that could establish Nix as the dominant system/distribution in that field whereas otherwise it would be overtaken and left behind by whatever OCI-container-based distribution manages to come out as the dominant one.
There is currently (temporarily) a unique window of opportunity in that:
* Docker is totally ruining their position in the OCI world, and had never really put effort into building a comprehensive quality curated distribution. That is: their registry may be "comprehensive" as in large choice, but apart from a small set of base images, it's mostly a hotchpotch of low-quality uncurated images with uncertain security… and often found to be of severely lacking in the security domain.
* Redhat has a much too closed policy for their OCI registries and has made the mistake of restricting their OCI stuff to the server side while fedora pushes flatpak/flathub which is too restricted to the desktop. That artificial chasm between a server-only and a desktop-only system sucks.
* Ubuntu has completely borked their attempts at new sandboxed/layered package formats, snap sucks. And Debian and the other remaining big distros have nothing in that category
Nix has the advantage of already having a large, comprehensive and curated set of packages. All it needs is to adopt OCI as its underlying layering system (instead of symlinks), make its large package base trivially accessible to OCI, and make an effort on UX (a little more accessible and easier) and it could come out as the dominant distribution.
Treating packaging boundaries and runtime isolation as the same thing is exactly the problem with Docker and similar solutions. Just because some package didn't require another package at build time doesn't mean we don't ever want to use them together at runtime. Yet Docker conflates the two, introducing all sorts of unnecessary friction all over the place.
This is why something as simple as getting more than one process to work with each other on Docker is such an overcomplicated mess. The runtime isolation boundary set by Docker doesn't represent any sort of logical component or security boundary in your system. It merely reflects how the underlying image was built.
This is a classic anti-pattern of mixing up policy with implementation. Runtime isolation policy should be independent of build time implementation. Nix gets this right with better design and composable packages. It's trivial to create a container that includes only the packages you want, with dependencies handled automatically by Nix. Docker, on the other hand, leaves you with a binary blob (i.e., Docker image) that's neither composable nor customizable.
OCI is based on Linux namespaces, which provide a way to create isolated filesystem trees for processes. You probably want that, and I agree with you, but probably forcing this into OCI itself is a lost cause, since its tooling is too based on layers.
No. The nix store is a graph. Oci images are a tree. This is terrible for code ruse. Nix is superior.
Oci should adopt a nix based approach.
I tried to install NixOS using the live cd last week in a Hyper-V VM, but it failed to get anywhere due to SquashFS errors.
That seemed pretty low-level so I'm putting it back on the back burner. User friendliness doesn't seem to be a top priority, and that's fine.
> I tried to install NixOS using the live cd last week in a Hyper-V VM, but it failed to get anywhere due to SquashFS errors.
Heh, that reminds me of installing NixOS back around 2014. I didn't have any way to physically boot off the install CD; so I ran it in qemu, using my real /dev/sda as the "virtual" hard drive (which I'd already partitioned). Thankfully there was no interference with the host system (Trisquel).
I'm still using (and evolved version of) the same NixOS config to this day; it still contains the following comment ( https://github.com/Warbo/nix-config/blob/master/nixos/machin... ):
trace "FIXME: Which modules are artefacts of using QEMU to install?"> I tried to install NixOS using the live cd last week in a Hyper-V VM, but it failed to get anywher e due to SquashFS errors.
I'm curious what happened here because just a few weeks ago I was using a NixOS live-cd to rescue a botched gentoo VM on my windows machine (managed with Hyper-V manager).
If you give it another shot, run into the issue again, and document it, the Nix community would almost certainly help you debug it and figure out what went wrong.
Realistically speaking, Nix will never become widespread. Instead, I foresee immutable OSes like Steam OS, Chrome OS and Fedora Silverblue combined with something like flatpak for installing applications.
The evolutionary strategy of reproducible snapshots of state has historically been far more successful than "pure" functional approaches; see Docker for example, or reproduction of DNA based lifeforms.
Surprising to me that there's 0 Nix meetups in the Bay Area, as listed on that page. There should be one!
Just announced the bay area meetup -> https://www.eventbrite.com/e/nixos-20th-bay-area-meet-ticket...
Hope to see you all soon :)
I’m looking to put one together in Bay Area for next week or so. DM me if interested or if you know more people in the area.
What happened to NixOps? It sounded like a great idea when I first read about it.
As far as I know, it’s still about [0]. I’ve had a better experience with deploy-rs though [1] - or even just using nixos-rebuild to target the remote machine.
Nix feels like a dead end.
Can you elaborate? Personally I feel like everything else is a dead end compared to Nix
Huh? I see nix more and more in the wild.