From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 52765 invoked by alias); 20 Apr 2016 22:10:21 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 52745 invoked by uid 89); 20 Apr 2016 22:10:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.5 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=swaps, isn, Oracle, can 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; Wed, 20 Apr 2016 22:10:08 +0000 Received: (qmail 52934 invoked by uid 13447); 20 Apr 2016 22:10:06 -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 ; 20 Apr 2016 22:10:06 -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: <152468049.20160415130425@yandex.ru> Date: Wed, 20 Apr 2016 22:23:00 -0000 Content-Transfer-Encoding: quoted-printable Message-Id: <980EF918-9A26-4F02-88D6-53951432B0E4@etr-usa.com> References: <416uDmm4T7200S05.1460552179@web05.cms.usa.net> <84CCF5B5-9F11-4541-A527-FD0BD3AE5545@etr-usa.com> <1117668279.20160414220758@yandex.ru> <9B4C5920-2F0F-4D7C-A489-A6329679A1E8@etr-usa.com> <152468049.20160415130425@yandex.ru> To: cygwin@cygwin.com X-IsSubscribed: yes X-SW-Source: 2016-04/txt/msg00538.txt.bz2 On Apr 15, 2016, at 4:04 AM, Andrey Repin wrote: >=20 >> And yet, despite the free >> availability of top-quality VM technology, Cygwin continues to thrive. >=20 > Because interoperability. So the ability to run native Linux ELF binaries without recompilation on Wi= ndows is not =E2=80=9Cinteroperability=E2=80=9D? >> UfW won=E2=80=99t fill 100% of the use cases of Cygwin from day 1, but f= or a lot of >> cases, the two will be interchangeable, >=20 > Name me a few. I can name a bunch, including some where UfW comes out ahead: 1. The Cygwin solution has some fatal flaw, either due to a missing POSIX f= acility in cygwin1.dll or an attempt to bypass the DLL, going straight to t= he Windows API under Cygwin, which results in mismatched semantics. One such example is the recent complaint thread about Git=E2=80=99s path ha= ndling, which wouldn=E2=80=99t even come up under UfW, because it isn=E2=80= =99t Windows at all. Git under UfW has exactly the same semantics as under= Linux, where presumably the semantics are perfect, since Linux is git=E2= =80=99s natural environment. Another example is CRLF and UTF-8 handling. Any program running under Cygw= in that bypasses its POSIX interfaces (e.g. calling ReadFile() instead of r= ead(2)) will likely do strange things with LF-terminated UTF-8 text files, = whereas a UfW binary will always assume LF and UTF-8 (or $LANG, anyway) tex= t encoding. Thus, all the hacks in Cygwin and Cygwin-ported executables fo= r CRLF workarounds (e.g. Cygwin=E2=80=99s =E2=80=9Ctext=E2=80=9D mount opti= on hack, the crnl-glob feature in Fossil to make it ignore CRs when determi= ning if a file is =E2=80=9Cbinary=E2=80=9D, etc.) don=E2=80=99t need to exi= st under UfW. Still another example is the unfortunate mismatches in Windows vs POSIX fil= e locking semantics, as you recently noted in your recent thread complainin= g about another =E2=80=9Cuseless=E2=80=9D feature, Cygwin=E2=80=99s flock()= implementation. Again, the insides of the UfW box are completely POSIX, n= ot Windows at all, so presumably locking semantics are Linux-native (i.e. a= dvisory by default, rather than mandatory), too, so there is no mismatch be= tween Windows and POSIX semantics. Here, the wall between NT subsystems he= lps: you can=E2=80=99t have a Windows app and a UfW app fighting for lock c= ontrol of a single file, since Windows apps can=E2=80=99t even see inside t= he UfW filesystem. (You could have such a fight through the /mnt/[driveletter] door, but that= =E2=80=99s like arguing that the availability of NFS or SMB locking prevent= s Linux locking semantics from working correctly. Conflicts can only occur= in the shared filesystem.) 2. Many people using Cygwin merely want a given non-portable Unixy tool (e.= g. git) to work on Windows. The choice between installing Cygwin git vs in= stalling UfW from the Windows app store and then saying =E2=80=9Capt instal= l git=E2=80=9D is a =E2=80=9Csix of one, half a dozen of the other=E2=80=9D= alternative, as long as you=E2=80=99re only interested in managing a Windo= ws git tree from the command line.=20 If you need non-CLI things to work, such as like git gdiff integration with= , say, Beyond Compare, then of course you=E2=80=99d have to use Cygwin git = or similar, such as the MinGW-based =E2=80=9CGit for Windows=E2=80=9D offer= ing instead of UfW git. 3. You=E2=80=99re using Cygwin merely to give Windows an interactive POSIX = userland, so you have things like grep and sed for operation on Windows fil= esystem objects. The same ability to say something like =E2=80=9Csed -i -e= s/foo/bar $(grep -Rsl foo)=E2=80=9D in Cygwin works just as well under UfW= . It works better under UfW, in fact, since the recursive filesystem searc= h will probably be a lot faster under UfW, since all file access isn=E2=80= =99t going through an in-userspace POSIX translation layer. This is what I meant when I described UfW as an apology to Windows users fo= r the complete misinterpretation of request vs intent when the PC poweruser= crowd demanded a better shell and Microsoft gave us PowerShell instead of = what we actually wanted, which is something more like Bash. 4. You=E2=80=99re using Cygwin on Windows to test software that normally bu= ilds and runs on Linux on a PC where installing Linux or a VM manager isn= =E2=80=99t an option. (e.g. A typical corporate locked-down desktop PC.) = Given a choice between Cygwin and UfW, both will work; UfW will probably wo= rk better, since your actual deployment environment needs ELF executables, = so you can even build distribution tarballs under UfW, whereas under Cygwin= , you=E2=80=99d have to do cross-compilation, which adds a bunch of complex= ity. (Custom compilers, separate include and lib trees, etc.) In fact, in such an environment, UfW might have a distinct advantage, being= available through the Windows Store. A typical corporate PC lock-down pol= icy might not restrict installation from the Windows Store (such apps being= pre-vetted, signed, and therefore =E2=80=9Csafe=E2=80=9D) but might preven= t installation of Cygwin, since Cygwin is third-party and doesn=E2=80=99t n= ormally install on a per-user basis. 5. Anything where the Ubuntu package repo has software not present in the C= ygwin or Cygwin Ports repo. For example, the Cygwin package repo only has = iperf2, which is protocol-incompatible with iperf3. If you need to do a ba= ndwidth test against a remote system running iperf3, installing UfW so you = can =E2=80=9Capt install iperf3=E2=80=9D is probably easier than porting ip= erf3 to Cygwin and maintaining a private copy.=20=20=20 (Indeed, iperf3 doesn=E2=80=99t build OOTB on Cygwin due to an API conflict= with newlib, a problem that doesn=E2=80=99t impact glibc based systems lik= e UfW.) Plus, iperf3 measures I/O overheads, so the lower impedance mismatch betwee= n the UfW ABI and the cygwin1.dll translation layer means the benchmark res= ults will probably be more accurate under UfW. (i.e. A truer measure of th= e system=E2=80=99s network I/O bandwidth.) 6. A lot of Unix software runs like a pig under Cygwin due to the user-spac= e gyrations Cygwin must go through to implement POSIX semantics under Windo= ws. The classic example of this is fork(), which makes a lot of software (e.g. = Apache, shell scripts, etc.) much faster on Linux or in native Windows port= s than under Cygwin. Another example is anything dealing with many I/O sockets or other file des= criptors, which often use poll() or epoll() on Linux for speed, relative to= select(2). Cygwin doesn=E2=80=99t implement epoll() at all, its poll() im= plementation is done in terms of select() (therefore giving no speed advant= age at all) and its select() implementation doesn=E2=80=99t even delegate t= o the in-kernel Windows Winsock function select(), but instead reimplements= its effect purely in user space in terms of Windows events, which are limi= ted to 64 per user thread, purely to get POSIX semantics (e.g. select() on = FD, FD passing, etc.) under Windows, things the Winsock select() implementa= tion doesn=E2=80=99t provide. All of this makes Cygwin select() much slowe= r than Winsock select(), which in turn is much slower than more modern inte= rfaces native to Linux and its competitors, such as epoll(), kqueue, aio_*(= ), and IO Completion Ports. Still another common area of Cygwin weakness is in threading. Cygwin=E2=80= =99s handling of threads is a lot better these days than it used to be, but= it=E2=80=99s still not at the level of thread handling under Linux, due to= the translation layer Cygwin needs to supply to convert POSIX threading se= mantics to Windows semantics. We saw this on the mailing list not long ago= when someone posted a question about using C++=E2=80=99s native threading = libraries under g++ on Cygwin, where Cygwin did something very odd that it = didn=E2=80=99t do on Linux. No one answered the question, apparently becau= se so few Cygwin users really understand how Cygwin threads are supposed to= work, whereas such software Just Works on Linux, where the NPTL library an= d its in-kernel backings (e.g. clone(2)) are highly-debugged and optimized. Thus, the availability of UfW will be a much greater disincentive to create= native Windows ports of software than Cygwin ever was. We have things lik= e native Apache for Windows because it simply runs so much better that way = than under Cygwin, because it swaps out all the POSIX mechanisms for native= ones, removing the impedance layer mismatch. That was necessary 20 years = ago when the alternative was Cygwin and all its attendant limitations. The= same will be true for anything else based on libapr, like Subversion, anot= her piece of software that=E2=80=99s difficult to port to Cygwin, as I unde= rstand it. Whereas =E2=80=9Capt install subversion=E2=80=9D is trivial. 7. Running =E2=80=9Ctoo-portable=E2=80=9D software. A lot of things ported to Cygwin have in-tree support for building natively= on Windows as well. (e.g. Perl.) Often such software has =E2=80=9C#ifdef= WINDOWS=E2=80=9D conditional code in it, so that it behaves differently wh= en run under Cygwin than when run under Linux, because its portable code co= mpiles instead of the POSIX alternative. Thus, a UfW version of the same p= rogram may simply behave more correctly than a naive rebuild of the same so= urce under Cygwin. A true Cygwin port =E2=80=94 where all the #if WINDOWS = code is carefully rewritten so the ifdef path isn=E2=80=99t taken under Cyg= win =E2=80=94 may simply not be available, whereas a proper Linux binary bu= ild may be available under UfW. 8. All of us who greatly prefer installing software via a command line pack= age manager (e.g. apt, pkg, brew, yum=E2=80=A6) rather than a GUI (e.g. set= up.exe) will probably be happier under UfW than on Cygwin. =E2=80=9Capt in= stall foo=E2=80=9D is a whole lot easier than Cmd-E, navigate to the Cygwin= download folder, and click-click-click for 2-3 minutes to navigate the GUI= just to install one piece of software. 9. A lot of software for Linux simply isn=E2=80=99t portable enough to buil= d under Cygwin, and there is no native Windows port. Such software may do = low-level unportable things, include assembly language hacks, etc. that don= =E2=80=99t work on Windows, so your only alternative heretofore to run such= software on a Windows box was to run a Linux VM. (e.g. Node.js, the Oracl= e JVM (as opposed to Cygwin=E2=80=99s current JVM alternative, gcc-gcj), Va= lgrind, etc.) Bottom line, for many use cases, UfW might well completely displace Cygwin. Obviously Cygwin will continue to be useful in many cases, too, as I enumer= ated in my original post on the -talk list in the Disadvantages section of = the post. > People always find uses for everything. Doesn't make it any > more useful. Again, I think you might be running into an =E2=80=9CEnglish as a second la= nguage=E2=80=9D problem here. (I wouldn=E2=80=99t normally complain about your use of English except for = your signature, apologizing for your facility with the English language. I= am therefore taking your signature at its face value: an admission that yo= ur facility with the language is not at the level you wish it to be.) Let=E2=80=99s define terms: useless /y=C5=8Dosle=C9=99s/ adj. not fulfilling or not expected to ach= ieve the intended purpose or desired outcome. Therefore, a thing is only =E2=80=9Cuseless=E2=80=9D if if fails to achieve= intended purposes. You can say that UfW is useless *for your own purposes= *, but to claim that a clearly useful thing is flat out =E2=80=9Cuseless=E2= =80=9D is simply incorrect. There is almost nothing in the world that is p= urely =E2=80=9Cuseless.=E2=80=9D I=E2=80=99m fine if you want to say UfW is of no use to yourself. I=E2=80= =99m objecting to the concept that because you can=E2=80=99t use it, that n= o one else can use it either because it is =E2=80=9Cuseless.=E2=80=9D That is, my objection is to the absolute nature of your statement. If you = make such a statement relative to yourself and I won=E2=80=99t have any arg= ument against the pronouncement. > And they will see no issues when moving from this crap to real *NIX syste= m. There=E2=80=99s much less impedance mismatch between UfW and Linux than bet= ween Cygwin and Linux. Therefore, UfW wins on this front as well. Is UfW problem-free? Certainly not. But does it have reduced problems rel= ative to Cygwin? In many cases, yes. > Always working as root? What could possible go wrong? That=E2=80=99s a temporary issue, a limitation of UfW=E2=80=99s current bet= a nature. Microsoft have publicly stated that they will be reworking it to= allow it to run under your normal user=E2=80=99s permissions and to implem= ent sudo before they release it to the public. I=E2=80=99m sure the =E2=80=9Ceverything runs as root=E2=80=9D nature of it= is for the same reason that during the bootstrapping process for any OS, y= ou normally do everything as root. User permission management is one of th= e last things you port over when bootstrapping a new OS, once all the tooli= ng is ported over.=20 -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple