>I guess the main problems with VMware running under Windows, is that you get
>all the windows "badness" without the linux "goodness" :)
No, the problem is that you're getting the "badness" that you get with any scenario that involves three things (linux + VMWare + Windows), and especially the interactions between them.
Jon apparently has a dim view of Windows, perhaps he's remembering memory or stability issues with the long-obsolete Win95/98/Me line of products. The WinNT/2K/XP line is decidedly more stable, memory-competent etc, and for supporting the kinds of GUI apps (often graphics- and memory-intensive) commonly run on Windows is arguably a lot more competent than linux, even recent releases thereof.
But that's beside the original correspondent's point here where the objective is to simply provide a competent *unix* environment for hosting research apps which heavily depend on scripting and have generally rudimentary GUIs (whose stability is in any case limited by what can reasonably be achieved in a scripting environment like TCL/TK).
So, in the end I agree with Jon's *recommendation* -- if you must have both OSes, then dual boot.
In our lab we have all combinations, and both arrangements of VMWare (linux-in-Win, Win-in-linux) and the hosted environments have one or another set of problems not experienced by the native OSes.
Bear in mind that VMWare's bread-and-butter scenario is a corporate environment where you have a large number of PCs deployed that "normally" need to run one OS, but also have some workflow that critically depends on a corporate app that needs the other OS. In that scenario, the IT dept invests some time working around the idiosyncracies of the corporate app + hosted OS on VMWare.. and that investment is amortized over the large number of users.
This is decidedly different from the scenario here -- work-in-progress scientific apps like FSL where you're on your own to get each variant running in the environment you've chosen. The fact is that apps developed and deployed with the light testing that these apps receive will have bugs.
When you encounter a bug, would you rather troubleshoot those in a vanilla OS environment, or be using a Frankenstein OS environment which might actually be the cause of the problem?
FWIW, for the specific case of FSL under linux in VMWare on Windows... we had continuous problems of FAST crashing, apparently out of memory, which did not occur on native linux. But we regularly run apps (not FSL) directly on Windows with far greater memory demands, with no problems, so I'm inclined to chalk that up to the linux+VMWare aspect of the problem, not Windows per se.
Personally, I have one box for each. :-)
Resources for programmable diagramming at: