[dchichkov]

You have Linux/Ubuntu development envinroment, right? Why do you use it in a VM on a Mac in the first place?

Why not just using a fast desktop with a couple of monitors at your workplace? And ssh/xterm to it, if you need to work remotely?

[adrianhoward]

Because being able to have a copy of the deployment environment - especially one that you can build, deploy and test automatically, is stupidly useful.

It's not being able to have a linux machine. It's being able to have one that you can build, throw away, test different deploy strategies on, etc. etc.

Suddenly you have all the developers dealing with deployment problems as soon as they occur - cutting that loooooong feedback loop to minutes saving everybody time, pain and money.

TL;DR - coz it's a good thing :-)

[vidarh]

Linux supports about a dozen virtualization technologies, and modern distros, e.g. Ubuntu 12.04, makes it trivial. Here's what it takes to start a new Ubuntu based container (less isolated, but more than enough for a dev environment) on Ubuntu 12.04:

lxc-create -n [some name] -t ubuntu

Then:

lxc-start -n [some name]

to start it and get the console (or tack on "-d" to run it in the background)

Ubuntu by default starts dnsmasq to serve up local dns results for vm's, so you can ssh to them, and setting up a tunnel for external access is easy.

LXC also works fine on Debian, though the experience isn't quite as polished.

Otherwise, you can use KVM, Qemu, Virtualbox, Vmware, Xen, OpenVz and more. In all cases, you can use the same deployment tools: Build .deb's and set up a local APT repo (just a directory you run dpkg-scanpackages over), or use Sprinkle or use Chef or Puppet or half a dozen other tools. Use buy into Ubuntu's orchestration tools (in particular Juju,which supports direct deployment onto LXC locally, OpenStack or EC2 for now)

In other words, putting your environments on a Linux box doesn't remove the ability to have copies of the deployment environment or building, deploying or testing automatically - it adds a massive number of additional options for how to do it. In particular, it lets you do it in ways that translates directly to private or public Linux based cloud solutions.

[adrianhoward]

Sorry - I just answered the "Why do you use it in a VM" bit, and ignoring the "why a Mac" bit :-)

The "Why a Mac" bit is because I find I'm more productive on a Mac - and I like them.

(By "more productive" I mean I've actually tracked and measured the stuff I get through each day during several months of using both platforms - ubuntu on the Linux side - and found I come out ahead on the Mac. I didn't try this with Windows coz, until Windows 8, I actively disliked the OS and didn't feel I needed to use something I didn't like even if I did turn out to be more productive :-)

I am very happy with Linux. All our boxes that aren't Mac's are Ubuntu - including some folks personal machines. My personal view towards hardware is you get whatever you feel most productive on. I've been using Unix-ish platforms for large chunks of my working day since 1988. For more than five years I used nothing but Unix-ish boxes (SunOs then Solaris then Linux). I spend large chunks of my day dealing with unix via various terminal windows. I don't find Linux scary or confusing. I just happen to like Macs, and some of the work that I do is easier to do on Macs.

"In other words, putting your environments on a Linux box doesn't remove the ability to have copies of the deployment environment or building, deploying or testing automatically - it adds a massive number of additional options for how to do it. In particular, it lets you do it in ways that translates directly to private or public Linux based cloud solutions."

I never meant to imply in any way that putting things on a Linux box removed the ability to have copies of the deployment environment or building, deploying or testing automatically. My apologies if I was not clear about that.

I know how lxc-create et al work. If the number of virtualisation options were the main factor I had in picking the OS of the machine my keyboard is attached to I'd be using a Linux based laptop. For me, personally, it isn't. So I'm not. That is, of course, in no way saying that Linux laptops are bad (have 'em, use 'em, love 'em). Just that they're not the best fit for me and the work that I do (and I have graphs to prove it :-)

[dchichkov]

Well, it can be as easy as 'sudo apt-get install mydevenv'.

Create a corporate apt repository with your custom modules/libs/ets and mydevenv module that includes all the dependencies. And that's it. You can recreate the environment with one command...

Edit: Uh. Deployment environment. Sorry. Yes. Having QA/Deployment env. in VM is a way to go.

[ajross]

You can virtualize linux in linux with no trouble at all (even with VirtualBox if you like). As I read it, the suggestion wasn't that you replace your virtualized Linux with physical hardware, it was that you replace your Macbook with a system that does what you need.

[adrianhoward]

As I read it, the suggestion wasn't that you replace your virtualized Linux with physical hardware, it was that you replace your Macbook with a system that does what you need.

That was the question I was attempting to answer - I have obviously failed :-) Let me try again.

A Macbook + virtualised environment does exactly what I need.

I happen to prefer Apple HW and the OS X GUI. My partner prefers Ubuntu. We both run dev environment in a VM because automating the creation and deployment on a virtualised environment brings a whole bunch of advantages that running it on your base machine does not.

Virtualisation of the dev environment is a good thing regardless of what that virtual environment is running on.

For example:

* We can trivially run the current dev branch on multiple versions of the OS by just building on top of a different vagrant box

* It has basically killed deployment issues stone cold dead for us - since we're always deploying. Problems get found as soon as you f\\k up. You can't forget dependencies. You don't get tempted to make a quick tweak to a config file that you then forget about it. And so on.

* You get your automated deployment code "for free" since you're developing it as you go rather than thinking "okay - how do we deploy this".

* It makes experimenting with different infrastructure / dependencies / versions very, very cheap and simple

* Makes developing in odd/remote locations really simple. All I need is an internet connection, virtual box, our repo and vagrant and I can get a dev environment up and running.

* We each get to have the OS that we like for coding on, without all that tedious "it works on my machine" faffing.

[justincormack]

Get a Linux box you can run VMs on then (ie non virtualised), or use a cloud service?