Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Message-ID: <3B3D0D46.1D76DC53@etr-usa.com>
Date: Fri, 29 Jun 2001 17:20:38 -0600
From: Warren Young <warren AT etr-usa DOT com>
Organization: -ENOENT
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: "shouted down", "shot down", apologies
References: <20010627205132 DOT C26445 AT redhat DOT com> <002d01c0ffa4$5ecd82e0$b3020a0a AT SRST20> <20010628102241 DOT D30710 AT redhat DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Christopher Faylor wrote:
> 
> I used gcc and gdb as examples.  I could easily have used things like:
> "bttv", "ssh", or "zsh".
> 
> I follow, to some degree, the discussions in those projects.  There are
> few complaints about how hard it is to check things out using cvs or
> build the tools.

To pick one of your examples, probably the reason there are more
questions about Cygwin than about zsh is that zsh users are mostly
experienced in the Unix way already, and they're building and using it
on a system that is stable and (largely) bug-free.  Also, the zsh
community is mostly saturated: it isn't going to grow at a rate much
faster than that of the world's population.

With Cygwin, a lot of people are being thrust into the Unix Advernture
game for the first time, and have found that there are a lot of grues
lurking about in the dark corners.  By Cygwin's very nature, the Cygwin
community will always be full of people finding mismatches at the
interface between two different worlds.

Until recently, it wasn't even clear what the overall design philosophy
of Cygwin was going to be.  Consider the whole //d/path/on/drive/d vs
/cygpath/d/ vs d:/path issue.  I seem to recall that back in the
b{18-21} days, the first two options didn't even exist.  The installer
didn't use the mount points feature, if it existed at all -- I used to
install directly into c:\ (e.g. c:\usr\bin for the binaries, c:\bin for
critical things like sh.exe, etc.) so that I could use 4NT for my shell
and still use Unix-like paths.  As time went on, we got setup.exe, which
put Cygwin off in its own directory and set up mount points that only
worked when using a Unix shell.  Cygwin made this and other 
distinctions about the world of Cygwin vs the Windows world, while still
trying to maintain two-way compatibility.

I don't intend to try and decide whether this is bad or good, just to
show that Cygwin's design is still evolving, and the location of the
boundary between Unix and Windows is still getting tweaked to and fro. 
Just like Linux's policy of changing internal kernel interfaces on a
whim to improve the overall design, Cygwin's evolving design sometimes
causes problems.  But the system always improves through this process.

Until the day several eons hence when the design freezes and the user
community expands to its saturation point and the bugs are all (mostly)
worked out, there will always be people getting cut on the bleeding
edge.  This is expected.  We'll need some good docs to help these poor
newbies get accultured.

-- 
= Warren -- Video articles: http://www.cyberport.com/~tangent/video/
= 
= ICBM Address: 36.8274040 N, 108.0204086 W, alt. 1714m

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/