12 ms·

I think it's time to give Nix a chance

148 points by pacmansyyu 1y ago

urlwolf 1y ago
I moved to nix around Nov last year and couldn't be happier, the motto 'nix fixes that' is true. First time I can say linux is trouble free. Upgrades are painless. Dev environments, reproducible. Largest repository of packages in the linux world. Next to zero time wasted configuring things. Foundation LLMs now know enough nix to get you out of trouble most of the time. It's perfect as a linux experience.
- zachlatta 1y ago
  Can you link your dotfiles? I’ve been having trouble figuring out a good way to structure mine
  - i915 1y ago
    Try using https://github.com/numtide/blueprint https://github.com/numtide/blueprint
  - sshine 1y ago
    Yes, that’s easy. Here’s a very small example: https://github.com/sshine/nix/blob/main/shared/home-manager.nix https://github.com/sshine/nix/blob/main/shared/home-manager.... My servers don’t have that many dotfiles because most server software can be configured in /etc (zsh, vim), while my work computers have a lot of dotfiles symlinked into ~/.config/ via Nix, e.g. VSCodium, ghostty, … Most people prefer to Nix up their dotfiles, which provides some advantages (e.g. universal styling via Stylix), but the main drawback that I’m not buying is: I can’t share my app-specific config with non-Nix users. But if you’re looking for a cheaper (in terms of complexity) dotfiles manager: https://github.com/yarlson/lnk https://github.com/yarlson/lnk
- TeeMassive 1y ago
  Until your use case hasn't been deciphered by a Nix scribe and then you have to fight the magic.
  - johnisgood 1y ago
    Which makes "next to zero time wasted configuring things" false, very much so. You will have to write your own derivation(s) using Nix[1]. In any case, from the article, what does not apply to Guix, too? I am leaning towards Guix because of its language (Scheme, i.e. Lisp-y), but I wonder about the differences between the two, today (besides userbase and hype). [1] https://nix.dev/tutorials/nix-language.html https://nix.dev/tutorials/nix-language.html
    - mplanchard 1y ago
      Mainly the mindshare. Nix has a massive set of packages. You’ll have to build more derivations for guix.
      - johnisgood 1y ago
        I assumed that, but "only" that? I genuinely wonder. I did not get around to try Nix yet.
        mplanchard 1y ago
        I think it’s “only” that yeah. Both have fundamentally the same capabilities. Nixpgs may provide more out of the box library functionality than guix, I’m not sure, but as far as I know there’s nothing possible in one that isn’t possible in the other. Would be glad to be corrected by anyone with more experience, though. I’ve run NixOS for years now, but have only dabbled with guix.
      - pxc 1y ago
        Guix already has as many packages as Nixpkgs did back when I started using it, and like Nixpkgs, the package set is growing exponentially. What you say is true but it also seems to me like for many, Guix already provides a very useful starting point.
        mplanchard 1y ago
