I was intimidated by having to install some drivers with nonguix, and had been experimenting with foreign installs of Guix on Debian and Ubuntu. I had been using Ubuntu and Debian for my entire “adult computing” life, but the siren call of the declarative builds and a bad experience bouncing off of Nix left me trying Guix. Things never seemed quite right with the foreign install, in particular with maintaining shell environments with my .bashrc. So, I faced my fears and made an attempt at installing Guix System, and have been pleasantly surprised with the whole process.
Positives:
- 
Adding a new channel (nonguix) or any others you are interested in is a matter of modifying a channels.scm for your user and root. If you can modify an i3 config to change a hotkey you can handle this.
 - 
Adding drivers for your hardware is almost as easy. Personally, I used LLM to help me figure out my hardware and which drivers I need. This worked wonderfully, and by adding two drivers in my system.scm everything “just works”, including adding a nonfree kernel. This was the only moderately complicated part, and I could have done it all myself if I didn’t need to know about separate initrd and firmware functions. Almost anyone with Claude Code and capable hardware can get Guix System working in short order.
 - 
Guix home is amazing and so easy. One of the big pulls for using Guix system is that I hate having to worry about .bashrc, .profile, /etc/profile, .bash_profile, whatever, all these hidden files. Guix home does a great job of making sure I’ll never have to think about them again, as it is all handled by my home.scm.
 - 
All of these things have great complimentary overlap! If you can make your home config but want to try guix system good news- it’s just a little bit more lisp code and if you can do one you can do the other!
 - 
Extremely favorable for LLM fueled workflows. Everything declarative is good for this, and guix is no exception. If something didn’t work, you can just change and try again, or worst case roll back, with no fear inside guix-land.
 - 
Overall, I would describe the overall difficulty experience for an imaginary “average linux user” as being easier than doing a fresh install of a modern Debian, with a couple of gotchas, but you are getting something much better out of it at the end of the process. In my opinion you should be aware of a general purpose user friendly distro like Ubuntu for your grandma and computers that you just want to have an internet browser and wifi on, and then Guix System for everything else.
 - 
Managing emacs with guix home is amazing. I haven’t fully committed to managed my init.el from home.scm yet, but even having my emacs packages linked to my profile means that I can do a guix home reconfigure and git pull my emacs profile on ANY system (with guix installed) and get an emacs exactly the way I like it with all the packages, and my development environments etc. are a short command away.
 - 
Amazing manual
 
Negatives:
- 
I think that the documentation should encourage the user to use Guix system more. Many sharp edges of a foreign distro Guix are resolved on Guix system. Even experienced developers will experience pain with environment variables unless they go into using Guix with open eyes about environment variables. In my experience, most difficult-to-resolve problems with Guix have amounted to environment issues, but that could be specific to my experience, and is resolved a lot on Guix System.
 - 
I can’t find any VPS that will give me Guix boxes by default. I think I may be able to experiment with using Guix system images for this, but I haven’t gotten there yet.
 - 
Some packages do not work yet, this has only been an issue for very recent projects that are less than a year old without a large Guix userbase. My hope is that Guix is easy enough to work on that I can help there.
 - 
Although the daemon and Guix home do a lot to resolve this, the entire situation around shells, sourcing profiles, etc. feels delicate and I’m scared to go off of the “happy path” for some things. For example, if a tool wants to use a shell script to install itself and doesn’t have a Guix package, I’m very hesitant to do so, because if it tries to modify my .bashrc I’m not sure what will happen because it’s managed by Guix home.
 - 
The nonfree channel distinction is a negative for the average user, but I understand why it is necessary and perhaps desirable. I feel I have “dirtied” my system a bit by adding it and I’m less likely to seek support because of it.
 - 
Amazing manual leads to RTFM culture and few examples, lack of examples in general
 
Thanks Guix people! The primary purpose of this post is to encourage people curious about guix system and enjoying the package management system to take the full dive in, because I found it an easy and enjoyable experience compared with setting up a linux distro for daily use and development. In fact, I had begun a reinstall of Debian intending to use foreign Guix, got frustrated with the corner cases, and decided to commit to this if the difficulty is equivalent or even easier. This is an awesome project, and I hope to be able to continue to use it as a daily driver and for development projects.