6 ms·

A few years ago I heard about Nix and NixOS. I loved the idea, but I did not enjoy the experience. Maybe the problem was I was trying to make it work on a less

A few years ago I heard about Nix and NixOS. I loved the idea, but I did not enjoy the experience. Maybe the problem was I was trying to make it work on a less well-supported platform (I think it was ARM32). But the packages I wanted to install either weren't available, or I kept getting incompatibility errors. I still love the idea, but these days I feel like environment managers like Anaconda make (mutable) Python development a little more manageable, and things like Docker make (mutable) Linux development a little more manageable. Basically these both make it less painful to start over with a fresh "thing" when the system starts to get crufty. In my view, there's a spectrum from "immutable and annoyingly rigid" to "mutable by default and annoyingly unpredictable". And the sweet spot is not at either end, but something like "immutable by default, but mutation is possible".

goosedragons 4y ago
I recently tried Guix which is somewhat similar to Nix in theory. While I loved the idea I did not love dealing with cryptic problems resulting from it. For example I ran into an issue where one R package would only work properly if I installed other packages in a specific order, doing an update though could mess up that order breaking the package. Later updates to R broke support for certain things entirely that I don't see on non-Guix setups either. Plus getting things that required binaries I can't (or easily) compile myself to work is a pain. I just can't justify fiddling with my package manager so much.
- jnxx 4y ago
  I am not sure, but it is possible that R want to be its own package manager which interferes with Guix? A similar problem seems to appear in Python, where there on Distributions like Debian there is kind of a struggle which package manager - the system-defined packages, or the user-defined ones like pip - have the last word. I have used Guix a bit with Common Lisp libraries, and that works like a charm. I also found it useful to be able to use new Emacs packages like the newest version of Magit, without having to install or supersede the OS installation.
  - goosedragons 4y ago
    R does have it's own package manager but I was explicitly not using it because I read there could be issues, instead only installing packages through Guix. It was mainly a problem compiling things within R as if the order of how gcc-toolchain and the R package were setup it straight up wouldn't work. With later versions it just broke entirely and I never managed to fix it.
    - wdkrnls 4y ago
      Despite R being the most commonly packaged software on Guix and it being a GNU project and a "common lisp for dummies" lispy language which is used by millions of students, researchers and data scientists, the developers seem to have a noticeable animosity towards it (although not as much as the "snake people"). This makes me sad, as R users would be the first to sign up for what Guix offers if it worked well and the RcppGuile R package could be used as a template for bridging the gap between the spartan scheme infrastructure and the extremely rich and beginner friendly R infrastructure. I feel like this could also help motivate the Guix developers to improve the documentation and guile porcelain interfaces so they could be used directly instead of the copious bash code they all seem to relish writing.
      - rekado 4y ago
        I don't follow. Are you saying that Guix developers have animosity towards R or the other way around? In any case I haven't seen animosity on either side. FWIW I also wrote guix.install, which lets you install R packages through Guix (whether or not they are available in Guix) from within a running R session. I'm maintaining R packages in Guix and woudl like to see more adoption of Guix among R users, so if you have any recommendations on what pain points there are and how to overcome them I'd be happy to hear them.
    - wdkrnls 4y ago
      I have not experienced that for what it's worth... atleast not after I rebuilt the whole profile.
    - 4y ago
- rowanG077 4y ago
  I mean if you don't want to fiddle with it I really don't get why you would choose Guix to test drive this way of managing your packages. It's the way less mature and less supported Nix.
  - goosedragons 4y ago
    I did try Nix briefly. It was even more confusing to configure for use with R IMO.
  - rekado 4y ago
    Not when it comes to R. I'm terribly biased, but R packaging in Guix is --- in my opinion --- very high quality, purely from source (including bundled minified JavaScript), and the tooling is great too. Unlike R in Nix, Guix does not just automatically wrap R packages, which would lead to build and runtime errors. I would not use R from Nix.
- mattarm 4y ago
  This is my experience with both Nix and Guix. They have advantages but they are different to the point of being unusual. I very much want the benefits of these kinds of systems, but they both produce a run time system (shell environment, whatever) that is not typical of how most people use software. So, while most other people are helping each other out with the "usual" problems, Nix/Guix users have a different set of problems. Sure, they are reproducible problems often shared by all other Nix/Guix users, but those communities are niche compared to what is typical.
- rekado 4y ago
  I would be very happy to see details on your R problems, as I have never encountered anything like that in the many years I have been packaging R things for Guix and supporting R users at the research institute where I work.
