Earlier quoted context omitted.
Sorry gentlemen, we had used libvirt and it set some limits. http://erlangonxen.org/blog/glimpse-truly-elastic
> Sorry gentlemen And ladies.
Sure, and ladies, ladies never to be forgotten!
Truly elastic clouds with Zerg: OS-less Erlang on Xen
51–59 of 59 posts
Re: Truly elastic clouds with Zerg: OS-less Erlang on Xen
#52Earlier quoted context omitted.
every instance can export its monitoring information as 9p virtual filesystem, which easily can be mounted from outside we debug server code in BEAM, Erlang on Xen is a deployment platform, if instance crashed we simply restart it. intruder has very few chances to find breaking in beneficial - there's no shell inside which gives only minimal chances to snatch control, instance simply will crash. also, having of no OS…
It mainly mean that instead of using a shell that runs /bin/sh and associated control commands (ls, cat, whatever), you've to bring your own shell code and call the functions yourself. I assume one would write such a loader in erlang that serves a webpage to query any content from the fs, database, etc. Also, IPC seems to be mainly network based, which means latency. Some modern OS designs function with the same base…
> Simple, fast, efficient filesystem (i.e. with features and performance as good as popular databases) - so you don't need a database server
File systems and databases (of any kind) are not 1:1 substitutes.
Re: Truly elastic clouds with Zerg: OS-less Erlang on Xen
#53It sounds like they exchanged one container, an OS managed process, for another one.
The idea behind this systems is that there is no operating system any longer. The programming language runtime is mapped to execute directly on top of the hypervisor. There are already such systems for Erlang, OCaml, Haskell and Java runtimes. If the programming language has a good library, there is no need for an operating system, the hardware access can be taken care by the hypervisor. This leads to safer and faste…
If the hardware access is taken care by the hypervisor, doesn't this imply the hypervisor supports the functionality of device drivers, i.e. the hypervisor has become the OS? Granted, it may delegate the device driver work to a some VM, in which case we're dealing with a microkernel of sorts.
Re: Truly elastic clouds with Zerg: OS-less Erlang on Xen
#54Earlier quoted context omitted.
The idea behind this systems is that there is no operating system any longer. The programming language runtime is mapped to execute directly on top of the hypervisor. There are already such systems for Erlang, OCaml, Haskell and Java runtimes. If the programming language has a good library, there is no need for an operating system, the hardware access can be taken care by the hypervisor. This leads to safer and faste…
If the hardware access is taken care by the hypervisor, doesn't this imply the hypervisor supports the functionality of device drivers, i.e. the hypervisor has become the OS? Granted, it may delegate the device driver work to a some VM, in which case we're dealing with a microkernel of sorts.
In a way yes, the hypervisor is the new OS, although a very thin one.
Some kind of microkernel, yes. With the set of required features for hardware abstraction and virtualization, with everything else being provided by the respective language runtime.
This is much faster than traditional operating system stacks, and may provide a way into bringing microkernels into mainstream OSs.
When using programming languages that come with batteries included, meaning with a good set of libraries for all the usual OS services, then removing a few layers between hardware and application helps running everything faster and increases security due to a smaller set of code.
The guys behind Microsoft's Singularity project are also researching something similar for Windows, a project named Drawbridge, where the full OS runs on a hypervisor as a set of libraries in user space.
Anyway this is nothing new, the idea of a virtualized OS goes back to OS/360, it was just kept away in the mainframe world and is now becoming mainstream.
Re: Truly elastic clouds with Zerg: OS-less Erlang on Xen
#55Isn't this simply an acknowledgement that having an entire OS (at least in a traditional sense) is overkill? I remember a couple of attempts to make the JVM run on bare metal (JavaOS was one if I recall correctly) and I think that, to a lesser extent, ChromeOS, FirefoxOS and company are trying to eliminate some of the bloat that's occurred. The other day I spun up a CentOS6 server on a VM and it required a minimum of…
There are JVMs that run in bare metal, specially in the embedded space.
This was also the Lisp Machines and Smalltalk.
Native Oberon and AOS are also two systems were the language and OS follow the same principles, although the code is usually compiled to native code, or JITted on load.
Re: Truly elastic clouds with Zerg: OS-less Erlang on Xen
#56It sounds like they exchanged one container, an OS managed process, for another one.
Yes. Everything old is new again, it seems. Many old OSes were VM hypervisors in today's parlance--- VM/370 comes to mind; several of the first Unix and other systems I got to play with were virtual machines running on IBM big iron--- and it was also reasonably common to run programs directly in the VM without a guest OS. When I was in school, a common formalism for talking about operating system design was that they…
I consider UNIX the C language runtime in a way. :)
Re: Truly elastic clouds with Zerg: OS-less Erlang on Xen
#57How is Xen better in this context than a general-purpose OS kernel, be it Linux, BSD, or Illumos? For a "truly elastic cloud", what one really needs is a homogeneous pool of host machines on which heterogeneous workloads can be quickly started and stopped. For this, I believe a general-purpose OS kernel is better, even if one dispenses with the usual accompanying userland, because such a kernel is already equipped to…
Because it follows a picokernel model, where it runs an hypervisor directly on top of the hardware to assure the minimal set of hardware integration features.
Everything else not required by your application just wastes hardware resources.
This allows for a higher use of applications per physical machine.
Re: Truly elastic clouds with Zerg: OS-less Erlang on Xen
#58Isn't this simply an acknowledgement that having an entire OS (at least in a traditional sense) is overkill? I remember a couple of attempts to make the JVM run on bare metal (JavaOS was one if I recall correctly) and I think that, to a lesser extent, ChromeOS, FirefoxOS and company are trying to eliminate some of the bloat that's occurred. The other day I spun up a CentOS6 server on a VM and it required a minimum of…
There are JVMs that run in bare metal, specially in the embedded space. This was also the Lisp Machines and Smalltalk. Native Oberon and AOS are also two systems were the language and OS follow the same principles, although the code is usually compiled to native code, or JITted on load.
ARM even implemented hardware java bytecode instruction execution. [0]
I don't think it ever got very far in the market, but I don't know all the reasons behind it.
[0]: http://www.arm.com/products/processors/technologies/jazelle....
Re: Truly elastic clouds with Zerg: OS-less Erlang on Xen
#59Earlier quoted context omitted.
There are JVMs that run in bare metal, specially in the embedded space. This was also the Lisp Machines and Smalltalk. Native Oberon and AOS are also two systems were the language and OS follow the same principles, although the code is usually compiled to native code, or JITted on load.
ARM even implemented hardware java bytecode instruction execution. [0] I don't think it ever got very far in the market, but I don't know all the reasons behind it. [0]: http://www.arm.com/products/processors/technologies/jazelle....
For the same reason Lisp Machines had issues with their special processors.
It is a fallacy that those instructions help execution, in the end general purpose processors are quite capable and you just need a native code compiler instead of trying to execute the bytecodes directly.
So most JITs on ARM just take advantage of the native instructions, or you just make use of a native code compiler for Java if required to do so. Although the general public seems unaware of it, many Java SDKs for the embedded market also offer native compilers, even Oracle does it.