change guix part 0 to not be draft

1 files changed, 5 insertions, 5 deletions

diff --git a/content/projects/1-guix-intro.md b/content/projects/1-guix-intro.md
index d868381..c7a260d 100644
--- a/content/projects/1-guix-intro.md
+++ b/content/projects/1-guix-intro.md
@@ -1,7 +1,7 @@
 ---
-title: "Guix Part 1 - Introduction"
-date: 2024-02-07T15:03:17-05:00
-draft: true
+title: "Guix Part 0 - Introduction"
+date: 2025-06-17T08:15:00-04:00
+draft: false
 ---
 
 # Preface
@@ -10,7 +10,7 @@ Welp, I am finally getting started with writing about Guix... This has been sitt
 
 # 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!)
+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 hard 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 inherentely *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
 
@@ -22,6 +22,6 @@ So, with all of that said, how do you get started with using Guix or Nix? Well,
 
 # 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!)
+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. 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!