Hi all,
Our carbon footprint is arguably the most important metric for
everything we do.
On 1/6/26 21:35, Ludovic Courtès wrote:
The carbon footprint of Guix
So we should do this properly and create some estimates (and
measurements) for the carbon footprint of Guix. Then we can act
accordingly.
For example, I expect that the energy consumption currently scales
super-linear with the number of packages. If true, we can take steps to
make that linear again (maybe even logarithmic, in the distant future).
I also think the energy consumption currently scales linearly with the
number of users, because I expect it is a regular experience of users to
have to build qtwebengine (or similar) overnight. We should try to get
this energy-consumption-vs-nr-of-users relation near constant.
I'm willing to put effort into collecting these measurements and
performing those estimates.
> But we can acknowledge that the
> environmental cost of these tools *alone* is a problem for society
I'll admit that genAI is a big wildcard here. It really depends on how
it is used.
Per package it can be okay. Manually fixing a package of medium
complexity can require several rebuilds, while an AI agent might fix it
in one go. Then, employing an agent reduces the carbon footprint.
Possibly even when including the amortized costs, depending on details.
The biggest risk of AI (for Guix' carbon footprint) is that we will get
an explosion of software that we could package. It is now trivial to
fork a project and 'improve' it the way you want.
That’s not the case due to Jevon’s paradox, as Simon nicely explained:
I countered that then, and do it again: Jevon's paradox applies when you
use the efficiency gain of an activity to do more of that activity (e.g.
historically: mining, travel, light, compute).
So the efficiency-per-package argument only breaks down if we are going
use that efficiency gain to package more and more software.
But that is true for all automation: if we improve `guix refresh` to
deal with those medium-complexity cases (which we should), then we also
free up developer time and compute resources to package more software,
again increasing our total carbon footprint.
The solution to Jevon's paradox is to limit the amount of software we
package through social means, not to artificially cap our capability of
packaging software by making the packaging process (energy-)inefficient.
Hugo
