Re: native Linux userland in Windows 10

[Warren Young <wyml at etr-usa dot com>]

On Apr 12, 2016, at 6:50 AM, Andrew Schulman <schulman.andrew@epa.gov> wrote:
> 
> By now I guess most of us have seen the reports of bash, and in fact a full
> Linux userland, running natively in Windows 10:

Yes; I started a thread here a couple of weeks ago on the same topic:

  http://comments.gmane.org/gmane.os.cygwin.talk/5285

You might find my analysis of the feature useful.

> Apparently
> Microsoft has developed an API translation layer, simliar to the Cygwin DLL,

No, not like the Cygwin DLL at all.

>From the very start, the Windows NT kernel has had a âsubsystemsâ feature that lets it implement many different APIs on top of the core kernel.  This is the API that the old Services For Unix product (nee Interix) used, which is why I call this feature âSFU rides again.â

There are two major differences relative to Cygwin because of this:

1. NT subsystems canât talk to each other.  Programs running under one subsystem are fully isolated from the others, kind of like running in separate VMs on the same host hardware.  This means simple things like âpsâ donât do what you expect.  Pretty much the only sharing possible is through the filesystem or network.

2. Itâs not an emulation layer.  Itâs all implemented inside the kernel, so you get 100% native application speed, full process isolation, etc.  Many of the problems with Cygwin simply go away: fork() problems, shared memory hacks via cygserver, etc.

> The first link cited above suggests that if this is all it claims to be, it
> would remove the need for Cygwin.

For some, yes, but it will hardly be an immediate Cygwin killer.

There are some huge areas where it will indeed be the better choice, such as running network servers.  (Apache, ssh, nginx, nodeâ)

There are also a whole pile of disadvantages that will continue to drive people to Cygwin:

1. According to the info Iâve seen, itâs 64-bit only.

2. Only works on Windows 10.

3. Because of the NT kernel subsystem isolation, interop with native Windows processes is nearly nonexistent.  For example, I have a native Windows program I work on here that needs an MSI installer, and I build that by scripting the WiX command line tools in Bash, under Cygwin.  I canât do that in this new âUbuntu for Windowsâ thing because programs running under it canât launch native Win32 processes, such as WiXâs candle.exe.  This is a bidirectional problem: you canât launch a Bash shell script from PowerShell, either.

4. No X11.

5. No AD/SAM integration.

The first two are huge problems today, from a âCygwin killingâ standpoint, but as the user base moves into Windows 10, the problem will disappear.

The latter two may improve over time.

As far as I can tell, the only reason for the âno Xâ limitation is that they havenât bothered to port X yet.  X being network based, you shouldnât even need a ânativeâ X server for it.  You could start Cygwin/X11 on the same box and run X software that way.

As for limitations like AD/SAM, that should disappear over time, too, as they go from 1.0 to 2.0.

That leaves only the inherent isolation from NT subsystems as a long-term limitation.

> I realize this may be strictly off-topic here,

Thereâs no such thing as off-topic on -talk. :)

> but it seems to me to be
> potentially so important to the future of Cygwin that it's worth discussing here
> insted of on cygwin-talk.

Wha??  You *are* on cygwin-talk.