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.<p>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.
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.<p>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 ..`.<p>For the future, I hope distributed Nix caches become the norm like BitTorrent and we can all share optimized builds.
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?
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.<p>Seriously, how is anything so hard to use still around after 20 years!
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.<p>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.<p>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.
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.<p>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.<p>There is currently (temporarily) a unique window of opportunity in that:<p>* 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.<p>* 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.<p>* 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<p>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.
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.<p>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.
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.<p>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.