Hacker News new | comments | ask | show | jobs | submit login
~/.osx updated — sensible hacker defaults for OS X Mountain Lion (github.com)
169 points by mathias on July 28, 2012 | hide | past | web | favorite | 90 comments



As with any dotfile repo, I wouldn't recommend installing the entire thing at once. Instead, try and take the time to read through it and select settings that you want piecemeal. You'll end up knowing what everything does, especially in the case that something strange happens and you want to tweak things.

Edit: I should note that I learned this the hard way starting out, I went backwards by ripping out things that didn't work for me/did not like, but not until after making some horrible mistakes!


As the author of this dotfiles repository, I completely agree. These are my settings, and I’m sure not everyone will like this configuration. The idea is that automating all these OS X preferences (hidden or not) can save you a lot of time if you need to set up new accounts for yourself on a regular basis.

TL;DR This repository is meant to be forked, not used as-is.


For example, dont use this AS-IS unless you want to make the scrollbar visible all the time.


This isn't "sensible hacker defaults", it's more like "some guy's view of what Mac OS X should be like".


Unilaterally resetting the scroll direction to the 10.6 standard is insanely presumptuous.


So was unilaterally setting it to the 10.7 standard. I think we should have the script flip a coin so people are annoyed evenly.


It's not arbitrary though. The point was to move away from the metaphor of moving the window around a document to just manipulating the document directly as you do in iOS. Granted it's not as obviously the right thing when touch is not involved, but it is the right thing.


Why did no one notice the supposed wrong behavior in 10.6? No one is fingering their OS X displays.


You've answered your own question.

The last time someone really thought about scroll direction was when they invented the scroll wheel. The implementors associated it with the motion of the position indicator in the scrollbar rather than the motion of the document. The reason this is wrong is because it's an unnecessary indirection from the document itself. At the time computers could not documents quickly enough to have any kind of physicality, so the scrollbar + indicator were critical UI elements simply for performance reasons (ie. the scrollbar is what could be drawn fast enough to enable responsive dragging, and the window wouldn't redraw til you let go). Once people got used to it, there was no reason to question it until the modernization of touch interfaces where suddenly the inconsistency became apparent.


While it may be wrong in theory, changing it meant that all muscle memory developed by users thus far was thrown out of whack.

What was the gain for disorienting the users by introducing a new default? An improvement in acceptance by users who had only used tablets and phones but never PC's? Is that a large set?


Consistency. It takes a few days to get used to then you have consistency across the Apple platform for the rest of time.


As far back as 10.3 on my iBook, I had the scroll direction reversed, with a utility that also enabled two finger scrolling on the trackpad.

The "standard" way of doing it never made sense to me, even with a mouse scroll wheel. I scrolled down and the page would go up--how did that ever makes sense?


It made sense when the only thing that would animate in real time was the little position indicator in the scrollbar.


I has messing around with it, and had another application reverse it for just the mouse, and then it got reset or something, and now I don't know which way is the correct way. I think there's a triple negative in the settings. I flipped it again, thinking it was backwards, but not it still feels backwards. Nothing is right anymore. I'll just set it to whatever windows has it, so it's the same when I boot into that.


