4 ms·

First yum - "a package manager written in Python" and now Nix - "a purely functional package manager". Well, I for one do not care the least which language or p

First yum - "a package manager written in Python" and now Nix - "a purely functional package manager". Well, I for one do not care the least which language or paradigm my package manager is using. What I do care about is compatibility, reliability, speed and correctness. How is Nix improving the situation for the user?

agumonkey 14y ago
Immutability is often helping correctness, and for the user, a simple way to rollback (as mentioned earlier here). I'm trying to use nix as a main system so it's still hypothetical on my side. That said, nix dev team built a continuous integration system for OSes using nix, that can automate system builds on many arch, it's a good sign.
jamii 14y ago
"Nix is a purely functional package manager. This means that it treats packages like values in purely functional programming languages such as Haskell — they are built by functions that don’t have side-effects, and they never change after they have been built. " "You can have multiple versions or variants of a package installed at the same time. This is especially important when different applications have dependencies on different versions of the same package — it prevents the “DLL hell”." "Nix helps you make sure that package dependency specifications are complete." "Nix has multi-user support. This means that non-privileged users can securely install software. " "Since package management operations never overwrite packages in the Nix store but just add new versions in different paths, they are atomic ... And since package aren’t overwritten, the old versions are still there after an upgrade. This means that you can roll back to the old version" "In addition to downloading binaries automatically if they’re available, Nix can download binary deltas that patch an existing package in the Nix store into a new version." "Nix can be used not only for rolling out packages, but also complete configurations of services. This is done by treating all the static bits of a service (such as software packages, configuration files, control scripts, static web pages, etc.) as “packages” that can be built by Nix expressions. As a result, all the features above apply to services as well: for instance, you can roll back a web server configuration if a configuration change turns out to be undesirable, you can easily have multiple instances of a service (e.g., a test and production server), and because the whole service is built in a purely functional way from a Nix expression, it is repeatable so you can easily reproduce the service on another machine."
- fffggg 14y ago
  "You can have multiple versions or variants of a package installed at the same time. This is especially important when different applications have dependencies on different versions of the same package — it prevents the “DLL hell”." This sounds nice, and it's a direct quote from the product page, but I can guarantee that Nix does nothing of the sort. This would need to be addressed in ld.so. It's simply not possible for a packaging system to solve this problem on a typical unix system.
  - pgeorgi 14y ago
    0install does that by tweaking PATH, LD_LIBRARY_PATH and similar variables. That way, each package gets visibility on the dependencies it requires (in exactly the desired version).
    - fffggg 14y ago
      Environment variables won't work. They're either reset for security (when sudo is invoked, for example) or they bleed inappropriately into sub-processes. There is no reliable way to solve this using environment hints to the dynamic linker. End of story.
      - talex5 14y ago
        With sudo, you just set the variables in the child process (after sudo, not before). Variables can indeed bleed into sub-processes if you're not careful. If the sub-process's command is declared as a dependency then 0install could reset the environment automatically when starting it. Currently, it instead finds a set of libraries that work with the process and its dependencies (which is safe, but could make some cases unsolvable in theory, if a program wanted to run a subcommand which used an incompatible library). Direct support from the dynamic linker would be nice though.
        fffggg 14y ago
        Sudo was an example, and is certainly not the only place this problem occurs. Variables cannot be set in the child process; the linker will have already run by the time you can access your environment. Furthermore, this scheme destroys the utility of LD_* variables, which itself is a non-starter. All setuid binaries will be incompatible with any scheme which involves environment variables controlling the linker -- that's a core element of unix security architecture. Over here [ http://news.ycombinator.com/item?id=3995200 http://news.ycombinator.com/item?id=3995200 ] someone who I believe is the author suggested that this thing uses DT_RPATH, and I've outlined the problems with that mechanism as well. Perhaps I'm coming across as a curmudgeon, if so I apologize. But I've worked on this problem quite deeply and there's just no way to reliably solve it. Modifications to ld.so are an absolute requirement.
