
Hacker's Guide to Setting Up Your Mac - matthewmueller
http://lapwinglabs.com/blog/hacker-guide-to-setting-up-your-mac
======
astrange
This "cool hacker settings for your Mac" script turns off your laptop's power
saving features (sleep, display dimming, hibernation even though sleep was
off(?)), removes at least three kinds of backups for data loss
(MobileTimeMachine, Resume, hibernation file), and changes AppKit settings in
a way your customers will never be using (by turning off Automatic
Termination, which is pretty harmless).

Please don't run scripts like this, unless you promise not to post about how
your untested configuration is so unstable and has such bad battery life after
an OS X update.

~~~
drzaiusapelord
Just like PC's, Macs have entered the world of, what I call, "car guys." Car
guys are always fiddling with things for a tiny performance or perceived
security boosts without really thinking things through. In the Windows world
you'll hear them tell you how you must disable the UAC, must install registry
'cleaners', must use $av_vendor_x because $av_vendor_y sucks, fiddle with some
obscure registry change, use drivers or utilities from sites laden with
malware, etc, etc. As a sysadmin, these guys drive me crazy. Often, they're
the dominant voice in PC or gaming forums and their advice is not only
terrible, but actually makes things worse for the end user looking to solve an
issue.

At least in the Windows world we have ugly GUIs and other roadblocks to making
these changes easy. With OSX's scripting, you could have one single script
make all these changes. Its interesting to think how terrible some random
person's advice on the internet can be to your machine if you decide to type
in what they say. Worse, I'm seeing a lot of FOSS/Linux stuff that more or
less asks you to wget a random file on a random server into your shell and run
it as root. Umm, no thanks.

The above wouldn't be so bad if they all came with well written undo scripts,
but I think the "car guys" aren't even considering scenarios where their half-
cooked advice would be wrong. If they did, they probably wouldn't be putting
this stuff out there like this.

~~~
sanderjd
This is a great analogy. In high school and college, I believe I was a Windows
and then Linux "car guy". One of the things I liked when I (mostly) switched
to OSX from Linux was that I no longer had to spend any time fiddling with
stuff. I used to find it fun, now it just feels like there's way too many
interesting things to be learning about and doing to spend any time tweaking
crap on my computer!

~~~
lelandbatey
I feel there's two levels of the constant fiddler, one where their fiddling is
fruitful, one where the fiddling is not. The difference, I feel, basically
comes down to how much you document, test, and automate what you do.

If treated like science instead of voodoo, messing with your computer becomes
one of those _" interesting things to be learning."_

~~~
sanderjd
That's how I used to feel, and then (documentation and automation or not) it
totally lost its interest for me! Creating software is just so much more
interesting than configuring somebody else's. YMMV.

~~~
klibertp
Programming is very interesting and enjoyable, but it's also quite hard. The
road from idea to implementation is often long and filled with obstacles. It's
well worth it to spend some time "fiddling" to remove some of them. In truth,
I personally am not very interested in tinkering with config files - it's
boring and frustrating at times - but I _still do it_. I feel it's my duty as
a professional as well as a pride as a craftsman to keep my tools sharp.

People who refuse to do this scare me a little. They got something somebody
else told them works and they learned to live with it even if it has flaws.
Now I have to wonder: how many refactors weren't done, how much technical debt
piled up just because they did the same when writing code?

~~~
sanderjd
Interesting perspective! I think the analogy to refactoring is also apt.
Keeping tools sharp is good, but (quickly, in my opinion) hits a point of
diminishing returns. Refactoring is even better but also eventually hits that
point (much less quickly).

~~~
klibertp
> but (quickly, in my opinion) hits a point of diminishing returns.

That's certainly true - it depends on the tools you use and problems you use
them to solve, but sooner or later you'll see your "sharpening" stop giving
you any advantage. That's the moment you should just stop :) And maybe try
other tools: but that's always a non-trivial time investment and should be
done only after making sure there actually is something to be gained from the
switch.

