6 ms·

As another builder of a Linux gaming desktop, let me just say: nice! I ended up going with an Nvidia 3080 because I'm more familiar with CUDA than AMD equivalen

As another builder of a Linux gaming desktop, let me just say: nice! I ended up going with an Nvidia 3080 because I'm more familiar with CUDA than AMD equivalents (and I do still need to get work done). If it wasn't for that, I'd likely have gone AMD as well! One thing that I'd love to hear more on is what Guix gets you as a package manager and/or as a distro. I'm not really following how it differs from other, perhaps more traditional, package managers. I've stuck it out on Arch, mainly for software availability in the AUR-- i.e. getting out of repo gaming utilities like greenwithenvy and the glorious eggroll proton fork without having to navigate flatpak/snap/etc. My last experience with Steam in a snap on Ubuntu was particularly bad: the application wasn't able to see the mounted drives where I was installing games, nor was it able to detect proton-ge-custom. I've heard the flatpak experience is better, but I haven't played with it at all.

MayeulC 5y ago
It's spelt out in the article, but be aware that Guix as a distro will give you a libre kernel, so no blobs. I am afraid it might not work with nvidia or AMD GPUs, as well as some wi-fi adapters (there's the cough nonguix project umbrella I haven't yet dug into). Other than that, the approach taken by Guix and Nix to package management (or even fedora silverblue) is quite interesting, and I've been folowing it rather closely. You get a more ansible-like (one config file for deployment) way of configuring your system, with rollbacks possible, it lets you have multiple software configurations exist simultaneously, that would be hard to achieve on other distributions (say, different environments with various versions of glibc). And portability+reproductibility of your environments.
- SkyMarshal 5y ago
  GUIX should work with AMD’s open source drivers, just not Nvidia’s blob drivers.
  - MayeulC 5y ago
    Not out-of-the box, though, as recent GPUs need to have firmware loaded before being usable. IIRC, older AMD GPUs have firmware pre-loaded (and though they would be better performing with newer firmware, they can run as-is).
  - podiki 5y ago
    The issue is loading firmware with the kernel, which linux-libre won't (by design) do. You can run the full linux kernel instead (but not in Guix default channels).
  - opan 5y ago
    It's not that simple, unfortunately. The AMD drivers are free, but rely on some blobs in the kernel that aren't there when using linux-libre.
    - MayeulC 5y ago
      I'd just like to clarify that these blobs are never executed on the main CPU, and are instead running inside the GPU, or possibly "management engine"-like cores inside it. They also likely contain opaque data like DRM-related keys, thermal management look-up tables, etc.
- ekianjo 5y ago
  > I am afraid it might not work with nvidia or AMD GPUs, You can still install non-free blobs on Guix, as described in the article.
  - MayeulC 5y ago
    Yeah, I commented before reading the article, I had missed "Guix" in the title. I now read it, and adjusted my comment a bit. Nice to know that firmware is easily available, though I am not sure nvidia's driver can install and play nice with guix, unless it's packaged up in the nonguix channel. I have previously had a test run on Guix on an old laptop with 1GB of ram, but it was clearly not powerful enough, as a guix pull could take 2-3 days (!) to complete. I guess I'll revisit it in a few months on a more powerful computer (an leave my old one with Alpine)
    - podiki 5y ago
      I'm not sure exactly the Nvidia situation, I know people have it working but still a little bit of work. I think the drivers are fine, but also might need some changes to make sure Nvidia's GL libraries are used. But it does work. I, for one, am happy to be in AMD-land now. (Good on you for admitting commenting before reading, and extra points for then reading! I jest, but we are all guilty)
