Virtual instruments and effects run at the very least in their own thread within the host process, and some run as their own process and use a form of IPC to communicate with the host. Sure, the single virtual instrument won't parallelize, but a typical project has dozens of effects/instruments, and a bunch of threads that pretty much just read data from one buffer and write data to another buffer without any inter-dependencies is pretty trivial for the kernel to schedule across as many cores as available.
So, rather than useless MAC filtering, how about doing what's sane and secure: run WPA2-Enterprise and require users to use 802.1x to get on your wireless network. You're either authing user/pass against a RADIUS server (which can hit corporate AD or LDAP) or authing the client cert against an internal CA revocation list, or both. Someone leaves? Invalidate their cert and disable their account. Problem solved.
Take a look at Ubersmith. It's designed for quite a few use cases and is pretty much a complete CRM for ISPs/Telcos/Colo facilities/etc with integration into just about everything.
Yeah, some of the players that have stuck around seem to think that the way people do things in comp are the only way to do things, and have completely lost sight of the fact that it's a game that's meant to be fun first and foremost.
Probably because you haven't used it and the person who modded you has. Diablo 3 at 1920x1200, maxed out, getting 60 FPS in a VM is certainly working 'very well'.
In my admittedly anecdotal experience Diablo 3 runs better in a Parallels Win 7 VM on my MBP than it does natively in OSX. Of course, that's a rare exception because of how poorly optimized D3 is on OSX. Typically with other games I see about 80-85% of the native (dual boot Win7, specifically) framerate when running in Parallels.
Of course, if you're using something like VirtualBox or QEMU, yeah, expect total crap performance. However, VMWare and Parallels devote a lot of time to 3D acceleration and it's very usable in their products.
It's amazing how content you are with ignorance. I'll just go ahead and add you to my "Never met a smart Australian in my life" list and leave it at that.
Ok. Let me lay this out for you, since you're apparently a dunce who can't use google.
How live migration works: 1. Snapshot system memory, live, while the system is running. 2. Transmit snapshot to shared storage. 3. After transmit, load snapshot into RAM on second host. 4. Suspend VM. 5. Send deltas of RAM, to bring second host up to date. 6. Resume VM. 7. Gratuitously ARP out so the switches know where the machine is.
The guest is never shut down. It is never aware it has even been suspended. As far as it, and clients are aware, it just experienced additional network latency for about 1/10th of a second between 4 and 6. During that time, its entire state was transferred to different physical hardware. Now, in many cases, this requires identical, or similar CPUs, but that's trivial.
It's not that complex, and if you were willing to do a bit of research, you'd avoid making yourself look like a total dunce.
I like how you assume I'm a Microsoft shill just because I know what Hyper-V is. You see, I do manage datacenters for a living. My virtualization, however, is entirely XenServer, so, hey, again on the assumptions? See, your problem is that you talk authoritatively on subjects you openly admit you know nothing about.
In a matter of about 1/10th of a second, you can suspend a VM, migrate its state to another host, resume it, gratuitously arp, and thanks to the fault-tolerant design of TCP, things just continue working. If you knew anything at all about networking you'd understand this.
Instead of being a dumbass and saying "Not possible, no way!" why don't you go install XenServer on two boxes, pool them, and see it for yourself? Or, how about simply not opening your mouth on a subject you yourself admit you know nothing about?
See, this is part of Windows Server, which you install on your own hardware, just like XenServer, or VMware, or well, any other operating system. It's not a hosted platform that you can't control that runs somewhere else.
While I have you here, I really would like to know two things: 1. What the fuck are you smoking? 2. Can I have some? Must be some good shit.
To put it very clearly: No. They're not flipping from one guest to another. The same guest, moving from one physical piece of hardware to another, without any interruption at all. Why this is mind boggling to you is beyond me - it's fairly simple, actually, once you realize that we have shared storage (y'know, logical volumes you can access from more than one machine - is that equally incredible?) and very fast network links...
And how exactly do you propose he gets that subdomain from whoever owns last.*? Pretty sure that if you just randomly email whoever owns a domain and say "Hay dood I want subdomain!!!!!111!1one" it won't work, and you certainly can't just go to a registrar and register a subdomain of someone else's domain...
OWA 2010 may as well have been a complete rewrite as far as I'm concerned. It's an incredible difference from 2007. I much prefer it to GMail's interface, and that's running in Chrome - yep, they made OWA fully cross browser with all the fancy features as well. About damn time.
Uhhhh? The company's called Mojang. Scrolls is another game they're working on. 3 seconds with Google would have told you that and spared you however long you wasted writing that up.:|
Sounds like a poorly thought out deployment to me. I used to manage an Exchange deployment with eh, 40,000 users, maybe 50,000? Everything was nearly instantaneous. Hell, all of those clients hit the 16 backend mailbox servers (each with a few Dell MD1000s hanging off of them) through one client access server (they were active/passive failover) with only 4 gigs of RAM. Exchange's requirements aren't nearly as insane as people like to make them out to be, but like anything involving tons of data and many users, it's only going to be as good as your backing storage, which is your weakest link.
They did exactly what the contract says and exactly what they said they'd do: they waived the monthly payment for three months. They didn't waive a portion of the balance, they didn't pay it for you, they waived the minimum monthly payment. As such, if there was interest, you'd have interest charges, and the balance would increase a bit over those three months. There isn't any way whatsoever that "we will waive the monthly payment for 3 months" equates to "we will pay your balance for you."
Nope... He's quite correct. If you're using GiB/Kib, it works out to 797.47 Kib/sec instead. Either way, if you saturate your link it's very easy to go over their cap in just a few days.
Knowing how blue the display on the iPad is, I'd prefer not to show photos on it even if it just had to be "pretty." Personal preference mostly though. A lot of my recent work has been straight up photojournalist, so color calibration doesn't matter as much there as it just ends up in a newspaper or website on someone's uncalibrated display anyway, but I wouldn't imagine I'd use an iPad for that type of work anyway as you can't tag, caption, and transmit photos nearly as quickly on a little tablet like that as you can in say Photo Mechanic.
Even if I had the other whizbangs for editing, cataloging, tagging, etc, I wouldn't use an iPad because I don't know that the image I see will match print. There's no way to calibrate it. Even software calibration would be a slight improvement, but without hardware calibration it's a bust for me and should be a bust for any photographer who takes his or her work seriously.
Slashdot Mirror
Virtual instruments and effects run at the very least in their own thread within the host process, and some run as their own process and use a form of IPC to communicate with the host. Sure, the single virtual instrument won't parallelize, but a typical project has dozens of effects/instruments, and a bunch of threads that pretty much just read data from one buffer and write data to another buffer without any inter-dependencies is pretty trivial for the kernel to schedule across as many cores as available.
So, rather than useless MAC filtering, how about doing what's sane and secure: run WPA2-Enterprise and require users to use 802.1x to get on your wireless network. You're either authing user/pass against a RADIUS server (which can hit corporate AD or LDAP) or authing the client cert against an internal CA revocation list, or both. Someone leaves? Invalidate their cert and disable their account. Problem solved.
Take a look at Ubersmith. It's designed for quite a few use cases and is pretty much a complete CRM for ISPs/Telcos/Colo facilities/etc with integration into just about everything.
Yeah, some of the players that have stuck around seem to think that the way people do things in comp are the only way to do things, and have completely lost sight of the fact that it's a game that's meant to be fun first and foremost.
I'll just leave this here:
http://www.tribesnext.com/
http://www.goonhaven.org/
We still play. Our pub (Goon Haven) has between 10-20 players on at any given time. Even have ladder matches going on pretty regularly!
Probably because you haven't used it and the person who modded you has. Diablo 3 at 1920x1200, maxed out, getting 60 FPS in a VM is certainly working 'very well'.
Where have you been for the past 3 or 4 years? 3D acceleration works very well in VMWare Workstation/Fusion and Parallels Desktop.
In my admittedly anecdotal experience Diablo 3 runs better in a Parallels Win 7 VM on my MBP than it does natively in OSX. Of course, that's a rare exception because of how poorly optimized D3 is on OSX. Typically with other games I see about 80-85% of the native (dual boot Win7, specifically) framerate when running in Parallels.
Of course, if you're using something like VirtualBox or QEMU, yeah, expect total crap performance. However, VMWare and Parallels devote a lot of time to 3D acceleration and it's very usable in their products.
It's amazing how content you are with ignorance. I'll just go ahead and add you to my "Never met a smart Australian in my life" list and leave it at that.
Ok. Let me lay this out for you, since you're apparently a dunce who can't use google.
How live migration works:
1. Snapshot system memory, live, while the system is running.
2. Transmit snapshot to shared storage.
3. After transmit, load snapshot into RAM on second host.
4. Suspend VM.
5. Send deltas of RAM, to bring second host up to date.
6. Resume VM.
7. Gratuitously ARP out so the switches know where the machine is.
The guest is never shut down. It is never aware it has even been suspended. As far as it, and clients are aware, it just experienced additional network latency for about 1/10th of a second between 4 and 6. During that time, its entire state was transferred to different physical hardware. Now, in many cases, this requires identical, or similar CPUs, but that's trivial.
It's not that complex, and if you were willing to do a bit of research, you'd avoid making yourself look like a total dunce.
I like how you assume I'm a Microsoft shill just because I know what Hyper-V is. You see, I do manage datacenters for a living. My virtualization, however, is entirely XenServer, so, hey, again on the assumptions? See, your problem is that you talk authoritatively on subjects you openly admit you know nothing about.
In a matter of about 1/10th of a second, you can suspend a VM, migrate its state to another host, resume it, gratuitously arp, and thanks to the fault-tolerant design of TCP, things just continue working. If you knew anything at all about networking you'd understand this.
Instead of being a dumbass and saying "Not possible, no way!" why don't you go install XenServer on two boxes, pool them, and see it for yourself? Or, how about simply not opening your mouth on a subject you yourself admit you know nothing about?
Oh hey, look, let me Google this one for you too:
http://lmgtfy.com/?q=Hyper-V
See, this is part of Windows Server, which you install on your own hardware, just like XenServer, or VMware, or well, any other operating system. It's not a hosted platform that you can't control that runs somewhere else.
While I have you here, I really would like to know two things:
1. What the fuck are you smoking?
2. Can I have some? Must be some good shit.
Uhhhhh?
To put it very clearly: No. They're not flipping from one guest to another. The same guest, moving from one physical piece of hardware to another, without any interruption at all. Why this is mind boggling to you is beyond me - it's fairly simple, actually, once you realize that we have shared storage (y'know, logical volumes you can access from more than one machine - is that equally incredible?) and very fast network links...
Since you're so lazy: http://lmgtfy.com/?q=live+migration
And how exactly do you propose he gets that subdomain from whoever owns last.*? Pretty sure that if you just randomly email whoever owns a domain and say "Hay dood I want subdomain!!!!!111!1one" it won't work, and you certainly can't just go to a registrar and register a subdomain of someone else's domain...
OWA 2010 may as well have been a complete rewrite as far as I'm concerned. It's an incredible difference from 2007. I much prefer it to GMail's interface, and that's running in Chrome - yep, they made OWA fully cross browser with all the fancy features as well. About damn time.
Well, yeah, but that still can fall under 3 seconds with Google. :P
Uhhhh? The company's called Mojang. Scrolls is another game they're working on. 3 seconds with Google would have told you that and spared you however long you wasted writing that up. :|
Works fine at 5970x1080 for me. \o/
Sounds like a poorly thought out deployment to me. I used to manage an Exchange deployment with eh, 40,000 users, maybe 50,000? Everything was nearly instantaneous. Hell, all of those clients hit the 16 backend mailbox servers (each with a few Dell MD1000s hanging off of them) through one client access server (they were active/passive failover) with only 4 gigs of RAM. Exchange's requirements aren't nearly as insane as people like to make them out to be, but like anything involving tons of data and many users, it's only going to be as good as your backing storage, which is your weakest link.
(1 horsu) Post pointing out the typo "horsu"
They did exactly what the contract says and exactly what they said they'd do: they waived the monthly payment for three months. They didn't waive a portion of the balance, they didn't pay it for you, they waived the minimum monthly payment. As such, if there was interest, you'd have interest charges, and the balance would increase a bit over those three months. There isn't any way whatsoever that "we will waive the monthly payment for 3 months" equates to "we will pay your balance for you."
Nope... He's quite correct. If you're using GiB/Kib, it works out to 797.47 Kib/sec instead. Either way, if you saturate your link it's very easy to go over their cap in just a few days.
Knowing how blue the display on the iPad is, I'd prefer not to show photos on it even if it just had to be "pretty." Personal preference mostly though. A lot of my recent work has been straight up photojournalist, so color calibration doesn't matter as much there as it just ends up in a newspaper or website on someone's uncalibrated display anyway, but I wouldn't imagine I'd use an iPad for that type of work anyway as you can't tag, caption, and transmit photos nearly as quickly on a little tablet like that as you can in say Photo Mechanic.
Two words: color calibration
Even if I had the other whizbangs for editing, cataloging, tagging, etc, I wouldn't use an iPad because I don't know that the image I see will match print. There's no way to calibrate it. Even software calibration would be a slight improvement, but without hardware calibration it's a bust for me and should be a bust for any photographer who takes his or her work seriously.