FW: An irritated cygwin newbie

["Suhaib M. Siddiqi" <ssiddiqi@inspirepharm.com>]

Speaking of GGI Documentation???
I had been fighting to get GGI and XGGI work properly
on Win32.  I could not.  Finally I tried the same stuff
on linux:
for example ./XGGI -targets glide&
should have XGGI Glide server up?  Right?  I could not find
a proper documentation... and as John wrotes
the GGI documentation is a real big mess... it will refer you
to another stuff and you get into head and tail game of never finding
where the head is and where the tail was.

As far Cygwin Documentation is concerned, I really do not know if it good,
bad
or worst.  All I can say if you know how to use Unices then you
would hardly nead any documentation for Cygwin.

Suhaib

John,
Sorry for Cc'ing to list.  I guess you are still unable to post directly.



>
> GGI has been ported to Cygwin.  All it needs at this point is a working
> DirectX (ddraw and dinput) display target, which I am currently working
> on.
>
> In terms of the GGI documentation, the internals portion of it basically
> sucks.  It basically implies, read the other display code ( which may be
> quite different ) and take your best shot.  The few FAQs are for the
> most part,
>
> from libggi-hackers.txt
> ...
>   [This article is NOT a substitute for not looking at the existing
>   display target code. This section does not explain every detail.]...
>
> However, the code itself it not all that easy to read at first glance.
>
> I guess the point here is not to start a flame war about the relative
> 'cleanliness' of the projects, but to point out that every project has
> its own flaws.
>
> Regards,
> John Fortin
>
> "Jon M. Taylor" wrote:
> >
> > On Wed, 18 Aug 1999, Chris Faylor wrote:
> >
> > > 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.
> >
> >         Oh.  That explains a lot.
> >
> > > 2) The actual Win32 group at Cygnus has gone from three engineers
> > >    to one engineer since B20.1.
> >
> >         That also explains a lot.  Why do you not ask for help
> in big bright
> > red letters (well, you know what I mean) on the web page, then?  How are
> > people supposed to know you _need_ help?  I've passed up Cygwin
> several times
> > when looking around for a needy open-source projects to spend some time
> > helping, because the FAQ and web pages make it look like a
> large core team is
> > already present.
> >
> >         I have relevant work experience, too - I worked at NEC
> for a while
> > last year on a project which was creating a system API
> emulation tool which
> > was quite similar to Cygwin.  We were porting a non-POSIX API for an old
> > proprietary Japanese-market Unix (UX4800) to HP-UX.  It was backwards
> > from Cygwin (porting non-POSIX to POSIX), but most of core API bridging
> > issues should be quite similar....
> >
> > > 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.
> >
> >         Probably not.  Cygwin is too big.  But I do not
> understand what the
> > problem is with the binary distributions.  Is there lack of suitable
> > hardware or something?
> >
> > > 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.
> >
> >         Don't misunderstand me.  I do not expect everything to
> work golden.
> > I have been doing open-source coding for too many years now to
> expect that,
> > especially from a project as huge and intricate as Cygwin.  What I _do_
> > expect is that the basic documentation (FAQs, install
> instructions, feature
> > lists) is more or less up to date and factually correct.  I
> believe that such
> > things are more important to get right first than a few extra
> features or
> > even bugfixes.
> >
> >         The GGI project went through a phase a few years ago
> when our FAQs
> > were horribly out of date, our web pages were not getting
> updated, release
> > schedules were erratic, and informal third-party patches and
> workarounds were
> > the order of the day.  And the result of all this mess was that
> we started
> > seeing messages on our mailing list much like the one I wrote
> that started
> > this thread - people who had wasted lots of time and endured massive
> > frustration due to the mess.  It took an outsider who really wanted to
> > use LibGGI but could not deal with the chaos to speak up on the mailing
> > list to wake us up.
> >
> >         I see this project heading down the same path, and I
> wanted to say
> > something about it.  One observation that was made to the GGI
> people back in
> > the "dark days" that I think should be burned into the forheads of every
> > open-source project manager is this: open source projects live
> and die by
> > their ability to attract and hold the interest of skilled
> coders, and first
> > impressions count for a lot in this regard.  Some people will
> instantly latch
> > on to your particular project because it is exactly what they
> want to code,
> > but more often you see people who are good coders and want to
> do "something
> > cool".  These folks will be put off by chaos, and will wander
> off to end up
> > contributing lots of coding hours to another project whose
> barriers to entry
> > are not so painful to get around.
> >
> >         GGI lost a lot of skilled coders during our "dark days"
> because they
> > could not deal with the chaos.  The difference in overall project health
> > since we cleaned up our act has been nothing short of stunning.
>  But what it
> > took was all of us "core coders" putting our pet coding
> projects down and
> > focusing on a massive spring cleaning.  The web pages got
> overhauled, the FAQ
> > was rewritten, manpages were updated, build systems and
> directory structures
> > and the configuration system were overhauled, everything that could be
> > automated was, and a comprehensive overview of all outstanding
> bugs was drawn
> > up and the bugs were methodically squashed.  We also chose to
> be far more
> > rigorous about defining alpha/beta/release cycles and sticking to them.
> >
> >         I won't lie.  It *really* sucked to have to put our noses to the
> > grindstone like that and spend an extended period of time doing boring,
> > trivial gruntwork.  But boy was it worth it in the end, and now
> that we are
> > used to it, it isn't nearly so bad.  I just want to strongly
> encourage the
> > Cygwin team to consider holding their own spring cleaning.  I
> would be more
> > than willing to lend a hand.  I cannot promise to become a core
> developer -
> > GGI is still my first priority right now.  However, I can fix
> bugs and work
> > on boring crap like webpages, mailing lists, FAQs build systems
> and whatnot,
> > which is really what needs to be done.
> >
> >         But I will not volunteer my time for this unless I see a clear
> > commitment from the people in charge that A) my ideas will be
> listened to
> > with an open mind, B) I will get help from other "core coders"
> on cleanup
> > work that is deemed by group consensus to be needed, and C) a concerted
> > effort will be made to stabilize the current CVS tree and get a
> solid b21 out
> > the door (pulling stuff that is too unstable to fix reasonable
> quickly from
> > CVS if necessary).  If people will agree to this, I will be
> happy to help
> > out.
> >
> > >    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).
> >
> >         You just received another one.
> >
> > > 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.
> >
> >         As long as the core rendering functionality can call
> out directly to
> > the DirectX DLLs, which appears to be possible, the overhead of
> the Cygwin
> > API calls should not be too bad.  A graphics API such as LibGGI
> is, by its
> > nature (speed is everything) designed to structure execution flow along
> > clearly defined code paths and to minimize system API calls at
> all times,
> > regardless of the particulars of the native environment.  LibGGI is
> > already ported to ~25 very different rendering targets and many
> different
> > versions of Unix.  We have been dealing with this issue for some time
> > now.
> >
> >         This is not to say that (for example) a slow select()
> wouldn't have a
> > major impact on LibGGI performance.  But at least we'd be able
> to clearly see
> > the potential optimization hotspots, both in LibGGI and in
> Cygwin, and that
> > never hurts.  And the nice thing about Cygwin is that, if some
> or all of the
> > LibGGI code turns out to just plain require a native port, only
> those parts
> > need be ported and the rest can be left alone.  And even if I
> should end up
> > with a 100% native win32 port for some reason, Cygwin will have been a
> > valuable stepping-stone on the way there.  I have many reasons
> to want to use
> > Cygwin, but LibGGI is far too complex a system to port unless I
> can get a
> > clear sense of what works and what doesn't.
> >
> > > 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.
> >
> >         You have as much time as you devote to any other aspect
> of Cygwin.
> > It is up to you how you choose to make use of that time.  The
> same goes for
> > everyone else in the Cygwin core team.  Every time you sit down
> to a pleasant
> > little hack-session on your pet codebase, think long and hard
> about whether
> > what you are are doing is *really* more important than fixing bugs or
> > updating a portion of the FAQ.
> >
> > > Maybe if I stopped reading this mailing list, that would help
> a little...
> >
> >         I think that would be the exact opposite of what you
> should do.  All
> > the whining on the list (even my posts |->) shows you where the
> weak spots
> > are.  If you are finding yourself growing annoyed by people
> repeating the
> > same questions over and over again, that should be a rather
> large red flag to
> > you that longstanding problems are not being addressed.  I have
> an informal
> > personal policy of not letting a problem report come up more
> than three times
> > on the GGI mailing list before I try to fix it (if it is in my area of
> > responsibility) or bother the person whose area of responsibility it is.
> >
> >         If the problem cannot be fixed, either it is
> fundamental, in which
> > case a meeting of the minds between developers is _required_ to
> straighten
> > things out, or it must be fixed but cannot be immediately in
> which case we
> > fix everything about it than can be fixed, clearly define and
> document the
> > rest, and set a schedule/milestone/plan/whatever for fixing it.
>  My point is
> > that, whatever is done, it is done consistently and major
> developers who do
> > not cooperate in keeping their corner of the project clean in
> this manner get
> > taken to task for it.
> >
> >         Linux is a successful open-source project primarily
> because Linus
> > enforces QA standards and alpha/beta schedules.  To the extent
> that he has
> > not in the past, problems have always cropped up.  The v2.0 fiasco is a
> > shining example of this, and we all learned from that
> unpleasant experience.
> > That is why Linus is trying to get 2.4 out the door by the end
> of this year.
> > As the major truly outstanding example of how to do software engineering
> > (with binary releases, even, though done by others) in a very large and
> > complex open-source development project, Cygwin could certainly
> do worse than
> > to emulate Linus' methodology.
> >
> >         Sorry for the rather pedantic and lecturing tone of
> this mail (I just
> > reread what I wrote), but I have seen this exact same problem
> do a lot of
> > damage to a lot of open-source projects over the years and I
> really would
> > hate to see it happen to Cygwin (any more than the mailing list
> shows that it
> > already HAS happened).  Cygwin is a wonderful concept and I can
> see that a
> > lot of very talented coders hang out here, but all the coding
> talent in the
> > world doesn't help if people can't use the results in a
> reasonably stable,
> > cohesive system.  I have to be honest about the problem areas
> that I see.
> > Take what I say however you wish to.
> >
> > Jon
> >
> > ---
> > 'Cloning and the reprogramming of DNA is the first serious step in
> > becoming one with God.'
> >         - Scientist G. Richard Seed
> >
> > --
> > Want to unsubscribe from this list?
> > Send a message to cygwin-unsubscribe@sourceware.cygnus.com
>


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