SkyMarshal 5y ago
GUIX (and NixOS) are significantly different than other package managers. They get you declarative system configuration, immutable and reproducible builds. Declarative config = entire system config specified in a single config file - all config that is normally scattered across different /etc files and other locations now goes into a single config file (which instructs the system to write those /etc files on install, so /etc is still used but there’s a single source for configuring all of it). All packages and package config, boot loader, systemd/init system config, networking, etc configured in one file. And all config is declarative, not imperative - eg, you tell the system what you want in your build, and the system handles how. In NixOS this all just a big JSON file, and GUIX it’s a Scheme data structure. Immutable builds = any time you make a configuration change, an entire new system is built with the change incorporated, and the system updated to point at the new build. Prior system builds are retained unchanged, and you can rollback to them any time if needed, if your new one is broken in some way not caught by compiler. Since current and prior builds are immutable, you can be sure that if a prior build worked reliably, it will continue to do so in case you need to rollback to it. In NixOS, builds are stored in /nix and soft-linked as needed to /bin, /usr/bin/, etc. Not sure about the equivalent on GUIX but that’s the idea. Reproducible builds = you can take your system configuration file and use it to install an identical system build on other hardware. Everything will be the same except different hardware drivers for different hardware. Reinstalling the same configuration on the same system with no hardware changes will result in an identical system build with the same checksum. One thing this does is make rapidly experimenting with different system configs much more possible. There’s no penalty to experimentation and failure, you can’t brick your system. If you do, just rollback to the prior working config, only takes a few seconds. You can iterate through many different config ideas, testing them all, and optimizing it to your needs. I spent the past spring/summer migrating to NixOS. There’s a learning curve, but now that I’ve gotten through most of it, I could never go back to a normal linux. GUIX/NixOS is really the right way to architect an OS, so much farther out of the tarpit than anything else I’ve seen.
015a 5y ago
In my experience, snap is Just Bad and will probably disappear in the next few years like all of Canonical's other NIH projects. Software availability is kinda ok, but compatibility and functionality is all over the place, primarily I think due to the sandboxing. Though, even classically confined snaps will sometimes misbehave in weird ways. E.g. for me, the classically confined nodejs snap cannot be used to run a simple mocha test suite for our backend app, as it causes every test to time out. native install, no problem. The classically confined golang snap, installs a bunch of go tools as you'd expect, which are weirdly invisible to VSCode's Golang addons. You install Slack, click a link in a conversation, and it opens in a new Firefox window with all of your settings and addons disappeared; you have to delete an about:profiles profile in Firefox to make it use the existing configuration. App startup times can range from hundreds of milliseconds to 10+ seconds. Its just really not a good situation; some of these problems have solutions, but these are issues I've seen in, who knows, 19.04, 19.10, 20.04, 20.10, 21.04, we'll see if they fix it in 21.10 but I'm not holding my breath; we're talking years of decay. Flatpak is definitely better. I've never ran into any compatibility or functionality issues. But, availability isn't as good; it seems like flatpak is geared more toward UI software; so, Discord, Slack, Spotify, Atom, Steam, even nvidia drivers, these I have installed through flatpak (Manjaro Gnome; so, Arch). You search flathub for Golang, or NodeJS, or other more dev/cli focused software, and it has nothing. So, I don't know if that's a cultural or technical thing, but it at least seems like flatpak has a focus, and excels within that focus.
podiki 5y ago
(Author here) Long time Arch user, and loved it, but now loving Guix. I'll be writing a followup article about how I set up everything in Guix, but as I mentioned here the only wrinkle on the software side was Steam via Flatpak. The beta version of Flatpak has solved the Proton issues, and it works great for me. Nonguix also has a Steam package, but we need to figure out some newer sandboxing that Valve has done to get newer Proton working. Edit: And thanks!
- tuananh 5y ago
  can you elaborate what do you love about guix?
  - aijony 5y ago
    Not OP but here are some of mine: - Universal package manager (replaces pip, cabal, npm, etc.) - Declarative OS-config which makes deploys on new devices and servers a breeze - Scheme declaration language (I prefer it to Nix-lang) - Bootstrapable from 512 byte binary [1] - I can build a package from source or download the binary - Easily modify package source, deps, or compiler [2] Cons: - No official nonfree software [3] - Smaller package set than Nix - No KDE yet and old version of Gnome (it takes a lot of work to update) Neutral: - No systemd - Works with GNU Hurd - No MacOS or BSD support (yet) [1] https://guix.gnu.org/en/blog/2020/guix-further-reduces-bootstrap-seed-to-25/ https://guix.gnu.org/en/blog/2020/guix-further-reduces-boots... [2] https://guix.gnu.org/manual/en/html_node/Defining-Package-Variants.html https://guix.gnu.org/manual/en/html_node/Defining-Package-Va... [3] https://gitlab.com/nonguix/nonguix https://gitlab.com/nonguix/nonguix
    - ajklsdhfniuwehf 5y ago
      > no systemd i was on this front for a long time, but now it feels like a lost cause. What guix suggest for managing services/containers/chroots/cgroups?
      - BrightGlow 5y ago

