Live data from Hacker News

~/.osx updated — sensible hacker defaults for OS X Mountain Lion

github.com

61–70 of 91 posts

Re: ~/.osx updated — sensible hacker defaults for OS X Mountain Lion

#61

Earlier quoted context omitted.

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 sa…

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.)

Re: ~/.osx updated — sensible hacker defaults for OS X Mountain Lion

#62

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...

Re: ~/.osx updated — sensible hacker defaults for OS X Mountain Lion

#63

Earlier quoted context omitted.

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

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.

Re: ~/.osx updated — sensible hacker defaults for OS X Mountain Lion

#64

Earlier quoted context omitted.

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…

> 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 thin…

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.

Re: ~/.osx updated — sensible hacker defaults for OS X Mountain Lion

#65

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

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.

Re: ~/.osx updated — sensible hacker defaults for OS X Mountain Lion

#66
post #7

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

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.

Re: ~/.osx updated — sensible hacker defaults for OS X Mountain Lion

#67
post #47
post #4

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 di…

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.

Re: ~/.osx updated — sensible hacker defaults for OS X Mountain Lion

#68
post #48

Earlier quoted context omitted.

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 tha…

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!

Re: ~/.osx updated — sensible hacker defaults for OS X Mountain Lion

#69
post #48

Earlier quoted context omitted.

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…

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 tha…

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

Re: ~/.osx updated — sensible hacker defaults for OS X Mountain Lion

#70
post #63

Earlier quoted context omitted.

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.

Named .txt?
Post reply on HN