This is definitely a developing trend... seems to be catching on that most server applications are more or less single programs that just use the OS as an emulation layer so that applications don't need to come with their own low level drivers. Quite overkill if you're just trying to run java, node, ruby, whatever

We're probably not too far off from java-as-the-os, node-as-the-os, etc. Substituting a hypervisor for Linux or whatever other OS you're using as the emulation layer seems to the be the architecture of choice for this type of work right now... I guess because you'd just have to implement a handful of drivers... in addition to other OS bits like scheduling and memory of course, but I suspect those things are fairly straightforward for many applications especially if you can assume that there are no other "processes" running... essentially those just become implementation details of the application that can be swapped in and out like any other library/framework

The term I've seen for this sort of architecture is a "unikernel"

This OSv project looks nice, definitely something to keep on the radar

I wouldn't really call OSv a unikernel. The main distinction is that in unikernel operating systems, the application IS the kernel. The OS is not an emulation layer, but the application itself. Application code is linked directly with the kernel to produce an operating system whose purpose is to execute a single application. One example is Mirage[0].

The big difference is that while OSv may be targeting the same use case, it's still more similar to a general purpose OS. Some of the kernel APIs it provides seem to be blurring the line though.

[0] http://openmirage.org/

OSv is not a general purpose OS although it does support a subset of the Linux ABI for compatibility. Both application and OSv share the same address space and application code is linked directly to the kernel at start-up (there's an embedded ELF linker). The design is wildly different from MirageOS but I don't really see why you would not call it an unikernel.

It seems like I didn't call it a unikernel because I misunderstood the design. The design you described sounds like a unikernel to me.

I'm kind of infatuated with the unikernel / libraryOS concepts. I think they're really on to something, especially when you consider how many systems are devoted purely to a single configuration and set of processes for large periods of time.

Some time ago, I listened to a talk given by one of the OpenMirage devs where he described substantial memory & complexity reductions and subsequent efficiency gains they were able to achieve compared to a comparable existing Unix System.

Moreover, after thinking about this for a while (and having a lot of experience working on embedded systems) I'm fairly confident there are still more opportunities for optimisation by removing ubiquitous but now actually unneeded layers of abstraction.

Fair enough, I agree your definition of a unikernel and OSv isn't that exactly.

Folks interested in this should also check out MirageOS (http://openmirage.org -- I'm a contributor).

There's also a good series of unikernel articles that give more background. http://www.linux.com/news/enterprise/cloud-computing/821243-...

This is interesting. They are also claiming that unmodified Redis and memcached instances run x2 faster on OSv [1]. Furthermore, a modified version of memcached, using their OSv network APIs [2] runs x4 faster.

Note also that they are launching a drop-in memcached replacement software appliance [3]

[1] http://osv.io/benchmarks/

[2] http://osv.io/nfv/

[3] http://osv.io/flashcache/

A related project: http://erlangonxen.org/

See also: http://www.seastar-project.org/ - a high performance C++ framework from the makers of OSv that runs on Linux and OSv (incredibly faster on the latter)

Folks, you're welcome to try Capstan - http://osv.io/capstan/ Capstan to OSv is what docker is to containers

The lock-free claims are really interesting.

I guess it was only a matter of time before people started trying to get their VM's closer to the meta. I look forward to watching their progress. Really very cool.

For many use cases, it would seem like container-based approaches are even better still.

You're missing the point. OSv and other unikernels are there to run on existing clouds, such as Amazon which (new things like ECS aside) is all Xen VMs. That's the environment that exists, and these sorts of tools are about squeezing an few extra drops of performance out of some Java app that's already running there.

I see -- you're right.

Written in C++, instead of yet another C based OS.

Windows has a lot of C++ in it, I think. Anyway, C++ has all the bad bits of C, so it's not really that much of a deal. An OS written in Rust, though, that could be an actual, real step up from our current 1970s software tech.

I agree, but we are very far away from a OS vendor adopting anything else.

There are some embedded solutions running Ada or Java directly on hardware, effectively using the runtime as an OS, but that is very specialized market.

Looking for the timeframe it took OS to adopt C++, we are looking at similar timeframe for any C++ alternative.

Does Ada have a runtime?

All programming languages have runtimes.

What's your definition for "runtimes" because in my experience your statement isn't true. I have done embedded system programming and would have noticed if the languages I used added some runtime.

The CS definition of runtime. The set of primitives required to support the semantics of the programming language.

In C this would be the code required to call main (), initialization of global variables, hooks for library functions like atexit () to register their actions and a few other things.

Sure one can disable this runtime, however whatever happens to be used instead is nothing else than a customized runtime.

I am streching a bit the meaning here, but in some processors even the microcode logic could be seen as a kind of silicone runtime.

Ok, but that not the definition used for a lot of languages (particularly when talking about microcode). Ada will happily compile to bare metal without what is traditionally considered a runtime. Forth on forth chips is as bare as you can get.

There was an excellent presentation on this at Fosdem 2014: http://video.fosdem.org/2014/UD2120_Chavanne/Saturday/OSv_a_...

See also https://github.com/galoisinc/halvm and http://openmirage.org

We have Datacenter OS's, Application Layers, Docker, Containers, but still two building blocks aren't done yet, first storage outside the cloud, or a storage layer on top of multiple clouds which scales good and also works on your own datacenter, similar to swift and ceph or hdfs but way easier to use (as easy as docker).

Also we couldn't scale out SQL Databases that easy. They are still a pain in the ass.

Also some building blocks are yet missing from Containers. 1. Layers that you could easily attach to a container, like a external Logger. 2. Configuration / Environment management on top of containers, something like archaius from netflix just for docker.

See also https://boxfuse.com for a minimal image generator for JVM-based applications with zero downtime deployments on AWS.

Disclaimer: Boxfuse founder speaking

Folks, you're welcomed to try Capstsan - http://osv.io/capstan/

Capstan to OSv is what Docker is to containers

Well I for one am going to try this out.