This is not explicitly a bug, it is more a development issue that becomes apparent in testing.

Winbirch runs *extremely* slowly in a virtual machine. The main issue, i believe, is I/O overhead due to lack of hardware support (not introduced until the i7 generation of chips).

Evidence of this is the fact that it takes 150-200 minutes to install birch in a virtual machine, due to the untar-ing overhead. On a physical machine, installs are usually clocked at less than 10 minutes.

This makes development slow and sluggish as forces a batch-job approach for development.

I recommend we find an old windows box, core2 due generation, for very cheap (~300 dollars), and set it up on a local subnet, using one of our terminals (probably albacore) as a gateway into it (for security reasons - having 2 doors instead of 1). This would reduce I/O overhead, and make local access very quick.

I am however marking this as low priority, as it is a suggestion and not a necessity. As other developers come to winbirch (brian, graham), I just want to bring this up as a potential issue to with the workflow. It exclusively applies to getbirch, and I think it will become a factor in testing binaries on windows, and the installer in general.