31–40 of 45 posts
So, this is this a means to bridge the gap between Hyper-V, Hyper-V app streaming and Docker on the windows side? I'm kinda confused what the use case is compared to other existing product offerings.
Seems like Microsoft's response to docker, although I have no idea if it actually is, in terms of precedence. But certainly aimed at the same idea.
Not really. It is a research project, and predates Docker.
Earlier quoted context omitted.
> "why not make an operating system that has only 45 syscalls?" Because much of Microsoft's licensing revenue is contingent upon continuing to support the edge cases that are inevitably not part of the set of programs that can be dropped into such a sandbox without problems.
You missed the joke. NT was originally a pretty hardcore microkernel, with even things like graphics drivers being in userspace. However, in the name of performance, more and more stuff was brought into kernel space.
NT is sometimes mistaken for a microkernel partly because of the graphics driver problem, and partly because it contains a module which Microsoft actually refers to as "the microkernel". This part consists mostly of the scheduler.
What is true about the NT kernel is that it's modular, with strict internal API separation between each subsystem, and that kind of design was (as far as I know) inspired by actual microkernels, as was the idea of hiding the kernel behind "OS personalities" such as Win32.
Earlier quoted context omitted.
Not really. It is a research project, and predates Docker.
LXC containers predate Docker, too. In any case, it doesn't really matter whether it's an actual response, or not.
Infact, Docker started as a wrapper around LXC. It literally configured and shelled out to lxc-start in order to orchestrate containers.
This however, is much much different to cgroups/namespaces.
What the Drawbridge paper describes is a full user-mode kernel . If you want the analagous implementation on Linux look at User Mode Linux, or the Graphene stuff that has already been linked to.
This seems like Microsoft's response to Bromium vSentry which is a very impressive product. http://www.bromium.com/products/vsentry.html
This sounds a lot like Docker for Windows, am I right ? I might have to try it to understand it, but it is exciting.
Earlier quoted context omitted.
LXC containers predate Docker, too. In any case, it doesn't really matter whether it's an actual response, or not.
Docker is not anything, Docker is a wrapper for cgroups and namespaces - also utilized by LXC. Infact, Docker started as a wrapper around LXC. It literally configured and shelled out to lxc-start in order to orchestrate containers. This however, is much much different to cgroups/namespaces. What the Drawbridge paper describes is a full user-mode kernel . If you want the analagous implementation on Linux look at User…
"a version of Windows enlightened to run efficiently" is just begging to be quoted out of context.
Earlier quoted context omitted.
You missed the joke. NT was originally a pretty hardcore microkernel, with even things like graphics drivers being in userspace. However, in the name of performance, more and more stuff was brought into kernel space.
NT was never a true microkernel (much less a hardcore one), and was never intended to be. It was never designed to have any protection between its internal "subsystems" (file system I/O, security, HAL, drivers, etc.) — everything runs in kernel mode, in the same address space, and communicates using direct calls, not IPC. NT is sometimes mistaken for a microkernel partly because of the graphics driver problem, and pa…
While NT is not a microkernel, from a kernel API level it appears to basically be one, only missing the fact that everything is not actually isolated.
It is important to note how this will shake the current state of the application virtualization market. There is no docker like solution for Windows. All the big players (VMware, Microsoft, Symantec, etc) do tricks to isolate the applications. The tricks are instrumenting API calls and adding filtering drivers. With these solutions only less than 70% can be virtualized and the process can be really difficult.
Because from what I've seen of the current state of docker, non trivial linux applications seem to have issues in docker as well because they depend on specific things which are not being namespaced well (say /sys manipulations for example, ioctls, or even use filesystem specific APIs).
Docker seems to work well as long as one stays close to web server functionality. (aka LAMP like stacks which tend to only manipulate network sockets and traditional files).