Your approach sounds dangerous: if your development machine is shared, how does your team manage versioning and avoid conflicts? How do you test individual changes? If your development server is yours only, I fail to see the point: your real development machine is the remote one and your Windows box is nothing more than a glorified VT-100.

> if your development machine is shared, how does your team manage versioning and avoid conflicts? How do you test individual changes?

Of course the machine is shared, but our development workspaces are not. We all have separate accounts on the staging server. The idea is that the staging environment is identical (in terms of software) to the live environment. Of course, we would have to coordinate any sort of hardware stress testing in order to get accurate results, but that's a rare edge case and would be true even if you were developing locally (since stress testing on the local machine wouldn't give useful results).

> If your development server is yours only, I fail to see the point: your real development machine is the remote one and your Windows box is nothing more than a glorified VT-100.

Oh come on, don't be obtuse. The reason I use Windows is because Windows 7 is a genuinely good OS that helps me to be productive. The UI is well-designed and I have direct access to all the various browsers I need to test sites on. I have good text editors and SSH clients. I have a solid laptop with features that I desire (easily upgradable, TrackPoint, much more durable than a MacBook). The only downside is that Windows comes filled with bloatware, but that's a matter of just installing a clean copy of it.