Virtualization, 20yrs late. Was: "Death of a firewall" and Xen

[Stewart Stremler]

begin  quoting Tracy R Reed as of Tue, Jul 12, 2005 at 01:03:32PM +0700:
[snip]
> 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?

[snip]
> 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. :)

Yup. :)

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
progress...

[snip]
> > I started reconsidering what 'progress' meant about then.
> 
> I think you should consider "What is an appropriate OS for this
> hardware?"

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
> hardware.

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
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url : http://www.kernel-panic.org/pipermail/kplug-list/attachments/20050712/638f706a/attachment.pgp