7 ms·

I firmly believe that Nix (and/or Guix) are the future. I am going to use Nix as the keyword below, but Guix and Nix are so very similar that everything is also

I firmly believe that Nix (and/or Guix) are the future. I am going to use Nix as the keyword below, but Guix and Nix are so very similar that everything is also true for Guix. Snap, Flatpak, Docker, AppImage, etc are all very complex solutions that are actually quite painful to interact with. Nix on the other hand solves the problem extremely well. You can have different complex applications running side by side with very different dependencies trees and they will not cross paths. Every time I see a package being distributed as a Snap, I wonder why. These containered solutions are very complex, trying very hard to emulate FHS with mount namespaces, binding mounting tons of sockets around, and almost always end up mounting all of /home in the container. The don't provide much security, and quite difficult to deal with, and require a daemon. Nix on the other hand has zero containerization requirements. It simply works by ensuring the programs are looking in the right place for the libraries they need. It would be great if more vendors just shipped a Nix derivation (or store path) that was their application stack. It would end version incompatibilities for ever, in a way that isn't a burden for the user. Nix + bubblewrap add all the benefits of snap and flatpak as well. But again, there is no benefit to bubblewrap is if you are just going to blanket allow read-write everywhere anyway. At least with raw bubblewrap you can make these policies actually protect something. Similarly, Nix is easily installed on any existing system. So you can use nix packages on Debian, Ubuntu, Centos, Fedora, DSL, or any other linux distribution because it runs entirely out of /nix. I use nix packages on Archlinux at home, and Debian systems as work. Cross distro development works 100% of the time because Nix doesn't use anything from the distro. Nix (and Guix) are really what the Linux community should be moving towards IMHO. I personally prefer Nix's syntax, but the underlying technologies are so similar I consider them the same. Guix started as a fork of Nix, and one day I hope they decide to end up becoming compatible with each other again.

rekado 6y ago
> Guix started as a fork of Nix This is repeated often but it is an unfortunate misunderstanding. One self-contained component of Nix was used unaltered in Guix: the nix-daemon. Everything else but the daemon (and that's a lot) is a completely independent implementation of the same principles that were first demonstrated in Nix: functional package management. Why reuse the daemon? Because it could be done. The daemon takes very low level build instructions ("derivations") and arranges for them to be executed in an isolated environment. In Guix derivations are generated through compilation of higher level concepts that as such have no correspondence in Nix. The common ground is the format of the derivation, which has only been modified occasionally to better suit our differing needs.
- georgyo 6y ago
  My point was more than guix and nix could both write to the same store using a single daemon compatible with both in the future. Ensuring some cooperation between the two going forward. That currently isn't possible, but would be nice. I imagine it could only work for packages, not for system configuration. But that still would be a huge win.
  - rekado 6y ago
    System configuration is also just another store item, really. The current development, however, is to move away from the old nix-daemon and to (slowly) finish its replacement that reuses all of the other existing Guix features for process isolation and building. This is desirable as there are minor annoying differences between the build environment spawned by the C++ daemon and the environment one would get using "guix environment --container". Unifying this by simply using Guile on both sides of the divide (build side vs host side) would allow for more code reuse within Guix and unlock a few features. It's not a high priority because the modified nix-daemon works fine for now, but a CS student is moving forward with the Guile daemon as a university project now. So the dream of sharing the same daemon may not be realistic. I think that this is not a big deal, because the daemon really should serve the project and as the needs of the two projects diverge so do their respective daemons.
    - georgyo 6y ago
      System configuration is just another store item, but symlinked, copied, or referenced by other places outside the store as well. Such as systemd services. You're likely right though that compatibility between the two projects will continue diverge. My true dream was that vendors wouldn't have to build for Snap, Flatpak, Guix, and Nix. They could just use either Guix or Nix and have something usable by either user base. In the end the outputs are just writing stuff to the store. But the fact that the store paths are already different would make it a huge migration for that path to change in the future, and unlikely to ever happen. Still, I can dream.
viraptor 6y ago
One thing that flatpak has over nix is the set of common bases. If I was going to distribute something shifted from nix, I'd essentially need to move every single dependency (which needs to be compiled/configured right). It's not a huge problem for a cli tool in golang, but something that requires qt, GL, input method support, etc.? I'm glad there's a flatpak base for those that not only "just works", and it's going to be maintained/distributed even of the app isn't.
- mbakke 6y ago
  I'm not sure I understand this argument. The main difference when compiling is that you use --prefix=$output instead of --prefix=/usr (which is nicely abstracted away by build systems). You can 'guix pack -RR ibus qutebrowser', copy the resulting binaries to any GNU/Linux system, and still expect them to work.
  - viraptor 6y ago
    Yes you can, but you have to compile and distribute them all. And again distribute every single update for them. You end up with "nothing changed in my app, but there's the whole package again with a fixed deep dependency of foo". (Or more likely, no update)
    - mbakke 6y ago
      Right. Referring to exact versions of dependencies is a feature of the functional package management model. How else can you guarantee that the program will behave exactly the same every time you run it? Guix (unlike Nix) supports "grafts", so you can change something deep in the graph without having to compile every dependent package again. But grafts also produce different store items of course, so no big difference for "guix pack".
      - georgyo 6y ago
        You can also do this in nix. https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/replace-dependency.nix https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-supp...
LockAndLol 6y ago
Nix and Guix have too steep of a learning curve. Maybe someday I'll be willing to invest the time to understand what's going on, but the CLI and docs just aren't good enough to go from "I know nothing" to "ah, I can install the latest <firefox,inkscape,chromium,etc.>". It really isn't clear to me how to switch a running system's package manager to either or even if either is fit to be the system's main package manager. I watched a video of a seasoned linux user trying to install nix and abandoning the procedure because of the lack of docs. I even downloaded a virtualbox image of NixOS and tried to update everything to the latest version: 30 minutes later only firefox was installed but it wasn't in PATH thus couldn't be executed. Never found out how to install the KDE desktop. Guix was another beast that I tried installing as a non-root user (insisted on using `curl | bash`, which I loathe). It was never up to date and I couldn't find the package I wanted to install (so fancy new chromium wrapper.. next-browser or something). Maybe now things are better, but back then (1-2 years ago), neither were anywhere close to modern GUI distros. Until they make it easy to use, it's going to stay niche.
- mbakke 6y ago
  Guix has never insisted on 'curl | bash'. At first there were no instructions on how to use the shell installer script (perhaps you translated to 'curl | bash'?), but now the manual explicitly recommends to wget and chmod it: https://guix.gnu.org/manual/devel/en/guix.html#Binary-Installation https://guix.gnu.org/manual/devel/en/guix.html#Binary-Instal... I think you'll find that things are much more up to date nowadays. You still need root access for the guix-daemon though.
- IngoBlechschmid 6y ago
  I realize that you just cited two particular issues as examples for a deeper problem. But still: The command `nix-shell -p firefox` spawns a subshell in which Firefox is in the PATH. (In case Firefox has not been downloaded before, it will by this command.) Others shells are unaffected by this command, and in fact, it is possible to have different versions of Firefox available in other subshells. This feature might be especially useful to web developers interested in gauging compatibility of their sites with different versions of browsers. To enable KDE, you put this into your configuration.nix: services.xserver.desktopManager.plasma5.enable = true; Perhaps you are also interested in the following cheatsheet: https://nixos.wiki/wiki/Cheatsheet https://nixos.wiki/wiki/Cheatsheet I've been using NixOS since 2017 and don't ever want to look back. I agree that NixOS is not anywhere close to modern GUI distros, but do like the documentation, and the friendliness and speed of the community.
AnIdiotOnTheNet 6y ago
> Snap, Flatpak, Docker, AppImage, etc are all very complex solutions that are actually quite painful to interact with. Uh... what? You're comparing these things against Guix and Nix, which require you to learn a new language to use. Not to mention that AppImage, at least, is only complex because it kinda has to be in order to be portable, single-file, directly-executable application. Which is to say, it is only complex in its implementation so that it can be much less painful to interact with [0]. > Nix on the other hand solves the problem extremely well. You can have different complex applications running side by side with very different dependencies trees and they will not cross paths. Which AppImage can do without you having to learn a new language, and as a bonus will even let you store those applications on entirely different media without recompilation or anything. > Similarly, Nix is easily installed on any existing system. AppImages work on most Linux systems, which is about as well as anyone can do with something that requires no pre-installed runtime. [0] and it actually isn't that complex really.
- rekado 6y ago
  > Guix and Nix [...] require you to learn a new language Not true. `guix install foo`, done. Oh, you want to define an operating system declaratively in a file? Yeah, learn the DSL that was designed to let you do just that.
  - AnIdiotOnTheNet 6y ago
    So the thing that is the primary value proposition of the system, yeah?
    - mbakke 6y ago
      I think the package managers themselves, with unprivileged operation, immutable profiles, atomic upgrades and rollbacks, "guix pack", etc are the main value propositions. The OS thing is mostly a side effect.
      - AnIdiotOnTheNet 6y ago
chongli 6y ago
The problem with nix is that it defeats the purpose of shared libraries. Normally, when you upgrade a shared library, all consumers of it get fixed for free. With nix every package is siloed into its own separate dependency graph and so you can have many versions of a shared library coexisting on the system but each version may be used only by one consumer. That means upgrading one will not affect all the others. So then the only way to get consumers of a shared library to upgrade is to upgrade the consumers as well. Well then why not switch to static linking and be done with it? It would be much simpler that way.
- ochoseis 6y ago
  IIUC, it’s more nuanced than that. The shared library would be specified as a dependency to the packages that rely on it. Pushing a fix to the library would trigger a rebuild of all the downstream packages during the next upgrade. This also means updates to a popular dependency will cause long upgrades.
- claudiojulio 6y ago
  From a security point of view, the Debian for example, seems to be much more reliable. It does not leave you at the mercy of libraries with security holes. Automatically translated.
- dnr 6y ago
  This is not actually a problem in practice. I had this misconception too before I started using it, though. I'll explain for Nix, since I've used it, but I assume Guix works similarly: Packages as defined in nixpkgs don't depend on specific versions of shared libraries. They depend on the library by name, just as they do in any other OS. So a single update in nixpkgs addresses all packages on the system "for free", including ones defined outside of nixpkgs, because they're almost certainly going to depend on nixpkgs for those libraries (I mean, they could duplicate the definitions, but why would they?). Built packages depend on specific versions. So you just have to be sure to update all your built packages. How does that happen? Well, packages are installed because they're requested by name somewhere, either NixOS system packages, or from home-manager, or from a dev environment. Those names point to packages in nixpkgs. So when you update your nixpkgs version (using nix-channel or flake update or however you're doing it), and then rebuild NixOS or update home-manager, you get updated versions of everything. If you're using a nix-based dev environment with pinned nixpkgs (with niv or a flake or whatever), you'll have to update that pin as well, for each project. I suppose you could claim that this makes it easy to use old dependencies. Perhaps, but the entire point of pinning the nixpkgs version is to make everything 100% reproducible, bugs and all, all the way down your dependency stack. So you have to make a deliberate choice between trade-offs there, which seems fair. As far as static linking, nix is essentially static linking, except that you still get the benefits of shared disk space and shared memory for .so files. "True" static linking might be simpler if your dependencies happen to be .so files that also have .a files, but many things aren't, e.g. dependencies among python modules, depending on other binaries to exec, data files, etc. Nix lets you "statically link" all of those too.
