What is up with that?... Come on people. Ron Paul!! He needs more attention. Which candidate wants to get rid of the IRS? Which candidate wants to bring the troops back ASAP? Which candidate wants to abolish the federal reserve (which is neither federal, nor reserve)? Who wants to restore the republic, and the constitution? Who wants to stop policing the world? Come on, there is really only one good candidate... And that is RON PAUL!!
Vote for McCain, and you'll probably be in another new war within the year. I think that was very low to limit the discussion of candidates. What happened to freedom of speech, expression, and the PEOPLE choosing their president?
Ok then, you go apply OpenVZ and any other virtual server project (or all of them) to a kernel and have it work. Good luck! When you are able to do this, then you will be able to say they work together. Until then, you may want to do better research on what your talking about.
Yes, some of the code they are using is probably used used by other virtualization project but you are leaving something out. Each of the server virtualization projects have not been working together. They each impliment things slightly different, and have differences in their abilities and features. Their code is not identical either.
In order to make a patch which supports server virtualization, there are many key aspects of code which are modified. If these projects all came together and decided on setting it up so that all the projects would work together and it was just an option in the kernel to enable which one, that would be awesome, but unfortunatly, that's not what SWSoft is trying to do. They want their version put into the kernel. They don't care about other vserver project, they only care about their own, and their own gets implimented, it creates problems for their competition.
If they could allow all the server virtualizaion project to work together, that would be great, but that's not what is being described here. They want their version to become the one in the kernel. They are not saying that all the virtualization projects should be made into the kernel, they are saying their version should be put into the kernel. Come on, I shouldn't have to explain this to true linux user, they should be able to see through these things, as I hope Linus will do in regards to this project integration request.
If you compile the kernel manually and build your own customized kernel, you would see this. If your a redhat user, or some other distro which makes the kernel for you, you do not need to concern yourself with this issue. If a distro wants to include virtualization into their distro, all they would have to do is apply they patch to their version of the kernel when it is released to a package in the distro software tree. So, users who do that will not be effected by this issue. Only people who know what they are doing and have been custom compiling kernels for years and uses another virtualization projects would be effected by this.
SWSoft uses OpenVZ for their hosting software called Plesk. Other control panels use other virtualization projects. It seems to be SWSoft is trying to make a grab at getting the upper hand in the market by having their project put into the kernel, and not others. If you can't see this, sorry, I have to say I think your being foolish. Each server virtualization project had been designed slightly different, by going with one over the other and including it into the kernel, means the others have big problems, and so does any of the companies which use those other projects.
Each server virtualization project has a different way of managing and controlling the vservers that are setup. Each has different implimentations and setups for pretty much everything they do. Of course all of the projects are going to have some things in common because THEY DO THE SAME TASK!!. If some of the code, as you say, is similar to each other, that is of course beause the projects do the same bloody task. So in order to do something, of course code is going to come up which is similar with other projects, because it's required in order to link those projects into the kernel. You are not looking at the rest of the big picture though. The rest of the project has many differences. The way to enable a vserver, where they are located, what features are setup for them, kind of configuration files control the vservers setup, how the vserver software interacts with all the servers and gets information, and other vserver control structures are completely different.
You impliment one which doesn't work with the others you run into a problem, where everyone who used a different server virtualization
I don't have an "ego", I just believe in voicing ones opinions instead of being a sheepie and following what I am told.
If you knew anything about the linux kernel and how these virtualization patches work you would have understood my statement. It is perhaps not me who "doesn't know what he's talking about", but it is you with the limited knowledge of how these work.
For these virtualization patches to work on a kernel, they have to modify key features and code of the kernel. If you had looked into what your talking about instead of reading some other comments and saying "reading the other posts on this topic does suggest that OpenVZ is a good thing to have". How about you use your own mind and think about this for a moment.
If you want to start talking about how the OpenVZ project works, perhaps you should download and look at the patch code. Look at which files of the kernel code if modifies. If you where smart enough to do this, you would see how much of the kernel this code has to modify. The proc code, seg fault code, kernel calls, traces, init code, bios code, cpu code, and much much more. A virtualization project is not some small single option. It has to modify the network code, processor, ram, and swap usage, as well as much other things.
If you had tried to actually use one of these projects, you would see, they are not realy compatible. Go look at all the different linux virtualization projects and try to use them and you'll see what I am talking about.
I offered solutions to this problem. You could create seperatee trees which use the different project, but to go with one will seriously cause problems for all the other projects. Any current software depending on them would be screwed for upgrading the kernel. You must not be any kind of administrator though, because if you where, and you had worked with this and other projects like it, you would understand.
Perhaps you should go do some reading up and figure out how all the source works with the kernel before you start talking about things you have no clue about.
Although a virtualization project I agree is extremely good, but there is more then one. I use a virtualization project in my company, as do many other companies. SWSoft who makes is the maker of this software is a company which makes hosting software. As many hosting softwares, they and many other hosting project use server virtualization projects. For SWSoft to make they version they use the dominating virtualization project, they are putting a kink in any other peoples projects who use other vserver projects to do the same thing.
This would be like microsoft getting intel and AMD to only work on windows operating systems. They would be putting people who use other products at a major loss, perhaps even collapse. Maybe you should look into these types of marketing issues as well as how vserver projects work and are coded into the kernel.
Leaving these virtualization project as external projects is the way I personally think it should remain. This allows more choice and it causes no problems for anyone. If a distribution wants to include it into their distro, they compile the kernels anyway, they can just include the patch as they do now. It makes no difference to the end user at that point. By them putting these changes into the source, it creates the problems I have mentioned. I'm sure Linus will see this on his own though. Perhaps you should go learn some more about what your talking about before you go and start making claims that I don't know what I am talking about. And instead of resulting to trying to discredit my comments with well... "reading the other posts on this topic does suggest that OpenVZ is a good thing to have". Sorry, reading other comments doesn't make you smart. Research the topic instead of just doing what many others have, just comment on something that you really have no idea on.
PS. If all the vserver projects could come together to allow all of them to work around eachother, that would be great, but I
Not really, just being one of the linux community members, I voice my opinions, I don't sit there with my mouth shut and ignore things that go on around me. As long time linux user, when we see something, we talk about it. Thist post on slashdot is the first post in many years.
Just because I say I would like to contact Linus with an email or something, doesn't mean I think I am more important then anyone else. Although I may have a better chance because I have been using linux for many many years, I'm a system admin, and I have have an impressive resume considering my age. I do not think in any way this makes me better then anyone else, it's just means I am smart enough to speak up about things I believe need to be spoken about.
I myself work on software which uses a VServer modification to the kernel. Although I do see advantages to setting this up so that it's included into the kernel. I see many more problems that this create then the good it would bring through.
Two really big problems I see are these two.
1) There is many other virtual server projects which do the same thing as OpenVZ. If one is included into the kernel, and the others conflict with eachtother over that, that's really going to complicate the linux world. 2) Multiple projects use vserver software currently in project, or they are developing on one of the many different virtual server project. This would cause problems for every one of those peoples project. Companies could loose lots of money because of a foolish decision like this.
The choice should be up to the user, and they should not be restricted to any one server virtualization project. This would get rid of competition over virtual server projects. If they are going to include this virtual server software, they should include all of the current virtual server projects and make them options. Most of them are probably incompatible with eachother, so the code has to make sure those conflicts do not happen.
Maybe an alternative should be to have a patchset made by the OpenVZ which could be given to linux for each kernel release, and multiple trees could be made. A regular kernel, then alternative virtual server kernels.
To allow this to happen would be something like Xorg saying they will only support Intel video cards from now on. Anyone with anything which doesn't have the intel chipset on their video card which is supported is screwed. Or for the linux kernel to only support AMD processors, it just wouldn't make sence. The foolish decision of OpenVZ to request this above all the other server virtualization projects is an extremely greedy and foolish choice I think.
I hope linus says no, or comes and checks the slashdot comments to read this and then tells them no. I may even have to fire him off an email about this.
While I can understand OpenVZ's side of things, overall this would be an extremely bad decision. I hope this never comes to be, for it will be a very sad day.
As for OpenVZ, Quit with the greed, keep your project as a seperate kernel addon to give a more competitive market.
Slashdot Mirror
What is up with that?... Come on people. Ron Paul!! He needs more attention. Which candidate wants to get rid of the IRS? Which candidate wants to bring the troops back ASAP? Which candidate wants to abolish the federal reserve (which is neither federal, nor reserve)? Who wants to restore the republic, and the constitution? Who wants to stop policing the world? Come on, there is really only one good candidate... And that is RON PAUL!! Vote for McCain, and you'll probably be in another new war within the year. I think that was very low to limit the discussion of candidates. What happened to freedom of speech, expression, and the PEOPLE choosing their president?
Ok then, you go apply OpenVZ and any other virtual server project (or all of them) to a kernel and have it work. Good luck! When you are able to do this, then you will be able to say they work together. Until then, you may want to do better research on what your talking about.
Yes, some of the code they are using is probably used used by other virtualization project but you are leaving something out. Each of the server virtualization projects have not been working together. They each impliment things slightly different, and have differences in their abilities and features. Their code is not identical either.
In order to make a patch which supports server virtualization, there are many key aspects of code which are modified. If these projects all came together and decided on setting it up so that all the projects would work together and it was just an option in the kernel to enable which one, that would be awesome, but unfortunatly, that's not what SWSoft is trying to do. They want their version put into the kernel. They don't care about other vserver project, they only care about their own, and their own gets implimented, it creates problems for their competition.
If they could allow all the server virtualizaion project to work together, that would be great, but that's not what is being described here. They want their version to become the one in the kernel. They are not saying that all the virtualization projects should be made into the kernel, they are saying their version should be put into the kernel. Come on, I shouldn't have to explain this to true linux user, they should be able to see through these things, as I hope Linus will do in regards to this project integration request.
If you compile the kernel manually and build your own customized kernel, you would see this. If your a redhat user, or some other distro which makes the kernel for you, you do not need to concern yourself with this issue. If a distro wants to include virtualization into their distro, all they would have to do is apply they patch to their version of the kernel when it is released to a package in the distro software tree. So, users who do that will not be effected by this issue. Only people who know what they are doing and have been custom compiling kernels for years and uses another virtualization projects would be effected by this.
SWSoft uses OpenVZ for their hosting software called Plesk. Other control panels use other virtualization projects. It seems to be SWSoft is trying to make a grab at getting the upper hand in the market by having their project put into the kernel, and not others. If you can't see this, sorry, I have to say I think your being foolish. Each server virtualization project had been designed slightly different, by going with one over the other and including it into the kernel, means the others have big problems, and so does any of the companies which use those other projects.
Each server virtualization project has a different way of managing and controlling the vservers that are setup. Each has different implimentations and setups for pretty much everything they do. Of course all of the projects are going to have some things in common because THEY DO THE SAME TASK!!. If some of the code, as you say, is similar to each other, that is of course beause the projects do the same bloody task. So in order to do something, of course code is going to come up which is similar with other projects, because it's required in order to link those projects into the kernel. You are not looking at the rest of the big picture though. The rest of the project has many differences. The way to enable a vserver, where they are located, what features are setup for them, kind of configuration files control the vservers setup, how the vserver software interacts with all the servers and gets information, and other vserver control structures are completely different.
You impliment one which doesn't work with the others you run into a problem, where everyone who used a different server virtualization
I don't have an "ego", I just believe in voicing ones opinions instead of being a sheepie and following what I am told.
If you knew anything about the linux kernel and how these virtualization patches work you would have understood my statement. It is perhaps not me who "doesn't know what he's talking about", but it is you with the limited knowledge of how these work.
For these virtualization patches to work on a kernel, they have to modify key features and code of the kernel. If you had looked into what your talking about instead of reading some other comments and saying "reading the other posts on this topic does suggest that OpenVZ is a good thing to have". How about you use your own mind and think about this for a moment.
If you want to start talking about how the OpenVZ project works, perhaps you should download and look at the patch code. Look at which files of the kernel code if modifies. If you where smart enough to do this, you would see how much of the kernel this code has to modify. The proc code, seg fault code, kernel calls, traces, init code, bios code, cpu code, and much much more. A virtualization project is not some small single option. It has to modify the network code, processor, ram, and swap usage, as well as much other things.
If you had tried to actually use one of these projects, you would see, they are not realy compatible. Go look at all the different linux virtualization projects and try to use them and you'll see what I am talking about.
I offered solutions to this problem. You could create seperatee trees which use the different project, but to go with one will seriously cause problems for all the other projects. Any current software depending on them would be screwed for upgrading the kernel. You must not be any kind of administrator though, because if you where, and you had worked with this and other projects like it, you would understand.
Perhaps you should go do some reading up and figure out how all the source works with the kernel before you start talking about things you have no clue about.
Although a virtualization project I agree is extremely good, but there is more then one. I use a virtualization project in my company, as do many other companies. SWSoft who makes is the maker of this software is a company which makes hosting software. As many hosting softwares, they and many other hosting project use server virtualization projects. For SWSoft to make they version they use the dominating virtualization project, they are putting a kink in any other peoples projects who use other vserver projects to do the same thing.
This would be like microsoft getting intel and AMD to only work on windows operating systems. They would be putting people who use other products at a major loss, perhaps even collapse. Maybe you should look into these types of marketing issues as well as how vserver projects work and are coded into the kernel.
Leaving these virtualization project as external projects is the way I personally think it should remain. This allows more choice and it causes no problems for anyone. If a distribution wants to include it into their distro, they compile the kernels anyway, they can just include the patch as they do now. It makes no difference to the end user at that point. By them putting these changes into the source, it creates the problems I have mentioned. I'm sure Linus will see this on his own though. Perhaps you should go learn some more about what your talking about before you go and start making claims that I don't know what I am talking about. And instead of resulting to trying to discredit my comments with well... "reading the other posts on this topic does suggest that OpenVZ is a good thing to have". Sorry, reading other comments doesn't make you smart. Research the topic instead of just doing what many others have, just comment on something that you really have no idea on.
PS. If all the vserver projects could come together to allow all of them to work around eachother, that would be great, but I
Not really, just being one of the linux community members, I voice my opinions, I don't sit there with my mouth shut and ignore things that go on around me. As long time linux user, when we see something, we talk about it. Thist post on slashdot is the first post in many years. Just because I say I would like to contact Linus with an email or something, doesn't mean I think I am more important then anyone else. Although I may have a better chance because I have been using linux for many many years, I'm a system admin, and I have have an impressive resume considering my age. I do not think in any way this makes me better then anyone else, it's just means I am smart enough to speak up about things I believe need to be spoken about.
I myself work on software which uses a VServer modification to the kernel. Although I do see advantages to setting this up so that it's included into the kernel. I see many more problems that this create then the good it would bring through.
Two really big problems I see are these two.
1) There is many other virtual server projects which do the same thing as OpenVZ. If one is included into the kernel, and the others conflict with eachtother over that, that's really going to complicate the linux world.
2) Multiple projects use vserver software currently in project, or they are developing on one of the many different virtual server project. This would cause problems for every one of those peoples project. Companies could loose lots of money because of a foolish decision like this.
The choice should be up to the user, and they should not be restricted to any one server virtualization project. This would get rid of competition over virtual server projects. If they are going to include this virtual server software, they should include all of the current virtual server projects and make them options. Most of them are probably incompatible with eachother, so the code has to make sure those conflicts do not happen.
Maybe an alternative should be to have a patchset made by the OpenVZ which could be given to linux for each kernel release, and multiple trees could be made. A regular kernel, then alternative virtual server kernels.
To allow this to happen would be something like Xorg saying they will only support Intel video cards from now on. Anyone with anything which doesn't have the intel chipset on their video card which is supported is screwed. Or for the linux kernel to only support AMD processors, it just wouldn't make sence. The foolish decision of OpenVZ to request this above all the other server virtualization projects is an extremely greedy and foolish choice I think.
I hope linus says no, or comes and checks the slashdot comments to read this and then tells them no. I may even have to fire him off an email about this.
While I can understand OpenVZ's side of things, overall this would be an extremely bad decision. I hope this never comes to be, for it will be a very sad day.
As for OpenVZ, Quit with the greed, keep your project as a seperate kernel addon to give a more competitive market.