Re: native Linux userland in Windows 10

[David Macek <david dot macek dot 0 at gmail dot com>]

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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature