New problem - Installed GUIX (OK), installed some software from GUIX, then tried to install Jupyter from GUIX...

Running out of storage while using Guix is a common issue, specially if you're installing Qt/GTK software or web browsers, which are massive and complex/bloated programs. The reason being it often fetches the whole software stack required to compile the package you're trying to install, multiple times in some cases as different packages require different versions of a dependency.

This is well explained on their docs which are excellent, bookmark them and read them thoroughly when you wanna get something done, you'll need it:
https://guix.gnu.org/manual/en/guix.html

You can free up the used space with guix gc, which exists to do cleanup with packages that are no longer needed (although on the next guix pull, the package manager will have to fetch them again to run upgrades).

Details here: https://guix.gnu.org/manual/en/guix.html#Invoking-guix-gc

> I'm not sure what the effect of moving /gnu/store to /home would be - it will probably kill GUIX unless there's something I can do in my .guix-profile.

You definitely can symlink or mount /gnu/store to a large partition and it should be fine, as long as you don't mess the filesystem permissions when migrating the directory. I've done similar things in scenarios where the root partition runs low on storage.

The easiest might be not to have separate partitions for / and for /home. I do that frequently, I boot on a live USB, copy /home to /home2, delete the home partition, extend the partition for / (actually, I use lvm, so I use lvdelete and lvresize for this), mount it and rename /home2 to /home, remove /home from /etc/fstab, and then I am done. Of course, I need to do this before I put any data (or install guix), so that the initial / has enough free space for the small initial /home.

You can also run "guix gc" sometimes.

Note that while 'guix gc' is the easiest and fastest way to get back space, but it's not the only way.

To get back more space you will need to update the guix packages at the same time or from the same guix revision so that each package can share dependencies.

Another additional issue is that your guix profile will keep the old packages to be able to roll back to older revisions of the profile.

The 'guix package --list-generations' command will show them. guix package also has '--delete-generations' so you could learn how to use that as well.

But even with all that, at the end of the day Guix will take more space than the same package provided by Trisquel and the reasons was already explained above, but I'll give a bit more background of why this is hard to avoid.

Basically to work, good software or anything that relies on science come with constraints or tradeoffs and these are known and/or documented somewhere (otherwise the software is bad or it's bad science or not scientific at all).

For instance a regular computer will stop working under water or at very high or low temperatures (these are documented, like -40 + 80 degrees C, or 0 to +40 degrees C). The ones that work under water and/or at very low/high temperatures will have other downsides, like being very heavy like the Roda RK9 for instance.

If your use case is just to install software on top of your distribution, Guix does much more and you might not need all the rest of the benefits it provides (like to have the exact same binaries across different distributions and environments, to be able to build everything from source, etc) and the only known ways to provides such benefits comes with a cost that you may not want to pay and that is perfectly fine.

This is why only packaging software in Guix is not sufficient because not everybody is OK with paying this cost.

Personally I rely on Guix a lot but I'm also pushed to also package software I rely on in Parabola precisely because it then allows me not to pay the size CPU and human time costs (updates also take time, especially with Guix).

If we look at other cross-distributions package managers, they also come with costs but their tradeoffs differ. For instance gsrc from the GNU project (and many other non-FSG cross packages managers as well) have minimal size footprint, but they all require the users to compile everything.

If we look at Firefox-based browsers that provide binaries for GNU/Linux, here they instead include lots of dependencies so they are quite big.

And here the issue is that to have both (not compile and small size), someone needs to compile the software specifically for Trisquel 11 and/or similar distributions, because then the compilation process will ensure that the software will use the dependencies provided by Trisquel (especially the libraries). So in practice this means that someone needs to do a PPA and be good at providing updates, backporting fixes, etc.

This requires time and testing and personally I'm not even sure how to do that myself, though I'd be interested in learning how to do it.

In contrast, if you want to target many distributions, and not just Trisquel 11, and that what you provide has dependencies, you will end up with the tradeoff I mentioned above. It's also not an all or nothing choice here, you could try to be more fine grained and look at what dependencies are usually available in distributions (like glibc) and not provide them, but then it means that you will need to know all distributions or to rely on testers, and it will eventually break on distributions that don't have the dependency (some distributions don't have glibc for instance, like LibreCMC).

At the end of the day, if the software is well made, you can also compile it yourself or learn how to do that (some software are too hard to compile or package, like for instance software with ton of JavaScript or browser dependencies, so try not to use these).

In Trisquel there is a checkinstall package that can help you do that as it can easily convert the result of some usual commands like ./configure && make && make install to a Debian package that can easily be removed (and so more easily upgraded). But then the main issue with this approach is that you will still need to find a way to learn when there are updates and make sure they continue working, even if you are stuck on Trisquel 11 and the software now require new dependencies. Usually people doing PPAs (are supposed to) do that work for you and/or accept contributions to help fix things.

Also note that Trisquel 11 has a jupyter-notebook package, so you could also compare both to see which one is best for you, and try to see if there are some FSDG PPA for it jupyter-notebook if you need more recent versions.