smoldesu 4y ago
I use Nix on an array of devices (any combo of x86/aarch64 and Linux/Darwin machines you can imagine), and while I really do love the experience, you're right that ARM is a sticking point. It's been getting better over the past few months, but still not close to x86 packaging parity. On the other side of that coin, I tried switching back to Arch a few weeks ago after ~4 months of NixOS. Maybe it's the sunken-cost fallacy, but Arch didn't make me feel all starry-eyed anymore. Nix feels like a really dependable piece of my workflow now, and it's difficult to imagine myself going back to Homebrew/pacman. > the sweet spot is not at either end, but something like "immutable by default, but mutation is possible". Flatpak tried that, you're welcome to draw your own conclusions on how that turned out. The problem is that your modifications now require build hooks for every update, and you're no longer guaranteed a comprehensive runtime. With Nix, these hooks get re-written into derivations, which (in my experience) provides a more stable, sane alternative to Docker images and Flatpaks. It's also not packaged hermetically, which means that not all Flatpaks will behave the same on all machines. Something as subtle as different environment variables or display server implementations can cause your application not to launch.
- mmcdermott 4y ago
  Is there a way to get it so that UI applications installed with Nix show up in Spotlight Search? I remember that being my big annoyance when I tried using Nix instead of Homebrew on MacOS.
  - smoldesu 4y ago
    Oh, I wouldn't know (my Mac is a dumb terminal for testing and nothing else). They should have appropriate .desktop files for their Linux counterparts, though.
  - pxc 4y ago
    Yeah, if you use a module system like Nix-Darwin or Home Manager: https://github.com/nix-community/home-manager/issues/1341#issuecomment-1190875080 https://github.com/nix-community/home-manager/issues/1341#is... (Hopefully comparable modules are on their way onto the defaults for each of those module systems)
easygenes 4y ago
For x86, the package availability is almost unparalleled. NixOS also has tools and options which are not all pure and declarative, they're just not considered, "the way." I find NixOS to have a bit of a high learning curve, but worth it for the power and reproducibility.
- rgoulter 4y ago
  > For x86, the package availability is almost unparalleled. https://repology.org/repositories/statistics/total https://repology.org/repositories/statistics/total In terms of total number of packages, nixpkgs unstable is at 72k, while AUR is at 68k. I'd bet there are many caveats, though.
  - hailwren 4y ago
    An unfortunate huge one is any way to interact w/ Intel Optimus. I can't be the only dev that wants to eat my gpu cake and have my battery life optimization cake too. Bumblebee and optimus-manager both solve this in the aur.
    - pxc 4y ago
      Bumblebee is well-supported in NixOS. My last mobile NVIDIA hardware has died, but I used it Bumblebee on NixOS for years. https://search.nixos.org/options?channel=22.05&from=0&size=50&sort=relevance&type=packages&query=bumblebee https://search.nixos.org/options?channel=22.05&from=0&size=5... https://search.nixos.org/options?channel=22.05&show=hardware.nvidia.powerManagement.finegrained&from=0&size=50&sort=relevance&type=packages&query=nvidia+prime https://search.nixos.org/options?channel=22.05&show=hardware...
      - hailwren 4y ago
        Oh, this is great info. Thank you. I use optimus-manager and it's 100% not, so I thought I was just SoL.
        4y ago
pca006132 4y ago
I don't think the problem you encountered is due to immutability, the problem is due to the implementation, which is now improved due to better documentation and more package support. The possibility of mutation alone will break a lot of assumptions and make program analysis a lot harder. I personally prefer no mutation at all or only when wrapped inside a cell (UnsafeCell), similar to rust. For the latter kind, we can treat the states as immutable if we don't have a cell, which can help analysis.
- hoosieree 4y ago
  That's fair. I blamed immutability when I should have blamed the implementation. Thanks for helping me realize my mistake. :) Availability of packages is what makes or breaks a distribution, though. If I can't (easily) install the software I need to do my job, I choose a distribution that can. My home Ubuntu server isn't bringing me joy, so maybe now's a good time to give Nix another shot. Fingers crossed for Nvidia driver support...
  - dpatterbee 4y ago
    In my experience the Nvidia driver support has been pretty painless (once you figure out the correct settings in configuration.nix of course), and the availability of packages is by far the best of any linux distro I've used.
    - jcelerier 4y ago
      I've been working on a project that uses Nix, and from an archlinux host with Nvidia hardware it has been very far from painless, with nixGL breaking every time Arch updates glibc
  - pca006132 4y ago
    I think if you don't use some relatively niche packages, nix is fine. However there are some quirks such as setting LD_LIBRARY_PATH for CUDA that may need some tinkering. If you want to give nix another try, I strongly recommend you to use nix flakes and home manager. Nix flakes allows you to pin dependency versions, and home manager provides a lot of configurations for commonly used packages.

