Don't you think so, do you? Appropriate functionality is already implemented in host OS and in cloud stack, so what's the reason to add complexity for each VM? Cloud is a new kind of server, the platform for applications with its own specific, and it would be wise to leverage the advantages and write new, cloud apps. That approach is already here: http://www.openmirage.org/ http://erlangonxen.org/

You're right, evolution usually goes spirals. But I have to confess, it's quite exciting to be at the start of the next wreath.

You see, we don't try to avoid OS-level completely. We want to avoid duplication of functionality inside each VM and unnecessary deployment and configuration efforts. That's what Erlang On Xen about.

Thanks, you've got the point precisely.

That would be KVM or lxc way, which also possible :) In our humble opinion Xen has better potential to be a node-level hypervisor for large cloud platforms. It already is, in Amazon, Rackspace, etc., actually, Xen is the standard hypervisor for public clouds. Of course, to be able to run instances in Amazon, we had to start from Xen. Moreover, when you running Xen you don't need to consider Linux-specific process scheduler and memory management, thus there's no need to give up the control on very important things. Migration things from Linux within is also problematic, Xen gives that functionality for no additional cost. In short, there were reasons to choose Xen.

Well, it's not so scary as it may look. Files are accessible through 9p protocol, both servers and clients of which could be implemented very easily. Again, in modern applications we often don't need access to a local file system at all, just to remote database. TCP/IP is implemented inside VM, it's not a problem, and if physical host has a TCP/IP offload card it can be imported from Dom0 through 9p with almost no cost at all. Recently we implemented concurrent block device driver and rudimentary filesystem over it to be able to run local databases, if required. I'm talking about much simpler implementation than you could meet in Linux or Windows, which are more than enough to provide some practical functionality. There is no need to put all complex things inside single VM, you can use remote services instead, and it's really useful now.

Whole "OS-less" and "elastic cloud" stuff sounds like marketing bullshit just because they were supposed to sound like that. And that's it, taking useless shit out is being created the new platform. Aside of fast start Zerg gives an imagination about how resources can be managed in cloud if we use lightweight, mobile VMs, this approach is quite different from traditional one.

Yes, but spreaded over the cloud.

Actually, you can save hundreds of hours of hard work of administrators who have to deploy and maintenance monstrous distributed applications. Erlang On Xen is not about throwing you on bare iron and not a glimpse back to 70s, development for this platform is not different from writing Erlang code for Erlang's standard environment. Erlang On Xen is deployment platform, that sets proper isolation of application code and enables efficietnt re-use of OS-related functionality that already implemented in hypervisor, Dom0 and in cloud services.

If you'd like proper resource usage, go to http://erlangonxen.org/ and press Esc (or click upper right corner of page). There are few hundreds users on site right now ;)

One of these days such systems will appear. I hope we made a step in right direction towards that future.

That's correct. Erlang On Xen is all about proper usage of OS-related functionality already presented by hypervisor, Dom 0 operating system, cloud stack, third-party services in the cloud.

There's no need to use direct calls. All required functionality is already presented in hypervisor, Dom0 OS and cloud stack, Erlang On Xen just uses it properly without doubling the same in every VM.

Well, our approach means that you still have Linux in Dom0. But there is no need to run separate OSes in every VM, unless you run legacy software in it. Erlang on Xen is supposed to be a platform for _new_ applications.

Surely, pidgin English has some charm. And it certainly adds a good weight to the arguments, opponent suddenly feels that he could be eaten if he sounds lame...