A new linux environment

Last Edited: Tue May 19 14:55:56 UTC 2026

Spoiler: GUIX

Impetus and goals

Over the last ~5 years I've been fortunate(unfortunate) enough to acquire and have to use three different computers and four different operating systems in my day to day: A mac given to me by my college, a Gaming Laptop with a battery so bad it's stationary and basically a desktop, and a work laptop. In terms of operating systems I have MacOS (mac), Arch (for gaming/general use), Guix (trying this out, planning to transition away from arch), and Fedora (Corporate Standard Build for work, but I can do pretty much whatever I want for my own dev). Now, this hasn't been too much of an issue but now that I've started to be an /actual/ developer doing my job, and getting involved in recreational programming at a level above "make something crappy and throw it up on github", I've started to experience several pain points that I want to fix:

1. Every system has its own quirks of configuration/installation/setup
2. My mac is ARM, everything else is x86
3. I use a different editor (neovim) for work and for personal stuff
4. I don't have a shared config for my neovim stuff
5. Switching between and managing python environments is Really Really annoying
6. Retro dev tools are not ergonomic
7. I have no centralized dotfiles management
8. My server is a mess to use

With all of these points combined, plus the fact that tools have really good cross-platform support these days, PLUS pycharm dropping support for the live collaboration feature (the only reason I'm using it), it's time to make some changes. My new setup will have the following principles.

• Maximum cross-platform compatibility
• Future proof(ish)
• Lisp!!!
• Prefer foss
• Be pragmatic

TLDR

Without further ado:

• OS(s): Guix, MacOS(phasing out once the laptop breaks), Fedora
• Editor: Neovim(lua, not fennel)
• Env management: Direnv + guix where applicable
• Desktop: Sway, Pipewire, waybar, greetd, wlgreet
• Programs: Kitty, Qutebrowser

I go into more detail below, but it's a fairly basic setup. Lots of standard choices, one glaringly obvious non-standard choice (guix, and maybe qute browser but I'm a vimkeys guy). Below is the rationale for each of these choices and little mini-blogs on the experience of choosing each of these. I will write a separate experience report on using guix at a later date.

Setup choices and rationale

Editor/environment management

Editor

Neovim, but more. Right now I have a horrible mixture of pycharm, and 2 different neovim configurations. The goal is to transition to only using neovim (but I'll keep pycharm around). The two different neovim configurations are pretty similar, but they both use outdated and weird ways of doing things. I spent a lot of time thinking about taking the plunge into emacs, but I like being able to easily use my neovim configs on my VPS for when I have to manually tweak stuff there. Plus, there's plenty of good configuration and theming that I can re-use so I won't have to start from scratch.

For all of my recreational programming this will be all well and good, but for work it's a slightly different story: I've never set neovim up for python. For the most part it will be easy, but I make pretty extensive use of the debugging features in pycharm, so I will need to find a way to hook into debugpy/pydevd (idk the difference, their relationship, or how they work to be honest). It might require a bit of elbow grease to get it integrated with ansible's debugging features, but there's already an example of getting it working with VScode and I can just ask the guy who implemented it for help if there's a need.

One quick note is that I haven't decided on the configuration language. On the one hand, Fennel fits principle 'Lisp!!!', but Lua fits the principle of pragmatism. To preempt the argument that "a fennel setup is heavier than lua" this is correct, but I'm already lugging around a whole suite of plugins so the "weight" of my neovim setup is already quite high. Still thinking about it. I'll be using lazy.nvim to manage plugins with the 1-file bootstrap, so I think I'll use lua, but we'll see how my mood strikes once I sit down to build a neovim config.

Environment

I want to start making more reproducible environments that will work across platforms. For one, many projects require lots of environment variables and other stuff that you have to deal with. My biggest biggest biggest biggest biggest pain point is dealing with python venvs at work. I store my venvs in a dedicated dir and it's annoying as hell to source ~/Projects/pythonvenvs/venv312/bin/activate UGH. So, I'm going to start using direnv!

Now, using direnv to smooth over some pain points is all well and good, but I want more reproducibility. For carrying dependencies and more from OS to OS, the most common solution might be a container (i interviewed for the Red Hat dev containers team, so I know that's a project), but I don't really care to do that ngl. A project I gave a try to years ago was Nix and I went as far as installing NixOS. I had a fine experience but for one reason or another I switched back to arch after about a week. I don't remember the reasons why I left NixOS, but I'm sure it was some combination of disliking the language, struggling with steam/gaming setup, and not generally understanding the nix workflow vs traditional linux (skill issue). Recently, however, I was chatting with a guy on a forum and he put me on to Guix which is actually a fork of nix, but it uses the gnu scheme extension language Guile instead of the Nix language. More on this in the next section.

A brief aside concerning retro dev

My biggest concerns about environment are largely related to my retro console programming hobby. I've been dealing with the headache of the pokemon mini toolchain recently and let me tell you, it is NOT FUN. The general experience for retro programming is windows-first for some reason, but the N64 guys have some really cool stuff going on (and recently a whole graphical Godot/Unity style engine :O). On libdragon, N64 stuff, they use a container. For the NES, it's usually cc65, your choice of assembler, or compiling a compiler (like Nesfab) from source. For pokemon mini on linux, it's using x86 Wine to run a bunch of old .exe files scraped from the Epson website.

To put it another way, it's scattered, difficult to work with, generally poorly documented, and requires some elbow grease. I've already done some work to improve the pokemon mini experience on MacOS, but I'd like to start writing packages for Guix that someone could just install guix and run. For my target audience this isn't much easier, so I'd be very happy if someone took my .scm files and plopped them in an LLM to build a package for the AUR or for another system. I'm even looking into guix-pack'ing a couple things together to make it even easier. Either way, I want something like Nix or Guix that's designed to make stuff portable.

OS

I plan on switching to Guix System as my primary

WM+necessities

Sway, blender, steam, the works yk?

Dotfiles

The benefits of declarative management are, in my opinion, obvious

(sidenote) General update

Been awhile since I've updated the blawg. I meant to blog more often this year, but ngl I haven't had much to say and have a few long-term posts planned (year of latin). I've been doing a bunch of retro computer development (mostly c64 for now) and it's been really fun.