I much prefer natural scrolling, but the 10.6 standard has the same thing going for it as vim: it works everywhere. I gave up trying to reverse the scrolling in Windows with AutoHotkey, it was a mess. :(


WizMouse has been working quite well for me on Windows.


Does it handle horizontal scrolling with the trackpad? That was the straw that broke the camel's back for me.


Well, yes - it is a superset of all the little tweaks that experienced and demanding users have found useful at one time or another. Clearly, you shouldn't be applying the whole file all at once before deciding what it is in there that you need or prefer.

Have a look at it - there really is some good stuff in there. This file, and then all the cool tweaks to the Cocoa text engine that you can make, make OS X a tough OS/environment to beat.


> Well, yes - it is a superset of all the little tweaks that experienced and demanding users have found useful at one time or another.

Eh, a lot of it is just some guy's arbitrary preferences, with little or nothing to do with "experienced or demanding users". Stuff like hiding the bookmarks bar in Safari or showing track notifications in the Dock is experience neutral.

Other than that, there's a few nice tweaks (like unhiding ~/Library), and the occasional disastrous idea (killing the executable quarantine).


Eh, a lot of it is just some guy's arbitrary preferences, with little or nothing to do with "experienced or demanding users". Stuff like hiding the bookmarks bar in Safari or showing track notifications in the Dock is experience neutral.

Completely agree - but someone has to keep this compendium somewhere, and why not keep it as a piece of working code, rather than as a web page or something? If you end up having to use a lot of different Macs and have to set up new accounts for yourself on a regular basis, what you'd probably do is fork the project here, eliminate the stuff you hate, and then that's your acceptable-mac-environment-maker script.

occasional disastrous idea (killing the executable quarantine).

Out of curiosity, why is this disastrous? I'm not a fan of the idea, but I can imagine how someone might come to hate com.apple.finder.quarantine badly enough to do this? Maybe this particular tweak should be commented out by default, though.


> Completely agree - but someone has to keep this compendium somewhere, and why not keep it as a piece of working code, rather than as a web page or something?

I think this would make sense if it was a compendium, but this is an arbitrary subset of everything you could possibly set via defaults, with no rhyme nor reason to what is and isn't in the list other than "this particular guy cares about these particular things".

> Out of curiosity, why is this disastrous? I'm not a fan of the idea, but I can imagine how someone might come to hate com.apple.finder.quarantine badly enough to do this?

I can imagine being annoyed at any number of things, but that doesn't mean turning them off is a good idea.

Security is all about layers, and disabling an important layer (and especially a layer you'll rarely trip over once you have all your commonly used apps downloaded) doesn't strike me as a bright idea. It only takes one bug in your browser of choice to con it into launching an arbitrary executable, or one asleep at the wheel moment to trick you into double-clicking a cleverly icon'd malicious app; the quarantine is your mitigation against such events.


Not when you confirm the dialog over and over to the point of being conditioned to it - when confirmation becomes an automatic response on the users part, it's no longer serving them.


But it's not. At least, I only see that after a reinstall, or maybe once a month, when I want to install something cool and new.


I see it all the time with documents.


fredsted's point is that it is not that. It's largely one person's personal preferences. I agree there's some good stuff in there, but there's also a lot I wouldn't like. I don't think it's a superset, just a set.


But how else would you describe a superset? I hate the glass dock and have hated it since 10.5 when it was introduced. You might like it and you'll stick with the default behaviour. For me it's a useful tweak. For you, you can live without it. It's not a superset of preferences - it's a superset of tweaks. Some of them you won't like, some of them are quite nice and this is a good place to find them all.

Or did you mean that you know of a whole bunch of other tweaks that should be on the list? If so, add them and send a pull-request.


There are many legal options one can change with the defaults command. Not all of them are present. Hence, it is not a superset of all configurations. Rather, it represents one person's preferences.


Thank you for sharing. Sorry you triggered an avalanche of whining from the "ugh. This free stuff isn't exactly how I'd do it if I weren't so lazy and I actually did something" brigade.


Could not agree more. I'm not completely convinced that "sensible defaults" for a hacker necessarily means disabling animations, etc. We're really past the point with machine power where this sort of thing is necessary, and I can't understand the continued insistence on doing things like that. I really expected this list to relate to things like git settings, etc.


     defaults write com.apple.LaunchServices LSQuarantine -bool false
This is a terrible idea. If your browser, or anything else, is ever conned into downloading and opening a file, the quarantine is the difference between "what the fuck, why is an executable I've never launched before trying to launch?" and silently getting owned.


Sorry - this is total security theater.

I download almost everything from the net - how else would I install? CD? Floppy? Telling me that it's downloaded from the internet doesn't do anything to identify that it's dangerous and so I ignore the warning.

Under what circumstance would I go "whoa, maybe it's dangerous this time"???

Mac's don't have auto-install .exe files. Yet we get warning for everything from JPEGs to TXT to DMG. Ridiculous.


The point is that you might not know you had downloaded the file, or that it was executing. Imagine you're surfing the Web one day and all of a sudden this warning pops onto your screen. It would be nice to know that something downloaded from the Internet is trying to execute itself.


In principle, you shouldn't be getting warnings for any of those formats. You should only be getting one when you launch an executable - it's a warning that the file you downloaded is an executable and not some random other file you can (barring vulnerabilities) open without trust.

I don't know why it cares about the executable bit(?) in this case, though.


If you can execute code, said code could be an auto-installer.

If there's a vulnerability in the application used to open a JPEG or whatever, you can execute code.

It's less asking "is this dangerous?" and more "did you download and open this?"


If something else downloaded and opened the file, it's already owned your account, hasn't it? The horses are out of the barn at that point, right?


There are 3 steps needed to exploit this attack vector (assuming no wetware exploits):

1. Download the file. Any website can do this by design.

2. Get LaunchServices to open the file. This requires at least one vulnerability.

3. Bypass quarantine. This requires at least one additional vulnerability.


I would love to not have to disable this, but it's buggy and I've had it up to here with pointless confirmations like "README.txt is an application downloaded from the internet. Are you sure you want to open this file in TextEdit?"


That's not buggy, that's a text file with it's executable bit set, which is actually potentially dangerous.


Under what scenario is it ever unsafe to open a text document in TextEdit? Under what scenario would you ever not completely ignore that warning?

A much more likely threat is a malformed jpg or pdf designed to exploit a decoder, in which case the executable bit is completely irrelevant. Warning the user about the executable bit protects them from nothing, unless Finder is preparing to execute the file itself. It is a warning that is always ignored, and pointless warnings only make the system less secure.

And working with multiple quarantined documents exposes more bugs.

It's not a thoughtfully designed feature. If they ever fix it I would gladly reenable it.


TextEdit could have a bug in its 'guess the character encoding' code that leads to a buffer overflow, or it could have a bug handling malformed UTF-8.

Its 'guess the character encoding' code also might have a 'wait a minute, this is RTF/PDF' feature.

Of course, Apple could trust its own apps, but I think they should not (why increase the attack surface?) and that would lead to complaints "why can't I tell this OS that my text editor can be trusted?".

I also think (but have no data on it) that this "open a .txt file you downloaded" check is very rare for 'normal' users. If they download at all, it is Word documents, PDFs, movies, and applications.


Isn't TextEdit sandboxed in Lion + Mountain Lion? If so TextEdit most likely cannot execute any non signed code or open a network connection... But of course sandboxing should only be used as a last resort. I am not a security expert - can anyone comment on that?


My .txt's open with Sublime, which is not Sandboxed (or maybe is, I don't know). They can't de-quarantine .txt's because the default is to open with TextEdit!


And that bug would not be triggered by the execute bit, so an exploit would have a non-exe attack vector


Not if you're opening it in a text editor.


There's no way for LaunchServices to know, a priori, whether a given executable file's default app is going to perform a safe editing operation, or execute its contents.

Now, you could hardcode a list of "safe" apps, or add some kind of "I swear I'm safe" declaration to the app's plist, but that has its own set of problems. A one-time "this seems funky to me, are you actually intending to do this?" is a simple and safe default.


> There's no way for LaunchServices to know, a priori, whether a given executable file's default app is going to perform a safe editing operation, or execute its contents.

But in that sense an executable file isn't any different from a non-executable file, is it? The default app for the file could do equally dangerous things with a non-executable.


But the application doesn't _need_ to execute the contents for bad stuff to happen viz jpg and pdf encoder exploits.

Also, how many applications actually _execute_ (bare machine, vm's don't count) content? My guess is that few if any of the applications a user opens that isn't executed by finder itself is going to execute the file's contents.


I think they just want something to complain about and aren't actually on mac os. I've already seen a number of examples which are simply fairy tales. (Such as claiming they're being prompted when opening ordinary jpg files.)

That said, even the author notes that this is designed to be forked. It's not a script to run on one's own machine blindly, the idea being to exclude what is not to your taste/while demonstrating features which can't be changed inside the gui. (It's also very helpful if setting up multiple accounts.)


yep definitely hell banned :)


