This configuration has two primary goals: it should allow full bootstrapping capabilities from a live USB containing this repository (see the bootstrapping section) and it should make it easy and safe to switch between radically different configurations.
Currently, this system only supports NixOS. Even though I plan to use Nix as my primary driver, I’d like to be able to experiment with other distros, notably Guix and Gentoo. I imagine the best way to do this is to create separate BTRFS subvolumes.
After originally having been totally convinced I’d use a single literate config file for my entire dotfiles repo, I’ve finally decided against it. Here’s a pro/con list (wrt literate config) that led me to this decision:
Pros:
- It keeps documentation and code side-by-side, which potentially makes it easier to understand chosen configurations.
Cons:
- They add a layer of complexity when something goes wrong. For example, if there’s an error in my Emacs config, I have to edit the files directly and then redo the edits in the literate config.
- Programming tools are well-designed for traditional source directories, but not really for literate configs. Counterintuitively, this makes literate configurations somewhat harder to navigate than traditional source directories (jump to definition etc don’t work, just simple searches). Of course, you can get all of these things to work, but you need to leave the literate config to do so. It just feels like you’re splitting yourself across separate systems.
- Literate configs require a fair amount of prerequisite software to work, whereas traditional source dirs just need vim and a terminal if all else fails.
- The adjacency of documentation and source code is not as good as it sounds. In order to avoid a complex web of code fragments that your tools can’t navigate, you need to keep code chunks large. So, if you want to document things with a high-level of granularity you need to use code comments anyway. The larger literate documentation sections are not too different from READMEs at the end of the day.
Modifies the behavior of existing programs. This is not used to change how we compile the program (e.g. optimization flags, etc.). For that, use overlays instead.
Computer-specific configurations.
Overlays change how Nix compiles a program. For instance, if Nix compiles a stable release version and we’d like the master version, or we’d like to change compiler flags (for debugging or optimization, etc.) we’d probably use an overlay.
Bash scripts to bootstrap and configure a system and to perform sysadmin functions.
When developing kicad libraries (such as symbols, footprints, etc.)
change the kicad config settings to point to the appropriate
directories (e.g. \tilde{}\slash{}src\slash{}kicad-footprints). Do not
change how kicad is compiled. That will prevent you from modifying
library components.
I haven’t yet setup octave packages in a Nix-declarative way. They are
installed adhoc with pkg install /package/ -forge and go in the octave
subdir of home. This is less than ideal and not reproducible.
All bootstrapping scripts are located under scripts\slash{}bootstrap.