Well glad to hear it worked out well for you anyway. I like to think I'm not petty enough to not hire someone for proving me wrong, but we are only human. :)

Countered the one vote, not sure why that one had to happen. That's pretty funny stuff if you ask me.

I would recommend this, makes window switching easier: http://www.makeuseof.com/tag/virtualboxs-seamless-mode-combine-operating-systems-desktop/[^] ===== \ | / \|/ | |-----| | | |_ | _) | / _) __/_ _) ____ | /| | / | | | |-----| | ===

:wtf: Too late. Have I started down a non-productive path with no hope of recovery?

Yes, of course, we stopped killing people using the chair, it is too heavy, it gets broken and the invoice from the laundry puts things in prespective... :sigh: [www.tamautomation.com] Robots, CNC and PLC machines for grinding and polishing.

Or you come here[^]. We have the right kind of glas for that :) At least artificial intelligence already is superior to natural stupidity

Vaughn Bigham wrote: 'we can't get the alpha and beta testers in if its all locked down first.' If the security isn't in the system by the time alpha or beta testing is being conducted, then that testing is hardly valid, is it? :doh: Assuming that your quote is an accurate representation of your colleagues concerns, the following thoughts may be helpful... Unless you've also got gamma, delta and a whole Greek alphabet of testing stages, then you and your team likely share (an approximation of) the following sense of what alpha and beta testing are about:       * beta is it really should be ready for release, but we know there are (likely to be) bugs and/or usability problems that real use will shake out, and       * alpha is it's basically done; we know it's real shaky and there are some features we're not sure whether to polish up or kill, but it's enough like the real deal that real-world evaluation will be valuable Going by those definitions (or even something close to them), without a functioning security infrastructure the product is just not complete and you're not ready for alpha, let alone beta, testing. So the rest of the team (if they even come close to those definitions) need to rethink their justification for holding off on security. Going back to the quote: Vaughn Bigham wrote: 'we can't get the alpha and beta testers in if its all locked down first.' A finished, released, product needs to be able to add the first user - so the experience of "it's all locked down" can never be a condition that applies to a finished product. If security is present and you can't add testers to the system, perhaps you need to ask "what is the intended means of adding the first administrative user in the finished product?" and then redefine the scope of "security" so that adding the first user to the system is a security issue, not a content issue. Once the ability to add the first admin user is defined to be a security behaviour, not a 'content' behaviour, then the first round of (unit) testing would be to verify that the security architecture is valid and complete ... and all subsequent rounds of unit, integration and alpha and beta testing build upon it (instead of requiring it to be delayed until the last minute).