[ANNOUNCEMENT] [1.7] Updated [security]: bash-3.2.49-23

[Warren Young]

Edward Lam wrote:
>>
>> No, they just aren't as mean as we are.  We like to make things
>> purposely slow because then people suffer.
> 
> I asked what I thought was a sensible question for someone who doesn't 
> know the internal workings of cygwin/mingw. It wasn't meant as a flame 
> bait. 

Flame?  Oh, my no.  That was just a light warming in a little butter and 
garlic.  (Ah, grilled newbie, yum.)  Flaming is not subtle here.  Like 
in many online fora, it's best to try to maintain a thick skin here, so 
as to be less easily upset.

Cygwin is slow because there is a huge amount of code in it to try and 
provide POSIX.1 interfaces and semantics on top of the Win32 API, so 
that programs assuming a POSIX environment can just be recompiled to run 
on Windows.[1]  MinGW provides so few packages because they're only 
trying to port the build tools, which are portable, not depending on 
POSIX.  That rules out a huge number of packages that would be 
impractical to port directly to Windows.

[1] That's the ideal, anyway.  It even happens quite a lot these days, 
probably even most of the time.

[2] There's still a lot of work that goes into MinGW to handle various 
Windowsisms.  They're not just recompiling GCC for Windows over there.

P.S. sidefx.com, eh?  I found the Houdini demo interesting, but not 
enough so that I'm going to set aside C4D and modo.

--
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