4 ms·

Almost any system can do that. Package managers typically have a concept of a “selected set” or something o that nature which is often simply a file that conta

Almost any system can do that. Package managers typically have a concept of a “selected set” or something o that nature which is often simply a file that contains all the packages the user wants to install on a new line at some places. Simply copy that file and do a world update with the package manager and it will install all those packages an their dependencies and typically uninstall what is not needed.

Nullabillity 5y ago
NixOS also covers package configuration, not just which packages are installed. And because it owns all of the configuration, it can semi-intelligently merge package configurations that are managed in multiple independent places. It can also be used to apply patches to packages (which are then automatically carried over when the upstream package is updated).
- Blikkentrekker 5y ago
  > NixOS also covers package configuration, not just which packages are installed. And because it owns all of the configuration, it can semi-intelligently merge package configurations that are managed in multiple independent places. Do you mean system configuration in /etc, or also user configuration in /home? In the latter case I do not see how this can ever be implemented, even if an exhaustive list be provided with each package in it's description, quite a bit of software will arbitrarily add new files under new names as part of it's confguration. Usually one simply copies one's entire `~/.config` directory along. > It can also be used to apply patches to packages (which are then automatically carried over when the upstream package is updated). True, but this is also a feature of any source-based system. The real advantage to me seems to be that it is a source-based system but with a central repository for identically configured packages to avoid compilation in many cases.
  - Nullabillity 5y ago
    > Do you mean system configuration in /etc, or also user configuration in /home? NixOS covers /etc, and Home-Manager covers /home. But in practice many applications support configuration from /etc as well, and you will tend to prefer just managing it from there when using NixOS. > In the latter case I do not see how this can ever be implemented, even if an exhaustive list be provided with each package in it's description, quite a bit of software will arbitrarily add new files under new names as part of it's confguration. Hm? If you use Nix to manage the application's configuration then Nix is the only program allowed to change the configuration directly. > Usually one simply copies one's entire `~/.config` directory along. Not the same thing. Nix allows you to express relationships between different application configurations (why does program A try to connect to localhost:9267? oh, ripgrep says that program B is binding that port for RPC...), and lets you stack configurations (so that defaults can be updated automatically, or you can change a specific value for a specific machine without having to maintain two completely separate copies). It's like the difference between giving a new employee access to your source code, vs saying "here's an optimized stripped build, and here's a copy of Ghidra, have fun!". > True, but this is also a feature of any source-based system. In the same sense that you can copy your dotfiles around manually, sure. The difference is that Nix allows you to patch the package definition itself dynamically. AUR/PKGBUILD (the only other source-based system I'm familiar with to be fair, not sure if Gentoo handles this differently) allows you to patch the /application/, but you still need to copy the PKGBUILD and backport all upstream changes.
pxc 5y ago
*Almost any system can attempt that. Nix lets you pin your whole dependency tree, and Nixpkgs includes facilities for managing the configurations of many applications, including integrations with their plugin systems that explicitly manage external runtime dependencies, like stuff your vim configuration might call at the CLI. Without that stuff, reproduction can often fail in practice. And in the case of NixOS, you can also reproduce things like running services and their configurations, which users exist, etc. Those are OS and configuration management features, not package management.

Nullabillity 5y ago

NixOS also covers package configuration, not just which packages are installed. And because it owns all of the configuration, it can semi-intelligently merge package configurations that are managed in multiple independent places. It can also be used to apply patches to packages (which are then automatically carried over when the upstream package is updated).

Blikkentrekker 5y ago
> NixOS also covers package configuration, not just which packages are installed. And because it owns all of the configuration, it can semi-intelligently merge package configurations that are managed in multiple independent places. Do you mean system configuration in /etc, or also user configuration in /home? In the latter case I do not see how this can ever be implemented, even if an exhaustive list be provided with each package in it's description, quite a bit of software will arbitrarily add new files under new names as part of it's confguration. Usually one simply copies one's entire `~/.config` directory along. > It can also be used to apply patches to packages (which are then automatically carried over when the upstream package is updated). True, but this is also a feature of any source-based system. The real advantage to me seems to be that it is a source-based system but with a central repository for identically configured packages to avoid compilation in many cases.
- Nullabillity 5y ago
  > Do you mean system configuration in /etc, or also user configuration in /home? NixOS covers /etc, and Home-Manager covers /home. But in practice many applications support configuration from /etc as well, and you will tend to prefer just managing it from there when using NixOS. > In the latter case I do not see how this can ever be implemented, even if an exhaustive list be provided with each package in it's description, quite a bit of software will arbitrarily add new files under new names as part of it's confguration. Hm? If you use Nix to manage the application's configuration then Nix is the only program allowed to change the configuration directly. > Usually one simply copies one's entire `~/.config` directory along. Not the same thing. Nix allows you to express relationships between different application configurations (why does program A try to connect to localhost:9267? oh, ripgrep says that program B is binding that port for RPC...), and lets you stack configurations (so that defaults can be updated automatically, or you can change a specific value for a specific machine without having to maintain two completely separate copies). It's like the difference between giving a new employee access to your source code, vs saying "here's an optimized stripped build, and here's a copy of Ghidra, have fun!". > True, but this is also a feature of any source-based system. In the same sense that you can copy your dotfiles around manually, sure. The difference is that Nix allows you to patch the package definition itself dynamically. AUR/PKGBUILD (the only other source-based system I'm familiar with to be fair, not sure if Gentoo handles this differently) allows you to patch the /application/, but you still need to copy the PKGBUILD and backport all upstream changes.

pxc 5y ago

*Almost any system can attempt that. Nix lets you pin your whole dependency tree, and Nixpkgs includes facilities for managing the configurations of many applications, including integrations with their plugin systems that explicitly manage external runtime dependencies, like stuff your vim configuration might call at the CLI. Without that stuff, reproduction can often fail in practice. And in the case of NixOS, you can also reproduce things like running services and their configurations, which users exist, etc. Those are OS and configuration management features, not package management.