Ask HN: I'm declaring dotfile bankruptcy. How to start from scratch effectively? | Hacker News Reader

Ask HN: I'm declaring dotfile bankruptcy. How to start from scratch effectively?

20 pointsgjvc16 comments

This is the way I do it: https://drewdevault.com/2019/12/30/dotfiles.html

Doesn't require anything beyond Git, which is really nice.

One thing I started doing differently is using a .ksajrc file. I then simply add that to the last line of .bashrc. The reason is that all too often the .bashrc that comes "stock" with a major OS update/upgrade requires changes that get clobbered if you overwrite the default .bashrc all the time. This means I don't miss out on the OS changes, but I also have all my creature comforts.

For example, instead of specifying my full path in .ksajrc, I simply prepend my ~/bin if it is not already included in the pre-.ksajrc $PATH variable. Doing that means I don't suddenly lose new dist-added /opt directories in the path, as one example of many possible.

I also keep a list of what packages I need installed so I can just run that script after installation of the new OS. I do this mainly because I install a lot of stuff that doesn't normally get included in a stock setup. (examples include sbcl, gaze, htop, etc)

I haven't reflected that in my github dotfiles repository yet, but I should get on top of that.

Pretty much as the title states. I'm a long-time dsktop Linux/Debian only user using zsh/emacs as the base for stuff but obviously use the usual suspects as well.

Please suggest pro-tips / useful github repos / etc for setting up a really effective development / semi-scientific computing setup. Thank you. :-)

Keep on top of committing changes.

I'm terrible for coming back to my dotfile repo, finding I have some staged changes, some not, and some more untracked files, and then it's sometimes a struggle to work out if they're important changes that I'm using or not. Keep on top of it, and try to make your commit messages useful notes you yourself about why you have it that way, so you don't come to change it later and break one workflow for the sake of another.

At this point only you know why it didn't work out. We don't yet know what approach you took and what potential mistakes were made. So only you can answer what to do and not to do when starting over.

To help you get started, why are you declaring dotfile bankruptcy?

I recommend using yadm. It's basically just git under the hood, but it has some nice features that allow you to e.g. encrypt sensitive files, use different files depending on the OS/host, etc.

Hmm. I only care about what's in:

  .bashrc/bash_profile (1 alias, 1 path addition, git prompt)
  .gitconfig
  .exrc (:syntax off)
  .ssh/config & keys

Try to stick to defaults.

For reference, I spend a lot of time at the shell, and despite having previously tuned zsh dotfiles, I now just use default bash.

The only change I make is to source fzf's setup file.

The only way to win at dotfiles is not to play.

Fresh out of college all my peers were using fancy 3D mice with programmable buttons for mechanical modeling and one older engineer was just dragging his finger around on the laptop trackpad. It was painful to watch.

Over 15 years later I realize that old guy knew what he was doing. Learning to deal with the defaults lets you drop into any standard install and go, whether that's for 3D modeling or Linux software. Unless you just love constant fiddling with custom config then having it all rot away in the next upgrade or hardware change there are much more productive uses of time.

I don’t understand this mentality tbh. Why do you need the ability to drop into any standard install and go? Don’t you use one computer as your main machine?

I use: * personal laptop * work laptop * work desktop * work remote desktops * a bunch of servers

Those machines are on different versions of different distros, and thus have different software available, and when the same package name is available, it's occasionally different versions. Work provides a set of customisations, additionally.

Every customisation is yet another dimension in the cartesian product of config space, making installation, upgrades and debugging costlier.

I used to think customisation paid off, but I no longer do.

To clarify, I never consciously make this conclusion. Over the years I've just removed more config than added, until the point I have ~nothing.

All my dotfiles are in a git repo.

Whenever I'm doing a fresh install, I simply download all my most-used packages and rsync the dot files.

I'm planning on investing some time and setting up Ansible so I only have to install python and it does the rest for me.

HTH

Whenever something isn't installable through the package manager I check if it's feasible to install in `$HOME`. Most of the times it is, therefore rsync'ing home directories works surprisingly well. (Especially on work computers which I keep much more tidy than my non-work computers)

stow is pretty great http://brandon.invergo.net/news/2012-05-26-using-gnu-stow-to...

Reply on news.ycombinator.com