If you double click a malicious file disguised as a txt file, it won't necessarily open in a text editor.


They could just as well automatically chmod the txt/docx/html file to remove the executable bitset. Why would anyone want to have an executable txt file? If one does want it, it's pretty safe to let them reset the bit manually afterward.


> Why would anyone want to have an executable txt file?

A shell script.


I meant to exclude scripts when I said txt/docx/html and likes. I understand I wasn't clear enough, that is my fault.


Named .txt?


Surely nobody with malicious intentions would ever try to trick you.


They would do a pretty bad job of harming me by addng and extension that makes me view the source of a malware script in TextEdit instead of executing it.


Well, perhaps it is a bug. An addition to the Info.plist in the editor could say, "always safe to open this kind of file".


  jtm@socrates ~ $ cat ~/Local/bin/unquarantine
  #!/bin/sh
  for i in com.apple.metadata:kMDItemDownloadedDate \
           com.apple.metadata:kMDItemWhereFroms \
           com.apple.quarantine; do
      xattr -r -d $i "$@"
  done


I agree. It takes a second to read what you're opening and another second or less to click "Open". It should at least be commented out and if someone really needs it, they are doing it on their own accord.


See also http://secrets.blacktree.com , a database of known hidden settings that can be changed. There is also a Preference Pane available there that makes it really easy to adjust them form System Preferences.


This:

    # Finder: allow text selection in Quick Look
    defaults write com.apple.finder QLEnableTextSelection -bool true
Combined with "Use OSX Finder Quicklook (Spacebar) to preview all plain text files"[1] is pretty useful.

[1] http://news.ycombinator.com/item?id=4230594


  # Set language and text formats
  # Note: if you’re in the US, replace `EUR` with `USD`, `Centimeters` with
  # `Inches`, and `true` with `false`.
:)