agumonkey 6y ago
nix/guix = academia and like conceptualism others = industry and leverage existing subsystems that's why
- georgyo 6y ago
  I don't know what you think is needed for nix/guix that has not existed the past 20 years. All the other technologies I mentioned require fairly recent kernels to work, namely for all the namespace shenanigans they employ. Nix can run on perfectly fine on at least Linux 3.2 (stock wheezy), so far as I tested.
  - agumonkey 6y ago
    I never implied nix needed anything quite the opposite, it was somehow from-scratch thinking, on the other systems were more inspired by new linux features to solve a slightly similar issue.
- rgoulter 6y ago
  I think this is about right. Nix feels pretty close to "right thing to do", but if the other solutions are more successful, it's a case of "worse is better". I think the important part is usability compared to what's already there. It's much easier to write a Dockerfile than to write something with Nix. You can get much stronger benefits from Nix than from a Dockerfile.. but, most of which you don't really need all the time. My impression is the other solutions are quick-ish hacks to solve problems that come from (and building upon) the complexities of systems built using quick-ish hacks. Nix feels like a more elegant solution, but it's also different enough that it's got a steep learning curve for anything harder than "install foo".
  - civodul 6y ago
    I think users may find it easier to create a Docker image with `guix pack -f docker app1 app2` than to write a Dockerfile. As a bonus, the resulting Docker image is bit-reproducible and recipients of the image can "map it back" to the original Guix revision. https://guix.gnu.org/manual/en/html_node/Invoking-guix-pack.html https://guix.gnu.org/manual/en/html_node/Invoking-guix-pack....
