The new syntax and then(): is used above to chain callbacks to the previous lambda function. This allows you to quickly create and manage the flow of callback logic.
with stack:
def handle_connection(s:connected_socket, a:socket_address) -> future<>:
output = s.output()
input = s.input()
return do_with( s, output, input ):
return repeat() and then( callback=lambda:output.close() ):
return input.read() and then( capture=[output], future=[buf] ):
if buf:
return output.write( move(buf) ) and then():
return next
else:
return stop
future<> handle_connection(connected_socket s, socket_address a) {
auto output = s.output();
auto input = s.input();
return do_with(std::move(s),std::move(output),std::move(input), [] (auto& s,auto& output,auto& input) {
return repeat([&] {
return input.read().then([&output] (auto buf){
if (buf==true) {
return output.write(std::move(buf)).then([] (){
return stop_iteration::no;
});
} else {
return make_ready_future(stop_iteration::yes);
}
});
}).then([&](){ return output.close(); });
});
}
This hello world loads the Numpy library, no special modifications were required to allow the Numpy C modules to work on OSv. The final VM image is tiny, just 25.7MB.
The Python script above is marked with @embed, which directs Pythia to inline it into the final compiled C++ module below.
The statically typed python-like-code above uses special syntax for interacting with CPython Objects, this is transpiled by Pythia into C++11.
Above is our port of CPython2.7 running a basic hello world on OSv. This is a work in progress, we plan to strip down Python and remove things that are not portable to OSv (like the multiprocessing module), and then optimize for OSv using the low level kernel API. We have another simpler hello world, here, that directly uses the Python CAPI.
Pythia is our custom transpiler and frontend to OSv. It allows you to mix normal Python scripts and statically typed Python code that is transpiled to C++11. Your python script is embedded into the C++ module, and not loaded from the VM file system. This further reduces the attack surface, and helps improve security. We are working to improve Pythia with even greater security, so that it can inject generated encryption keys into each image build, and provide you tools to verify that your cloud instances are only running the code you have deployed into your Zero-Trust network.
The official OSv apps repo on github is missing Python, how could nobody working on a Python port! In 2013 OSv launched with lots of momentum, but this year things have slowed down. We expect this is partly due to bad policy by Cloudius-Systems, not accepting pull requests, and patches are becoming lost and not merged into the main repo!
Development of OSv had a good start, the first two years of development were very active, and driven by Avi Kivity (CTO of Cloudius) contributing about 100,000 lines of new code.
Then in 2015 Nadav Har'El, takes over development of OSv, and it hits a brick wall, with only 2,000 lines of new code, what the hell happened?
Zvi Avraham at this years Erlang user conference talks about OSv security and how unikernels have a very small attack surface (jump to 14min). At 20minutes in, Avraham says "containers are not a secure solution". Container solutions like Docker are not secure when compared to unikernel systems like OSv.
At 30minutes in, Avraham talks about the interesting details of the work in progress on porting Erlang/OPT to OSv. Erlang is highly dependent on OS fork and multiple processes, making it especially difficult to port to OSv.
At the end of the presentation (jump to 30min), Avi Kivity talks about security and compares it to Docker. OSv and the hypervisor it runs within have a very small attack surface compared to Docker. The attack surface of Docker is huge by comparison, because it includes the entire general purpose OS, Linux. Once a hacker, or malicious sys-admin insider, has penetrated a network, Linux provides them many hiding places they can implant their malicious code: kernel modules, inserting scripts into cron jobs, or hack bash login config files like ~/.bashrc, etc... It takes significant time and expertise to maintain a secure Linux cluster. With OSv this is simply not an issue, because the developer hard-codes everything that goes into the VM image, tests the image locally, and can then easily deploy it directly to the network cluster. Most of the security management is then moved to the hypervisor level, which requires fewer system administrators, and less people with privileged access.