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.
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.
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!
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."
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.
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?
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).
> 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.
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.
Took me a moment to realize what you were talking about then visions of my game boot disks came flooding back. They're probably still in my parents' computer desk.
Huawei even builds this nonsense into the OS! The Mate 2 (which is neat because I get 30+hours battery) has this stupid easy-to-hit button on the app switch page that terminates everything. Despite my usage never going below a GB free, it gleefully proclaims "XXX MB freed!" Well shit, I can go buy a 1GB SODIMM and leave it on my desk and always have 1GB free.
"Automatic"? Or do you mean an application that makes killing tasks fewer taps?
Because the latter isn't that bad ... I have apps misbehave about twice a week; chrome, skype, yelp, google voice - they all need an occasional fresh start - a convenient way to do that I don't understand the objections against.
"Haxies are a source of controversy among Macintosh software developers. Because haxies make changes to Mac OS X that Apple did not intend, they complicate the operating environment for other developers' applications, and are frequently the cause of system instability and unexpected crashes.[1] Applications by Bare Bones software display a dialog after crashing (or are force quit by the user) if haxies are detected on the system. The Omni Group routinely asks users to remove Application Enhancer modules before contacting customer support for help with their applications.
According to a post by an Apple employee on an Apple mailing list, Apple ignores all crash reports submitted by users if they show that APE is installed."
"Reports abound regarding users suffering from a “blue screen” after upgrading to Leopard: they upgrade, reboot, and get stuck at a blank blue screen.
But, as far as I can tell, there is no mystery involved. There is one and only one known cause for this problem: old versions of Unsanity’s Application Enhancer, a.k.a. APE. Versions 2.0.2 and 2.0.3 of APE are apparently inert but harmless on Leopard. But at least some, if not all, versions of APE preceding version 2.0.2 are incompatible, and will render the system unbootable if left in place during an upgrade."
I think one of the things that the author forgot to mention is that you don't have to install these as `sudo` basically, homebrew does that already but with other things there no really need for it. As of the FOSS/Linux stuff you are seeing, these aren't random files, these are mac apps see: https://github.com/caskroom/homebrew-cask
That's a common problem with all of these OS X setup helpers. I recall one floating around with a big batch of defaults settings, many of which I would never use.
That said, these projects are useful for showing off strategies for others to adopt. I treat them much like someone's heavily customized emacs or vim setups: a good reference for ideas, but only ever to be cherry picked into my own setup, and only after I understand the piece I'm picking.
It turns off hybrid sleep (where memory is written to disk when sleeping so it could eventually resume even if the battery died), as well as automatic sleep (when the lid is open). These are things I turn off 100% of the time on all of my machines.
I'm a bit dubious about the display dimming thing - I'll probably leave that on in my fork of this script.
As for Automatic Termination, I need to read more about that before I turn it _on_, not before I turn it off. :)
I agree, I seriously don't understand why anyone would ever want to run this script. Getting 8+ hours of battery life is the entire reason I use a Macbook.
That's a little hyperbolic. Sure, that script stops your Mac from automatically going to sleep, but it's not like it changes the CPU usage or power usage (and it will still sleep when you close the lid).
Most of the settings in that script appear to be disabling automatic or "smart" things that average users don't want to think about and power users want done a specific way (e.g. backups, screenshots). Basically if you read that script and don't understand what it's doing then you shouldn't be running it.
Actually, I was going to check if those commands changed the lid-closed behavior and edit the post, but guess they don't.
Still, it does turn off display dimming and automatic termination - those can both affect the leaving laptop on a table unplugged case, one much more than the other.
You're missing the rather well placed claim that people should not run the script blindly but indeed read the comments of the script, and only use the parts that they want to. This is an Administrators' script - most admins worth their salt read the scripts they're about to run, especially if bold claims are being made about their efficacy.
There are lots of great things to learn in the settings being tweaked in this script ..
Completely agree, you should definitely closely inspect any script you run, before running it. These settings have been working well for me, but I may tweak them in the future.
I agree with you 100%. I bought a new mac book pro 2 weeks ago and it took me about 2 hours to get up and running.
Because OS X is linux based (BSD but the difference is not relevant here), a lot already exists to make these kind of things work out of the box.
Personally, I need two things to have my setup working:
- Homebrew (OS X only but it's a given to anyone used to ruby)
- dotfiles
My dotfiles are on github and git can be installed via homebrew. I am using vim so my setup depend on both homebrew (git) & dotfiles (settings/plugins).
I have no idea why I would need anything more than that to get started. But this is personal, your company needs may be different. But don't think you need some kind of automation, linux has powerful tools. Use them.
Oh dear...
Its not even BSD-based...
Its Mach based(http://en.wikipedia.org/wiki/Mach_(kernel)) with a BSD userland. (Read BSD-API). So its "BSD-based" in the same way as Windows is Posix-based (as it too can have a Posix userland API).
I always got the feeling that installing Homebrew and running the associated apps that run under X but not natively under Quartz was a broken way to get apps on Mac OSX (unless it runs under Quartz now...?)
It feels like the "dirtying" of the native system in the same way that installing cygwin and a mingw and GNUWin32 on Windows does, just in order to get it more like Windows. Rather, I'd use the native utilities on the system and native compilers.
Is it just me who feels this way? Does any Linux user feel compelled to install Linux and then run software ONLY under Wine?
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.
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.)
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. :)
- What I said in my previous comment in no way applies to programming languages. It applies to my programming environment. I very much enjoy using different kinds of languages. (There are definitely some that I dislike and stay away from though.)
- I do not think I've found the perfect anything or "the one right answer." I continue to improve my setup. I have spent more years in Windows than in Linux, so I am aware of what I'm missing in that regard. My tactic is not to remain static; it is to iteratively improve. So far, it has lead me deeper and deeper into the terminal. (My next big task is migrating email into the console. It is a task so daunting and terrifying that I've procrastinated on it for years.)
- I very strongly disagree with your disconnect between annoyance and efficiency. If I'm getting annoyed, then my emotional state is an impediment to focusing and working productively. Drudgery is annoying and frustrating and error prone. I don't really swear by any particular config as some Universal Truth, but I do have strong opinions about what works well for me. And I will spend an exuberant amount of time fixing it, especially if there is an engineering challenge involved (because, why not, we're hackers and it's fun to do that stuff). If the only thing you think you gained is "saving a few key strokes," then I agree that it probably isn't a useful tweak in most cases. What I gain by tweaking is compartmentalization and automation, and they usually pay for themselves in due time.
- Haha yes, I'm not quite old yet, but I've been at it for over a decade at this point. So not exactly a fresh lamb either. :-)
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.)
I take the strategy that I will customize and learn tools that are free to use and deploy anywhere. That way I can effectively work in any environment that doesn't dictate 100% of the terms.
That said, I've only being through 2 applicable jobs, so whether long term this is a good strategy, I dunno.
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.
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!?
I prefer Homebrew over Macports, because the Homebrew default is to use the stuff your system already has. Macports always wants to pull in (newer versions) a bunch of stuff that's already in OSX.
There's benefits to both approaches. However, I really only need a few extras on my OSX laptop, and I don't really want to end up compiling dozens of extra stuff just to get the latest version. Sometimes I want to force that new version, but only if there's specific functionality I'm after. Others really want to get the latest and greatest of everything constantly...
I like Macports a lot more. I've never had an issue with any of the packages really besides a few esoteric ones that failed to build or hadn't been updated in a while (and they are usually easy to by updating the portfile). I prefer the segregated environment of macports too, you won't overwrite any system stuff. I got the impression that homebrew wasn't a terribly well thought out tool and was a bit lazy. There's a lot of 'github' culture there which I'm wary of (and by github culture I mean half finished stuff and fancy looking projects lacking rigor). Case in point, it annoys me that their slogan is 'the missing package manager for OSX'. Macports had been around long before they were. I only sometimes wish that Macports had better binary package support.
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.
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.
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.
> On a Mac, there is no system-blessed pacakage manager ...
Which is one very big reason why commandeering /usr/local for a single package manager is inappropriate; it means that your 3rd-party package manager cannot share the system with any other 3rd-party package manager.
To re-iterate -- the BSD team, who maintained hier(7), very intentionally didn't put MacPorts in /usr/local.
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.
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.
Can I ask what you use your package manager for? My experience on the Mac is that it's mostly used by developers that want to install a package and don't want to have to manually install the 30 other dependencies by hand. For that use case, installing the dependencies along side the module that you actually wanted seems like an eminently reasonable thing to do, and certainly in my case it's pretty much exactly what I want from a package manager on the Mac. I assume if it bugs you that you have a different use case from mine. I would be interested to hear what it is (have I been missing opportunities on my Mac all this time???)
Nope, I'm a Macports guy as well, never had any serious problems with it. I wish it was possible to run both though because there are packages exclusive to either that I would like to run.
I use MacPorts. I tried Homebrew about a year ago, it worked fine, but I could not see the benefit. The current MacPorts is pretty up to date, at least for my needs. Pretty trouble free…
I stopped using Macports for two reasons. First, it was taking a long time for some of the ports to get up to date. That doesn't seem to be a problem now, but it was. The second reason is that it insists on using its own versions of tools that OS X already has. I'd prefer not to install new versions if I don't have to. I understand their reasoning, but that's why I don't use Macports.
I think homebrew is much easier to contribute to. I started using it when I wanted something that neither Macports nor homebrew had at the time, and it was very simple to add it to homebrew. It seems like things are generally more up to date and comprehensive in homebrew, and I think it's because of how easy it is to add things.
I would think you can't find recent Macports complaints because nobody uses Macports. I didn't even realize it was still being updated at all. I stopped using it many years ago because it was frequently long out of date and broke in ways that I found impossible to fix without wiping everything and starting over.
I switched to Fink, which broke occasionally but I was usually able to rescue it without too much hassle.
Eventually I stopped using Fink maybe a year (or two?) ago in favor of homebrew, and have not had any serious problems since. brew's structure combined with 'brew doctor' and a vast and frequently-updated array of available packages seem to have done a pretty good job of avoiding the "can't get there from here" problems I had with fink and macports.
Huh. I had no idea. I've been using MacPorts for what must be a decade, or close to it. Tried Fink a few times, never had any luck -- but never had a reason to find anything new (brew). I guess the Ports versions of everything I use are "good enough". If it ain't broke, and all that.
I am absolutely no kind of programmer but I prefer to compile from source on my own, when I can. For example, the first thing I did yesterday after clean installing Yosemite Beta 4 was to compile Scrypt.
For example, I like running the latest version of Vim (OS X is often behind). Compiling from the source, I can control what the binary is named (to avoid a name collision with the built in Vim), I can control the features (--with-features), and I can have it install to a directory of my choosing (~/Applications, where I also have scrypt install).I also install Lame and FLAC this way.
I don't use either. I build my stuff manually, and that way I also contribute upstream if there is a problem with some software not building on Mac OS X out of the box.
Macports was perhaps necessary a while back, when most people didn't realize Mac OS X was just another BSD based UNIX. Now that the word is out, most software builds without a hitch.
And honestly if you can't download a source tar archive and compile it yourself with your own customizations, then don't call yourself a hacker.
Homebrew was new 5 years ago when a whole new generation of Mac-using front end developers discovered the command-line (and git, and tmux…). MacPorts worked perfectly well but hey! how can an old tcl-based, svn-using package manager compete with a new ruby-based package manager that's on GitHub?
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.
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.
I use a macbook for the battery life and the no-hassle experience (which is getting worse everyday, but that's a different discussion). Homebrew works against these two principles in multiple ways. Compiling software takes massive amounts of time; if I need to install something I want it now, dammit. In principle, there are some binary packages too, but when I tried homebrew there were not for anything that I needed.
Apart from time, compiling software consumes energy, decreasing the autonomy of my laptop.
But those are not the main reasons I dislike homebrew so much. My main gripe is that the packages are of extremely poor quality. When I needed something, it was not compiled with the options I needed. E.g. packages were missing DTrace integration, QEMU was missing the one target I cared about etc.
I am a Go developer; you have no idea how many problems people have had with the homebrew package. It is garbage. And Go is quite trivial to package compared to other stuff. I simply gave up on helping anyone reporting a problem if he is using homebrew. I ask them to recompile Go from official source first.
And then there's the whole curl into bash things, gah I'll just stop now.
The biggest advantage of pkgsrc (apart from quality binary packages) is that I can use the same package versions, compiled exactly the same (to the extent possible) on OS X, Linux, and Solaris; and these are production-ready releases used in production by Joyent (and others) vetted by actual release engineers.
And with pkgsrc it is trivial to install from source when you need to modify a package locally (unlike, say, with apt).
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.
> It is also a whole C program and Homebrew is just ruby scripts.
And that's a problem?
I would argue that it's a feature. Due to Homebrew being written in Ruby, it has easily allowed over 4,000 contributors [1]. Recipes are easy to read and inspect for verification purposes.
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.
(On a sidenote, I got into Arch because I heard hype, but did not even like it until I recognized the BSD outlook, with ports and pkgsrc style tools. This is very cool, and now I know what to use if I deal with OSX again!)
> 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.
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.
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.
Huh, I'm not sure why you say it takes "hours", it takes about 15 minutes for me to download it on a 50Mbps and that's not exactly fast.
When you get a new machine, at most you'll be one or two point updates down, and you can just use a combo updater, again, about 15 minutes to download, another 15 minutes to update.
Every one has their own dotfiles set up but I have a script that pulls my dotfiles, installs every package in a Brewfile, and while that's going on, I can set up my mail by just switching on iCloud in System Preferences.
So for me, when someone says it takes days, I don't know what to tell them. You must have really slow download speeds for it to take days. I can get started in a day, less than 4 hours total to get set up. 'days' is a BIG overstatement.
> Huh, I'm not sure why you say it takes "hours"
Because it took me hours. I don't understand, I'm telling my anecdote and people seem to be saying it's wrong.
Just because it takes you 15 minutes doesn't mean it takes me or everyone else 15 minutes.
It took me days to be happy with my dev environment.
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/
Boxen always seemed pretty heavy-handed to me for a single developer as opposed to an IT team managing workstations for a team of developers. Is this not the case? A dotfiles repository always seemed like enough to me.
On windows I'm forced to do some nasty tricks (i.e.: reloading the script with admin user, and if any exception happens I output the stacktrace on a tkinter textarea, since the terminal is not available anymore)
(to actually install software, I use chocolatey, but it's really hit and miss...)
Windows Management Framework 5.0 Preview [1] contains early versions of Microsoft's OneGet and PowerShellGet.
OneGet can install applications from repositories, using any number of providers. The preview version comes with a version of Chocolatey [2] built in managed code (C#) instead of PowerShell, but it supports the same Chocolatey gallery (a repository of software packages) and protocol.
PowerShellGet [3] can install PowerShell modules (e.g. make new Cmdlets available on the PowerShell command line). The modules can be delivered as scripts or as compiled .NET assemblies. By default PowerShellGet is configured to use a (closed preview) repository [4], which makes it not very usable, but it's interesting to know what direction it is headed.
As a more practical alternative to PowerShellGet, have a look at PSGet [4], a PowerShell module for installing PowerShell modules, with its own dedicated repository. Hopefully Microsoft's PowerShellGet will support PSGet as a provider in the future as well, the names are certainly confusing.
Desired State Configuration (DSC) [6] is a new (Windows 8.1) capability to configure Windows using a declarative syntax extension of PowerShell v4. It can set registry keys, create files and directories, enable Windows Features, and more. DSC 'resources' are PowerShell modules, so DSC's capabilities can be extended, see this GitHub repository [5] for examples.
Alternatively, have a look at Boxstarter [7]. It can do installation and configuration, and you can host your 'starter script' online and launch it with a single command. Boxstarter will take care of all Windows restarts that might be necessary along the way.
Be aware that, although most modern package solutions for Windows are using NuGet as a packaging format, using NuGet.exe directly (the application) and with nuget.org (the website) is meant for managing software development dependencies, not installing/updating end-user applications or command-line utilities.
A taskbar like Windows is useful to know what are your alt-tab targets, of if you need to open a new app. But good idea, I'm going to try the empty dock.
I use the empty dock too - well, nearly. I have emacs, terminal and browser on there permanently, for quick access to my 3 most-used programs. For quick access to everything else, I've got a shortcut to the Applications folder too. (Sort by Name, Display as Stack, View Content as Automatic.) To reduce clutter, you could alternatively make yourself a ~Applications folder with a reduced set of shortcuts in it, and add a shortcut to that instead.
I'm certain OS X was set up this way when I first got my computer, but I've used some people's Macs and they don't have it. So... maybe it wasn't? But anyway, default or not, it works well.
Thanks for linking to this, I just picked up a copy. I switched to a MBP retina two months ago, and have made an effort to keep it fairly vanilla and figure out how to do things in OS X... without diving into OSXvsWIN, let's just say I'm super glad to have found this add on. It'd be even better if it updated to mimic Windows 8's taskbar (popup previews of windows, mostly), but I'll take what I can get for now. Easily worth the $20 it normally sells for to me, but I could only pay the $10 sale price. Sold!
On one hand, I feel so much more aware of what's currently running on my computer, but on the other hand, I feel a bit like the kid I mocked in the 2000s who would move his Windows task bar to the top of his screen because he missed using his Mac.
You might also be interested in Witch [0] which lets you switch between windows of different apps as opposed to only switching between single apps or between windows of a single app.
I love Witch, but after upgrading to Mavericks I found that it was weirdly sluggish and tended to overshoot what I was aiming at. It also doesn't function with a lot of fullscreen apps (primarily games) and iBooks does ridiculous stuff with its windows that no app switcher seems to know how to work around. All that said, I'm still glad I bought it and I end up switching back and forth to the default app switcher because it's so much better in every way but those bugs. I'm sure the iBooks thing will get resolved and I think the sluggishness thing is eventually going to get cleared up in patch.
Years ago I thought DragThing (http://www.dragthing.com/) was the coolest thing around. I went around making all sorts of clicky things to litter my desktop with. It's apparently still developed though I don't think I've seen any screenshots of it from this decade, so it might be wishful thinking that it would've kept up with OS X UI styling. uBar looks interesting though and it's nice to see people working on this kind of tool.
I think the developer spends more time working on PCalc, and even then, I think the iOS version gets the most attention.
I last used DragThing back in the OS 9 days. With the OS X dock, it didn't seem as necessary. Couple that with LaunchBar (or Alfred/Quicksilver) and I have basically my launch needs met.
Assuming you have uBar installed, is there anything about it that makes it feel like an add-on? Or does it feel like it's really a part of the desktop environment? (I'm not talking about design aesthetic or anything like that, just wondering if it gets wonky sometimes)
Hi there, I'm the developer of uBar:) uBar is made to totally feel like part of the system. Please feel free to check out the 4 week trial, and take advantage of the The Talk Show coupon! And if you have any suggestions or feedback, you can send them via Twitter or email using the Send Feedback item in the uBar menu. Just see the release notes to see how much user feedback gets incorporated into updates:) Regards, Edward
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.
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.
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.
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.
I think the parent poster is talking about eliminating all known-vulnerable bash shells from his machine, not just having the default user shell change.
That should be #!/usr/bin/env bash, particularly for BSD which does not install bash in /bin. Nothing new about absolute executable paths being non-portable, #!/bin/bash is as bad as #!/usr/bin/python.
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.
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
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.
> 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. ;)
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!
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.
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.
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?
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.
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...
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) ?
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.
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.
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?
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.
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.
For me there was a time where I wanted stuff to just work, to get good battery life on my laptop and still have a Unix. I went Mac OS X for a few years (X years ago).
A few years later I switched back to Linux. Much better Java support. Better window manager. Multiple desktops (yes, I had something like that on the Mac, but it was weird). Much better file manager. Much faster (than either Windows or Mac OS).
I still love Apple hardware and their attention to detail regarding battery life, but you can pry my Gnome, I mean MATE, desktop from my cold dead hands. And Linux Mint at least has the Windows battery life (seems to be the only distro that does), so that's kind of ok.
Macs have by far the best build quality for the price, with great displays and hardware as well. They can run most all of the dev tools that you can run on Linux(yeah there is always going to be that one person yelling about X specific thing that doesn't work as it should).
Recently I'm doing iOS dev and you have to use a Mac unless you plan on emulating. iOS strikes me as a platform that so-called hackers would like, seeing as how mobile is a fairly new frontier with unique and undiscovered uses, and Apple is always putting out new iPhones with interesting new hardware and APIs, unlike boring old CRUD webapps and desktop apps which have been stale for years. I was just blown away this week with the amount of insane stuff you can do using GPU hardware acceleration on the newer (5+) iPhones, its like everyone is carrying these little powerhouses around in their pockets. Though I guess you could also say that the closedness of the platform and ecosystem would be repellent to hackers, I personally don't get my panties in a bunch about this, I just like making cool stuff.
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.
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.
Good hardware, consistent experience, lots of development tools. I moved from Linux to Mac simply because it lets me focus on work and less on fiddling around.
I would obviously have liked to use a completely open OS as well, but it's not like there's a lack of community on OS X.
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.
The biggest problem I had with Mac OS X was it's user space unix tools. Everything GNU is ancient from before GPL3, everything BSD is crazy ancient from FreeBSD 5.. it's pretty awful.
Thus why macports for me was king. HomeBrew tried to hard to not replace your user space, though I haven't looked at it in a long while. I'm on Linux everywhere now.
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.
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".
As the other commenter stated, it's an X11 thing. Despite the prevalence of applications that run under X11 and the XQuartz availability, the native UI under OSX is Quartz which handles everything under OpenGL I believe....?
iOS may be Unix underneath, but on the top it has a terrible WM that simply cannot be changed to behave like anyhting else. I'm using xmonad and while I may come off as pretentious, I do see that my colleagues that use mac constantly fight against the WM, searching for windows, moving them around, resizing etc.
That's a larger problem I have with the Mac (and Windows, although less so) platform as a developer environment: all the cool tools are closed-source and paid. That's a serious barrier to innovation.
"Cool tools"? Needing ext#fs write support on OS X is a pretty niche application and I'm honestly surprised it's continued to be a viable business for Paragon all these years, especially with the rise of mainstream virtualization. I wasn't expecting to find them still selling it at all.
It probably wouldn't be there except I'm sure most of the expertise and code had to be developed for their imaging and partitioning products.
I think the only things I run frequently for development that don't come with OS X and aren't free or open source are Sublime Text and Paw. You can certainly use vim/emacs/TM2 and curl scripts if you want.
Were I using Linux, I'd be using Sublime Text, and, well, curl scripts again. I'd also be jumping off a cliff after about two days of dealing with desktop Linux's horrific regressions over the past decade.
OS X's native development tools (Xcode, llvm/clang) are free, and most of the tools you use in Linux are either already there, or a "brew install" away.
I've never gotten CPAN to work reliably with any OS's included copy of Perl. As with Python and Ruby, if you want to use things not available via the OS's package manager, you're best off installing a separate copy.
So, I've satisfied your request, "Try using cpan to install basic modules like MySQL". I guess that means you admit OS X "can do pretty much any Unix based task that GNU/Linux can"?
BSD differs from Linux in some important ways. If one of those differences affect your works, than Mac OS X is useless, even if it is Unix (and Linux, some would say, isn't)
I get that, and I wasn't trying to say that GNU/Linux is Unix, either. In fact, what with systemd on most major distros these days, GNU/Linux is less Unix-y than ever (I'm not saying that's good or bad; I have my reservations about systemd but they are irrelevant to this discussion and I'm not being biased either way about it here).
That said, for just about any project I've ever worked on within a GNU/Linux ecosystem, I could have easily adapted it to Mac if that was my chosen platform. HTML is HTML, JavaScript is JavaScript, so for today's web-centric projects the OS you're running doesn't matter as much. Even languages like Python don't really care what's under the hood.
Of course, if you're doing Linux kernel development, or targeting a GNU/Linux deployment, then a Mac isn't the best idea. :)
"Useless" a strong word for a simple difference between two Unices that affects your work. You could just as well say Linux is useless because sysvinit and upstart aren't the same as launchd.
The UX is amazing if you ignore gnome/kde etc, which are just imitations of windows and mac. I'd say the true linux UX is in tiling window managers. Just like the terminal and vim/emacs, tiling WMs have a steep learning curve and an amazing payoff where the computer becomes an extension of your will, rather than something you fight. I really recommend you try them.
That being said, they don't look pretty, but they make me so productive I just can't go back to anything else.
I disagree that tiling WMs necessarily have a steep learning curve. From experience I claim: Anybody can learn to use a WM like xmonad in its stock configuration in about 30 minutes, and be proficient enough to have a significant boost in productivity in a day or two.
You're right that it's not necessarily steep if you're used to using keyboard commands. But if you're used to doing everything with a mouse it might take some adjusting
It's just, look at all this fighting you have to do to get linux tools on your mac. It's not a hacker OS by default, it's a pretty, user-friendly OS by default, and you can use homebrew and these other tools to replicate many of the features you'd get on the actual hacker OS: linux. Unless you're developing for Mac, I just don't get why it's so popular with developers.
(OK, that's not true, I get it. It's very cool looking. But I'd think more developers would get past that and see how hard they're working to turn their cool looking OS into a poor linux imitation).
It's popular because it's Unixy without all the bullshit. I stopped running desktop Linux/FreeBSD years ago because the UI and system management tools in that world were such a clusterfuck. Now I can run commercial applications and not have to deal with all that configuration file nonsense.
Honestly, it's quite insulting when you presume that people who use OS X haven't considered the alternatives, or are unfamiliar with Linux.
Why try to get Linux tools on your Mac in the first place? You don't see guys fighting to get Mac tools on Linux, so why does it happen the other way around? Perhaps they picked the wrong hardware and OS?
I don't understand what you mean by "hacker OS" though? If you mean an OS that I can write code on, all mainstream OSes apply. If you mean an OS that I can constantly fight to get hardware working on and where the windowing paradigm shifts according to the whims of the incoming teenage developers (see the CADT model), then OSX doesn't fit in. (I use Linux, just not any recent WM thanks).
But I agree with you otherwise; not trying to pick a fight.
It worked pretty well on my macbook air once I figured out the marvell ata errors (the sata controller behaves poorly) and the backlight (magical recompilation every boot on a new kernel with dkms solved it).
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.
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.
> why not just use your Linux flavor of choice and cut to the chase
Because desktop Linux is simply not sufficient for me as a daily driver. It is unpleasant to me, it's highly frictional and there are a thousand shitty cuts everywhere that you have to endure for the legitimately good development environments you can get there. I am a software developer but I'm a person first and as a person Linux-on-the-desktop doesn't work for me. Quality matters to me, and OS X's user experience is qualitatively better for my use case.
If OS X didn't exist, I'd still be using Windows and SSHing everywhere. But OS X is a happy combination of the tools I want to use (including ones that don't exist on Linux--I use TextMate 2, for example, because I'm not a big fan of Sublime Text) and a desktop environment that doesn't make me endure it rather than enjoy it.
(And as for expense: if you've got a job as a software developer in the developed world, you can afford Mac gear. If you can't, that sucks, but frankly I'm gonna still use the best tools for my job.)
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.