How I set up new MacBooks | Hacker News Reader

How I set up new MacBooks

catalins.tech

53 pointscmpit47 comments

When you search for "dotfiles" on GitHub, you'll find plenty of good script examples for setting up a new computer. Since Apple doesn't provide good documentation on what you can configure with "defaults" variables, these examples are a goldmine.

That's how I found some to be honest. :-)

Jeff Geerling has a phenomenal ansible playbook to setup his macs:

https://github.com/geerlingguy/mac-dev-playbook

This is the ideal version of the playbook I've been wanting to write for years to automate the chaotic dotfile collection I've written over the last 15 years!

I moved all my setup to Ansible about five years ago. It’s been awesome, especially as it makes it trivial to replicate changes to new machines. Installed a new package? Run the playbook again. Changed a script? Run the playbook again.

Sure, there are edge cases I hit because I have some older machines, but for the most part, it’s awesome. I’m up and running on new Macs within a coffee break of getting terminal access.

PSA: "setup" is a noun, and "set up" is the verb you're looking for.

Noted, thank you!

I have https://github.com/rcarmo/ground-init - which I also use for Macs, although via a bit of a hack right now. I should update it to a brewfile-like setup...

Anyway, my $0.02 is that doing fully automated installs on Macs is a fast track to having weird Finder and settings bugs (if not worse), so I mostly just install packages and very seldom (if ever) apply settings via the CLI -- I've had Apple break things across too many OS releases to find that a worthwhile long-term strategy, and most of the time I'd rather just use Migration Assistant (across Macs with equivalent OS versions) or configure settings manually for a new OS release.

Edit: just went and updated the above script to support brew/cask installs on macOS. Settings can go into the runcmd section.

nix-darwin is a thing, and like all nix tools. It tackles this exact problem

I do this too. Nix is incredible, until it isn’t and then I regret using it so much.

I’ll probably use something dumber for the next machine, and keep nix for servers and local vms.

I'm trying nix instead of Homebrew on my mac. It worked great until I decided to give rust a shot. I think my solution is to just do rust development on my Arch machine and stick with nix. That said, if I run into additional issues, I will probably just go back to Homebrew.

Where were your pain points?

from the top of my head: various hacks to make apps available to spotlight, packages/apps behind their equivalents in brew to the point where I use nix to orchestrate brew for too many things, starting envs and build switch is too slow for my taste despite caching etc, nix the language is unfriendly and hard to debug, the stack traces are useless, etc

Highly recommend keeping Nix to your NixOS machines. IYKYK

Can you elaborate? I don't know, and would like to know.

I have custom scripts to bootstrap my macOS as many others here, and I can testify that migrating to nix-darwin greatly simplified my scripts.

P.S. I don’t use home manager though as I also need to bootstrap systems without nix.

The best way to do it!

I have a file that sets my MacOS Defaults: https://github.com/joeyagreco/dotfiles/blob/main/.macos

And a file to remap some keys: https://github.com/joeyagreco/dotfiles/blob/main/.macos_key_...

And apply the remaps: https://github.com/joeyagreco/dotfiles/blob/b5b819c9bcde2e3a...

Why are macOS keyscan codes 11 digits long?

Probably modifiers in the binary number, where a specific bit means something. That gives very large numbers in the end.

Interesting! Do you know how to convert com.local.KeyRemapping.plist to the JSON format you used for remapping keys?

I used to hand-setup each new Mac, but lately (last decade or so; gosh this M1 Pro is absolutely ancient) I just let the migration assistant do the needful.

Storage is too cheap for me to spend time optimizing it anymore. I’m sure I have cruft somewhere, but it doesn’t bother me.

I get that. Personally, I'm a bit weird because I don't like to bring all the stuff from the previous machine (documents, files, etc.). I like to start fresh and only install a couple of apps / configure some settings.

Understandable - it gives you a chance to do "spring cleaning" and decide what you really want/use.

Exactly, haha. If something's important enough, it'll find its way to the new machine. :-D

> I just let the migration assistant do the needful

but will it revert back if things go wrong?

It leaves the "source computer" alone, so if it blows up you can always just start again.

I never trade in my old computer, even if I'm going to sell or get rid of it (donate) I keep it around for a month or so to make sure everything's working.

Dear, this was gold.

It reverts back and it does it at its earliest.

Just in case anyone is lost in all the `defaults write ...`, I really recommend https://macos-defaults.com/

It's a really nice overview for (almost) all of the options.

I have an open-source script which installs all my conf https://github.com/Frizlab/frizlabs-conf

Thanks for sharing it. Will deffo have a look and pick some stuff for my config.

I use a setup script that installs brew, a brewfile, runs chezmoi to setup terminal and defaults, pulls some secrets/keys out of 1Password, and good to go, other than manually having to log into certain things. Everything in a personal dotfiles repo. I do have to occasionally diff my brewfile and terminal config and push that up, I should probably spend a little time figuring out how to automate that.

same, more or less!

I am also using this setup powered by chezmoi. It has brilliant secrets support and powerful templating allowing cross-platform setups. I do get lost in its state sometimes when updating `run_once_*` scripts and trying to make sure they still run. Another friction point is external tools installed via .chezmoiexternal.toml from GitHub.

The missing magic incantation to create your Brewfile:

brew bundle dump

Thank you!

Ah ha! I had searched the article to see if there was a way to do that. Because while it would be awesome to have a file like this, creating it sounded like a pain.

sweeeet

In the case of an existing Brewfile, make sure to execute "brew bundle dump --force" to overwrite the Brewfile with updated list of formulae, kegs etc.

Is there any shell/bash extensions that just allow you to use LLMs easily from the command line? Basically like warp but just a simple extension instead of a full iterm replacement?

[gh copilot](https://docs.github.com/en/copilot/using-github-copilot/usin...) works okay.

Just use Ansible, it's the best for installing and configuring things

I'm always a little upset when I read posts excited about configuring things, where they've missed the obvious tooling that's designed for it. Not sure why, but it makes me sad.

Obvious to whom? We don’t all know everything. Also, rolling your own can be an interesting learning exercise.

I think the lessons in this article are still great and you can automate them via ansible. E.g. install brew, run brewfile, apply default config, etc.

Professionally? Sure. Personally, I don't want to learn and maintain ansible for something I do once every 5-7 years. I basically diffed the defaults and got the settings I need to change in my script. I then add or remove them as I tweak things (infrequently). The rest of my shell script is a Makefile I use cross platform for making directories and stow-ing dotfiles.

No. I tried, the person from which I initially based my conf repo[1] tried too[2], we both went away from it (w/o communication between us). We both realized Ansible is good for managing many machines in a professional environment, but waaaay overkill to manage the configuration of a single machine (or two or three), as well as incredibly obtuse in its syntax.

[1] <https://github.com/Frizlab/frizlabs-conf> [2] <https://github.com/wincent/wincent>

slow solution if you want to configure your box quickly and idempotently whenever you launch a terminal (IMO).

Reply on news.ycombinator.com