This is true in most other areas as well. For example, I'm collecting knives
as a hobby. I had to learn how to care for them and sharpen them. It's
incredible how sharp you can make a knife given proper tools - whetstones ans
stropping - you can get an edge which is sharper than any scalpel or razor.
It's also a complete waste of time to do so: it takes hours to make a knife
that sharp and it takes one or two cuts to dull it. Granted, my "dulled" edge
is probably still sharper than anything you ever saw ;) but in the end I get
the same edge I'd get without those extra hours spent on polishing it. It then
stays that way for quite a long time. It took me years to learn how much
sharpening is "good enough". Now, for my primary pocket folding knife, I spend
15-30 minutes sharpening it per week and get an edge I can trust.

It's the same in programming. Both sharpening knives and tinkering with
programming tools can be pleasant by itself. It takes practice to recognize
that "good enough" is actually really ok and that anything more than that is a
waste of time. Still, I can't imagine _not_ sharpening my knives at all. Or
giving them to someone else for sharpening. The very idea seems crazy to me.

~~~
sanderjd
Your story about the knives is interesting, because it sounds like all you
really _need_ is one (or maybe even zero - I'm not sure what you're doing with
them) "good enough" knife, but you _enjoy_ having a bunch and tinkering with
them. That's great, and sounds pretty fun. My point in this thread has just
been that at some point I realized all I really _need_ is a simple development
setup, and that I don't particularly _enjoy_ tinkering with it.

------
mwfunk
One of the most valuable skills someone can have, in my opinion, is not
getting attached to really specific workflows or settings or tools. Instead I
value being flexible and being able to adapt to whatever system I'm using.

In practice, this means that whenever I think about making some change to my
software environment, my first impulse is to ask myself, "do I really have to
change this?" This is a 180 from my old, college-age attitude, in which I not
only wouldn't question the impulse, I would look for ways to automate making
as many little changes and tweaks as possible. At the time I thought I was
doing it because I was really increasing my productivity, when in fact I was
just doing it because it was fun and fed into my self-image as a super l33t
hacker guy. If anything, it was a distraction from whatever I was actually
supposed to be working on.

~~~
burntsushi
I am exactly the opposite and it certainly has nothing to do with fun or self-
image. I can hop on to any Linux box and be just fine. But I'm _comfortable_
in a familiar setting with my `~/bin`, aliases, editor (vim), keybindings, a
few key-remappings and package manager (pacman). There's a lot of benefits
that come from having precisely the same environment on my web server, home
machine, laptop, media PCs and my machine at work.

I consistently look for ways to automate things. I do it not because I'm a
tweaker for tweaking's sake, but because I find it insane to let myself be
annoyed by tasks that I know I can automate away. (Then my brain can forget
the details of the operation because it is enshrined in code and maybe even
some documentation.) For me, it's an efficient way to work. Actually, that's a
nice way to sum up how I work: how can I most effectively offload This Stuff I
Know so I don't have to worry about it any more?

I am _extremely_ uncomfortable on Macs or Windows machines. The solution is to
just not use them. (We, as programmers, are fortunate to have some freedom
here. For example, I would not take a job with someone who forced me to use
OSX or Windows.)

To give you an idea of how far I'm willing to go: I wrote my own window
manager. I spent years on that path. I got something working around late 2012
and haven't really touched the X11 world since. I had some really specific
goals that I wanted to accomplish (support 3+ monitors correctly), and I did,
and now I'm happier and more productive for it. Another plus: people using Go
now have native X client libraries.

Another example: I wrote 8,000 lines of Go to download all of IMDb and load it
into a relational database in under 8 minutes (including building trigram
indexes on all movie, episode, tv show and actor names). And then I built a
command line utility that does fuzzy search and can rename all of my media
files instantly. Renaming them manually was terrible drudgery. (And I
certainly enjoyed the engineering challenge of making this fast.)

Sorry for the banter. :-)

~~~
mwfunk
I totally get what you're saying, I guess I just have different values (for
lack of a better term) where this stuff is concerned. My ideal job would have
me bouncing between different operating systems, hardware, and languages all
the time. For career reasons, and just to feed my curiosity, I have a fear of
getting too comfortable with any one workflow/language/OS/etc. Plus
familiarity breeds contempt- every time I thought I found the perfect
anything, it was only because I hadn't been using it long enough to hit any of
the pain points.