appehuli 6y ago
I don't understand some details about Nix when people talk about it. Forgive me for being ignorant. * Do packages need to be 'ported' to Nix or its build / install system? If so, how much effort will it take and on what factors the effort required to port may vary substantially? (eg: Programming Language). * How is disk space usage? Is there any kind of deduplication? * How are security updates to shared libraries handled? * Transactional upgrades look great. But how is the user experience around Transactional upgrades of running GUI applications? * Other performance characteristics - bandwidth (delta upgrades possible?), startup time (I hope this will be good)..
- siraben 6y ago
  Note: these points concern Nix, the situation may be different on Guix > * Do packages need to be 'ported' to Nix or its build / install system? If so, how much effort will it take and on what factors the effort required to port may vary substantially? (eg: Programming Language). Yes. To make Nix really work it has to be pervasive and this sometimes means porting packages again, however there's a lot of automation around this, see[0] for ones that leverage existing build systems in other languages. Autoconf and cmake packages are already accounted for by the default builder, and usually only the dependencies have to be specified. > * How is disk space usage? Is there any kind of deduplication? The Nix store can be intensive on memory, as once a dependency such as glibc is updated, all the reverse dependencies (i.e. the set X such that X depends on glibc directly or transitively) have to be rebuilt as well. There is an option to optimise the store, but I don't know how much it helps in practice, see[1]. Garbage collection can be invoked manually or automatically to free up unused store entries. > * Other performance characteristics - bandwidth (delta upgrades possible?), startup time (I hope this will be good).. By startup time you might be referring to NixOS. It's very good on my Late 2013 13-inch MacBook Pro, around 20 seconds to go from cold boot to login screen. [0] https://github.com/svanderburg/node2nix https://github.com/svanderburg/node2nix https://github.com/NixOS/cabal2nix https://github.com/NixOS/cabal2nix https://github.com/cargo2nix/cargo2nix https://github.com/cargo2nix/cargo2nix https://github.com/nix-community/poetry2nix https://github.com/nix-community/poetry2nix https://github.com/kamilchm/go2nix https://github.com/kamilchm/go2nix https://github.com/nix-community/pip2nix https://github.com/nix-community/pip2nix [1] https://nixos.wiki/wiki/Storage_optimization https://nixos.wiki/wiki/Storage_optimization