- sepositus 1y ago
  Welcome to the honeymoon phase. Mine lasted about a year. Eventually you will have to leave the comfortable area of "those who have done it before" and engage with some long, unwieldy, mostly undecipherable stack trace. When I asked a long-time Nix vet why he thinks people leave, he provided the most insightful answer I've seen yet: they just don't try hard enough.
  - atrus 1y ago
    Why is it inevitable that you have to leave the comfortable area of "those who have done it before" though? Most of the benefit of nix for me is maintaining a configuration for a couple computers in a way that's easy to backup, upgrade, and recover with.
    - sepositus 1y ago
      For reference, I use Nix to manage three different machines, always via home-manager and nix-darwin (I left NixOS awhile ago and haven't looked back). I don't think it's "inevitable" that you'll hit the difficulty wall, but certainly likely. As an example, I was recently playing with Pyinfra which is like a pure Python version of Ansible. It turns out that one of the dependencies uses an archaic version of setuptools and the package owner had inserted some _very_ hacky code that ended up breaking on two of my systems. Now I'm relatively experienced with Nix, so it took me a few hours to track down, but it would have been days if not impossible for a beginner. Nowadays I package brew along with my machines and as soon as something smells funky in Nix I just manage it with brew. Much more peaceful.
  - nextos 1y ago
    I think Nix is getting an unfair reputation for being too hard. Simple things are IMHO simpler in Nix than in any other distribution, and what one needs to know to accomplish them is tiny. It has basically reduced my sysadmin maintenance tasks to zero. In case of regressions, Nix makes it trivially easy to go back in time 2 or 3 years, cherrypick some packages and install them, or change your entire desktop environment, and then go back to the previous state with no effort. Nix is hard if you need to build something difficult to package or something that has very unusual or dirty build processes. If you need to that regularly, Nix is not worth the effort unless you are an organization that values reproducibility and is prepared to pay for its cost upfront. If these particularly messy usecases are something that you don't encounter so frequently, you can always use an escape hatch to be able to make your install impure. For instance, distrobox is quite convenient to run e.g. an Arch or Ubuntu container. In my case, this has been helpful to run Julia, whose Nix packages are quite brittle.
bigyabai 1y ago
Clutter reduction and version-controlled build/packaging is where Nix wins big-time. With Direnv you can automatically enter a developer shell as soon as you CD into the directory, which is another helpful timesaver.
- peterbecich 1y ago
  Agreed, and the full NixOS is unnecessary for the developer shell feature and Direnv
krapht 1y ago
I tried to give Nix a chance but I never figured out how to package dependencies that didn't already have a derivation written for them. Particularly since I do a lot of ML work - I never figured out how to handle mixed Python/C++ code with dependencies on CUDA. It's just way easier, even if not reproducible, to build an environment imperatively in Docker.
- sepositus 1y ago
  The most common answer I've seen is that Python packaging just "doesn't do it right" so it's impossible to get a clean Nix experience with them. Which, to some degree is true, but it also reveals the opinionated nature of Nix and why it often falls flat.
- unignorant 1y ago
  I do a lot of ML work too and recently gave NixOS a try. It's actually not too hard to just use conda/miniconda/micromamba to manage python environments as you would on any other linux system with just a few lines of configuration. Pretty much just add micromamba to your configuration.nix plus a few lines of config for nix-ld. Many other python/ML projects are setup to use docker, and that's another easy option. I don't have the time or desire to switch all my python/ML work to more conventional Nix, and haven't really had any issues so far.
blueflow 1y ago
Yes, but: du -sh /nix I specifically remember the glibc 2.26/ucontext desaster that triggered an rebuild of the nix world and exhausted all disk space that i had.
- atrus 1y ago
  Yeah, if you only have nixos on a space constrained device (like my poor old chromebook), you're going to have a bad time. The plus side though if you go all in is that you can build once on something more powerful and just copy the updates to the low powered stuff.
- kenmacd 1y ago
  du -sh /nix 187G /nix This is with nix.gc = { automatic = true; dates = "weekly"; options = "--delete-older-than 30d"; }; Cleaning up some direnv versions and a `nix-collect-garbage --delete-older-than 5d` would bring it down to around 40G. For me this isn't _too much_ space, but it's easy for an update to download multiple gigs, so something to keep in mind I guess. The size of the nix store has never really caused me issues, but ending up with a full `/boot` has. I now always set `boot.loader.systemd-boot.configurationLimit` to avoid these issues.
xena 1y ago
Honestly it's not been worth my time. I spent more time shoving things into Nix than I did shipping.
weinzierl 1y ago
What is the supply chain security story with Nix packages? I stick mostly to reasonably popular Debian packages. My thinking is that if one of them has a serious vulnerability it will get fixed quickly or a lot of people have much bigger problems than me. I always worry about niche package systems, where it should be much easier to sneak in something malicious and it could linger there for a long time undetected.
- elsjaako 1y ago
  The source code is retrieved from the official source of the package, and checked against a hash that is stored in the package definitions. All the package definitions are stored in a large github repository, and they are "code reviewed". For example, you can see where the xz sources get pulled from in the src section here: https://github.com/NixOS/nixpkgs/blob/nixos-25.05/pkgs/tools/compression/xz/default.nix#L82 https://github.com/NixOS/nixpkgs/blob/nixos-25.05/pkgs/tools... As usual, wherever you get your software, if someone at the source sneaks in something malicious and no one notices it it gets in there. NixOs has no special mitigations against that (AFAIK). But you can be reasonably sure that the binary you have matches the official source of the software, with maybe some reviewed patches to get it to work in Nix's environment. The binaries are cached, so you don't have to build everything yourself. There is a command to rebuild the software from source yourself. Most packages are reproducible, about 95% of the distributed gnome version: https://reproducible.nixos.org/nixos-iso-gnome-r13y/ https://reproducible.nixos.org/nixos-iso-gnome-r13y/
  - subsection1h 1y ago
    > All the package definitions [...] are "code reviewed". [...] with maybe some reviewed patches to get it to work in Nix's environment. In order for people to review Nix package definitions and patches, do they need to have their keys signed by other Nix contributors they meet in person like Debian contributors do? https://www.debian.org/events/keysigning https://www.debian.org/events/keysigning
    - microtonal 1y ago
spenczar5 1y ago
Something I have always wondered about is how Nix interacts with my editor and language servers. I use emacs. The emacs LSP mode starts up a language server process for a language like Python or Go. If I use Nix to manage development dependencies like my compiler, linting tools, and even language-specific dependencies, then how do I get the LSP and emacs to use the correct Nix-y set of dependencies? To make things extra complex, note that I often work on multiple interdependent projects concurrently; I imagine that makes things even gnarlier. Is there a sane way to manage this sort of thing? Do I end up managing a per-project installation of emacs??
- mplanchard 1y ago
  Easiest thing is to use direnv to load your nix environment (which is just ‘use nix’ or ‘use flake’, support is builtin to direnv), so that all the nix stuff is first in PATH. There are packages to help with this for emacs, like envrc-mode and direnv-mode, that will load the envrc file whenever you’re visiting a file in the project. Then, whenever emacs runs some external command, it’ll pick up the right one. There are similar plugins for vscode, vim, etc
- bigyabai 1y ago
  The "correct way" is flakes, but I don't know if it would cover every edge case. I don't use emacs, but I'd assume you'd arrange it a bit like this: - Install nixpkgs emacs or emacs distribution to your user profile so it links into every shell you open. - Configure system-wide settings with the default emacs config, or with home-manager (https://mynixos.com/home-manager/options/programs.emacs https://mynixos.com/home-manager/options/programs.emacs) - Each project (or group of projects) gets a Nix flake with a derivation specifying which dependencies or LSP packages are needed. When a devshell is spun up, you should have the nixpkgs version of Emacs with your system-wide config and project-specific modifications, handled via version-control. It is a hassle, but in my experience the ROI is very worthwhile. YMMV.
- __MatrixMan__ 1y ago
  For each project, configure a nix devshell to include the appropriate linters etc for that project. Then configure direnv to activate the nix devshell when you cd into the project directory. Then launch your editor from that shell. Since the editor's parent process is the devshell, its PATH var points to that project's dependencies. Or at least that's how I do it. That will make `ruff` or `pyright-langserver` point to whichever version of the tool is bound to that project. So when I run `nix flake update` it updates the tools for only that project and I don't get any crosstalk between projects. As for whether a given linter or language server should be configured for that project, helix looks for .helix/languages.toml in the CWD to decide which ones to load, so that bit of config I handle independently from nix, I just add that file to the repo. Presumably emacs has something similar. So to answer your question: you only get a project-specific version of emacs if you add emacs to the project's devshell. Otherwise whatever was already on your PATH will be used.
sdsd 1y ago
I was so excited to give Nix a chance, but I'd prefer to program in Guile rather than Nix, so now I'm excited to give Guix a chance lol. Going to install it this Wednesday on new laptop, wish me luck
- xhevahir 1y ago
  Better check to make sure your laptop's hardware, particularly WiFi, is compatible. Most aren't.
  - seabombs 1y ago
    You can install/run guix using a nonfree kernel to get around that. https://wiki.systemcrafters.net/guix/nonguix-installation-guide/ https://wiki.systemcrafters.net/guix/nonguix-installation-gu...
- seabombs 1y ago
  I installed it a few months ago, I thought it was pretty good! I couldn't find a prebuilt package mirror in or near Australia though so it was painfully slow to install updates, and I didn't stick with it.
taosx 1y ago
Nope, not yet. I tried that 3 times, once for my mac, then for my linux and once for a project. Every time I gave it a solid try found it lacking so I made a note to wait a few more years. The promise of reproducible systems is so hard to resist but nix brings crazy complexity (not all of it necessary), I'd prefer a system where their package repo has 4 packages but it makes it easy enough to me to bring other packages. Writing nix is like writing functions but in order to remember the arguments and fields of those arguments in another file that you can only access through your browser. Look at any nix file, and tell me where each variable is coming from.
- ThatMedicIsASpy 1y ago
  I have tried NixOS and the out of the box experience isn't bad, neither on my main VM nor my notebook. Everybody points you to flakes and flakes point you do use the unstable branch of nixos and that is where I say no. Then you learn a bunch of things along the way like upgrading replaces your stuff and you have to start again. I've moved to Atomic desktops and can't name anything I am missing. For dev stuff there are containers.
  - pxc 1y ago
    Flakes and the unstable branch of NixOS (the `nixos-unstable` branch of Nixpkgs) are unrelated. Flakes is an "experimental feature" of Nix itself, but it has shipped in stable releases of Nix for years now. There was a time when you had to build an unreleased version of Nix to play with flakes but that was a long time ago. Whether you use a rolling release for the package set, e.g., nixos-unstable or nixpkgs-unstable, is orthogonal to whether or not you use flakes. Fwiw, I generally prefer to run the unstable branches of Nixpkgs. Occasionally you hit something you have an opportunity to fix yourself, but that's not very frequent these days, even on the unstable branches.
- IshKebab 1y ago
  Yeah I think this is a big flaw of declarative systems. I see a Nix derivation that contains `foo: bar`. How do I know what this does? It's pretty much impossible to know without learning all of Nix, because anything can access it. If it was a function call you could just go-to-definition. Environment variables have a similar issue. It's often hard to know what they do because they could be used by basically anything at any time.
yungporko 1y ago
interesting that the author blames "the modern developer tooling ecosystem" for the issue of not being able to reproduce builds, it's still a problem of course but in my experience it was way worse in the past, with most ecosystems i've used adopting some kind of passable package manager now.
mplanchard 1y ago
An unexpected benefit of nix for me was CI caching. It’s easy to set up S3 as a binary cache, and then anything you can express as a nix derivation can be cached so that if nothing has changed, it avoids a build. One fun example is the test database: five years of accumulated migrations were relatively slow to run in various portions of the pipeline. I made a nix derivation that runs postgres, runs migrations, seeds some test data, runs some tests, and then saves the data directory into $out. CI jobs can then load the DB by building that derivation and copying the data files into a local directory. If no migrations or other dependencies have changed, this is virtually instantaneous.
- bigyabai 1y ago
  My last gig was at a place where a guy basically wrote his own job security by reducing a 1hr 40min JS build pipeline down to 2 minutes with Nix caching.
  - remram 1y ago
    FYI by calling it "job security" you imply that this nix caching approach is unmaintainable.
    - pxc 1y ago
      He made himself useful by practicing an uncommon skill, so I understand why it was put that way. But Nix is plenty learnable and Nix hires are possible, so I see what you mean.
    - bigyabai 1y ago
      It's implied because it's true. Throw away the content-adressable cache index and you're back to 2 hour development velocity, so the Nix guy probably gave himself a decade and a half of runway for a workload that mostly amounts to periodically running `nix flake update` and shuffling around version hashes. We already saw this same trend happen where "the CMake guy" or "the Xcode guy" gets wheeled in to solve their domain-specific issue in large enough orgs. I was impressed by this guy's initiative to carve out an equally indispensable niche.
dbalatero 1y ago
I recently had to switch back from Nix, as the way it operated clashed with the corporate IT security controls on my work laptop and prevented me from using it. I just went back to Bash and it honestly works just fine, any rough edges probably don't outweigh how inscrutable Nix tends to be: https://github.com/dbalatero/dotfiles/blob/main/apply https://github.com/dbalatero/dotfiles/blob/main/apply
yakshaving_jgt 1y ago
The time to “give Nix a chance” was already years ago.
greenavocado 1y ago
[flagged]
- nand_gate 1y ago
  That's a shame, is there any funding transparency? Wasn't aware they were EU funded — thought they were independent!
  - greenavocado 1y ago
    [flagged]
    - pxc 1y ago
      This is FUD, plain and simple.
      - DaSHacka 1y ago
        Care to elaborate?
- gjm11 1y ago
  Are you suggesting some connection between "most European" and "some areas of concern", and if so what? Or are you just making two completely independent statements? I'm guessing from past comments of yours that it's the former. But if there's an actual connection, it's very not-obvious to me what it is, and a quick look at the "problems" and "crisis" links you gave doesn't suggest to me any connection with Nix's European-ness.
  - greenavocado 1y ago
    [flagged]
    - gjm11 1y ago
      Do you have some concrete evidence that the Nix project has made bad decisions because it gets money from the EU? I mean, it's not as if other projects, open source or otherwise, funded by companies or lots of random individuals' donations or governments or no one at all, don't make bad decisions all the time. And the specific complaints you make -- "it has bad UX and bad documentation", "when money's available, most of it goes to people who have been involved in the project for ages", etc. -- are ... not exactly unusual in the world of open-source software. Consider two hypothetical worlds. In one, the Nix project has been corrupted by taking money from the EU, just as you say it has. In the other, the Nix project's flaws are just those of a typical open-source software project, and you're imagining it's caused by the project's taking funds from the EU because you really hate the EU. How could I distinguish between those two worlds?
pjmlp 1y ago
For me it is another Gentoo. I had my time trying every new distro that would be popping up on Linux related magazines CD/DVDs up to the mid-2000's (they still do in some European countries), unless it comes on a laptop I can get at the mall computer store, or some customer imposes it on our delivery contract, not really something I want to give a chance to.
- watusername 1y ago
  > some customer imposes it on our delivery contract It's happening: Companies are adopting Nix [0] and you may see such requirement come up some time. [0]: https://github.com/ad-si/nix-companies https://github.com/ad-si/nix-companies
  - pjmlp 1y ago
    In the bubble I live on, classical VMs have become the exception nowadays, containers and serverless deployments are the rule now. I am yet to see any classical VM deployment isn't one variation of Debian, Ubuntu, Red-Hat, SuSE. Note how that list has a certain startup feeling to the company list, not boring big corp.
    - stackskipton 1y ago
      Even if classical VM deployment, I still see a ton of containers. Like our database servers Ansible playbook which run Ubuntu are "Setup OS, mount disks, install docker apt repos, install stable docker, run container. So Nix would let us avoid the Ansible playbook by just installing the Nix file but Ansible playbook is extremely rock solid so it feels like a problem we don't have. Also, we do pay for support for Cassandra to someone and while they officially would support us running on Nix, it's clear their support technicians are much more comfortable with RH or Debian based systems.
    - zylent 1y ago
      Arista, D.E. Shaw, Google are boring big corp Several of those companies (replit) are building their business on nix. With nix, even containers are optional.
kombine 1y ago
I use Nix and Home manager to keep a consistent terminal development environment (Neovim and friends) across my personal computers and on the HPC cluster. I never used NixOS. It took me a while to craft a working and flexible config, but since then I rarely touch it and only update packages once in a while. It works great for my needs.
lemonwaterlime 1y ago
It is possible to use nix simply as a better Homebrew—one where you can update packages without all of your system potentially breaking from package updates. That has happened to many people with brew and it no longer happens to me. That means `nix-env -iA <packagename>`. Is this approach using the full power of nix? No. But in a “worse-is-better” kind of way, just doing this has given me a more stable system than I had with Homebrew. And that’s all I wanted from nix. Flakes and nix-shell are just additional things that I’ve gotten some benefit from over time.
OscarCunningham 1y ago
I recently installed NixOS on my laptop after years of using Debian, and the main difference I noticed was that it's much easier to keep everything clean. For example with Debian I might do something like try to get my GPU to work by installing nouveau, try various configs, then uninstall nouveau and install the Nvidia proprietary drivers. But then when I finally got the GPU working, I'd worry. Are some of those config changes I tried for nouveau still affecting my system? Has all that mucking around left my GPU forever in a suboptimal state? With Nix, it might take just as much tinkering to get the GPU to work. But once I'm done, I know that my system is exactly as I've defined it in configuration.nix. Anything else I tried along the way will just sit inertly in /nix/store until the garbage collector wipes it away.
- layer8 1y ago
  I don’t know. My concept for reproducibility with Debian is a backup of /etc and the list of installed packages (the output of `dpkg --get-selections`). It’s also not difficult to diff one’s /etc with a pristine version, though I haven’t actually needed that in many years.
  - OscarCunningham 1y ago
    I believe 'dpkg --get-selections' lists all packages, not just the ones the user installed. So if I installed some package foo that had a dependency bar, this method would have me carrying around bar even if foo updated to stop depending on it.
    - layer8 1y ago
      You are right. In that case, apt-clone is better, though not universally available.
  - __MatrixMan__ 1y ago
    If that scratches the itch, great. Backups of /etc can't be combined in a way that lets you reliably uncombine them later though, so you're going to be limited in how modular you can make it.
Altern4tiveAcc 1y ago
This article felt like a strong argument against Nix rather than in favor of it. The complexity it brings is just not worth the gains for the majority of people that I know. No, most people won't be happy that Nix breaks dynamic linking. Docker with a Debian Stable base will solve the problems listed for most users, with 1% of the time investment. The author used Nix for 8 years, and I'm not surprised it looks a bit simpler to them now.
- codethief 1y ago
  > No, most people won't be happy that Nix breaks dynamic linking. True. In my case I just enabled nix-ld[0,1] and now everything works flawlessly. [0]: https://github.com/nix-community/nix-ld https://github.com/nix-community/nix-ld [1]: https://wiki.nixos.org/wiki/Nix-ld https://wiki.nixos.org/wiki/Nix-ld
  - nylonstrung 1y ago
    This is one area where Nix needs a sane default I wish Nix-ld was just bundled into Nix
douchescript 1y ago
Nix + flakes & direnv is the perfect dev environment, run it on the Mac and everybody in team can setup any project in seconds. We also have a makefile that sets up Postgres / init,start,stop with a local file socket - so every project instance has it’s own db instance. Very jummy. That said I wish it was easier to be able to pick a specific build of for example ruby like ruby-3.3.7-p123.
Tractor8626 1y ago
Wow. 1) you can python environment with dependencies! (can do that without nix) 2) you can pin dependencies by hash! (can be done with any tool mentioned in article: docker, pip, npm etc) If you can't make reproducible dev environment in 2025 - it is 100% skill issue.
- corndoge 1y ago
  For 1), how? I'm specifically interested in how you handle packages that use C extensions that link system libraries.
  - Tractor8626 1y ago
    In such cases I use either docker or mmdebstrap.
    - corndoge 1y ago
      Nix would work too, and that fact touches on one of the main advantages of Nix - it solves the problem at a low enough level that it works in all cases.
      - Tractor8626 1y ago
        There is hidden assumption what using one tool for everything makes things easier. Does it though? If using one tool is harder than using several - there is no advantage here.
