In terms of an asset being software that you're deploying, I don't get this attitute.
If the process for producing the software is unreproducible, then you're running the risk that the behaviour of the software will be unreproducible. As in you run the generation process once, and then again with the same inputs, and you'll get an output that works differently.
Now of course you can store the generated asset, which gives some certainty in the roll back case. But roll backs are hopefully rare, what's more common is to make small changes to inputs (like source code changes), and hope that the generate asset has only been affected by the intended change.
To give an example of how this works where no care has been taken that the process is reproducible, I've seen people try to make code changes to Docker images, and end up with changes that they didn't intend (like a different version of Debian in the image, or a different Ruby/Python version).
Some analytics information is public, if you know where to look. You can add /info to the start of the URL path, and that might reveal some information about the page.
In the case of things like page views, this is something addressable by just gathering the data yourself. If you put in the effort up front, it'll be more accurate than Google (as you don't miss anyone who Google misses).
Normally you'd just be using one glibc version. Packages that you installed a while ago may be using a different one, but it's not like every package has massively divergent dependencies.
Because of the immutable store, you can do file level deduplication, so if you have multiple versions of the same packages, you can deduplicate the identical files.
I think the worries about disk usage are relevant, but only on systems with small amounts of storage. These are still relevant though, and it's an important area to improve on. As for burning CPU time, I don't think there's a perfect solution to avoid this, but I think Guix is pretty good. Guix provides substitutes, so you don't have to build things locally on every machine (I'm looking at you Rubygems, pip and Python stuff is pretty bad also).
No, you just update the package definition for A and release the updated package definitions, people will then be using the updated A, whether directly or through other packages (X, Y, B, M, N, ...).
There is an issue here of rebuilding all those dependent packages with the updated A, especially if it's something like glibc. Guix includes a mechanism called grafts that allows for package replacements, which allows avoiding this, and this is often used for releasing security fixes.
Guix has packages, and packages have inputs (like dependencies), and you're right in that normally package definitions specify the exact dependencies it the code (they're hardcoded).
Guix package definitions are truely code though, so if you want to generate packages on the fly by using a dependency resolver, you can totally write some code to make that happen.
With respect to inefficiency, what do you mean? It's quite time efficient when building and installing to not have to attempt to resolve dependencies.
I used to think package managers and dependency resolvers were inseperable, I even did a little bit of work on the APT resolver.
Since using GNU Guix though, I'm so glad it doesn't have a dependency resolver as part of building or installing packages! It's so much better for it, no slow or unpredictable resolving, you know what it's going to do.
I think this is one reason why I've never used pip for managing Python software, I've only ever used Debian, and then Guix.
> I’ve seen Guix pop up a few times and I’m intrigued ... ostensibly a package manager but this article says it can work as an operating system in its own right. Can somebody explain this to me?
Guix as a package manager knows how to build software, and how to manage all the files. If you build the right software, plus a few more things with some files, then you end up with something that'll boot.
One really neat thing about this is that this is set out in one Git repository, making it pretty easy to reason about.
> Is this HURD? Or does it have a kernel? Is it some sort of hypervisor or application container? I always found HURD to be exciting in a sci-fi kind of way but from what I’ve heard this sounds like it’s actually something that could be practically useful. Where would I start? Does it make any sense running in VirtualBox let’s say?
Guix by default uses Linux-libre, but you can run it with the Hurd.
You can start by using Guix as a package manager, it'll fit alongside your existing operating system (providing it's something using Linux). There's also a VM image you can download from the website if that's of interest.
Maybe it would be nice to have a wiki style page for this... anyway, I can only offer a perspective from the Guix side of things, but these are the reasons I'd personally be cautious about using Nix/Nixpkgs.
I believe a higher proportion of Nixpkgs don't build all or some of the software/artifacts from source. I picked a random example, JOSM. The nixpkgs package definition is quite short [1], but I don't think it's actually building the software? The Guix package definition is much longer [2] but I think that's because it's actually building the software from source.
Personally, I like binary packages, which is why I use Guix, but I also value the security and flexibility of having these packages actually build the software from source.
Nixpkgs also contains non-free software. This is sort of related to the previous point, as it's much harder to tell if software is free or not if you're not building it from source, but Guix everything should be free software which takes away a worry when using it. With nixpkgs, I believe there are some bits of non-free software that are marked as such, but not taking a strong stance on attempting to build everything from source makes me generally unsure about the quality assurance in this area.
If the process for producing the software is unreproducible, then you're running the risk that the behaviour of the software will be unreproducible. As in you run the generation process once, and then again with the same inputs, and you'll get an output that works differently.
Now of course you can store the generated asset, which gives some certainty in the roll back case. But roll backs are hopefully rare, what's more common is to make small changes to inputs (like source code changes), and hope that the generate asset has only been affected by the intended change.
To give an example of how this works where no care has been taken that the process is reproducible, I've seen people try to make code changes to Docker images, and end up with changes that they didn't intend (like a different version of Debian in the image, or a different Ruby/Python version).