sergeykish 6y ago
And it is easy to install software that's not packaged by distribution, ungoogled chromium [1]: $ nix-env -iA nixpkgs.ungoogled-chromium $ which chromium /home/sergeykish/.nix-profile/bin/chromium [1] https://search.nixos.org/packages?channel=20.09&show=ungoogled-chromium&from=0&size=30&sort=relevance&query=ungoogled https://search.nixos.org/packages?channel=20.09&show=ungoogl...
- civodul 6y ago
  Or: guix install ungoogled-chromium This CLI difference is in part due to the underlying design, which is not just about syntax (parens vs. braces) but more about abstractions and composition. For example, the Nix language doesn't have the ability to define new data types, and it doesn't have a "package" or an "operating system" data type. That means that all the entries in Nixpkgs look alike, which in turn prevents building a "package-aware" or "OS-aware" user interface. The Guix CLI "knows" about packages and versions, and package transformation options are an example of how the CLI can take advantage of that abstraction. Likewise, the "guix system" command knows about services, which gives it convenient introspection capabilities such as "guix system extension-graph" and "guix system shepherd-graph". It really isn't about parentheses vs. braces. :-)
  - eliaspro 6y ago
    This is what annoys me about Nix the most - the missing abstraction of those, resulting in an often cumbersome UX and a very steep learning curve. Guix on the other hand provides those, but is far from what nixpkgs offers in terms of number and actuality of pkgs.
    - mbakke 6y ago
      I think it's somewhat unfair to use number of packages vs Nix as an argument against Guix. Nixpkgs has the biggest package repository of all the distributions, and a much larger community. If you compare Guix against Arch for example, Guix comes out more favorably (15k packages) vs Arch's 12k. Guix packages tend to be very well integrated too, usually running upstream test suites, leading to fewer run-time problems. I think only Debian and Fedora matches Guix on this practice.

rekado 6y ago

