Earlier quoted context omitted.
Docker just spins up a VM on OS X with boot2docker so you don't get any real benefit here.
Yep, although it creates only one you can run a bunch of containers in it. It feels almost as a native support, but the hack is betrayed by the networking setup. I wish it would be possible to just expose ports on the real localhost.
Ask HN: Best practices for OS X dev environments
51–57 of 57 posts
Re: Ask HN: Best practices for OS X dev environments
#52Earlier quoted context omitted.
I've never used Chef, with or without Vagrant, but I have used Puppet. It's generally better to have a shell script install your provisioning tool, or use a box that already has it installed, than depending on Vagrant to do anything for you. Here's a simple example: https://github.com/puphpet/puphpet/blob/master/archive/puphp...
...or switch to a provisioning tool that doesn't need to be installed on guest VMs (e.g. Ansible), saving a little time every time you provision. Otherwise, another option is to either use prebuilt Vagrant boxes with your CM tool already installed, or build your own using Packer.
Re: Ask HN: Best practices for OS X dev environments
#53It is interesting to see everybody using VM's and containers. Personally I have a web server I do all my work on, so I can get to that from my mac over: http, ftp, ssh, and vnc. I do all my work online so I can easily point any device (or ask a friend with an exotic device to click a link to test something) and I can also work from any device with an internet connection. This setup has let me be flexible, travel, wor…
Re: Ask HN: Best practices for OS X dev environments
#54Earlier quoted context omitted.
How do people find the battery life overhead? A quick test showed a Flask dev server tool 25% in a VM compared to less than 2% natively. That would seriously restrict my ability to develop on the move or away from my desk.
First, 25% of the VM's CPU (seen in the VM's "top") is not the same as 25% of the host CPU. Second, do you develop on the move unplugged for large stretches of time? Where is that place that doesn't have a plug?
I'm talking about host CPU
> Second, do you develop on the move unplugged for large stretches of time? Where is that place that doesn't have a plug?
Anywhere with sunshine and fresh air. We don't get many sunny days in the UK and I'm damned if I'm spending them indoors.
Re: Ask HN: Best practices for OS X dev environments
#55Earlier quoted context omitted.
First, 25% of the VM's CPU (seen in the VM's "top") is not the same as 25% of the host CPU. Second, do you develop on the move unplugged for large stretches of time? Where is that place that doesn't have a plug?
> First, 25% of the VM's CPU (seen in the VM's "top") is not the same as 25% of the host CPU. I'm talking about host CPU > Second, do you develop on the move unplugged for large stretches of time? Where is that place that doesn't have a plug? Anywhere with sunshine and fresh air. We don't get many sunny days in the UK and I'm damned if I'm spending them indoors.
Re: Ask HN: Best practices for OS X dev environments
#56Earlier quoted context omitted.
It's called Docker.
Docker is not a VM and only works on Linux.
On non Linux systems, it downoads a prebuilt VM, and runs it with Virtualbox.
This is how Docker currently works on other OSes.
Re: Ask HN: Best practices for OS X dev environments
#57Earlier quoted context omitted.
> First, 25% of the VM's CPU (seen in the VM's "top") is not the same as 25% of the host CPU. I'm talking about host CPU > Second, do you develop on the move unplugged for large stretches of time? Where is that place that doesn't have a plug? Anywhere with sunshine and fresh air. We don't get many sunny days in the UK and I'm damned if I'm spending them indoors.
Well, if you're based in the UK, you should be alright with an 8 hour battery to make it through those sunny days without recharging.
Which is a big chunk of time.