Replacing a Development VPS with Linux on OSX
jmlacroix.com
jmlacroix.com
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)
I used Linux exclusively for more than four years, and I miss many things about it, but I don't think I can go back, at least yet.
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).
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.
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).
vboxmanage controlvm "Name of VM" poweroff
If you want to turn it off from the outside.
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.
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.
Many thanks!
VBoxManage start vmname -type=headless
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.
Great. Shut down the instance. You pay nothing when it's off.
> Plus, the title and the content of this post is ...
I know what the article says. I'm telling you it's not a good idea, for the reasons listed above.
I do run a few local images here and there, but that's only for situations where I don't have access to the internet.
Not true for Rackspace.
You're right. From what I hear, it may become a feature once they convert everything to openstack.
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.
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.
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.
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.
Makes perfect sense in that context.
What I like in QEMU, is its simplicity. The learning curve is a bit steeper, but when you're used to it there's no turning back.
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.
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…
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).
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…
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.
LXC (obviously).
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.
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"
What are you thinking you'd miss in a setup like this?
What is the advantage of trying to make OS X your development environment and then deploying to a Linux host?
Unless you have an older laptop with less than 4 gigs of ram why not? Even with 2gigs it's not that system intensive to run a Linux guest os.
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.