But what if you paid for Redhat 9, standardized upon it, put a huge developer investment into it, and a year later they tell you it's gone and they want more money (since RHEL was basically 9 with minor changes), or to goto something else that will require another huge developer investment. That is unacceptable, and Microsoft has every reason to bash them over the head for it. Bad business practice, if anything Redhat should have said 9 was the last release and we will support our paid customers who made an investment in it for longer than 1 year and do good by them.
There is no possible way for someone to take missing data and put it back in. With mplayer and it's post processing filters I can make any dvd that has more data than your rip, look better. With a RIP I have less data, no if ands or buts about it, I can make it look better than the original media if I post process the rip but not the original; but I *can't* make it look better than the original if I post process the original as well.
You might want to look again, Nat demoed it for a large audience first time in March of 05, with a targetted release in 06, while Apple demoed it in July 2004, and released it in 2005. Microsoft has been talking about their search functionality for a couple of years as well (with regards to WinFS) So Apple & Microsoft had talked about it before Beagle, Apple demoed it almost a year before Beagle, and Apple released the finished product in their OS just a few months after Beagle's first major demo (Suse officially released Suse 10 just last month). You you like to try again?
And if you are talking about Linux you wait months/years after Apple & Microsoft desktop features are out and you finally copy both of them, but never in a good way... I kid, I kid
But in this case, what protection should there be? Normally it's about protecting confidential sources, to keep them from being afraid to talk to the press; I fail to see how that would apply in this case. Someone videotaping on a public street riot violence, what expectation of confidentiality should these people expect. It would seem that to apply protection to people who were not coming to a person confidentially, where doing acts in plain public view that it cheapens the protection of people who really need to maintain confidential when talking to reporters.
Having the resources to do it and whether or not it's profitable are two separate things. My guess is that they don't expect lots and lots of seats of Mac/Intel Office being sold, so they won't recoup the costs of doing it from scratch. They theoretically could do it from alturistic purposes, but that would be a more than a little bit of a stretch for any public company.
No, I'm not. I'm saying that linking binary blobs into the kernel is a GPL violation, and stable ABIs facilitate and encourage that.
Binary blobs can be GPL compliant too you know, and you do also realize that linking binary blobs into the kernel happens all the time (what exactly do you think glibc does?) God you really are that stupid aren't you.
What part of "a stable API would mean you wouldn't have to recompile your kernel when you changed your hypervisor (or vice-versa), beacuse they wouldn't be linked to each other in the first place" do you not understand?!
Take your bash example from a while back: bash does not rely on a stable ABI to run; all it requires is a stable system call API. A hypervisor should work the same way, not like a kernel module (which is the way they plan to do it, if they're defining an ABI).
That's exactly the point, without glibc you would have to recompile bash everytime you recompile the new kernel, glibc uses a standardized ABI interface to talk to the kernel. Why looky here, old kernels can talk to the VMI layer via a standardized API and talk to the kernel via a standardized ABI. You'd think that someone intentionally thought about that... hmmm....
No it doesn't, as I just said.
Ok rather than just saying you have to recompile a module, prove to me why that would not be the case. Why exactly do you think programs talk to glibc rather than the kernel itself? Have you ever done any actual development, or at least thought about things for a little while?
Your questions can't be answered either "yes" or "no" because they depend on a false presupposition. However, if it were true then of course it would be stupid because it wouldn't be sustainable or maintainable. But it's not true, so the question is irrelevant.
It is true, and you merely saying that it isn't doesn't prove anything. If the kernel never, ever changed it would be the case, but the kernel is dynamic. To fit into your thought process would require the kernel to be as slow moving as glibc, have you ever dealt with systems when they did any major changes to glibc? Is the light coming up now? Do you see what you are saying?
Read it again. He wasn't concerned merely that open source wouldn't benefit; he was concerned that it would hurt
Again, you are decrying horrible, evil things, close to GPL violations and that is the best thing you can come up with? That it makes debugging harder? No statements that it's against the GPL, no statements that it's against the philosophy, no nothing. What you bring to support argument is a statement that it makes debugging harder... dear god, just stop. If that's the criteria.... you are a true idiot, a monumental idiot... no gpl statements, nothing of the sort, just a statement it makes debugging harder... that proves it you must NEVER have done any programming in your entire life. DO YOU NOT THINK THAT ARGUMENT COMES UP IN ALMOST EVERY OTHER PROGRAM KNOWN TO MAN? If that's the requirement, than every single program out there, that's maintained by more than 2 people would be GPL violators, you are truely an idiot. Just stop going down that rat hole because you digging a huge hole, you've officially crossed into idiot land now.
I know damn well what it's for! But the problem is that it has the side effect of introducting unauditable, unsupportable, un-Free binary blobs into the kernel. If we're going to do that we might as well close the whole source and call it Windows! It goes against everything Free Software stands for, and it ought to be a GPL violation (and if it isn't, it's damn close).
Wait so you are saying that if I compile up kernel 2.6.x that has a standardized, stable ABI for a second systems kernel that when I upgrade to kernel 2.6.y that it's close to a GPL violation, even though I'm not using anything non GPL compliant? Are you truely this dense?
No, it would be like having to recompile your kernel modules every time you upgraded the kernel, which is entirely reasonable.
No it would not be like having to recompile your kernel modules every time you upgraded the kernel. I could no longer be testing kernel 2.6.x if I upgrade anything. Everything has to have the exact same kernel patches. Not recompile, insert new virtualization patches specific to the hypervisor onto any old kernels running in the hypervisor. What part of this do your not understand?
You say that as if it's only one, simple thing. It's not. APIs and ABIs are two completely different things; in the case of Linux, the first is OK but the second isn't.
No duh, they are two different things. One is a specification everyone must code to, the other allows a fully GPL compliant kernel to directly talk to another fully GPL compliant kernel, period. If you don't do that you must recompile the kernel everytime you upgrade the hypervisor (the way Xen is today). Do you honestly believe that is a sustainable, maintainable, option? Do you truely believe that it's not in the best interest of Linux to be able to run 2.16.20 & 2.16.22 & 2.17.1 in the same hypervisor? Do you know how stupid that really is?
Notice how he did not address the issue of the GPL at all, but rather just dismissed it? I think it most certainly is about "the open source versus the closed source world," and that VMWare has managed somehow to pull one over on the kernel devs.
Neither did the questioner really address anything about the GPL, he said that some areas closed source would get a new benefit, where open source already had the same benefits. Unless your intent is so zealotist to make intentional out-of-the-norm roadblocks against anything closed, actually causing linux in general pain. There is no GPL violation at all, none whatsoever, elsewise you could have come up with a MUCH better example than someone saying that opensource wouldn't benefit because it already has it. Come on you can do better than that.
I think you are missing the point of what that ABI is there for, that ABI is so that you don't have to recompile the kernel everytime to match things up. Instead of everytime I virtualize something I had to recompile the kernel for the virtual machine, I have a standardized ABI for older and newer kernels to be able to talk to the hypervisor. What VMware proposed an open API framework that anyone could use, which would allow different kernel revs to use a stable ABI to talk to, rather than recompile to the specific hypervisor version. It would be like having to recompile bash everytime you upgraded the kernel to the new specs, a standardized ABI for the guest kernel keeps you from having to do that. It's not specific to VMware, it would be beneficial to everyone (unless you really want to recompile every kernel in every VM everytime you patch your hypervisor). So what really is being debated is the implementation details of that proposal (do memory this way not that way), not the proposal of VMI itself.
If it really was what you seem to think it would be, don't you think that when they proposed it that someone on the kernel mailing list would have been jumping up and down about it? That would be something that someone would have mentioned by at least the 3rd message. Check the thread yourself: http://thread.gmane.org/gmane.linux.kernel/388353
Maybe you should do some more reading, especially since your last post basically admitted that you hadn't been reading anything previously and were speculating.
Then come back here, after you are informed and not speculating anymore, realizing that when the current stable kernel developer says he agrees with VMware's methodology (a common VM layer rather than a specific one to Xen), that you were seriously incorrect. That you are saying that the person responsible for the stable kernel is incorrect because it goes against the philosophy of the kernel. You are just so incorrect it's actually hurting me.
What isn't acceptable? What proprietary code? Are you truely that stupid? Read it again and quote me where it forces the linux kernel to accept proprietary code in the mainline kernel (against the GPL). What it does allow is a standardized way for proprietary & non-proprietary code to be able to talk to the kernel if you want to. Proprietary code in the mainline kerenl... you really aren't that moronic are you? You are intelligent enough to understand the difference?
Simon Crosby, the CTO for XenSource, said: "The VMware team should be praised for engaging an open dialog with the Linux kernel and Xen communities, and they are actively engaging in the process," he said.
Let's look at your post, do you mention an open standard API? nope. Do you mention using Xen's? yes, multiple times infact. What is the issue? Xen has requested Xen specific patches to the kernel, VMware has requested generalized patches to the kernel. If you accept Xen specific kernel patches it kind of makes a generalized interface redundant doesn't it? Why would you ever have a specific Xen interface in the kernel and than a generalized one for everyone else? Do you realize how stupid that would be??? I think you can make the small mental leaps as to implying people to use Xen's interface (you can make those small leaps can't you?)
You understand wrong on the VMware exclusive statement, VMware is not pushing their exclusive one, they are saying that they need a generalized one that can be used by anyone (I'm not sure how you can get more opposite of what you are saying). That way Xen, VMware, or any other can use it; do something different without requiring constant changes.
And you continue to be uninformed, VMware had no technical design boundries hampered by patents, etc they wanted a stable one that anybody could use, go back and read rather than randomly speculate that VMware was trying to make an interface that only their product could use.
If they were fine about the change, than it would have happened months ago, it would have been done already and people would have been coding to what was agreed to and moving on already.
But it's a virtual abstraction that others cannot use, only Xen can use it. You'd rather make a concious decision to choose the Xensource commercial product method be the only way and then force everyone else to make constant shoe-horn changes in the kernel? What kind of stuff are you on here? It's like saying that instead of using http we should have *extended* telnet protocol to be able to not break telnet but support http, it's truely that stupid. If you want a non-stable, constantly changing kernel go with a Xen specific option, if you want something stable that won't require constant changes use a standardized non-specific option that favors neither Xen, VMware, Virtuozo or any other. Why should we choose an option specific to Xen or VMware, how about one that supports both equally well, doesn't require major major changes to the kernel everytime one wants to do something new because the interface was written specific to only one, it only makes sense; the only real reason I can think of objecting to a generalized VM interface rather than having everyone use a specific VM interface coded to a certain product is: that person has a bias for their product to be better than the other, not by out coding them but by stacking the cards in one direction so that others can't be better than the one they are supporting.
But if one looks at the post he put a cause of the problem being Xensource & Microsoft teaming together, when the problem existed *prior* to it. If the problem existed prior, it cannot be the causation, it can be additional factors but it cannot be the causation. If it was only about Xensource & MS getting together than it would have been resolved prior to the announcement, because there was no Xensource & MS. There must be other problems that have been going on longer than that cooperative agreement, that are still unresolved.
Actually VMware suggested a documented, standardized, gernal interface that would allow closed-source binaries to talk to it. Xen want's an interface that is specific to Xen, that only Xen could use, effectively closing VMware and anyone else who would want to do virtualization that is any different than Xen from being in the kernel. If you believe that nobody could ever create a product better than Xen or if you believe that Xen will always have all the possible features that you could ever want in a hypervisor than you should support Xen specific patches in the kernel rather than a general interface.
I suggest you look at the announcement of Xensource & Microsoft and compare that to when the generalized vs Xen specific hypervisor in the kernel issue began, and check and see if the timeline fits. Hint: Xensource announced partnership with Microsoft July 18th, my link above was from April 13th.
That's like saying because it's opensource ReiserFS has to code using the exact same kernel hooks specific ext3 as they are all opensource and do the same thing (filesystem). Or that all network protocols can only talk using the telnet protocol as it's opensource, not patented, everyone must be forced into using just that, no direct use of http, ssh, SIP, etc everything must now be tunneled in the existing telnet process. With both those examples technically it could be done, you could try and force resier to use ext3 specific extentions, you could tunnel all network communication inside a telnet session, but IS IT SMART?
Ever think that maybe one might have a feature set that the other doesn't? Ever think that maybe someone has a different thought than Xen? Ever think that maybe some other opensource project could do something better than Xen? Are you really this short-sighted?
I think the problem was that Xen source was pushing a design that was exclusive to Xen, no other hypervisor could use it's option. VMware, Microsoft, wouldn't be able to use it, it would be custom just to Xen. I guess that you maybe think that the kernel should have 50 or so different hypervisor product specific interface is a better solution than a generalized hypervisor.
True, WhiteBox, CentOS and a number of others, but I'd hazzard a guess that if you are running ESX which only officially supports Redhat Enterprise & Suse Enterprise you probably are in a corporate environment.
Actually you do require a license, as the binaries are copyrighted. You are not allowed to copy the released binaries from system to system, but if you want, you can download the source RPMS's compile them yourself and then do what you will with them. Access for 1x server to the Redhat binaries via RHN is basically the only thing that the ~$350 base license gives you (there is no support after 30days for the base license), you are not legally allowed to install the binaries on another box, you are not allowed to redistribute the binaries, etc.
It'd be hard for you to be more *WRONG*, Redhat has been pushing Xen for quite some time, last year our Redhat rep told us that they want to use Xen so bad that if it passes the muster in Fedora it might come out as an addon to RHEL 4.0. They specifically said to us that it was their intent to have their customers not use VMware anymore. It makes only sense, Redhat requires a license for each VM under VMware or Xen, if they can get 4x the revenue per physical box they'd be stupid not to push for it, rather than having companies try to get things to co-exist on the same install, get them to just pony up for another license. Don't try and mix your different web servers in the same install, just give them each their own instance. With VMware they'd only ever have a limited number of their installations in this extremely profitable position, with Xen every single customer could be possible targets.
VMware datacenter product only supports the enterprise Suse & Redhat products (none of the non-enterprise products), while VMware workstation products support: Mandriva, Mandrake, Redhat, Suse, Turbolinux, Ubuntu, etc. VMware has two different products lines, and look there's Suse and Redhat with two different product lines too, the reason that VMware support those two surely can't be that Suse & Redhat product lines match with VMware product lines, and in can't be that VMware chose RHEL as it's console OS for ESX was because of Redhat's commitment to long lifespan, stability or that there are lots more 3rd party enterprise tools that are certified with it than any other distribution it has to be colusion between the two while they rub their hands together nefariously, that is the only reasonable explanation.
Accredited should mean your average school or else you are going to some place that is teaching out of the back of a van. In the US alone there are over 28,800 accredited schools (at least http://www.accreditedschools.org/ says there are), so your nobody in actuality if we were to use an EXTREMELY low number of only averaging 100 people per school means there are almost 3 million people who would have access to it in the US alone.
Umm why do you think the average virtualization rule of thumb for virtualization is 4x vm's / cpu, when the average utilization of those individually is much less than 25% (actually around 5-10%)? Hello it's headroom, you don't dump bazzillions onto one and run it upto 100% utilization at all time, you run it from 10% up to 50% leaving you ample headroom.
Businesses buy excess superfast machines all the time, majority of businesses in datacenters lease their equipment. Every three years you get to buy a system 3x as fast for an application that was having acceptable response time. A datacenter having 1000x old 700mhz systems, when they go to replace them they can buy 1000x new 4ghz systems, do a massive consolidation effort getting different apps to try and play nice with different libraries or you can virtualize them onto a smaller ammount of servers.
According to gartner the average utilization rate is ~5-10% for x86 servers, the average rate is so damn low saying 75% could be virtualized is a conservative statement, not an aggressive one.
Slashdot Mirror
But what if you paid for Redhat 9, standardized upon it, put a huge developer investment into it, and a year later they tell you it's gone and they want more money (since RHEL was basically 9 with minor changes), or to goto something else that will require another huge developer investment. That is unacceptable, and Microsoft has every reason to bash them over the head for it. Bad business practice, if anything Redhat should have said 9 was the last release and we will support our paid customers who made an investment in it for longer than 1 year and do good by them.
There is no possible way for someone to take missing data and put it back in. With mplayer and it's post processing filters I can make any dvd that has more data than your rip, look better. With a RIP I have less data, no if ands or buts about it, I can make it look better than the original media if I post process the rip but not the original; but I *can't* make it look better than the original if I post process the original as well.
You might want to look again, Nat demoed it for a large audience first time in March of 05, with a targetted release in 06, while Apple demoed it in July 2004, and released it in 2005. Microsoft has been talking about their search functionality for a couple of years as well (with regards to WinFS) So Apple & Microsoft had talked about it before Beagle, Apple demoed it almost a year before Beagle, and Apple released the finished product in their OS just a few months after Beagle's first major demo (Suse officially released Suse 10 just last month). You you like to try again?
l ?tw=wn_tophead_4l
http://www.wired.com/news/mac/0,2125,64069,00.htm
http://www.desktoplinux.com/news/NS9210850677.htm
And if you are talking about Linux you wait months/years after Apple & Microsoft desktop features are out and you finally copy both of them, but never in a good way... I kid, I kid
But in this case, what protection should there be? Normally it's about protecting confidential sources, to keep them from being afraid to talk to the press; I fail to see how that would apply in this case. Someone videotaping on a public street riot violence, what expectation of confidentiality should these people expect. It would seem that to apply protection to people who were not coming to a person confidentially, where doing acts in plain public view that it cheapens the protection of people who really need to maintain confidential when talking to reporters.
Having the resources to do it and whether or not it's profitable are two separate things. My guess is that they don't expect lots and lots of seats of Mac/Intel Office being sold, so they won't recoup the costs of doing it from scratch. They theoretically could do it from alturistic purposes, but that would be a more than a little bit of a stretch for any public company.
No, I'm not. I'm saying that linking binary blobs into the kernel is a GPL violation, and stable ABIs facilitate and encourage that.
Binary blobs can be GPL compliant too you know, and you do also realize that linking binary blobs into the kernel happens all the time (what exactly do you think glibc does?) God you really are that stupid aren't you.
What part of "a stable API would mean you wouldn't have to recompile your kernel when you changed your hypervisor (or vice-versa), beacuse they wouldn't be linked to each other in the first place" do you not understand?!
Take your bash example from a while back: bash does not rely on a stable ABI to run; all it requires is a stable system call API. A hypervisor should work the same way, not like a kernel module (which is the way they plan to do it, if they're defining an ABI).
That's exactly the point, without glibc you would have to recompile bash everytime you recompile the new kernel, glibc uses a standardized ABI interface to talk to the kernel. Why looky here, old kernels can talk to the VMI layer via a standardized API and talk to the kernel via a standardized ABI. You'd think that someone intentionally thought about that... hmmm....
No it doesn't, as I just said.
Ok rather than just saying you have to recompile a module, prove to me why that would not be the case. Why exactly do you think programs talk to glibc rather than the kernel itself? Have you ever done any actual development, or at least thought about things for a little while?
Your questions can't be answered either "yes" or "no" because they depend on a false presupposition. However, if it were true then of course it would be stupid because it wouldn't be sustainable or maintainable. But it's not true, so the question is irrelevant.
It is true, and you merely saying that it isn't doesn't prove anything. If the kernel never, ever changed it would be the case, but the kernel is dynamic. To fit into your thought process would require the kernel to be as slow moving as glibc, have you ever dealt with systems when they did any major changes to glibc? Is the light coming up now? Do you see what you are saying?
Read it again. He wasn't concerned merely that open source wouldn't benefit; he was concerned that it would hurt
Again, you are decrying horrible, evil things, close to GPL violations and that is the best thing you can come up with? That it makes debugging harder? No statements that it's against the GPL, no statements that it's against the philosophy, no nothing. What you bring to support argument is a statement that it makes debugging harder... dear god, just stop. If that's the criteria.... you are a true idiot, a monumental idiot... no gpl statements, nothing of the sort, just a statement it makes debugging harder... that proves it you must NEVER have done any programming in your entire life. DO YOU NOT THINK THAT ARGUMENT COMES UP IN ALMOST EVERY OTHER PROGRAM KNOWN TO MAN? If that's the requirement, than every single program out there, that's maintained by more than 2 people would be GPL violators, you are truely an idiot. Just stop going down that rat hole because you digging a huge hole, you've officially crossed into idiot land now.
I know damn well what it's for! But the problem is that it has the side effect of introducting unauditable, unsupportable, un-Free binary blobs into the kernel. If we're going to do that we might as well close the whole source and call it Windows! It goes against everything Free Software stands for, and it ought to be a GPL violation (and if it isn't, it's damn close).
Wait so you are saying that if I compile up kernel 2.6.x that has a standardized, stable ABI for a second systems kernel that when I upgrade to kernel 2.6.y that it's close to a GPL violation, even though I'm not using anything non GPL compliant? Are you truely this dense?
No, it would be like having to recompile your kernel modules every time you upgraded the kernel, which is entirely reasonable.
No it would not be like having to recompile your kernel modules every time you upgraded the kernel. I could no longer be testing kernel 2.6.x if I upgrade anything. Everything has to have the exact same kernel patches. Not recompile, insert new virtualization patches specific to the hypervisor onto any old kernels running in the hypervisor. What part of this do your not understand?
You say that as if it's only one, simple thing. It's not. APIs and ABIs are two completely different things; in the case of Linux, the first is OK but the second isn't.
No duh, they are two different things. One is a specification everyone must code to, the other allows a fully GPL compliant kernel to directly talk to another fully GPL compliant kernel, period. If you don't do that you must recompile the kernel everytime you upgrade the hypervisor (the way Xen is today). Do you honestly believe that is a sustainable, maintainable, option? Do you truely believe that it's not in the best interest of Linux to be able to run 2.16.20 & 2.16.22 & 2.17.1 in the same hypervisor? Do you know how stupid that really is?
Notice how he did not address the issue of the GPL at all, but rather just dismissed it? I think it most certainly is about "the open source versus the closed source world," and that VMWare has managed somehow to pull one over on the kernel devs.
Neither did the questioner really address anything about the GPL, he said that some areas closed source would get a new benefit, where open source already had the same benefits. Unless your intent is so zealotist to make intentional out-of-the-norm roadblocks against anything closed, actually causing linux in general pain. There is no GPL violation at all, none whatsoever, elsewise you could have come up with a MUCH better example than someone saying that opensource wouldn't benefit because it already has it. Come on you can do better than that.
I think you are missing the point of what that ABI is there for, that ABI is so that you don't have to recompile the kernel everytime to match things up. Instead of everytime I virtualize something I had to recompile the kernel for the virtual machine, I have a standardized ABI for older and newer kernels to be able to talk to the hypervisor. What VMware proposed an open API framework that anyone could use, which would allow different kernel revs to use a stable ABI to talk to, rather than recompile to the specific hypervisor version. It would be like having to recompile bash everytime you upgraded the kernel to the new specs, a standardized ABI for the guest kernel keeps you from having to do that. It's not specific to VMware, it would be beneficial to everyone (unless you really want to recompile every kernel in every VM everytime you patch your hypervisor). So what really is being debated is the implementation details of that proposal (do memory this way not that way), not the proposal of VMI itself.
If it really was what you seem to think it would be, don't you think that when they proposed it that someone on the kernel mailing list would have been jumping up and down about it? That would be something that someone would have mentioned by at least the 3rd message. Check the thread yourself: http://thread.gmane.org/gmane.linux.kernel/388353
Maybe you should do some more reading, especially since your last post basically admitted that you hadn't been reading anything previously and were speculating.
+ for+Linux/2100-7344_3-6061019.html?tag=nefd.top where the current stable kernel developer likes VMware's solution of a non-Xen specific implementation, rather than Xen native and everybody else uses shims into Xen to get into the kernel.
Here's a thought, first start with the actual VMI interface: http://www.vmware.com/interfaces/vmi_specs.html
Read that, and see that it's a standardized API
Then read this again (actually for the first time) that I posted earlier
http://news.com.com/VMware-friendly+change+likely
Then come back here, after you are informed and not speculating anymore, realizing that when the current stable kernel developer says he agrees with VMware's methodology (a common VM layer rather than a specific one to Xen), that you were seriously incorrect. That you are saying that the person responsible for the stable kernel is incorrect because it goes against the philosophy of the kernel. You are just so incorrect it's actually hurting me.
What isn't acceptable? What proprietary code? Are you truely that stupid? Read it again and quote me where it forces the linux kernel to accept proprietary code in the mainline kernel (against the GPL). What it does allow is a standardized way for proprietary & non-proprietary code to be able to talk to the kernel if you want to. Proprietary code in the mainline kerenl... you really aren't that moronic are you? You are intelligent enough to understand the difference?
How about link #1: http://www.eweek.com/article2/0,1895,1996904,00.as p
Simon Crosby, the CTO for XenSource, said:
"The VMware team should be praised for engaging an open dialog with the Linux kernel and Xen communities, and they are actively engaging in the process," he said.
Let's look at your post, do you mention an open standard API? nope. Do you mention using Xen's? yes, multiple times infact. What is the issue? Xen has requested Xen specific patches to the kernel, VMware has requested generalized patches to the kernel. If you accept Xen specific kernel patches it kind of makes a generalized interface redundant doesn't it? Why would you ever have a specific Xen interface in the kernel and than a generalized one for everyone else? Do you realize how stupid that would be??? I think you can make the small mental leaps as to implying people to use Xen's interface (you can make those small leaps can't you?)
You understand wrong on the VMware exclusive statement, VMware is not pushing their exclusive one, they are saying that they need a generalized one that can be used by anyone (I'm not sure how you can get more opposite of what you are saying). That way Xen, VMware, or any other can use it; do something different without requiring constant changes.
And you continue to be uninformed, VMware had no technical design boundries hampered by patents, etc they wanted a stable one that anybody could use, go back and read rather than randomly speculate that VMware was trying to make an interface that only their product could use.
Next time just read a little before posting.
If they were fine about the change, than it would have happened months ago, it would have been done already and people would have been coding to what was agreed to and moving on already.
But it's a virtual abstraction that others cannot use, only Xen can use it. You'd rather make a concious decision to choose the Xensource commercial product method be the only way and then force everyone else to make constant shoe-horn changes in the kernel? What kind of stuff are you on here? It's like saying that instead of using http we should have *extended* telnet protocol to be able to not break telnet but support http, it's truely that stupid. If you want a non-stable, constantly changing kernel go with a Xen specific option, if you want something stable that won't require constant changes use a standardized non-specific option that favors neither Xen, VMware, Virtuozo or any other. Why should we choose an option specific to Xen or VMware, how about one that supports both equally well, doesn't require major major changes to the kernel everytime one wants to do something new because the interface was written specific to only one, it only makes sense; the only real reason I can think of objecting to a generalized VM interface rather than having everyone use a specific VM interface coded to a certain product is: that person has a bias for their product to be better than the other, not by out coding them but by stacking the cards in one direction so that others can't be better than the one they are supporting.
But if one looks at the post he put a cause of the problem being Xensource & Microsoft teaming together, when the problem existed *prior* to it. If the problem existed prior, it cannot be the causation, it can be additional factors but it cannot be the causation. If it was only about Xensource & MS getting together than it would have been resolved prior to the announcement, because there was no Xensource & MS. There must be other problems that have been going on longer than that cooperative agreement, that are still unresolved.
Actually VMware suggested a documented, standardized, gernal interface that would allow closed-source binaries to talk to it. Xen want's an interface that is specific to Xen, that only Xen could use, effectively closing VMware and anyone else who would want to do virtualization that is any different than Xen from being in the kernel. If you believe that nobody could ever create a product better than Xen or if you believe that Xen will always have all the possible features that you could ever want in a hypervisor than you should support Xen specific patches in the kernel rather than a general interface.
I suggest you look at the announcement of Xensource & Microsoft and compare that to when the generalized vs Xen specific hypervisor in the kernel issue began, and check and see if the timeline fits. Hint: Xensource announced partnership with Microsoft July 18th, my link above was from April 13th.
That's like saying because it's opensource ReiserFS has to code using the exact same kernel hooks specific ext3 as they are all opensource and do the same thing (filesystem). Or that all network protocols can only talk using the telnet protocol as it's opensource, not patented, everyone must be forced into using just that, no direct use of http, ssh, SIP, etc everything must now be tunneled in the existing telnet process. With both those examples technically it could be done, you could try and force resier to use ext3 specific extentions, you could tunnel all network communication inside a telnet session, but IS IT SMART?
Ever think that maybe one might have a feature set that the other doesn't? Ever think that maybe someone has a different thought than Xen? Ever think that maybe some other opensource project could do something better than Xen? Are you really this short-sighted?
I think the problem was that Xen source was pushing a design that was exclusive to Xen, no other hypervisor could use it's option. VMware, Microsoft, wouldn't be able to use it, it would be custom just to Xen. I guess that you maybe think that the kernel should have 50 or so different hypervisor product specific interface is a better solution than a generalized hypervisor.
+ for+Linux/2100-7344_3-6061019.html
In addition to the topic links here's another.
http://news.com.com/VMware-friendly+change+likely
True, WhiteBox, CentOS and a number of others, but I'd hazzard a guess that if you are running ESX which only officially supports Redhat Enterprise & Suse Enterprise you probably are in a corporate environment.
Actually you do require a license, as the binaries are copyrighted. You are not allowed to copy the released binaries from system to system, but if you want, you can download the source RPMS's compile them yourself and then do what you will with them. Access for 1x server to the Redhat binaries via RHN is basically the only thing that the ~$350 base license gives you (there is no support after 30days for the base license), you are not legally allowed to install the binaries on another box, you are not allowed to redistribute the binaries, etc.
It'd be hard for you to be more *WRONG*, Redhat has been pushing Xen for quite some time, last year our Redhat rep told us that they want to use Xen so bad that if it passes the muster in Fedora it might come out as an addon to RHEL 4.0. They specifically said to us that it was their intent to have their customers not use VMware anymore. It makes only sense, Redhat requires a license for each VM under VMware or Xen, if they can get 4x the revenue per physical box they'd be stupid not to push for it, rather than having companies try to get things to co-exist on the same install, get them to just pony up for another license. Don't try and mix your different web servers in the same install, just give them each their own instance. With VMware they'd only ever have a limited number of their installations in this extremely profitable position, with Xen every single customer could be possible targets.
VMware datacenter product only supports the enterprise Suse & Redhat products (none of the non-enterprise products), while VMware workstation products support: Mandriva, Mandrake, Redhat, Suse, Turbolinux, Ubuntu, etc. VMware has two different products lines, and look there's Suse and Redhat with two different product lines too, the reason that VMware support those two surely can't be that Suse & Redhat product lines match with VMware product lines, and in can't be that VMware chose RHEL as it's console OS for ESX was because of Redhat's commitment to long lifespan, stability or that there are lots more 3rd party enterprise tools that are certified with it than any other distribution it has to be colusion between the two while they rub their hands together nefariously, that is the only reasonable explanation.
Accredited should mean your average school or else you are going to some place that is teaching out of the back of a van. In the US alone there are over 28,800 accredited schools (at least http://www.accreditedschools.org/ says there are), so your nobody in actuality if we were to use an EXTREMELY low number of only averaging 100 people per school means there are almost 3 million people who would have access to it in the US alone.
Umm why do you think the average virtualization rule of thumb for virtualization is 4x vm's / cpu, when the average utilization of those individually is much less than 25% (actually around 5-10%)? Hello it's headroom, you don't dump bazzillions onto one and run it upto 100% utilization at all time, you run it from 10% up to 50% leaving you ample headroom.
, 00.aspe rgy-costs-at-forefront-of-it.html
Businesses buy excess superfast machines all the time, majority of businesses in datacenters lease their equipment. Every three years you get to buy a system 3x as fast for an application that was having acceptable response time. A datacenter having 1000x old 700mhz systems, when they go to replace them they can buy 1000x new 4ghz systems, do a massive consolidation effort getting different apps to try and play nice with different libraries or you can virtualize them onto a smaller ammount of servers.
According to gartner the average utilization rate is ~5-10% for x86 servers, the average rate is so damn low saying 75% could be virtualized is a conservative statement, not an aggressive one.
http://www.cioinsight.com/article2/0,1540,1914946
http://www.webwereld.nl/articles/41675/gartner-en