Virtualization, 20yrs late. Was: "Death of a firewall" and Xen
bofh at stremler.net
Tue Jul 12 09:59:00 PDT 2005
begin quoting Tracy R Reed as of Tue, Jul 12, 2005 at 01:03:32PM +0700:
> You cannot talk about the performance of virtualizing without mentioning
> what kind of virtualization and whose implementation we are talking
> about and then if you want to be really pedantic we can talk about what
> kind of uses. For generalized use they vary wildly in performance.
> Emulating another cpu type of virtualization is the slowest. Then we
> have VMWare and then User Mode Linux. With Xen finally coming in as
> fastest. IBM's MVS style virtualization is probably right in there with
> Xen as far as speed goes but it's hard to say since mainframe
> architecture is wildly different.
True. I was considering emulation as its own "virtualization technique",
restricting 'virtualization' to the high-end meaning.
So what term do you suggest for the minimally-emulated virtualization?
> I think we have quite a bit to show for it (I think the Internet and
> sharing photos with my family via my webpage is nice).
That's just bandwidth and connectivity. Nothing whatsoever to do with
CPU performance. We have taken advantage of bandwidth improvements,
and I value those.
> But you and I
> obviously value different things. :)
I value stablity, reliablity, robustness, choice, and a sensible UI.
"New" doesn't automatically imply "Improved."
I infer that you value newness, performance, ubiquity, and cost.
It probably takes a blending of our values to achieve worthwhile
> > I started reconsidering what 'progress' meant about then.
> I think you should consider "What is an appropriate OS for this
One would think the answer would be "Linux", no?
> as the newer RedHats clearly offered a lot more functionality
> but that level of functionality were not intended for that sort of
Actually, no, they did NOT offer a lot more functionality.
> I think if you had your way the default install of any OS
> would be able to run on your 7Mhz Atari and if we wanted anything else
Get yer facts straight. Atari STs were 8MHz.
> to take advantage of the new machine we just bought with a cpu two and a
> half orders of magnitude faster we would have to download it separately.
While I think you would have people buy a new machine every three months
just so they could run the latest and greatest, presumably by using a
clock circuit that gradually decayed to slower and slower speeds to really
drive the point home. After all, hardware is dirt-cheap these days.
Screw the user. Make 'em pay, and pay again, and pay again, just so that
the open-source developers don't have to actually think about anything
other than appearing cool.
> > I think it's a matter of user expectations. The average user will put
> > up with a certain amount of pain, and so that's what we get. If they'd
> > put up with any more, we'd get that instead.
> The average user these days is accustomed to bitmapped displays and a
> certain level of ease of use that was not available on your 2e. For
You're confusing people again. I never owned an Apple 2e.
> example hardly anybody memorizes keystroke combinations to save files
> etc anymore.
Cite? Everyone I've come across who works with a computer has memorized
at least the basic keystrokes for common operations.
> Nobody would care to use AppleWriter or whatever you used
> on your 2e because they would word process more slowly with that than
> they would with a modern PC. In that case it was the user that was too
> slow, not the hardware.
So people _were_ stupid back in the day, and everyone else was just too
stupid to see how stupid everyone else was! I see! It's all so clear!
They had slow hardware because they couldn't type very fast or think
very well! The past was peopled by idiots. Amazing how far we've come...
-Stewart "The sin of youth: to think those who came before were stupid" Stremler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 232 bytes
Desc: not available
Url : http://www.kernel-panic.org/pipermail/kplug-list/attachments/20050712/638f706a/attachment.pgp
More information about the KPLUG-List