- __MatrixMan__ 1y ago
  Having to think about docker's hashing/caching scheme and also pip's and also npm's and to apply them each separately in CI and in a local environment and in dev/stage/prod... for a large repo that's a lot of work. Easy to overlook whichever one you're less concerned about at the time and put the repo in some kind of inconsistent state where something works here but not there. There's a lot to be said for having a single lockfile for all of them.
PaulDavisThe1st 1y ago
What problem(s) does Nix solve that macOS's .app format does not? For that matter, that ad-hoc Linux packaging solutions involving LD_LIBRARY_PATH and included dependencies? Put differently, doesn't the fundamental complexity of Nix come down to the combination of (a) "every app should get its own dependencies" and (b) "don't include dependencies with each app" ?
- spijdar 1y ago
  Building those applications consistently and reliably, e.g. being able to hop on a random Linux box and be able to build and deploy an application without thinking about where to fetch copies of all the dependencies. Nix’s raison d’etre is really to make developer lives easier, IMO. I don’t use Nix, but I’ve played with other Linux package managers enough to understand the desire for something better, and something that’s actually predictable, especially (emphasis here!) when mixing/matching arbitrary versions of dependencies. I used Gentoo/Gentoo-derivates for several years and it (building random packages with == specific versions) is a sticky problem when using a traditional build system. Of course, once the packages are built then you can do whatever hacks to bundle the dependencies with it. But the hard part is building them in a consistent, “reproducible” way.
  - PaulDavisThe1st 1y ago
    "build and deploy" are two entirely different tasks. Both the macOS .app design, and various ad-hoc Linux packaging strategies deal with the deployment step in a relatively trivial, extremely non-invasive way. The build step is something else entirely, and while I can imagine that for some projects what Nix offers has much value, for others the problem is solved by a permanently deployed build stack (or stacks) whose specificity goes beyond anything that a distro-managed system could offer.
    - __MatrixMan__ 1y ago
      I think you're right that it's the build step where nix provides value. It's about replacing: > a permanently deployed build stack (or stacks) with a consistently deployable build stack. So if you want to distribute a .app package, you could use nix to build it, and then people could download it and install/configure it according to some different scheme. But if it's trivial to reliably instantiate the build stack, why not just ship that instead and dispense with the special format? Then nobody has to wonder if you slipped some malware in the package before you distributed it. The idea behind NixOS is that since we must precisely define our build stack anyway, why not use the same technology to define the rest of our OS. Maybe that's overkill for some, but it sure is handy that there are NixOS users out there so when I want to use something from nixpkgs when defining my dev environment on MacOS it already has the kinks worked out. As for > ...whose specificity goes beyond anything that a distro-managed system could offer. My feeling is that most nix code is not distro managed but rather written by individual project maintainers. We only bother contributing something to nixpkgs if we think it's widely applicable.
zoogeny 1y ago
Nix falls into the camp in my mind that includes Rust: great idea that I just don't have time for right now. Reproducibility is the holy grail, IMO. It is so valuable that any system that actually achieves it will find some longevity and eventually be hammered into a useable form. I believed in the promise when AWS was all about amis. Then I believed in the promise with docker. It seems something like Nix is a natural next step in this evolution. I want it to succeed enough that it gets easy enough for me to use. But for now I'll stick with macOS for my laptop and docker with alpine for my deployments.
- codethief 1y ago
  > Reproducibility is the holy grail, IMO > I'll stick with […] docker with alpine for my deployments Huh. In my experience Alpine is the worst possible base image to use if you care about reproducibility. - The package index's URL cannot be pinned (URL expires on a regular basis) - The downloaded package index itself (tarball) cannot be pinned/cached, either, because old package versions (i.e. the URLs in the tarball) become unavailable after a few weeks. Meanwhile: https://snapshot.debian.org/ https://snapshot.debian.org/ https://snapshot.ubuntu.com/ https://snapshot.ubuntu.com/
  - zoogeny 1y ago
    That is a good point and I should have been more clear. My choice for alpine isn't based on it's reproducibility at all, but its small size. As with anything in engineering there are tradeoffs, there is no singular perfect solution. My choice of alpine was from years ago when I examined the amount of included code in competing docker images and I found the alpine solution was geared towards the least amount of code required to achieve the desired goal (e.g. running a server of a particular kind). That line of thought almost certainly requires a new examination of the available options since the world has changed since I last did a deep dive into docker base images. In a perfect world I want a base image that doesn't contain a single bit extraneous to executing the services I deploy (for whatever expansive definition of "necessary" I arbitrarily choose). And in that perfect world the image is completely reproduceable from a static definition. Oh yeah, and it should be stable/robust, free from exploits, etc. So it might be too strong to say "holy grail" if one interprets that as a singular goal that needs to be fulfilled. I meant it as "one among many" in the list of virtues I look for. That being said, there are a lot of minimal *nixes these days and I would expect Nix would be a contender in that realm as well.
