On 10/15/2016 12:23 AM, L. A. Walsh wrote:



Daniel Colascione wrote:
One such case is Cygwin --- I'm not sure how "contrived" it is. Cygwin
has an old-fashioned non-COW fork, and to add insult to injury,
process creation generally is very slow (~100ms). It pays to eliminate
subshells in that environment.
Given what Cygwin has to work around in Windows -- it is very contrived.

Maybe the internals. From the perspective of programs like bash, Cygwin is a mostly ordinary POSIX environment, one with lots of users and that deserves full support.

MS has copy-on-write available to MS processes, that it's not usable in
Cygwin isn't surprising given that most of Windows is closed-source.

It has nothing to do with being closed source and everything to do with the win32 subsystem (under which Cygwin runs) not being designed to cope with process duplication.


But if you really want bash on your windows, use a native copy.  It's
not as likely to have the same problems
(https://techcrunch.com/2016/03/30/be-very-afraid-hell-has-frozen-over-bash-is-coming-to-windows-10/)


It doesn't do the same thing. Cygwin is an integrated POSIXish environment.


Apparently there is a Windows Subsystem for Linux that is currently in Beta
for Win10:
http://www.howtogeek.com/265900/everything-you-can-do-with-windows-10s-new-bash-shell/


SFU and similar do not interact with the win32 subsystem as closely as Cygwin and so can't provide the same experience. IMHO, you might as well run a VM.

Reply via email to