Hmmm, I thought I posted a reply but it seems to have got lost somewhere...
Anyhow, I like the Nexuiz gameplay, although it could certainly be improved with some enhancements (to weapons loadouts, maybe the controls, etc). If you have any specific issues it's worth posting on the forums - since it's OSS you can share constructive feedback directly with the developers.
Also, you might like to look at Code Red (I don't have a URL but Google Knows). There are several Code Red games, they run on Linux and they're based on an enhanced Q2 engine (IIRC).
Take a look at Nexuiz. It's a free FPS arena game, complete with a selection of levels, player models, weapons, music, sound effects and a range of AI bots.
The really interesting thing is that its engine is derived from the "Dark Places" engine, which is (in turn) an enhanced Quake I engine. Over the years, the developers of Dark Places and Nexuiz have done an incredible job of bringing this engine up to date and adding high quality eye candy - it's closer to the Q3 engine's capabilities than its modest roots.
Nexuiz is at 1.1 release and is one of those GPL games that really show that OSS gaming can work. It's eaten a lot of my time:-)
What exactly is the issue of it being animal flesh though?
Obviously if you prefer not to eat meat for health reasons then that's a factor. Perhaps also that requiring a "seed" from some real animal encourages people to keep and potentially mistreat animals even if they're not being killed and eaten / having their products eaten / etc?
To my mind (admittedly as a certified omnivore) the requirement for an originator is the only thing that (morally) distinguishes "grown" meat from vegetables. If the answer is simply that the "source" animal could be mistreated then I guess I accept that (event though it seems a little extreme to me). I'd be interested in hearing any other reasons though...
FYI, Intel have already donated code to Xen to support their equivalent ("Vanderpool"), which is due for public release H2 2005. They've also given Cambridge some machines to developer / test on. IBM have also helped out with this effort. Intel in fact contributed the code before even releasing the specs to VT (!).
AMD will also be donating code to Xen - they're discussing right now how best to integrate their code.
VMware's big strength is probably the tools. They'll certainly support VT and Pacifica (I imagine Intel and AMD has teams working with them and with MS). They'll also be introducing a Xen-style paravirtualisation API for VMware-aware guests to achieve better performance - VMM-aware guests are always going to do better than fully virtualised guests that think they're on real hardware.
Hi, I work on Xen but I don't officially represent the project. Anything good I say is the work of a great team, anything stupid I say is my fault... First off: I keep saying this on/. but I'll say it again - VMware _rocks_. It does an incredible task, technically and the management apps rock, from what I've heard: cluster management is very important for enterprise class virtualisation. However, I'd like to compare a few features anyhow... As I have an obvious built-in bias, you _must_ call out anything you think I haven't justified well! I'd be only too happy to respond.
Xen can do any networking trick you can do with Linux, *transparently* to the virtual machines: "teaming" can be done with Linux ethernet bonding, VLANs can be done too, NIC failover should be doable under Linux also.
SAN Multipathing should work since multipathing got merged into the mainline kernel. Xen will support any SAN hardware Linux supports. Again, this is *transparent* to virtual machines.
Hot backups - you can simply take LVM snapshots from the "host" to backup a VM, make CoW disks, etc. Improved support for CoW and cluster-wide virtual disk snapshotting is being worked on.
Live migration under Xen does basically the same job as VMotion - migrate virtual machines whilst they're still running. Xen gets excellent performance doing this - migrating running Quake 3 servers with 60ms downtime, imperceptibly to the grad students playing deathmatch;-)
There is a remote management API using HTTP (Python library provided), however the management tools for Xen need _lots_ of work to get up to the level of quality VMware have set... This is in progress but there's lots still to be done.
* Snapshotting VMs can again be done using LVM in the "host" but this has some limitations, so work is planned to improve this feature.
* Guest OS support - Linux 2.4, 2.6, Plan 9, FreeBSD 5, NetBSD 2 (and current) can all run under Xen, ReactOS is being ported. NetBSD 3.0 and FreeBSD 6.0 are planning to include Xen support natively, as is a Real Soon Now release of mainline Linux. The lacking area is full virtualisation: Xen can't run Windows. This will be fixed by specialised hardware (Intel Vanderpool or AMD Pacifica) or by running QEmu or Win4Lin on top - if you want to run Windows virtual machines with maximal performance on current hardware you should buy VMware, it's that simple. However, it's always going to be better to have a virtualisation-aware OS than do completely full virtualisation - even with h/w assist. VMware are working on a paravirtualised API themselves for this reason
Some work on provisioning virtual machine installs is being done by the distros and by xen-get.org (a sort of "apt for OS installs") but I suspect ACE has the edge there for the timebeing.
Finally, I'd like to point out that Xen is close to zero overhead for most system level benchmarks. Due to licensing restrictions (which I think are not entirely unreasonable) on VMware prodcuts, I don't have numbers for VMware's overheads. Intuitively, though, fooling an OS into thinking it's *not* in a VM requires more effort than not fooling it - VMware will always have to do more work than a paravirtualised solution like Xen, so it necessarily incurs more overhead (for now).
Whilst I'm about it, I should also mention some more things that are under development. Yes, you can always say things are "on the way" (and I'm sure VMware have cool things in the pipe too). Nonetheless this should be arriving in the foreseeable future and since it's an OSS project it's not a secret...
VM replays - there's code for replaying a virtual machine deterministically so that you can watch its lifetime again from any point. A nice trick which should get implemented on top of this is a "backwards debugger", allowing you to set "reverse breakpoints", etc. This has been done for UML in the past.
VM forks - "fork" virtual machines to replicate services
AFAIK AMD and INTEL are making VM monitors. As I understand it AMD Pacifica or IntelVM will compete directly against VMware and Xen. The hardware *will* natively implement virtual machines.
Nope, although early reports seemed to indicate the contrary, the hardware definitely doesn't implement full virtual machines. It gives you the building blocks but lacks the logic to use them (also, virtual devices, etc need to be implemented separately, as do the management tools).
Basically, Pacifica and VT extend the instruction set to close up the "holes" in the x86 architecture that make it hard to virtualise, plus they add some extensions to help with performance and flexibility. That's all however: Intel and AMD appear to be just adding value to their hardware, not competing with existing software.
Both companies have likely developed hypervisors *internally* for testing purposes but haven't expressed any interest in trying to sell them.
HP have contributed code and a port to IA-64 and offered machines also (yey! toys for us:-), Sun haven't contributed to the core code but are porting OpenSolaris, XenSource is (obviously) backing Xen too...
Ummmm, can't think of any other players right now but there probably are some more. Sun, IBM and (maybe) HP are talking about shipping Xen on their systems *in flash* so that they boot natively into Xen.
Pacifica / Vanderpool provide "assists" for a VMM, rather than replacing the VMM. VMware ESX will be able to take advantage of these (eventually), as will Xen - they won't go away.
AMD released its VM simulation software (a preview of its Pacifica technology) today. The new AMD Pacifica technology will allow multiple OS's to run on a single CPU as virtual machines.
Intel is actually a bit ahead of AMD here - they've been shipping real hardware to developers for some time now and are intending to release to the public during H2 this year. We have had Intel VT boxes in Cambridge for Xen work for months (and Intel contributed code to allow Xen to make use of them).
So we've got $180 Billion Intel and $7 Billion AMD
It's important to note that Intel and AMD just want to support virtualisation in hardware but you still need a virtual machine monitor to run on it. This will be something like VMware or Xen - the hardware doesn't natively implement virtual machines, just provides assists for a VMM wishing to do so.
Intel (and AMD, soon) have contributed code to the Xen project and I rather expect they will also have assigned teams to work with VMware and MS to help them support the technology also.
Performance penalty for compute-intensive apps should be near zero on any virtualisation system - that's *relatively* easy. The difficult part is the kernel mode and IO stuff. VMware has to take bigger penalties than Xen for kernel-mode stuff because it must scan and rewrite the machine code before running it (for correctness and isolation). I haven't seen any numbers for this sort of workload on a recent VMware, though.
The IO performance can be fixed (although I understand VMware only support really good IO on their more expensive products) by using virtualisation-aware drivers (same as Xen), so that should perform well.
Things like live clones (VM forks) are underway for Xen. You can also use CoW (using LVM or similar) to share block devices copy on write between several virtual machines.
Another *huge* benefit for the enterprise is the ability to Live Migrate with both Xen and VMware ESX. This allows you to move a virtual machine *whilst running* to another host system.
Imagine evacuating all your servers from another host to other systems before taking it down for maintenance, or load balancing a "virtual server farm" over a cluster of real machines that you can easily add to and rebalance.
Sound like magic? It's not, it's just very cunning;-) You precopy as much state as possible, then stop the virtual machine for a *very* small copy operation of the remaining state before completing the transfer.
Xen can migrate a running Quake 3 server with a 60ms outage (short enough that the grad students in the lab didn't notice the migration).
XP will need hardware support that'll be forthcoming presently... Unfortunately there's not a way round that (other than to use QEmu / Win4Lin under Xen and take the performance hit of those products).
NPTL works under Xen x86_32 but it's better (for performance) if you don't use it. On x86_64 it's fine, doesn't matter to performance. In fully virtualised mode (with hardware support) it doesn't matter either.
But yes, despite my biases for Xen, VMware is also an amazing piece of engineering. Both have advantages and VMware also offer advanced management products right now (XenSource will be offering similar products for Xen soon, I believe).
One of the really big markets for virtualisation is for server consolidation in the enterprise. In these cases, it's very important to achieve strong isolation, as in VMware, Xen, etc.
coLinux is great for compatibility. Some guys also used it recently to get software RAID 5 working over USB disk under Windows - pretty cool:-)
Intel and AMD are introducing new virtualisation-aware chips that'll fix this though. Code (and test machines) have been contributed by Intel to the Xen project (AMD is following suit), so xen-unstable already boots unmodified OSes (not quite Windows yet but it should work soon).
The idea is that Windows will run with good performance in a fully virtualised guest. Once a fully-virtualised guest is up and running, Xen-aware disk and network drivers will be installed within it to boost the performance even more.
In the future, it *might* be possible to fake out the MS paravirtualisation APIs under Xen to get better performance for Windows (depending on licensing and the achievable performance benefits).
For the immediate future, Win4Lin recently announced official support for running W4L Pro on Xen.
Xen support won't be in 2.6.13 but could be in 2.6.14. Basically the hold up is in restructuring to fit with emerging kernel policies on x86-like architectures (i.e. fit them into the i386 directory, instead of forking a separate arch tree as x86_64 did). Once this restructuring is done, the Xen patches should get merged.
"most of the people developing Linux probably sit at night writing up malicious code for windows!"
If this guy thinks droves of Linux developers are also Windows virus writers, he's a bit off target. I can honestly say that: a) I develop Linux kernel code at night, not viruses b) I don't know how to code for Windows c) I don't have a Windows box to test on d) I don't have time to muck about with viruses
I suspect this applies to lots of Linux developers. I don't mind Windows as a system, I just have an utter lack of interest in working on it. And I'd much rather build something useful than something destructive to other people.
The Plan 9 OS (which really was named after the film:-) is under an Open Source license. It's a weird one nobody else uses but it is certified Open, AFAIK.
Not quite Public Domain but good enough for most purposes.
I don't think straight MOL will be so straightforward: x86 is a pig to virtualise. I'd point to VMWare, QEmu and (eventually) Xen as being useful for "Mactel on Linux". The new virtualisation-aware chips from Intel and AMD will also help when they're released.
Yes but not on your existing hardware: running Windows XP will require hardware virtualisation support. Intel and AMD will be releasing this shortly (Q2 this year for Intel, Next year for AMD).
You won't need to wait for XenSE to achieve this, though - one of the Xen 3.x series will probably be able to do everything you want. A number of people are running a firewall in a separate virtual machine using Xen 2.0 (which can't run Windows). You're able to assign the network device directly to the firewall domain for better performance: no need to "double virtualise" the network card:-)
OpenBSD, whilst doable, probably wouldn't be the best choice for the firewall virtual machine: a native Xen-aware OS such as Linux, NetBSD or FreeBSD would be better[*].
[*] assuming there isn't a port of OpenBSD by that stage.
I was present at the XenSE meeting (that's me at the bottom of the list;-) I'd like to clarify exactly what XenSE is and what it isn't:
What XenSE isn't: * it's not Xen's "security issues team". It's not for patching exploits, etc.
What XenSE is: * the "virtual machine monitor" equivalent of SELinux * mandatory access control for virtual machines
- e.g. you might enforce some sort of information flow between virtual machines (e.g. "Top Secret" only talks to other "Top Secret") * enforced from the very lowest levels of the system, so should be very trustworthy
The goal is that the complete XenSE system achieve a higher security rating than currently possible with SELinux alone. The initial prototype of the mandatory access controls has been supplied by IBM and is in the 3.0-testing tree right now. Fully achieving the project's security goals will take considerably longer (Xen 4.0 timeframe).
The original paper from MS Research is an academic-style journal paper. Where does it claim that it's a product, or is that misreporting by some news sites?
MS Research Cambridge is not a product development lab, they're a bunch of smart people who get to play with technology which might be productised *one day*. Taking an existing technology and innovating to make it better is a very important part of research. (but I hope they don't patent it!)
Slashdot Mirror
Hmmm, I thought I posted a reply but it seems to have got lost somewhere...
Anyhow, I like the Nexuiz gameplay, although it could certainly be improved with some enhancements (to weapons loadouts, maybe the controls, etc). If you have any specific issues it's worth posting on the forums - since it's OSS you can share constructive feedback directly with the developers.
Also, you might like to look at Code Red (I don't have a URL but Google Knows). There are several Code Red games, they run on Linux and they're based on an enhanced Q2 engine (IIRC).
The really interesting thing is that its engine is derived from the "Dark Places" engine, which is (in turn) an enhanced Quake I engine. Over the years, the developers of Dark Places and Nexuiz have done an incredible job of bringing this engine up to date and adding high quality eye candy - it's closer to the Q3 engine's capabilities than its modest roots. Nexuiz is at 1.1 release and is one of those GPL games that really show that OSS gaming can work. It's eaten a lot of my time :-)
And then Apple will switch to AMD, right ;-) /me wants an Opteron in his iPod
What exactly is the issue of it being animal flesh though?
Obviously if you prefer not to eat meat for health reasons then that's a factor. Perhaps also that requiring a "seed" from some real animal encourages people to keep and potentially mistreat animals even if they're not being killed and eaten / having their products eaten / etc?
To my mind (admittedly as a certified omnivore) the requirement for an originator is the only thing that (morally) distinguishes "grown" meat from vegetables. If the answer is simply that the "source" animal could be mistreated then I guess I accept that (event though it seems a little extreme to me). I'd be interested in hearing any other reasons though...
FYI, Intel have already donated code to Xen to support their equivalent ("Vanderpool"), which is due for public release H2 2005. They've also given Cambridge some machines to developer / test on. IBM have also helped out with this effort. Intel in fact contributed the code before even releasing the specs to VT (!).
AMD will also be donating code to Xen - they're discussing right now how best to integrate their code.
VMware's big strength is probably the tools. They'll certainly support VT and Pacifica (I imagine Intel and AMD has teams working with them and with MS). They'll also be introducing a Xen-style paravirtualisation API for VMware-aware guests to achieve better performance - VMM-aware guests are always going to do better than fully virtualised guests that think they're on real hardware.
Finally, I'd like to point out that Xen is close to zero overhead for most system level benchmarks. Due to licensing restrictions (which I think are not entirely unreasonable) on VMware prodcuts, I don't have numbers for VMware's overheads. Intuitively, though, fooling an OS into thinking it's *not* in a VM requires more effort than not fooling it - VMware will always have to do more work than a paravirtualised solution like Xen, so it necessarily incurs more overhead (for now).
Whilst I'm about it, I should also mention some more things that are under development. Yes, you can always say things are "on the way" (and I'm sure VMware have cool things in the pipe too). Nonetheless this should be arriving in the foreseeable future and since it's an OSS project it's not a secret...
Nope, although early reports seemed to indicate the contrary, the hardware definitely doesn't implement full virtual machines. It gives you the building blocks but lacks the logic to use them (also, virtual devices, etc need to be implemented separately, as do the management tools).
Basically, Pacifica and VT extend the instruction set to close up the "holes" in the x86 architecture that make it hard to virtualise, plus they add some extensions to help with performance and flexibility. That's all however: Intel and AMD appear to be just adding value to their hardware, not competing with existing software.
Both companies have likely developed hypervisors *internally* for testing purposes but haven't expressed any interest in trying to sell them.
HP have contributed code and a port to IA-64 and offered machines also (yey! toys for us :-), Sun haven't contributed to the core code but are porting OpenSolaris, XenSource is (obviously) backing Xen too...
Ummmm, can't think of any other players right now but there probably are some more. Sun, IBM and (maybe) HP are talking about shipping Xen on their systems *in flash* so that they boot natively into Xen.
Pacifica / Vanderpool provide "assists" for a VMM, rather than replacing the VMM. VMware ESX will be able to take advantage of these (eventually), as will Xen - they won't go away.
Intel is actually a bit ahead of AMD here - they've been shipping real hardware to developers for some time now and are intending to release to the public during H2 this year. We have had Intel VT boxes in Cambridge for Xen work for months (and Intel contributed code to allow Xen to make use of them).
So we've got $180 Billion Intel and $7 Billion AMD
It's important to note that Intel and AMD just want to support virtualisation in hardware but you still need a virtual machine monitor to run on it. This will be something like VMware or Xen - the hardware doesn't natively implement virtual machines, just provides assists for a VMM wishing to do so.
Intel (and AMD, soon) have contributed code to the Xen project and I rather expect they will also have assigned teams to work with VMware and MS to help them support the technology also.
Here's my Xen-oriented take on this:
Performance penalty for compute-intensive apps should be near zero on any virtualisation system - that's *relatively* easy. The difficult part is the kernel mode and IO stuff. VMware has to take bigger penalties than Xen for kernel-mode stuff because it must scan and rewrite the machine code before running it (for correctness and isolation). I haven't seen any numbers for this sort of workload on a recent VMware, though.
The IO performance can be fixed (although I understand VMware only support really good IO on their more expensive products) by using virtualisation-aware drivers (same as Xen), so that should perform well.
Things like live clones (VM forks) are underway for Xen. You can also use CoW (using LVM or similar) to share block devices copy on write between several virtual machines.
Another *huge* benefit for the enterprise is the ability to Live Migrate with both Xen and VMware ESX. This allows you to move a virtual machine *whilst running* to another host system.
;-) You precopy as much state as possible, then stop the virtual machine for a *very* small copy operation of the remaining state before completing the transfer.
Imagine evacuating all your servers from another host to other systems before taking it down for maintenance, or load balancing a "virtual server farm" over a cluster of real machines that you can easily add to and rebalance.
Sound like magic? It's not, it's just very cunning
Xen can migrate a running Quake 3 server with a 60ms outage (short enough that the grad students in the lab didn't notice the migration).
XP will need hardware support that'll be forthcoming presently... Unfortunately there's not a way round that (other than to use QEmu / Win4Lin under Xen and take the performance hit of those products).
NPTL works under Xen x86_32 but it's better (for performance) if you don't use it. On x86_64 it's fine, doesn't matter to performance. In fully virtualised mode (with hardware support) it doesn't matter either.
But yes, despite my biases for Xen, VMware is also an amazing piece of engineering. Both have advantages and VMware also offer advanced management products right now (XenSource will be offering similar products for Xen soon, I believe).
One of the really big markets for virtualisation is for server consolidation in the enterprise. In these cases, it's very important to achieve strong isolation, as in VMware, Xen, etc.
:-)
coLinux is great for compatibility. Some guys also used it recently to get software RAID 5 working over USB disk under Windows - pretty cool
Intel and AMD are introducing new virtualisation-aware chips that'll fix this though. Code (and test machines) have been contributed by Intel to the Xen project (AMD is following suit), so xen-unstable already boots unmodified OSes (not quite Windows yet but it should work soon).
The idea is that Windows will run with good performance in a fully virtualised guest. Once a fully-virtualised guest is up and running, Xen-aware disk and network drivers will be installed within it to boost the performance even more.
In the future, it *might* be possible to fake out the MS paravirtualisation APIs under Xen to get better performance for Windows (depending on licensing and the achievable performance benefits).
For the immediate future, Win4Lin recently announced official support for running W4L Pro on Xen.
Xen support won't be in 2.6.13 but could be in 2.6.14. Basically the hold up is in restructuring to fit with emerging kernel policies on x86-like architectures (i.e. fit them into the i386 directory, instead of forking a separate arch tree as x86_64 did). Once this restructuring is done, the Xen patches should get merged.
"most of the people developing Linux probably sit at night writing up malicious code for windows!"
If this guy thinks droves of Linux developers are also Windows virus writers, he's a bit off target. I can honestly say that:
a) I develop Linux kernel code at night, not viruses
b) I don't know how to code for Windows
c) I don't have a Windows box to test on
d) I don't have time to muck about with viruses
I suspect this applies to lots of Linux developers. I don't mind Windows as a system, I just have an utter lack of interest in working on it. And I'd much rather build something useful than something destructive to other people.
But who won?
I had a scan through http://www.cs.bell-labs.com/plan9dist/license.html
What's the clause you object to? Doesn't it have to be redistributable to be classified as Open by OSI?
The Plan 9 OS (which really was named after the film :-) is under an Open Source license. It's a weird one nobody else uses but it is certified Open, AFAIK.
Not quite Public Domain but good enough for most purposes.
I don't think straight MOL will be so straightforward: x86 is a pig to virtualise. I'd point to VMWare, QEmu and (eventually) Xen as being useful for "Mactel on Linux". The new virtualisation-aware chips from Intel and AMD will also help when they're released.
Yes but not on your existing hardware: running Windows XP will require hardware virtualisation support. Intel and AMD will be releasing this shortly (Q2 this year for Intel, Next year for AMD).
:-)
You won't need to wait for XenSE to achieve this, though - one of the Xen 3.x series will probably be able to do everything you want. A number of people are running a firewall in a separate virtual machine using Xen 2.0 (which can't run Windows). You're able to assign the network device directly to the firewall domain for better performance: no need to "double virtualise" the network card
OpenBSD, whilst doable, probably wouldn't be the best choice for the firewall virtual machine: a native Xen-aware OS such as Linux, NetBSD or FreeBSD would be better[*].
[*] assuming there isn't a port of OpenBSD by that stage.
I was present at the XenSE meeting (that's me at the bottom of the list ;-) I'd like to clarify exactly what XenSE is and what it isn't:
What XenSE isn't:
* it's not Xen's "security issues team". It's not for patching exploits, etc.
What XenSE is:
* the "virtual machine monitor" equivalent of SELinux
* mandatory access control for virtual machines
- e.g. you might enforce some sort of information flow between virtual machines (e.g. "Top Secret" only talks to other "Top Secret")
* enforced from the very lowest levels of the system, so should be very trustworthy
The goal is that the complete XenSE system achieve a higher security rating than currently possible with SELinux alone. The initial prototype of the mandatory access controls has been supplied by IBM and is in the 3.0-testing tree right now. Fully achieving the project's security goals will take considerably longer (Xen 4.0 timeframe).
/me compiled the Amarok beta earlier today.
:-)
It doesn't do the Wikipedia lookup unless you ask it to - normal operation is the same as ever. It works very nicely
The original paper from MS Research is an academic-style journal paper. Where does it claim that it's a product, or is that misreporting by some news sites?
MS Research Cambridge is not a product development lab, they're a bunch of smart people who get to play with technology which might be productised *one day*. Taking an existing technology and innovating to make it better is a very important part of research. (but I hope they don't patent it!)