craftkiller 1y ago
> These hashes are computed using SHA-256 Not so fast! The hash story is actually much more complex than that, as this recent article showed: https://bernsteinbear.com/blog/nix-by-hand/ https://bernsteinbear.com/blog/nix-by-hand/ Regardless, the hash function is irrelevant to end-users, I just thought it was interesting that they cooked up such a convoluted scheme.
Modified3019 1y ago
My recent experience being tech support for family and trying to make available some sort of digitized preservation of family photos/history, has been impressing upon me the need to get away from Rube Goldberg systems that only I could possibly understand and modify. My primary filesystem being ZFS already makes having my stuff be accessible to others after my death a bit unrealistic. (Part of my strategy, will be physical redundancy with archival disks and HDDs, and even paper for text information) I’m forever intrigued by the promises of nix, but I have finally accepted that I am not the target audience for what they have built. The nix language is fundamentally at odds with general purpose usability. Even using the package manger on other distros is fraught with gotchas. On an off topic note, I find it fascinating how both my father and grandfather, who are/were quite technically competent, seem to become increasingly and possibly willfully helpless about computers as they get older. I find myself wondering if at some point I will also experience exhaustion of whatever internal energy is needed to fuel technical fluency.
- microtonal 1y ago
  The nix language is fundamentally at odds with general purpose usability. I have contributed or tried to contribute to many distributions (heck, I even worked for a commercial Linux distribution when I was young) and contributing to nixpkgs was an order of magnitude easier than other distributions. Part of it was the GitHub/PR-centered workflow, but the other part is that Nix is a small functional language and the package definitions are not in some arcane weird format like RPM spec files or Debian rules. Also, Nix makes it much easier to refine a derivation/package without actually having to install it on your system.
  - pxc 1y ago
    I want to second this experience. I've never actually submitted my contributions upstream for other distros, but I've maintained repositories for personal use for Ubuntu, openSUSE, Arch, Gentoo, CentOS and Fedora. Writing a new package from scratch based on Nixpkgs is far easier than for other distros, and easy packaging tasks are much easier with Nixpkgs than with other distributions. (It's also much easier to distribute packages without standing up new infrastructure with Nix, since it's source-based and will fall back to source-based builds if you have no established mechanism for distributing binaries.)
codethief 1y ago
Ubuntu user of 15 years here (+ a couple years of tinkering with RedHat, Arch & Gentoo before that). I tried to learn Nix (the language) a couple years ago, didn't like it and got nowhere. Now, two months ago I heard I would be getting a Windows machine at my new client, so I really wanted a way to deterministically generate a Linux VM that worked & felt exactly the same as my usual setup. So I thought back to Nix(OS) and this time I skipped trying to learn Nix and just tried to absorb it from examples and code snippets I would find online (very reminiscent of my experience with Emacs many years ago). Often I would also ask Gemini to explain things to me. Only a few afternoons later I had a working VM[0] that looked and felt exactly as the desktop environment I have carefully curated over 15 years. Now, several weeks later, I also have built a live CD image with that same config and will soon roll out my Nix config to all my Ubuntu machines & Debian servers. I won't look back. I won't deny, though: I still don't like the language too much and I think it is tied too much to building an OS, as opposed to anything else. Documentation is sparse and mediocre at best. But overall it's alright! Things are usually not that complicated, and most of the time they just work! (And if they don't, it's surprisingly easy to navigate the nixpkgs source code and look up what's happening under the hood.) In any case, my new Nix config is so much better than the set of bespoke Bash scripts I've written over the years to (reproducibly?) configure my Ubuntu desktop with i3wm for me. [0]: nixos-generators is magical when you first try it! https://github.com/nix-community/nixos-generators https://github.com/nix-community/nixos-generators (Fine print: Of course with the benefit of hindsight I now know that it's merely a dumb wrapper around things that Nix provides out of the box but oh well.)
- johntash 1y ago
  Are you using NixOS, or are you using Nix + home-manager or something like that to manage your user's stuff?
  - codethief 1y ago
    Just NixOS. When building the VM / live CD I copy my dotfiles into the Nix store and then during first boot-up I copy them into my home dir and set up symlinks. The main reason I decided against home-manager was that it makes my simple symlink setup (~/.foo -> ~/.dotfiles/foo) virtually impossible: Symlinks will always point to the read-only Nix store in one way or another. See https://github.com/nix-community/home-manager/issues/3514 https://github.com/nix-community/home-manager/issues/3514 or one of the countless other tickets on the topic. Through this episode I also learned that home-manager isn't exactly well-documented, either, and also quite opinionated. (Which, to be fair, is not a bad thing – if it works for you, it probably works great.) Finally, not using home-manager was also a risk management decision in that it's probably best to not go all-in on Nix, NixOS, home-manager etc. all at once. Start with the simplest possible config that gets you running, then iterate.
mar0ux 1y ago
p oo de n nn d but vvjjfc. A b
swoorup 1y ago
Nix is great but the user interface is ugly and cryptic. Debugging dependency issues (what depends on this package of particular hash), installing a particular version of a package is just more trouble than something you would get from the likes of npm or cargo. Would I use nix for my servers? Yes. Would I also use nix personally to keep my systems in sync? Yes. Will I recommend nix to others? Absolutely not.
roydivision 1y ago
> More importantly, Docker containers themselves aren’t reproducible—running apt-get update or pip install requests at different times can yield different results, even with the same Dockerfile. apt-get install <package name>=<version> > And frankly, no one really needs Kubernetes, they just have it because everyone and their grandma has it. I digress, that’s a topic for another day. Oh grow up, ffs.
- codethief 1y ago
  > apt-get install <package name>=<version> That's still not reproducible unless you use snapshot.debian.org or snapshot.ubuntu.com as upstream package index.
  - roydivision 1y ago
    You can easily host and manage your own package repository. My point is that this apparent limitation is not in itself a strong enough reason to embark on NIX. Go fill your boots if you want to use NIX, power to you, but be honest about why if you're going to write a piece about it.
    - codethief 1y ago
      > You can easily host and manage your own package repository. Sure, it's not hard but it's work nonetheless, plus you'll incur the costs of maintaining that infrastructure indefinitely. Compare that to creating a Dockerfile which uses https://github.com/reproducible-containers/repro-sources-list.sh https://github.com/reproducible-containers/repro-sources-lis... to fully pin its package sources and calling it a day.
