News for hackers. Stuff that matters.
Re:GNU Guix 1.2.0 by chongli on Monday November 23, 2020 @06:17PM (#25193075)
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.

Re:GNU Guix 1.2.0 by dnr on Monday November 23, 2020 @09:17PM (#25194553)
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.

Re:GNU Guix 1.2.0 by ochoseis on Monday November 23, 2020 @06:29PM (#25193203)
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.
Re:GNU Guix 1.2.0 by rfoo on Monday November 23, 2020 @11:40PM (#25195330)
The unholy basis of all modern Linux systems named glibc does not like being statically linked. It would break slightly and sometimes seriously if you do so.
Re:GNU Guix 1.2.0 by claudiojulio on Monday November 23, 2020 @07:12PM (#25193592)
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.