OS Technologies to Watch(gfxmonk.net) |
OS Technologies to Watch(gfxmonk.net) |
Using Docker for this forces you to do things the Docker way, whereas Vagrant is much more OS and CM agnostic. (CM is configuration manager: you can use puppet, chef, ansible, shell, salt or even Docker: whatever you're already using in production).
Qubes is great, however the project really is a bit absolutist in my (amateur) opinion in placing all 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.
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 that 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.
seL4 is great and all, but this is simply not possible as long as hardware devices can access memory. For example, a graphics driver can program the GPU to overwrite arbitrary system memory, regardless of how drivers are "isolated" by the kernel.
Unless there's a hardware IOMMU configured by Genode, Xen, etc, http://transpute.github.io/test1/related/
Currently I think a couple of things that stands in the way of it being more widespread.
* Its tedious to create a new release.
* The documentation is scattered.
* Distributing a release can be a bit tricky. Spiff + deployment templates doesn't really scale that well. For CF we have to pipe to a mod script just because the original templates are not flexible enough, i.e "./generate-manifest infra stub.yml | ./add-extra-releases-and-change-static-logging-levels-and-other-random-stuff > manifest.yml"
* Its sufficiently different even for a seasoned admin that it will take some time to get up and running and understanding how stuff fits together end to end. Currently it feels like the only way to understand BOSH is to understand BOSH.
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.
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.
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).
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.
You could essentially construct monolithic kernels on the same framework that allowed us to build optimized databases, optimized servers.
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.
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.
Irdis is neat.[1]
I guess they meant Rocket (https://github.com/coreos/rocket). Rocket is an app container runtime similar to Docker, which is developed by the CoreOS group.
An open WinNT alternative that is still in alpha is ReactOS.
SmartOS is an "operating system". The way it designed to decoupled may give the illusion of Docker alternative, but it certainly doesn't serve the main purpose of docker which is to only prepackaged dependencies/environment, not the whole machine.
Its the same on how LXC/KVM/Jails is not docker alternative.
Vagrant also has more options for stateless deployments than Docker: docker, packer, nixos, et cetera.
> The main push of docker seems to be for completely self-contained applications, basically a super cheap and consistent VM. But VMs are a hack, and docker in many ways is just as hacky.
So I just thought that the problem you have with Docker is similar to the author of the article (which is anti Docker/VM, since he dislike both).