benreesman 1y ago
Nix is still waiting for its GitHub moment. It's possible to live a strictly better life (as an individual or company) via Nix and NixOS but there's still a ton of lore and inside baseball that requires a pressing need to justify learning it all. If there's a serious Nix person in your company or friend group it's time, otherwise be ready for a learning curve that's only worth it if you have one of the problems it solves (if Docker is starting to be a weird init system or devs are finding excuses to go around it). It's the choice of people who can't compromise on anything (Anduril, more and more trading shops, shit like that). Nix is in a bit of a split/argument/fork-prone thing at the moment but it looks like this will settle into a practical/purist thing where everyone can be happy, so go in knowing which crowd is your people. I'm not a purist so listen to one of them if you are. That said: - flakes aren't optional or experimental, they're the default, its a small clique holding it up for years and its getting forked around by everyone serious - flake parts is looking like a lock for the de facto flake standard, something else might come along but the leet stuff is congregating around it - Cachix devenv is a good gateway drug: its better than Docker and easier to graduate from when it gets serious on that component - nix-ld and FHS envs aren't a sin, they fix most all the friction bilugs and should be the default design, I overlay the shebang thing and all the unfree restrictions and all of it: the incompatible by design people are aging out, this will all work flawlessly in a year or two and you can do it today but its inside baseball If you need to support Mac and Linux without the limitations of a strict all-OCI flow it's your best option, if you need a chance in hell against serious supply-chain attacks its your best starting point. If you need to run on a mix of metal and cloud and/or double-virtualizing is an issue its The Way. The best super accessible resource to go from zero to "holy shit computers can do that" is vimjoyer's YouTube. Use sops.nix and your secrets management is solved. Also by Mic92 is nixos-generators, that is basically infinitely portable to anything. juspay's GitHub, srid's GitHub, pretty much all the nixos-asia stuff is galaxy brain next level. It all works great on MacOS if you're not over it yet with the telemetry. (sidebar: telemetry is your biggest computer problem now and your phone addiction is part of the telemetry deal. Linux and Graphene and NextDNS and Proton and stuff are worth it even for Grandma finally. I'm glad the purists do their thing, its an act of service).
- nylonstrung 1y ago
  Couldn't have said it better, this is a perfect description > It's the choice of people who can't compromise on anything (Anduril, more and more trading shops, shit like that). This is crucial- Nix has interhent advantages in certain industries where it IS genuinely easier than any alternatives. We're gonna see adoption start there and disseminate to general tech companies in a more consumerized form IMO
CuriousRose 1y ago
For someone wanting to use nix for the premise of the article (dev environment management), I'd encourage you to checkout Coder[0] which I'm self-hosting personally for my company, but will prove useful once I hire. [0]: https://coder.com https://coder.com
bfrog 1y ago
I’ve tried a few times now, it’s great when you don’t have to actually write nix yourself. At scale though the typeless dictionary style parameter approach is so impossibly unreadable, constantly hunting down some nixos helper and its underspecified parameters is painful. Its honestly a lot of the same pain yaml has at scale. Lack of typing means more burden on me to remember everything, except nix adds to this a really tough debugging story as it’s lazy and the error messages aren’t usually that helpful.

148 points by pacmansyyu 1y ago

I moved to nix around Nov last year and couldn't be happier, the motto 'nix fixes that' is true. First time I can say linux is trouble free. Upgrades are painless. Dev environments, reproducible. Largest repository of packages in the linux world. Next to zero time wasted configuring things. Foundation LLMs now know enough nix to get you out of trouble most of the time. It's perfect as a linux experience.

zachlatta 1y ago
Can you link your dotfiles? I’ve been having trouble figuring out a good way to structure mine
- i915 1y ago
  Try using https://github.com/numtide/blueprint https://github.com/numtide/blueprint
- sshine 1y ago
  Yes, that’s easy. Here’s a very small example: https://github.com/sshine/nix/blob/main/shared/home-manager.nix https://github.com/sshine/nix/blob/main/shared/home-manager.... My servers don’t have that many dotfiles because most server software can be configured in /etc (zsh, vim), while my work computers have a lot of dotfiles symlinked into ~/.config/ via Nix, e.g. VSCodium, ghostty, … Most people prefer to Nix up their dotfiles, which provides some advantages (e.g. universal styling via Stylix), but the main drawback that I’m not buying is: I can’t share my app-specific config with non-Nix users. But if you’re looking for a cheaper (in terms of complexity) dotfiles manager: https://github.com/yarlson/lnk https://github.com/yarlson/lnk
TeeMassive 1y ago
Until your use case hasn't been deciphered by a Nix scribe and then you have to fight the magic.
- johnisgood 1y ago
  Which makes "next to zero time wasted configuring things" false, very much so. You will have to write your own derivation(s) using Nix[1]. In any case, from the article, what does not apply to Guix, too? I am leaning towards Guix because of its language (Scheme, i.e. Lisp-y), but I wonder about the differences between the two, today (besides userbase and hype). [1] https://nix.dev/tutorials/nix-language.html https://nix.dev/tutorials/nix-language.html
  - mplanchard 1y ago
    Mainly the mindshare. Nix has a massive set of packages. You’ll have to build more derivations for guix.
    - johnisgood 1y ago
      I assumed that, but "only" that? I genuinely wonder. I did not get around to try Nix yet.
      - mplanchard 1y ago
        I think it’s “only” that yeah. Both have fundamentally the same capabilities. Nixpgs may provide more out of the box library functionality than guix, I’m not sure, but as far as I know there’s nothing possible in one that isn’t possible in the other. Would be glad to be corrected by anyone with more experience, though. I’ve run NixOS for years now, but have only dabbled with guix.
    - pxc 1y ago
      Guix already has as many packages as Nixpkgs did back when I started using it, and like Nixpkgs, the package set is growing exponentially. What you say is true but it also seems to me like for many, Guix already provides a very useful starting point.
      - mplanchard 1y ago
sepositus 1y ago
Welcome to the honeymoon phase. Mine lasted about a year. Eventually you will have to leave the comfortable area of "those who have done it before" and engage with some long, unwieldy, mostly undecipherable stack trace. When I asked a long-time Nix vet why he thinks people leave, he provided the most insightful answer I've seen yet: they just don't try hard enough.
- atrus 1y ago
  Why is it inevitable that you have to leave the comfortable area of "those who have done it before" though? Most of the benefit of nix for me is maintaining a configuration for a couple computers in a way that's easy to backup, upgrade, and recover with.
  - sepositus 1y ago
    For reference, I use Nix to manage three different machines, always via home-manager and nix-darwin (I left NixOS awhile ago and haven't looked back). I don't think it's "inevitable" that you'll hit the difficulty wall, but certainly likely. As an example, I was recently playing with Pyinfra which is like a pure Python version of Ansible. It turns out that one of the dependencies uses an archaic version of setuptools and the package owner had inserted some _very_ hacky code that ended up breaking on two of my systems. Now I'm relatively experienced with Nix, so it took me a few hours to track down, but it would have been days if not impossible for a beginner. Nowadays I package brew along with my machines and as soon as something smells funky in Nix I just manage it with brew. Much more peaceful.
- nextos 1y ago
  I think Nix is getting an unfair reputation for being too hard. Simple things are IMHO simpler in Nix than in any other distribution, and what one needs to know to accomplish them is tiny. It has basically reduced my sysadmin maintenance tasks to zero. In case of regressions, Nix makes it trivially easy to go back in time 2 or 3 years, cherrypick some packages and install them, or change your entire desktop environment, and then go back to the previous state with no effort. Nix is hard if you need to build something difficult to package or something that has very unusual or dirty build processes. If you need to that regularly, Nix is not worth the effort unless you are an organization that values reproducibility and is prepared to pay for its cost upfront. If these particularly messy usecases are something that you don't encounter so frequently, you can always use an escape hatch to be able to make your install impure. For instance, distrobox is quite convenient to run e.g. an Arch or Ubuntu container. In my case, this has been helpful to run Julia, whose Nix packages are quite brittle.

bigyabai 1y ago

Clutter reduction and version-controlled build/packaging is where Nix wins big-time. With Direnv you can automatically enter a developer shell as soon as you CD into the directory, which is another helpful timesaver.

peterbecich 1y ago
Agreed, and the full NixOS is unnecessary for the developer shell feature and Direnv

krapht 1y ago

I tried to give Nix a chance but I never figured out how to package dependencies that didn't already have a derivation written for them. Particularly since I do a lot of ML work - I never figured out how to handle mixed Python/C++ code with dependencies on CUDA. It's just way easier, even if not reproducible, to build an environment imperatively in Docker.

sepositus 1y ago
The most common answer I've seen is that Python packaging just "doesn't do it right" so it's impossible to get a clean Nix experience with them. Which, to some degree is true, but it also reveals the opinionated nature of Nix and why it often falls flat.
unignorant 1y ago
I do a lot of ML work too and recently gave NixOS a try. It's actually not too hard to just use conda/miniconda/micromamba to manage python environments as you would on any other linux system with just a few lines of configuration. Pretty much just add micromamba to your configuration.nix plus a few lines of config for nix-ld. Many other python/ML projects are setup to use docker, and that's another easy option. I don't have the time or desire to switch all my python/ML work to more conventional Nix, and haven't really had any issues so far.

blueflow 1y ago

Yes, but: du -sh /nix I specifically remember the glibc 2.26/ucontext desaster that triggered an rebuild of the nix world and exhausted all disk space that i had.

atrus 1y ago
Yeah, if you only have nixos on a space constrained device (like my poor old chromebook), you're going to have a bad time. The plus side though if you go all in is that you can build once on something more powerful and just copy the updates to the low powered stuff.
kenmacd 1y ago
du -sh /nix 187G /nix This is with nix.gc = { automatic = true; dates = "weekly"; options = "--delete-older-than 30d"; }; Cleaning up some direnv versions and a `nix-collect-garbage --delete-older-than 5d` would bring it down to around 40G. For me this isn't _too much_ space, but it's easy for an update to download multiple gigs, so something to keep in mind I guess. The size of the nix store has never really caused me issues, but ending up with a full `/boot` has. I now always set `boot.loader.systemd-boot.configurationLimit` to avoid these issues.

xena 1y ago

Honestly it's not been worth my time. I spent more time shoving things into Nix than I did shipping.

weinzierl 1y ago

What is the supply chain security story with Nix packages? I stick mostly to reasonably popular Debian packages. My thinking is that if one of them has a serious vulnerability it will get fixed quickly or a lot of people have much bigger problems than me. I always worry about niche package systems, where it should be much easier to sneak in something malicious and it could linger there for a long time undetected.

elsjaako 1y ago
The source code is retrieved from the official source of the package, and checked against a hash that is stored in the package definitions. All the package definitions are stored in a large github repository, and they are "code reviewed". For example, you can see where the xz sources get pulled from in the src section here: https://github.com/NixOS/nixpkgs/blob/nixos-25.05/pkgs/tools/compression/xz/default.nix#L82 https://github.com/NixOS/nixpkgs/blob/nixos-25.05/pkgs/tools... As usual, wherever you get your software, if someone at the source sneaks in something malicious and no one notices it it gets in there. NixOs has no special mitigations against that (AFAIK). But you can be reasonably sure that the binary you have matches the official source of the software, with maybe some reviewed patches to get it to work in Nix's environment. The binaries are cached, so you don't have to build everything yourself. There is a command to rebuild the software from source yourself. Most packages are reproducible, about 95% of the distributed gnome version: https://reproducible.nixos.org/nixos-iso-gnome-r13y/ https://reproducible.nixos.org/nixos-iso-gnome-r13y/
- subsection1h 1y ago
  > All the package definitions [...] are "code reviewed". [...] with maybe some reviewed patches to get it to work in Nix's environment. In order for people to review Nix package definitions and patches, do they need to have their keys signed by other Nix contributors they meet in person like Debian contributors do? https://www.debian.org/events/keysigning https://www.debian.org/events/keysigning
  - microtonal 1y ago

spenczar5 1y ago

Something I have always wondered about is how Nix interacts with my editor and language servers. I use emacs. The emacs LSP mode starts up a language server process for a language like Python or Go. If I use Nix to manage development dependencies like my compiler, linting tools, and even language-specific dependencies, then how do I get the LSP and emacs to use the correct Nix-y set of dependencies? To make things extra complex, note that I often work on multiple interdependent projects concurrently; I imagine that makes things even gnarlier. Is there a sane way to manage this sort of thing? Do I end up managing a per-project installation of emacs??

mplanchard 1y ago
Easiest thing is to use direnv to load your nix environment (which is just ‘use nix’ or ‘use flake’, support is builtin to direnv), so that all the nix stuff is first in PATH. There are packages to help with this for emacs, like envrc-mode and direnv-mode, that will load the envrc file whenever you’re visiting a file in the project. Then, whenever emacs runs some external command, it’ll pick up the right one. There are similar plugins for vscode, vim, etc
bigyabai 1y ago
The "correct way" is flakes, but I don't know if it would cover every edge case. I don't use emacs, but I'd assume you'd arrange it a bit like this: - Install nixpkgs emacs or emacs distribution to your user profile so it links into every shell you open. - Configure system-wide settings with the default emacs config, or with home-manager (https://mynixos.com/home-manager/options/programs.emacs https://mynixos.com/home-manager/options/programs.emacs) - Each project (or group of projects) gets a Nix flake with a derivation specifying which dependencies or LSP packages are needed. When a devshell is spun up, you should have the nixpkgs version of Emacs with your system-wide config and project-specific modifications, handled via version-control. It is a hassle, but in my experience the ROI is very worthwhile. YMMV.
__MatrixMan__ 1y ago
For each project, configure a nix devshell to include the appropriate linters etc for that project. Then configure direnv to activate the nix devshell when you cd into the project directory. Then launch your editor from that shell. Since the editor's parent process is the devshell, its PATH var points to that project's dependencies. Or at least that's how I do it. That will make `ruff` or `pyright-langserver` point to whichever version of the tool is bound to that project. So when I run `nix flake update` it updates the tools for only that project and I don't get any crosstalk between projects. As for whether a given linter or language server should be configured for that project, helix looks for .helix/languages.toml in the CWD to decide which ones to load, so that bit of config I handle independently from nix, I just add that file to the repo. Presumably emacs has something similar. So to answer your question: you only get a project-specific version of emacs if you add emacs to the project's devshell. Otherwise whatever was already on your PATH will be used.

sdsd 1y ago

I was so excited to give Nix a chance, but I'd prefer to program in Guile rather than Nix, so now I'm excited to give Guix a chance lol. Going to install it this Wednesday on new laptop, wish me luck

xhevahir 1y ago
Better check to make sure your laptop's hardware, particularly WiFi, is compatible. Most aren't.
- seabombs 1y ago
  You can install/run guix using a nonfree kernel to get around that. https://wiki.systemcrafters.net/guix/nonguix-installation-guide/ https://wiki.systemcrafters.net/guix/nonguix-installation-gu...
seabombs 1y ago
I installed it a few months ago, I thought it was pretty good! I couldn't find a prebuilt package mirror in or near Australia though so it was painfully slow to install updates, and I didn't stick with it.

taosx 1y ago

Nope, not yet. I tried that 3 times, once for my mac, then for my linux and once for a project. Every time I gave it a solid try found it lacking so I made a note to wait a few more years. The promise of reproducible systems is so hard to resist but nix brings crazy complexity (not all of it necessary), I'd prefer a system where their package repo has 4 packages but it makes it easy enough to me to bring other packages. Writing nix is like writing functions but in order to remember the arguments and fields of those arguments in another file that you can only access through your browser. Look at any nix file, and tell me where each variable is coming from.

ThatMedicIsASpy 1y ago
I have tried NixOS and the out of the box experience isn't bad, neither on my main VM nor my notebook. Everybody points you to flakes and flakes point you do use the unstable branch of nixos and that is where I say no. Then you learn a bunch of things along the way like upgrading replaces your stuff and you have to start again. I've moved to Atomic desktops and can't name anything I am missing. For dev stuff there are containers.
- pxc 1y ago
  Flakes and the unstable branch of NixOS (the `nixos-unstable` branch of Nixpkgs) are unrelated. Flakes is an "experimental feature" of Nix itself, but it has shipped in stable releases of Nix for years now. There was a time when you had to build an unreleased version of Nix to play with flakes but that was a long time ago. Whether you use a rolling release for the package set, e.g., nixos-unstable or nixpkgs-unstable, is orthogonal to whether or not you use flakes. Fwiw, I generally prefer to run the unstable branches of Nixpkgs. Occasionally you hit something you have an opportunity to fix yourself, but that's not very frequent these days, even on the unstable branches.
IshKebab 1y ago
Yeah I think this is a big flaw of declarative systems. I see a Nix derivation that contains `foo: bar`. How do I know what this does? It's pretty much impossible to know without learning all of Nix, because anything can access it. If it was a function call you could just go-to-definition. Environment variables have a similar issue. It's often hard to know what they do because they could be used by basically anything at any time.

yungporko 1y ago

interesting that the author blames "the modern developer tooling ecosystem" for the issue of not being able to reproduce builds, it's still a problem of course but in my experience it was way worse in the past, with most ecosystems i've used adopting some kind of passable package manager now.

mplanchard 1y ago

An unexpected benefit of nix for me was CI caching. It’s easy to set up S3 as a binary cache, and then anything you can express as a nix derivation can be cached so that if nothing has changed, it avoids a build. One fun example is the test database: five years of accumulated migrations were relatively slow to run in various portions of the pipeline. I made a nix derivation that runs postgres, runs migrations, seeds some test data, runs some tests, and then saves the data directory into $out. CI jobs can then load the DB by building that derivation and copying the data files into a local directory. If no migrations or other dependencies have changed, this is virtually instantaneous.

bigyabai 1y ago
My last gig was at a place where a guy basically wrote his own job security by reducing a 1hr 40min JS build pipeline down to 2 minutes with Nix caching.
- remram 1y ago
  FYI by calling it "job security" you imply that this nix caching approach is unmaintainable.
  - pxc 1y ago
    He made himself useful by practicing an uncommon skill, so I understand why it was put that way. But Nix is plenty learnable and Nix hires are possible, so I see what you mean.
  - bigyabai 1y ago
    It's implied because it's true. Throw away the content-adressable cache index and you're back to 2 hour development velocity, so the Nix guy probably gave himself a decade and a half of runway for a workload that mostly amounts to periodically running `nix flake update` and shuffling around version hashes. We already saw this same trend happen where "the CMake guy" or "the Xcode guy" gets wheeled in to solve their domain-specific issue in large enough orgs. I was impressed by this guy's initiative to carve out an equally indispensable niche.

dbalatero 1y ago

I recently had to switch back from Nix, as the way it operated clashed with the corporate IT security controls on my work laptop and prevented me from using it. I just went back to Bash and it honestly works just fine, any rough edges probably don't outweigh how inscrutable Nix tends to be: https://github.com/dbalatero/dotfiles/blob/main/apply https://github.com/dbalatero/dotfiles/blob/main/apply

yakshaving_jgt 1y ago

The time to “give Nix a chance” was already years ago.

greenavocado 1y ago

[flagged]

nand_gate 1y ago
That's a shame, is there any funding transparency? Wasn't aware they were EU funded — thought they were independent!
- greenavocado 1y ago
  [flagged]
  - pxc 1y ago
    This is FUD, plain and simple.
    - DaSHacka 1y ago
      Care to elaborate?
gjm11 1y ago
Are you suggesting some connection between "most European" and "some areas of concern", and if so what? Or are you just making two completely independent statements? I'm guessing from past comments of yours that it's the former. But if there's an actual connection, it's very not-obvious to me what it is, and a quick look at the "problems" and "crisis" links you gave doesn't suggest to me any connection with Nix's European-ness.
- greenavocado 1y ago
  [flagged]
  - gjm11 1y ago
    Do you have some concrete evidence that the Nix project has made bad decisions because it gets money from the EU? I mean, it's not as if other projects, open source or otherwise, funded by companies or lots of random individuals' donations or governments or no one at all, don't make bad decisions all the time. And the specific complaints you make -- "it has bad UX and bad documentation", "when money's available, most of it goes to people who have been involved in the project for ages", etc. -- are ... not exactly unusual in the world of open-source software. Consider two hypothetical worlds. In one, the Nix project has been corrupted by taking money from the EU, just as you say it has. In the other, the Nix project's flaws are just those of a typical open-source software project, and you're imagining it's caused by the project's taking funds from the EU because you really hate the EU. How could I distinguish between those two worlds?

pjmlp 1y ago

For me it is another Gentoo. I had my time trying every new distro that would be popping up on Linux related magazines CD/DVDs up to the mid-2000's (they still do in some European countries), unless it comes on a laptop I can get at the mall computer store, or some customer imposes it on our delivery contract, not really something I want to give a chance to.

watusername 1y ago
> some customer imposes it on our delivery contract It's happening: Companies are adopting Nix [0] and you may see such requirement come up some time. [0]: https://github.com/ad-si/nix-companies https://github.com/ad-si/nix-companies
- pjmlp 1y ago
  In the bubble I live on, classical VMs have become the exception nowadays, containers and serverless deployments are the rule now. I am yet to see any classical VM deployment isn't one variation of Debian, Ubuntu, Red-Hat, SuSE. Note how that list has a certain startup feeling to the company list, not boring big corp.
  - stackskipton 1y ago
    Even if classical VM deployment, I still see a ton of containers. Like our database servers Ansible playbook which run Ubuntu are "Setup OS, mount disks, install docker apt repos, install stable docker, run container. So Nix would let us avoid the Ansible playbook by just installing the Nix file but Ansible playbook is extremely rock solid so it feels like a problem we don't have. Also, we do pay for support for Cassandra to someone and while they officially would support us running on Nix, it's clear their support technicians are much more comfortable with RH or Debian based systems.
  - zylent 1y ago
    Arista, D.E. Shaw, Google are boring big corp Several of those companies (replit) are building their business on nix. With nix, even containers are optional.

kombine 1y ago

I use Nix and Home manager to keep a consistent terminal development environment (Neovim and friends) across my personal computers and on the HPC cluster. I never used NixOS. It took me a while to craft a working and flexible config, but since then I rarely touch it and only update packages once in a while. It works great for my needs.

lemonwaterlime 1y ago

It is possible to use nix simply as a better Homebrew—one where you can update packages without all of your system potentially breaking from package updates. That has happened to many people with brew and it no longer happens to me. That means `nix-env -iA <packagename>`. Is this approach using the full power of nix? No. But in a “worse-is-better” kind of way, just doing this has given me a more stable system than I had with Homebrew. And that’s all I wanted from nix. Flakes and nix-shell are just additional things that I’ve gotten some benefit from over time.

OscarCunningham 1y ago

I recently installed NixOS on my laptop after years of using Debian, and the main difference I noticed was that it's much easier to keep everything clean. For example with Debian I might do something like try to get my GPU to work by installing nouveau, try various configs, then uninstall nouveau and install the Nvidia proprietary drivers. But then when I finally got the GPU working, I'd worry. Are some of those config changes I tried for nouveau still affecting my system? Has all that mucking around left my GPU forever in a suboptimal state? With Nix, it might take just as much tinkering to get the GPU to work. But once I'm done, I know that my system is exactly as I've defined it in configuration.nix. Anything else I tried along the way will just sit inertly in /nix/store until the garbage collector wipes it away.

layer8 1y ago
I don’t know. My concept for reproducibility with Debian is a backup of /etc and the list of installed packages (the output of `dpkg --get-selections`). It’s also not difficult to diff one’s /etc with a pristine version, though I haven’t actually needed that in many years.
- OscarCunningham 1y ago
  I believe 'dpkg --get-selections' lists all packages, not just the ones the user installed. So if I installed some package foo that had a dependency bar, this method would have me carrying around bar even if foo updated to stop depending on it.
  - layer8 1y ago
    You are right. In that case, apt-clone is better, though not universally available.
- __MatrixMan__ 1y ago
  If that scratches the itch, great. Backups of /etc can't be combined in a way that lets you reliably uncombine them later though, so you're going to be limited in how modular you can make it.

Altern4tiveAcc 1y ago

This article felt like a strong argument against Nix rather than in favor of it. The complexity it brings is just not worth the gains for the majority of people that I know. No, most people won't be happy that Nix breaks dynamic linking. Docker with a Debian Stable base will solve the problems listed for most users, with 1% of the time investment. The author used Nix for 8 years, and I'm not surprised it looks a bit simpler to them now.

codethief 1y ago
> No, most people won't be happy that Nix breaks dynamic linking. True. In my case I just enabled nix-ld[0,1] and now everything works flawlessly. [0]: https://github.com/nix-community/nix-ld https://github.com/nix-community/nix-ld [1]: https://wiki.nixos.org/wiki/Nix-ld https://wiki.nixos.org/wiki/Nix-ld
- nylonstrung 1y ago
  This is one area where Nix needs a sane default I wish Nix-ld was just bundled into Nix

douchescript 1y ago

Nix + flakes & direnv is the perfect dev environment, run it on the Mac and everybody in team can setup any project in seconds. We also have a makefile that sets up Postgres / init,start,stop with a local file socket - so every project instance has it’s own db instance. Very jummy. That said I wish it was easier to be able to pick a specific build of for example ruby like ruby-3.3.7-p123.

Tractor8626 1y ago

Wow. 1) you can python environment with dependencies! (can do that without nix) 2) you can pin dependencies by hash! (can be done with any tool mentioned in article: docker, pip, npm etc) If you can't make reproducible dev environment in 2025 - it is 100% skill issue.

corndoge 1y ago
For 1), how? I'm specifically interested in how you handle packages that use C extensions that link system libraries.
- Tractor8626 1y ago
  In such cases I use either docker or mmdebstrap.
  - corndoge 1y ago
    Nix would work too, and that fact touches on one of the main advantages of Nix - it solves the problem at a low enough level that it works in all cases.
    - Tractor8626 1y ago
      There is hidden assumption what using one tool for everything makes things easier. Does it though? If using one tool is harder than using several - there is no advantage here.
