Disqus - Latest Comments for mitchellh

Re: Pow port forwarding with Vagrant

mitchellh — Sun, 17 Mar 2013 14:38:40 -0000

Good post!

You can also use static IPs: http://docs.vagrantup.com/v...

And for forwarded ports, you can ask Vagrant to auto-correct port collisions:http://docs.vagrantup.com/v...

Re: Lessons Learned Building Open Source Software

mitchellh — Wed, 04 Apr 2012 23:39:32 -0000

Hey Jeff! Thanks.

I totally should've covered versioning. I'm a big fan of Semantic Versioning and follow this pretty closely: http://semver.org/

Re: Lessons Learned Building Open Source Software

mitchellh — Thu, 29 Mar 2012 18:45:11 -0000

FFI in general is an _amazing_ lib. Ruby-FFI is garbage. I gave it an honest shot for over 18 months, and it resulted in nothing but pain. Like I said, waking up to find out that an FFI release (Ruby-FFI) broke Vagrant on Windows, despite being a patch release, is infuriating. I can't support a library that is so brittle.

Again, FFI itself is great.Thanks.

Re: Lessons Learned Building Open Source Software

mitchellh — Thu, 29 Mar 2012 16:13:00 -0000

Generally I merge the pull request, then fix the formatting in my own commit, then mention the commit in the pull request so that [hopefully] the original committer can learn something.

Re: Lessons Learned Building Open Source Software

mitchellh — Thu, 29 Mar 2012 15:23:05 -0000

If you link directly to an HN post, then any upvotes will show up for the count, but do not count towards the front page ranking algorithm.

Re: The Hardest, Most Rewarding Job I’ve Ever Had.

mitchellh — Thu, 08 Mar 2012 21:58:59 -0000

Awesome, good to hear!

Re: The MongoDB NoSQL Database Blog, Cache Reheating - Not to be Ignored

mitchellh — Mon, 19 Sep 2011 17:13:22 -0000

Here is a real issue I posted about this a few weeks ago:

https://jira.mongodb.org/br...

Re: The MongoDB NoSQL Database Blog, Cache Reheating - Not to be Ignored

mitchellh — Mon, 19 Sep 2011 17:02:48 -0000

SO FUCKING WRONG.

We run an average sized MongoDB cluster servicing around 8,000 ops per second with around 500GB of data. One of the _BIGGEST_ problems with MongoDB is that secondaries in replica sets do NOT know the recently queried data and therefore have literally 0 cache. MongoDB advertises replica sets as having smooth failover and this is simply not the case. If your primary dies, your database is literally sodomized with a redwood tree log for around 5 to 10 minutes.

Thanks for making a blog post about something extremely important.

But its laughable that MongoDB is absolutely terrible at keeping the caches warm. Keeping the caches warm on one server (the primary) is about 1% of the way there.

Stay classy, 10gen.

Re: Manually Halting VirtualBox VMs From Terminal.App — Article — TheDrunkenEpic

mitchellh — Mon, 08 Aug 2011 21:24:09 -0000

Hello! Does `vagrant destroy` not actually work? What crash cases are you seeing? I'd love to fix these up.

I do realize that VirtualBox 4.1 on Lion and certain Mac machines is unstable, however.

Re: Welcome to Ruby. We Have Many Rubies.

mitchellh — Mon, 14 Mar 2011 15:05:42 -0000

Sorry, have some benchmarks: http://programmingzen.com/2...

There are more recent ones that show Rubinius and JRuby being even faster, but I've been unable to find them. But as you can see, both are clearly faster than MRI (Ruby 1.8). 1.9 is slightly faster still, however.

Re: CloudFormation: The Big Picture

mitchellh — Tue, 08 Mar 2011 02:57:21 -0000

Jeff,

Taking down an entire infrastructure and bringing up another (or doing that in the opposite over for no downtime) is a very taxing operation. It is a very careful dance. Plus, as infrastructures get larger, this gets harder and harder.

Although its a much harder problem, I think incremental changes are important in the long run.

But you are right, for now you can take down an infrastructure and bring up another.

Mitchell

Re: JRuby, win32ole, and Vagrant on Windows

mitchellh — Wed, 09 Feb 2011 02:19:43 -0000

