[kolencherry]

From the TechNet Announcement:

"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/...

[ochoseis]

Since this is all remote powershell, it would be nice if MS/Windows introduced a native SSH server. That would probably help drive some conversion for people used to the posix world.

[quotemstr]

In order to make a native SSH server, Windows need pseudoconsoles (analogous to pseudoterminals in POSIXland). That is, it must be possible for a random program to create a handle that supports operations like SetConsoleCursorPosition without having to call AllocConsole. Calling AllocConsole is a problem because there's no way to monitor what programs are doing with that console except scraping it. (The accessibility hooks are insufficient because if you try to access the console from inside them, you deadlock, and if you queue an access request for later, you race.)

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.

[olavgg]

This!!!! One of the biggest things I really miss in Windows-land is SSH. Just today I had to create a SSH tunnel for SQL Server. While it's not a big issue with third party tools, it should just be built and ready for use as with every Linux distro, FreeBSD, Solaris and OSX.

[dordoka]

While they are at it, they could create a posix compatible layer for Windows. That would really drive some conversion.

edit: after rereading my comment and seeing the downvotes, just to clarify, it was a serious, not negative suggestion. :)

[tkmcc]

There used to be Windows Services for UNIX (a.k.a. Subsystem for UNIX-based Applications):

http://en.wikipedia.org/wiki/Windows_Services_for_UNIX

https://technet.microsoft.com/en-us/library/cc771470.aspx

[mushiake]

They ditched in Windows Server 2012.

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

[DiabloD3]

msys2 is a lot better than mingw+msys and cygwin, in my opinion. I switched months ago and its been a lot easier to deal with.

[emodendroket]

They've done that before and, as far as I know, it was not an extremely popular product.

[stormbrew]

It was not an extremely functional product. It was largely there to get government contracts where one of the requirements was POSIX conformance, even if they weren't using it.

[emodendroket]

Imagining they had first-class support for it (a major undertaking, I'd guess, but anyway) how many people would use it? I'd guess it'd be about the same people who use Cygwin now.

[stormbrew]

Why would you guess that? Because cygwin is nothing close to first class support. It has a lot of friction associated with its use. You're better off just running linux in a vm if you want posix on windows, and trust me plenty of people do that these days.

[rbanffy]

Anyone porting applications from Linux would be able to use it to reduce the effort.

[jamra]

I think with Azure, you can log into your Azure instance and then send commands. I recently tried to set up automated deployments for our non-Azure infrastructure and investigated bringing things to Azure.

It's not the same as SSH, but then again powershell is not the same as linux shells.

[rsync]

"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."

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 ?

[wila]

Not really the first time. Windows Server Core has existed since Windows Server 2008 [1]. Sounds like they stripped some more parts like MSI and 32 bits support.

[1] https://msdn.microsoft.com/en-us/library/dd184075.aspx

[lawl]

Thanks for the clarification. I at first assumed they'd bring OS level virtualization, apparently I'm not the only one. But it's basically just minimal images of windows in regular VMs then...

A step in the right direction but still disappointing imo. Linux and BSD are still miles ahead.

[throwaway1979]

So this is like boot2docker ... on Windows? You have a VM and you have containers inside it. This is not the same as containers on baremetal. But that is fine .. my confusion is the OS inside the VM. Is that Linux or Windows? Normally, I can run Ubuntu and Centos-based containers on my box. Can I run these as Hyper V containers? What about dot net? Can that be containerized.

[lawl]

No. When you talk about containers, you talk about operating system level virtualization[0]. This means you have one kernel, with multiple user spaces. You can run a CentOS container on Ubuntu because both use a Linux Kernel. What will actually happen is that CentOS will use your already booted Ubuntu Kernel.

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...

[justincormack]

You might be able to run Windows containers under Wine....

[waitwaitwhay]

That referrs to Nano, not Hyper V virtualization?

[wmf]

Microsoft is doing OS-level containers and they are also going to allow running containers in VMs.

[johngossman]

Trying to clarify. We are talking about 3 things: 1) OS virtualization for Windows. We announced this last year: http://azure.microsoft.com/blog/2014/10/15/new-windows-serve... 2) Nano Server -- A small Windows Server sku. Perfect for containers, but also useful for other scenarios where you need a small, cloud optimized Windows 3) Hyper-V Containers -- Think if you wanted to optimize a hypervisor with assumption that it is only running a container. What enlightenments would you enable? What management interface would you put on it? We'll have more details later, but this is the core concept.

[MichaelGG]

I guess the question is, are these containers a shared kernel, near zero overhead kinda thing? So I could just run, say, DNS or a file share in a container without paying any overhead. Like what containers/jails or OpenVZ can do on Linux.

[atomi]

In other words, if you want to run a Linux based Docker container on Windows you're still going to need Virtual Box.

[jacques_chester]

> In other words, if you want to run a Linux based Docker container on Windows you're still going to need Virtual Box.

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.

[atomi]

You have a good understanding of why this is the case. Hyper-V would be doing the job of Virtual Box and boot2docker which is what most developers have been using to run Docker daemon on non-linux hosts. I've tried the Hyper-V driver with Docker Machine and had some issues. So I'll be sticking with Virtual Box until that changes.

[nickstinemates]

Or Hyper-V, or VMWare Equivalent (Fusion/Workstation/etc)

[bydo]

They're doing OS-level virtualization in Linux Azure instances, sure. They don't seem committed to OS-level virtualization in Windows, unless I've missed something.

edit: http://research.microsoft.com/en-us/projects/drawbridge/ ?

[lawl]

That's what you would assume when you look at the image. But

> 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?

[cwyers]

All we have is a press release. The diagram and the constant references to containers would seem to indicate these are, well, containers. You're picking at a few things and assuming they mean that the rest of the release is wrong. Why?

[guelo]

> All management is performed remotely

Wow, I've been out of the Windows world for years, can you really fully manage a Windows box without the GUI?

[motoboi]

No. But you can use your machine to run the tools which will connect to the server. You can do this with desktops, not only windows server. Try Computer Management on your machine.