goosedragons 4y ago

I recently tried Guix which is somewhat similar to Nix in theory. While I loved the idea I did not love dealing with cryptic problems resulting from it. For example I ran into an issue where one R package would only work properly if I installed other packages in a specific order, doing an update though could mess up that order breaking the package. Later updates to R broke support for certain things entirely that I don't see on non-Guix setups either. Plus getting things that required binaries I can't (or easily) compile myself to work is a pain. I just can't justify fiddling with my package manager so much.

jnxx 4y ago
I am not sure, but it is possible that R want to be its own package manager which interferes with Guix? A similar problem seems to appear in Python, where there on Distributions like Debian there is kind of a struggle which package manager - the system-defined packages, or the user-defined ones like pip - have the last word. I have used Guix a bit with Common Lisp libraries, and that works like a charm. I also found it useful to be able to use new Emacs packages like the newest version of Magit, without having to install or supersede the OS installation.
- goosedragons 4y ago
  R does have it's own package manager but I was explicitly not using it because I read there could be issues, instead only installing packages through Guix. It was mainly a problem compiling things within R as if the order of how gcc-toolchain and the R package were setup it straight up wouldn't work. With later versions it just broke entirely and I never managed to fix it.
  - wdkrnls 4y ago
    Despite R being the most commonly packaged software on Guix and it being a GNU project and a "common lisp for dummies" lispy language which is used by millions of students, researchers and data scientists, the developers seem to have a noticeable animosity towards it (although not as much as the "snake people"). This makes me sad, as R users would be the first to sign up for what Guix offers if it worked well and the RcppGuile R package could be used as a template for bridging the gap between the spartan scheme infrastructure and the extremely rich and beginner friendly R infrastructure. I feel like this could also help motivate the Guix developers to improve the documentation and guile porcelain interfaces so they could be used directly instead of the copious bash code they all seem to relish writing.
    - rekado 4y ago
      I don't follow. Are you saying that Guix developers have animosity towards R or the other way around? In any case I haven't seen animosity on either side. FWIW I also wrote guix.install, which lets you install R packages through Guix (whether or not they are available in Guix) from within a running R session. I'm maintaining R packages in Guix and woudl like to see more adoption of Guix among R users, so if you have any recommendations on what pain points there are and how to overcome them I'd be happy to hear them.
  - wdkrnls 4y ago
    I have not experienced that for what it's worth... atleast not after I rebuilt the whole profile.
  - 4y ago
rowanG077 4y ago
I mean if you don't want to fiddle with it I really don't get why you would choose Guix to test drive this way of managing your packages. It's the way less mature and less supported Nix.
- goosedragons 4y ago
  I did try Nix briefly. It was even more confusing to configure for use with R IMO.
- rekado 4y ago
  Not when it comes to R. I'm terribly biased, but R packaging in Guix is --- in my opinion --- very high quality, purely from source (including bundled minified JavaScript), and the tooling is great too. Unlike R in Nix, Guix does not just automatically wrap R packages, which would lead to build and runtime errors. I would not use R from Nix.
mattarm 4y ago
This is my experience with both Nix and Guix. They have advantages but they are different to the point of being unusual. I very much want the benefits of these kinds of systems, but they both produce a run time system (shell environment, whatever) that is not typical of how most people use software. So, while most other people are helping each other out with the "usual" problems, Nix/Guix users have a different set of problems. Sure, they are reproducible problems often shared by all other Nix/Guix users, but those communities are niche compared to what is typical.
rekado 4y ago
I would be very happy to see details on your R problems, as I have never encountered anything like that in the many years I have been packaging R things for Guix and supporting R users at the research institute where I work.

smoldesu 4y ago

