* Re: native Linux userland in Windows 10
[not found] <70rpgbh81o3fkrdgh8ldh2hmon25ihnr1s@4ax.com>
[not found] ` <570CF112.6060405@gmail.com>
@ 2016-04-12 15:46 ` Warren Young
2016-04-12 15:53 ` Corinna Vinschen
1 sibling, 1 reply; 4+ messages in thread
From: Warren Young @ 2016-04-12 15:46 UTC (permalink / raw)
To: The Vulgar and Unprofessional Cygwin-Talk List
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.
^ permalink raw reply [flat|nested] 4+ messages in thread