An FHS base system that still gives you some of the nice features of Nix and Guix, like immutability and rollbacks.
In theory something like it could be a giant escape hatch so that if you run into Guix packaging difficulties for some software that, e.g., tries to fetch from the internet at runtime, you can just build with autoconf and make or `npm build` or whatever against the Fedora base system. Silverblue might be quirky enough that it has its own hiccups though, idk.
It includes some code to get around the group/user management quirks that some other commenters have noted b0rked the Guix installer with Silverblue, so perhaps it gives an outline of how to install Guix on Silverblue for a hacker who'd like to try it :)
There's an FHS emulating option for guix shell containers that has been proposed (it needs some minor code changes but is functional; I use it): https://issues.guix.gnu.org/56677
So doing a guix shell --container --emulate-fhs <packages> will have you in a container with the usual /lib, /bin, and so on, which should work just as a "typical" Linux distro. You'll want to share things from the host to the container (e.g. graphics) but that is all standard guix container options.
That is very cool. Could one then persist binaries built against such a container with something like `guix pack`? That would be absolutely killer. (Not reproducible at all, but an awesome escape hatch for building software in a traditional way, ad-hoc and imperative, on GuixSD. Could be really nice when packaging an odd piece of software feels overwhelming.)
Either way, that's pretty exciting and I hope it can be merged soon!
I'm not sure how that could work exactly, but yeah, did think of some sort of guix shell build environment container. Though I guess inside it should be the same as "regular" Linux, but you've specified the environment exactly (i.e. you could capture the exact Guix commits to make a reproducible container). Unfortunately, once in there you have state to worry about, so you'll lose reproducibility control as you say, but do think there could be some way to make this a nice stop-gap.
In Guix's case, a working desktop with wayland + proprietary Nvidia drivers. (I'm actually using Kinoite, which is the KDE spin of silverblue)
I could install Guix on top of something like Ubuntu or Fedora workstation for the same effect, but then I'll have two system package managers side by side, which is pointless and probably error prone.
Well, Nix was mentioned a few posts up... But in general, Guix is directly based off of Nix and is seen by many as "Nix + Guile + GNU". Is it odd to see people talking about a different BSD in a {Free,Open,Net,*}BSD thread?
Guix is quite different from it's origins, though some of the oldest part of the daemon are still from the Nix days, if I understand. It will one day be rewritten in all Guile, presumably.
A question for nonguix contributors, including OP: is there a reason that nonguix has an nvidia package but not an nvidia service that handles more of this in a streamlined way, even just some stuff copied and pasted from this wiki?
There's an ongoing effort to smooth out the entire Nvidia process, e.g. https://gitlab.com/nonguix/nonguix/-/issues/198 has the current discussion. As anyone that has dealt with Nvidia on Linux, it is always a bit of a hassle and the effort hasn't yet happened to make it as smooth in Guix as other distros. We're getting there though.
