It's nice that Sandstorm is mentioned, as a way of users running web services under their own control. I think it's worth also pointing out that one of the uses of Mirage OS (also mentioned) is to build/deploy small services that can give users control of their data -- a project called Nymote [1]. The website needs a refresh and I haven't updated the blog in a while but I'll be making more time for it this year. If anyone's interested in the technical aspects, then the Mirage mailing list is the one to join.<p>[1] <a href="http://nymote.org/blog/2013/introducing-nymote/" rel="nofollow">http://nymote.org/blog/2013/introducing-nymote/</a>
Docker was written off with the caveat of, "but I still use it for my local development environment". I feel like that's a huge advantage for Docker. Maybe I missed it, but all the other mentioned technologies didn't try to solve the problem of providing a consistent development to production environment. That said, Docker still has a lot of problems around making the dev-to-production experience smooth, especially for teams that use OS X for development and run Linux in production.
What a great list; I used this holiday season to build a similar list actually. Genode's potential is really understated in the post - it can apparently run a number of different microkernels including the formally verified seL4 which provides secure isolation of each individual driver, VM, or process. They seem to have some Linux interoperability going too. I really want to find the time to dig into this one some more.<p>Qubes is great, however the project really is a bit absolutist in my (amateur) opinion in placing <i>all</i> the trust in isolation: I still care about integrity of the isolated environments too, but Qubes seems to somewhat throw that baby out with the bathwater by, for example, insisting on passwordless sudo in all AppVMs.<p>I get where they are coming from - local privescs are a dime a dozen and they have a small team. Linux process isolation sucks but is it <i>that</i> worthless that we should deliberately introduce new vulnerabilities by leaving the doors completely wide open? When the skids find a new RCE in my crappy mail client or attachment viewer, the effort required to engineer exploits is massively reduced.
I'm surprised BOSH isn't brought up more when I see discussions on stateless deployment. Maybe I'm biased as I spent some months as an intern on that team but I definitely think it has a place in a thread like this. Check out <a href="http://github.com/cloudfoundry/bosh" rel="nofollow">http://github.com/cloudfoundry/bosh</a> or the #bosh channel on freenode
Excellent article. I like the sound of OSv, which attempts to make appliances that run on hypervisors: <a href="https://github.com/cloudius-systems/osv" rel="nofollow">https://github.com/cloudius-systems/osv</a><p>Sandstorm looks interesting. I'm slightly skeptical as the homepage has a link to their enterprise sales, yet it's hyped as a project of good will. I'd like to hear more about their business model. From a technical side, the project makes a lot of sense. But I'd rather see something like OSv be made to run on users' machines and phones and not just cloud systems, which would let app authors distribute directly to users with little hassle.
I really like the concept of MirageOS. I think its the only way to scale up above c10m [1].<p>In Mirage single application servers are able to git rid of a ton of the multiprocess kernel complexity. One really cool improvement/simplification I'd like to see: I'd like to remove all CPU level security (ie. context switches). For now I don't see the benefit of removing memory safety/abstraction but that could be discussed.<p>Something like a SQL DB is the perfect example. In production its the only application on the OS. It already has its own set of security concerns (the majority of which are not solved by context switching). Yes, it increases the scope of a DBs security concerns, but it allows the application to choose its own security model. The DB has as much power as the kernel now, so maybe the DB would reimplement context switches for all network activity (be as safe as the Kernel lets it be today)? Maybe instead it would optimize context switches away for a majority of calls except writes? The possibilities/optimizations only grow, at the cost of only a 5-10% code size increase (ie to implement the subset of kernel security features that it actually needs).<p>The other really nice thing about this could be: Imagine if Mirage allowed you to run a process with kernel level permissions and (as I understand it) it already allows that one process to run arbitrary OCaml on a selected CPU core. Imagine then the one process built into Mirage was the code for multi-process/multi-thread management with scheduling, message passing, security, signals and all the bells and whistles of a monolithic kernel.<p>You could essentially construct monolithic kernels on the same framework that allowed us to build optimized databases, optimized servers.<p>I think this set of lower level libraries, would be a game changer. If these libraries (framework) for building monolithic applications could be extracted out of the Linux kernel that would be huge since you could run it on any device Linux currently has drivers for (think embedded). However, even as it stands if you could create a framework for building Kernels with MirageOS on Xen, that would be really impressive.<p>[1] <a href="http://c10m.robertgraham.com/p/manifesto.html" rel="nofollow">http://c10m.robertgraham.com/p/manifesto.html</a>
There's also bromium, which is very similar to qubes-os but backed by a big startup ,so it's polished for enterprise usage. The drawback is probably the price.
Ling, the Erlang VM directly on Xen seems neat.[0]<p>Folks have talked about composable OS frameworks / domain-specific OSes in the usual suspects of Erlang, OCaml, perhaps Haskell... especially useful for soft-realtime / embedded.<p>Irdis is neat.[1]<p>0: <a href="http://build.erlangonxen.org/" rel="nofollow">http://build.erlangonxen.org/</a><p>1: <a href="http://www.idris-lang.org/" rel="nofollow">http://www.idris-lang.org/</a>
Also perhaps worth mentioning Baserock (<a href="http://wiki.baserock.org" rel="nofollow">http://wiki.baserock.org</a>) which can reproducibly build an OS from sources in git and deploy the resulting artifact to various popular targets, kvm, virtualbox, openstack etc.
There are videos of talks on both Genode and OpenMirage from the OS conference I organized back in November [1] - I tried to get a Qubes talk too, hopefully this year.<p>[1] <a href="https://operatingsystems.io/" rel="nofollow">https://operatingsystems.io/</a>
Yesterday, I've attended a container presentation held by Microsoft. They mentioned CoreOS (<a href="https://coreos.com/" rel="nofollow">https://coreos.com/</a>) for a potential alternative to Docker.
For windows users, a docker alternative is sandboxie. WinNT series has almost all required features ever since the early nineties - it's just not exposed in the Win32 UI. The Windows backwards compatibility layer and IE 10+ also use the sandbox functionality. Maybe Win10 comes with a easy to use sandbox UI?<p>An open WinNT alternative that is still in alpha is ReactOS.
I really like the idea of Qubes OS. I just wish a "lighter weight" method existed to sandbox apps or groups of apps just as well, and adopted by more mainstream operating systems, too.