Hacker's Guide to Setting Up Your Mac
lapwinglabs.com
lapwinglabs.com
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.
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.
If treated like science instead of voodoo, messing with your computer becomes one of those "interesting things to be learning."
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?
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.
Ubuntu has even more powerful window managing key bindings by default (on OSX I need Spectacle).
For all other things I just don't care.
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.
The biggest one in Mac OS X history I remember is haxies:
http://en.wikipedia.org/wiki/Haxie
"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."
http://daringfireball.net/2007/10/blue_in_the_face
"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."
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.
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. :)
> This script should not be run without prior examination. It's quite opinionated and intended to be modified.
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.
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.
There are lots of great things to learn in the settings being tweaked in this script ..
Just use esxi and run a hypervisor running boot mac os and what ever your production environed if you must have the mc os shiny
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
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.
Wait... what?
> (BSD but the difference is not relevant here)
Still, "Linux-based" is a funny way of saying "Unix-like". Is HP-UX also "Linux-based (System V but the difference is not relevant here)"? ;)
Linux != UNIX. BSD != OSX
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?
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 consistently look for ways to automate things. I do it not because I'm a tweaker for tweaking's sake, but because I find it insane to let myself be annoyed by tasks that I know I can automate away. (Then my brain can forget the details of the operation because it is enshrined in code and maybe even some documentation.) For me, it's an efficient way to work. Actually, that's a nice way to sum up how I work: how can I most effectively offload This Stuff I Know so I don't have to worry about it any more?
I am extremely uncomfortable on Macs or Windows machines. The solution is to just not use them. (We, as programmers, are fortunate to have some freedom here. For example, I would not take a job with someone who forced me to use OSX or Windows.)
To give you an idea of how far I'm willing to go: I wrote my own window manager. I spent years on that path. I got something working around late 2012 and haven't really touched the X11 world since. I had some really specific goals that I wanted to accomplish (support 3+ monitors correctly), and I did, and now I'm happier and more productive for it. Another plus: people using Go now have native X client libraries.
Another example: I wrote 8,000 lines of Go to download all of IMDb and load it into a relational database in under 8 minutes (including building trigram indexes on all movie, episode, tv show and actor names). And then I built a command line utility that does fuzzy search and can rename all of my media files instantly. Renaming them manually was terrible drudgery. (And I certainly enjoyed the engineering challenge of making this fast.)
Sorry for the banter. :-)
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. :-)
Thanks for indulging in some friendly banter!
And it's not a scraper. :-) Here: https://github.com/BurntSushi/goim
That said, I've only being through 2 applicable jobs, so whether long term this is a good strategy, I dunno.
[applications_to_ignore]
ack
bash
git
screen
ssh
tmux
vimI 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!?
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...
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.
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.
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.
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.
Right, that's what it's for, it's also why a 3rd party package manager shouldn't use it.
I mean, in the end it seems like almost nobody cares, but it's always been a pet peeve of mine.
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.
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.
As for bread, no, I am horrible at cooking!
I suppose I never run into this problem because I don't use the software to its full extent and therefore don't miss any features! I must be lazy.
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.
The older I get, the more I leave things alone. Swim with the current.
Me too, but I'd never discourage anyone from tinkering. Sure you might break stuff, and that's a learning opportunity.
More info here: http://saveosx.org/
It's great. It really is. I never understood why it's not used by more people. Homebrew is simply awful.
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).
Hence, trying to get such libraries installed with homebrew results in dependency hell, as the package manager won't handle those dependencies.
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.
What is the advantage of C over Ruby?
[1](https://github.com/Homebrew/homebrew/graphs/contributors)
At least, not using /usr/local myself, I see a lot of packages building because they have detected I changed the base directory.
Give it a try, you might like it (because it rocks!)
Why use OSX, then? Shouldn't you be using Gentoo?
(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!)
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.
* It takes hours to download Xcode
* It takes hours to download OSX Updates
* Setting up Homebrew, Zsh, Vim, Browsers, GitHub, Dropbox, Mail, Rbenv, Rubies, Cloning work repos
* Getting those other smaller things you were tinkering with, Z, Go
Everyones dev setup is different. So I'd agree it takes days to get set up.
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.
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.
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.
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.
`xcode-select --install`
[1]: https://ninite.com/
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.
[1]: http://www.microsoft.com/en-us/download/details.aspx?id=4407...
[3]: http://blogs.msdn.com/b/powershell/archive/2014/05/20/settin...
[4]: https://msconfiggallery.cloudapp.net/
[5]: http://psget.net/
[6]: https://github.com/powershellorg/dsc
[7]: http://blogs.technet.com/b/privatecloud/archive/2013/08/30/i...
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.
@powershell -NoProfile -ExecutionPolicy unrestricted -Command "iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'))" && SET PATH=%PATH%;%ALLUSERSPROFILE%\chocolatey\bin
# tools
choco install dropbox
choco install gow
choco install googledrive
# graphics
choco install inkscape
choco install colorpic
choco install blender
choco install gimp
# IDEs
choco install eclipse
choco install VisualStudio2012Professional
# editors
choco install atom
choco install lighttable
choco install ProgrammersNotepad
# browsers
choco install firefox
choco install GoogleChrome
# languages
choco install jdk8
choco install lein
choco install groovy
choco install python
choco install ruby
# build
choco install ant
choco install gradle
choco install maven
choco install puppet
choco install wixtoolset
# servers
choco install nodejs.install
choco install Tomcat
# databases
choco install mysql
choco install mysql.workbench
choco install toad.mysql
# scm
choco install git.install
choco install TortoiseGit
choco install GitHub
choco install svn
choco install tortoisesvn
choco install ankhsvnhttps://github.com/berdario/dotfiles/blob/master/deploy.py
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...)
I'm faster with the Windows-style taskbar and uBar (http://brawersoftware.com/products/ubar) was the sponsor of the last episode of John Gruber's podcast.
For launching I use a tool like Quicksilver or Alfred of Spotlight.
This way I get more screen realestate, I see no point staring at a dock icons all the time.
My dock resembles Command-Tab.
defaults write com.apple.dock autohide-delay -float 1000 && killall Dock
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.
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.
And don't feel bad - if NeXT had had a taskbar, we would all have been using a taskbar for the last 14 years!
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.
...right? `brew install bash` will just give you /usr/local/bin/bash, and then use that as your interactive shell.
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.
#!/bin/bashhttp://support.apple.com/downloads/
I don't know if it fixes the more recently found bash vulnerabilities, but I know it fixes the first one that was reported.
You can find versions for Lion and Mountain Lion if you search.
The problem was with Mackup, in the sense, for it to 'backup' (which I assumed would just copy/paste the files) had actually moved the contents to Dropbox and created the symlinks in place. Therefore not a true backup!! :(
I guess what I am trying to say is that please be VERY SURE of what the 3rd party tool/script does before you use it, cause sometimes you might just 'rm -rf' the seemingly useless artefacts.
Screwing up your work environment is NEVER fun!
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
$ brew tap phinze/homebrew-cask ; brew install brew-cask
$ brew install caskroom/cask/brew-cask
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. ;)
[1] https://github.com/KyleAMathews/linux-config [2] https://registry.hub.docker.com/u/kyma/dev-image/
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.
For me, I use CentOS for servers and I really wish that OS X had 'yum' (https://www.centos.org/docs/5/html/yum/)
It feels very easy for me to install, update, remove, etc
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.
Edit: I just discovered "brew doctor" and I had to use it. Ugh. Showing lots of warnings that I have to wade through...
Do I understand that brew does not require xcode and I can jump straight from a new machine to `brew install git` (for instance) ?
If so, why does anyone use macports over brew ?
I suspect macports might also be able to cope with just these tools? Or does it still have X11 ports?
xcode-select --install
cd
git clone https://github.com/magnars/.emacs.d.gitAiming for something you can easily use quickly, or send to less techy friends or parents to run.
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.
How many developers are launching bash scripts with environment variables defined by third parties?
A one liner tool in node that refers to defined config.
The dependency on a new machine is to install node.
;) Just kidding of course, yours is way better. Time to think of another silly name for my dotfiles...
Really? Puppet, Chef, Ansible, Salt, etc are pretty attention getting.
Who uses -days- setting up your own computer ?
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 beginners... https://wiki.archlinux.org/index.php/Beginners%27_guide
All others... https://wiki.archlinux.org/index.php/Installation_guide
[1]: http://robots.thoughtbot.com/brewfile-a-gemfile-but-for-home...
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.
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.
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.
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.
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.
http://steve-yegge.blogspot.it/2008/04/settling-osx-focus-fo...
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.
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....?
Edit: Seems it's still read-only. If you need write support that badly (why?), there's always Paragon: http://www.paragon-software.com/home/extfs-mac/
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.
Well, that's one I can personally tell you I've had problems with in the past.
> even worked back in 2000 on Cygwin out of the box on win2k
And also this one. That's even back around the timeframe I was actively doing Perl development while using win2k.
In the end after seeing the complex work arounds and all the warnings about buggering up your mac OS install I gave up and run a VM.
After all the nice people that employ me want me to do some nifty Machine learning tools to save a week a month running single adwords account.
https://gist.github.com/anonymous/d69f5b0cee13102a9167
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"?
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. :)
I'm hoping the year of the linux desktop will come eventually however.
That being said, they don't look pretty, but they make me so productive I just can't go back to anything else.
(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).
Honestly, it's quite insulting when you presume that people who use OS X haven't considered the alternatives, or are unfamiliar with Linux.
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.
1. Excellent laptop displays (16:10, high-DPI that actually works). 2. Reliable networking and graphics drivers. 3. Battery life.
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.
Perhaps people should stop expecting OSX to be Linux. In the same way that nobody expects Linux to be OSX.
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.)