 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gail wrote:
>
> No one ever suggested that MS's marketing dept was 'honest'. I've heard
> a couple of MS developers complaining about the massaged facts the
> marketing dept was pushing.
Yep.
I haven't used Hyper-V, so I won't say anything about it's quality. It
might suck, it might be superior, or anything from between. I won't even
say sure that it's compareable with Xen or ESXi.
It just annoys me while MS continously gets innovations of "new, unseen
technology" which I'm (or someone else if I know for sure) already using
and is just unknown for most of the people. Marketing ranting :).
--
Eero "Aero" Ahonen
http://www.zbxt.net
aer### [at] removethis zbxtnetinvalid
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Eero Ahonen" <aer### [at] removethiszbxtnetinvalid> wrote in message
news:48bc1d26$1@news.povray.org...
>
> I'd probably go with the latter one. Probably, not surely.
Very likely. Though, as always, test carefully.
> Hyper-V is still pretty new and at least I wouldn't be sure if they have
> actually had the time to test it enough. I'd guess the support on Hyper-V
> would get better after some time.
I hope so. There's enough companies fully aboard the vitualisation train
already, many without checking to see if there's coal, if the wheels are
about to fall off or if it's going in the direction they want. <grin>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gail wrote:
>
> Very likely. Though, as always, test carefully.
>
Yep.
> I hope so. There's enough companies fully aboard the vitualisation train
> already, many without checking to see if there's coal, if the wheels
> are about to fall off or if it's going in the direction they want. <grin>
As you said: test carefully ;). MS is a big player after all, so before
they give theier support (which practically means they promise it'll
work) for such a thing, they'll need to be pretty sure of it. The surer
they are, the happier will customers be and the better they'll sell.
--
Eero "Aero" Ahonen
http://www.zbxt.net
aer### [at] removethiszbxtnetinvalid
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> I'd probably go with the latter one. Probably, not surely.
>
> Very likely. Though, as always, test carefully.
Wait a sec - small firm, just started up, *testing*???
From what I've seen most *large* companies don't bother to test
anything, never mind small startups. ;-)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> One might argue that if MS were to be "honest" about their products,
>> they'd never sell any because they all suck so much...
>
> Not all of them.
> You're generalising to a hell of a lot of stuff that you've probably
> never used based on your experiences with a couple.
Perhaps. But you might argue it's fitting for their most popular
products (which, presumably, are where they make most of their money).
It wasn't intented to be a serious statement. MS's reputation is the
stuff of legend - I'm sure we've all been there and done that.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> So when you say "works on any reasonably modern PC", what you *actually*
> mean is "works on any brand new bleeding-edge PC"?
No. I believe it was the 386 that added the capability.
You know, two generations back before the Pentium came out?
Added primarily to emulate multiple "DOS boxes" under Windows.
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Eero Ahonen wrote:
> similar as in Xen
As far as I understand it, an OS running under Xen has to know it's
running under Xen, doesn't it? It's actually quite a large leap from
"we can run multiple OSes" to "we can run multiple OSes that don't have
to cooperate with the hypervisor".
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> But surely if you're going to run a guest OS on the physical host CPU,
> the host CPU would need to have hardware support for enforcing the host
> seperation?
Nope. You don't *need* it. You can, for example, get a chunk of code the
guest is trying to execute, translate the little parts that need changing
to provide security and enforcing host separation, then run it. (I don't
even know assembler, so actually I have no idea what I'm talking about)
VMware Inc has dozens of patents on different tricks to do that efficiently.
And yes, there are *also* CPUs (64-bit Intel and AMD CPUs you can buy at any
shop) that include built-in support for virtualization. That just gives you
more performance; doesn't really let you do anything you couldn't do
before...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Until yesterday, I had always assumed that any kind of emulation or
> virtualisation solution would be roughly 1,000,000x slower than native
> execution, so it's not something I've ever been interested in. Hence
> it's something I know almost nothing about. However, since it appears
> that you can actually run real software at almost native speeds,
> suddenly it becomes far more interesting... ;-)
There is an emulator for PowerPC processors called PearPC.
It has two modes. One is an actual interpreter. Runs anywhere; it's quite
portable C code. 500x slower than native.
The other mode is only for x86 hosts. Translates PowerPC instructions into
x86 instructions on-demand, and caches the translations. 15x slower than
native.
I have also seen an IBM PC emulator written in Java. It was pretty fun to
see Linux and DOS boot inside a browser (even though the RAM usage was
insanely high). But even Lemmings under DOS ran at slow motion in that
emulator...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> A hundred maybe, but a million?
>
> Last time I checked, the IA32 instruction set is *very* complex. I doubt
> it's got any simpler since then...
But still, presumably you write your emulator in such a way that the most
common instructions (that usually take 1 or just a few clock cycles) are
emulated as fast as possible.
I would guess emulation is a prime candidate to be written in assembler,
where you can just have a huge branch table for each instruction type, then
jump the real CPU program counter into that table based on the op-code. In
that way, I would imagine you can get away with even a factor of 10
slow-down for the common instructions.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
