Not just with development environments, but all computer configuration, I stick with the defaults as much as possible. Instead of changing the configuration of the computer, I change myself.

For example, let's say an app has a default keyboard shortcut I don't like. I won't change it. Instead, I'll just get used to it until it becomes muscle memory.

Now the default configurations are my preferred configurations. Of course, there are still a few things I change from the defaults. But since there are so few I can just configure them by hand, because how often am I setting up a new computer? Not very often. And there are so few config changes, it only takes a minute.

The only thing I have to actually sync is my vim config. It's a very small config, but it's still more than nothing. I just store it in a Git repository.

Yeah, my macOS set-up is simple enough it's not worth scripting or otherwise saving.

Use the GUI settings panel to make CAPS LOCK an extra ctrl. Takes maybe 10 seconds.

Use same to make dock auto-hide. 10 seconds if I'm slow about it.

Install Homebrew. Maybe 15 seconds hands-on and a couple minutes in the background.

Use Homebrew to install spectacle. Less than 5 seconds hands-on time, done less than a minute later.

Start Spectacle and use its preferences panel to set it to start on boot. Maybe 15 seconds.

Remove all the pinned programs on the dock. 60-90 seconds.

The last one's the only part I've considered scripting, but since I only do it once every couple years at most, it's not really worth it.

Once I'm past a Mac's initial "welcome to Mac" flow and on the actual desktop, I'm only about 5 minutes (not all of it actively doing things) from having a comfortable environment set up and being all ready to install project-specific tools, as needed.

If I ever switch back to Linux (or FreeBSD, which is more likely at this point) I might go back to versioning and backing up a bunch of config and dot files. I need them, there.

> Use same to make dock auto-hide

Cmd-Opt-D to toggle auto-hiding – I use this one to check if the dock is frozen :)

