native Linux userland in Windows 10

[David Macek]

Note that I'm not necessarily arguing against you in every point you wrote. Some reactions are just notes.

On 21. 4. 2016 0:10, Warren Young wrote:
> One such example is the recent complaint thread about Git’s path handling, which wouldn’t even come up under UfW, because it isn’t Windows at all.  Git under UfW has exactly the same semantics as under Linux, where presumably the semantics are perfect, since Linux is git’s natural environment.
> 
> Another example is CRLF and UTF-8 handling.  Any program running under Cygwin that bypasses its POSIX interfaces (e.g. calling ReadFile() instead of read(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) text encoding.  Thus, all the hacks in Cygwin and Cygwin-ported executables for CRLF workarounds (e.g. Cygwin’s “text” mount option hack, the crnl-glob feature in Fossil to make it ignore CRs when determining if a file is “binary”, etc.) don’t need to exist under UfW.
>
> Still another example is the unfortunate mismatches in Windows vs POSIX file locking semantics, as you recently noted in your recent thread complaining about another “useless” feature, Cygwin’s flock() implementation. Again, the insides of the UfW box are completely POSIX, not Windows at all, so presumably locking semantics are Linux-native (i.e. advisory by default, rather than mandatory), too, so there is no mismatch between Windows and POSIX semantics. Here, the wall between NT subsystems helps: you can’t have a Windows app and a UfW app fighting for lock control of a single file, since Windows apps can’t even see inside the UfW filesystem.

So far you're enumerating limitations of Cygwin-Win32 interoperability, not limitations of Cygwin. Correct me if I'm wrong, but AFAIK if you stick to (well-written) Cygwin programs and Cygwin filesystem, you don't have to work around wrong line endings nor strong locks.

> (You could have such a fight through the /mnt/[driveletter] door, but that’s like arguing that the availability of NFS or SMB locking prevents Linux locking semantics from working correctly.  Conflicts can only occur in the shared filesystem.)

I would like to make the same argument for Cygwin and /cygdrive.

> 4. You’re using Cygwin on Windows to test software that normally builds and runs on Linux on a PC where installing Linux or a VM manager isn’t an option.  (e.g. A typical corporate locked-down desktop PC.) Given a choice between Cygwin and UfW, both will work

You can install UoW without admin privileges? Or from another POV, you can install UoW but not VirtualBox?

> In fact, in such an environment, UfW might have a distinct advantage, being available through the Windows Store.  A typical corporate PC lock-down policy might not restrict installation from the Windows Store (such apps being pre-vetted, signed, and therefore “safe”) but might prevent installation of Cygwin, since Cygwin is third-party and doesn’t normally install on a per-user basis.

You're assuming LSW will become pre-installed on these workstations and UoW will become a Windows Store "app". I'm not saying it can't happen, but it seems unlikely at the moment.

> (Indeed, iperf3 doesn’t build OOTB on Cygwin due to an API conflict with newlib, a problem that doesn’t impact glibc based systems like UfW.)

Although practically speaking, Linux is more comfortable because people primarily target Linux, it'd be better to push for programs to be truly POSIX-portable instead of furthering the Linux near-monopoly.

> 6. A lot of Unix software runs like a pig under Cygwin due to the user-space gyrations Cygwin must go through to implement POSIX semantics under Windows.

Midipix could end up taking the place of the top competitor of LSW/UoW performance-wise, while retaining interoperability with Win32.

> 8. All of us who greatly prefer installing software via a command line package manager (e.g. apt, pkg, brew, yum…) rather than a GUI (e.g. setup.exe) will probably be happier under UfW than on Cygwin.

This is fixable. MSYS2 already has pacman which can do the same. (Thanks to Cygwin developers, among others.)

> 9. A lot of software for Linux simply isn’t portable enough to build under Cygwin, and there is no native Windows port.  Such software may do low-level unportable things, include assembly language hacks, etc. that don’t 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 Oracle JVM (as opposed to Cygwin’s current JVM alternative, gcc-gcj), Valgrind, etc.)

This is definitely a win for LSW/UoW, because it goes for Linux compatibility.

-- 
David Macek

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3834 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://cygwin.com/pipermail/cygwin/attachments/20160421/a7513d38/attachment.p7s>