4 ms·

This is pretty wild! It looks like Nix, NixOS, & NixOps replace: - low level package managers (eg rpm, dpkg) - high level package managers (eg yum, apt)

by dbenamy 12y ago

This is pretty wild! It looks like Nix, NixOS, & NixOps replace: - low level package managers (eg rpm, dpkg) - high level package managers (eg yum, apt) - reproducible build tools - configuration managers (eg puppet, chef) - language-specific isolated env tools (eg rvm, virtualenv) - language-specific package managers (eg bundler, pip) - dev environment setup tools (eg vagrant) - vm provisioning tools - configuration source control (I think) (eg etckeeper) - and probably more AND it does all of these with atomic updates that are undoable and never break deps for other programs AND it fixes tons of warts in many of these tools AND it does this all with a unified set of tools that speak a common language! If the day to day details come anywhere close to the high level promise, this seems like it'll be totally amazing.

mtdewcmu 12y ago
It sounds almost too good to be true. The bottom line (as always): * How hard is it to use? * How easy is it to break?
- sparkie 12y ago
  It's easier to use than all of the above, since it just works nearly all of the time - the beauty of having identities for packages and complete dependency chains means that building software on one machine should be reproducible on another machine of the same architecture. Failure to build is not a human-error or missing dependency - it's a bug, and the package distributor is to blame, not the person trying to build. It's difficult to break because packages are immutable, and the /nix/store where they are held is read-only - it can only be modified by a user with root privileges (which should be never), or the nix daemon (which runs as root). The caveat is that packages have identities - you can't simply swap out a dependency for an equivalent version which has a different identity, without also updating all of the dependents of that package. "Swapping out" is the wrong term, since all versions can live alongside each other - it's more that, applications at the bottom of the chain will not automatically receive the updates of dependencies (for bug-fixes, etc) - you must also update all dependents to make use of such bug-fixes. For a bug-fix in the compiler for instance, that effectively means updating the entire distribution. This could open up significant challenges in the area of live-patching on running systems, as the current research and tooling for this is built on the assumption that you can overwrite packages. On the other hand, I actually think Nix provides a better model for live-updating, because immutability is much more suited to making the kind of transactions we really need to perform them. Arguably, shared libraries could be obsoleted and everything could be statically linked too, which could provide performance gains at the cost of memory/storage.
- davorak 12y ago
  It is pretty easy to use as a end user installing packages is no harder then other distributions. It does not have as wide of a selection as Debian, but I have found it easier to use their packaging system. The packaging system is very friendly to beginners since it is straight forward to experiment with writing new packages installing them and then reverting if it does not work quite right. Or even better switching to a different profile with a different set of packages installed and coming back to your experiment later. > How easy is it to break? In the sense that the packages start conflicting with each other? The packages that come with nixpkgs rarely if every caused a conflict with other packages in nixpkgs. When they do I can simply roll back and make changes to the package. If you explicitly mount the read only /nix/store as read/write and alter packages manually you can cause yourself some trouble, but it is something that is explicitly marked as dangerous and nearly unnecessary.
  - mtdewcmu 12y ago
    Back when I had debian on my home machine (a number of years ago), I experienced that dpkg would gradually lose track of the state of the system and become less and less useful over time. Once things got incoherent, there was no putting it back together, and it seemed inevitable after so many upgrades. I don't recall specifics, and I don't want to dwell on it, but just to illustrate how these things are predisposed to experience a kind of entropy death. This one seems to be solving the right problems. But I hope they didn't get too carried away with solving the problem of being functional... that's not a real problem.
    - davorak 12y ago
      > I experienced that dpkg would gradually lose track of the state of the system and become less and less useful over time. Similar experience with ubuntu and upgrading to different versions was my motivation to use nix. It was made worse by my efforts to install cutting edge versions of numpy and scipy at the time. > But I hope they didn't get too carried away with solving the problem of being functional... that's not a real problem. Heh, they are practical bunch, well at least good chunks of nix, nixos, hydra are written in perl and nixops is written in python. I think the main argument for the former was they all knew perl at the time and want to make sure it was reasonable to port to several systems including cygwin on windows thought it is no longer has tier one support.

by dbenamy 12y ago

mtdewcmu 12y ago

It sounds almost too good to be true. The bottom line (as always): * How hard is it to use? * How easy is it to break?

sparkie 12y ago
It's easier to use than all of the above, since it just works nearly all of the time - the beauty of having identities for packages and complete dependency chains means that building software on one machine should be reproducible on another machine of the same architecture. Failure to build is not a human-error or missing dependency - it's a bug, and the package distributor is to blame, not the person trying to build. It's difficult to break because packages are immutable, and the /nix/store where they are held is read-only - it can only be modified by a user with root privileges (which should be never), or the nix daemon (which runs as root). The caveat is that packages have identities - you can't simply swap out a dependency for an equivalent version which has a different identity, without also updating all of the dependents of that package. "Swapping out" is the wrong term, since all versions can live alongside each other - it's more that, applications at the bottom of the chain will not automatically receive the updates of dependencies (for bug-fixes, etc) - you must also update all dependents to make use of such bug-fixes. For a bug-fix in the compiler for instance, that effectively means updating the entire distribution. This could open up significant challenges in the area of live-patching on running systems, as the current research and tooling for this is built on the assumption that you can overwrite packages. On the other hand, I actually think Nix provides a better model for live-updating, because immutability is much more suited to making the kind of transactions we really need to perform them. Arguably, shared libraries could be obsoleted and everything could be statically linked too, which could provide performance gains at the cost of memory/storage.
davorak 12y ago
It is pretty easy to use as a end user installing packages is no harder then other distributions. It does not have as wide of a selection as Debian, but I have found it easier to use their packaging system. The packaging system is very friendly to beginners since it is straight forward to experiment with writing new packages installing them and then reverting if it does not work quite right. Or even better switching to a different profile with a different set of packages installed and coming back to your experiment later. > How easy is it to break? In the sense that the packages start conflicting with each other? The packages that come with nixpkgs rarely if every caused a conflict with other packages in nixpkgs. When they do I can simply roll back and make changes to the package. If you explicitly mount the read only /nix/store as read/write and alter packages manually you can cause yourself some trouble, but it is something that is explicitly marked as dangerous and nearly unnecessary.
- mtdewcmu 12y ago
  Back when I had debian on my home machine (a number of years ago), I experienced that dpkg would gradually lose track of the state of the system and become less and less useful over time. Once things got incoherent, there was no putting it back together, and it seemed inevitable after so many upgrades. I don't recall specifics, and I don't want to dwell on it, but just to illustrate how these things are predisposed to experience a kind of entropy death. This one seems to be solving the right problems. But I hope they didn't get too carried away with solving the problem of being functional... that's not a real problem.
  - davorak 12y ago
    > I experienced that dpkg would gradually lose track of the state of the system and become less and less useful over time. Similar experience with ubuntu and upgrading to different versions was my motivation to use nix. It was made worse by my efforts to install cutting edge versions of numpy and scipy at the time. > But I hope they didn't get too carried away with solving the problem of being functional... that's not a real problem. Heh, they are practical bunch, well at least good chunks of nix, nixos, hydra are written in perl and nixops is written in python. I think the main argument for the former was they all knew perl at the time and want to make sure it was reasonable to port to several systems including cygwin on windows thought it is no longer has tier one support.