I use Nix on an array of devices (any combo of x86/aarch64 and Linux/Darwin machines you can imagine), and while I really do love the experience, you're right that ARM is a sticking point. It's been getting better over the past few months, but still not close to x86 packaging parity. On the other side of that coin, I tried switching back to Arch a few weeks ago after ~4 months of NixOS. Maybe it's the sunken-cost fallacy, but Arch didn't make me feel all starry-eyed anymore. Nix feels like a really dependable piece of my workflow now, and it's difficult to imagine myself going back to Homebrew/pacman. > the sweet spot is not at either end, but something like "immutable by default, but mutation is possible". Flatpak tried that, you're welcome to draw your own conclusions on how that turned out. The problem is that your modifications now require build hooks for every update, and you're no longer guaranteed a comprehensive runtime. With Nix, these hooks get re-written into derivations, which (in my experience) provides a more stable, sane alternative to Docker images and Flatpaks. It's also not packaged hermetically, which means that not all Flatpaks will behave the same on all machines. Something as subtle as different environment variables or display server implementations can cause your application not to launch.

mmcdermott 4y ago
Is there a way to get it so that UI applications installed with Nix show up in Spotlight Search? I remember that being my big annoyance when I tried using Nix instead of Homebrew on MacOS.
- smoldesu 4y ago
  Oh, I wouldn't know (my Mac is a dumb terminal for testing and nothing else). They should have appropriate .desktop files for their Linux counterparts, though.
- pxc 4y ago
  Yeah, if you use a module system like Nix-Darwin or Home Manager: https://github.com/nix-community/home-manager/issues/1341#issuecomment-1190875080 https://github.com/nix-community/home-manager/issues/1341#is... (Hopefully comparable modules are on their way onto the defaults for each of those module systems)

easygenes 4y ago

For x86, the package availability is almost unparalleled. NixOS also has tools and options which are not all pure and declarative, they're just not considered, "the way." I find NixOS to have a bit of a high learning curve, but worth it for the power and reproducibility.

rgoulter 4y ago
> For x86, the package availability is almost unparalleled. https://repology.org/repositories/statistics/total https://repology.org/repositories/statistics/total In terms of total number of packages, nixpkgs unstable is at 72k, while AUR is at 68k. I'd bet there are many caveats, though.
- hailwren 4y ago
  An unfortunate huge one is any way to interact w/ Intel Optimus. I can't be the only dev that wants to eat my gpu cake and have my battery life optimization cake too. Bumblebee and optimus-manager both solve this in the aur.
  - pxc 4y ago
    Bumblebee is well-supported in NixOS. My last mobile NVIDIA hardware has died, but I used it Bumblebee on NixOS for years. https://search.nixos.org/options?channel=22.05&from=0&size=50&sort=relevance&type=packages&query=bumblebee https://search.nixos.org/options?channel=22.05&from=0&size=5... https://search.nixos.org/options?channel=22.05&show=hardware.nvidia.powerManagement.finegrained&from=0&size=50&sort=relevance&type=packages&query=nvidia+prime https://search.nixos.org/options?channel=22.05&show=hardware...
    - hailwren 4y ago
      Oh, this is great info. Thank you. I use optimus-manager and it's 100% not, so I thought I was just SoL.
      - 4y ago

pca006132 4y ago

I don't think the problem you encountered is due to immutability, the problem is due to the implementation, which is now improved due to better documentation and more package support. The possibility of mutation alone will break a lot of assumptions and make program analysis a lot harder. I personally prefer no mutation at all or only when wrapped inside a cell (UnsafeCell), similar to rust. For the latter kind, we can treat the states as immutable if we don't have a cell, which can help analysis.

hoosieree 4y ago
That's fair. I blamed immutability when I should have blamed the implementation. Thanks for helping me realize my mistake. :) Availability of packages is what makes or breaks a distribution, though. If I can't (easily) install the software I need to do my job, I choose a distribution that can. My home Ubuntu server isn't bringing me joy, so maybe now's a good time to give Nix another shot. Fingers crossed for Nvidia driver support...
- dpatterbee 4y ago
  In my experience the Nvidia driver support has been pretty painless (once you figure out the correct settings in configuration.nix of course), and the availability of packages is by far the best of any linux distro I've used.
  - jcelerier 4y ago
    I've been working on a project that uses Nix, and from an archlinux host with Nvidia hardware it has been very far from painless, with nixGL breaking every time Arch updates glibc
- pca006132 4y ago
  I think if you don't use some relatively niche packages, nix is fine. However there are some quirks such as setting LD_LIBRARY_PATH for CUDA that may need some tinkering. If you want to give nix another try, I strongly recommend you to use nix flakes and home manager. Nix flakes allows you to pin dependency versions, and home manager provides a lot of configurations for commonly used packages.