__MatrixMan__ 1y ago
Having to think about docker's hashing/caching scheme and also pip's and also npm's and to apply them each separately in CI and in a local environment and in dev/stage/prod... for a large repo that's a lot of work. Easy to overlook whichever one you're less concerned about at the time and put the repo in some kind of inconsistent state where something works here but not there. There's a lot to be said for having a single lockfile for all of them.

PaulDavisThe1st 1y ago

What problem(s) does Nix solve that macOS's .app format does not? For that matter, that ad-hoc Linux packaging solutions involving LD_LIBRARY_PATH and included dependencies? Put differently, doesn't the fundamental complexity of Nix come down to the combination of (a) "every app should get its own dependencies" and (b) "don't include dependencies with each app" ?

spijdar 1y ago
Building those applications consistently and reliably, e.g. being able to hop on a random Linux box and be able to build and deploy an application without thinking about where to fetch copies of all the dependencies. Nix’s raison d’etre is really to make developer lives easier, IMO. I don’t use Nix, but I’ve played with other Linux package managers enough to understand the desire for something better, and something that’s actually predictable, especially (emphasis here!) when mixing/matching arbitrary versions of dependencies. I used Gentoo/Gentoo-derivates for several years and it (building random packages with == specific versions) is a sticky problem when using a traditional build system. Of course, once the packages are built then you can do whatever hacks to bundle the dependencies with it. But the hard part is building them in a consistent, “reproducible” way.
- PaulDavisThe1st 1y ago
  "build and deploy" are two entirely different tasks. Both the macOS .app design, and various ad-hoc Linux packaging strategies deal with the deployment step in a relatively trivial, extremely non-invasive way. The build step is something else entirely, and while I can imagine that for some projects what Nix offers has much value, for others the problem is solved by a permanently deployed build stack (or stacks) whose specificity goes beyond anything that a distro-managed system could offer.
  - __MatrixMan__ 1y ago
    I think you're right that it's the build step where nix provides value. It's about replacing: > a permanently deployed build stack (or stacks) with a consistently deployable build stack. So if you want to distribute a .app package, you could use nix to build it, and then people could download it and install/configure it according to some different scheme. But if it's trivial to reliably instantiate the build stack, why not just ship that instead and dispense with the special format? Then nobody has to wonder if you slipped some malware in the package before you distributed it. The idea behind NixOS is that since we must precisely define our build stack anyway, why not use the same technology to define the rest of our OS. Maybe that's overkill for some, but it sure is handy that there are NixOS users out there so when I want to use something from nixpkgs when defining my dev environment on MacOS it already has the kinks worked out. As for > ...whose specificity goes beyond anything that a distro-managed system could offer. My feeling is that most nix code is not distro managed but rather written by individual project maintainers. We only bother contributing something to nixpkgs if we think it's widely applicable.

