# GNUrvana: a dotfiles repository that deploys itself with stow and guix home > daviwil's dotfiles repository holds a complete system configuration for a Guix-based Linux desktop, with user-level files kept under .files/ and symlinked into place by GNU Stow and Guix Home, so a new machine is set up with two commands. It is worth reading as a worked example of a keyboard-driven, text-configured desktop, not as a configuration to install unchanged. **daviwil/dotfiles** — [MIRROR] The path to GNUrvana - Repository: https://github.com/daviwil/dotfiles - Website: https://config.daviwil.com - Stars: 898 · Forks: 166 - Language: Emacs Lisp - License: MIT - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/daviwil-dotfiles ## Two commands to set up a machine The repository is the home of the author's custom system configuration, and its stated purpose is to enable a consistent computing experience across multiple machines. The author primarily uses GNU/Linux via the GNU Guix distribution. The deployment mechanism is the part worth stealing. Configuration files are managed with a combination of Guix Home and GNU Stow, which allows symlinks for all user-level configuration to be set up with two commands: ```bash stow .files/ update-home ``` The second command is the author's own custom script, and the README points at its location in the tree, .files/.bin/update-home, and explains that it launches the guix home command. So the two-step sequence is: Stow lays down the symlinks for the plain files, then the script applies the Guix Home configuration on top of them. That split is what makes the setup portable between machines. Guix Home handles the declarative part, the programs, the services and the package list, and Stow handles the files that Guix Home does not manage, the Emacs config, the shell aliases, the editor settings, anything you would otherwise write by hand into a dotfile in your home directory. Because the two mechanisms have different jobs, neither has to be stretched to cover the other's cases. The top-level layout follows that division. There is a .files/ directory holding the stow-managed tree, a daviwil/ directory which is the Guix Home configuration, an .emacs.d/ directory, an emacs/ directory, a backgrounds/ directory, an .archive/ directory holding a retired literate configuration, a .site/ directory, a .build.yml file, a .mcp.json file, a .stow-local-ignore file, a .gitmodules file, an Emacs.org file, a README.org and a tangle.sh script. The description of the repository is a mirror notice, and the homepage is at config.daviwil.com. ## Four principles behind the tool choices The README states the principles the configuration crystallises, and they are more useful than the file list. The first is keyboard focus. The author prefers tools that let him control everything primarily with the keyboard, because when you work with words and code all day, reaching for the mouse switches your input modality and slows you down. GNU Emacs covers about 80 percent of daily needs with consistent key bindings, another 15 percent is handled by websites and apps, and qutebrowser is named as the tool that makes web browsing keyboard friendly and integrates with the Emacs workflow. The second is minimal distractions. The workflow is built around a single main screen with an occasional secondary screen, the laptop, when docked, and very rarely more than one buffer or window visible at a time. The argument given is that Emacs makes switching between buffers and workspaces in EXWM easy and fast, so there is no reason to have two unrelated things on screen. The mode line is deliberately minimal, using doom-modeline, and only a small amount of computer status information is shown in Emacs' tab-bar-mode. The third is text-based configuration. The author says he really does not want to use a program that does not support text-based configuration files, and also prefers tools that do not write those files out on his behalf. The stated benefit is that program configuration can be committed to source control, in this repository, so configurations stay in sync across every machine. The fourth is high customisability. The criterion is whether a tool lets you intercept or replace the code for what it does, which is where Emacs is described as the most faithful adherent. For everything else, the requirement is that the tool is scriptable or can call out to another process to gather information. Vimb and Polybar are named as tools that do this, which makes them easy to fold into the rest of the workflow. These principles are a decent checklist for evaluating your own setup, whether or not you use any of this. ## From literate Emacs config to a Guix Home declaration The repository has been through a structural change, and the remains of the earlier approach are still visible in the tree. The README says the former literate configuration has been replaced by a Guix Home configuration, with the old version archived in the .archive/ directory, and that the author will document the new setup more completely as time permits. The .archive/ directory and the Emacs.org file at the root are the fossils of that literate phase, in which configuration was written as prose with embedded source blocks and tangled into files. The tangle.sh script at the root is the tool for that workflow, and the .build.yml file suggests the tangle step is run in CI. The top-level Emacs.org file is an org-mode document, which is the literate format the script consumes. So the current arrangement is two literate systems living side by side. The Emacs side is still literate, with an org-mode document that tangles into the Emacs configuration, and the system side is declarative Guix Home, with the daviwil/ directory holding the home configuration. The archived directory keeps the earlier generation of the Emacs configuration so that the history is recoverable rather than deleted. Two directories carry the Emacs setup itself, .emacs.d/ and emacs/. The .stow-local-ignore file is the Stow mechanism for excluding specific files from being symlinked, which is the practical way to keep a file in version control without having it appear in your home directory, and its presence confirms that .files/ is the tree Stow operates on. The .gitmodules file says the repository pulls in at least one external piece, and .mcp.json suggests the configuration also carries a Model Context Protocol setup, which fits an Emacs-centred environment where an editor assistant is part of the workflow. ## Why this is a personal environment rather than a package The most important thing to understand before reading any of the configuration is what this repository is not. It is not a distribution, a framework, or a themed desktop that other people install. It is one person's environment, committed in full, with the author's own names in it, the author's own directory layout, and the author's own principles baked into the tool choices. The README even says the configuration files crystallise a workflow that is increasingly effective and satisfying for daily use, which is a description of a personal habit rather than a proposal for anyone else. The path structure makes that concrete. The title line of the README is the path /home/daviwil/.dotfiles, and the tree contains a daviwil/ directory. The .files/ tree has a .bin/ directory inside it, holding the update-home script that the deployment runs. These are the artefacts of one machine, one user name, one set of habits. That does not make it a poor artefact to read. The opposite. A dotfiles repository that hides its decisions is not much use, and this one states its reasoning in the same place as its configuration, so a reader can see why a tool was chosen and what trade-off the author accepted. The SystemCrafters YouTube channel and its playlists go further, with step by step creation of a custom Emacs configuration from scratch, a minimalistic desktop environment with EXWM, a development environment using lsp-mode and dap-mode, community package tips and Emacs as a mail client. So the realistic use is borrowing. Reading .files/ and the daviwil/ directory to see how a keyboard-driven Guix desktop is put together, and taking the ideas, not the files. The README's own tooling choices also tell you what the author considers non-negotiable, and those are the parts most worth questioning when you borrow, since Guix Home, EXWM, doom-modeline and qutebrowser are a specific stack rather than a general one. ## Licensing, cadence and the absence of releases The licence is straightforward and worth stating precisely, because dotfiles get copied more casually than most code. The project is released under the MIT License unless otherwise specified by license files in subfolders. That qualifier is the operative part. When a configuration pulls in a subproject with its own terms, those terms win for that subproject, and the repository ships the LICENSE file at the root alongside the.files/ and other directories. Anyone copying a directory wholesale should check what is in it rather than assuming the root MIT notice covers everything, and the README does not enumerate the per-folder exceptions, so those have to be read from the files themselves. On maintenance, the repository is not archived and the last push was on 2026-10-22, on the master branch. The recent releases list is empty, because the repository has no GitHub releases at all. There is no version tag to pin, no changelog and no release notes to read before upgrading. That combination, a recently pushed repository with no release history, is a specific situation. It means the master branch is the only thing to point at, and it means there is no way to see what changed between two points in time except by reading the commit log. For a configuration repository that is a normal state of affairs, since the author is the only user and the history is the documentation. For anyone else, it means adopting the configuration means tracking a moving branch rather than consuming a version. The repository also has a.github/ directory, so the CI that runs the tangle step and whatever else the build script does is configured there, and the.build.yml file at the root is the pipeline definition for it. The hosting is a git remote on a service the author uses, and the homepage config.daviwil.com is where the rendered version of this same configuration lives. ## Conclusion GNUrvana is worth reading and borrowing ideas from if you run GNU Emacs on Guix and want a keyboard-driven, text-configured desktop, because the principles are stated plainly and the whole configuration is committed to a repository you can read. It is the wrong thing to install wholesale if you do not use Guix, since the deployment path depends on guix home and on a custom update-home script, and it is the wrong thing to fork if you want a maintained upstream package rather than one person's environment. Before you adapt any of it, read the .files/ directory rather than the README alone, check the tangle.sh script that generates part of the tree, and confirm the last push date, since this repository has no tagged releases to fall back on. ## FAQ ### How do I set up the configuration in daviwil's dotfiles repository? The README gives two commands: `stow .files/` to symlink the user-level configuration, and `update-home`, which is the author's own script at .files/.bin/update-home that launches the guix home command. ### What tools does the GNUrvana configuration use? The README names GNU Emacs as the main application with doom-modeline for the mode line, EXWM for window management, qutebrowser for keyboard friendly web browsing, and Vimb and Polybar as scriptable tools that can call out to other processes. The system side is the GNU Guix distribution with Guix Home. ### What is the difference between the .files/ and daviwil/ directories? The README says the configuration files are managed with a combination of Guix Home and GNU Stow, with Stow handling the user-level files under .files/ and Guix Home applying the declarative system and home configuration, which lives in the daviwil/ directory. The .stow-local-ignore file at the root excludes specific files from being symlinked. ### Does the repository have tagged releases? No. The repository has no GitHub releases, and the recent releases list is empty. The default branch is master and the last push was on 2026-10-22, so the branch is the only thing to point at. ### What licence do these dotfiles use? The README says the project is released under the MIT License unless otherwise specified by license files in subfolders, so individual subdirectories can carry their own terms. The MIT LICENSE file sits at the root of the repository. ## Sources - [daviwil/dotfiles on GitHub](https://github.com/daviwil/dotfiles) - [Issues](https://github.com/daviwil/dotfiles/issues) - [License: MIT](https://github.com/daviwil/dotfiles/blob/master/LICENSE) - [Project website](https://config.daviwil.com) - [README](https://github.com/daviwil/dotfiles/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/daviwil-dotfiles