I’ve always liked the silo approach to applications on phones. Each app is running in its own little island with its data files private and inaccessible to other programs. It can only access things the user grants, and via policed IPC.
I first encountered this model when developing Symbian 9 and have met it since in Android and iOS.
Apps should be silos. So should server processes. Even on desktops and server machines.
You can kind of get this with Unix by making each program have its own user/group, chroot and some localhost firewalling malarkey.
The problem is of course versioning shared libraries and such.
(I’ve spent too long fighting native dependency hell in virtualenv’d Python so I’m a bit bitter.)
The exciting direction things have taken more recently is virtual machines.
Usually this is at, the, well, machine level. You run whole operating systems on virtual computers that are running on real computers. This can be done at several levels, from the hardware supporting hypervisors to running the virtual machine as an app.
Performance is always a concern.
Native Client (NaCL) is process-based sand-boxing. Its getting some high profile exposure and getting fixed and its portable. As zeroVM demonstrates, its not just about browser plug-ins.
I have no experience with User-Mode Linux but I imagine its along these lines too.
So I have a vision:
Imagine that applications and servers run in NaCL containers.
These containers run a platform personality (from a basic POSIX userland to win32 emulation to a full Linux VM (UML-ish)). OpenGL (ES 2 mapped) can be passed through Chrome-style.
Some things like epoll, mmap and threads must be passed through as efficiently as possible; others can be expensively emulated. A silo’ed virtual file system can be provided to each container and there can be quota support.
These containers can be split into the program and personality sub-parts that are managed separately so that the personality can be optimal for the target (emulating win32 on Linux is a different beast to passing through on Windows; likewise epoll and so on will present interesting problems for Linux personality on Windows).
And these containers can be distributed in LLVM intermediate representation and the final compilation step can be done on each deployment in the optimal machine architecture.
So we have these nice portable apps and servers that run as processes on the operating system of your choice.
This is different from classic VMs in that we’re not trying to give the VM apps emulated framebuffers and such - much better we intrinsically support sshing into them or x-forwarding or OpenGL forwarding and such. Where possible we want nice sandboxed apps that have just the minimal personality glue layer.
The big thing though is how we plug these separate silos together.
Have a node.js server that needs a Redis or RabbitMQ server? If each of these is a nice sand-boxed silo, we can have a nice UI that lets us plug together them. Imagine that these sand-boxed containers have configuration files that make it easy to transparently map their ports together and configure what is basically a firewall.
And then, why should these containers all be running on one machine? Grid distribution ought to be seamless too.
All these containers will have lots of duplicated code and data; a deduplicating COW file-system and RAM will help make this negligible.
Finally, an app-store or repository system to make getting these components easy.
I imagine this being for developers and deployments.
If I could package my Python servers or their dependencies in nice little silos, and if it was easy to juggle various islands of interacting components and spread them across several machines seamlessly I’d be so much happier.
↓ click the "share" button below!