(Also a great option to rebind: it's a global hotkey so no other app should be using it)

Ha, I hit this by accident a couple times a year, then have to fix it in settings because I can never remember what the combo is.

Just as a sidenote, because I was using Spectacle as well. JFYI: As it is no longer maintained, I switched to Rectangle (https://github.com/rxhanson/Rectangle) and can highly recommend it.

Yeah, I'm just putting off switching because Spectacle still works, and has never broken or even behaved in a way that seemed weird or less than ideal, even across multiple monitors, with changing screen situations (hiding/un-hiding the dock), et c. It is one of the very few pieces of software I run that has given me precisely zero problems of any kind. Ain't broke, don't fix it, and all that.

> CAPS LOCK an extra ctrl

Another fine specimen, salute!

If it was ESC instead you'd get a +1. ;)

What if I told you that you can have both? For me it's ctrl when I hold it down and use it with another key and esc when I press it briefly. Can be set up on a Mac with Karabiner Elements.

If you told me that, I'd give you the +1. But Karabiner Elements doesn't work on my Arch box.

I have a udev rule that does the ESC mapping, but will have to try harder to see if I can make it do that on Linux.

Mine just does nothing.

Why not Command instead of Ctrl? Isn't that something that you use way more often?

Because I go used to use Emacs binding while on the terminal and VIM bindings for everything else. Ctrl + [ instead of ESC to change modes for me :D

I'm not that commenter but ctrl is my least favourite regularly used key to hit. It's not comfortable to reach with either my pinky or thumb. Command is basically where my thumb rests naturally, it's in prime position.

Yep, cmd is great where it is. If I compare cmd-shortcuts with identical ctrl-shortcuts, with normal key mapping, the ctrl ones strain my hand and pull my fingers away from the home row. The same cmd-based shortcuts do neither of those things. It's one thing Apple got very right, that everyone else is getting wrong.

Yes, this is one of the best decision I made quite a while back. I'm usually asked for ideas and advices on how to setup computers, both technical and non-technical friends and families. I have always suggested putting a little more effort in learning the defaults and getting used to it.

I have even written a short essay, as I found myself repeating the same suggestions many a times. https://notes.oinam.com/digital/apple/

This is where I’ve come to over the years as well. Generally defaults are best unless it’s something you really care about and that makes a big difference to your workflow.

Most configuration stuff doesn’t fit that category - or if it does, it’s best to first work on just caring about it less if possible.

Additional benefit is that defaults are often such that they work well together, often in ways that you might not have foreseen beforehand and thus never would have set up yourself.

> I stick with the defaults as much as possible. Instead of changing the configuration of the computer, I change myself.

This is the worst advice you could give. There are plenty of shitty defaults and default tastes vary from app to app and there's a reason things are customizable.

Customize to your taste throughout your tools and don't let a new tool eat your time.

You can take it even further: stick to the defaults and mainly use command line tools.

Almost every linux box has bash, vim, and the GNU command line tools. If you can become proficient with default config cli tools, you can become proficient on almost any linux box.

I think there's a healthy middle ground here. Endless tweaking of settings tends to be a waste of time, but if you spend hours a day on a computer, you might as well make it comfortable. Some people use no $EDITOR plugins and wear it like a badge of honor, this is pretty silly to me. The few minutes it takes to install and learn about a plugin might save you hundreds on hours in the future.

I guess my personal strategy is to run with the defaults until you find the pain points, and install/configure something to address them. And put them in git repo if possible.

> Some people use no $EDITOR plugins and wear it like a badge of honor, this is pretty silly to me.

I don't use any plugins for PyCharm or IntelliJ, but they're pretty full-featured right out of the box. I certainly don't do it as a badge of honor, that indeed is pretty silly.

But vim is useless without any plugins. Even VSCode is only marginally better than Notepad++ unless you give it the plugins necessary to turn it into an actual IDE and not just a code editor.

> vim is useless without any plugins

It’s not? I mean vim defaults are great, it supports a lot of formats out of the box (indentation, syntax highlighting), it’s ideal for quick edits. Surely if you need an IDE-like functional then it’s not enough (probably) but it is very far from being useless without plugins.

I'm doing the same. In some companies you can't just get ssh to outside world, or download some stuff from github... So I stick to defaults and I try to do development on single machine.

I have a friend who does this. But his reasoning goes one step further. He's usually mentoring people on his team, so he finds it very valuable to be able to not only function quickly on someone else's setup, which is usually the standard, but to give them hints that'll work directly for people unfamiliar with the tools.

This is a great answer if, like you said, you don't set up computers very often. I use mostly defaults in part because I set up computers a couple times a month. Often just for a day does that physical or virtual device live, consuming my configs, but having to manually do it every time would be a pain.

If i have to deal with ancient osx gnu gplv2 utilities, i think I'd go bananas. You have to modify the default settings at some point or your productivity will surely wane in comparison to others. I see your point with some defaults but the purest approach doesn't seem practical either.

Agreed, same thing with basic stuff like color schemes. I just pick one that's auto installed by default with an IDE and stick with it. I'm tired of futzing and installing stuff to get things juuuuust right. Most IDEs come with great defaults.

Yes, this. Custom configurations are a maintenance burden when you change systems. Living with defaults saves time in the long run, usually. Only when I spot an exception to that rule will I install something custom.

Basically I use git for .local/dotfiles/ which are then symlinked to the relevant files like .zshrc or .emacs.d/init.el. Then I just keep that repo up to date with git pulls. Works across 2 macbooks, a Fedora workstation, and a Fedora headless server.

Couple of bits from a guide I wrote recently: https://gist.github.com/aclarknexient/0ffcb98aa262c585c49d4b...

    # store stuff here that you don't want in github
    [[ -f $HOME/.zshenv-local ]] && source $HOME/.zshenv-local

    # depends on 'brew install grep'
    [[ $OSTYPE =~ ^darwin.* ]] && alias grep='ggrep --colour=auto --exclude-dir={.bzr,CVS,.git,.hg,.svn,.idea,.tox}'

That OSTYPE is great for all those little bits that are unique to each operating system. The zshenv-local is in .gitignore, so you can keep tokens, api keys, etc etc in there. OSTYPE could even be used to import specific files like .zshenv-darwin or .zshenv-linux-gnu

If you're ssh'ing between your hosts, you can use something like this:

    if [[ -n $SSH_CONNECTION ]]; then
      ZSH_THEME="afowler"
    else
      ZSH_THEME="powerlevel10k/powerlevel10k"
    fi

It's not fancy and doesn't use cool tools, but my setup works for me just fine.

I do something similar, but even simpler. I have my entire home dir as a git repo, but my .gitignore contains a single "*". I git add files I want with a -f.

I'm gonna go though your guide later though-- I like quite a bit of what I've skimmed so far. Thanks for posting that.

Any feedback on the guide will be gratefully received. I'm trying to write better docs to give a little back to the open source community - it's not much but it's what I can manage :)

EDIT: and that "*" for gitignore is intriguing, I'll have to take a better look at that whitelist vs blacklist setup, thank you!

I've been doing "home dir is a repo" for a while now too and I'm always surprised when people think it's weird/dangerous. I wrote a few guides with tricks on how to do it on my blog that all started with "This is probably a horrible idea but here's how to do it anyway!"

I keep a .dotfiles git-repo similarly. The configs/custom scripts/etc are organized into separate folders by what they do (shell config/work tools/...) and I use GNU Stow to symlink them into my home directory. Makes setting up super easy:

    git clone <repo> .dotfiles && cd .dotfiles
    stow --target=$HOME --dir=packages shell-config
    stow --target=$HOME --dir=packages work-stuff

I've found this to be much more manageable than tools like yadm since I can pick-and-choose sets of configs/scripts based on the machine I'm using them on.

This is what I've done for a long time. You get the benefits of keeping things synced and having a full history.

I did the same plus just a little bit of Ansible makes deployment a little nicer.

I looked into Ansible after reading your comment - I've only ever used it and Puppet for larger-scale stuff so hadn't even thought of using it as a localhost-only playbook. This looks like it could manage my symlinks for me very nicely :) Thank you!

I use chezmoi (http://chezmoi.io) after years of rolling my own. It’s not as straightforward as some home managers, but the extra power it provides is _amazing_ and worth the learning curve.

I pull some information from the local keychain and others from 1Password (with `op`; I will be moving most of the rest to 1Password from the keychain). It can run additional scripts _after_ each update (I use it to update my fish plug-in installations if I change `fish_plugins`).

It has integrations with many different password managers so that it is possible truly keep your secrets out of your dotfile configuration and _still_ vary the configuration based on those secrets.

Chezmoi looks to be exactly what I want, HUGE thank you for sharing that!

Another happy chezmoi user here. The templates are hugely convenient.

I use Nix to manage: - a desktop running NixOS (primary work machine) - a Macbook (secondary/travel work machine) - a Linux VM on WSL - two servers (a raspberrypi in my closet and a Hetzner vps)

I keep my config on Github (latest branch https://github.com/alexghr/nix/tree/host/vader). I'm still new to this so a lot of my config is duplicated across different hosts but I want to refactor it to eliminate duplication.

If you haven't yet, I'd recommend giving Nix/NixOS a try. There's a bit of a learning curve but it's very powerful.

It's crazy how good nixos+git gets when you've iterated for a while. I'm using the same setup on my work laptop, my home PC, and my router.

Coming up on my 1 year anniversary with NixOS and couldn't be happier, even though it has taken quite some time to adjust to (and I still barely know the language).

Having one place for all configurations is such a breath of fresh air, and having my work & home PC being identical (even Gnome is declaraticely configured!) is so nice.

Before NixOS, I resented using my private PC because it was never up to date with what I had configured on my work PC, but now that's just a "git pull && nixos-revuild switch --flake ." away - regardless of what has changed.

One of the things I love the most about it is that we can use CI to update flake inputs and build configs on a cadence, which is almost like having dependabot for machine configuration.

I've been a sysadmin since I was 12, FreeBSD, Debian, Arch, Windows (sigh). I've been an SRE managing 1k+ mixed machines. I've done nomad, k8s, docker-compose, podman, ansible, powershell admin, firecracker, gitops...

I will never, ever, use anything that doesn't behave like NixOS again. It is a sea-change.

Is the language weird? Oh yes. Is the documentation scattered? Quite. It's all worth it.

If the love of your live spoke a different native language, you'd learn it.

Stick to defaults? Hell no. Own your computing life.

Nix learning curve wouldn't be bad if the documentation wasn't so bad. I have had to put together my configuration based on couple of blogposts from randoms.

Documentation (and cli assuming you use nix-command) today is bounds better than in the past. A huge shoutout to Jon Ringer who always seems to pop up making a positive impact whenever I google something nix-related.

I'd say Nix is 95% wonderful, 5% very painful.

If you're trying to do something with Nix and it works, neat.

If you're trying to do something and can't get it to work, you'll have a very difficult time. (It demands a depth of understanding, and Nix is a bit weird).

Hopefully in future, "documentation", "blogposts from randoms", etc. help alleviate that pain as more people use it.

Yup. I run one laptop and four servers on Nix. It is the only sane option I have come across so far(I used bare git repos with Arch before).

Just use vscode and remotes. Zero hassle and zero friction - just fire up and start coding. It is seamless.

I use it on windows, Debian, macos and even Chromebooks and don't have to worry about any kind of syncing. It just works

It has a built in settings sync thing, but as a general rule I strongly strongly avoid the use custom settings (in anything) to avoid the issue you are facing. There is in my experience a huge productivity gain to be had by just being pragmatic and using (and knowing) defaults in everything you use frequently, and not being a useless prima dona if your custom key bindings are missing from every single machine you need to use each day/week/month/year. We jump around servers and computers frequently, so I find it is easiest and most productive to just go with the flow and use the defaults so I can be working immediately as soon as I SSH into a new host or am given a new laptop to use for a 3 week long contract or whatever.

Yeah, mixed environments are really tough. Though (most) of my machines are Linux, they often have _some_ stuff that should be the same and _some_ stuff that should not. My solution has been to use the fine-grained GNU Stow approach, which allows me to apply only the bits I need for a particular machine.

The files you're managing don't even need to be text, though, of course, it makes versioning, etc. a lot easier.

I also check the host name in some of the scripts to modify behavior depending on the machine.

I did a write-up about my whole setup (emphasis on GNU Stow + Git) here:

https://ratfactor.com/setup2

I also use GNU Stow + Git and has worked well for me. For files I want to sync that I don't need versioning for and it is important that I have them available even in cases where I may have forgotten to commit my changes on some individual machine, I use Syncthing[1], which is really great for the more Dropbox-y kind of cross-machine sync that I also have a need for.

[1]: https://syncthing.net/

I used to use a git repo of dotfiles which used a script to symlink into $HOME: https://github.com/RyanGibb/dotfiles

But there were a few problems with it: - installed packages needed to be managed separately (the mechanisms for which varied by platform) - managing differing configs for different machines (e.g. headless servers, hardware quirks) was done by managing different branches of this repo and rebasing, which was a pain - it was generally brittle and hard to change

I've started to use https://nixos.org/ and it's been like night and day: https://github.com/RyanGibb/nixos/

My config is version controlled, reproducible, manages packages, and is very composable.

Using the nix package manager and https://github.com/nix-community/home-manager this should work on other Linux distributions, MacOS, and even Windows Subsystem for Linux. Although I haven't tried this for myself yet.

Like a few others here, I use git with a .dotfiles directory, which uses an install script that creates symblinks (among other things). It's grown a lot of over the years (maybe decade now?) and I've been meaning to look into using something like GNU Stow, but haven't got around to it.

The install script and configuration works on macOS and Linux, but sometimes requires updating when running on a new machine (like recently when provisioning a new M1 Max MacBook Pro). At one point I had it installing default packages (particularly a lot of stuff from Homebrew), but ultimately moved away from that because I realized it just kept too much old unused cruft hanging around.

I also have my configuration files setup so that it can be used for work or personal machine. For example, my .gitconfig includes another config when in the ~/work directory:

    [includeIf "gitdir:~/work/"]
      # work-specific settings (override email, etc.)
      path = ~/work/.gitconfig.inc

https://github.com/sethdeckard/dotfiles

I'd never heard of the Include behaviour for gitconfig files. That's really nice, thank you for sharing that!

You say you also have a windows machine, but if you were to use only linux then I would seriously consider using nixos. I have three desktops and one macbook pro (2015) all of which run off of the same configuration.nix and the home-manager nix package. Using this on a new machine I'm up and running in about an hour.

Configuration changes are committed and pushed, and whenever changing machines a `git pull && nixos-rebuild switch` would bring the current one up to date.

Things that are automated: installed packages, systemd services, mounts, users and user groups, networking (including VPNs, /etc/hosts), users' environments, users' home folder content (dot files, random useful bash scripts put in PATH, etc), emacs packages.

A few manual steps still remain (adding keys, cloning repos, some desktop environment tweaks) - undone mostly out of laziness to figure them out.

Of course, one has to learn nixos to use this, and that, quite frankly, has been quite pain :). Though, once you get a hang of it, it relieves a huge painpoint: you are no longer mentally attached to any single physical computer.

Would recommend.

I use primarily linux but these are the tools i use:

Ansible - I can bootstrap a new linux install with all of my configs in ~10min, this has saved me countless hours of time. My linux installs are heavily modified (tiling window manager, lots of custom hotkeys, custom ricing)

Git - I sync all of my dotfiles to git and and can keep them in sync between PCs.

Syncthing - My dev folder and a few other important folders are kept in sync between all of my PCs using syncthing. I can save a file on my desktop and turn to my laptop and the file will almost instantly be there.

I record everything that I do, for initial setup or otherwise, in a large text file and/or cloud document holding blocks of shell instructions like:

  # set up stuff
  (
    VAR=<stuff>
    curl <stuff>
    <do-something-with> "$VAR"
    brew install <stuff> # or apt-get install <stuff>
    # ...
  )

I write them so I can paste them into the shell at any time and keep my environment updated declaratively, without having to think. This way I never store any local state, not even command aliases. Otherwise I start getting attached to my setup, which leads to anxiety.

It's good practice to check out a project repo periodically and see what it takes to get running inside a fresh OS or user. It's handy to do while onboarding new developers too. Sometimes I'll even put these setup instructions at the top of the project repo's readme itself, so it doesn't have a dependency on anything external.

I have a remote Linux server for my dev environment. This way it's one dev environment that I can access from any device.

I am mostly using NeoVim now but in the past VSCode with the remote extension worked great too. It's totally platform agnostic (I can even work straight from my iPad). It's also a single instance that I have to manage instead of syncing or making changes in more than one place.

With this setup I can still use docker containers or VM's to make it easy to spin up different types of dev environments but it's all on one computer so super easy to manage. Since I don't have to worry about managing multiple platforms I create simple bash scripts to install everything and create the necessary configs so if I need to wipe everything and start over it's no big deal.

Dotfiles in my home directory go in a repo that gets cloned and "installed" (I use a shell script that I wrote to make all the symlinks, but GNU Stow is probably better better). System level configuration and package installation is handled by ansible, with a certain amount of stuff controlled by conditional statements based on the distro and host name of the machine to allow arbitrarily local overrides.

All that said, if I was starting today I would strongly consider just putting everything into nix with home manager and carry that config around in a git repo that installed my packages and their configuration and encapsulated my entire environment.

Stow requires LaTex support to build from source. I tweaked it[0] to make sure it builds without it.

[0] https://github.com/jvsg/stow-simple

I use Nix: https://bou.ke/blog/nix/

I'm able to have the same shell with all my Vim plugins across macOS and Linux with changes committed to git. It's been so good, setting up all my command-line tooling now takes about 15 minutes from scratch.

Nice writeup, just wanted to comment in case you hadn't thought of it, that you can achieve a nix-shebang with flakes by adding a wrapper script. e.g. foo_wrapper.sh:

    #!/usr/bin/env bash

    readonly gitsha="..."
    nix shell nixpkgs/${gitsha}#bash nixpkgs/${gitsha}#{foo-pkg} nixpkgs/${gitsha}#{bar-pkg} -c bash foo.sh $@

I travel light.

I have multiple machines on multiple operating systems and dev on all of them. I sync nothing across them, instead I adjust to as many of the defaults of Sublime Text as possible and the only consistency is in how I organise the working directory on disk.

This isn't what you asked, but I'm not sure one has to sync them all.

I just have a dotfiles repository and in it an installation script, one for Mac and one for Linux.

Might be bad of me, but I definitely share it between professional and personal - it's just dotfiles after all.

The biggest difficulty is making sure that the installation script actually matches what you want to happen because it is difficult to test on already finished system. so every so often I spin up a Digitalocean droplet and try to configure my system from scratch using the dotfiles.

There’s a neat tool - stow - which handles dotfiles style installs with soft links quite handily. Absolutely worth investigating.

yes, stow + a git repo is really useful when replicating a conf on many environments. Its a nice alternative to ansible which is sometimes overkill for some easy copy-and-paste

That's one reason I have close to zero interest in Vim(Or window managers, or anything of the sort).

I can rebuild my configuration(Aside from some fussy embedded toolchains) in half an hour or so. VS code, a few different linters, swissknife, stack tabs, timestamper, indenticator, pylance.... done.

Even if there's a Windows machine I'm fine. Haven't done anything on mac in a decade but I assume I'd be fine there too.

Also, if something takes more than 5 minutes to learn or set up I will usually at least look for other options, on the assumption that if it takes time to set up, it will probably take time to maintain and modify, because it was probably made by people who enjoy deep customization.

There's lots of things worth learning and setting up, but also lots that... I'm not so sure about.

> I can rebuild my configuration(Aside from some fussy embedded toolchains) in half an hour or so. VS code, a few different linters, swissknife, stack tabs, timestamper, indenticator, pylance.... done.

I can clone my dotfiles repo[0], run a single command that installs all my dependencies[1], another that links my config and I'm done. That gives me a fully-configured neovim with all my plugins (thanks vim-plug) within 2 minutes.

[0] https://github.com/peteryates/dotfiles/

[1] https://github.com/peteryates/dotfiles/blob/master/Makefile#...

Pretty impressive, but also looks like a big initial time investment.

Also, will it all work on Windows? Looks like I'd need a whole new setup to get things running on a windows machine if for some reason that's what was available at work.

Do things break between Linux releases? The number of extra steps you need to get something like language server protocol working makes it seem like at least some maintenance could be needed.

Yeah, my config has been evolving though my career over the last twenty years or so.

I'm totally not suggesting you jump ship or change the way you're working, but automating the copying of config and placing it under some kind of version control is the real winner.

Things occasionally break, but the only part of my config where that's likely are my neovim plugins - things keep moving and occasionally a bit changes and I need to adapt.

I can happily use a minimal neovim setup so if I need to disable LSPs for a bit it's not the end of the world. It's been mostly fine though.

It would probably work on Windows but I don't think Windows has symlinks so you might need to copy files rather than stow them.

Sounds like a good opportunity for building a tool that syncs dotfiles in a smart way across different environments. Bonus points for managing what gets synced at a granular level, i.e. including/excluding certain files/configurations.

I've been using Ansible for years now to do this.

Right now all my computers run fedora so there's not much difference between them but for some time I used Ansible on macOS too. It worked but was a pain to make my roles compatible for both linux and macOS.

In my experience Ansible is good when dealing with text files or if there's already a module for what you're trying to do (for example managing postgresql users). If what you're trying to do is complex enough that you need to write a custom module or plugin, it is a pain in the ass: we had to do that at work and it was terrible.

Ansible works on Windows but I have no experience with it.

I’ve used a git repo with ansible on ubuntu, win10, WSL2 and macos. Works close-enough-ish and I mainly use it to copy dotfiles into place. I’ve used symlinks in the past to avoid reliance on a tool, but symlinks are no good on windows.

Check out Unison [0]. I use it to sync between macOS and Linux box.

[0] https://www.cis.upenn.edu/~bcpierce/unison/

I symlink a few files in place via Dropbox, but have most of my local configs in a dot files repo: https://github.com/geerlingguy/dotfiles

Then for more systemwide configuration, I have an Ansible playbook I run every now and then (configures apps, dock item order, etc): https://github.com/geerlingguy/mac-dev-playbook

A nice way to do that with git:

https://news.opensuse.org/2020/03/27/Manage-dotfiles-with-Gi...

> then tediously spend a day or more re-configuring newly installed computers with the software and configurations I know I'm using

Config is just dotfiles pull and software is either a bash script, dpkg --set-selections or ansible (a bit overkill).

Another option is dropbox and lots of symlinks.

I use syncthing to sync my dev folders between windows, linux and mac. The mac is set up to backup to time machine and backblaze. I’ve standardized on vscode as much as possible, use settings sync to automatically sync its config between machines, and put per-project config in the project’s folders.

If I had to start over now I would consider something like github codespaces, but requiring constant internet connectivity would be enough of a downside I would land on syncthing + vscode again.

It's probably awful but I sorta really just rely on system backups for my configs. Download and restore anything I'm missing from the latest backup when I reinstall the system.

I do keep my ~/scripts/ directory in a git repo (also this directory is in my $PATH) because they're all very hack and slash "I need to do a thing repeatedly, quickly" scripts. Sometimes I might want to go back a step or two when I really break everything. This repo auto pulls/commitpushes every now and then as this one is more useful to be up to date on all machines than to have useful commit messages

As for live syncing devices I do have unison running on my laptop frequently to sync (when its on) a few directories I might need offline. Mostly everything I need as a dev is in git repos though, so I use manual git push/pulls to sync everything else

I did previously use mackup (https://github.com/lra/mackup) to sync configs but if I'm honest I forgot I had it set up the last time I reinstalled so it got removed from the process unintentionally

I have a desktop and a laptop, both running the same OS (PopOS).

Note: I don't sync anything to my work computer. I will never trust adding a conduit for my personal activity or files to my work computer.

I use SyncThing which syncs critical parts of my home directory (.config, project files, misc dot files, git configs for multiple profiles). My SyncThing setup is local network only. I work mostly on my desktop and if I'm about to leave I spin my laptop up real quick, it syncs everything in a few seconds, and I'm out the door.

In terms of projects, this also syncs my project settings from VSCode and IntelliJ. I was a little worried about my apps that support hot code reloading if I left the daemon running by mistake, but honestly I've discovered no local state issues.

My shell configuration is also synced, which is really nice. Once homed (in systemd) becomes more of a thing I'll probably see how I can incorporate that workflow.

I really like homeshick, it's very simple and stays out of my way, but also makes it trivial to keep track of aliases and config that I like to have around.

I don't do a ton of configuration these days, I mostly just set up VSCode, fzf and my .vimrc and feel pretty happy. But whenever I do want to make a change, I know it's worth the effort, since it can be easily synced to any of my machines.

I do have a setup where my bashrc and zshrc just source a common aliases / functions file, which makes most of my config work across both shells. If I'm doing something tricky then I'll usually take the time to implement it for both shells.

I also have a file called `.system-specific-profile` which is sourced by my common profile, but is not synced - this is where I dump one-off stuff that doesn't need to be synced.

All in all it's fairly minimal but flexible enough for basically anything I've ever needed to do.

- Dotfile repo hoested on GitHub

- `git clone` said repository to my machines

- `ln` from repository folder to `~/` (can be done in an install script or piecemeal)

- `git pull` to update

I also purposely try and use as many default configurations as possible. I use a lot of remote machines that do not have my configs on them, so I do not want to become too reliant on custom setups.

Ansible. I maintain 4 workstations (3 Linux, 1 Windows) from the same config. It's a bit overkill but it has the flexibility to deal with the hardware and OS differences.

Linux is essentially automatic. Install OS using custom arch-iso build. Download Ansible config repo. Run playbook.

Windows is a bit more rough. Ansible runs in WSL connecting to the host via ssh.

For work I just fork my personal config, add changes needed for work environment in a private repo. I can pull upstream changes and rebase easily.

Main downside is it's a bit verbose, and I still need manual steps to converge certain types of changes (like deleting/moving configs) because I don't want to write even more code to do that.

Having all the additional steps in a role and not just config files is extremely useful when revisiting a configuration years later.

For development, I usually just use Git to synchronize changes. Syncthing is useful sometimes.

I use a combination of a .dotfiles folder and syncthing.

my .dotfiles folder has a script in it that symlinks the dotfiles and folders out to the right places, then installs any tools with asdf and the .tool-versions I save. usually gets any Linux setup up and running in a few seconds.

I then have a workspace folder that stores all my code and projects. I syncthing that between my computer and a 3rd server computer as a backup that has weekly backups running. the 3 way sync makes it easy to not lose anything, or if one machine goes down when I need my most recent files.

Since I use WSL on Windows, the same stuff works mostly the same. The script I have is tailored to my preferred distros. I have currently a fedora one, but I also have an Ubuntu and a Arch one for when I used those or need to get my stuff setup on them. I try to keep all of them updated. asdf really helps with tools.

Personally I'm in Emacs for almost anything so different environments are just different set of org-mode files with things to tangle, different org attach and roam directories etc, common staff sync-ed with unison.

That's work VERY well, but might not fit your needs depending on what you need to use for work...

EDIT: Chezmoi will do all this. https://www.chezmoi.io/quick-start/

Somewhat related question:

Can GNU stow do this, and if not, can anyone recommend a package/app to do it? I want to have a config file with a list of source files and where I want them symlinked. Then have a tool that maintains those links. Example:

    # SOURCE                               # DESTINATION
    zsh/zshenv                             ~/.zshenv
    zsh/zshrc                              ~/.zshrc
    gitconfig                              ~/.gitconfig

From my reading of GNU stow, it operates on full directories and relies on having the files already named correctly.

I have a 'personal' directory in my dotfiles repo, and within it are my .zshrc and other files. Then it's just:

    stow -v --defer='.+' personal

and they're all put in place. The defer argument simply prevents any overwriting.

    ~/dotfiles % ls -a personal/
    .bash_aliases  .bashrc        .gitconfig
    [...]

EDIT: Yeah, it won't rename files when stowing them. It's never been an issue for me, FWIW.

I just have a bare metal server I rent from OVH and run everything there and just remote into it with VS codes pretty great remote feature. Works great unless I'm traveling. If I'm going to be on the road I'll just setup what I need locally just in case.

I keep my Dev environments in dockerfiles. It's a bit annoying as docker isn't designed for this so I had to figure out how to punch holes in its security for things like access to USB, running graphical apps, etc. I tried to watch to podman but ironically didn't get that to work because it is too secure.

The advantage of all this is that they are separate so you don't need to worry about some embedded IDE or python crap barfing all over your system. I check all the dockerfiles and config files that they install into git. I've been watching nix but it's seems like it's a bit of a Marmite project so I might wait to see if something better turns up.

home-manager and nix: https://github.com/legendofmiracles/dotnix

This allows me to abstract logic easily, have it all modular and have everything be nix.

I have a dotfiles repo on GitHub, with Homebrew bundle to install almost everything and some additional shell script. For real dotfiles, I just migrated to rcm to manage that easier.

There are lots of dotfiles repos on GitHub. And you learn that quickly.

You could use a dotfiles manager like https://yadm.io/

It's more or less a wrapper of git, but it comes with a bunch of features that allow you to do the things you describe.

This is what I have set up. Admittedly I keep forgetting to use it.

It slows my shell start-up a few hundred milliseconds, but I keep a nag in my bashrc to list changed files.

    yadm_diff=$(yadm --no-pager diff --name-only --exit-code)
    if [ $? -ne 0 ]; then
        echo -e "\e[1m\e[91m[yadm] \e[0m\e[92mThese config files have been modified:\e[39m"
        echo "$yadm_diff"
    fi

I just have my dotfiles in git, along with a script that clones the repo, moves the files into position, installs packages and does a few other little things. I had thought about just making my whole ~/ a git repo but I feel like that would inevitably lead to me putting something into git that I didn't want to be in there like a private key or something (I'm not that bright, it's bound to happen).

Another option I considered was Ansible or similar, but my script was very simple to write and has no dependencies other than bash and git which I do kind of like from a simplicity perspective.

I use a tool called rcm[0], which is essentially a set of shell scripts for managing symlinks from $HOME into $HOME/.dotfiles. $HOME/.dotfiles can then be a git repo.

Some notes:

1. rcm lets you decide make host-specific or host-agnostic dotfiles. For example, I can declare that I want a different `.ssh/config` file for each host, and rcm will figure out which `.ssh/config` to symlink based on the current machine's hostname.

2. The installation process is very simple. It's just shell scripts, so you don't have to worry about a C/C++ compiler or having any pre-reqs installed. Operating system packages exist for the common platforms, and there's also a convenient way to "build" from source using configure && make && make install. The from source option is particularly convenient if you need to change the installation prefix to a user-writable location on a multi-user machine.

3. I use SSH Agent Forwarding[1] to avoid needing to install private keys (either new keys or copies of existing keys) on all the hosts I manage. This lets me git push and pull to my dotfiles repo on all hosts.

4. Taking it a step further, some shell config I have is host-specific (e.g., certain PATH modifications I only want to apply on certain hosts). Rather than use the host-specific dotfile feature of rcm for the whole .bashrc, I factor my shell config files into multiple files, that I then source. One of these files is called `$HOME/.util/host.sh`, which is host specific. Again, rcm creates a symlink from this to the correct host-specific file automatically by hostname.

If you're curious to learn more about any of this, my dotfiles are public.[2]

[0] https://github.com/thoughtbot/rcm

[1] https://docs.github.com/en/developers/overview/using-ssh-age...

[2] https://github.com/jez/dotfiles

My use case is simpler than yours, as I only have one personal and one work Mac, so I can get away with a manually managed dotfiles repo[0]. My work GitHub account is a collaborator on the repo so I can edit config on both machines. The actual differences in configuration are intentionally minimal and kept in separate, unversioned, optional files. This repo is the only thing shared between my personal and work machines

[0]: https://github.com/nkantar/dotfiles

I've got a fairly unique setup, and work on a Windows machine that runs my Ubuntu VM with KDE(where I do all development).

I take monthly snapshots of the VM, and carry it around on all my computers. It drifts from time to time, and I just end up just overwriting it with an older version when I fumble with some settings. Once every 3-4 years I do a clean reinstall of the VM.

I tweak a bit frequently used software like PyCharm, but aim to keep everything in stock and updated constantly.

I've not had any issues or regrets in the last 5 years and I'll carry this on indefinitely.

Ha I do exactly this. Windows with Linux in a VM is great.

This might be the worst answer but....

I dont! I love setting up each new machine fresh, because I feel like during the development cycle I incur a lot of software/CLI tooling debt that I don't need anymore.

You still need to have the reference point saved somewhere right? I am not sure if starting from scratch every time is the right way.

Homeshick for dotfiles: https://github.com/andsens/homeshick

Docker for Obsidian and Alfred syncing - the three target limit on the free tier is just barely enough for 2 of my own computers and my work laptop.

I've also got a Brewfile for installing the basic tooling on macOS

I also have a "how to set up a new computer/server" document on Notion that I use so I don't forget any steps.

I'll echo the other comments recommending to stick with "defaults". However, I do like having the ability to sync my installed packages and apps across machines, so I wrote a little script to update/reinstall packages on macOS using brew: https://github.com/maxpetretta/dotfiles

Between my dotfiles and cloud storage, you could throw my laptop in a lake and I could configure a brand new machine in an hour or two.

I switch between MacOS, Window 10, and Linux Mint.

In each case I stick with the defaults except for minor tweaks, where I keep a Markdown bullet list - things like switching on hidden files and file extension visibility, or installing obscure things like Rectangle and Silicon Info on the Mac, or where to get my favourite fonts from (eg iA Writer Duospace). None of that is time-consuming enough to script or otherwise automate.

No need to sync anything, but to be fair I habitually reinstall the OS at least once a quarter so I'm pretty practiced at it.

With the exception of Excel, I don't use Microsoft for development. I don't use vim. I stick with the defaults as much as possible as painful as that is. I thoroughly document all changes I make so that on the next clean install, I can remember what I did before. Any of my "conveniences" are never dependencies. The only dotfile that matters to me is my .bash_aliases file which is merely a stub pointing to an over-engineered startup script to avoid the madness of using dotfiles.

It isn't what you asked, but we use Gitpod to have identical environments across our team and between different laptops. I used to avoid writing code on my Macbook (using it only for administrative stuff I can do in Chrome), but now that it's identical to my main Ubuntu driver it's actually pretty nice. I also used to hate Windows/Mac developers complaining that scripts don't work for them because bash/coreutils are different on their machines.

Work-provided bootstrap script to install most tools.

Self-provided dotfiles for shell and the like.

But since I started using VS Code Remote, the "bootstrap" portion doesn't happen all too often.

I use salt for configuration management of the machine itself (system-wide settings, packages), a dotfiles git repo for desktop configuration files with submodules for certain things (like package managers for vim and zsh).

For development environments, JetBrains IDEs have their own cloud config sync thing and I try to stick to defaults as much as possible (and rely on the language environment's tooling for linting/formatting/etc rather than the one in the IDE).

Nix package manager / Home manager + a Brewfile for some casks

Now that there are flakes (and the macOS installer is really good now), I can `git clone` my config and bootstrap a new machine with this

    sh <(curl -L https://nixos.org/nix/install) --daemon
    nix build .#homeConfigurations.{computer}.activationPackage --max-jobs auto --cores $(sysctl -n hw.ncpu) && ./result/activate && rm -rf ./result

I stick to default configuration as far as possible and I'd rather learn the hot key I dislike, rather than changing it.

Everything is a in git repository I usually call dotfiles.

I wrote a utility for this problem. I had 3 computers -- Linux with HiDPI, Linux with a normal DPI, and Mac. They all used the same dotfiles with slight differences. It was impossible to keep them in sync. I created a super simple template utility designed for working with dotfiles.

https://github.com/kesslern/dot-templater

Basically I use Git, ln and a setup script that I wrote.

https://github.com/danisztls/dotfiles

> primarily that I'd have to try to share it between professional and personal computers

My script has a recipes feature so you can store config at arbitrary places and have different recipes/configs for different situations.

These days I use VSCode's remote development extension to mount my dev machine on my laptop. It works well for frontend and backend works (automatic port forwarding), but obviously doesn't work when working on native or mobile apps. I simply duplicated the environments and sync the development files with git when working on native stuff.

Wouldn't remote be the simplest solution?

Unfortunately, I can't find a perfect remote software, which should be able to automatically adapt to client resolutions, support multiple monitors, use hardware acceleration.

RDP is great, but it does not utilize the high bandwidth of modern network environment, so it's not as performant as it should be.

I have a custom repo which my .config folder will have symlinks to. It gets synced to remote git (~GITHUB). For new devices, I use stow[0] to create symlinks...

[0] - http://www.gnu.org/software/stow/

As many others have mentioned, dotfiles in a git repo (https://github.com/lachenmayer/dotfiles), mainly for having unified shell themes/aliases/etc. on all machines I use.

I stole/copied my setup from Nick Janetakis who's just great all around. Its worked for me through several new systems and many updates.

https://github.com/nickjj/dotfiles

I use Strap (https://github.com/MikeMcQuaid/strap) to manage everything and it works pretty dang well for me on macOS. Homebrew brewfiles were a game-changer.

I have a repository with common config files. Whenever possible I prefer to not just symlink files but instead include them (source in shell, load-file in emacs, etc). That way I can still have local variations, work-related stuff, etc.

I have put vscode into a docker container. This allows you to commit the settings via git.

https://github.com/pubkey/vscode-in-docker

Syncthing is magic. I use it on all my computers (personal/work/home server/etc).

Put the config files in their own directory and then share them with syncthing and then use symlinks to link to them in the right place on each system.

Nix/NixOS. It is the best in class tool for this purpose, with a bumpy learning curve due to the subpar language and complex documentation. But once things get going it's quite a convenience.

I have a dedicated repo for this: https://github.com/Frizlab/frizlabs-conf

I don't synchronize them. I have Ubuntu server edition running on an old machine. I ssh into the machine to do any sort of programming. VSCode Remote is really helpful.

Two parts:

  1. For dotfiles, YADM: https://yadm.io/
  2. For everything else, like packages to install, I use an Ansible playbook.

Both sync via git.

For the MacOS users out there, Mackup is pretty nice.

https://github.com/lra/mackup

I just use this https://github.com/lra/mackup since a decade

Everything is source-controlled: https://github.com/kbd/setup

the main question here is, do you really need to change the settings once you have a baseline?

I'm another one using a private GitHub repo for this. But I don't need to pull, update, sync or whatsoever. I've been using the same config for years, and in the eventual case that I would change / add something, I can do that quickly in a few computers, no need to have any sort of sync.

For VSCode settings I just use the built-in service.

This is pretty much what vagrant was made for.

[1] - https://www.vagrantup.com/

I've moved my neovim dev environment entirely to a docker container. That way my development environment is always only a `docker run` away.

I use SyncThing between Mac, Windows (including Ubuntu WSL) and Fedora. I also sync my dot files (with a Git backup) that way.

I just use Goodsync personally. I used to have it sync to a WebDAV server in my house, but these days I just use a cloud provider.

I manually scp config files whenever I set up a new pc (I should really set up somethin better)

syncthing and gnu stow.

as long as things stay reasonably connected and you take a bit of care to avoid split-brain (after powering up a laptop that has been off or away for awhile give it some time to sync) then you can even sync git repos just fine.

I mount the home directory to NFS for all of my machines.

Set up your environment in a nix shell.

I use a git repo with dotbot

I just use nix.

Scripting, scripting, and more scripting. I wish there were a better way, but there isn't. And it will forever be brittle, because operating systems change. With that said, here's what I do.

First, I keep a personal monorepo. It not only has all my dotfiles, but also my personal website, and binary tools I've written. A game changer for me was git submodules, which let me keep third party stuff up to date with a minimum of fuss. The only thing I keep in a separate repo is my password repository.

So the main script I use invokes a lot of other scripts in order. This is so I can just run one thing to update everything. The first thing it does is sync the monorepo and password repos. Then it runs my homebrew stow command, which is like GNU stow[1] but I have all the control I want over it because I wrote it in Ruby. This not only syncs my dotfiles but also copies all my homebrew bins over to where they're not only in $PATH, but /usr/local/bin so that they're in root's path as well.

Next is package management. I run Arch Linux and use pacdef[2] for lightweight declarative package management. If I install some random package, it will remove it at this step, unless I put it in one of my package lists that I keep in the monorepo. This tool will take any Arch Linux install with paru or yay and make it into mostly the system I use every day. It is the most brittle part of the process because, well, operating systems change.

Finally, to manage all the other package management tools out there, I use asdf.[3] My script installs all the plugins if they're not there, update them, then installs everything. Most asdf plugins support a 'default lib' config, which install a list of packages whenever you install a version of the tool. It's not the wholly declarative solution that pacdef is, but I may eventually write enough scripting to get it there.

It has to be this way because Linux is freedom, and with great freedom comes great amounts of time spent learning how it works. I used to try to keep a portable config across OSX, Windows WSL, and Linux, but that was really hard to maintain, and my life got way simpler when I decided no more OSX or Windows. It's kinda possible to do but it's a ton of work.

But the basic building blocks are, 1) dotfiles, 2) system packages, 3) secondary packages. Get those three scripted, and you're off to the races.

[1] https://www.gnu.org/software/stow/

[2] https://github.com/steven-omaha/pacdef

[3] https://asdf-vm.com/

Nix seems like the perfect match for you.

You would think.

But Nix and Guix are still very very new. Arch Linux has the best overall package management system, nothing else even comes close. Wrapping it is a way better option than trying to reinvent it from the ground up.

If Arch didn't exist, I'd lean on Debian before going Nix.

> But Nix and Guix are still very very new

Uhh nix has been around since 2003 [1]. I can definitely recommend taking a look at it if you are fine with running Arch.

[1] - https://en.wikipedia.org/wiki/Nix_(package_manager)

Sure, but Nix is very weird, and takes quite a different approach compared to other things. Understanding Linux is both necessary, but not sufficient.

But comparing Arch an NixOS:

- Arch requires more elbow grease than Ubuntu. NixOS requires more elbow grease than Ubuntu. I wouldn't recommend either to beginners.

- On the other hand: NixOS is immutable and pure, whereas Arch is a system that can be beaten into shape. - Or the Arch Linux wiki is fantastic, and Nix documentation is .. all over the place.

(Maybe AUR is better than Nixpkgs; but ultimately nix is a much more powerful tool than pacman strives to be).

Nix is different, but I wouldn't say its _weird_. Nix the language is weird, but the packaging system is pretty straightforward. Imagine that every single thing you install is done in a chroot, so you need to declare exactly what it depends on to have it work. Thats it.

My point is that if you are comfortable with the effort needed for Arch, NixOS is _probably_ a better option because I think it does the same thing but better.

mackup + syncthing