zoogeny 1y ago

Nix falls into the camp in my mind that includes Rust: great idea that I just don't have time for right now. Reproducibility is the holy grail, IMO. It is so valuable that any system that actually achieves it will find some longevity and eventually be hammered into a useable form. I believed in the promise when AWS was all about amis. Then I believed in the promise with docker. It seems something like Nix is a natural next step in this evolution. I want it to succeed enough that it gets easy enough for me to use. But for now I'll stick with macOS for my laptop and docker with alpine for my deployments.

codethief 1y ago
> Reproducibility is the holy grail, IMO > I'll stick with […] docker with alpine for my deployments Huh. In my experience Alpine is the worst possible base image to use if you care about reproducibility. - The package index's URL cannot be pinned (URL expires on a regular basis) - The downloaded package index itself (tarball) cannot be pinned/cached, either, because old package versions (i.e. the URLs in the tarball) become unavailable after a few weeks. Meanwhile: https://snapshot.debian.org/ https://snapshot.debian.org/ https://snapshot.ubuntu.com/ https://snapshot.ubuntu.com/
- zoogeny 1y ago
  That is a good point and I should have been more clear. My choice for alpine isn't based on it's reproducibility at all, but its small size. As with anything in engineering there are tradeoffs, there is no singular perfect solution. My choice of alpine was from years ago when I examined the amount of included code in competing docker images and I found the alpine solution was geared towards the least amount of code required to achieve the desired goal (e.g. running a server of a particular kind). That line of thought almost certainly requires a new examination of the available options since the world has changed since I last did a deep dive into docker base images. In a perfect world I want a base image that doesn't contain a single bit extraneous to executing the services I deploy (for whatever expansive definition of "necessary" I arbitrarily choose). And in that perfect world the image is completely reproduceable from a static definition. Oh yeah, and it should be stable/robust, free from exploits, etc. So it might be too strong to say "holy grail" if one interprets that as a singular goal that needs to be fulfilled. I meant it as "one among many" in the list of virtues I look for. That being said, there are a lot of minimal *nixes these days and I would expect Nix would be a contender in that realm as well.

