you, and they, were doing it wrong.

The point of vagrant is that you type 'vagrant up' and you have a working environment.

All of my projects use vagrant to ensure compatibility. You can 'git clone' and 'vagrant up' and have a working environment as soon as the provisioning task completes.

Not my experience.

Vagrant encounter 1: it would always exit immediately after barfing some garbage that messed up the line discipline. It wouldn't even print help menus. Reinstalling, 32 vs 64 bit, slightly different binary versions etc didn't seem to affect this behavior.

Vagrant encounter 2: on a nearly virgin Windows box, "vagrant up" on a bog standard centos image stalled out for an entire work day. No stdout, no stderr, no logs, no exit status, it just sat there.

On a scale of 0 to 'flake', it's at full flake.

That screams badly written vagrant file to me.

Vagrant updates can wreak havoc too.

Vagrant is very bare-bones, so you need plugins, but those are ... picky.

Also, handling Linux / Windows / OSX with the same Vagrantfile results in interesting things. (Let's say you want to use NFS for Linux, so you put there an if, and you want to set up bridging for a local interface, you have to guess the interface name - or do shell and cmd.exe wizardy .)

Thanks for the help.

I trust that the people who provided whatever configuration it used knew what they were doing, but it was still incredibly flaky.

I don't think I've ever encountered a Vagrant setup that was flaky and wasn't just down to the Devs not actually understanding how to write a vagrantfile. In my experience, those who have hate for vagrant are folks who either didn't know how to use it, or were burned by others who didn't. It's a real shame as well, vagrant's a really good tool.

> I trust that the people who provided whatever configuration it used knew what they were doing

You should never trust that people know what they are doing in this industry.