Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

A Glimpse of a Truly Elastic Cloud

timothy posted 1 year,26 days | from the nice-to-meet-you-goodbye dept.

Cloud 201

New submitter cloudozer writes "Virtual servers in the future may stop using OSes entirely. As recently demonstrated OS-less platforms may change our understanding of how long does it take to bring a server up. A demo server gets created, booted up, configured, runs an application and shuts down in under 1 second. Radically lower startup latency means that the computing infrastructure may be woven strictly on demand, during the processing window allotted for a given request. Currently cloud providers round an instance uptime to the full hour when calculating charges. They might need to switch to per-second billing if OS-less instances get traction. The demo uses a new Erlang runtime system capable of running directly on Xen hypervisor."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered


A runtime system is an OS (5, Insightful)

Anonymous Coward | 1 year,26 days | (#43261617)

If you don't need much from your OS, then trim the OS down. That doesn't mean you're not using an OS. Unless you run bare-metal code, you are using an OS.

Re:A runtime system is an OS (5, Funny)

Anonymous Coward | 1 year,26 days | (#43261809)

No kidding. Are we going to allow application programmers to start making direct calls to the hardware? If so, then kill me now. Use a spoon if you have to, it will be more merciful.

Re:A runtime system is an OS (1)

vsov (2874465) | 1 year,26 days | (#43262071)

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.

Re:A runtime system is an OS (3, Funny)

Anonymous Coward | 1 year,26 days | (#43262107)

So, the os then.

Re:A runtime system is an OS (1)

vsov (2874465) | 1 year,26 days | (#43262131)

Yes, but spreaded over the cloud.

Re:A runtime system is an OS (-1)

Anonymous Coward | 1 year,26 days | (#43262163)

Just use Google App Engine?

You also get the cloud feature of Google deciding to kill Google App Engine a few years later because of declining usage/profit.

"stop using OSes"? (5, Insightful)

1u3hr (530656) | 1 year,26 days | (#43261637)

What gibberish is this? There is an OS, presumably Xen. Unless we're returning to the 1940s and wiring up tubes to make programs, there is an OS.

Re:"stop using OSes"? (1)

PTBarnum (233319) | 1 year,26 days | (#43261685)

I think this means no guest OS. You can argue about whether the Erlang runtime constitutes an OS of sorts, but in their example they are not booting a general purpose kernel. Presumably they could port this to run on bare metal instead of Xen, although the boot times for physical hardware would never be as good as starting a new Xen instance.

Re:"stop using OSes"? (5, Insightful)

julesh (229690) | 1 year,26 days | (#43261803)

You can argue about whether the Erlang runtime constitutes an OS of sorts

AFAICS there's no argument at all. It is an OS; not a particularly good one, but one that provides scheduling, interprocess communication (albeit for what we'd traditionally consider to be threads rather than processes, but due to Erlang's memory/threading model there's actually no real distinction), memory management, and abstraction of IO (albeit somewhat simplified from the approach taken by a typical modern OS).

Re:"stop using OSes"? (0)

Anonymous Coward | 1 year,26 days | (#43262117)

So what you're saying is that they've reinvented the microkernel! Somebody call Andrew Tanenbaum [wikipedia.org]!

Re:"stop using OSes"? (2)

Bert64 (520050) | 1 year,26 days | (#43262155)

So loading up just the code required for the application, rather than loading an entire general purpose kernel and userland on top of it...
Sounds like just running your app on a multiuser server in the traditional way, only with some level of sandboxing...

So instead of xen, just use a standard multiuser os, the user logs in, perhaps over ssh, and runs their app, and logs out when done.
As an added advantage, existing os already have the facilities to account for resources used on a per user basis.

Re:"stop using OSes"? (1)

muon-catalyzed (2483394) | 1 year,26 days | (#43261709)

There many applications that run without an "OS", sometimes even made to fit inside the CPU's cache, big advantage is that no OS overhead is involved, lots of dedicated console setups or micro controller software uses such configuration for example.

Re:"stop using OSes"? (1)

Anonymous Coward | 1 year,26 days | (#43261787)

Performing the rare task of RTFA and then stripping it of gibberish, bad nomenclature and "Gee Whiz!" I find that the author does have a nice idea at hand.

The problem is that they came up with this scheme ages ago, and more or less ironed out the wrinkles. Just change a few words in the original artice: replace "virtual server" with "application" and you're good to go.

Sure does sound impressive, though.

Re:"stop using OSes"? (5, Informative)

ls671 (1122017) | 1 year,26 days | (#43261805)

Unless we're returning to the 1940s and wiring up tubes to make programs,

I had a few games on bootable floppies back in the original PC days, around 1985. The floppies would boot up the computer right into the game so there was no OS involved. And no, BIOS is not some kind of bisexual OS, it stands for Basic Input/Output System.

Re:"stop using OSes"? (0)

Anonymous Coward | 1 year,26 days | (#43261959)

Theres still something that read binaries from disc, load in memory and pass control. A no-OS machine would have the binary of the program already in memory, and jump to the program as the first intruction the CPU execute.

Re:"stop using OSes"? (1)

zAPPzAPP (1207370) | 1 year,26 days | (#43262027)

That would be called a bootloader.

Many OS-less plattforms have bootloaders.

The thing about them is, no matter what features the bootloader has, once it passes control, they are of no use to the loaded program (unless you do some adr jump magic... maybe).

Re:"stop using OSes"? (-1)

Anonymous Coward | 1 year,26 days | (#43262005)

I thought BIOS meant Built In Operating System.

Re: "stop using OSes"? (-1)

Anonymous Coward | 1 year,26 days | (#43262029)

The bootable floppies still have an OS. In the early PC days that most likely would have been DOS.

Re: "stop using OSes"? (1)

ls671 (1122017) | 1 year,26 days | (#43262055)

Nope, they were floppies written in assembly. The idea was indeed to get rid of the OS to eliminate overhead so the game could achieve more with less. There was no DOS code on them at all.

Re: "stop using OSes"? (0)

Anonymous Coward | 1 year,26 days | (#43262169)

Nope, they were floppies written in assembly. The idea was indeed to get rid of the OS to eliminate overhead so the game could achieve more with less. There was no DOS code on them at all.

Can you give a more specific example how this would work? The boot code on the floppies is not OS-like because? And the game does not reuse any input/output libraries throughout (eg. contain OS-functionality the game uses)?

Re:"stop using OSes"? (0)

Anonymous Coward | 1 year,26 days | (#43262159)

Why 1940 and tubes? What's wrong with PIC and ATmega?

Link? (1)

Moloth (2793915) | 1 year,26 days | (#43261643)

The second link goes into the void.

Re:Link? (0)

Anonymous Coward | 1 year,26 days | (#43261665)

They meant for it to head off to the demo page on the top link. All that does is kick off an example that prints up the page that it displays for which is basic using the Ling VM under the XEN hypervisor.

The details that it gives you are:

Details for technically inclined

The breakdown of what happened during the request processing:
Phase Duration Notes
A 702.5 ms An HTTP GET request received by nginx. The request is temporarily forwarded to the 'spawner' application. The spawner asks Xen via libvirt daemon to launch a new instance. The new instance gets created and is ready to boot.
B 14.0 ms The LING VM starts to execute. It performs all preparatory steps needed to run Erlang code. Control reaches the main emulator loop. Erlang code starts to run.
C 260.0 ms init:boot() is entered and the standard Erlang boot sequence is performed. Many standard servers, such as code_server and application_master, are started. The boot sequence concludes with the launch of 'zergling_app' application as requested by a command line flag.
D 1.5 ms zergling_app:start() is entered. A cowboy webserver is asked to listen for incoming requests on port 8000.
E 1.1 ms The spawner is notified that the new instance is ready to process web requests.
F 1.8 ms The spawner replies to nginx with X-Accel-Redirect header citing the location of the instance. nginx proxies the original client connection to the new instance.
G ? After rendering the page you are viewing the instance immediately shuts itself down. The spawner recongnises that the instance has gone away and notes that its IP address may be reused.

Re:Link? (3, Interesting)

Anonymous Coward | 1 year,26 days | (#43261697)

Does anybody else see the problem with this? One second to render a single page. Two thirds of it spent setting up a virtual machine, a quarter booting the Erlang runtime (the OS...) and then a couple of milliseconds to actually perform the work for which the instance was created.

Yes, you do not need a big OS to perform a trivial task, but on the other hand it doesn't take a long time to perform a trivial task, so even a very short boot time is prohibitively expensive compared to the actual task. This doesn't look like a sweet spot at all.

Re:Link? (0)

Anonymous Coward | 1 year,26 days | (#43261671)

The second link goes into the void.

That's not a link, that's a sub-second demonstration!

Re:Link? (1)

ls671 (1122017) | 1 year,26 days | (#43261759)

Well, the OS-less platform providing the linked document was only up for 1 second and is therefore off-line now...

Editors? (1)

Anonymous Coward | 1 year,26 days | (#43261651)

"may change our understanding of how long does it take to bring a server up"

This sentence is writed by no-brains.

Re:Editors? (1)

ls671 (1122017) | 1 year,26 days | (#43261825)

"may change our understanding of how long does it take to bring a server up"

This sentence is writed by no-brains.

This sentence is written by no-brains

-The editor

Re:Editors? (2)

ldobehardcore (1738858) | 1 year,26 days | (#43261989)


Re:Editors? (1)

ls671 (1122017) | 1 year,26 days | (#43262037)

OK, but if the case, then something like:

Does this sentence is written by no-brains ?

Would have been more appropriate IMHO.

Bonus: Google for "writed" and you will find out more people than you may think use it.

Re:Editors? (1)

vsov (2874465) | 1 year,26 days | (#43262059)

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...

A real server OS. (4, Interesting)

Animats (122034) | 1 year,26 days | (#43261659)

This could be interesting. Servers are still designed like PCs. That's not fundamental. One could have compute servers which have network hardware that is configured during the boot process and which restricts what the machine can talk to. Their storage is all external, on file servers elsewhere. They have no peripherals other than the network. They barely need an operating system - the remote management hardware in the network interface handles administration.

With Linux at 15,000,000 lines of code, there's a bloat problem. There's still a need for a run-time library, but it will be more like the C run time system than an OS.

A true cluster operating system has not been made (0)

Anonymous Coward | 1 year,26 days | (#43261721)

Unix is from the 70s. Windows, which was based on VMS, thank you Cutler, is also from the 70s. They were not intended for masses of 28 nm ICs. There simply is no operating system designed to run many programs across thousands of clusters, with cloud like features.

Re:A true cluster operating system has not been ma (1)

vsov (2874465) | 1 year,26 days | (#43262085)

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

Re:A real server OS. (4, Informative)

AmiMoJo (196126) | 1 year,26 days | (#43261785)

Linux scales insanely well. You can boot it from flash on an ARM based system in a couple of seconds. Intel demonstrated booting from cold to a graphical desktop in five seconds years ago.

Re:A real server OS. (4, Insightful)

Let's All Be Chinese (2654985) | 1 year,26 days | (#43261801)

Servers are still designed like PCs.

Servers didn't use to be beefed-up desktops, no "still" about it. That they are now has to do with cheap desktop ubiquity and wanting to use desktop emulator software to underpin "servers". In short, middle management stupidity.

But that sort of thing fits well with TFA, where they say "look ma, no OS!" when they do have software acting like that, only not calling it that. Put the achievement in perspective and it isn't nearly as ground breaking as implied. So the announcement is a bit pompous. Well, nothing new there either.

It's all a bit bass ackwards, but then so is the whole peecee paradigm. The whole virtualisation thing has been with us for ages, in many guises. This is but yet another. Likewise, single-language app boxen. Lisp machine, anyone? Only this time with erlang.

On another note, rethinking how we organise monitors, supervisors, hypervisors, hardware drivers, and all that, and how they interact with userland, isn't a bad idea. This here idea is a valid approach, but by no means the only one.

Re:A real server OS. (1)

emj (15659) | 1 year,26 days | (#43261899)

But that sort of thing fits well with TFA, where they say "look ma, no OS!" when they do have software acting like that

There are reasons why "no OS" is interesting, it does take a while for Linux to boot, I usually boot it in 20s on my virtual servers, making that 3s would actually allow me to save money. If they really were booting Linux, could process CPU intensive request by just buying an instance booting my OS and serving the request in 10s instead of 27s. But as someone said this can be compared with the not so novel approach called "applications".

So if you can boot Linux in 2 seconds, I'll agree that the annoucment is pompous.

Re:A real server OS. (1)

Electricity Likes Me (1098643) | 1 year,26 days | (#43262177)

Does Linux really take 20 seconds to boot on a VM?

My impression was Linux's boot time is mostly probing for hardware or waiting on slow devices to initialize. It seems like in a VM you could skip all that, and also would be ignoring all the usual daemons.

The OS-less approach seems absurd though, because at that point it's really just an application being run on a multi-user system. And we've been doing that since the 80s.

Re:A real server OS. (1)

DarkOx (621550) | 1 year,26 days | (#43262205)

The OS-less approach seems absurd though, because at that point it's really just an application being run on a multi-user system. And we've been doing that since the 80s.

Its absurd because its not OSless at all. There is nothing magical about a hypervisor. Its just a bullshit term someone came up with the clarify they were talking about an operating system + tools set specifically aimed at running other operating systems normally designed to run on the bare metal themselves.

If you stop booting the more general use operating systems on top of the hyper-visors as you say you have not eliminated the OS you have just gone back to a simple OS lacking shared libraries (which can be a good thing) and including some exhotic memory over subscription and de-duplication feature set. Its been more than 20 years though so we all have to invent new language and pretend these are new ideas.

Re:A real server OS. (1)

Anonymous Coward | 1 year,26 days | (#43261905)

Most of the 15mil lines never get used in your specific hardware setup. Linux is this big because it supports a lot of hardware. It took linux 45 seconds to boot up into a running system on a 48Mhz PPC chip. Extrapolating this to a 1.6Ghz machine would mean linux could boot in 1.5 second. Which is no surpise, as the linux kernel boot very quick on modern hardware. It's all the bloat that's added after that that makes it slow.

Re:A real server OS. (1)

vsov (2874465) | 1 year,26 days | (#43262063)

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.

Re:A real server OS. (1)

Bert64 (520050) | 1 year,26 days | (#43262203)

Why not simply have a single instance of linux, and then multiple instances of erlang running under that linux kernel? What benefit does adding xen into the mix bring?

It seems that doing it the traditional way would be both faster and more efficient in terms of resource usage, as well as easier since it would work better with existing applications and languages.

Re:A real server OS. (1)

vsov (2874465) | 1 year,26 days | (#43262077)

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.

Foreign link to libvert, not Erlang-specific (1)

White Flame (1074973) | 1 year,26 days | (#43261667)

libvert [libvirt.org] is what communicates to the virtualized instance, and is the actual OS abstraction that runs on top of Xen in this case.

If there's no OS, we code to the metal, and there's zero "elasticity" in terms of being able to pop your process into any available machine in the cloud.

Re:Foreign link to libvert, not Erlang-specific (1)

White Flame (1074973) | 1 year,26 days | (#43261673)

and yeah, "libvirt". I've had my head in too much visualization stuff. I should be in bed. :-P

Re:Foreign link to libvert, not Erlang-specific (2)

vsov (2874465) | 1 year,26 days | (#43261967)

This demo was prepared in less than a week, so there was a reason to use something well-known and simple to use, like libvirt. Production code will use Xen API directly, or appropriate cloud stack functionality.

Still an OS... (5, Insightful)

FaxeTheCat (1394763) | 1 year,26 days | (#43261669)

So instead of booting a general purpose OS, the system uses one OS specifically for running other OSes (XEN) and one minimal special purpose OS for running the application (Erlang runtime). Whether you cal it a hypervisor or a runtime system, it is still an OS.

Instead of focusing on the irrelevant and incorrect "not using an OS", why not focus on the more interesting fact that for some tasks, it may be worth the effort to create a custom build of the OS with only the functions needed. That version may even be automatically created (or chosen) as part of the application build.

Re:Still an OS... (0)

Anonymous Coward | 1 year,26 days | (#43261751)

So basically we have an OS that starts processes.
You just re-invented UNIX, badly.

Re:Still an OS... (0)

Anonymous Coward | 1 year,26 days | (#43261829)

THIS. "Cloud" computing is a fucking joke.

Re:Still an OS... (4, Interesting)

julesh (229690) | 1 year,26 days | (#43261811)

I just have to say, I'm not quite sure where Xen fits into the picture here. Why do we need it? Why not run something much simpler -- Erlang is a fully memory-safe language where it is impossible for one piece of code to modify the memory in use by another piece of code (because it is a pure functional language, and such operations are basically not possible in a pure functional language), so there is no necessity to protect instances from each other. So why, therefore, does their system not run on base hardware without the hypervisor, thus avoiding the extra abstraction layer?

Re:Still an OS... (0)

Anonymous Coward | 1 year,26 days | (#43261827)

In theory there is no difference between theory and practice. In practice, there is.

Re:Still an OS... (0)

Anonymous Coward | 1 year,26 days | (#43261885)

I've often wondered why we never see bare-metal versions of things like LISP or Erlang. Xen is just a target - the target could equally be the bare metal, like you say. Except, I'm not sure how much driver support you'd have to end up writing. I would assume Xen provides a fairly fixed set of virtual hardware, so it's easier to code to if you don't want to get bogged down in various network drivers and disc controller drivers and so on.

Re:Still an OS... (1)

vsov (2874465) | 1 year,26 days | (#43262011)

There are similar projects for OCaml (http://openmirage.org/) and Haskell http://corp.galois.com/halvm [galois.com] as well as some dull activity with Java VM in the same direction. I believe, that this approach is the future, since it simplifies (a lot) building and management of elastic cloud-based applications.

Re:Still an OS... (1)

Alioth (221270) | 1 year,26 days | (#43261997)

Well, only theoretically possible. While Erlang may be a functional language (it's not quite a pure functional language, but from the point of view of how variables work we may consider it so), bugs in the Erlang virtual machine could still allow memory overwrites - at the end of the day, the bytecode interpreter will be written in an imperative language.

Re:Still an OS... (1)

vsov (2874465) | 1 year,26 days | (#43261999)

I have to insist that there is no "traditional OS" inside VM in this case. Of course, all appropriate functionality exists, but components are being orchestrated not in traditional way. In modern cloud environments there's no reason to make all this unnecessary fuss with multiple layers of virtualisation - we need it only to run legacy code. Cloud is our next computer, and VMs are our processes which we run there. Why keep full functional kernel inside VM and play with context switches (for example) on virtual CPU? Instead of that we could outsource some parts to external instances, and make life a bit easier, it's what Erlang On Xen about...

Re:Still an OS... (1)

Bert64 (520050) | 1 year,26 days | (#43262213)

But *why*?
Why should VMs be processes, whats wrong with processes?

Instead of putting xen on your hardware and running each instance inside of xen, why not simply put linux (or any other os) on the hardware and run each instance as a process on linux?

Minimum != No (2)

rok3 (1133003) | 1 year,26 days | (#43261681)

'OS-less' based system, sweet! Just think, we'll save a few seconds during the boot up process and it will only take hundreds of hours for our devs to code in assembly / binary! It's almost as efficient as the href-less anchor tag.

Sarcasm aside... there is something working as an OS it's just trimmed down to the bare minimum. Also, check your damn summaries.

Re:Minimum != No (2)

vsov (2874465) | 1 year,26 days | (#43262121)

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.

Chrome is a virtual box too - NaCl (1)

yurik (160101) | 1 year,26 days | (#43261689)

This seems to talk purely about virtual servers, not hardware. Everything above hardware is nothing but programs, even if we call them virtual PCs. They only differ in the level of integration with the rest of the machine and peripheral devices. For example, javascript running in a browser could be considered as much of a virtual pc as Oracle's VirtualBox, with the only difference being the interface with which internal code communicates with the outside. Chrome's native client (NaCl) ability to run native code without any interpretation while still maintain complete isolation from the OS and other processes is the best example of complete virtualization.

SmartOS or Solaris? (0)

Anonymous Coward | 1 year,26 days | (#43261719)

The idea of not having an os is false. Obviously there is an os under Xen, it's just the guest that doesn't have an os. So now it's staring to look like SmartOS or Solaris Zones....

Re: SmartOS or Solaris? (0)

Anonymous Coward | 1 year,26 days | (#43261955)

My thought exactly, a slim bare metal zones / KVM running OS has been already put into full scale production by Joyent - SmartOS. Zerg Demo has had the slashdot effect already, ouch. Poster says 1 sec, article says 1.5-2 sec? Even with slight exaggeration - still orders of magnitude off for processing simple requests. FWIW project FIFO - SmartOS's VM management GUI is entirely written in Erlang.

Reusable OS-less instances (2)

FaxeTheCat (1394763) | 1 year,26 days | (#43261723)

So to develop this further, we could create reusable OS-less (or minimal-OS VMs, if you prefer) instances to save the boot time.

Oh, wait, I guess we just reinvented the process...

Re:Reusable OS-less instances (1)

vsov (2874465) | 1 year,26 days | (#43262021)

Yes, we did. Actually, I've just mentioned it in the comment above. Cloud is our computer and VMs are our processes. Saving the boot time is just an aspect of much bigger impact, think about simplified deployment and maintenance, better resource isolation and granularity, easier migration, much better security (yes, there's no shell inside), etc.

Not quite OS-less, but still sounds neat (4, Interesting)

AdamHaun (43173) | 1 year,26 days | (#43261733)

The broken link should probably point here [erlangonxen.org].

If I read the article right, they're using a hypervisor (Xen) to directly run an Erlang interpreter (LING VM) that they wrote. The interpreter relies on Xen to provide some higher-level functionality. (Wikipedia says this is called paravirtualization [wikipedia.org].) So it's not quite a web server running on bare (virtual) metal, cool as that would be.

It looks like the significance of this is twofold. First, people are using VMs to create run-time environments that are less featureful than a standard OS but much faster to start up. Second, there's a working demo of a simple virtualized web server using this concept. I don't really follow virtualization tech, so maybe someone can clarify this? I'm not clear on exactly what the difference is between a hypervisor+para-API and a normal OS.

Re:Not quite OS-less, but still sounds neat (3, Insightful)

julesh (229690) | 1 year,26 days | (#43261833)

I'm not clear on exactly what the difference is between a hypervisor+para-API and a normal OS.

None. The paravirtualisation API is pretty much identical to those provided by normal OSs, except that it is designed in such a way that other OSs can easily be rewritten to use it rather than raw hardware features. This pretty-much means that the only real difference is in terms of what kind of features it provides, rather than how it does it.

Re:Not quite OS-less, but still sounds neat (1)

AmiMoJo (196126) | 1 year,26 days | (#43261891)

What sort of thing would you actually use this for? How is it significantly better than just having a shared server running a bunch of applications?

Re:Not quite OS-less, but still sounds neat (0)

Anonymous Coward | 1 year,26 days | (#43262161)

Scalability. This makes it much more easy to scale up to processing thousands, millions or more instances, ala grid/cloud computing.

Re:Not quite OS-less, but still sounds neat (4, Interesting)

bertok (226922) | 1 year,26 days | (#43261923)

I'm not clear on exactly what the difference is between a hypervisor+para-API and a normal OS.

Essentially, traditional operating systems mix several vaguely related things into a single system:

1) The "core" of an operating system: resource management, device drivers, isolation, time sharing
2) Useful "libraries" or APIs: advanced networking features, security such as access control and authorization, filesystems, etc...

The reality is that the two should have been split from the beginning, not merged into one giant monster, because different applications need different things, and the rest is just a maintenance and security nightmare just because it's present in the kernel or in privileged system services.

For example, some databases like Oracle can directly format a block device and treat it as a "file" in the database. No operating filesystem required, that's just overhead. Similarly, cross platform products need to have a portable set of libraries (#2), but don't typically care about drivers and whatnot. Hence, many products ignore the built-in libraries of the operating system, and roll their own anyway, which means whatever is in the OS is just wasted.

What hypervisors bring to the table is that they correctly split out #1 and #2, each optimised for its own thing. The "core" becomes the hypervisor kernel, and "2" becomes the guest virtual machine's operating system. This is why well written hypervisors such as VMware ESXi tend to be crazy robust. They have one job to do, and they do it well. The problem is that the client virtual machines are still using legacy operating systems with both #1 and #2 instead of just #2, which is redundant. This Erlang project is a simplified OS that lets the hypervisor do its thing, and then only loads what Erlang needs inside the guest, and nothing else. Hence the fast startup times and I'm guessing good efficiency.

In this kind of split environment, the guest "OS" would typically run a single "application" per virtual machine, which is already typical anyway, but by making that assumption from the beginning, a bunch of simplifications can be made: everything can run in ring 0, there's no need for access control lists, serial ports, display drivers, or any of that junk. Just a basic filesystem, basic IP-only networking, and network-based security such as SAML or Kerberos.

Essentially, in an idealised hypervisor-based computing world, most code that's currently part of Linux or Windows would move into user-mode libraries that ship with compilers, and the "operating system" would be essentially a modern version of DOS: something trivial to start processes, then get out of the way.

Re:Not quite OS-less, but still sounds neat (0)

Anonymous Coward | 1 year,26 days | (#43262017)

There is a similar project based on the OCaml language: http://openmirage.org/

Sounds like these might be useful as an optimization when you have a fixed Xen hypervisor that you can't touch (i.e. Amazon EC2). In that case it might help eliminate some virtualization overhead.

Other than that you could just use processes in a non-virtualized OS and achieve similar results.

Move along, nothing new here... (0)

Decker-Mage (782424) | 1 year,26 days | (#43261769)

Set up and tear down takes some time and consumes (somewhat) valuable resources. This observation about electronic devices is as old as electronics, not just computers even unto the original (re-)wired computers. From that viewpoint, even the roomful of ladies using calculators in parallel had a significant waste, at that time, involved. Now it's setup and tear-down of virtual machines on massively parallel hardware. My, how things have changed. NOT!

The first thing I do after getting a distro running here is take apart the kernel, modify it to strip everything non-relevant to that machine's purpose(s), recompile, link, substitute, and go. Someone else pointed out the sheer (bloated) size of the kernel that attempts far too much, IMNSHO. VM's receive exactly the same treatment whenever a new purpose is identified and they go into my golden master collection. Turning off services, reducing the amount of code, removing as much of the driver base, all this to create not only a reduced memory footprint, but also a reduced demand on the server by all tiers, and a much reduced attack surface. And BTW, I do exactly the same to any version of Windows that I'm playing with at that time. 'Sides, it's always fun to torture the little beasties in my chamber of horrors here.

These things come in waves. Generalized yields to a flood of purpose built [Sofware | Hardware], which yields to a new, sweeping generalized. Lather, wash, rinse, repeat, ad nauseum. So unless you've already plopped down in front of the 'puter with this page up, move along. Nothing new here.

DOS (4, Funny)

GbrDead (702506) | 1 year,26 days | (#43261791)

Reminds me of a certain OS from the distant past. It had file system support, a process launcher (one process at a time), and... more or less, that was it.

Re:DOS (2)

Floyd-ATC (2619991) | 1 year,26 days | (#43261913)

The problem is, many people seem to have forgotten what an operating system actually is and what it isn't. What they see when they boot up their computers is a user interface. Go ahead and try to explain the difference to someone who grew up with DOS, Windows or Linux :-/

Just another OS (3, Insightful)

ensignyu (417022) | 1 year,26 days | (#43261807)

If you think about it, a hypervisor is just an OS that manages other (guest) OSes. It enforces privilege separation and abstracts device access to the guest OS.

If you replace the guest OS with a guest application ... it's really just a regular OS again. You know what else takes less than 1-2 seconds to start up and shut down? A UNIX process.

From a technical perspective, maybe there's some value in moving beyond the traditional *NIX APIs, filesystems, etc, and defining a novel, possibly simpler interface for running and managing application code.

Or go in the opposite direction by extending its capabilities, taking advantage of the new hypervisor security space to let app runtimes take over traditionally OS-level "ring 0" responsibility like page tables and interrupts/handlers with full hardware acceleration.

You can't call it OS-less though, unless you really mean "less OS" rather than "without an OS". Call it OS-minus, or maybe even OS-plus.

Re:Just another OS (1)

vsov (2874465) | 1 year,26 days | (#43262043)

Well, I would use "spreaded OS" :) Of course, all OS-related functionality remains, but it's being orchestrated in a completely different manner. Different parts of appropriate functionality can be provided by another instances, hypervisor, Dom0 OS or even cloud stack. That approach gives us a loads of advantages - better resource granularity, fast start and fast migration, small and secure instances, much more resilient app code (since instances can be restarted after crash in a very short time), etc

Re:Just another OS (1)

Electricity Likes Me (1098643) | 1 year,26 days | (#43262195)

Isn't this just adding a ton of boilerplate code though?

It's in the cloud so you'll always need networking support, and that's going to be TCP/IP generally. You'll need to write files, so you also need a network file system or real file system driver of some sort, and a way to write to block device like objects. At some level, all this is just "things a very minimal Linux kernel" would do for us.

That all said, I'm now very curious about how quickly said kernel would spin up and launch a custom application as init. But 1-2 seconds feels like it would easily doable considering we've had the 5 second graphical desktop previously.

Re:Just another OS (1)

vsov (2874465) | 1 year,26 days | (#43262227)

Isn't this just adding a ton of boilerplate code though?

It's in the cloud so you'll always need networking support, and that's going to be TCP/IP generally. You'll need to write files, so you also need a network file system or real file system driver of some sort, and a way to write to block device like objects.

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.

VM/CMS (0)

Anonymous Coward | 1 year,26 days | (#43261851)

Yes, this technology is utterly, unbelievably new.


"in the future may stop using OSes" (1)

Anonymous Coward | 1 year,26 days | (#43261857)

And in the future HTML may stop using HREF

Virtualization is kind of bullshit (1)

allo (1728082) | 1 year,26 days | (#43261935)

when you virtualize in unix system, then you create a virtual machine to run multiple applications seperated from each other on a OS, which was invented to run multiple applications seperated from each other. Many applications do not really need a VM, but just a shell account and some own ip, where they are allowed to use privileged ports.

other approaches are chroot/lxc/linux-vserver maybe openvz lightweight VMs.

Re:Virtualization is kind of bullshit (1)

CBravo (35450) | 1 year,26 days | (#43262143)

There are a couple of issues that arise on production systems I find:
-config files and adhoc installed libraries are impossible to link to the application that actually needs it (given the fact that my time is scarce). Nightmare when upgrading, creating new instances or when pulling apart a system (for e.g. performance/HA).
-if an application uses resources, e.g. I/O, too much you want to know about it, point fingers and restrict its usage (and maybe give it its own). Nightmare when you want to find out 'what causes it to grind to a halt during Xmas'.
-applications has 'resources' they should not have, because another application needed that 'resources'. Example: Qmail needed compiler and afterwards a cracked PHPMyadmin used that to compile malware.

Some of it can be avoided by automation, e.g. Puppet, good administration of all systems (which people hate and 'forget' or do not get the time for). But it is not simple as it should be.

Xen's Mini-OS (1)

Skinkie (815924) | 1 year,26 days | (#43261939)

Xen introduced Mini-OS [xen.org] years ago. The question is: how much functionality that the kernel and a fat libc commonly provides, does the application need. Boot times are not really the issue anymore; look at systemd, everything is booted within 2s.

Re:Xen's Mini-OS (1)

vsov (2874465) | 1 year,26 days | (#43262031)

Boot time is not the only issue. We have to confess that we do not need the fully-functional kernel in userspace in every VM we start in cloud. OS functionality can be redistributed over other instances and cloud stack services, such architecture provides much better flexibility and scalability than unnecessary doubling gigabytes of code and functionality in VMs.

Awesome performance (3, Insightful)

BitZtream (692029) | 1 year,26 days | (#43261973)

Upon reception of an HTTP request, the demo spawns a new Xen domain with LING VM and a web application written in Erlang. After serving a single request the domain simply shuts itself down and frees all resources. The whole process takes 1.5-2sec.

I think that 1 connect per 1.5-2 seconds minimum is probably impressive for a web server if its running on ... well hell, I don't know, an Arduino can serve pages faster than that.

Considering that Apache or IIS on any modern hardware, even limited to a single core will move 400 requests a second or more without breaking a sweat then I'm not really getting why I'm supposed to be impressed with their silly misuse of resources. This setup is more or less an example of why we have people who write OSes, people who write server software ... and guys like this who reinvent the wheel ... poorly.

Re:Awesome performance (0)

Anonymous Coward | 1 year,26 days | (#43262051)

Um, it's a proof of concept of starting up a VM in a second. You think it's stupid because they didn't attach a real workload yet? How blinkered of you.

Re:Awesome performance (0)

Anonymous Coward | 1 year,26 days | (#43262079)

Real workloads have requirements that aren't satisfied by that Erlang runtime environment, and have setup times of their own. There's a reason why typical operating systems take a while to load, and it's not loading drivers and initializing hardware: Booting the Linux kernel is usually only a small fraction of the total boot time of an operating system. A custom kernel that only contains the drivers for the present hardware (possibly virtual hardware) boots insanely fast. The rest of the time is spent preparing the system for the applications so that the expected software infrastructure is available when they're started.

If you end up using a virtual machine for a nontrivial task, you'll want higher level services from your OS and not just scheduling, memory management and a network stack. Then it becomes even more expensive to setup and tear down a VM just for one run of the task.

Re:Awesome performance (0)

Anonymous Coward | 1 year,26 days | (#43262187)

Not impressive at all. Current Fedora with systemd can container with whole OS in 2 seconds, serve the data and shutdown. All of this is triggered by network request. And you have full OS, not some highly specialised runtime.
More details at Socket Activated Internet Services and OS Containers [0pointer.de].

Re:Awesome performance (1)

Anonymous Coward | 1 year,26 days | (#43262241)

You know, at first I reacted in exactly the same way. What's so awesome with 1.5 secs to service a request?

But then, in contrast to you, I though a little. The rest of the article made me realise that I probably don't know enough about this to immediately shoot at that number. These guys are thinking about scalable server solutions, how to deal with sudden and large increases in number of users and that's no the same thing as "how many requests can a certain server serve".

My guess is that this "1.5" second thing that comes into being will then be able to serve quite a few of requests until it's taken down. I guess it's the equivalent of booting up one more web-server and then 1.5 seconds isn't that bad :-)

progress maybe (1)

crutchy (1949900) | 1 year,26 days | (#43262105)

A demo server gets created, booted up, configured, runs an application and shuts down in under 1 second

so you're saying the hypervisor starts an application layer that then runs an application and then shuts down

sounds kinda similar-ish to dalvik (android)... with all the useless shit taken out

useful yes, but the whole "OS-less" and "elastic cloud" stuff just sounds like marketing bullshit

Re:progress maybe (1)

vsov (2874465) | 1 year,26 days | (#43262165)

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.

Re:progress maybe (0)

Anonymous Coward | 1 year,26 days | (#43262247)

lol dongs

This approach has been used since the dawn of computing. It's just the first time someone has thrown the word cloud at it. Computing appliances aren't new, throwing them behind Xen isn't a huge stretch.

micro-virtualisation (0)

Anonymous Coward | 1 year,26 days | (#43262115)

Well, I find the idea interesting. That way, you can instantiate an "appliance", on a barebone OS, and reduce the attack surface to the minimum. A kind of security by isolation, nice for vswitches and other software boxes.

There is a similar projet in OCaml which is going to be integrated in Xen, openmirage ( openmirage.org) and also a micro-hypervisor projet by Intel, NOVA, which is a base upon which Genode OS can run ( https://github.com/IntelLabs/NOVA )

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account