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
smime.p7s
Description: S/MIME Cryptographic Signature
