Hacker News new | past | comments | ask | show | jobs | submit login

The author might have a different experience, but for me it's mainly anything that a) depends too heavily on a plethora of GNU tools and b) anything that's about deployment and installation. You're basically running on a different Unix system, so if you deploy to a Linux server, you'll probably encounter quite a lot of differences - mostly deployment, but also libraries, syscalls etc. Quite reminiscent of the days of different commercial Unices, where the compatibility of e.g. AIX and HP-UX wasn't exactly 100% (I'm sorry if that caused some violent flashbacks for veteran developers)

Also, OS X is usually behind even compared to Linux distros with fixed releases (i.e. not rolling). You get your basic Unix software in one fell swoop, with the occasional update through a dot version. Apple doesn't provide a pkgsrc or even a rpm/deb packaging system. There are third party efforts, like MacPorts, Fink or – as the author mentioned – Homebrew, which is more similar to BSD's package tree or Arch's AUR (basically a git repo of Ruby build scripts).

Nevertheless, these add on to your system, so aren't really integrated perfectly. Also, compared to Debian or Arch, you'll have a smaller package list (esp. true for Homebrew). So it might just be easier to install some stuff from within a headless Linux VM.

Heck, I've been doing something similar even when I was running Linux as a dev environment. Your deployment environment might be quite different, and I like to do some local testing first – doubly so if your company doesn't even have a proper testing/integration environment. I had an Arch PC, but deployed to both somewhat recent Ubuntu machines and ancient SuSe installations. Now, I often work on OS X and deploy to a CentOS VPS. All good use cases for VMs – and the way described, where it's just a small headless instance in the background instead of a useless GNOME desktop-within-a-desktop is a pretty good approach.




Hello, author here.

This is really a great overview of why I like this setup, I couldn't have put it more clearly.

An example of something I've been trying lately and didn't work well under OSX: ruby bindings for FUSE filesystems. I wanted to write a quick FUSE fs using ruby, so I installed gems and other dependencies. But since MacFUSE has been deprecated for a while, it's not easy to get everything working.

It could probably work under OSX, but given the current state of FUSE on Lion, I gave up (and did not try it under Linux yet).

While trying to setup my FUSE environment, I installed every FUSE version, many gems with a couple of ruby versions with rvm, rbenv, ruby-build, etc. When playing with new tools and environments, I always end up with lots of useless or broken stuff.

This setup allows me to keep my base system clean and simple.

I do not use it daily, but it's nice to have it ready to launch when needed.


One of the benefits of VMs is that it's usually quite easy to create a backup of a certain state, so that you can easily mess around with it, install lots of stuff, wreck the system, and then easily get back to the pristine state. Or do the same again three months later when you have to test the next version of the software…

That's one of the reason why I think that every company larger than one person should have a dedicated VM server…

What I still have to try is NFS mounting my Mac's $HOME directory. Introducing some special cases into the shell startup scripts etc. shouldn't be a big deal, but me and NFS had a bit of a tiff a few years ago…


shudder! Suddenly it's not such an attractive thought to invest in a MacBook even for (L)AMP development, and deployment to Cent OS.


If you're developing for a CentOS server, I'd say you'll have to do some final testing on a VM in 95% of all cases. Even a CentOS laptop that you use for production (and maybe a little fun) will have some major differences to a server deployment. And that's assuming that you're enough of a glutton for punishment to be running CentOS 5.6 on a laptop.

Even if you're running Ubuntu 10+ on your laptop (a somewhat more sane assumption), you'd want to test your code on something closer to the "metal".

And honestly, (L)AMP (for normal values of P) won't be a problem on OS X. The usual frontend stack doesn't have major differences, maybe apart from a different default versions of the software (which are easy enough to install). Once you get closer to the system-specific stuff (when it get's more unix-y or network-y), then care about the differences. Not exactly the case for most web scripting stuff…


It's really not that bad. Homebrew may have fewer packages than, say, Debian's apt repo, but I still don't use 99% of the packages in either, and both cover everything I need.

Consider what exactly you'll be using in your stack, and go from there. I've had zero problems over the years using OS X for Rails, Python, node.js, and C++ development that was seeing deployment on Linux (typically Debian or Ubuntu, sometimes CentOS).




Consider applying for YC's W25 batch! Applications are open till Nov 12.

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

Search: