5 ms·

The PhD thesis that goes with Nix is a really great intro to it. It's very accessible and well-structured. It motivates the need for a new take on package mana

The PhD thesis that goes with Nix is a really great intro to it. It's very accessible and well-structured. It motivates the need for a new take on package management by analogy to memory management in programming languages. It contrasts how software deployment works today (“Fuck it, I’m sure /usr/bin/local/python is a reference to a python 2.7.12 install with PIL available”) to how we used to write software (“Fuck it, I’m sure 0x7FEA6072 is the address of the array of files; so clearly, assuming a 32-bit address space, the seventh file is at 0x7FEA608A.”) In both cases, as long as your assumption was correct, things go swimmingly. But it could be easier and rely less on hoping your assumptions are correct, and more on things that are verifiably true. And that's what Nix offers: a way to build software that is insulated against assumptions and "it works on my machine". Thesis: https://edolstra.github.io/pubs/phd-thesis.pdf https://edolstra.github.io/pubs/phd-thesis.pdf

amelius 6y ago
The downside is that the approach works best when packages are aware of the Nix approach. But the packages have not been written with Nix in mind, and some work is needed per package to adapt to the approach.
- Ericson2314 6y ago
  Nixpkgs has already done much of that work for you, thankfully.
  - amelius 6y ago
    Yes that's true. But some things remain difficult, for example installing the latest version of CUDA. https://discourse.nixos.org/t/cuda-setup-on-nixos/1118/9 https://discourse.nixos.org/t/cuda-setup-on-nixos/1118/9
    - ninjin 6y ago
      Yes, absolutely. Although to be fair, CUDA is a royal pain (although way easier) even on more standard distributions (supporting multiple versions seamlessly is hours and hours of fun and breaks all too easily) and is behind the great majority of time “wasted”. NVIDIA deserves a lot more flak for this than they receive.
      - zetalemur 6y ago
        Very true. Part of the reason is probably that you need the proprietary drivers to use CUDA efficiently and as they are not in the (upstream) kernel you have to use some other tools, like unofficial repositories or the native installer (which doesn't always play well with the OS package manager, system upgrades, etc.). It's a real PITA.
    - sfj 6y ago
      Funny, I was able to install it (for use with pytorch) just a few days ago without a hitch.
      - disgruntledphd2 6y ago
        Did you use conda? It does a lot of the leg work for you.
        sfj 6y ago
        No, I tried conda once, but it downloaded gigs and gigs of data, and I have enough trouble trying to keep nix under control.
  - K0SM0S 6y ago
    It's a true wonder but much like the AUR (read: Archlinux User Repo), it's great 80% of the time when projects have reasonable popularity or committed (even 'niche') support. It's honestly a treat for personal use if you have the mind of a tinkerer, but it's a difficult proposition to sustain in business (you basically end up vendoring yourself if big enough). Nix has a very different proposition that solves from the "inside" a problem that is currently usually solved from the "outside" using e.g. Ansible in ops/infra, or Vagrant in dev. In my perspective, the outside/black-box solution is ultimately brute-force, plain and simple. It works because it scales well, because copying data is cheap enough (re. deduplication, delta sync, etc) You hit limits when systems grow older and complexity creeps in no matter what however, it's an approach that requires a blank slate every now and then. But the inside package approach is elegant in that it's absolute, it's not conjuring a black box that "should just work" if Ubuntu18.04-387lts-32-1.989-2a and my_fav_package.1.1.1.9.3.5-f work fine together, this time around. Sure, there is testing but we're back to the popularity/support limit. In the end, in a world where some of the stack is basically nailed and can be modularized with clear forever-true expectations of I/O (the content, not the hardware), then Nix eventually prevails— but we really have to evolve "LTS" for what it means (like we'd do in construction, electricity, plumbing...), and not a half-trendy windmill / rat race. But we have to think of those systems that could transfer almost-as-is well from now to 2050 or more, not 2025-2030. It's not impossible, it's what COBOL did, does as we speak. I think something like Nix could help shift perception in the right direction, but I expect mindsets to take a good part of the decade to change deeply, if it happens.
- IshKebab 6y ago
  That's really a flaw with how those packages have been designed rather than a flaw with Nix. We've known that it is a terrible idea to put everything into global directories, edit `PATH` and so on for literally decades.
Ericson2314 6y ago
I gotta use pointers? Ugh, sounds hard, I think I'll just stick to DOS. /s

amelius 6y ago

The downside is that the approach works best when packages are aware of the Nix approach. But the packages have not been written with Nix in mind, and some work is needed per package to adapt to the approach.

Ericson2314 6y ago
Nixpkgs has already done much of that work for you, thankfully.
- amelius 6y ago
  Yes that's true. But some things remain difficult, for example installing the latest version of CUDA. https://discourse.nixos.org/t/cuda-setup-on-nixos/1118/9 https://discourse.nixos.org/t/cuda-setup-on-nixos/1118/9
  - ninjin 6y ago
    Yes, absolutely. Although to be fair, CUDA is a royal pain (although way easier) even on more standard distributions (supporting multiple versions seamlessly is hours and hours of fun and breaks all too easily) and is behind the great majority of time “wasted”. NVIDIA deserves a lot more flak for this than they receive.
    - zetalemur 6y ago
      Very true. Part of the reason is probably that you need the proprietary drivers to use CUDA efficiently and as they are not in the (upstream) kernel you have to use some other tools, like unofficial repositories or the native installer (which doesn't always play well with the OS package manager, system upgrades, etc.). It's a real PITA.
  - sfj 6y ago
    Funny, I was able to install it (for use with pytorch) just a few days ago without a hitch.
    - disgruntledphd2 6y ago
      Did you use conda? It does a lot of the leg work for you.
      - sfj 6y ago
        No, I tried conda once, but it downloaded gigs and gigs of data, and I have enough trouble trying to keep nix under control.
- K0SM0S 6y ago
  It's a true wonder but much like the AUR (read: Archlinux User Repo), it's great 80% of the time when projects have reasonable popularity or committed (even 'niche') support. It's honestly a treat for personal use if you have the mind of a tinkerer, but it's a difficult proposition to sustain in business (you basically end up vendoring yourself if big enough). Nix has a very different proposition that solves from the "inside" a problem that is currently usually solved from the "outside" using e.g. Ansible in ops/infra, or Vagrant in dev. In my perspective, the outside/black-box solution is ultimately brute-force, plain and simple. It works because it scales well, because copying data is cheap enough (re. deduplication, delta sync, etc) You hit limits when systems grow older and complexity creeps in no matter what however, it's an approach that requires a blank slate every now and then. But the inside package approach is elegant in that it's absolute, it's not conjuring a black box that "should just work" if Ubuntu18.04-387lts-32-1.989-2a and my_fav_package.1.1.1.9.3.5-f work fine together, this time around. Sure, there is testing but we're back to the popularity/support limit. In the end, in a world where some of the stack is basically nailed and can be modularized with clear forever-true expectations of I/O (the content, not the hardware), then Nix eventually prevails— but we really have to evolve "LTS" for what it means (like we'd do in construction, electricity, plumbing...), and not a half-trendy windmill / rat race. But we have to think of those systems that could transfer almost-as-is well from now to 2050 or more, not 2025-2030. It's not impossible, it's what COBOL did, does as we speak. I think something like Nix could help shift perception in the right direction, but I expect mindsets to take a good part of the decade to change deeply, if it happens.
IshKebab 6y ago
That's really a flaw with how those packages have been designed rather than a flaw with Nix. We've known that it is a terrible idea to put everything into global directories, edit `PATH` and so on for literally decades.

Ericson2314 6y ago

I gotta use pointers? Ugh, sounds hard, I think I'll just stick to DOS. /s