In my testing, yes. I just generalized his patch so that it could be used when starting any thread rather than just the specific thread that he found. jojelino finds some interesting stuff but his implementation often leaves something to be desired.
When bash takes that long to parse a.bashrc it's usually because you have the bash_completion package installed. That takes a long time under Cygwin. It would take a long time under msys too.
And, of course, the "translation system" is just cygwin + hacks.
Now that they are dropping Win9x support, they can use NT kernel system calls to implement fork(), rather than the high-level Win32 calls. This might be a bit better.
It should be no surprise that most of the comments in this thread are rehashes of 12+ years of history of "Why don't they just do...?"
We'll happily accept a patch which implements fork using low-level NT semantics since all of our efforts in finding the right sequence of calls to make this work have proved to be for naught.
Re:I wonder if Cygwin really has much of a future
on
Cygwin 1.7 Released
·
· Score: 1
We "stopped at 95%" because we were supporting Window 9x. Once we stopped doing that we could make use of the features available in more sophisticated versions of Windows.
But, of course, there are some things that are just very hard to do in Windows no matter what version. That's why some things are not implemented.
you just package Cygwin DLLs with your binaries, and that's it. Then the user another app with a different version of the cygwin dll (or installs cygwin on thier system) and due to the way cygwin uses shared memory to emulate posix stuff things tend to start crashing when two versions of the dll are loaded at once.
The new 1.7.1 version of Cygwin allows multiple versions of Cygwin to coexist.
I'm one of the cygwin project leads. I wanted to point out that adding packages to cygwin is pretty easy. You just have to package up.tar.bz2 source and binary files, a "hint' file, and send a proposal to the cygwin-apps mailing list.
So, if you're interested in adding new packages to the cygwin release -- you have the power.
I found out about this thread rather late and had little to add, especially since *I* don't run cygwin in production. I did clarify another point in the discussion, however.
Of course I want to defend cygwin against charges like "fork is poorly implemented". I don't know why I have to explain this but if someone blindly criticizes something you contributed to without offering any supporting details, you don't just let the criticism sit. We're happy to hear about improvements to fork assuming that they aren't the same-old suggestions that have been showing up in the cygwin mailing list for the last five years. Vague criticisms could well leave a reader with an incorrect impression of something that has received a lot of attention from cygwin developers over the years.
I also thought it was useful for people to know that the other issues were just normal problems that you would find moving between two different versions of *nix. Often people spend time on linux, move to cygwin, have problems, and think "Aha! I've found cygwin incompatibilities."
What I was trying to make clear is that you would have similar incompatibilities moving to HP/UX or Tru64 or even another version of linux. You can't expect that if you built a program using Red Hat Linux 7.3 it will run without problems on Red Hat Linux 9. You could well have issues with the fact that there are different versions of bash or because there are different shared libraries available.
I do apologize for using the term "common sense" since it is an implied slight indicating that if someone makes a point they lack common sense. Obviously issues involved in porting to other platforms are not obvious and deserved to be discussed. Cygwin does have some unique issues not common to linux (like filename case sensitivity, tcp/ip issues, permission problems) but most of the issues listed were not cygwin-specific.
Finally, it might be a good idea to ask this question in the cygwin mailing list. You won't reach as wide an audience as here but you will hit many people who have spent a lot of time on issues like cygwin reliability in a production environment.
I don't have to troll. I am one of the project leaders for cygwin. I understand the issues very well. Most of the problems you describe are just generic problems with porting to another system. Perhaps you have little experience porting between systems and are unaware of this.
Cygwin's fork is certainly slower than UNIX's fork, but since you lack any understanding of Cygwin fork internals, your assertion that it is badly implemented is uninformed. I thought people should know that.
>Versions of the applications you run: they often differs from what you're used to. Sometimes I ended up with different settings between solaris, linux, win32, etc.
This is pretty much common sense. If you are using a different version of program X on platform Y, you may run into trouble. Well, duh.
>Forks and threads are really badly implemented. Yet nobody else did better.
Odd how you would make such a strong statement with no apparent understanding of how "fork and threads" could be implemented better.
"threads" are just Windows threads. It's hard to see how they could be implemented as anything else.
>No compatibility: NEVER trust that if it will work with nunux, it will work with cygwin,
It's generally true that you should never trust that something will run just because you happened to get it working on some *NIX variant. This is true of HP/UX, Ultrix, SunOS, and Cygwin.
>The DLL hell here is that you'll probably not only need the cygwin dll but some more...
Yeah, cygwin apps rely on shared libraries, just like linux/*nix apps do. So, if you build your program to use a shared library, guess what? You have to make sure that the shared library exists on the platform that you're going to run the program on. Again, this is common sense. What seems to be tripping you up is the fact that you can't expect cygwin to be installed on every Windows system but you do stand a good chance of the shared library you want being installed on another linux system.
So, this basically sets up a cross compiler? And, that's a big deal?
I've been generating cygwin releases from linux for years. I can't believe that this rates as news in any way.
If it does, then the crossgcc mailing list at sources.redhat.com is probably worth checking out. There you can be amazed by the fact that many many people are using cross compilers on a daily basis.
Basically, if you don't want to GPL your programs, you have to pay for the privilege. The $$$ from sales of proprietary cygwin licenses are used, to some degree, to fund Cygwin development at Red Hat.
> You can download the huge current tree in standard gzipped tar format, but be warned: it's about a megabyte right now.
I don't know where you found this. It's very incorrect. The full installation is several hundred megabytes.
I've been running the cygwin project for several years. Cygwin was originally developed by Cygnus, as others have noted. However, the current development is almost entirely a spare time type of thing. Red Hat does not fund ongoing cygwin development. It is basically just a tolerated technology within Red Hat. It is obviously not a core focus.
All of the work that I and any other Red Hat employee have put into cygwin has come from after hours activities. It's funny because Cygwin is arguably one of Red Hat's most successful free software enterprises but 1) Red Hat barely acknowledges it and 2) Nobody seems to notice that it is actively being run by an individual (me) who contributes time outside of the normal work time. This is no different from most other free software projects, of course, but granting Red Hat credit with doing anything other than hosting the web site would be incorrect. If you're reading the cygwin mailing list, you probably know this but when was the last time you saw a SlashDot interview with the head of the Cygwin project? People probably think that's Matthew Szulik or something. Everyone assumes that Red Hat corporate is somehow responsible, which is pretty funny.
There are people inside of Red Hat and external to Red Hat who contribute to the Cygwin project.
There is no more "Cygnus". Cygnus was absorbed by Red Hat last year.
Cygnus did not write gcc. I believe that was RMS. Red Hat/Cygnus does contribute a lot to the gcc and gdb projects but they did not write these programs and do not own these programs.
Cygwin was written by Cygnus employees (hence the name) but, like any successful free software endeavor, it's grown far from its humble beginnings.
The GNU project does not maintain the cygwin documentation. Cygwin developers do that. Cygwin is not an FSF project. That's why it isn't called gnu-win32 anymore.
The FSF is supposedly going to sell a CD based on Cygwin and DJGPP but this is a derivative work based on a Cygwin net release.
Bug reports and "it seems to me..." ideas do not contribute as much to the project as actual contributions of code, documentation updates, FAQ updates, web page maintenance, or even answering questions in the cygwin mailing list.
Attaboys of any type are welcome... Well, the "I love Cygwin, but..." attaboys are not quite as exhilarating as the ones without the "but", I guess.
Slashdot Mirror
In my testing, yes. I just generalized his patch so that it could be used when starting any thread rather than just the specific thread that he found.
jojelino finds some interesting stuff but his implementation often leaves something to be desired.
When bash takes that long to parse a .bashrc it's usually because you have the bash_completion package installed. That takes a long time under
Cygwin. It would take a long time under msys too.
And, of course, the "translation system" is just cygwin + hacks.
You're misinterpreting the email. An equivalent patch was added. It just wasn't done in the manner proposed by the original author.
Now that they are dropping Win9x support, they can use NT kernel system calls to implement fork(), rather than the high-level Win32 calls. This might be a bit better.
It should be no surprise that most of the comments in this thread are rehashes of 12+ years of history of "Why don't they just do ...?"
We'll happily accept a patch which implements fork using low-level NT semantics since all of our efforts in finding the right sequence of calls to make this work have proved to be for naught.
We "stopped at 95%" because we were supporting Window 9x. Once we stopped doing that we could make use of the features available in more sophisticated versions of Windows.
But, of course, there are some things that are just very hard to do in Windows no matter what version. That's why some things are not implemented.
you just package Cygwin DLLs with your binaries, and that's it.
Then the user another app with a different version of the cygwin dll (or installs cygwin on thier system) and due to the way cygwin uses shared memory to emulate posix stuff things tend to start crashing when two versions of the dll are loaded at once.
The new 1.7.1 version of Cygwin allows multiple versions of Cygwin to coexist.
Here's the link to the cygwin donations page.
I'm one of the cygwin project leads. I wanted to point out that adding packages to cygwin is pretty easy. You just have to package up .tar.bz2 source and binary files, a "hint' file, and send a proposal to the cygwin-apps mailing list.
So, if you're interested in adding new packages to the cygwin release -- you have the power.
I found out about this thread rather late and had little to add, especially since *I* don't run cygwin in production. I did clarify another point in the discussion, however.
Of course I want to defend cygwin against charges like "fork is poorly implemented". I don't know why I have to explain this but if someone blindly criticizes something you contributed to without offering any supporting details, you don't just let the criticism sit. We're happy to hear about improvements to fork assuming that they aren't the same-old suggestions that have been showing up in the cygwin mailing list for the last five years. Vague criticisms could well leave a reader with an incorrect impression of something that has received a lot of attention from cygwin developers over the years.
I also thought it was useful for people to know that the other issues were just normal problems that you would find moving between two different versions of *nix. Often people spend time on linux, move to cygwin, have problems, and think "Aha! I've found cygwin incompatibilities."
What I was trying to make clear is that you would have similar incompatibilities moving to HP/UX or Tru64 or even another version of linux. You can't expect that if you built a program using Red Hat Linux 7.3 it will run without problems on Red Hat Linux 9. You could well have issues with the fact that there are different versions of bash or because there are different shared libraries available.
I do apologize for using the term "common sense" since it is an implied slight indicating that if someone makes a point they lack common sense. Obviously issues involved in porting to other platforms are not obvious and deserved to be discussed. Cygwin does have some unique issues not common to linux (like filename case sensitivity, tcp/ip issues, permission problems) but most of the issues listed were not cygwin-specific.
Finally, it might be a good idea to ask this question in the cygwin mailing list. You won't reach as wide an audience as here but you will hit many people who have spent a lot of time on issues like cygwin reliability in a production environment.
"trolling" == "making salient points"
I don't have to troll. I am one of the project leaders for cygwin. I understand the issues very well. Most of the problems you describe are just generic problems with porting to another system. Perhaps you have little experience porting between systems and are unaware of this.
Cygwin's fork is certainly slower than UNIX's fork, but since you lack any understanding of Cygwin fork internals, your assertion that it is badly implemented is uninformed. I thought people should know that.
>Versions of the applications you run: they often differs from what you're used to. Sometimes I ended up with different settings between solaris, linux, win32, etc.
This is pretty much common sense. If you are using a different version of program X on platform Y, you may run into trouble. Well, duh.
>Forks and threads are really badly implemented. Yet nobody else did better.
Odd how you would make such a strong statement with no apparent understanding of how "fork and threads" could be implemented better.
"threads" are just Windows threads. It's hard to see how they could be implemented as anything else.
>No compatibility: NEVER trust that if it will work with nunux, it will work with cygwin,
It's generally true that you should never trust that something will run just because you happened to get it working on some *NIX variant. This is true of HP/UX, Ultrix, SunOS, and Cygwin.
>The DLL hell here is that you'll probably not only need the cygwin dll but some more...
Yeah, cygwin apps rely on shared libraries, just like linux/*nix apps do. So, if you build your program to use a shared library, guess what? You have to make sure that the shared library exists on the platform that you're going to run the program on. Again, this is common sense. What seems to be tripping you up is the fact that you can't expect cygwin to be installed on every Windows system but you do stand a good chance of the shared library you want being installed on another linux system.
But we'll certainly appreciate the donation of a hyperthreaded machine...
Msys is just an older version of cygwin with some additions that purportedly make it easier to use with mingw.
The last time I checked, msys was slower than cygwin.
So, this basically sets up a cross compiler?
And, that's a big deal?
I've been generating cygwin releases from linux for
years. I can't believe that this rates as news in
any way.
If it does, then the crossgcc mailing list at sources.redhat.com is probably worth checking out. There you can be amazed by the fact that many many people are using cross compilers on a daily basis.
Basically, if you don't want to GPL your programs, you have to pay for the privilege. The $$$ from sales of proprietary cygwin licenses are used, to some degree, to fund Cygwin development at Red Hat.
Yep, duh. This was a reference to the perl utilities not cygwin itself.
Sorry about that.
> You can download the huge current tree in standard gzipped tar format, but be warned: it's about a megabyte right now .
I don't know where you found this. It's very incorrect. The full installation is several hundred megabytes.
I've been running the cygwin project for several years. Cygwin was originally developed by Cygnus, as others have noted. However, the current development is almost entirely a spare time type of thing. Red Hat does not fund ongoing cygwin development. It is basically just a tolerated technology within Red Hat. It is obviously not a core focus.
All of the work that I and any other Red Hat employee have put into cygwin has come from after hours activities. It's funny because Cygwin is arguably one of Red Hat's most successful free software enterprises but 1) Red Hat barely acknowledges it and 2) Nobody seems to notice that it is actively being run by an individual (me) who contributes time outside of the normal work time. This is no different from most other free software projects, of course, but granting Red Hat credit with doing anything other than hosting the web site would be incorrect. If you're reading the cygwin mailing list, you probably know this but when was the last time you saw a SlashDot interview with the head of the Cygwin project? People probably think that's Matthew Szulik or something. Everyone assumes that Red Hat corporate is somehow responsible, which is pretty funny.
I read the title.
The minimum cygwin installation contains "ls". If you truly installed the standard cygwin minimal installation, you will get "ls".
However, if you don't set your path to find it you won't be able to run it.
If you are talking about some other installation method where you actually chose not to install "ls" well, then "duh".
Real UNIX savvy are we? Set your PATH environment variable to include the cygwin bin directory.
cgf
Of course there are "cygwin people".
There are people inside of Red Hat and external to Red Hat who contribute to the Cygwin project.
There is no more "Cygnus". Cygnus was absorbed by Red Hat last year.
Cygnus did not write gcc. I believe that was RMS. Red Hat/Cygnus does contribute a lot to the gcc and gdb projects but they did not write these programs and do not own these programs.
Cygwin was written by Cygnus employees (hence the name) but, like any successful free software endeavor, it's grown far from its humble beginnings.
% cat > hello.c
#include
main (int argc, char **argv)
{
printf ("hello world\n");
}
% gcc -o hello.exe -O2 hello.c
% ls -l hello.exe
-rwxr-xr-x 1 cgf None 18919 Aug 15 21:17 hello.exe
% strip hello.exe
% ls -l hello.exe
-rwxr-xr-x 1 cgf None 3072 Aug 15 21:18 hello.exe
% # obviously someone is on some powerful
% # hallucinogens
A few points:
The GNU project does not maintain the cygwin documentation. Cygwin developers do that. Cygwin is not an FSF project. That's why it isn't called gnu-win32 anymore.
The FSF is supposedly going to sell a CD based on Cygwin and DJGPP but this is a derivative work based on a Cygwin net release.
Bug reports and "it seems to me..." ideas do not contribute as much to the project as actual contributions of code, documentation updates, FAQ updates, web page maintenance, or even answering questions in the cygwin mailing list.
Attaboys of any type are welcome... Well, the "I love Cygwin, but..." attaboys are not quite as exhilarating as the ones without the "but", I guess.
"assumptions about the file system". Hmm. I wonder what that means and why it would stop you from compiling simple stuff on Cygwin.
Yes, Cygwin is owned and developed by Red Hat.
Red Hat does sell GNUpro tools for Windows, so there is at least some interest in Windows as a platform.