From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21527 invoked by alias); 12 Apr 2016 15:46:01 -0000 Mailing-List: contact cygwin-talk-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: cygwin-talk-owner@cygwin.com Reply-To: The Vulgar and Unprofessional Cygwin-Talk List Mail-Followup-To: cygwin-talk@cygwin.com Received: (qmail 20718 invoked by uid 89); 12 Apr 2016 15:46:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=4.6 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPAM_BODY autolearn=no version=3.3.2 spammy=killer, vms, D*gov, pile X-HELO: etr-usa.com Received: from etr-usa.com (HELO etr-usa.com) (130.94.180.135) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 12 Apr 2016 15:45:50 +0000 Received: (qmail 43517 invoked by uid 13447); 12 Apr 2016 15:45:48 -0000 Received: from unknown (HELO polypore.west.etr-usa.com) ([73.26.17.49]) (envelope-sender ) by 130.94.180.135 (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 12 Apr 2016 15:45:48 -0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: native Linux userland in Windows 10 From: Warren Young In-Reply-To: <70rpgbh81o3fkrdgh8ldh2hmon25ihnr1s@4ax.com> Date: Tue, 12 Apr 2016 15:46:00 -0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <70rpgbh81o3fkrdgh8ldh2hmon25ihnr1s@4ax.com> To: The Vulgar and Unprofessional Cygwin-Talk List X-IsSubscribed: yes X-SW-Source: 2016-q2/txt/msg00006.txt.bz2 On Apr 12, 2016, at 6:50 AM, Andrew Schulman wrot= e: >=20 > By now I guess most of us have seen the reports of bash, and in fact a fu= ll > 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 D= LL, No, not like the Cygwin DLL at all. >From the very start, the Windows NT kernel has had a =E2=80=9Csubsystems= =E2=80=9D 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 I= nterix) used, which is why I call this feature =E2=80=9CSFU rides again.=E2= =80=9D There are two major differences relative to Cygwin because of this: 1. NT subsystems can=E2=80=99t talk to each other. Programs running under = one subsystem are fully isolated from the others, kind of like running in s= eparate VMs on the same host hardware. This means simple things like =E2= =80=9Cps=E2=80=9D don=E2=80=99t do what you expect. Pretty much the only s= haring possible is through the filesystem or network. 2. It=E2=80=99s not an emulation layer. It=E2=80=99s all implemented insid= e the kernel, so you get 100% native application speed, full process isolat= ion, 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 a= s running network servers. (Apache, ssh, nginx, node=E2=80=A6) There are also a whole pile of disadvantages that will continue to drive pe= ople to Cygwin: 1. According to the info I=E2=80=99ve seen, it=E2=80=99s 64-bit only. 2. Only works on Windows 10. 3. Because of the NT kernel subsystem isolation, interop with native Window= s processes is nearly nonexistent. For example, I have a native Windows pr= ogram I work on here that needs an MSI installer, and I build that by scrip= ting the WiX command line tools in Bash, under Cygwin. I can=E2=80=99t do = that in this new =E2=80=9CUbuntu for Windows=E2=80=9D thing because program= s running under it can=E2=80=99t launch native Win32 processes, such as WiX= =E2=80=99s candle.exe. This is a bidirectional problem: you can=E2=80=99t = 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 =E2=80=9CCygwin killing=E2=80= =9D standpoint, but as the user base moves into Windows 10, the problem wil= l disappear. The latter two may improve over time. As far as I can tell, the only reason for the =E2=80=9Cno X=E2=80=9D limita= tion is that they haven=E2=80=99t bothered to port X yet. X being network = based, you shouldn=E2=80=99t even need a =E2=80=9Cnative=E2=80=9D 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 th= ey go from 1.0 to 2.0. That leaves only the inherent isolation from NT subsystems as a long-term l= imitation. > I realize this may be strictly off-topic here, There=E2=80=99s 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 discussi= ng here > insted of on cygwin-talk. Wha?? You *are* on cygwin-talk.