> Guix started as a fork of Nix This is repeated often but it is an unfortunate misunderstanding. One self-contained component of Nix was used unaltered in Guix: the nix-daemon. Everything else but the daemon (and that's a lot) is a completely independent implementation of the same principles that were first demonstrated in Nix: functional package management. Why reuse the daemon? Because it could be done. The daemon takes very low level build instructions ("derivations") and arranges for them to be executed in an isolated environment. In Guix derivations are generated through compilation of higher level concepts that as such have no correspondence in Nix. The common ground is the format of the derivation, which has only been modified occasionally to better suit our differing needs.

georgyo 6y ago
My point was more than guix and nix could both write to the same store using a single daemon compatible with both in the future. Ensuring some cooperation between the two going forward. That currently isn't possible, but would be nice. I imagine it could only work for packages, not for system configuration. But that still would be a huge win.
- rekado 6y ago
  System configuration is also just another store item, really. The current development, however, is to move away from the old nix-daemon and to (slowly) finish its replacement that reuses all of the other existing Guix features for process isolation and building. This is desirable as there are minor annoying differences between the build environment spawned by the C++ daemon and the environment one would get using "guix environment --container". Unifying this by simply using Guile on both sides of the divide (build side vs host side) would allow for more code reuse within Guix and unlock a few features. It's not a high priority because the modified nix-daemon works fine for now, but a CS student is moving forward with the Guile daemon as a university project now. So the dream of sharing the same daemon may not be realistic. I think that this is not a big deal, because the daemon really should serve the project and as the needs of the two projects diverge so do their respective daemons.
  - georgyo 6y ago
    System configuration is just another store item, but symlinked, copied, or referenced by other places outside the store as well. Such as systemd services. You're likely right though that compatibility between the two projects will continue diverge. My true dream was that vendors wouldn't have to build for Snap, Flatpak, Guix, and Nix. They could just use either Guix or Nix and have something usable by either user base. In the end the outputs are just writing stuff to the store. But the fact that the store paths are already different would make it a huge migration for that path to change in the future, and unlikely to ever happen. Still, I can dream.

viraptor 6y ago

One thing that flatpak has over nix is the set of common bases. If I was going to distribute something shifted from nix, I'd essentially need to move every single dependency (which needs to be compiled/configured right). It's not a huge problem for a cli tool in golang, but something that requires qt, GL, input method support, etc.? I'm glad there's a flatpak base for those that not only "just works", and it's going to be maintained/distributed even of the app isn't.

mbakke 6y ago
I'm not sure I understand this argument. The main difference when compiling is that you use --prefix=$output instead of --prefix=/usr (which is nicely abstracted away by build systems). You can 'guix pack -RR ibus qutebrowser', copy the resulting binaries to any GNU/Linux system, and still expect them to work.
- viraptor 6y ago
  Yes you can, but you have to compile and distribute them all. And again distribute every single update for them. You end up with "nothing changed in my app, but there's the whole package again with a fixed deep dependency of foo". (Or more likely, no update)
  - mbakke 6y ago
    Right. Referring to exact versions of dependencies is a feature of the functional package management model. How else can you guarantee that the program will behave exactly the same every time you run it? Guix (unlike Nix) supports "grafts", so you can change something deep in the graph without having to compile every dependent package again. But grafts also produce different store items of course, so no big difference for "guix pack".
    - georgyo 6y ago
      You can also do this in nix. https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/replace-dependency.nix https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-supp...

LockAndLol 6y ago

Nix and Guix have too steep of a learning curve. Maybe someday I'll be willing to invest the time to understand what's going on, but the CLI and docs just aren't good enough to go from "I know nothing" to "ah, I can install the latest <firefox,inkscape,chromium,etc.>". It really isn't clear to me how to switch a running system's package manager to either or even if either is fit to be the system's main package manager. I watched a video of a seasoned linux user trying to install nix and abandoning the procedure because of the lack of docs. I even downloaded a virtualbox image of NixOS and tried to update everything to the latest version: 30 minutes later only firefox was installed but it wasn't in PATH thus couldn't be executed. Never found out how to install the KDE desktop. Guix was another beast that I tried installing as a non-root user (insisted on using `curl | bash`, which I loathe). It was never up to date and I couldn't find the package I wanted to install (so fancy new chromium wrapper.. next-browser or something). Maybe now things are better, but back then (1-2 years ago), neither were anywhere close to modern GUI distros. Until they make it easy to use, it's going to stay niche.

mbakke 6y ago
Guix has never insisted on 'curl | bash'. At first there were no instructions on how to use the shell installer script (perhaps you translated to 'curl | bash'?), but now the manual explicitly recommends to wget and chmod it: https://guix.gnu.org/manual/devel/en/guix.html#Binary-Installation https://guix.gnu.org/manual/devel/en/guix.html#Binary-Instal... I think you'll find that things are much more up to date nowadays. You still need root access for the guix-daemon though.
IngoBlechschmid 6y ago
I realize that you just cited two particular issues as examples for a deeper problem. But still: The command `nix-shell -p firefox` spawns a subshell in which Firefox is in the PATH. (In case Firefox has not been downloaded before, it will by this command.) Others shells are unaffected by this command, and in fact, it is possible to have different versions of Firefox available in other subshells. This feature might be especially useful to web developers interested in gauging compatibility of their sites with different versions of browsers. To enable KDE, you put this into your configuration.nix: services.xserver.desktopManager.plasma5.enable = true; Perhaps you are also interested in the following cheatsheet: https://nixos.wiki/wiki/Cheatsheet https://nixos.wiki/wiki/Cheatsheet I've been using NixOS since 2017 and don't ever want to look back. I agree that NixOS is not anywhere close to modern GUI distros, but do like the documentation, and the friendliness and speed of the community.

AnIdiotOnTheNet 6y ago

> Snap, Flatpak, Docker, AppImage, etc are all very complex solutions that are actually quite painful to interact with. Uh... what? You're comparing these things against Guix and Nix, which require you to learn a new language to use. Not to mention that AppImage, at least, is only complex because it kinda has to be in order to be portable, single-file, directly-executable application. Which is to say, it is only complex in its implementation so that it can be much less painful to interact with [0]. > Nix on the other hand solves the problem extremely well. You can have different complex applications running side by side with very different dependencies trees and they will not cross paths. Which AppImage can do without you having to learn a new language, and as a bonus will even let you store those applications on entirely different media without recompilation or anything. > Similarly, Nix is easily installed on any existing system. AppImages work on most Linux systems, which is about as well as anyone can do with something that requires no pre-installed runtime. [0] and it actually isn't that complex really.

rekado 6y ago
> Guix and Nix [...] require you to learn a new language Not true. `guix install foo`, done. Oh, you want to define an operating system declaratively in a file? Yeah, learn the DSL that was designed to let you do just that.
- AnIdiotOnTheNet 6y ago
  So the thing that is the primary value proposition of the system, yeah?
  - mbakke 6y ago
    I think the package managers themselves, with unprivileged operation, immutable profiles, atomic upgrades and rollbacks, "guix pack", etc are the main value propositions. The OS thing is mostly a side effect.
    - AnIdiotOnTheNet 6y ago

chongli 6y ago

The problem with nix is that it defeats the purpose of shared libraries. Normally, when you upgrade a shared library, all consumers of it get fixed for free. With nix every package is siloed into its own separate dependency graph and so you can have many versions of a shared library coexisting on the system but each version may be used only by one consumer. That means upgrading one will not affect all the others. So then the only way to get consumers of a shared library to upgrade is to upgrade the consumers as well. Well then why not switch to static linking and be done with it? It would be much simpler that way.

ochoseis 6y ago
IIUC, it’s more nuanced than that. The shared library would be specified as a dependency to the packages that rely on it. Pushing a fix to the library would trigger a rebuild of all the downstream packages during the next upgrade. This also means updates to a popular dependency will cause long upgrades.
claudiojulio 6y ago
From a security point of view, the Debian for example, seems to be much more reliable. It does not leave you at the mercy of libraries with security holes. Automatically translated.
dnr 6y ago
This is not actually a problem in practice. I had this misconception too before I started using it, though. I'll explain for Nix, since I've used it, but I assume Guix works similarly: Packages as defined in nixpkgs don't depend on specific versions of shared libraries. They depend on the library by name, just as they do in any other OS. So a single update in nixpkgs addresses all packages on the system "for free", including ones defined outside of nixpkgs, because they're almost certainly going to depend on nixpkgs for those libraries (I mean, they could duplicate the definitions, but why would they?). Built packages depend on specific versions. So you just have to be sure to update all your built packages. How does that happen? Well, packages are installed because they're requested by name somewhere, either NixOS system packages, or from home-manager, or from a dev environment. Those names point to packages in nixpkgs. So when you update your nixpkgs version (using nix-channel or flake update or however you're doing it), and then rebuild NixOS or update home-manager, you get updated versions of everything. If you're using a nix-based dev environment with pinned nixpkgs (with niv or a flake or whatever), you'll have to update that pin as well, for each project. I suppose you could claim that this makes it easy to use old dependencies. Perhaps, but the entire point of pinning the nixpkgs version is to make everything 100% reproducible, bugs and all, all the way down your dependency stack. So you have to make a deliberate choice between trade-offs there, which seems fair. As far as static linking, nix is essentially static linking, except that you still get the benefits of shared disk space and shared memory for .so files. "True" static linking might be simpler if your dependencies happen to be .so files that also have .a files, but many things aren't, e.g. dependencies among python modules, depending on other binaries to exec, data files, etc. Nix lets you "statically link" all of those too.

