cbaines
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).
For example: https://www.gov.uk/info/find-coronavirus-local-restrictions
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).
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).
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 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.
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.
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.
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.
1: https://github.com/NixOS/nixpkgs/blob/master/pkgs/applicatio... 2: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages...
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.