A decade of dotfiles
evanhahn.com
evanhahn.com
Personally, I stopped worrying about dotfiles and GNU stow after joining the cult of Nix. While I gave honest attempt to everything else, Nix made it stick. Now I only have one single repo, where In write config for (almost) all of my applications in Nix, deploy them with Nix, rollback with Nix etc. Compared to hodgepodge of INI/YAML/TOML/XML/JSON/WHATHAVEYOU it is nice to to only have single tool to worry about.
I wished Guix had the momentum and size of Nixpkgs. I'd much prefer a Lisp than the language contraption of Nix.
For example, my emacs config is a literate org file, which is important to me. It is large and complicated and I don’t feel like it’s a good fit for an “all my configs together” solution. I’m not sure how that would fit into home manager and while I’m sure the answer is in the docs somewhere it just seems hard enough to get to that it stops me from really digging in.
1. There's some syntax for importing files "raw" as strings; I don't recall details now from memory, but it's used extensively e.g. to load contents of .patch files. So you could have an Org file and get it imported.
2. I suspect there's some "smart wrapper" (so-called "module") for emacs in home-manager; it could conflict with your one. But using the "modules" is not mandatory; you can just have h-m put raw files in your ~/.emacs/ dir or whatsit, and add emacs in your $PATH. The thing that may be most tricky would be plugins - sure doable, but could need some nontrivial work. Alternatively, you could try seeing if the emacs module has some "extraConfig" field or something similar, and plug your literate Org there.
I have a literate config that works with home-manager.
The problem is the 800 noweb-ref blocks took 10+ seconds to tangle.
I reported it, and someone optimized tangling to 0.5 seconds. I'm still using the custom patches though since the changes haven't been released or maybe even merged yet.
And frankly, I barely have motivation to study more concrete stuff...
I used the simple template generated during nixos-install and kept adding packages I needed. Configured them manually as usual and went about my business. It works out more often than people would realize. For services, development toolchains etc just google and copy-paste from other people's config. Simply add 'ext:nix' to google query and you should be good.
I'm at almost 3 years, know just enough Nix to write some custom stuff, but nowhere close to the Wizard title. Its not as bad as people make it out.
Remember, your target is not to master it on day 1. Target is to get VLC to play the media file (or some equivalent for you).
https://github.com/nix-community/home-manager
I use it on NixOS. It should absolutely work on other distros unfortunately I don't have any first hand experience with that or with what the best way is to set it up on other distos (I think there are few options for how to do it).
I'm curious about your phrasing. In idiomatic English, this says "there are _not many_ options", IOW options are limited. It emphasizes the constraints. OTOH had you written "there are _a_ few options", it'd emphasize the existence of more than one option, with a positive connotation.
From context I infer you meant the latter, is that right?
I meant to write 'a few options'.
e.g. with nix installed, you'll be able to use the nix-shell to get the development dependencies without having to install system wide, if a shell.nix or flake.nix has been written for it. (e.g. for repos like https://github.com/helix-editor/helix).
You'll be able to use the `nix shell` command to try out a program without needing it installed system wide. Or you can figure out how to write your own nix-shells etc.
I think Home Manager is worth trying only once you're otherwise familiar with Nix (or if you find a good config to copy-paste from, though), since Nix's error messages and debugging still aren't great.
There are some other advantages: rollback to a previous state at any time, enable complex system services with one line in your config file, install multiple versions of tools on your system without conflicts, install programs without root (using home manager), build VMs and Docker images, pin the versions and dependencies of all packages for reproducibility, patch software with your own tweaks natively. You can also put a Nix file in a code repo and easily share your build dependencies with other developers.
Nix stores all builds of its packages in a separate “store” on the machine, each identified by the hash of the build (“derivation”). When you activate your config, it basically symlinks the version you want into your PATH.
If your project needs a specific version, when you activate a Nix shell or script it will check your store for that version and activate it. If it doesn’t exist, it will fetch it (or even compile it from scratch if you need to).
Does Nix allow for a similar workflow? It's really nice to be able to move between projects and automatically have the correct tool versions configured without having to run any special command.
I think the nice thing about project-specific tooling like this is it allows getting started with the project very easily. (Rather than copy-pasting "apt-get <whatever>").
However, if you really want to make sure that you're not including anything from your system, you can have direnv pass the `--pure` flag, which will then include only the dependencies from the project and nothing else. This is helpful to make sure that you're not accidentally relying on something already on your system when you declare the project dependencies.
In terms of applying configs, ansible is 'convergent', where Nix is 'congruent'. https://blog.flyingcircus.io/2016/05/06/thoughts-on-systems-... (ansible will make changes to get it closer to a target state, whereas nix will reach the target state by constructing the target state again).
I'm a little way into the Nix Pills document (https://nixos.org/guides/nix-pills/why-you-should-give-it-a-...) which seems to start the explanation from a place where I can understand.
e.g. create a g zsh alias for git using the alias section of zsh module in home manager
> g = "${pkgs.git}/bin/git";
I personally switched for these reasons.
This is an extensive study at trying to 'understand' Nix, because is does so many things differently: https://ianthehenry.com/posts/how-to-learn-nix/
If you're just looking to start building your system, follow NixOS manual up until you have a running system, then pace yourself as you will. You can also setup Nix on existing Linux distro or macOS and practice the ropes before plunging into NixOS.
No need to boil the ocean, just start small. You can mix and match with what you're using now. If you like, port it all to nix over time
all the randomly named config options and the spotty coverage of them were like fingernails on the chalkboard for me.
Options are almost exclusively discovered through search.nixos.org, the configuration man page or by reading the source code. Since the introduction of structured settings there is also often a way to set settings in a freeform type.
There are a fair few very vocal former NixOS users who miss no opportunity to extol the benefits of Guix in the chatrooms I frequent, though. Not without merit either, I should say: the project and its UX does seem to be much more well-thought out; it's developed by GNU; the project takes software freedom seriously; many will surely enjoy hacking away at their config in Scheme. As it stands currently, though, there are more resources and it's easier to get things done with NixOS - you also get to use learn a (imo really great) packaging system that is in somewhat wide use.
Had never lisped before.
It seemed cool and I tried my hand with a tutorial that makes you embed guile in a C program to make it interactive. It was okay but it seemed like too much boilerplate to have to register functions individually but maybe it is standard when embedding. Never tried with lua or Janet before so I can't say.
In general there is a lack of resources, it is quite hard as a beginner to get a start with the language past playing with the repl a little.
Also tried to see if there was a Guile version of the famous SICP but ugh it was not straightforward.
I gave up. Hope Guix will foster better resources on Guile Scheme.
Knowing a Lisp in general is a significant advantage for a person who deals with writing code, IMHO. (I feel the same about regular expressions.)
This is exactly my feeling as well. The fact that Guix uses Guile (which is basically Scheme, a Lisp) throughout the entire process (even from the preboot environment!) is kind of a big deal. Plus the commandline UI is just better (at least if you prefer your package manager to look like "brew install <packagename>" instead of "pacman -Ssyyu <package>"). I know the "nix" command is making headway there but it's apparently also being rewritten at the same time and is basically still a buggy clusterfuck plus I hear there's an added complication of friction between the older nix devs and the newer committers working on the newer stuff.
I almost wish there was a "declarative Bash" variant on a fork of Nix that would allow people to lean on Bash knowledge but would only permit declarative style operations, so you could get the underlying Nix goodness but would have a more familiar (to most) declarative command language on top of it... or even better, something like https://wryun.github.io/es-shell/
... but you'd still lose the nix momentum
Here is my experience so far :
Fundamentally it's a pretty simple language. Once you grasp those details, the rest kind of falls into place where you look at some code and go "Oh, THAT'S what it's doing".
I also answered your comment there.
It’s using the Nixpkgs version, which unfortunately depends on which nixpkgs channel you’re on. There’s a `nodejs_latest` attribute, which is actually latest (18.2.0 right now), as well as `nodejs-12_x` or somesuch for past major versions (where required by other nixpkgs packages). Plain `nodejs` should be the LTS version.
> This completely ignores the fact that my various projects requires specific versions of node
Nix allows you to pin either nixpkgs or a particular package with commit-level granularity. I’m not sure this sort of video is the right place to introduce that.
I think it's more like decorating your home for the first time (which is a lot of work), but then in the proceeding years you keep tweaking a few bits to your liking as you learn more about "decoration".
The true benefits of the analogy break down a little, for instance one big advantage is persistence, stability and control - that some large corporation doesn't keep rudely breaking into your home every month and forcefully redecorate everything with the latest trend, or keep moving the furniture and light switches around while you are asleep, and inserting annoying store fronts into critical appliances like the fridge, or your toothpaste... The other benefit being that you can fairly effortlessly take your decorations with you to your next home!
I’ve been decorating my home for a decade.
So I've been decorating my $XDG_CONFIG_DIRS for a decade.
I guess the idea is to find the one tool/methodology that sticks with you.
For more reasons, see: https://www.chezmoi.io/why-use-chezmoi/
Disclaimer: I'm the author of chezmoi
> you can set up symlinks, with a script or manually.
So yeah… that’s exactly what dotfile managers do with standardised scripts.
Also, is writing your own scripts to symlink appropriate dot files across different environments not also a new dependency?
I mean we’re talking about Linux dotfiles. At worst, you might need a binary for arm, if amd64 isn’t enough. I’m not clear on your point about ABI incompatibility for simple binaries.
Like, i think its best to wait like, 10 years, and see how the whole thing worked out. Maybe we need another systemd or two until people realize that software is still a liability even if you aren't the one who is maintaining it.
I find the idea of having a file system full of links in it a bit odd.... but I only discovered the nest of them in my Windows 10 system a month or so ago with the windows DIR /AL command. I'll have to get over the cognitive dissonance and adjust to this new reality.
1 - https://www.freecodecamp.org/news/dotfiles-what-is-a-dot-fil...
Windows has the same concept of a PATH, which is where your OS looks for binaries. The difference is that Windows development is, most of the time, not CLI driven, especially if you use Visual Studio and other GUI tools.
Development in Windows is a completely different beast to Linux/Unix.
Why?
The big issue is that backup programs didn't know about them, and would back up things more than once.
I used to be a Mac user. Everything stored settings in resource forks and binary. When I moved to Windows, it was weird to have a registry for most things and some things used .ini files that were more useful. It was nice to have user-readable settings even if they were in obscure places and directories.
When I moved to Linux, dotfiles all made a whole lot more sense.
I've helped others learn how to Linux. Windows hides a lot of things in order to make the user experience idiot-friendly. I've had to un-teach them the crap that Windows teaches them.
I got nerd-sniped by this. I can't see any reason why this wouldn't work. I tested this myself by writing a script called show-error.sh:
#!/bin/bash
echo $?
$(exit 5)
. ./show-error.sh
5If you just run it it won't work.
So instead of running `boop` you would always have to `source boop` or `. boop`. A function or alias you could just run like normal.
(and `export ?` complains about ? being an invalid identifier in bash, in zsh `export "?"` apparently "works", but will reset it before you get a chance to print it in another process)
$(exit 5) ./show_error.sh
outputs 0.
Sourcing the file is the same as copying and pasting its content into the current shell. It is designed to allow this kind of things (accessing the caller execution context). But it is not what we usually call a script precisely because of this.
$(exit 5)
just spawn a subshell which exits with 5 which is visible by the parent script you just source your show-error.sh in?
Try to subshell the source too like
(. ./show-error.sh)
When I also ran into the stow bug with --dotfiles , I gave up on stow and wrote fling ( https://github.com/bbkane/fling ), which works quite similarly, but prints out what symlinks it plans to create and asks for confirmation before making them. Being written in Go, fling is also easy to install on Windows, which has come in real handy on occasion.
I don't have any dotfile management at all(Aside from my regular incremental backups), and the only time I provision a new machines is if i get a new laptop or reinstall.
I prefer to stay extremely hands off with VMs or servers. Ideally anything I do via SSH should be declarative and repeatable with Ansible.
But recently there seems to be more and more important tools that can't be installed from a package manager and usually require manually editing PATH for some reason(I have no idea why they can't just use ~/.local/bin, or why there's no standard path management tool).
It might be time to start putting things like that in a provisioning script. Or not, because they might not have a stable install process, and it's only a few minutes to do each one manually every few years.
And then nearly all of the comments are actually about the title, not about the article itself.
In hindsight, going with Nix would have been the most efficient way to reach most of that, apart from the Qubes-specific stuff. This will probably be the next step on my (ironic) odyssey of going all-in on configuration to finally stop worrying about it and reap the benefits of the beauty that is computing without its nasty warts.
In essence, I would love a proper integration between Nix and Qubes OS.
Edit: For anyone interested in an example of my current process, see https://github.com/lkubb/salt-tool-chromium-formula, https://github.com/lkubb/salt-tool-gpg-formula or https://github.com/lkubb/salt-tool-macos-formula.
This sounds like it'd be interesting to you: https://spectrum-os.org/
NixOS (since unfortunately Guix System is still a bit raw for me) complete tha game allowing to easy tangle the whole system config and generate a custom iso with Emacs and all the rest.
Zsh complete the game as shell, eshell honestly it's on my list but I still can't use it daily...
nix-build '<nixpkgs/nixos>' -A config.system.build.isoImage \
-I nixos-config=iso.nix
I prefer aliases when possible because they inherit autocomplete rules. Also it’s easy to “complect” things with custom scripts.
110 boop () {
111 local last="$?"
112 if [[ "$last" == '0' ]]; then
113 afplay /System/Library/Sounds/Glass.aiff
114 else
115 afplay /System/Library/Sounds/Submarine.aiff
116 fi
117 $(exit "$last")
118 }Also stuff to distinguish between different Unix flavors and hardware ("if it's this host which is a sun3 with FPU, add -m68881 to CFLAGS") -- not removed but commented out.
First solution a decade ago was to have a git repo and dotfiles were linked directly into the working dir. This was nuts. The dots were changed immediately, when checking out other branches. And slight differences between hosts were not easily manageable. A branch per host was not a solution.
I learned from those mistakes and wrote an installer script for that repo which copied/rsynced files from repo into ~
Still, slight changes between hosts were not easily manageable and I was thinking about a templating mechanism... but then ansible became a thing which I happily adopted.
Might be too much for most users, but it helps me managing many machines.
group/ (e.g., "devel" or "pim")
program/ (e.g., "vim" or "mutt")
CMakeLists.txt (lists files and packages needed; I use Fedora)
config/
local/
Each program's CMake code declares what needs symlinked, directories to be made, permission bits, etc. This is used to also write out a "validation" script to ensure symlinks are accurate and to notice untracked config files and such. I then just configure, turn the programs I plan on using on in the project and then "build" it. It also generates a `dnf install` argument list for me to install anything needed for these configurations.
The symlink setup is actually `$HOME/.path` (to avoid the repo from having hidden files; skippable if needed in the CMake code) -> `$builddir/group/program/path` -> `$srcdir/group/program/path`. This way, turning off a program nukes the build tree and then I can just go and look for broken symlinks in `$HOME` to clean up. Per-host bits overlay cleanly since I use split configs where possible (i.e., `include *.rc`).
One nice thing about using CMake is that I can also have `add_custom_command` at hand to generate files if needed (I use it to generate `xcompose` combinations).
For this point - I use an alias
alias chalias="vim ~/.bash_aliases && source ~/.bash_aliases"
Similarly, but using speech synthesis to tell which command is done: https://github.com/tv42/audibly
audibly rsync junk server:/data/
With entr:
find . | entr COMMAND
watchexec COMMAND
1. Some bash is allowed, which has been confusing me. I'd rather call 'bash -c "echo stuff > file"' myself. 2. Watchexec has its own interface for "filter which files to watch". Entr just relies on unix tools.
Now I just edit config files by hand and with zfs autosnapshot I can easily rollback if needed.
I'd love to try something like nix, but I rely on many aur packages that are bleeding edge for my workflow, I fear it would be hard to be up to date with nix, but I have not tried yet.
I will not pretend that there is not a learning curve though, Nix is a bit of a beast.
Ripgrep (coming from silversearcher a few years ago) is one of my favourite tools I use constantly.
I am a big fan of making higher order tools for yourself that reflect your own working style and preferences.