agumonkey 6y ago

nix/guix = academia and like conceptualism others = industry and leverage existing subsystems that's why

georgyo 6y ago
I don't know what you think is needed for nix/guix that has not existed the past 20 years. All the other technologies I mentioned require fairly recent kernels to work, namely for all the namespace shenanigans they employ. Nix can run on perfectly fine on at least Linux 3.2 (stock wheezy), so far as I tested.
- agumonkey 6y ago
  I never implied nix needed anything quite the opposite, it was somehow from-scratch thinking, on the other systems were more inspired by new linux features to solve a slightly similar issue.
rgoulter 6y ago
I think this is about right. Nix feels pretty close to "right thing to do", but if the other solutions are more successful, it's a case of "worse is better". I think the important part is usability compared to what's already there. It's much easier to write a Dockerfile than to write something with Nix. You can get much stronger benefits from Nix than from a Dockerfile.. but, most of which you don't really need all the time. My impression is the other solutions are quick-ish hacks to solve problems that come from (and building upon) the complexities of systems built using quick-ish hacks. Nix feels like a more elegant solution, but it's also different enough that it's got a steep learning curve for anything harder than "install foo".
- civodul 6y ago
  I think users may find it easier to create a Docker image with `guix pack -f docker app1 app2` than to write a Dockerfile. As a bonus, the resulting Docker image is bit-reproducible and recipients of the image can "map it back" to the original Guix revision. https://guix.gnu.org/manual/en/html_node/Invoking-guix-pack.html https://guix.gnu.org/manual/en/html_node/Invoking-guix-pack....

appehuli 6y ago

