Administered by:
I'm getting a new computer soon which I think will allow me to install #guix as my OS. I'm fairly happy on Debian 12 currently but I like some of the features promised by guix like user-installed packages, more up-to-date packages than Debian, 'undoable' updates and of course being fully free.
Would any guix user here answer a couple of questions for me though:
Do flatpaks and appimages work well on it?
Does it take more resources to install and update software than apt does on Debian? Thanks :)
@flowti haven't tried Appimage, but flatpak works fine. Appimage should work too. Updating takes more time, but I accept this for the benefits it gives.
@simendsjo @flowti Is it possible to list flatpak apps in a config file for 'guix home' to deploy?
@Guillawme @flowti no, they live outside guix and have definitions elsewhere.
@simendsjo @flowti I understand they live outside of the guix package collection, but I was hoping there was a way to tell 'guix home' to run all the corresponding 'flatpak install' commands for me upon doing 'guix home reconfigure'.
@Guillawme @flowti then Guix could not be deterministic as the flatpak definitions is not managed by Guix. Maybe flatpack has some sort of pinning to make it fully deterministic though. But I just use flatpak as a last resort when I have been unable to correctly create a package myself.
@simendsjo @flowti Makes sense. I was thinking about how I want to manage GUI apps, and flatpak seemed like the easiest way to get automatic updates for “computationally cheap”. I am testing Guix System on a small computer, pull and reconfigure always make it break a sweat… so I’d rather minimize their use if I can. But on the other hand I want an always up-to-date browser for obvious security reasons.
@Guillawme @flowti Adding substitute servers is useful so you can download prebuilt packages. I also use an offload server to avoid building things on my laptop. Used Guix for several years before configuring an offload server though.
@simendsjo @flowti Yes, I already use substitute servers. But pull is still expensive with the commit authentication step, when there are many new commits in the channels being pulled.
@Guillawme @flowti I think Guile will compile everything too. Not sure what parts are the main performance issues. I'm hoping Guile can improve the situation over time. But the situation is getting worse as the repository grows.
@simendsjo @flowti Most AppImages don't work, because they are dynamically linked. So you need to use guix shell's FHS Container or patchelf to fix the paths
@simendsjo @flowti In theory, AppImages should be completely self contained to guarantee this, the AppImages generated with `guix pack` are an example.
In practice, this is rarely the case for multiple reasons:
- You need the runtime to be compiled statically or with musl.
- Adding all dependencies is really heavy, you can use guix size to see the size a package would have with all dependencies.
- The AppImage runtime uses libfuse for user mounts, which can't be bundled as its needs a suid binary.
@flowti My take on those two questions: 1) Flatpaks and appimages don't usually work well on Guix _System_ (but see below!). I usually avoid them and write native #Guix package descriptions instead. 2) In the "common" case (if you don't heavily customise packages, and don't eagerly "guix pull"), Guix package installations/updates will probably require resources comparable to apt.
@flowti One thing you might want to consider: it is entirely possible to run #Guix on top of #Debian (see the "foreign distro" description in https://guix.gnu.org/manual/en/html_node/Installation.html). In this configuration, flatpak/appimage/etc. will work essentially identically to on plain #debian. Such a setup might be a low risk way to tinker with Guix functional package management? (Perhaps trying soon on your current computer, to have a chance to form an opinion before deciding how to configure your new one?)
Especially if you are new to Guix, start with Debian + Guix as an add-on package manager, and learn working the Guix way without pressure.
My setup is Ubuntu 20.04 (but planning to migrate to Debian 12) plus Guix. I get the base system plus "boring" apps (LibreOffice, Firefox), ... as apts, and everything I care about and configure in detail from Guix.
@khinsen @gtw Yes, I think that's what I'll do. Do you know if programs installed using Guix will look in .config directories for configuration? For example if I installed GIMP using apt on Debian and edited keyboard shortcuts before reinstalling it using guix would my keyboard shortcuts still work on the new install? Or would I need to set up the keyboard shortcuts again on the guix-installed version of GIMP?
@flowti I started testing Guix System recently, and so far it's been a great experience! I am slowly porting my previous home to it.
I haven't yet tried AppImage or Flatpak apps. I see no reason why AppImage app wouldn't work though. And Flatpak is in the package collection, which then can act as its own package manager to pull apps from Flathub and other repositories.
Regarding upgrades, 'guix pull' (roughly equivalent to 'apt update; apt upgrade apt') takes a lot of resources if there are many new commits in the package collection since the last pull. Similarly, 'guix system reconfigure' (roughly equivalent to 'apt upgrade') takes a lot of resources if you do it after a pull. But if you are only changing configuration while on the same commit of the package collection, it's a bit faster.
Generally, you will want to have substitutes (= binary packages in guix vocabulary) enabled with substitute server URLs listed somewhere, otherwise every pull and reconfigure will trigger a lot of compilations. Using substitutes is the default for the default channels (= repositories in guix vocabulary), but if you add new channels make sure to check if they offer a substitute server (the nonguix channel does), and enable it.
Good luck! And if you decide to share your progress here, I'm curious to learn more.