On Apr 15, 2016, at 4:04 AM, Andrey Repin <anrdae...@yandex.ru> wrote:
>
>> And yet, despite the free
>> availability of top-quality VM technology, Cygwin continues to thrive.
>
> Because interoperability.
So the ability to run native Linux ELF binaries without recompilation on
Windows is not “interoperability”?
>> UfW won’t fill 100% of the use cases of Cygwin from day 1, but for a lot of
>> cases, the two will be interchangeable,
>
> 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
facility in cygwin1.dll or an attempt to bypass the DLL, going straight to the
Windows API under Cygwin, which results in mismatched semantics.
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.
(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.)
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
installing UfW from the Windows app store and then saying “apt install git” is
a “six of one, half a dozen of the other” alternative, as long as you’re only
interested in managing a Windows git tree from the command line.
If you need non-CLI things to work, such as like git gdiff integration with,
say, Beyond Compare, then of course you’d have to use Cygwin git or similar,
such as the MinGW-based “Git for Windows” offering instead of UfW git.
3. You’re using Cygwin merely to give Windows an interactive POSIX userland, so
you have things like grep and sed for operation on Windows filesystem objects.
The same ability to say something like “sed -i -e s/foo/bar $(grep -Rsl foo)”
in Cygwin works just as well under UfW. It works better under UfW, in fact,
since the recursive filesystem search will probably be a lot faster under UfW,
since all file access isn’t going through an in-userspace POSIX translation
layer.
This is what I meant when I described UfW as an apology to Windows users for
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’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; UfW will probably work better, since your
actual deployment environment needs ELF executables, so you can even build
distribution tarballs under UfW, whereas under Cygwin, you’d have to do
cross-compilation, which adds a bunch of complexity. (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 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.
5. Anything where the Ubuntu package repo has software not present in the
Cygwin 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
bandwidth test against a remote system running iperf3, installing UfW so you
can “apt install iperf3” is probably easier than porting iperf3 to Cygwin and
maintaining a private copy.
(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.)
Plus, iperf3 measures I/O overheads, so the lower impedance mismatch between
the UfW ABI and the cygwin1.dll translation layer means the benchmark results
will probably be more accurate under UfW. (i.e. A truer measure of the
system’s network I/O bandwidth.)
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.
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 ports
than under Cygwin.
Another example is anything dealing with many I/O sockets or other file
descriptors, which often use poll() or epoll() on Linux for speed, relative to
select(2). Cygwin doesn’t implement epoll() at all, its poll() implementation
is done in terms of select() (therefore giving no speed advantage at all) and
its select() implementation doesn’t even delegate to the in-kernel Windows
Winsock function select(), but instead reimplements its effect purely in user
space in terms of Windows events, which are limited to 64 per user thread,
purely to get POSIX semantics (e.g. select() on FD, FD passing, etc.) under
Windows, things the Winsock select() implementation doesn’t provide. All of
this makes Cygwin select() much slower than Winsock select(), which in turn is
much slower than more modern interfaces 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’s
handling of threads is a lot better these days than it used to be, but it’s
still not at the level of thread handling under Linux, due to the translation
layer Cygwin needs to supply to convert POSIX threading semantics to Windows
semantics. We saw this on the mailing list not long ago when someone posted a
question about using C++’s native threading libraries under g++ on Cygwin,
where Cygwin did something very odd that it didn’t do on Linux. No one
answered the question, apparently because so few Cygwin users really understand
how Cygwin threads are supposed to work, whereas such software Just Works on
Linux, where the NPTL library and 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 like
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, another piece of
software that’s difficult to port to Cygwin, as I understand it. Whereas “apt
install subversion” is trivial.
7. Running “too-portable” 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 “#ifdef WINDOWS”
conditional code in it, so that it behaves differently when run under Cygwin
than when run under Linux, because its portable code compiles instead of the
POSIX alternative. Thus, a UfW version of the same program may simply behave
more correctly than a naive rebuild of the same source under Cygwin. A true
Cygwin port — where all the #if WINDOWS code is carefully rewritten so the
ifdef path isn’t taken under Cygwin — may simply not be available, whereas a
proper Linux binary build may be available under UfW.
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. “apt install foo” 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’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.)
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 enumerated
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 “English as a second language”
problem here.
(I wouldn’t 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 your
facility with the language is not at the level you wish it to be.)
Let’s define terms:
useless /yōosleəs/ adj. not fulfilling or not expected to achieve the
intended purpose or desired outcome.
Therefore, a thing is only “useless” 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 “useless” is simply incorrect. There is
almost nothing in the world that is purely “useless.”
I’m fine if you want to say UfW is of no use to yourself. I’m objecting to the
concept that because you can’t use it, that no one else can use it either
because it is “useless.”
That is, my objection is to the absolute nature of your statement. If you make
such a statement relative to yourself and I won’t have any argument against the
pronouncement.
> And they will see no issues when moving from this crap to real *NIX system.
There’s much less impedance mismatch between UfW and Linux than between Cygwin
and Linux. Therefore, UfW wins on this front as well.
Is UfW problem-free? Certainly not. But does it have reduced problems
relative to Cygwin? In many cases, yes.
> Always working as root? What could possible go wrong?
That’s a temporary issue, a limitation of UfW’s current beta nature. Microsoft
have publicly stated that they will be reworking it to allow it to run under
your normal user’s permissions and to implement sudo before they release it to
the public.
I’m sure the “everything runs as root” nature of it is for the same reason that
during the bootstrapping process for any OS, you normally do everything as
root. User permission management is one of the last things you port over when
bootstrapping a new OS, once all the tooling is ported over.
--
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