I've come to feel really strongly that there is no one right answer when it
comes to those things. Sometimes there are wrong answers (I wouldn't write a
word processor for a desktop OS in assembly if I didn't have to), but rarely
is there ever one right answer, and there's usually something to be learned
from all of the viable alternatives. If I get too used to one particular
environment, to the point where I refuse to use anything other than that one
environment, then I would feel like I was missing out on a lot of cool stuff
by ignoring the rest of the computing world.

The other side of it is that I've also come to feel really strongly that a lot
of the tweaks and optimizations that people swear by and obsess over with (for
example) their editor configs aren't actually improving efficiency. When I've
gotten into deep configuration and automation and optimally efficient usage of
vim or emacs, it felt like I was more efficient, but in hindsight I don't
think I actually was. I might've saved a few keystrokes here and there, but at
most the extra keystrokes I shaved off were annoyances, and not meaningful
impediments to my efficiency. I spent so much more time learning how to shave
off those few keystrokes that it's unlikely that I'll ever get it back via
repeated usage of what I learned.

That's just me though, everybody's got different motivations for why they do
what they do. I would like to think that all of the above comes from hard-
earned experience, but it's just as likely to be my own preferences and
values. When you get super old like me, you get to pass off your personal
preferences as genuine wisdom learned the hard way over many long years. :)

~~~
loevborg
Excuses for the off-topic question, but would you be willing to share your
imdb scraper? That would be very useful to me. (My contact data is in my user
profile.)

~~~
burntsushi
I think you replied to the wrong person. I just happened to see your comment
when looking over my "threads."

And it's not a scraper. :-) Here:
[https://github.com/BurntSushi/goim](https://github.com/BurntSushi/goim)

------
ccbean
After installing Mackup, the Mac backup tool mentioned in this guide, I
noticed that it backed up my entire ~/.ssh directory to Dropbox. This included
my id_rsa private key, which I would prefer not to have on Dropbox, even with
a key passphrase.

~~~
matthewmueller
Yep, it's meant for backup and restoring. I'm hoping that in future builds of
Mackup you will be able to configure what you backup.

~~~
ccbean
Right, or even if Mackup could add a Y/n confirmation prompt before copying
that private key file over to Dropbox.

------
616c
I do not wants to flame, but is there a reason people dislike Macports so
much. I tried Homebrew when it was 1-2 years old, but stuck with ports bc it
was so stable, compiles from source, and I never heard a serious problem.

I heard the opposite complaint on the net, but almost all Macports hate was
from many years before.

I am the only one who chose not to rely on Homebrew!?

~~~
archagon
My understanding is that Homebrew does not clobber any system defaults — works
with the OS, not against it. I could be wrong, though.

~~~
tvon
No, MacPorts is actually more sane in this regard because it build it's own
set of dependencies instead of relying on anything the system provides. This
makes it a more soundly designed tool, IMO.

Homebrew also recommends using /usr/local as the root which I think is just
plain bad advice, but it is simple enough to change it to something else.

~~~
6cxs2hd6
Why is /usr/local bad advice?

~~~
teacup50
Because /usr/local doesn't belong to homebrew and is not appropriate for
homebrew to commandeer.

MacPorts was originally written by the BSD team at Apple; if /usr/local was
where a packaging system was supposed to stuff itself on OS X, they would have
used it -- instead of /opt/local.

The co-opting of /use/local breaks all kinds of stuff -- for instance,
/usr/local/lib is in the default linker search path and _can 't_ be removed,
which means that trying to _not_ link against homebrew libraries requires some
pretty evil hacks -- such as library symbol interposing to hide /usr/local
from stat(), etc.

~~~
antimagic
I disagree. / is where the stuff needed for single-user mode gets installed.
/usr is where the OS's userland stuff gets installed. On Linux systems this
includes everything that you get from your package manager, because this is
considered to be part of your system. /usr/local is wher you install your own
packages. For example, if I'm installing something from source, that's where
I'm going to install it. Or if I'm building my own project, I would also
install it there.

On a Mac, there is no system-blessed pacakage manager - the official packages
are pre-installed on your Mac and only change when you get an OS update. They
tend to be installed in /Library or ~/Library. All of the add-on package
managers therefore play a role much closer to that of hand-installed source.
It's logical that they install to /ur/local. In particular, one of my main use
case for package managers is when I want to try out a package that has a whole
bunch of dependencies. I might want to compile the package that interests me
by hand, as I need to tweak the config, but I don't want to have to do the
configure-make-make install dance for the 30 packages that it has as
dependencies. That's where homebrew / MacPorts comes into the picture, they
save me that work. But they should be installed into the same hierachy as the
package that does interest me, as they are at the same level of
"officialness".

One last thing. I know Fedora, Gentoo and MacOSX fairly well, and I have also
worked a fair bit on a hand-rolled linux distribution. None of them ever had
/usr/local/lib in their LD_LIBRARY_PATH by default, I've always had to
configure that in my .bash_profile. This is exactly what you would expect, by
default the directory should be empty, so why add it to the default
LD_LIBRARY_PATH, that doesn't make any sense.

~~~
tvon
> /usr/local is wher you install your own packages. For example, if I'm
> installing something from source, that's where I'm going to install it.

Right, that's what it's for, it's also why a 3rd party package manager
shouldn't use it.

~~~
eropple
Homebrew _is_ installing stuff from source, though. It's automating the task
of me doing it.

~~~
tvon
Well, it usually installs from source, but that's not really the point. It's a
package manager, it is trivial to give it it's own home, (and thankfully they
made that an easy thing to do), but to throw it in that /usr/local bucket by
default? It seems like a decision that requires real justification and the
reasons I have seen seem pretty weak.

