6 ms·

I don't understand this. In particular I don't understand the sense in which it is "purely functional". Surely a package manager needs to mutate the state of a

by mjs 14y ago

I don't understand this. In particular I don't understand the sense in which it is "purely functional". Surely a package manager needs to mutate the state of a system, which seems to be an inherently non-functional operation--? If I have a system S1, and then I do S2 = install(S1, "firefox"), does S1 still exist? This bit is also interesting: "Runtime dependencies are found by scanning binaries for the hash parts of Nix store paths (such as r8vvq9kq…). This sounds risky, but it works extremely well."

agumonkey 14y ago
I think of it as git-for-system. All the data lies in the store/repository. Nix offers you to pick different isolated branches as needed.
dons 14y ago
Installing the "same" package doesn't overwrite previous versions -- all packages are persistent -- so dependencies continue to work. It is the mutation of packages, silently breaking API and ABI compatibility, that is the bane of distro management. Nix is a great attempt to address this.
- ori_b 14y ago
  That was solved decades ago with static linking. The bane of distro management is keeping everything as up to date as possible without breaking things.
  - andreasvc 14y ago
    And the bane of static linking is that a vulnerability in say libc will require the re-compilation & upgrade of a gazillion packages.
    - randallsquared 14y ago
      With ubiquitous high bandwidth and huge disk drives, that doesn't seem to be as much of a problem as it used to be.
      - morsch 14y ago
        Yes, but you are still at the mercy of whoever is statically building (and packages) your binaries. Bad for binary linux distributions, worse for proprietary software.
        9mit3t2m9h9a 14y ago
        Nix model is that you work with expressions that allow to build packages from source. Binary packages are provided in format "if you performed build described by hash X you would get the contents of this archive". For proprietary software, you have to consider the binary as-distributed "source" and build a version with proper dynamic linker an library path. Some third party binary wouldn't run as-is on NixOS, but there is a package that sets correct linking settings post-factum.
    - ori_b 14y ago
      Exactly. And is the result different from keeping old versions of libc around and linking all programs you haven't updated against it? From the description, that's what this system does. If dependencies never change in place, you're emulating static linking with a dynamic linker.
bumeye 14y ago
Yep S1 still exists. Nix does not do destructive updating. When you install or update a package, you'll always be able to revert to the previous state. The best explanation of that process can be found in the original paper: Nix: A Safe and Policy-Free System for Software Deployment - http://www.st.ewi.tudelft.nl/~dolstra/pubs/nspfssd-lisa2004-final.pdf http://www.st.ewi.tudelft.nl/~dolstra/pubs/nspfssd-lisa2004-... I really hope nix will become standard practice, it has some significant advantages over existing package managers.
jerf 14y ago
Purely functional does not mean "has no state at all". This meme needs a stake stuck through it, though beats me how to do it. Functional languages exist and do real work. In this case it means that packages are handled as functional programming languages handle data values. New ones are created from old ones, and unreferenced values are cleaned up via garbage collection.
- thurn 14y ago
  It doesn't seem unreasonable to think that "purely functional" means "consisting of pure functions". Why not just say "functional" if that's what is meant?
  - deleted 14y ago
    [deleted]
  - deleted 14y ago
    [deleted]
  - 9mit3t2m9h9a 14y ago
    The aim of Nix is to make function from dependencies to resulting packages a pure function. Nix seems to have achieved it with respect to set of packages installed on a system; the most problematic thing now is that some packages manage to detect CPU version at build time... Fortunately, most of them allow to disable this feature.

by mjs 14y ago

agumonkey 14y ago

I think of it as git-for-system. All the data lies in the store/repository. Nix offers you to pick different isolated branches as needed.

dons 14y ago

Installing the "same" package doesn't overwrite previous versions -- all packages are persistent -- so dependencies continue to work. It is the mutation of packages, silently breaking API and ABI compatibility, that is the bane of distro management. Nix is a great attempt to address this.

ori_b 14y ago
That was solved decades ago with static linking. The bane of distro management is keeping everything as up to date as possible without breaking things.
- andreasvc 14y ago
  And the bane of static linking is that a vulnerability in say libc will require the re-compilation & upgrade of a gazillion packages.
  - randallsquared 14y ago
    With ubiquitous high bandwidth and huge disk drives, that doesn't seem to be as much of a problem as it used to be.
    - morsch 14y ago
      Yes, but you are still at the mercy of whoever is statically building (and packages) your binaries. Bad for binary linux distributions, worse for proprietary software.
      - 9mit3t2m9h9a 14y ago
        Nix model is that you work with expressions that allow to build packages from source. Binary packages are provided in format "if you performed build described by hash X you would get the contents of this archive". For proprietary software, you have to consider the binary as-distributed "source" and build a version with proper dynamic linker an library path. Some third party binary wouldn't run as-is on NixOS, but there is a package that sets correct linking settings post-factum.
  - ori_b 14y ago
    Exactly. And is the result different from keeping old versions of libc around and linking all programs you haven't updated against it? From the description, that's what this system does. If dependencies never change in place, you're emulating static linking with a dynamic linker.

bumeye 14y ago

Yep S1 still exists. Nix does not do destructive updating. When you install or update a package, you'll always be able to revert to the previous state. The best explanation of that process can be found in the original paper: Nix: A Safe and Policy-Free System for Software Deployment - http://www.st.ewi.tudelft.nl/~dolstra/pubs/nspfssd-lisa2004-final.pdf http://www.st.ewi.tudelft.nl/~dolstra/pubs/nspfssd-lisa2004-... I really hope nix will become standard practice, it has some significant advantages over existing package managers.

jerf 14y ago

Purely functional does not mean "has no state at all". This meme needs a stake stuck through it, though beats me how to do it. Functional languages exist and do real work. In this case it means that packages are handled as functional programming languages handle data values. New ones are created from old ones, and unreferenced values are cleaned up via garbage collection.

thurn 14y ago
It doesn't seem unreasonable to think that "purely functional" means "consisting of pure functions". Why not just say "functional" if that's what is meant?
- deleted 14y ago
  [deleted]
- deleted 14y ago
  [deleted]
- 9mit3t2m9h9a 14y ago
  The aim of Nix is to make function from dependencies to resulting packages a pure function. Nix seems to have achieved it with respect to set of packages installed on a system; the most problematic thing now is that some packages manage to detect CPU version at build time... Fortunately, most of them allow to disable this feature.