OSX is an OS where you run VMs for Linux and Windows.
I keep seeing people saying how great and fast it is to do stuff on their mac and run Windows for a few apps incl. mail client, office suites, some dev tools and many java apps (cause they're often not so nice on OSX)
Then I see them with the Linux VM for all the dev tools, the hack tools, and so forth, because, well, hacking them up to work in OSX is always a pain, and even using stuff like brew is often a pain (+ delay)
Well I dunno, I run Linux native and I get stuff done faster than the ones running Linux in a VM of course. I also have Linux VMs under Linux when necessary, with KSM and it's a lot faster and memory efficient than when running OSX native on the same hardware.
I install stuff in about <5s where it takes a VM to boot/resume in OSX, and about 5-10min to install from scratch when the app _supports_ OSX (ages if it doesn't but has more or less compliant sources)
Yeah, me too. I have a linux computer for most development, a Macbook when I want to mess around with iOS development, and a Thinkpad for .NET development. All of these are tax write-offs and since I use the linux computer (which twice as old as the other two, by the way) 90% of the time because it's simply easier to install development related stuff. Whenever I want to install a gem that uses native headers requiring a -dev package in OSX I just quit.
I'm the opposite. I like all of my OS X dev tools (navicat, textmate/macvim (I know, gvim...)/sublime text/github for os x/things), and it's a much more usable OS overall for me. The parts I don't like, compiling libraries, running servers, etc, I automate away with vagrant. I'm more productive with this setup than if I ran everything directly in Linux (I've tried).
Using qemu in a no-gui mode is pretty cool. I've used VirtualBox, VMWare Fusion, and Parallels on OSX before, but I hate having to deal with the GUI window (and having the system reserve resources for it).
Since OSX is based on Unix under the hood, it shouldn't be too difficult to for a developer to use either OSX or Linux as their development machine. It's not like the knowledge gap between Windows and OSX/*nix machines. So other than messing around with Linux, the article fails to mention why he doesn't use OSX (other than some unfounded 'flaky' and 'impossible' critiques).
I mostly use OSX for everything. The only times I switch to the VM is when I'm having a hard time installing something (for an example, see my earlier comment - http://news.ycombinator.com/item?id=2969509) or want to try a tool that's not available under OSX.
I admit the post would have been better with examples and without then unfounded critiques, taking notes for the next ones.
Just wondering if you could think of anything obvious I'm doing wrong (I'm pretty much a newbie when it comes to this)...
I'm following the instructions in your post on my Macbook Pro (2010); however I get 'Booting from DVD/CD... 180MB medium detected. Boot failed: Could not read from CDROM (code 0005) No bootable device.' I am using the netinstall Arch Linux ISO.
I used to work on Django project on a Mac. Dependencies like python-mysqldb can be quite tricky to install on OSX, whereas Ubuntu only requires you to type 'apt-get install python-mysqldb' and you're done.
More importantly, though, I do not like the idea of having all those services constantly running on my desktop system. I'm using Ubuntu for both development and deployment now and I still use a separate VM.
I may be missing something but I think you can do what is proposed with VirtualBox. I use it for my virtual dev machines and run them in headless mode. For example the command:
vboxmanage startvm "Name of VM" --type=headless
to boot an image up, takes about 10 seconds to be ready to ssh into (You can ssh immediately it just waits till it has booted to connect).
I think one of the main reasons why I like VMs so much is that they allow my base OS to stay relatively clean. Especially as I like to try out all kind of new stuff constantly, VMs make that easy without having to care how they affect the rest of my system. Even if you aren't trying out new stuff, keeping separate projects mostly isolated makes me feel happier. imho also configuring stuff becomes easier when your machines become basically single-purpose systems.
There is a problem with doing things this way. I want my development server to be always on, always available. It does things in the background and sometimes I use it when I'm away from the office.
Yes, you can keep your desktop machine on all the time, but that's a huge power suck. Shut down your desktop when you're not using it. Most development servers just don't need to be that beefy anyway.
A better approach, if you're absolutely committed to virtualization, is to just spin up an instance on Rackspace or Amazon. You'll pay about 10 bucks a month, which is less than you would for keeping your desktop running 24/7. On top of that, if your desktop dies, you won't lose your data.
These are all good points, I should have made my goals clearer. I do not use it as a web development machine or something that needs to be always on.
I use it as an occasional machine, to compile and test stuff that's not working or unavailable under OSX. I was looking for a powerful and cheap VPS (which is uncommon) when I figured I'd be better served by a headless VM.
Another big plus for me is having access to it when there's no connectivity.
Why would you need to have your dev server always-on? I think you are either speaking of different kind of development server or your dev server is doing too much stuff.
When I hear development server, I think of box on which I can try out various things which may, or may not blow up. That makes it inherently not always available. Also, I want it to be in a relatively clean state so I know that any problems rising are not side effects of some other thing running on it or anything. And after I finish testing some new stuff, I want to be able to just throw it all away if necessary, without needing to care if there are some other services that may be disturbed.
> When I hear development server, I think of box on which I can try out various things which may, or may not blow up.
I'm not always in the office. Sometimes I'm at home. Or on a trip. Or in another country. And I still need to have access to my code, try things, make sure they don't blow up.
I suppose I could just use Wake-On-LAN or IPMI, which I do sometimes ... but my development server also doubles as a file server and collects error logs from deployments. Not kosher, I know, but no $$$ for anything else.
Yeah, I kinda guessed that you were talking about something completely different.
The kind of server you are talking about obviously can not be hosted on a local virtual machine. imho that kind of stuff should be hosted in some data center on a stable server. As it contains many of your most valuable assets and losing access (even temporarily) to it could hinder your ability to work, it should have relatively high availability and general reliability.
The kind of server I, and what I believe the article, were talking about is on the other hand convenient to host locally. It's a machine where you can freely test your code or try out some new stuff. This way you don't need to risk your "main" server unnecessarily with your testing.
As VMs are practically free, you can have them everywhere and as many as you wish. On your workstation, desktop at home, or on your laptop on the road, each can have it's own testing VM. And every project you are working on can have it's own testing VM too, so there is no risk of them interfering each other in any way.
If you can realistically put a VM image in Dropbox, then I want to live where you live. Where I am (London), that kind of bandwidth is scarce and costly.
Not everybody needs to run development server 24/7. Plus, the title and the content of this post is "Replacing a Development VPS with Linux on OSX", and you're suggesting the opposite.
I currently use a similar environment but with VirtualBox. Does qemu offer any advantages over it? I was considering recreating my VM so I may as well try qemu.
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.
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…
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).
It's not necessarily that you "can't" do a lot of things -- it's just harder. Recently I was trying to play around with Xmonad. I managed to get it up and running in X11 on OS X but it always was a little "off". I wanted it full screen, but sometimes the dock would appear, sometimes not, sometimes the OS X menubar along the top would appear, sometimes not. Sometimes various applications would lose focus but stay in front of X11. It was just not very great.
Then I ran into some problems getting gvim working in that setup. I'm not completely facile with all things Linux and usually Google for some help setting things up, but in this case I couldn't find anyone else who wanted to install gvim on OS X using X11, so I was out of luck there.
In the end I just fired up a Linux VM and it was all as easy as could be.
Never mind that nowadays we have the linux version of "all the world's a VAX" syndrome. Not every OS has utilities that obey all the occult incantations of the GNU versions…
I'd encourage every Linux developer to get a similar setup with a BSD version – or even just an older and/or different Linux distro.
I recently got into an endless back and forth with a guy on reddit because I said that as a web developer, I require a mac (instead of a windows machine). When asked why I said that it is a hell of a lot easier to mimic testing/dev/production environments on a mac than windows and the only reason to choose a mac over a linux distro is because of the adobe dependance. His stance was that it isn't important to have your machine muddled up trying to replicate the dev/staging/production machines when you simply can develop on a remote box via some sort of ssh/file mounting. To which I replied with not always having access to remote dev machines, etc.
What is your take on this issue? I was actually surprised that people want to develop on remote machines. It reminds me of "ftp to see a change"
bah, not really if you use editors like emacs or vim. I'd suggest also using screen to maintain a dev session going. screen lets you start shells and detach from a session without closing any of them (useful for long running jobs too). In the end my remote environment doesn't differ much from my local environment.
I do most of my development on my server at home from my laptop (either at home or at coffee shops), but if I hadn't already invested in a beefy box I would definitely be using http://pair.io instead.
That's how I develop. Since I use vim anyways, I just ssh into a linux dev server from my windows box and code right on the server with the only delay being latency. 99% of what I do can be done in the command line so I end up with few problems.
I develop (Django/Rails) with Chrome running locally and my dev environment running in vim/tmux on a Ubuntu box that I ssh into. As long as the dev server automatically reloads when it detects a file change I see no issues.
What are you thinking you'd miss in a setup like this?
Yes. Not having to leave the box in front you is a good thing, it means you can continue working on the train even when your 3G connection drops out. It also enforces a certain discipline about dependencies.
Let's face it: SSH into an VM and write code there is not an enjoyable experience. Yes I can do a proper deployment into the VM right after I make a minor change in color of the 10px square box located at the bottom of the page, but it's really a pain in the ass to have the deployment delay. Oh, right, the deployment process just takes 10 seconds!
Why SSH into a VM? With Virtualbox I have a folder shared out that I can use like a regular folder and edit with whatever editor on my Host. Or you could turn on SMB shares and use those.
Or I could run a lightweight X environment (or even gnome it really doesn't need much to run) and just edit there.
Everyone seems to be on the "OMG Vim/Emacs are so awesome, TextMate is so yesterday" part of the every going cycle anyway. Might as well use them on the guest OS as well.
And it's worth running a vm for development even if you're hosting it on a linux machine; presumably your workspace has a bunch of things that don't need to be installed in production.
I also "deploy" to my local Linux VM for when I want to test a multi-server set up or try something new without messing up my main computer. Otherwise, I code and test almost exclusively on OSX. Haven't run into any situations yet where I wished I was coding in Linux as well. Linux doesn't have Photoshop or iTunes.
I'm following the instructions in the post on my Macbook Pro (2010); however I get 'Booting from DVD/CD... 180MB medium detected. Boot failed: Could not read from CDROM (code 0005) No bootable device.' Does anyone have any ideas why this is not working? I am using the netinstall Arch Linux ISO. Many thanks!
Then I see them with the Linux VM for all the dev tools, the hack tools, and so forth, because, well, hacking them up to work in OSX is always a pain, and even using stuff like brew is often a pain (+ delay)
Well I dunno, I run Linux native and I get stuff done faster than the ones running Linux in a VM of course. I also have Linux VMs under Linux when necessary, with KSM and it's a lot faster and memory efficient than when running OSX native on the same hardware.
I install stuff in about <5s where it takes a VM to boot/resume in OSX, and about 5-10min to install from scratch when the app _supports_ OSX (ages if it doesn't but has more or less compliant sources)