I mean, in the end it seems like almost nobody cares, but it's always been a
pet peeve of mine.

~~~
eropple
I get what you're saying, but /usr/local is where I install stuff. I'm happy
with having the thing that does little more than untangle my dependencies
before running `make` for me with sane defaults use it too.

I expect to find system-specific applications in /usr/local. I get the
argument otherwise, and it has merit, but not enough to _not_ do it, if you
get me.

------
juddlyon
It's interesting to see how other folks tweak their machines, but this is a
highly personal thing and you're likely to break things.

The older I get, the more I leave things alone. Swim with the current.

~~~
orangecat
_The older I get, the more I leave things alone._

Me too, but I'd never discourage anyone from tinkering. Sure you might break
stuff, and that's a learning opportunity.

~~~
dopeh
Definitely, but after reading some of the responses (e.g. "I ran this script
but now my spotlight is missing"), I think too many people skip the learning
part.

------
yrmt
A great alternative to Homebrew is pkgin because of it's speed and the amount
of packages available in pkgsrc.

More info here: [http://saveosx.org/](http://saveosx.org/)

~~~
4ad
This is the work of Jonathan Perkin (from joyent):
[http://www.perkin.org.uk/](http://www.perkin.org.uk/)

It's great. It really is. I never understood why it's not used by more people.
Homebrew is simply awful.

~~~
spost
Just curious, what's wrong with Homebrew? I'm just a student, not a full-time
developer, but I've never had problems with it and find it pretty pleasant to
use.

~~~
yrmt
It's slow and it has to build the packages most of the time. pkgin will
install a precompiled packages very quickly. It is also a whole C program and
Homebrew is just ruby scripts.

~~~
evgen
So the opaque pre-compiled blob that installs other pre-compiled blobs is
somehow better than a collection of scripts that lets you build from source? I
don't think so... As an update is something that is done occasionally and in
the background "slow" is not exactly a reason to change.

~~~
snw
actually the "src" in pkgsrc means that you have the choice of using binary
packages (pkg) or building from source. The best of both worlds!

Give it a try, you might like it (because it rocks!)

~~~
ics
Homebrew does both as well for popular packages; 'bottles' are binary
packages, with the option (--build-from-source) to build it yourself.

------
efuquen
> allowing you to setup a new Mac in a matter of hours, not days

Wow, it takes days for people to set up their Macs? I would be interested in
something that would make this take minutes, not hours. It's already pretty
easy to setup a Mac for development in a few hours.

~~~
dekz
I recently received a new MBPr from a work laptop and I would totally agree it
takes days to setup from scratch.

* It takes hours to download Xcode

* It takes hours to download OSX Updates

* Setting up Homebrew, Zsh, Vim, Browsers, GitHub, Dropbox, Mail, Rbenv, Rubies, Cloning work repos

* Getting those other smaller things you were tinkering with, Z, Go

Everyones dev setup is different. So I'd agree it takes days to get set up.

~~~
72deluxe
But the speed to download xcode + updates is related to your Internet speed,
surely? Nobody says Linux takes days to set up and then reference their
Internet connection...?

I've got fibre, so perhaps I'm biased. Also, I avoid Homebrew/MacPorts etc.
because the apps don't fit in with the window manager properly.

~~~
dekz
Yes but the parent comment is about installing in minutes vs hours vs days. I
proposed my story where it took hours to download Xcode and eventually days to
fully get my system setup.

I also once had Fibre then moved to a bigger city without Fibre.

Who doesn't say linux doesn't take days to setup?

I say my OSX took days to setup, if you have a counter anecdote then
elaborate.

~~~
akfanta
With that internet speed, it could take days to do anything. :D

------
swat535
i personally think Boxen is the easiest way to setup a brand new machine. it
can also easily be distributed and updated the only downside is that it
requires Xcode + command line tools.
[https://boxen.github.com/](https://boxen.github.com/)

~~~
xbryanx
And you can bootstrap that part of what you need for Boxen with one command:

`xcode-select --install`

------
MikeKusold
I would also highly suggest installing curl via homebrew. The version that
ships with OSX 10.9 has some broken features that might bite you.

[http://curl.haxx.se/mail/archive-2013-10/0036.html](http://curl.haxx.se/mail/archive-2013-10/0036.html)

~~~
iancarroll
Did I miss something or does Chrome use the Keychain?

~~~
chc
Chrome uses the Keychain for passwords, but it handles certs itself AFAIK.

~~~
iancarroll
Not according to this: [http://www.chromium.org/Home/chromium-security/root-
ca-polic...](http://www.chromium.org/Home/chromium-security/root-ca-policy)

------
wasd
Anybody have any suggestions on how to do this on a Windows PC? I like
Ninite[1] a lot but I would prefer something more customizable.

[1]: [https://ninite.com/](https://ninite.com/)

~~~
Aloha
[https://chocolatey.org/](https://chocolatey.org/)

------
swah
Do any of you use Dock replacements?

I'm faster with the Windows-style taskbar and uBar
([http://brawersoftware.com/products/ubar](http://brawersoftware.com/products/ubar))
was the sponsor of the last episode of John Gruber's podcast.

~~~
dekz
I use a auto-hidden dock which has nothing in it. It is populated by running
programs and is not used as a launcher.

For launching I use a tool like Quicksilver or Alfred of Spotlight.

This way I get more screen realestate, I see no point staring at a dock icons
all the time.

My dock resembles Command-Tab.

~~~
ics
Same; though upon browsing the support page for uBar, I stumbled on this:

    
    
        defaults write com.apple.dock autohide-delay -float 1000 && killall Dock
    

Make sure to use a lowercase 'd' in 'dock' in the identifier– it matters on
Mavericks.

~~~
ubar
Thanks ics I updated the support page.

------
unspecified
You still have to replace /bin/bash and /bin/sh binaries, even after doing a
`brew install bash`.

...right? `brew install bash` will just give you /usr/local/bin/bash, and then
use that as your interactive shell.

~~~
oinksoft
No, you change your user shell to the shell you want. You can do this in the
"Accounts" preference pane by control-clicking a user, selecting "Advanced
Options" from the context menu, and changing the "Login shell" setting to your
preferred shell.

~~~
unspecified
Right....but your user shell has nothing to do with shellshock. Shellshock
involves things like Apache invoking system calls that need a shell, and those
system calls don't care what your user shell is. They care what /bin/sh and
/bin/bash are (or wherever your system shells live, it's /bin for OSX).

This guide is claiming that updating your login shell to bash via Homebrew
will mitigate shellshock, which is flat-out wrong, and dangerous to boot.

~~~
oinksoft
OK, but nothing in your comment implied that you were talking about the
"Shellshock" vulnerability. I believe that a very recent OSX update patched
this vulnerability, anyhow.

~~~
unspecified
Oops, a very good point. I should have mentioned that right off the bat: my
issue was with calling this a "hacker's guide", when it contains a pretty
blatant security issue.

------
gauravagarwalr
This just screwed up with my settings. I was lucky that I had almost
everything backed up.

The problem was with Mackup, in the sense, for it to 'backup' (which I assumed
would just copy/paste the files) had actually moved the contents to Dropbox
and created the symlinks in place. Therefore not a true backup!! :(

I guess what I am trying to say is that please be VERY SURE of what the 3rd
party tool/script does before you use it, cause sometimes you might just 'rm
-rf' the seemingly useless artefacts.

Screwing up your work environment is NEVER fun!

------
rcarmo
Other than using brew (which I love and use from the outset), I would strongly
advise against following this guide without understanding what it's doing.
Seriously.

That's why the author says "This script should not be run without prior
examination", for starters.

And the bit about having to install a new Python just to get pip when you can
do it just fine with easy_install pip... _rolls eyes_

------
ryanmarsh
I'm surprised oh-my-zsh wasn't mentioned.

~~~
dekz
What makes oh-my-zsh worth being a assumed default in your opinion?

------
dfc
What is the difference between the cask installation suggested in the link and
the cask installation procedure suggested on the cask home page?

    
    
      $ brew tap phinze/homebrew-cask ; brew install brew-cask  
    
      $ brew install caskroom/cask/brew-cask
    

FYI: The grep in homebrew/dupes is not a newer version of the grep provided by
OSX. OSX grep is the BSD variant, hb/dupes provides GNU grep. I am always
shocked by how poorly BSD grep performs compared to GNU grep. I think you need
to provide the `--default-names` option in order to use GNU grep in place of
BSD grep.

~~~
phinze
> What is the difference between the cask installation suggested in the link
> and the cask installation procedure suggested on the cask home page?

Two differences. One is that we moved to an org repo, so the first form is
relying on the github redirect from the move. The other is that the second
form relies on the semi-recently introduced "auto-tap" syntax in homebrew.

Functionally they will get you to the same place (we've got code to notice
that your remote is pointing to the old repo location and update it), but the
second form is newer and cooler. ;)

~~~
matthewmueller
Good to know. Thanks for your great work phinze. Updated the post :-)

------
kylemathews
I have an Ansible setup [1] that installs my dot files and other useful tools
on Mac and Debian/Redhat derived platforms. I also created recently a Docker
image [2] that runs my Ansible script so I can easily dev inside this Docker
container. Just "git clone" and start working!

[1] [https://github.com/KyleAMathews/linux-
config](https://github.com/KyleAMathews/linux-config) [2]
[https://registry.hub.docker.com/u/kyma/dev-
image/](https://registry.hub.docker.com/u/kyma/dev-image/)

~~~
jimmcslim
If you like Ansible you might also be interested in OSXC which is based on
Ansible.

[http://osxc.github.io/](http://osxc.github.io/)

------
joeblau
Last year I was thinking about creating a service for this built on top of
Hubot. The core idea is that you would go to a website and configure your
profile. When you get a new Mac, you would just ssh install your profile, go
way, come back and your Mac would be setup (Similar to GitHub's new employee
setup).

I didn't do much research into whether or not anyone would pay for the service
or how many users they might be. But it sounds like this is a stab at helping
individual users set up something personal.

------
jason_slack
I've been a long time Mac user and I think that software setup and updates has
always been a bit clunky. Apple tries to make it easy with Software Update.
You can always Homebrew to get missing pieces.

For me, I use CentOS for servers and I really wish that OS X had 'yum'
([https://www.centos.org/docs/5/html/yum/](https://www.centos.org/docs/5/html/yum/))

It feels very easy for me to install, update, remove, etc

~~~
72deluxe
This is very true, and I too happily go to Linux land for servers. But for the
typical target market of Apple devices (this is debatable), most people are
happier with the download / open DMG / drag to applications scenario instead
of typing, no?

~~~
jason_slack
yes, I agree that most people are happy with the DMG process.

I wonder if I could port yum to OS X. I'd have to look into how they structure
the repo and how I would host it. What about just analyzing for what updates
the system needs and pulling them from their respective websites, etc.

------
msie
Fiddling around with rvm I tried to install the latest ruby on OSX. Well,
something in "brew" broke so I tried to do a "brew update" but got an error
with that. Then according to an SO entry I should "git reset" the local git
repo used by "brew". Why do developers put up with this shit?

Edit: I just discovered "brew doctor" and I had to use it. Ugh. Showing lots
of warnings that I have to wade through...

------
rsync
My stumbling block is always that I start with macports, which requires Xcode,
which requires logging into apple, app store, long download, long install ...

Do I understand that brew does not require xcode and I can jump straight from
a new machine to `brew install git` (for instance) ?

If so, why does anyone use macports over brew ?

~~~
iancarroll
You can download the command line tools directly, you may need to be a
registered Apple dev first though

~~~
reubenmorais
You don't, just run

    
    
         xcode-select --install
    

And it'll prompt you to install the command line tools.

~~~
untog
and, in my experience, fail every time you try to do it.

~~~
RexRollman
I just did this yesterday. Easy peasy.

------
csixty4
I like having separate "work" and "play" accounts on my machine, and Cask
isn't really set up to work with multiple accounts (issue #5887 in their
github issue tracker). That's something you'll need to keep in mind if you use
this approach.

------
thomasfl
My personal favourite is to clone this .emacs.d to get the emacs hacks as
featured on the [http://emacsrocks.com](http://emacsrocks.com) screencasts:

    
    
        cd
        git clone https://github.com/magnars/.emacs.d.git

------
kelv
I've built a less "hacker" way to automate the install of a bunch of common
apps at [http://getmacapps.com](http://getmacapps.com)

Aiming for something you can easily use quickly, or send to less techy friends
or parents to run.

~~~
72deluxe
Looks good but is opening a Terminal less techy for my mum? I would argue not.
She wouldn't know what a terminal was, other than perhaps something at an
airport?

No offence meant by the way. I don't know of an easier way to get the required
command to run, so apologies for no suggestions on how to improve it.

------
brown9-2
_The next thing you should do is update the unix tools you already have on
your mac. This is more relevant than ever since the recent "Shellshock"
debacle._

How many developers are launching bash scripts with environment variables
defined by third parties?

~~~
jayrhynas
not to mention that many scripts & apps often hardcode the system bash (i.e.
/bin/bash) so they won't use the homebrew version

~~~
dekz
Which is why you symlink the homebrew version ontop of /bin/bash!

------
0x420
Most of these I already have. I use GNU/Linux at home and it's what I'm most
comfortable using, but at work I need OS X for compatibility with Adobe
products. Any software that makes OS X feel a little bit more like home is a
good thing.

------
codez
I wrote something similar for myself in node based off of Zach Holmans
dotfiles.

A one liner tool in node that refers to defined config.

[https://github.com/jh3y/kody](https://github.com/jh3y/kody)

The dependency on a new machine is to install node.

------
tomphoolery
You thief! [https://github.com/tubbo/dots](https://github.com/tubbo/dots)

;) Just kidding of course, yours is way better. Time to think of another silly
name for my dotfiles...

------
aaronbrethorst
And nowhere in the instructions was the word "Xcode" used. Odd.

------
keypusher
> One area that's ripe for automation that hasn't seen much attention lately
> is setting up your computer.

Really? Puppet, Chef, Ansible, Salt, etc are pretty attention getting.

------
toredash
\- The goal of this post is to automate 80% of the bootstrapping, allowing you
to setup a new Mac in a matter of hours, not days.

Who uses -days- setting up your own computer ?

~~~
noir_lord
If I'm not restoring an image (which is the right way but technically
cheating).

It takes me maybe an hour from inserting USB stick to been able to develop
(most of that is watching progress bars), Vagrant has helped with that hugely.

------
spitcode
I thought the guide would start off with erasing osx and installing Linux
lolz, but honestly its a really good guide :)

------
nogbit
Hackers guide to setting up any laptop...especially ones that cost $1.5K less
than a Mac.

For beginners...
[https://wiki.archlinux.org/index.php/Beginners%27_guide](https://wiki.archlinux.org/index.php/Beginners%27_guide)

All others...
[https://wiki.archlinux.org/index.php/Installation_guide](https://wiki.archlinux.org/index.php/Installation_guide)

------
mikewhy
look into Brewfile[1]

[1]: [http://robots.thoughtbot.com/brewfile-a-gemfile-but-for-
home...](http://robots.thoughtbot.com/brewfile-a-gemfile-but-for-homebrew)

------
jongalloway2
sprout-wrap works pretty well for me: [https://github.com/pivotal-
sprout/sprout-wrap](https://github.com/pivotal-sprout/sprout-wrap)

------
aalbertson
this is pretty awesome. Definitely some tools in here I'd not heard of before
and will help get a nice clean mac. Definitely playing with this more!

------
jokoon
in the end any hacker will end up realizing he should have used everything by
default and not tinker too much.

------
jfmercer
This is magnificent. Thank you.

------
alphadevx
If you are a hacker would you be running a Mac? I'll stick to Linux and OSS,
thanks.

~~~
72deluxe
Why? Did you know that you can write code under Mac OSX too?

~~~
alphadevx
Hacker ethos to me is supposed to be about free computing, sharing, open
sourcing you code, building communities etc. Closed source platforms like OSX
and Windows are in conflict with that ethos in my opinion. Nothing to do with
writing code, more to do with sharing it.

~~~
72deluxe
Ah OK that makes sense. I suppose there is an argument about how open the
hardware you build on is (do you have access to Intel's CPU designs? etc.),
but that's another argument...

I would be careful dismissing all users of OSX/Windows as not hackers though.
I make my living writing software for both (it means I can eat if I don't
share my code), and also use Linux outside work; does this make me not a
hacker when I write under OSX?

Regarding communities, there also appears to be rather significantly large
communities associated with both Windows and OSX development platforms. It
would be naive to believe otherwise.

------
jug5
Step 1. Install linux

~~~
morganvachon
I get the joke, and it was the first thing that popped in my head too. But in
all seriousness, OS X is Unix as well, and can do pretty much any Unix based
task that GNU/Linux can. Sometimes the best tool for the job is the one you
already own.

~~~
davidw
Have the Mac folks got focus-follows-mouse yet?

[http://steve-yegge.blogspot.it/2008/04/settling-osx-focus-
fo...](http://steve-yegge.blogspot.it/2008/04/settling-osx-focus-follows-
mouse-debate.html)

In general, I don't think I'd ever give up Linux. It's a hacker's OS, by and
for hackers. Being able to pick apart and fiddle with any portion of, from the
kernel on up, is a wonderful, empowering feeling, and something that has
proved useful both personally and professionally over the years.

~~~
morganvachon
Indeed, when I'm on GNU/Linux I always set the WM to focus-follows-mouse,
click-to-raise. But strictly speaking, that's an X11 thing, not a
Mac/BSD/Unix/Linux thing.

I didn't mean any slight against GNU/Linux; I use it every day (and I don't
mean on a phone or tablet either). But I also have used Macs for stuff that
works better on a Mac, and Windows for stuff that works better on Windows.
There isn't a "Best OS" period, because every use case is different. There's
only "best for the job at hand".

------
no_future
So basically this is just a guide on how to use Homebrew? I see nothing time-
saving or "hacker" about this.

------
LowDog
This is interesting given that OS X is anything but a hacker's paradise. The
platform is very locked down, discourages tinkering and customization, and
given how expensive Apple hardware is, this is the least accessible and most
exclusive out of the three main players. Even worse is when developers make it
the leading platform for their software, like in the case of Atom, where the
Windows support is awful given that they started out focusing on OS X.

I'm guessing it takes a lot of work to create and maintain things like
homebrew in order to make the OS X experience more palatable, but why not just
use your Linux flavor of choice and cut to the chase? I used to use OS X and I
loved homebrew, but it feels like it's cut off from the rest of the operation
system, which has often caused me a lot of headaches in the past.

~~~
tptacek
I'm confused by the idea that a platform with a published kernel development
kit could be considered "locked down, discouraging tinkering".

~~~
habitue
The kernel is open source, how about everything else? To act like is OSX is
open because Darwin is open source is pretty disingenuous.

~~~
72deluxe
True, but why does it need to be open anyway? The windows development industry
has done well without being OSS, no?

Perhaps people should stop expecting OSX to be Linux. In the same way that
nobody expects Linux to be OSX.

~~~
habitue
I definitely don't expect Windows or OS X to turn into Linux. I think they
each have advantages for the people who are using them. The grandparent was
talking about hackability, and I was saying I don't think OS X counts as
hackable just because the kernel is open source. There is a lot more that's
closed source surrounding that kernel that makes it OS X.

~~~
72deluxe
Ah understood. Thanks!