MayeulC 5y ago

It's spelt out in the article, but be aware that Guix as a distro will give you a libre kernel, so no blobs. I am afraid it might not work with nvidia or AMD GPUs, as well as some wi-fi adapters (there's the cough nonguix project umbrella I haven't yet dug into). Other than that, the approach taken by Guix and Nix to package management (or even fedora silverblue) is quite interesting, and I've been folowing it rather closely. You get a more ansible-like (one config file for deployment) way of configuring your system, with rollbacks possible, it lets you have multiple software configurations exist simultaneously, that would be hard to achieve on other distributions (say, different environments with various versions of glibc). And portability+reproductibility of your environments.

SkyMarshal 5y ago
GUIX should work with AMD’s open source drivers, just not Nvidia’s blob drivers.
- MayeulC 5y ago
  Not out-of-the box, though, as recent GPUs need to have firmware loaded before being usable. IIRC, older AMD GPUs have firmware pre-loaded (and though they would be better performing with newer firmware, they can run as-is).
- podiki 5y ago
  The issue is loading firmware with the kernel, which linux-libre won't (by design) do. You can run the full linux kernel instead (but not in Guix default channels).
- opan 5y ago
  It's not that simple, unfortunately. The AMD drivers are free, but rely on some blobs in the kernel that aren't there when using linux-libre.
  - MayeulC 5y ago
    I'd just like to clarify that these blobs are never executed on the main CPU, and are instead running inside the GPU, or possibly "management engine"-like cores inside it. They also likely contain opaque data like DRM-related keys, thermal management look-up tables, etc.
ekianjo 5y ago
> I am afraid it might not work with nvidia or AMD GPUs, You can still install non-free blobs on Guix, as described in the article.
- MayeulC 5y ago
  Yeah, I commented before reading the article, I had missed "Guix" in the title. I now read it, and adjusted my comment a bit. Nice to know that firmware is easily available, though I am not sure nvidia's driver can install and play nice with guix, unless it's packaged up in the nonguix channel. I have previously had a test run on Guix on an old laptop with 1GB of ram, but it was clearly not powerful enough, as a guix pull could take 2-3 days (!) to complete. I guess I'll revisit it in a few months on a more powerful computer (an leave my old one with Alpine)
  - podiki 5y ago
    I'm not sure exactly the Nvidia situation, I know people have it working but still a little bit of work. I think the drivers are fine, but also might need some changes to make sure Nvidia's GL libraries are used. But it does work. I, for one, am happy to be in AMD-land now. (Good on you for admitting commenting before reading, and extra points for then reading! I jest, but we are all guilty)

SkyMarshal 5y ago

GUIX (and NixOS) are significantly different than other package managers. They get you declarative system configuration, immutable and reproducible builds. Declarative config = entire system config specified in a single config file - all config that is normally scattered across different /etc files and other locations now goes into a single config file (which instructs the system to write those /etc files on install, so /etc is still used but there’s a single source for configuring all of it). All packages and package config, boot loader, systemd/init system config, networking, etc configured in one file. And all config is declarative, not imperative - eg, you tell the system what you want in your build, and the system handles how. In NixOS this all just a big JSON file, and GUIX it’s a Scheme data structure. Immutable builds = any time you make a configuration change, an entire new system is built with the change incorporated, and the system updated to point at the new build. Prior system builds are retained unchanged, and you can rollback to them any time if needed, if your new one is broken in some way not caught by compiler. Since current and prior builds are immutable, you can be sure that if a prior build worked reliably, it will continue to do so in case you need to rollback to it. In NixOS, builds are stored in /nix and soft-linked as needed to /bin, /usr/bin/, etc. Not sure about the equivalent on GUIX but that’s the idea. Reproducible builds = you can take your system configuration file and use it to install an identical system build on other hardware. Everything will be the same except different hardware drivers for different hardware. Reinstalling the same configuration on the same system with no hardware changes will result in an identical system build with the same checksum. One thing this does is make rapidly experimenting with different system configs much more possible. There’s no penalty to experimentation and failure, you can’t brick your system. If you do, just rollback to the prior working config, only takes a few seconds. You can iterate through many different config ideas, testing them all, and optimizing it to your needs. I spent the past spring/summer migrating to NixOS. There’s a learning curve, but now that I’ve gotten through most of it, I could never go back to a normal linux. GUIX/NixOS is really the right way to architect an OS, so much farther out of the tarpit than anything else I’ve seen.

015a 5y ago

In my experience, snap is Just Bad and will probably disappear in the next few years like all of Canonical's other NIH projects. Software availability is kinda ok, but compatibility and functionality is all over the place, primarily I think due to the sandboxing. Though, even classically confined snaps will sometimes misbehave in weird ways. E.g. for me, the classically confined nodejs snap cannot be used to run a simple mocha test suite for our backend app, as it causes every test to time out. native install, no problem. The classically confined golang snap, installs a bunch of go tools as you'd expect, which are weirdly invisible to VSCode's Golang addons. You install Slack, click a link in a conversation, and it opens in a new Firefox window with all of your settings and addons disappeared; you have to delete an about:profiles profile in Firefox to make it use the existing configuration. App startup times can range from hundreds of milliseconds to 10+ seconds. Its just really not a good situation; some of these problems have solutions, but these are issues I've seen in, who knows, 19.04, 19.10, 20.04, 20.10, 21.04, we'll see if they fix it in 21.10 but I'm not holding my breath; we're talking years of decay. Flatpak is definitely better. I've never ran into any compatibility or functionality issues. But, availability isn't as good; it seems like flatpak is geared more toward UI software; so, Discord, Slack, Spotify, Atom, Steam, even nvidia drivers, these I have installed through flatpak (Manjaro Gnome; so, Arch). You search flathub for Golang, or NodeJS, or other more dev/cli focused software, and it has nothing. So, I don't know if that's a cultural or technical thing, but it at least seems like flatpak has a focus, and excels within that focus.

podiki 5y ago

(Author here) Long time Arch user, and loved it, but now loving Guix. I'll be writing a followup article about how I set up everything in Guix, but as I mentioned here the only wrinkle on the software side was Steam via Flatpak. The beta version of Flatpak has solved the Proton issues, and it works great for me. Nonguix also has a Steam package, but we need to figure out some newer sandboxing that Valve has done to get newer Proton working. Edit: And thanks!

tuananh 5y ago
can you elaborate what do you love about guix?
- aijony 5y ago
  Not OP but here are some of mine: - Universal package manager (replaces pip, cabal, npm, etc.) - Declarative OS-config which makes deploys on new devices and servers a breeze - Scheme declaration language (I prefer it to Nix-lang) - Bootstrapable from 512 byte binary [1] - I can build a package from source or download the binary - Easily modify package source, deps, or compiler [2] Cons: - No official nonfree software [3] - Smaller package set than Nix - No KDE yet and old version of Gnome (it takes a lot of work to update) Neutral: - No systemd - Works with GNU Hurd - No MacOS or BSD support (yet) [1] https://guix.gnu.org/en/blog/2020/guix-further-reduces-bootstrap-seed-to-25/ https://guix.gnu.org/en/blog/2020/guix-further-reduces-boots... [2] https://guix.gnu.org/manual/en/html_node/Defining-Package-Variants.html https://guix.gnu.org/manual/en/html_node/Defining-Package-Va... [3] https://gitlab.com/nonguix/nonguix https://gitlab.com/nonguix/nonguix
  - ajklsdhfniuwehf 5y ago
    > no systemd i was on this front for a long time, but now it feels like a lost cause. What guix suggest for managing services/containers/chroots/cgroups?
    - BrightGlow 5y ago