Is this just about management tools? Because that's cool, too, but why the spin?
Is this just about management tools? Because that's cool, too, but why the spin?
"we removed the GUI stack, 32 bit support (WOW64), MSI and a number of default Server Core components. There is no local logon or Remote Desktop support. All management is performed remotely via WMI and PowerShell. We are also adding Windows Server Roles and Features using Features on Demand and DISM. We are improving remote manageability via PowerShell with Desired State Configuration as well as remote file transfer, remote script authoring and remote debugging. We are working on a set of new Web-based management tools to replace local inbox management tools."
http://blogs.technet.com/b/windowsserver/archive/2015/04/08/...
A step in the right direction but still disappointing imo. Linux and BSD are still miles ahead.
So unless Windows switches to a Linux Kernel or vice versa you will never be able to run one as a container on the other.
You can however do that with Virtual Machines. But installing a stripped down version of windows in a virtual machine does not make it a container, it makes it marketing bullshit.
"Containers on baremetal" and containerizing dot net are thus a bit silly concepts since .NET has nothing to do with the operating system and you can't run a container on "bare metal" whatever you might mean by that.
[0] http://en.wikipedia.org/wiki/Operating-system-level_virtuali...
edit: http://research.microsoft.com/en-us/projects/drawbridge/ ?
> Hyper-V Containers, a new container deployment option with enhanced isolation powered by Hyper-V virtualization.
Everything written tells a different story. "Hyper-V virtualization" means virtual machines, making it not a container. They just try to make that sound like a feature.
Or do you have more information than I do?
Is this a surprise?
Containerisation is not magical pixie dust -- it's a particular approach to implementation that is specific to the OS. You have a single kernel, and it follows that in general that single kernel will only allow corresponding containers to be run.
That there will be a Docker server backend that can speak Hyper-V doesn't magically make a Windows kernel into a Linux kernel, or vice versa.
edit: after rereading my comment and seeing the downvotes, just to clarify, it was a serious, not negative suggestion. :)
Now recommend cygwin.
"The Subsystem for UNIX-based Applications (SUA) is deprecated. If you use the SUA POSIX subsystem with this release, use Hyper-V to virtualize the server. If you use the tools provided by SUA, switch to Cygwin's POSIX emulation, or use either mingw-w64 (available from Sourceforge.net) or MinGW (available from MinGW.org) for doing a native port. " https://technet.microsoft.com/en-us/library/hh831568.aspx
Since consoles are real kernel objects since Windows 8 and talk to conhost over IPC anyway, this feature is eminently doable. It's been my top feature requests for years. Nobody's gotten around to it.
Pseudoconsoles would be a bit more complicated than POSIX pseudoterminals because Windows consoles have more features, but the basic concept would transplant beautifully. It'd also make Cygwin a lot better.
I miss working on operating systems.
It's not the same as SSH, but then again powershell is not the same as linux shells.
Wow, I've been out of the Windows world for years, can you really fully manage a Windows box without the GUI?
Is this unprecedented ? I think it is, but I've been divorced from the windows ecosystem for a very, very long time ...
Is this, in fact, the first time that there has been a Windows release that had ... no windows ? Had no GUI ? Was administered with a CLI only ?
It makes sense for their container solution to make use of existing Hyper-V components like the virtual switch etc.
But for that to be possible it's likely they needed to make use of VT-x and VT-d (if using stuff like hardware accelerated network device isolation like SRIOV).
If anything this is closer to Bromium [1] than anything else.
Will be interesting to see if this requires Hyper-V to be running in Type-1 mode (or if this will be the default in upcoming Windows versions) or if they are able to make use of the virtualisation extensions without actually running the host as a Hyper-V partition.
So much cool stuff to hear about at BUILD.
Done correctly this allows the hardware level protections to apply to the code running in the container, assuming the penalty of your OS calls routing through the VM-bridge doesn't kill your performance.
Hope that helps?