[Intermernet]

My prediction is that they'll continue to work on the recently announced "Windows Subsystem for Linux"[1] and attempt to cover a larger and larger portion of the Linux ABI. If people can develop, and run the majority of Linux programs on Windows, and those programs are competitive in performance, and those programs have MS support backing, then they have a huge win in the enterprise space.

Personally, I'm happy to keep providing whatever mix of OS services customers request, but I'm very interested in where this could be going

[1]: https://blogs.windows.com/buildingapps/2016/03/30/run-bash-o...

[zeta0134]

I think this is an amazing move for Microsoft. If they get the kinks worked out and get it working well on Windows Server, they'll have one platform that can run pretty much all the major enterprise software without virtualization. That's great; it's a way for Linux shops to convert to Windows Server without having to fully commit right away, because they'll still be able to quite easily run their existing stack and leverage their developers who are used to Linux tooling.

[tluyben2]

Why is that good though; why would Linux shops want to convert? In the space I work in companies (including enterprises) like the fact they can do whatever with the source code and that they can audit whatever part they want. MS has that too but not for many clients and you cannot do whatever with it. The freedom in Linux means a lot to a lot of people even if you maybe could get a bit more perf or support from a paid platform. We have people working with VS (a few only) and because of our tooling it works smoothly anyway. I have no clue why you would switch to something paid and closed...

[rgbrenner]

It sounds like a rehash of Windows Services for Unix: https://en.wikipedia.org/wiki/Windows_Services_for_UNIX

What's different this time?

My prediction is that it'll languish in obscurity, rarely used, and eventually be discontinued.

[akiselev]

This time around we have a decade plus of virtualization experience and specialized silicon in many (most?) modern processors like Intel VT-i/x/d and AMD-V. We no longer have to try to emulate kernel code or implement interfaces like POSIX or WINE on top of other kernels that inevitably lead to impedance mismatches between very different archirectures.

For example, modern virtual machine software like Parallels and VMWare Workstation allow for "unity" modes where the guest OS window manager is hijacked so that each window can be rendered onto the host without the rest of the guest desktop interface. If you're running the guest kernel "side by side" with the host as a virtual machine, you can focus on drivers that bridge the two operating systems (filesystem, network, window manager, etc.) and make it seamless instead of trying to shoehorn a low level emulated interface into a system that may not be ergonomic for that task.

[e12e]

> What's different this time?

Running 64bit Linux elf binaries on the NT kernel, side-by-side with windows binaries is quite different from WSUS -- at least what experience I had with WSUS. It's more like Wine (a port of the win32 api to Linux (and BSD/OS X?) that allows running unmodified windows executables on Linux.

Being able to "apt install redis" on windows, and get the redis-build that Ubuntu ships, and be able to use it locally is a pretty big deal, IMNHO.

[mappu]

WSUS is (conventionally) something different when talking about Microsoft - https://en.wikipedia.org/wiki/Windows_Server_Update_Services - whereas you clearly mean ${whatever Interix ended up renamed to}.

[e12e]

Yeah, according to Wikipedia, the abbriviation(s) I was looking for was: "Windows Services for UNIX (SFU)".