This is the most important one, that's not been mentioned in OP:

    defaults write -g NSScrollAnimationEnabled -bool NO
It disables the stupid "smooth scrolling". on Lion (and everything before that) you could disable it from the 'General' tab of SysPrefs, but now it's gone.

What does it do? When you press spacebar in a web browser, or fn-downarrow in a text editor, it "smoothly" bring new content up from the bottom of the screen and pushes current screen up.

I don't know, maybe it works great on recent machines, but my poor old 2009 MBP's graphics card is not really powerful, and this animation is not smooth at all. It distracts me a lot.

I strongly suggest you at least try it. If you don't like it, just replace NO with YES and everything's back to normal.


I'm completely the opposite; having windows contents jarrigly jump down slows me down significantly as I keep having to scan to find my place. It's one thing that annoys me about vimium that there's no option to j/k scroll smoothly


I would love it too, if it wasn't 8 frames per second on my machine! I love animations, but this one is ridiculously slow on my machine...


Strange. It works fine in my early 2008 MBP.


Is there a way to change or disable the animation time when switching between spaces (or "desktops" as they are now called)?


The only way I know of is with "TotalSpaces", currently in a free beta. http://totalspaces.binaryage.com/


To my knowledge, no. But the suggestions at http://apple.stackexchange.com/questions/17929/how-can-i-dis... help a little bit.


Is it really beneficial to disable disk image verification? What does OS X actually verify when it opens a disk image? It does take some time to verify disk images and I want to be sure of what I'm actually disabling.


It's taking a CRC32 of the contents of the image and comparing it to the expected value stored in the image.

I've very occasionally run across corrupted disk images, which is what this catches.


Considering I've frequently encountered this with botched downloads of disk images from the Apple servers, this seems like something that shouldn't be disabled.

And no, it isn't my system, it's Apple's servers; only have the problem with downloads from them.


It's probably calculating a checksum of the file to check for corruption.


Great list. Stripping animations out is always appreciated.

Does anyone know how to alter / remove the animation from horizontal motion between spaces? Particularly when using the keyboard shortcuts, this whizzing is disorienting and irritating.

I assume it is not possible, given that animation seems to be keenly bound to the trackpad 'peeking' operation and all.


As mentioned above, I was happy to find TotalSpaces (http://totalspaces.binaryage.com/) which allows you to disable it completely!


Looks great. How about making home/end on external keyboards go to beginning/end of the line rather than the document?


I highly recommend this app for things like that:

http://pqrs.org/macosx/keyremap4macbook/

It does that, and many more useful things too. I have command on mac, and from a different app, control on my ubuntu machines mapped to caps lock. So wherever I am, I can use the same key combo...


That's a long list. I kind of want to run the whole thing just to see what happens...


I wouldn't run the whole script blindly. You will have to do more than one linear pass through the script to find and invert settings you later discover you don't like.

I recommend one close readthrough, uncommenting or commenting things you do or don't like, and then a full run. I do recommend running the script after a careful edit. It will save you time.


As the author of ~/.osx, I agree. Never blindly copy anyone else’s settings. Heck, never blindly copy _anything_.


I have to recommend against a lot of the items of this script. Having carefully read through it, I can say that more than half of these are not reasonable changes for hacker defaults. My tweaks are more sysctl oriented vs these, although a few can be useful, but ymmv depending on how you are accustomed to working or if you want some of the new benefits, which I find quite useful, in X.8.


There's plenty I wouldn't want. God forbid this alone:

# Trackpad: map bottom right corner to right-click


You know, when I tell people I use Linux, they usually say something like, "But don't you have to spend countless hours on pointless yak-shaving tasks just to get things to work sensibly?"


`# Group windows by application in Mission Control`

`defaults write com.apple.dock "expose-group-by-app" -bool true`

Can't believe any hackers would use this. Mountain Lion was worth $20 just for the new `false` alone.


I don't think I'd like this at all. What's the point of disabling animations, system-wide resume, not letting the OS terminate inactive apps, etc?


Animations take time and get old fast.

Terminating inactive apps doesn't work right. Often you'll try to reopen an app (such as Preview) and it's stuck: finder thinks it's already open but it's not. So you have to force close it and reopen it.

There's a lot of ideas in Lion & MLion that clearly should never have passed if there was a tasteful gatekeeper at the helm, but now everyone's a UX expert and it's a sloppy, half-baked mess of random, unchangeable preferences.


It would be great to have a script that setup your machine with all settings, is there a list of all "defaults write" commands somewhere?



Sadly, most of those are outdated. :(


> Sensible

HAHA! What?

How on Earth are these sensible

> # Disable the warning before emptying the Trash

> # Empty Trash securely by default

> # Disable the “Are you sure you want to open this application?” dialog




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: