This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]