Interesting. I've been trying to google for "COM Surrogate" but all I get is crap (thanks google!) about "COM Surrogate Errors." I'd like to learn more about this technology. Do you have any additional links?

Re: Libvirt 0-8-6 and Vmware Esx

mitchellh — Wed, 08 Dec 2010 13:55:27 -0000

Patrick,

I wanted to note that Justin Clift (jclift@redhat) did most of the work on getting Mac OS X to compile libvirt. I simply provided error messages and debugging help where possible. He did all the heavy code changes and makefile changes :)

Best,
Mitchell

Re: Virtualize This – Instant Rails in a Virtual Box

mitchellh — Fri, 03 Dec 2010 13:17:53 -0000

Andy,

Fog is an EngineYard project for controlling cloud resources, whereas Vagrant is a tool for managing local virtual machines. They work well together hand-in-hand.

Best,
Mitchell

Re: Why You Should Be Using Virtualisation

mitchellh — Sat, 06 Nov 2010 03:03:18 -0000

Rory, just wanted to note that Vagrant uses (and automatically setups up on the host and guest) NFS to get around VirtualBox's terrible shared folder performance. For a few real world tests, I've actually found NFS to be faster than even VMWare's shared folders, where the performance is still quite bad.

Re: Why You Should Be Using Virtualisation

mitchellh — Sat, 06 Nov 2010 03:01:41 -0000

Yes! Yes Yes Yes! Virtualization for development is extremely important and I'm glad you wrote this. Also, thanks for the hat tip to Vagrant, I appreciate it. I've given a few talks on this and it always amazes me how many people are so comfortable with the status quo of developing on their own machines with apache/mysql/etc installed directly on their machines. Its a disaster waiting to happen.

I want to point out to the many people using VMWare out there: VMWare Fusion is great, yes, I won't argue. Their shared folders are better, again I agree. But Vagrant does make use of NFS which is faster than even VMWare Fusion's shared folders in order to get around VirtualBox's terrible performance.

And just because I have things to say, here are a few of my own remarks against the arguments against virtualization of development:

* Speed - Given enough RAM (which for a standard web application, shouldn't be any more than 512 MB to 1 GB for the VM instance), the speed difference is noticeable but not detrimental to your productivity. For regular web requests you won't notice any speed difference. For CPU intensive background tasks, you'll probably see a 1.5x slowdown. Again, unless you're running 5 hour tasks during development, it shouldn't be a big deal, and the benefits outweigh these issues, in my opinion.

* Lower level than you're used to - Then get your friendly sysadmin to setup a base image to use for your site. A modern sysadmin has many scripts made to automate the setup of the environment for production. There is no reason these scripts can't be used to setup your development as well. Use it! Stay in your happy place and just boot up a VM and code! (Although its my opinion every developer should take the time to learn their software stack top to bottom)

* Something else to setup - Once. You only need to learn it once, and its repeatable and dependable. I would argue that setting up a new software stack every time a dependency changes on your web app is far more than one more "something else to setup."

* Developer workstations should be personal - Right! I agree 100%. So stop installing server crap on your personal computers. Keep your Twitter clients away from your web servers. Use a VM and keep your workstation personal.

Thanks again,
Mitchell

Re: Always initialize your memory

mitchellh — Tue, 28 Apr 2009 03:11:38 -0000

Oh wow. This happens in EA games. I've had web pages fully rendered on my textures in Battlefield 2142 and I couldn't find any solutions to it. Its good to know it was probably EA's fault.

Man.

Re: You keep using that word “distributed”…

mitchellh — Wed, 08 Oct 2008 22:39:29 -0000

I completely agree. I think its funny how people focus everything around github. For example the one tweet that says "now i'm manually changing code on a live production site" should never be using his github git repo as a dependency for deploying to his production site. If anything he should set up (even if its difficult, 5 minutes save you a ton of pain) a publically accessible git repo either on his computer or some other server which his deployment can depend on.

And even if that goes down, since everyone who has the repo has the ENTIRE repo, you can just point your deployment scripts to the new repo and hurrah it works.

My company uses an internal git server for hosting all our production site repos which are used in deployment scripts, while a post-receive hook pushes this to github as a read-only mirror. This seems to make a lot more sense than putting all our eggs in one basket with github (which is a big no no).