An irritated cygwin newbie

[Chris Faylor]

I don't have much to say about this but there are a few of points:

1) Cygnus doesn't directly fund Cygwin development as an open source
   project.  Cygwin was developed here to allow building of our GNUpro
   toolset.  Much of the work done on the project is volunteered by
   two people.

2) The actual Win32 group at Cygnus has gone from three engineers
   to one engineer since B20.1.

3) AFAIK, EGCS provides only sources for *you* to compile.  Cygwin provides
   binaries which are installed via InstallShield.  It's a minor matter,
   but I'd be happy to release B21 as a source-code only distribution.
   It would simplify things greatly.  I doubt that that would be acceptable
   to many people.

4) EGCS has a lot of high quality contributors.  Cygwin has (not counting
   DJ or me) two or three.  Most of the users of Cygwin are people like
   you -- they want tools and they want them good and hard.  There are
   probably scores of suggestions every week for how the project could
   be improved.  There are very few offers to volunteer to help (although
   I have recently received a few offers of help for which I am *very*
   grateful).

5) Given that Cygwin is an emulation layer I can't imagine why you would
   consider porting GGI using it.  There will be inavoidable slowdowns
   which I would think would be unacceptable given the nature of what
   it is doing.

I am grateful that you took the time to outline the problems that you
see with the project.  I wish we had more time to devote to getting a
release out.

Maybe if I stopped reading this mailing list, that would help a little...

cgf

On Tue, Aug 17, 1999 at 10:26:10PM -0700, Jon M. Taylor wrote:
>	I am a member of the GGI project (www.ggi-project.org).  Our
>standard-bearer is LibGGI, a dynamic library based cross-platform graphics
>and event library and API system.  I want to port LibGGI to win32/DirectX,
>so naturally I thought that cygwin would be a great help to me.  I now
>have serious doubts about that, and am planning to fall back to a native
>port.  Although a native port will require a lot more work in the 
>short-term, I do not feel comfortable relying heavily on cygwin anymore.  
>Why?  Read on....
>
>	Around four hours ago I downloaded the latest "stable" (ha!)
>release, b20.1.  I was a bit nervous about using such an old release, but
>I didn't want to play with snapshots on a project as huge and complex as
>cygwin.  So, I downloaded full.exe and installed it.  I then downloaded
>autoconf, automake and libtool, I figured that, since cygwin comes with
>GNU M4 and /bin/sh all nicely set up, there couldn't be any problems. 
>Yeah right.  I had been bitten by the "/bin/sh is ash" bug.  No info about
>this in the FAQ.  After searching the mailing list for every keyword I
>could think of (the list archives at www.cygnus.com are quite broken BTW),
>I finally found out:
>
>* /bin/sh.exe is actually ash, which is not POSIX-compliant.  The weird 
>errors I was seeing when I tried to run .configure were ash improperly 
>quoting strings. Copying bash.exe to /bin/sh.exe fixed all my problems.
>
>* This problem has been know about since a few weeks after b20.1 was 
>released, which was last December.  Nobody has fixed it, released a new 
>cygwin with /bin/sh symlinked to bash.exe, or even updated the FAQ.  ash 
>was apparently used 'because it is faster than bash' (direct quote from 
>the mailing list).  As if speed could ever be justifiably be a higher 
>priority than formal correctness on a system API emulator??....
>
>* b20.1 has been know to be badly broken in a lot of places for quite some
>time now, so much so that people appear to be forced to either stay with
>b19 or use the bleeding-edge snapshots in order to get anything to work
>properly.  Again, this is not mentioned anywhere on sourceware.cygnus.com
>or the FAQ.  Patches and workarounds for the problems with b20.1 are
>piling up, with no release date for a b21 in sight.  People are routinely
>advised to fix their problems with b20.1 by downloading CVS snapshots. 
>
>	This is not the way to do things, folks.  If a supposedly-stable
>release goes out the door and a nontrivial bug is discovered (and IMHO the
>sh-is-really-ash thing qualifies), you fix the bugs _first_ before going
>off and starting a bunch of major new changes in CVS, leaving people with
>no choice other than to stick with a quite old release (b19) or be forced
>to use bleeding-edge CVS snapshots.  I find it odd that b20.1 was released
>specifically to fix bugs in b20 (released two months previously), but then
>we get a period of _nine_ months now where many serious bugs with b20.1
>have been reported, and yet there is no b20.2 available and b21 looks like
>being released later rather than sooner.
>
>	"Beta" implies, if not the formal software-engineering definition
>of "only bug fixes, no new features" (few projects stick to that
>rigorously), at least that bug-fixes and stability in general take
>priority over new features.  That certainly does not appear to be the case
>right now with cygwin, the 'b' on the releases notwithstanding.  I've seen
>many alpha releases from many open-source projects which are far more
>stable than the supposed beta release of b20.  In fact, it is quite
>obvious that the alpha development period of cygwin is far from over. 
>
>	I am surprised to see the software engineering process of a
>commercially-funded open source project of this size and complexity in
>such disarray, all the moreso since the EGCS people are also funded by
>Cygnus and the stablity, regularity and timeliness of their snapshots and
>stable releases have always been outstanding.  I had thought that I would
>also find this level of quality in the cygwin project, but it appears that
>I was mistaken.
>
>	I ported LibGGI to a GNU emulation environment on the __AMIGA__
>that was *considerably* less of a hassle to get set up and running than
>cygwin was!  That's not a good sign.  I strongly urge those in change of
>this project to put whatever they are working on on the shelf for a while
>and focus on cleaning up all the ratty loose ends of this project before
>it all unravels on them.  I will be putting my LibGGI win32 port on the
>shelf as well, until I see a new "stable" release of cygwin that is
>verified stable by lots of users over an extended period of time.  If 
>this does not happen soon, I may have to bite the bullet and do a native 
>port |-<.
>
>
>Disappointed as all hell,
>Jon Taylor

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com