For example:
Start your new Ubuntu machine...
$ vagrant init precise32 http://files.vagrantup.com/precise32.box
$ vagrant up
SSH in..
$ vagrant ssh
And install tmux
$ sudo apt-get install tmux
*note: these commands are off the top of my head, please read the getting started guide for proper instructions.
The supplied hardware at these gigs didn't really have the spec for spinning up VMs - this also spared me from fiddly network and other shared resource setup.
I even had a "portable" cygwin install on a USB stick.
Seriously, though. If you have machines with lower-end resources, who wants to to wait on a VM. Plus I wouldn't trust testing to a virtualized machine. I wouldn't release software without testing it on a real box.
Plus, you get cron, sshd, and most importantly a bash shell that works much like it does on Linux. For people who prefer a Linux-like environment, but have to deal with Windows (for work, or for whatever reason), Cygwin is a must-have, IMHO.
Wouldn't release software without testing it on a real box? We run all our production software on EC2.
Much like it does on Linux? Oh no. Oh no. You are lost my friend.
Cygwin is not UNIX. It looks like it and runs UNIX tools but it has some gotchas that can shoot you in the toes and face if you move your stuff to another box.
I don't have any problem moving things from box to box. If I administer a Windows machine, it will almost always have Cygwin on it. I do development and administration on them all the time. I'd be curious to know what kind of "stuff" you were moving to another box that gave you trouble. Perhaps you were talking about moving executables/DLLs between different versions of Cygwin. I keep my machines mostly on the same version of Cygwin, and I'm not developing Cygwin-specific applications, so I'm not linking to the Cygwin DLLS, so I don't have problems with that.
NO that's NOT what I meant.
I meant that I wouldn't release software that was designed to run on, say Windows XP/7/8.x/..., without running it natively on a machine running those operating systems.
I was NOT talking about virtualized Linux systems. I was talking about desktop software (since we were talking about Cygwin, I guess I thought that would be obvious, but perhaps I should have spelled that out).
Yes, people do still write software for desktop operating systems (I realize that's a shock, and "how 1994 of them!", etc). Yeah, it is nice to have Virtualbox or VMWare, etc to test and debug on (so if something hoses the OS, you don't have to reboot the hardware, and stuff like that), but if the app is targeted at a desktop OS, I'll be testing it in a non-virtualized environment at some point. I wouldn't rely strictly on testing in a Windows VM running in Virtualbox under Linux. Call me paranoid if you want, but I still think it makes good sense.
I do production stuff that runs on a Linux VPS also. That's an entirely different ball game. I'd have absolutely no problem releasing that software after only running it on a virtualized system. Of course, in that case, the target environment is a virtualized system, so the production environment is the same as the development environment.
So, that's my response to you if you were being serious. If you were just trying to be funny, then ... oh never mind. :-D
Then Git for Windows (which is built upon MinGW, and includes bash, grep and whatnot) + MinTTY is immensely more useful and lightweight than Cygwin.
Even when I do work in a VM, I use a Cygwin terminal and ssh client to connect to it. mintty is fairly amazing.
I work in the cygwin terminal as much as possible on my work Win7 box. I often do this from cygwin:
$ OurWindowsOnlyProprietaryLogReader someLog.log
I do also use a vagrant VM, but I rarely fire it up these days because I do a lot of what I just described. One reason I wanted vagrant was for tmux, and tmux on cygwin will be welcome.