chriseidhof 14y ago
Just to clarify: the purely functional part is how the package are managed. Nix itself is mostly written in C++, and I'm not sure, but probably not in a purely functional style.

agumonkey 14y ago

Immutability is often helping correctness, and for the user, a simple way to rollback (as mentioned earlier here). I'm trying to use nix as a main system so it's still hypothetical on my side. That said, nix dev team built a continuous integration system for OSes using nix, that can automate system builds on many arch, it's a good sign.

jamii 14y ago

"Nix is a purely functional package manager. This means that it treats packages like values in purely functional programming languages such as Haskell — they are built by functions that don’t have side-effects, and they never change after they have been built. " "You can have multiple versions or variants of a package installed at the same time. This is especially important when different applications have dependencies on different versions of the same package — it prevents the “DLL hell”." "Nix helps you make sure that package dependency specifications are complete." "Nix has multi-user support. This means that non-privileged users can securely install software. " "Since package management operations never overwrite packages in the Nix store but just add new versions in different paths, they are atomic ... And since package aren’t overwritten, the old versions are still there after an upgrade. This means that you can roll back to the old version" "In addition to downloading binaries automatically if they’re available, Nix can download binary deltas that patch an existing package in the Nix store into a new version." "Nix can be used not only for rolling out packages, but also complete configurations of services. This is done by treating all the static bits of a service (such as software packages, configuration files, control scripts, static web pages, etc.) as “packages” that can be built by Nix expressions. As a result, all the features above apply to services as well: for instance, you can roll back a web server configuration if a configuration change turns out to be undesirable, you can easily have multiple instances of a service (e.g., a test and production server), and because the whole service is built in a purely functional way from a Nix expression, it is repeatable so you can easily reproduce the service on another machine."

fffggg 14y ago
"You can have multiple versions or variants of a package installed at the same time. This is especially important when different applications have dependencies on different versions of the same package — it prevents the “DLL hell”." This sounds nice, and it's a direct quote from the product page, but I can guarantee that Nix does nothing of the sort. This would need to be addressed in ld.so. It's simply not possible for a packaging system to solve this problem on a typical unix system.
- pgeorgi 14y ago
  0install does that by tweaking PATH, LD_LIBRARY_PATH and similar variables. That way, each package gets visibility on the dependencies it requires (in exactly the desired version).
  - fffggg 14y ago
    Environment variables won't work. They're either reset for security (when sudo is invoked, for example) or they bleed inappropriately into sub-processes. There is no reliable way to solve this using environment hints to the dynamic linker. End of story.
    - talex5 14y ago
      With sudo, you just set the variables in the child process (after sudo, not before). Variables can indeed bleed into sub-processes if you're not careful. If the sub-process's command is declared as a dependency then 0install could reset the environment automatically when starting it. Currently, it instead finds a set of libraries that work with the process and its dependencies (which is safe, but could make some cases unsolvable in theory, if a program wanted to run a subcommand which used an incompatible library). Direct support from the dynamic linker would be nice though.
      - fffggg 14y ago
        Sudo was an example, and is certainly not the only place this problem occurs. Variables cannot be set in the child process; the linker will have already run by the time you can access your environment. Furthermore, this scheme destroys the utility of LD_* variables, which itself is a non-starter. All setuid binaries will be incompatible with any scheme which involves environment variables controlling the linker -- that's a core element of unix security architecture. Over here [ http://news.ycombinator.com/item?id=3995200 http://news.ycombinator.com/item?id=3995200 ] someone who I believe is the author suggested that this thing uses DT_RPATH, and I've outlined the problems with that mechanism as well. Perhaps I'm coming across as a curmudgeon, if so I apologize. But I've worked on this problem quite deeply and there's just no way to reliably solve it. Modifications to ld.so are an absolute requirement.

chriseidhof 14y ago

Just to clarify: the purely functional part is how the package are managed. Nix itself is mostly written in C++, and I'm not sure, but probably not in a purely functional style.