This is a good one, I hope I'll have mine for that long (started 2019).
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.
Notably, Nix with home-manager. Makes it pretty seamless for me to switch between Linux, Mac, and between employers. I love it even more since I got my home-manager config to be a Nix Flake - this way I have it 100% deterministic and can upgrade/downgrade the tool versions when I like without worrying too much whether I'll be able to go back if something breaks (having flake.lock versioned in git is kinda mandated and checked by Flakes).
I’ve been toying with the idea of switching from stow to home-manager, but I feel like there’s a lot of friction in the form of hard to answer questions.
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.
> 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 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.
Not sure if that would be good enough for you, but:
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.
If home-manager options for configuration files weren't always that backwards and hard to use. Compared to NixOS a lot is still lacking and you're better off just using it for package management IMO.
> I wish Guix had the momentum and size of Nixpkgs. I'd much prefer a Lisp than the language contraption of Nix
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/
I actually learned Scheme in CS212 at Cornell (which, incidentally, I bombed at the time, but it was due to the pacing, not being unable to handle the depth), so it was pretty much a no-op for me.
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".
Oh, I so wish to learn it, seems quite awesome. I literally made my own scripts to do exactly this management over the years. But the learning curve seems huge, not many good resources, etc... Honestly they all sound like those posts trying to explain monads
And frankly, I barely have motivation to study more concrete stuff...
Admittedly, it can be worse than sitting down and reading the manual front to back, but I did it the hard (or simple) way.
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).
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.
I'd just install nix + home-manager on your linux or Macos box. That's not too hard. Then take one of your dotfiles supported by home-manager e.g. kitty term, and port it to nix + home-manager
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
Currently I use Ansible to deploy my dotfiles, along with anything else needed to setup a workstation. I keep seeing people mention Nix. Would it give me anything that Ansible and Git can't give me?
I'd describe nix as "programmatic package management". Nix is a difficult tool to learn, but very powerful. A lot of nice UX use cases with Nix could perhaps be described as "like Docker, without the containers".
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).
There is no AnsibleOS, so you'll not have a reproducible OS, and as the base OS gets upgraded underneath, ansible scripts will break. Also, you have to put a ton of effort into making sure Ansible scripts are idempotent, and even then there are usually leaks. Nix (with flakes) is 100% reproducible and it's very difficult to do anything that isn't idempotent. What this all means is that there is more effort up front learning and setting it up, but a lot less effort and suffering in the long term.
Mostly it provides guarantees about your system. It guarantees that anything not in your config is not on your system (for the most part). It guarantees that everything builds successfully before it applies any changes. Most of the filesystem is immutable so it forces you to use the configuration.
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.
Yes, that’s exactly the kind of thing it’s great at.
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).
Part of the magic of asdf is that it reads a `.tool-versions` file from anywhere above your current directory and applies the correct version of each tool based on the listed value. (You can also configure a global default version for each tool in case your directory tree doesn't have a .tool-versions file with an entry for the tool you want to use.)
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>").
To add to what rgoulter said, you can use your default system configuration plus whatever the project says you need (and the project's shell will override any conflicts with your default).
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.
The biggest advantage that I can give is that everything is together in a unified language. To give a trivial, but extreme example, my workstation's colour scheme is controlled via my Nix setup. This includes terminal colours, GTK theme, Emacs syntax highlighting, Matplotlib colours, CSS overrides, window manager, and more. Yet I can change a single line in my Nix file and update all of these without worrying about the myriad configuration languages that are involved. A single change on a different line will update the default font for all these applications as well.
Interrupt Ansible mid way and then change some configs. That's a situation where you probably need to rerun from start and hope for the best. With nix you can just rerun and you would start mid way through your build process without any side effects. Also Ansible cannot easily do iterative changes without rerunning everything or knowing yourself what has changed. With nix the changes get computed and everything that is necessary will rebuild and restart.
I tried learning Guile some days ago because Guix seems so cool and I like the idea that the configuration is not done in a special purpose language.
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.
I wouldn't bother trying to learn Guile and would instead try to learn Lisp, or specifically Scheme, and then learn the few bits where Guile differs, because it's 99% Lisp/Scheme to me. (Scheme and Lisp have existed for decades and there should be absolutely plenty of resources to get up to speed in them.)
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.)
I know, I even mentioned it. Unfortunately and understandably Guix means my WiFi won't work and there will be less stuff supported OOTB. So I'll be on Nix for foreseeable future.
You can include community sources in order to use the standard, non-libre Linux kernel - though my Guix experience was a bit frustrating in part due to complications such as this one compared to what I'm currently experiencing with NixOS (thoroughly enjoying it!).
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.
You can install Nix package manager on any system, but the packages will be separate from system packages. You can try it and switch to full NixOS if you like it
Yes. I think it's a good way to get started with Nix.
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.
If you are talking about provisioning dot files and command line applications you want to have available on all you machines then take a look at 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?
Did you ever try to patch a software in debian or create your own package? Debian had no native and easy way to do that unless nix. If you have a standard cmake project you can be done in 10 minutes packaging it. Also applying patches is very easy with overlays while also keeping your software up to date and propogate the changes through the dependency chain.
The nix language almost always uses camel case while packages use kebab case.
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.
So, not having heard of Nix, I go to their home page and watch the video. It shows "nix-shell -p nodejs". Hmm, sounds like it's using the apt-get version of node which is usually out of date. It then shows making a shell.nix that enables nodejs and commits it to a repo and suggests sharing it. This completely ignores the fact that my various projects requires specific versions of node. Maybe the first example shouldn't be one that's pretty clearly wrong?
> sounds like it's using the apt-get version of node which is usually out of date
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.
would have been all that hard for the video to show node-12.x instead of nodejs? I would have clearly shown choosing a version instead of wrongly showing bad unreproducible practices that makes anyone paying attention question if the devs actually get what they're doing
> Saying that I’ve been maintaining my dotfiles for a decade is like saying that I’ve been decorating my home for a decade.
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!
For my dotfiles [1] I use https://www.chezmoi.io which I really like using and stuck (as opposed to my previous dotfiles attempts which didn’t stick).
Albeit I have only been using it for a few months as opposed to the author’s decade.
I guess the idea is to find the one tool/methodology that sticks with you.
I managed my dotfiles across many distros using a bare multi-branch Git repo. But eventually it became a chore to share snippets among them. Chezmoi is little thin utility wrapper over Git that handles this usecase beautifully. I switched to Chezmoi over the weekend and just shudder to the thought of how much time I could have saved had I found it earlier.
I find it odd that people use extra management software for their dotfiles. Most of the files are in `~/.config` anyways, so you can track this folder like a regular directory in git. And for the software that does insist on writing into `~` directly you can set up symlinks, with a script or manually.
Tracking `~/.config` as a regular directory in git only works if all your machines are near-identical. If you want to share dotfiles between, say, Linux and macOS, or between your home and work machines, then a dotfile manager makes it much much easier.
Unrelated, but thank you for chezmoi, it's a clever little utility very well designed. I use it to manage many distinct Arch-based systems and soon will be moving my Ubuntu servers to it. Congratulations!
You can ship a portable shell script with your config files. Portable shell script is supported out-of-the-box everywhere where you have dotfiles. No extra installing necessary. Contrast this to binaries, which are not portable and need to be re-generated for every possible architecture and ABI.
> which are not portable and need to be re-generated for every possible architecture and ABI.
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.
Its still work to be done. Thats something that is not even an /issue/ if you dont need much except the tools that already come with your distribution.
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.
As a long time Windows user... I had no idea, nor knowledge of dotfiles. I found this introduction[1] which seems to explain it fairly well, as far as I'm concerned.
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.
AFAIK, many Windows apps traditionally tend to use the registry for storing their configs. Which I believe is a similarly odd and foreign idea to most Linux users. On the other hand, before there was the Registry, there were .INI files on Windows too, so kinda similar like dotfiles.
> I find the idea of having a file system full of links in it a bit odd
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 find the idea of having a file system full of links in it a bit odd...
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.
Windows configuration is just wild. Every program does whatever wherever and the only sane way is to go through every program you install and change all your settings again.
Quite simply, they weren't a thing for decades in the Windows world. There were facilities to do so built into the code and NTFS, but you had to be an administrator to make symlinks or junctions.
The big issue is that backup programs didn't know about them, and would back up things more than once.
> It doesn’t work for everything. For example, I have a boop command (which I mentioned above) that needs access to the previous command’s exit status—as far as I know, that’s impossible with a script.
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:
Well, yeah, if you source the file (for which `.` is a shortcut) it runs in the current shell so the environment is intact.
If 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)
this only works because you are sourcing the file, and not just executing it:
$(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.
I used GNU Stow for a several years and always found it difficult to tell what symlinks were actually being created, even in verbose mode.
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.
It's always cool to see what the real lived experience of using a totally different workflow is like.
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.
I use yadm (https://yadm.io/), very happy with it. It's a thin wrapper above a git repo rooted in the user home that is configured to ignore untracked files. yadm adds a bunch of helpful convenience feature on top (like "alt files" that symlink either one or the other file depending system tags or the OS, and secrets [which I don't use])
Going to be that person but an article named "a decade of dotfiles" has nothing to do with dotfiles. The first sentence says "My first commit to my dotfiles repository was ten years ago" and then the entire rest of the article has nothing to do with "dotfiles" whatsoever.
And then nearly all of the comments are actually about the title, not about the article itself.
Last year, I started setting up a Qubes OS workstation. Doing all the intricate little steps manually seemed like such a waste of time that I started learning SaltStack, which is built into the Qubes management stack, to be able to automate and replicate the setup. This small itch exploded in such a way that I wrote a formula for almost every program on every system and server I use. For all other small programs, I just use one formula that syncs the appropriate dotfiles (I can also template them with Jinja).
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.
My personal sauce is Emacs with org-mode configs to be tangled, far more efficient than anything else tried before to manage dotfiles I care, ignoring those I do not care...
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
you can add anything else, for instance X config for interactive usage, perhaps with the same (nearly) EXWM used normally etc. Nix language is obscene but making iso is awesome easy, just a matter of download and build time.
I also started my dotfiles over ten years ago! First commit was in 2012. Use them every day. I thank the awesome folks at Jane Street for teaching me about both dotfiles and Mercurial! (Second job out of college.)
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.
dot files, configs and hosts are now managed in ansible.
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.
Yeah, I started with the direct symlink long ago too ("declarative" lines that were just shell commands sourced at the top). I now have a more…complex setup that uses CMake. The basic setup is:
group/ (e.g., "devel" or "pim")
program/ (e.g., "vim" or "mutt")
CMakeLists.txt (lists files and packages needed; I use Fedora)
config/
local/
repeat for each program, sorted into groups. Each program is added via a function that wraps `add_subdirectory` in an option asking if I want to enable that project. It also takes a list of dependencies (so, e.g., `mutt` is hidden if I turn off `msmtp` or `nvim` since it needs it in its configuration).
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).
The first part of his murder command can be accomplished by using pkill or killall (but maybe those aren't available on mac?). The second part is useful though.
I love `entr`, but I've recently moved a lot of my `entr` usage to `watchexec`. Entr requires a file list on stdin, watchexec watches the current folder.
With entr:
find . | entr COMMAND
with watchexec:
watchexec COMMAND
Watchexec also gracefully handles new files and file deletions.
The point is that entr can then focus only on specific files... watchexec now has to add special behaviors for .gitignores and whatnot. It's way more flexible and you can alias this so you don't have to remember anything or save it to ~/bin/my-watcher-thing.sh (both of these things I find people are not using enough).
I think entr handles some things more cleanly, though:
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.
I used to use stow to manage my dotfiles but this was a cumbersome step that didn't provide any real advantage.
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.
NixOS user here. My experience is that if you track unstable, you will have bleeding edge packages within a day or two from an upstream release. Likewise, due to how Nix works, you can pick and mix from stable, unstable, and your own custom expressions to your heart’s content. My personal preference is stable, with a very small subset of packages from unstable that I try to peg back to stable once there is a new stable release.
I will not pretend that there is not a learning curve though, Nix is a bit of a beast.
I have recently gone through mine when I finally changed to zsh after using Bash for the last 16 years (starting on Ubuntu and removed so many random commands I used. Now I barely need anything, as the tooling is really good and is going through a renaissance.
Ripgrep (coming from silversearcher a few years ago) is one of my favourite tools I use constantly.
I do love improving my dot files. My aliases and functions have become like a second language. I often make interesting one liners that make cumbersome multi command workflows interactive with fzf and related tooling I’ve built and collected.
I am a big fan of making higher order tools for yourself that reflect your own working style and preferences.
No one asked, but I feel like I've been down this road before. Heavily customizing a system with obscure lines plucked from strangers dotfiles. These days I use VS Code and Firefox for almost everything.
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.