I don't understand some details about Nix when people talk about it. Forgive me for being ignorant. * Do packages need to be 'ported' to Nix or its build / install system? If so, how much effort will it take and on what factors the effort required to port may vary substantially? (eg: Programming Language). * How is disk space usage? Is there any kind of deduplication? * How are security updates to shared libraries handled? * Transactional upgrades look great. But how is the user experience around Transactional upgrades of running GUI applications? * Other performance characteristics - bandwidth (delta upgrades possible?), startup time (I hope this will be good)..

siraben 6y ago
Note: these points concern Nix, the situation may be different on Guix > * Do packages need to be 'ported' to Nix or its build / install system? If so, how much effort will it take and on what factors the effort required to port may vary substantially? (eg: Programming Language). Yes. To make Nix really work it has to be pervasive and this sometimes means porting packages again, however there's a lot of automation around this, see[0] for ones that leverage existing build systems in other languages. Autoconf and cmake packages are already accounted for by the default builder, and usually only the dependencies have to be specified. > * How is disk space usage? Is there any kind of deduplication? The Nix store can be intensive on memory, as once a dependency such as glibc is updated, all the reverse dependencies (i.e. the set X such that X depends on glibc directly or transitively) have to be rebuilt as well. There is an option to optimise the store, but I don't know how much it helps in practice, see[1]. Garbage collection can be invoked manually or automatically to free up unused store entries. > * Other performance characteristics - bandwidth (delta upgrades possible?), startup time (I hope this will be good).. By startup time you might be referring to NixOS. It's very good on my Late 2013 13-inch MacBook Pro, around 20 seconds to go from cold boot to login screen. [0] https://github.com/svanderburg/node2nix https://github.com/svanderburg/node2nix https://github.com/NixOS/cabal2nix https://github.com/NixOS/cabal2nix https://github.com/cargo2nix/cargo2nix https://github.com/cargo2nix/cargo2nix https://github.com/nix-community/poetry2nix https://github.com/nix-community/poetry2nix https://github.com/kamilchm/go2nix https://github.com/kamilchm/go2nix https://github.com/nix-community/pip2nix https://github.com/nix-community/pip2nix [1] https://nixos.wiki/wiki/Storage_optimization https://nixos.wiki/wiki/Storage_optimization

sergeykish 6y ago

And it is easy to install software that's not packaged by distribution, ungoogled chromium [1]: $ nix-env -iA nixpkgs.ungoogled-chromium $ which chromium /home/sergeykish/.nix-profile/bin/chromium [1] https://search.nixos.org/packages?channel=20.09&show=ungoogled-chromium&from=0&size=30&sort=relevance&query=ungoogled https://search.nixos.org/packages?channel=20.09&show=ungoogl...

civodul 6y ago
Or: guix install ungoogled-chromium This CLI difference is in part due to the underlying design, which is not just about syntax (parens vs. braces) but more about abstractions and composition. For example, the Nix language doesn't have the ability to define new data types, and it doesn't have a "package" or an "operating system" data type. That means that all the entries in Nixpkgs look alike, which in turn prevents building a "package-aware" or "OS-aware" user interface. The Guix CLI "knows" about packages and versions, and package transformation options are an example of how the CLI can take advantage of that abstraction. Likewise, the "guix system" command knows about services, which gives it convenient introspection capabilities such as "guix system extension-graph" and "guix system shepherd-graph". It really isn't about parentheses vs. braces. :-)
- eliaspro 6y ago
  This is what annoys me about Nix the most - the missing abstraction of those, resulting in an often cumbersome UX and a very steep learning curve. Guix on the other hand provides those, but is far from what nixpkgs offers in terms of number and actuality of pkgs.
  - mbakke 6y ago
    I think it's somewhat unfair to use number of packages vs Nix as an argument against Guix. Nixpkgs has the biggest package repository of all the distributions, and a much larger community. If you compare Guix against Arch for example, Guix comes out more favorably (15k packages) vs Arch's 12k. Guix packages tend to be very well integrated too, usually running upstream test suites, leading to fewer run-time problems. I think only Debian and Fedora matches Guix on this practice.