We're not a charity or an accredited educational institution. If anyone has a personal contact it might be possible but otherwise we'll just be told to use 180-day demo editions. -Adam
On Feb 13, 2014 7:52 AM, "[email protected]" <[email protected]> wrote: > > This is a long shot, but have we considered actually approaching Microsoft > for a donation of some licenses or even MSDN? Not that it's my preference to > entertain trolls on their own bridges, their nature notwithstanding they tend > to like getting their software into learning contexts. > > > - Alex > > > On Wed, Feb 12, 2014 at 6:32 PM, Mark Jenkins <[email protected]> wrote: >>> >>> Most VM systems actually handle this quite well. >>> >>> Turning up a bunch of WinXP/Win7 VMs that are all running the same >>> software actually chews up a *lot* less memory than you'd expect because >>> of this feature. >> >> >> Wow, didn't know that existed. So freaking cool! >> >> Sounds like this may be very relevant to the discussion I was having with >> Ian last night re Cyber Defense Challenge ridiculous RAM requirements as >> well. >> >> >>> Also, logging multiple users into a single Windows Server isn't anything >>> like UNIX - that's a Windows feature called Terminal Server, which >>> requires separate, additional licensing, and requires significant >>> expertise in Terminal Server to configure correctly. >> >> >> Thanks for letting me know that I should never bother, sticking with >> unix-like systems for true multi-user knowing this! >> >> Attention Skullspace donors -- forget what I said -- don't throw your money >> away to the licensing on Terminal Server, as it sounds so broken that the >> admin labour will *never* be there to put it to use. >> >> Probably easier to scale a Windows lab up in the Skullspace setting by >> calling for with machines with hard drives and using broadcast ghosting. >> >> Though, at the end of day, after all the admin work to do this, it seems to >> me there should be a startup performance advantage with Terminal Server over >> the multiple-VM approach? >> >> You mention a 4-5 hour deploy time -- is that due to the system working hard >> to find shared pages between VMs? That's what it seems like we're talking >> about with the KVM implementation, following your kernel doc link and >> looking at what it links to: >> http://lwn.net/Articles/306704/ >> http://lwn.net/Articles/330589/ >> >> These describes the whole damn thing *searching* for shared pages between >> VMs and comparing them with SHA1 hashes which is pretty intense! You get at >> lot of shared pages automatically when things are happening all under one >> operating system that has active knowledge over its own pages. >> >> Never realized quite how spoiled I am being a unixen for my entire adult >> life. >> >> And until a few years ago, I didn't realize how spoiled the FreeBSD and >> OpenBSD folks have been for a long time with access to containers (one >> kernel, many well isolated userlands where root can be safely used) until I >> started playing with the less mature LXC (linux containers) >> http://linuxcontainers.org/ >> . >> >> One kernel to rule them all, and in the darkness page them. >> >> >> Mark >> _______________________________________________ >> SkullSpace Discuss Mailing List >> Help: http://www.skullspace.ca/wiki/index.php/Mailing_List#Discuss >> Archive: https://groups.google.com/group/skullspace-discuss-archive/ > > _______________________________________________ SkullSpace Discuss Mailing List Help: http://www.skullspace.ca/wiki/index.php/Mailing_List#Discuss Archive: https://groups.google.com/group/skullspace-discuss-archive/
