From 223bbcf7f65d3225b3c1568bd9ccb847c54028d8 Mon Sep 17 00:00:00 2001 From: Ryan Schanzenbacher Date: Sat, 19 Oct 2024 23:22:04 -0400 Subject: Fixed some deprecated variables didn't mean to add these --- content/projects/1-guix-intro.md | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) create mode 100644 content/projects/1-guix-intro.md (limited to 'content/projects') diff --git a/content/projects/1-guix-intro.md b/content/projects/1-guix-intro.md new file mode 100644 index 0000000..d868381 --- /dev/null +++ b/content/projects/1-guix-intro.md @@ -0,0 +1,27 @@ +--- +title: "Guix Part 1 - Introduction" +date: 2024-02-07T15:03:17-05:00 +draft: true +--- + +# Preface + +Welp, I am finally getting started with writing about Guix... This has been sitting in the back of my mind ever since I announced I was going to do it all the way back in... May.. of 2023. Woops. Sorry about that. I'll be honest, I still don't feel _completely_ ready to be writing something like this, but at the end of the day, I don't think I'll ever be. It's that feeling of "I could always know this a little deeper, a little more complete." that has been holding me back. However, I think at this point, I can safely say I know the absolute _basics_. Most of the main concepts I will talk about, even though I'm specifically referring to Guix, can even be transferred over to NixOS. If you find this series useful, please reach out and let me know, I'd love to hear :). Without _further_ ado, let's begin! + +# Introduction + +As I stated previously, I switched over to using [Guix](https://guix.gnu.org) as my main Linux distribution around April of last year. Surprisingly (to me as much as everyone else), I've stuck with it and have since fallen in love with its ideals. The idea of functional package management has always been intriguing to me, given the state of package management on every other distro. Its always been the same: install the packages you need (or want to try), inevitably forget you installed about half of them, taking up space on your drive, run into :ogre: ***dependency hell*** :ogre:, and if you use more than one computer regularly (like a powerful desktop at home and a smaller, but more power efficient laptop on the go)-- good luck keeping them in sync with each other. For example, my workflow consists of two computers: my main laptop that I keep docked at home due to its battery life, and a secondary I carry around with me... again for its battery life. Throughout college, I would switch between them through the day. Do a little homework on the go, do a little more when I get home, etc. Which was fine, I sync my files with either Git (if coding) or Syncthing (general purpose files). However, the biggest issue I would constantly run into (especially in the type of work I usually find myself doing) is inconsistent state of my machines. What exactly does this mean? Well, imagine this: You have an assignment to complete. To do this assignment, you need to install some external software of some kind to do this. Sometimes, this software may be custom/prioprietary/require custom configuration/anything else that may happen. So, you spend the first hour of homework simply getting your environment to work. You get it to work and go about your day. You get home to continue your harrd work aaaaand...... you need to install everything again.... No matter, you just did this earlier in the day (because you work hard and would never procrastinate.... right?), it should be a piece of cake to recreate your environment. However, your computers obviously aren't identical. Months and months of varied usage has caused them to diverge somewhat, try as you may to keep them somewhat the same, by syncing dotfiles for instance. So, you try to recreate your environment aaaaand, it's broke. Why's this, I did the *exact* same steps on my other computer. Turns out I updated this other computer more recently, causing an incompatibility of some kind. Let's try and fix it.... 30 minutes of sunk time later and I either get it working or I just switch to my other computer again. Anyways, hopefully that illustrates the point I'm trying to make: computer's by default are inherintely *stateful* and, while I'm not saying state is bad outright (it's absolutely necessary to actually do anything useful!), maybe some less imperative state could be beneficial. Now, where does Nix/Guix come into this? Imagine the same scenario as last time, however one important change: you are now running Guix and your system is *entirely* configured (programs installed, dotfiles, even the bootloader) declaratively (more on that in a moment). You make changes by updating files, and those exact changes are synced over to your other computer and applied. Now, all of a sudden, you no longer have this issue of systems that don't behave exactly the same, because for all intents and purposes *they are exactly the same* (provably, in fact!) + +# Imperative v. Declarative + +So, I described the system being described *declaratively* above. What exactly does this mean? Well, most systems (Linux, macOS, Windows, etc.) are all designed on an *imperative* model. The systems are inherintely stateful, and making changes requires running commands in a certain order to reach a desired state. For example, say I wanted a computer to have Firefox, NeoVim, git, and Wireshark to be installed. I would need to either go to all of these product's websites (in the case of Windows) or run the appropriate commands in my terminal (like `apt`, `dnf`, `pacman`, etc.) in the case of Linux to actually get my system to this desired state. Then, if I want to replicate that state on another computer, I would need to: 1. Start at a common point (to guarantee the end state is the same), 2. Hope that packages haven't been updated (or pin them somehow), 3. Run the commands in the same order. Take all of that, in contrast, with declarative computing. In that case, you define an *end state*. For example, I would create a file that would describe my desired end state, not really caring what has to be done to actually get there. I would say "I want firefox, NeoVim, git, and Wireshark of versions x installed" and whatever backend is being used would figure out how to get my device to this end state. The best (and most well known) example of these principles (sort of...) would be Ansible. By default, you make playbooks that describe how you want a system to be set up (what files present, what packages installed, etc.) and it figures out how to get to this desired state. You don't really need to worry about the individual commands, per se. + +# Getting started + +So, with all of that said, how do you get started with using Guix or Nix? Well, first you actually need to choose one or the other (sorta, more on that in later posts!) So how do you actually choose between the two? Well, it's mostly an ideological choice at the end of the day, but there is one key difference. Nix was the original package manager, where NixOS was built around it. Around 2012, Ludovic Courtès released the first version of Guix (a play on the words Guile and Nix, which sort of describes its main selling point) as a component of the "GNU system". Two key differences between Guix and Nix are: Nix uses it's own language to describe derivations, Guix extends on Lisp, specifically *Scheme*, to describe derivations. Personally, I prefer using Scheme since it is already a functional language, by design. Plus, I have the power of the entire Scheme ecosystem behind me. Second, Guix focuses *very* purely on free software, where non-free software isn't even packaged (think like Discord, default Google Chrome, etc.) and it uses the Linux-libre kernel by default. On the other hand, Nix also focuses on free software but there is an option you can toggle to allow non-free software to be installed. However, with free software comes the freedom to do what you want with it, like installing non-free software anyways :smile:. So, I personally chose Guix since its paradigms checked more of my boxes, per se. + +# Coming soon... + +Given the length of this post has already ballooned more than I was expecting, I will be starting the actual Guix installation guide in Part 1 of this guide, hopefully coming out in the next few weeks (yay Spring Break!). Afterwards, I'll be delving into managing a home environment with Guix, then finally I will be making a series of posts describing how to actually hack Guix to make it purely your own (as well as hack it to contribute back for the greater good of everyone!) + +Until next time! -- cgit v1.2.3