4 ms·

Thanks! So let's say I start installing Nix packages. What distro's packages would they end up most similar to? Say, maybe Arch (which mostly leaves things unmo

Thanks! So let's say I start installing Nix packages. What distro's packages would they end up most similar to? Say, maybe Arch (which mostly leaves things unmodified)? Does that mean you basically end up with Arch no matter which distro you're on?

catern 6y ago
Trying to put it politely, but your question seems a bit confused. Arch is not the only distro that strives for minimal modifications on upstream packages. In fact, most distributions work that way - it's Debian and its derivatives that's the outlier, and these days, even Debian rarely patches upstream packages. There is much more to distributions than what patches they apply to their packages. The package manger they use, their default configurations, their compiler toolchain, their C library, their init system, their stance on software freedom, etc etc - much more than just what patches they apply to their packages. But, yes, Nix packages are mostly close to upstream, with occasional patches to improve determinism and reproducibility.
- mehrdadn 6y ago
  Thanks for explaining. I'm (obviously, I thought) not suggesting distros are only about the patches, but patches are a very significant aspect of their raisons d'être to me. I thought most distro maintainers do things like backporting changes though, for security/stability/etc.? Including RedHat, Canonical, the Debian maintainers, etc.? Arch (and I guess Gentoo, and maybe their derivatives like Manjaro) are the only ones I know that minimize upstream package changes. With other popular distros like Fedora, Ubuntu, SUSE, etc. I fully expect they've made custom modifications to some popular packages, but it's been years since I've touched other flavors. You're saying this is wrong and only Debian derivatives tend to do this?
  - catern 6y ago
    Fedora stays close to upstream: https://fedoraproject.org/wiki/Staying_close_to_upstream_projects https://fedoraproject.org/wiki/Staying_close_to_upstream_pro... Ubuntu is a Debian derivative, they patch things heavily, just like Debian. SUSE, I don't know about their policy. I assume they're like RHEL, which starts from Fedora, which is close to upstream, and then backports bugfixes from later versions on to stable branches. Many distros maintain stable branches and just update the packages on that branch when they have security issues. Backporting security fixes has (somewhat) gone out of favor, because backports executed by package maintainers that weren't familiar with the code have caused serious security issues in the past. Of course, distros like RHEL and (I guess) SUSE still do backport security fixes to their stable branches. But they start from a base which is close to upstream - it just diverges more and more as their stable branch gets older and older.
tel 6y ago
In addition to other answers, I think it's important to note that Nix is comparatively very small (but growing!). To that end, the Nixpkgs policies are still in flux and defined somewhat culturally (at least compared to older, larger distros). There's a release schedule for NixPkgs which is being continuously updated, you mostly subscribe to a fixed "channel" which gives you the default set of derivations. If you need something more fresh then you either modify a derivation yourself (hot-patching the distro) or pull something temporarily from master on NixPkgs. This is hugely facilitated by the way Nix allows you to install multiple package versions in parallel without conflict. Finally, Nix is still sometimes a bit of a research project. The "best" way to manage a distro that's being built using this technology is still being uncovered. For instance, there's an upcoming feature (flakes) which hopes to seriously change the way you talk about and consider versions of NixPkgs and NixOS. Using Nix definitely requires some patience with living on the edge of tech. It can be frustrating and less reliable than other repos due both to the bigger challenge of building a repo using Nix's technology and the smaller contributor base. That said, the returns on using this weird technology are really high. The short pitch is something like "zero runtime cost, highly repeatable Docker containers for everything". Of course, the technology works nothing like that, but it really hit some of the big position independence value props of Docker in a way that's lightweight enough to use it for everything.
- takeda 6y ago
  > That said, the returns on using this weird technology are really high. The short pitch is something like "zero runtime cost, highly repeatable Docker containers for everything". Of course, the technology works nothing like that, but it really hit some of the big position independence value props of Docker in a way that's lightweight enough to use it for everything. It simply delivers what docker was promising to deliver.
chpatrick 6y ago
In my experience, nixpkgs packages are modified with the bare minimum to get the upstream code to work.
takeda 6y ago
GuixSD? Only because Guix was build from Nix. Frankly I don't think there's anything else like it. I don't know Arch enough to compare, but there's something also similar to Gentoo, except Nix knows that if source + dependencies + architecture + configuration is the same it will pull compiled version from cache, if something changes it will recompile it. The killer NixOS feature is that it has a single configuration file that's declarative which you can use to describe your OS, so it has something like salt/ansible/chef/puppet built in, and unlike them it's also is truly declarative. For example if you have package installed, to remove it, you just remove it from the list, where in those tools you need to create a state that ensures the package must not be present. Edit: from other comments I see that you meant that packages in arch are not modified, I guess Nix does follow that and only add patches if it absolutely needs them to make application work correctly, but unlike other distros nix also allows user trivially (ignoring the steep curve to learn nix :) to modify a derivation (for example applying patches, changing dependencies, changing ./configure flags) similarly how you would extend a class in OO language. In any other OS to do such customization, you would need to generate a new package, place it in package repo, and worry about your modified package breaking other parts of the system. NixOS will then recompile that package and use it (if you use caching it will pull from cache)

catern 6y ago

Trying to put it politely, but your question seems a bit confused. Arch is not the only distro that strives for minimal modifications on upstream packages. In fact, most distributions work that way - it's Debian and its derivatives that's the outlier, and these days, even Debian rarely patches upstream packages. There is much more to distributions than what patches they apply to their packages. The package manger they use, their default configurations, their compiler toolchain, their C library, their init system, their stance on software freedom, etc etc - much more than just what patches they apply to their packages. But, yes, Nix packages are mostly close to upstream, with occasional patches to improve determinism and reproducibility.

mehrdadn 6y ago
Thanks for explaining. I'm (obviously, I thought) not suggesting distros are only about the patches, but patches are a very significant aspect of their raisons d'être to me. I thought most distro maintainers do things like backporting changes though, for security/stability/etc.? Including RedHat, Canonical, the Debian maintainers, etc.? Arch (and I guess Gentoo, and maybe their derivatives like Manjaro) are the only ones I know that minimize upstream package changes. With other popular distros like Fedora, Ubuntu, SUSE, etc. I fully expect they've made custom modifications to some popular packages, but it's been years since I've touched other flavors. You're saying this is wrong and only Debian derivatives tend to do this?
- catern 6y ago
  Fedora stays close to upstream: https://fedoraproject.org/wiki/Staying_close_to_upstream_projects https://fedoraproject.org/wiki/Staying_close_to_upstream_pro... Ubuntu is a Debian derivative, they patch things heavily, just like Debian. SUSE, I don't know about their policy. I assume they're like RHEL, which starts from Fedora, which is close to upstream, and then backports bugfixes from later versions on to stable branches. Many distros maintain stable branches and just update the packages on that branch when they have security issues. Backporting security fixes has (somewhat) gone out of favor, because backports executed by package maintainers that weren't familiar with the code have caused serious security issues in the past. Of course, distros like RHEL and (I guess) SUSE still do backport security fixes to their stable branches. But they start from a base which is close to upstream - it just diverges more and more as their stable branch gets older and older.

tel 6y ago

In addition to other answers, I think it's important to note that Nix is comparatively very small (but growing!). To that end, the Nixpkgs policies are still in flux and defined somewhat culturally (at least compared to older, larger distros). There's a release schedule for NixPkgs which is being continuously updated, you mostly subscribe to a fixed "channel" which gives you the default set of derivations. If you need something more fresh then you either modify a derivation yourself (hot-patching the distro) or pull something temporarily from master on NixPkgs. This is hugely facilitated by the way Nix allows you to install multiple package versions in parallel without conflict. Finally, Nix is still sometimes a bit of a research project. The "best" way to manage a distro that's being built using this technology is still being uncovered. For instance, there's an upcoming feature (flakes) which hopes to seriously change the way you talk about and consider versions of NixPkgs and NixOS. Using Nix definitely requires some patience with living on the edge of tech. It can be frustrating and less reliable than other repos due both to the bigger challenge of building a repo using Nix's technology and the smaller contributor base. That said, the returns on using this weird technology are really high. The short pitch is something like "zero runtime cost, highly repeatable Docker containers for everything". Of course, the technology works nothing like that, but it really hit some of the big position independence value props of Docker in a way that's lightweight enough to use it for everything.

takeda 6y ago
> That said, the returns on using this weird technology are really high. The short pitch is something like "zero runtime cost, highly repeatable Docker containers for everything". Of course, the technology works nothing like that, but it really hit some of the big position independence value props of Docker in a way that's lightweight enough to use it for everything. It simply delivers what docker was promising to deliver.

chpatrick 6y ago

In my experience, nixpkgs packages are modified with the bare minimum to get the upstream code to work.

takeda 6y ago

GuixSD? Only because Guix was build from Nix. Frankly I don't think there's anything else like it. I don't know Arch enough to compare, but there's something also similar to Gentoo, except Nix knows that if source + dependencies + architecture + configuration is the same it will pull compiled version from cache, if something changes it will recompile it. The killer NixOS feature is that it has a single configuration file that's declarative which you can use to describe your OS, so it has something like salt/ansible/chef/puppet built in, and unlike them it's also is truly declarative. For example if you have package installed, to remove it, you just remove it from the list, where in those tools you need to create a state that ensures the package must not be present. Edit: from other comments I see that you meant that packages in arch are not modified, I guess Nix does follow that and only add patches if it absolutely needs them to make application work correctly, but unlike other distros nix also allows user trivially (ignoring the steep curve to learn nix :) to modify a derivation (for example applying patches, changing dependencies, changing ./configure flags) similarly how you would extend a class in OO language. In any other OS to do such customization, you would need to generate a new package, place it in package repo, and worry about your modified package breaking other parts of the system. NixOS will then recompile that package and use it (if you use caching it will pull from cache)