It is inspired by Nix, but with a few key differences:
- it is developed under the flag of the GNU Project, so you can expect the same standards of quality of both code and documentation as the rest of the GNU Project
- it uses GNU Guile as the main language of the system instead of Nix, which (allegedly) allows you to extend or modify the behavior of the whole system
- it uses GNU Shepherd as the service manager instead of systemd
All the main goals of the projects are pretty much the same.
Oh yes, I completely forgot to mention that monumental achievement :)
For any readers unfamiliar with the importance of reproducible full-source boostrapping, please consider reading the paper "Reflections on Trusting Trust" by Ken Thompson [0], the creator of Unix.
The other big thing is that being a FSF project they are much more committed to free software than Nix. It's harder to get stuff like Chrome, Steam, Nvidia drivers etc. Not impossible but you're definitely swimming against the current in trying.
Important to note that it’s not hard or swimming against the current - you just use the nonguix channel, which has all of those things and is a perfectly acceptable use of the system (it’s what channels are for) - but it’s not in the default installation.
They don't want to compromize their mission - which is to provide a fully-free operating system. But they recognize that, at the current moment, non-free software is required for many users. So they maintain an unofficial repository for non-free software, and avoid endorsing or promoting it on the official channels.
> Too ideological for someone who wants to get stuff done.
The maintainers of Nonguix are mostly the same people working on Guix, so you can expect the same amount of ideology :)
This is what ultimately bounced me away, along with seeing some negative interactions others had. Sure I might not end up with problems, but I’m going to choose to believe them when they tell me the official communication channels will be hostile to me if I do have problems that need the unclean fixes.
Which is a shame, because I think there are some technical things which guix does better, but I find it’s more important to not have to worry about saying the wrong things in the wrong places when troubleshooting basic issues like what I get with the nix community.
That's an unfortunate take. "Unclean" is your choice of words, not ours. There is no hostility to people who use proprietary software, nor is any kind of judgement of other people's computing purposes and habits warranted.
Personally, I avoid proprietary software where I can, but I've found myself in many situations where I'm made to use it. But that's really the point: the free software movement's goal is to create a world in which people are no longer compelled or coerced or forced into being mistreated by proprietary software. You don't need to subscribe to these values, of course, but it is unfortunate if you experience this goal as a personal judgment. Keep in mind that one of the four software freedoms is the freedom to use software for any purpose you want --- judgement of users would be a completely misdirected emotion.
Having said that, the Guix project's communication channels simply aren't for proprietary software. The Nonguix communication channels are. The HPC channels are. You will likely get redirected to those communication channels if you ask about proprietary software on Guix project channels.
I wouldn’t say it’s too ideological for someone who wants to get stuff done. To get stuff done with Guix, you just go do it and it won’t get in your way - the project channel and the nonguix channel won’t interfere with each other, they’re just different channels.
Directions for using Guix in practice (i.e. with some non-free software) could definitely be easier to find, especially if you start green and don’t know what you’re meant to be looking for. But the system won’t get in your way.
It's (deliberately) difficult to discover. I tried GuixSD once, and bounced off it because of the apparent lack of support for my hardware, CUDA, Pytorch et al, which isn't an uncommon story apparently.
Now, seemingly there are channels that would deal with this. But when I asked through the official channels, I was told not to do that -- that is, "don't use nvidia dummy", which really isn't an option. I was never pointed to the non-free channel.
I agree with that - directions for how to use Guix in practice, i.e. for someone who isn’t a GNU warrior using 15 year old hardware because you don’t need non-free blobs, need to be easier to come across.
The FSF is not involved in the project. The FSF had no say in what service manager we use.
A common misconception is that we somehow don't like systemd. It just so happens that having a thing that's written in Guile (like the rest of Guix) allows for some code sharing. Hey, we've got the initrd in Guile, too. Might as well go all the way, eh?
Apologies, I assumed that being a GNU project (which is supported by the FSF), the project identified as an FSF project.
> A common misconception is that we somehow don't like systemd. It just so happens that having a thing that's written in Guile (like the rest of Guix) allows for some code sharing. Hey, we've got the initrd in Guile, too. Might as well go all the way, eh?
I didn't have this misconception, but let me correct my statement:
But also, I realize that guix devs have to do what guix devs have to do, glad they're around.
GNU Shepherd (was aka DMD) predates systemd by many years. And many other “PID 1” efforts.
It also had different goals when Wolfgang and I designed it, one might say even incompatible since we were targeting the GNU/Hurd specifically and wanted easy ways to manage translators there on a per user basis.
One thing that hasn't changed, though, is that compatibility with the Hurd is still a major goal. Sadly (but understandably) development pushes forward for Shepherd on Linux and then we aim to make it work on the Hurd, instead of letting Hurd-native facilities guide development. But this might change as there is considerable overlap between Guix contributors and Hurd enthusiasts.
- All issue tracking and discussion happens on a mailing list/with custom tooling
Also IIRC Shepherd was a simple 1-level service manager like runit. Is that correct? I played around with it for a while and came to the conclusion that it couldn't represent a service graph.
Same... Apart from the extreme view on freedom in guix. Loadable firmware? No. Microcode updates for your CPU? No. Not free enough! There's non-guix and all that, but really... if the main project tells you this is now what they want, you will run into issues one day.
No it's not like that all. Free software is a component of it, but Guix is not a fork. It's a completely separate implementation of the functional package management model with many significant differences and advancements. It uses Scheme, a general purpose and extensible programming language, rather than a custom DSL like Nix. Scheme is used for build scripts as well and a lot of code can be shared between the host and build containers. Nix uses Bash. Having one language unifying all the layers makes it easier to hack on the entire stack. Guix has a stronger focus on reproducible and bootstrappable builds and is making notable advancements on the "software supply chain" security problem. OS service configuration is done through a graph extension system whereas Nix uses something more like a flat hash of config values. I could go on but I hope this makes the point that Guix isn't just taking Nix and removing proprietary stuff. It's its own thing.
