Mail Archives: cygwin/2001/06/29/19:27:34
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/
- Raw text -