Jose R R wrote: > [...] >>>> Ok, that's nothing I would have expected, from my limited experience with VMs. >>>> VMware, you install the "guest" o/s in the VM, and it doesn't have to know >>>> anything about the VM host. >>> Xen guest paravirtualization, i.e., when the guest or DomU "knows" >>> that it is being virtualized, provides the closest to native hardware >>> performance. Accordingly, open --hence modifiable or capable of being >>> "Xenizied"-- kernels like that of GNU/Linux are the ideal for the >>> so-called cloud computing platform or delivery mechanism. >>> >>> The performance of Software as a Service (SaaS) applications, being >>> served/delivered through the cloud platform, is dependent on the >>> qualities of underlying infrastructure, of which virtualization plays >>> a prominent role. Neither proprietary, closed source, technologies as >>> those by VmWare or MS HyperV, can provide the level of flexibility >>> and/or performance as that enabled by open source Xen technology. >>> >>> Additionally, interoperability and deployment of virtual machines >>> hosting business applications among the different cloud computing >>> providers, including those of private clouds, decreases significantly >>> if closed source, self-serving proprietary virtualization enabler >>> infrastructure technology prevail. >>> >> On the other hand, given ESGLinux's problems, *requiring* knowledge of the host >> o/s can result in more problems. It also seems to me that that same knowledge >> would provide hooks for intrusion into the host o/s. > > This issue has been addressed at length --please, search relevant > keywords. The fact that proprietary technologies like VmWare do not > disclose in the open their security issues does not leave them out of > similar security issues. Sorry, I thought we were just having such a discussion. > >> For that matter, the whole concept of an o/s, as I was taught it, lo, these >> many years ago, was that the programs running on it did *not* have to have >> knowledge of the hardware, but made standardized calls to the API's of the o/s, >> which provided the services required. >> > That was when x86 technology was still a "creature." Now, in spite of > its obvious limitations, it wants to "grow" and emulate an feature of > the mainframe. I beg your pardon. This was in the late seventies and early eighties, and we were discussing *mainframes* in school. Everything I've learned on mainframes, mid-frames, and micros has only reinforced such an attitude. For example, from Macaholic friends, I heard how when Mac went from the Motorola chips to the IBM PowerPC chips when, in the nineties? it *broke* M$'s Word for the Mac; when folks investigated, they found that M$ Word was such a *dog* that to get acceptable performance, M$ had made direct hardware calls, bypassing the o/s. BAD. Not acceptable. And that's true for *any* platform, other than someone's lab breadboard. > >> Then there's another issue, that being that I am *very* unconvinced of the >> wonderfulness of cloud computing. If it were being offered via an intranet, to >> use spare resources inside an organization, that's one thing (I'm thinking of >> something along an expanded version of Seti-at-home); but as soon as it's out >> of my control, the guaranty of both data security and availiblity becomes >> questionable. >> > Current economic conditions are dragging conservative attitudes into > outsourcing their IT plumbing and cloud computing does exactly that. > The proliferation of cloud computing platform delivery mechanism > providers, of which Amazon EC2 is the poster child, should start > smashing those artificial attitudes. Sorry, I don't understand what you're saying here. If I read it one way, you're attacking my attitude. If I read it another, you're attacking the use of cloud computing. Kindly rephrase. mark -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