craftkiller 1y ago

> These hashes are computed using SHA-256 Not so fast! The hash story is actually much more complex than that, as this recent article showed: https://bernsteinbear.com/blog/nix-by-hand/ https://bernsteinbear.com/blog/nix-by-hand/ Regardless, the hash function is irrelevant to end-users, I just thought it was interesting that they cooked up such a convoluted scheme.

Modified3019 1y ago

My recent experience being tech support for family and trying to make available some sort of digitized preservation of family photos/history, has been impressing upon me the need to get away from Rube Goldberg systems that only I could possibly understand and modify. My primary filesystem being ZFS already makes having my stuff be accessible to others after my death a bit unrealistic. (Part of my strategy, will be physical redundancy with archival disks and HDDs, and even paper for text information) I’m forever intrigued by the promises of nix, but I have finally accepted that I am not the target audience for what they have built. The nix language is fundamentally at odds with general purpose usability. Even using the package manger on other distros is fraught with gotchas. On an off topic note, I find it fascinating how both my father and grandfather, who are/were quite technically competent, seem to become increasingly and possibly willfully helpless about computers as they get older. I find myself wondering if at some point I will also experience exhaustion of whatever internal energy is needed to fuel technical fluency.

microtonal 1y ago
The nix language is fundamentally at odds with general purpose usability. I have contributed or tried to contribute to many distributions (heck, I even worked for a commercial Linux distribution when I was young) and contributing to nixpkgs was an order of magnitude easier than other distributions. Part of it was the GitHub/PR-centered workflow, but the other part is that Nix is a small functional language and the package definitions are not in some arcane weird format like RPM spec files or Debian rules. Also, Nix makes it much easier to refine a derivation/package without actually having to install it on your system.
- pxc 1y ago
  I want to second this experience. I've never actually submitted my contributions upstream for other distros, but I've maintained repositories for personal use for Ubuntu, openSUSE, Arch, Gentoo, CentOS and Fedora. Writing a new package from scratch based on Nixpkgs is far easier than for other distros, and easy packaging tasks are much easier with Nixpkgs than with other distributions. (It's also much easier to distribute packages without standing up new infrastructure with Nix, since it's source-based and will fall back to source-based builds if you have no established mechanism for distributing binaries.)

codethief 1y ago

Ubuntu user of 15 years here (+ a couple years of tinkering with RedHat, Arch & Gentoo before that). I tried to learn Nix (the language) a couple years ago, didn't like it and got nowhere. Now, two months ago I heard I would be getting a Windows machine at my new client, so I really wanted a way to deterministically generate a Linux VM that worked & felt exactly the same as my usual setup. So I thought back to Nix(OS) and this time I skipped trying to learn Nix and just tried to absorb it from examples and code snippets I would find online (very reminiscent of my experience with Emacs many years ago). Often I would also ask Gemini to explain things to me. Only a few afternoons later I had a working VM[0] that looked and felt exactly as the desktop environment I have carefully curated over 15 years. Now, several weeks later, I also have built a live CD image with that same config and will soon roll out my Nix config to all my Ubuntu machines & Debian servers. I won't look back. I won't deny, though: I still don't like the language too much and I think it is tied too much to building an OS, as opposed to anything else. Documentation is sparse and mediocre at best. But overall it's alright! Things are usually not that complicated, and most of the time they just work! (And if they don't, it's surprisingly easy to navigate the nixpkgs source code and look up what's happening under the hood.) In any case, my new Nix config is so much better than the set of bespoke Bash scripts I've written over the years to (reproducibly?) configure my Ubuntu desktop with i3wm for me. [0]: nixos-generators is magical when you first try it! https://github.com/nix-community/nixos-generators https://github.com/nix-community/nixos-generators (Fine print: Of course with the benefit of hindsight I now know that it's merely a dumb wrapper around things that Nix provides out of the box but oh well.)

johntash 1y ago
Are you using NixOS, or are you using Nix + home-manager or something like that to manage your user's stuff?
- codethief 1y ago
  Just NixOS. When building the VM / live CD I copy my dotfiles into the Nix store and then during first boot-up I copy them into my home dir and set up symlinks. The main reason I decided against home-manager was that it makes my simple symlink setup (~/.foo -> ~/.dotfiles/foo) virtually impossible: Symlinks will always point to the read-only Nix store in one way or another. See https://github.com/nix-community/home-manager/issues/3514 https://github.com/nix-community/home-manager/issues/3514 or one of the countless other tickets on the topic. Through this episode I also learned that home-manager isn't exactly well-documented, either, and also quite opinionated. (Which, to be fair, is not a bad thing – if it works for you, it probably works great.) Finally, not using home-manager was also a risk management decision in that it's probably best to not go all-in on Nix, NixOS, home-manager etc. all at once. Start with the simplest possible config that gets you running, then iterate.

mar0ux 1y ago

p oo de n nn d but vvjjfc. A b

swoorup 1y ago

Nix is great but the user interface is ugly and cryptic. Debugging dependency issues (what depends on this package of particular hash), installing a particular version of a package is just more trouble than something you would get from the likes of npm or cargo. Would I use nix for my servers? Yes. Would I also use nix personally to keep my systems in sync? Yes. Will I recommend nix to others? Absolutely not.

roydivision 1y ago

> More importantly, Docker containers themselves aren’t reproducible—running apt-get update or pip install requests at different times can yield different results, even with the same Dockerfile. apt-get install <package name>=<version> > And frankly, no one really needs Kubernetes, they just have it because everyone and their grandma has it. I digress, that’s a topic for another day. Oh grow up, ffs.

codethief 1y ago
> apt-get install <package name>=<version> That's still not reproducible unless you use snapshot.debian.org or snapshot.ubuntu.com as upstream package index.
- roydivision 1y ago
  You can easily host and manage your own package repository. My point is that this apparent limitation is not in itself a strong enough reason to embark on NIX. Go fill your boots if you want to use NIX, power to you, but be honest about why if you're going to write a piece about it.
  - codethief 1y ago
    > You can easily host and manage your own package repository. Sure, it's not hard but it's work nonetheless, plus you'll incur the costs of maintaining that infrastructure indefinitely. Compare that to creating a Dockerfile which uses https://github.com/reproducible-containers/repro-sources-list.sh https://github.com/reproducible-containers/repro-sources-lis... to fully pin its package sources and calling it a day.

benreesman 1y ago

Nix is still waiting for its GitHub moment. It's possible to live a strictly better life (as an individual or company) via Nix and NixOS but there's still a ton of lore and inside baseball that requires a pressing need to justify learning it all. If there's a serious Nix person in your company or friend group it's time, otherwise be ready for a learning curve that's only worth it if you have one of the problems it solves (if Docker is starting to be a weird init system or devs are finding excuses to go around it). It's the choice of people who can't compromise on anything (Anduril, more and more trading shops, shit like that). Nix is in a bit of a split/argument/fork-prone thing at the moment but it looks like this will settle into a practical/purist thing where everyone can be happy, so go in knowing which crowd is your people. I'm not a purist so listen to one of them if you are. That said: - flakes aren't optional or experimental, they're the default, its a small clique holding it up for years and its getting forked around by everyone serious - flake parts is looking like a lock for the de facto flake standard, something else might come along but the leet stuff is congregating around it - Cachix devenv is a good gateway drug: its better than Docker and easier to graduate from when it gets serious on that component - nix-ld and FHS envs aren't a sin, they fix most all the friction bilugs and should be the default design, I overlay the shebang thing and all the unfree restrictions and all of it: the incompatible by design people are aging out, this will all work flawlessly in a year or two and you can do it today but its inside baseball If you need to support Mac and Linux without the limitations of a strict all-OCI flow it's your best option, if you need a chance in hell against serious supply-chain attacks its your best starting point. If you need to run on a mix of metal and cloud and/or double-virtualizing is an issue its The Way. The best super accessible resource to go from zero to "holy shit computers can do that" is vimjoyer's YouTube. Use sops.nix and your secrets management is solved. Also by Mic92 is nixos-generators, that is basically infinitely portable to anything. juspay's GitHub, srid's GitHub, pretty much all the nixos-asia stuff is galaxy brain next level. It all works great on MacOS if you're not over it yet with the telemetry. (sidebar: telemetry is your biggest computer problem now and your phone addiction is part of the telemetry deal. Linux and Graphene and NextDNS and Proton and stuff are worth it even for Grandma finally. I'm glad the purists do their thing, its an act of service).

nylonstrung 1y ago
Couldn't have said it better, this is a perfect description > It's the choice of people who can't compromise on anything (Anduril, more and more trading shops, shit like that). This is crucial- Nix has interhent advantages in certain industries where it IS genuinely easier than any alternatives. We're gonna see adoption start there and disseminate to general tech companies in a more consumerized form IMO

CuriousRose 1y ago

For someone wanting to use nix for the premise of the article (dev environment management), I'd encourage you to checkout Coder[0] which I'm self-hosting personally for my company, but will prove useful once I hire. [0]: https://coder.com https://coder.com

bfrog 1y ago

I’ve tried a few times now, it’s great when you don’t have to actually write nix yourself. At scale though the typeless dictionary style parameter approach is so impossibly unreadable, constantly hunting down some nixos helper and its underspecified parameters is painful. Its honestly a lot of the same pain yaml has at scale. Lack of typing means more burden on me to remember everything, except nix adds to this a really tough debugging story as it’s lazy and the error messages aren’t usually that helpful.