When will cygwin ever be stable?

When will cygwin ever be stable?

[Andy Piper]

Don't get me wrong - I love cygwin and think Chris and co have done a 
marvellous jobs, but as a user who simply wants cygwin to work well I have 
never installed a version that actually has all the signifcant bugs 
squashed. Each time I install, something might be fixed but something else 
breaks. For instance C-c - using C-c in cygwin is completely fundamental to 
its usability and yet it has been fairly broken in the last two versions I 
have installed (1.1.8-2 and 1.3.1); the headers change the whole time so 
that trying to maintain anything that builds under cygwin is a complete 
nightmare. I could go on, but the point is that all of these features have 
worked at one time or other, but there doesn't seem to ever be a release 
that squashes them all. Am I hoping in vain?

Yours frustratedly,

andy


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: When will cygwin ever be stable?

[Christopher Dale Campbell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I can't speak for the developers, but IMHO, it's an on-going process.
 Nothing is bug free and while there are small problems here or
there, most (if not all) are being taken care of very nicely.  As was
stated in an earlier e-mail, most of the developers are voluntary. 
It's come a long way, and again IMHO, I think it's constantly being
improved.  Try to find another unix environment (for Windows, that
is) that is as stable, or open sourced as Cygwin.  I dare ya.  ;)


- ----- Original Message ----- 
From: "Andy Piper" <andyp@bea.com>
To: <cygwin@cygwin.com>
Sent: Monday, April 30, 2001 2:02 PM
Subject: When will cygwin ever be stable?


> Don't get me wrong - I love cygwin and think Chris and co have done
> a  marvellous jobs, but as a user who simply wants cygwin to work
> well I have  never installed a version that actually has all the
> signifcant bugs  squashed. Each time I install, something might be
> fixed but something else  breaks. For instance C-c - using C-c in
> cygwin is completely fundamental to  its usability and yet it has
> been fairly broken in the last two versions I  have installed
> (1.1.8-2 and 1.3.1); the headers change the whole time so  that
> trying to maintain anything that builds under cygwin is a complete 
> nightmare. I could go on, but the point is that all of these
> features have  worked at one time or other, but there doesn't seem
> to ever be a release  that squashes them all. Am I hoping in vain?
> 
> Yours frustratedly,
> 
> andy
> 
> 
> --
> Want to unsubscribe from this list?
> Check out: http://cygwin.com/ml/#unsubscribe-simple
> 

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use < http://www.pgp.com >

iQA/AwUBOu29GYXnWfGgRqP+EQID9gCfSxB5bptLNOqkRRcXR0pjbXOuo+EAoLFv
MuXHRamu938ZKtKf0jI1c7PJ
=Erk4
-----END PGP SIGNATURE-----



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: When will cygwin ever be stable?

[Christopher Faylor]

On Mon, Apr 30, 2001 at 11:02:00AM -0700, Andy Piper wrote:
>Don't get me wrong - I love cygwin and think Chris and co have done a
>marvellous jobs, but as a user who simply wants cygwin to work well I
>have never installed a version that actually has all the signifcant
>bugs squashed.  Each time I install, something might be fixed but
>something else breaks.  For instance C-c - using C-c in cygwin is
>completely fundamental to its usability and yet it has been fairly
>broken in the last two versions I have installed (1.1.8-2 and 1.3.1);

What does "fairly broken" mean?  I'm aware of only one problem which I
announced a fix for a couple of days ago.

>the headers change the whole time so that trying to maintain anything
>that builds under cygwin is a complete nightmare.

What does "the headers change the whole time" mean?  What specifically
caused you problems?  Was it the move of headers to /usr/include/w32api?

FWIW, the 1.3.1 release of Cygwin was a major release.  That's one of
the reasons that we incremented the middle number.  We expected
problems.  There are problems.  We'll be making a 1.3.2 release soon.

Whether it fixes your problems or not is unknown at this point since I
have no clear idea what your problems are.  Without specific feedback we
can't fix specific problems, so your specific problems are not
specifically fixed.  Perhaps you might want to try a snapshot.

cgf

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: When will cygwin ever be stable?

[Charles S. Wilson]

Andy Piper wrote:
> 
> Don't get me wrong - I love cygwin and think Chris and co have done a
> marvellous jobs, but as a user who simply wants cygwin to work well I have
> never installed a version that actually has all the signifcant bugs
> squashed. 

This is true.  I've had the same experience with the Linux kernel
2.2.10, 2.2.13, 2.2.14, 2.2.16, and 2.2.18.  And don't get me started on
2.4.0-testX, 2.4.0, 2.4.1, 2.4.2, ...

> Each time I install, something might be fixed but something else
> breaks. For instance C-c - using C-c in cygwin is completely fundamental to
> its usability and yet it has been fairly broken in the last two versions I
> have installed (1.1.8-2 and 1.3.1);

You are unfortunately correct about the ^C issue.  However, (and this is
the really strange thing) it got fixed in the snapshots *prior* to 1.3.1
IIRC, but then broke AGAIN at 1.3.1...but is NOW fixed (again) in the
snapshots.  I think.  :-P

> the headers change the whole time so
> that trying to maintain anything that builds under cygwin is a complete
> nightmare.

(I harp on building non-cygwin apps with cygwin extensively; the reason
for that is made clear several paragraphs down):

Well, no.  What has gone through a lot of *disruptive* changes recently
is not the cygwin kernel itself (although the kernel has changed
substantially, those changes have not been, by and large, disruptive). 
Cygwin's gcc has changed a lot, and the "w32api" headers have changed --
that has caused havoc with building non-cygwin (e.g. -mno-cygwin) apps. 
If you want to build "pure" cygwin apps, it's been pretty stable (I know
-- I maintain a LOT of the application packages for cygwin).  However,
if you try to build something that's pure windows (no cygwin1.dll
reliance) then -- yeah -- it's been hell recently.

Part of that is because (a) mingw, upon which a lot of the pure windows
support is derived, had a period of roughness there for a while, (b) the
w32api was practically unmaintained for a year or more; we've been
sync'ing up with the "good" version over the last several months and the
mingw folks are really picking up steam, (c) in an attempt to make the
separation between pure-cygwin headers and pure-windows headers, stuff
has moved around [this had ripple effects out to gcc and binutils,
things are still shaking out now], and FINALLY, (d) the -mno-win32 /
-mwin32 default change to gcc is still causing a ripple effect [IMO, the
fact that THAT change is causing problems is indicative of poorly or
incompletely ported apps, but...]

Another part of the problem is w.r.t -mno-cygwin is, well, the NO-CYGWIN
part.  There's enough to do adding features and fixing bugs just in
cygwin and its associated packages (70 or 80 at last count) for the 10
or so developers and package maintainers.  The reason for keeping the
NO-CYGWIN part of the cygwin toolchain working is just that a lot of
people use it -- but since extremely few of those people (none?), who
use cygwin as a toolchain for non-cygwin apps, actually contribute to
the cygwin project itself,

well,

that makes maintaining the NO-CYGWIN part of the cygwin toolchain
completely altruistic.  And altruism, coupled with constant complaints
without assistance, eventually wears thin.  Right now, if it weren't for
the fact that cygwin's setup.exe (and certain other parts of the cygwin
kernel itself) requires the NO-CYGWIN stuff to work -- if it weren't for
that, I think the developers of cygwin would drop NO-CYGWIN support
completely in a New York minute, and tell everybody who wanted it to
install mingw.

> I could go on, but the point is that all of these features have
> worked at one time or other, but there doesn't seem to ever be a release
> that squashes them all. Am I hoping in vain?

Short term pain for long term gain?  Maybe?  We hope?  8-j  (sometimes
it DOES seem like squeezing a balloon or playing whack-a-mole, doesn't
it...)

Anyway, Andy, I know that you recently adapted cygwin's setup (e.g.
"cinstall") for use by XEmacs.  Since setup is a pure-windows app, it
got hit by the gcc/specfile/headers-moving-around problems -- and even
some w32api changes.  You may want to take a look at this patch:

http://www.cygwin.com/ml/cygwin-patches/2001-q2/msg00114.html

which was necessary to keep *cygwin's* version of setup.exe working...

--Chuck

P.S. I know you mean to be *contructively* critical of cygwin, and that
you've been a loyal cygwin'er far longer than most of the rest of us. 
In fact, you're the inspiration behind my usr-local package for cygwin
V1.1
( http://www.neuro.gatech.edu/users/cwilson/cygutils/V1.1/usr-local/ ) --
your usrlocal package for B20 made cygwin really usable.  Of course, my
usr-local for V1.1 has dwindled as I've migrated most of 'my' packages
into the core cygwin dist.  So, all cygwiners owe you a debt of thanks,
and should take comments by a long timer like yourself with a certain
seriousness. 

OTOH, Chris is right -- we can try to fix *specific* complaints, but
"cygwin isn't stable" is a bit too general...

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: When will cygwin ever be stable?

[Christopher Faylor]

On Mon, Apr 30, 2001 at 11:33:03PM -0400, Charles S. Wilson wrote:
>>Each time I install, something might be fixed but something else
>>breaks.  For instance C-c - using C-c in cygwin is completely
>>fundamental to its usability and yet it has been fairly broken in the
>>last two versions I have installed (1.1.8-2 and 1.3.1);
>
>You are unfortunately correct about the ^C issue.  However, (and this
>is the really strange thing) it got fixed in the snapshots *prior* to
>1.3.1 IIRC, but then broke AGAIN at 1.3.1...but is NOW fixed (again) in
>the snapshots.  I think.  :-P

WHAT ^C issue?  What are we talking about?????

The only issue I'm aware of is being unable to stop a cygwin process if
all of its standard input/output has been redirected.  That was fixed
a couple of days ago but it was hardly a new problem.

cgf

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: When will cygwin ever be stable?

[Charles S. Wilson]

Christopher Faylor wrote:
> 
> On Mon, Apr 30, 2001 at 11:33:03PM -0400, Charles S. Wilson wrote:
> >>Each time I install, something might be fixed but something else
> >>breaks.  For instance C-c - using C-c in cygwin is completely
> >>fundamental to its usability and yet it has been fairly broken in the
> >>last two versions I have installed (1.1.8-2 and 1.3.1);
> >
> >You are unfortunately correct about the ^C issue.  However, (and this
> >is the really strange thing) it got fixed in the snapshots *prior* to
> >1.3.1 IIRC, but then broke AGAIN at 1.3.1...but is NOW fixed (again) in
> >the snapshots.  I think.  :-P
> 
> WHAT ^C issue?  What are we talking about?????
> 
> The only issue I'm aware of is being unable to stop a cygwin process if
> all of its standard input/output has been redirected.  That was fixed
> a couple of days ago but it was hardly a new problem.

That's the most recent appearance.  Perhaps I'm misremembering, but I
had thought there were several "signal-handling" things that have
cropped up since January.  CTRL-Z not suspending windows apps, CTRL-C
not able to interrupt a process (regardless of whether its I/O was
redirected), ...

I haven't really paid too much attention to those threads, but that was
my recollection.  I have been known to be wrong, however. 
Occaisionally. :-)

Since Andy is the one who has actually observed the problems with both
1.1.8-2 and 1.3.1, perhaps he could clarify?  Andy? ...

--Chuck

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: When will cygwin ever be stable?

[Christopher Faylor]

On Tue, May 01, 2001 at 12:15:05AM -0400, Charles S. Wilson wrote:
>Christopher Faylor wrote:
>> WHAT ^C issue?  What are we talking about?????
>> 
>> The only issue I'm aware of is being unable to stop a cygwin process if
>> all of its standard input/output has been redirected.  That was fixed
>> a couple of days ago but it was hardly a new problem.
>
>That's the most recent appearance.  Perhaps I'm misremembering, but I
>had thought there were several "signal-handling" things that have
>cropped up since January.  CTRL-Z not suspending windows apps, CTRL-C
>not able to interrupt a process (regardless of whether its I/O was
>redirected), ...

CTRL-Z was an issue.  CTRL-Z is a very special animal as far as signals
go.

CTRL-C was not an issue, AFAIK.

Regardless, the simple fix that was proposed a few days ago only solves
one specific problem.  The problem that was fixed has been in cygwin
for quite a while.

cgf

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: When will cygwin ever be stable?

[Andy Piper]

Chris Faylor writes:
>What does "fairly broken" mean?  I'm aware of only one problem which I
>announced a fix for a couple of days ago.

It means that hitting C-c for anything but simple scenarios does not 
interrupt the target process. My case is running java inside a shell script.

> >the headers change the whole time so that trying to maintain anything
> >that builds under cygwin is a complete nightmare.
>
>What does "the headers change the whole time" mean?  What specifically

It means that each time I install a new version of w32api or the mingw 
one's I have to fix XEmacs compilation in some way or other.

>caused you problems?  Was it the move of headers to /usr/include/w32api?

That didn't help. My problem is not whether this was a good or bad thing to 
do, but rather that it changed again (remember the move to the new headers 
etc?)

>FWIW, the 1.3.1 release of Cygwin was a major release.  That's one of
>the reasons that we incremented the middle number.  We expected
>problems.  There are problems.  We'll be making a 1.3.2 release soon.

So what happened to the stable release in between? Was there a 1.2?

>Whether it fixes your problems or not is unknown at this point since I
>have no clear idea what your problems are.  Without specific feedback we
>can't fix specific problems, so your specific problems are not
>specifically fixed.  Perhaps you might want to try a snapshot.

I don't want to beta-test cygwin - I just want it to work. That's 
fundamentally my issue. I suspect that you disagree with this and I suspect 
that people feel the same way about XEmacs, but its my opinion and I'm 
entitled to it :)

My top 3 bugs:

- C-c habitually breaks (i.e. does nothing)

- cygwin term does not handle scrollbacks properly (this worked once but 
has been broken for ever), do this:
build something to generate lots of output and then hit C-c to interrupt, 
scrollback through the screen buffer by dragging the scrollbar with the 
mouse or using a mousewheel. Then type - the screen buffer will habitually 
not scrollback down to the bottom but instead insert your typing in the 
middle of the output.
[I see from trying to reproduce this reliably that it is somewhat random]

- headers moving and/or changing.

andy


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: When will cygwin ever be stable?

[Louis Bohm]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3381 bytes --]

I do not know about the other points you made but I can tell you that the scroll
bars do work when you are running rxvt.  Maybe you should try that instead.

Louis

Andy Piper wrote:

> Chris Faylor writes:
> >What does "fairly broken" mean?  I'm aware of only one problem which I
> >announced a fix for a couple of days ago.
>
> It means that hitting C-c for anything but simple scenarios does not
> interrupt the target process. My case is running java inside a shell script.
>
> > >the headers change the whole time so that trying to maintain anything
> > >that builds under cygwin is a complete nightmare.
> >
> >What does "the headers change the whole time" mean?  What specifically
>
> It means that each time I install a new version of w32api or the mingw
> one's I have to fix XEmacs compilation in some way or other.
>
> >caused you problems?  Was it the move of headers to /usr/include/w32api?
>
> That didn't help. My problem is not whether this was a good or bad thing to
> do, but rather that it changed again (remember the move to the new headers
> etc?)
>
> >FWIW, the 1.3.1 release of Cygwin was a major release.  That's one of
> >the reasons that we incremented the middle number.  We expected
> >problems.  There are problems.  We'll be making a 1.3.2 release soon.
>
> So what happened to the stable release in between? Was there a 1.2?
>
> >Whether it fixes your problems or not is unknown at this point since I
> >have no clear idea what your problems are.  Without specific feedback we
> >can't fix specific problems, so your specific problems are not
> >specifically fixed.  Perhaps you might want to try a snapshot.
>
> I don't want to beta-test cygwin - I just want it to work. That's
> fundamentally my issue. I suspect that you disagree with this and I suspect
> that people feel the same way about XEmacs, but its my opinion and I'm
> entitled to it :)
>
> My top 3 bugs:
>
> - C-c habitually breaks (i.e. does nothing)
>
> - cygwin term does not handle scrollbacks properly (this worked once but
> has been broken for ever), do this:
> build something to generate lots of output and then hit C-c to interrupt,
> scrollback through the screen buffer by dragging the scrollbar with the
> mouse or using a mousewheel. Then type - the screen buffer will habitually
> not scrollback down to the bottom but instead insert your typing in the
> middle of the output.
> [I see from trying to reproduce this reliably that it is somewhat random]
>
> - headers moving and/or changing.
>
> andy
>
> --
> Want to unsubscribe from this list?
> Check out: http://cygwin.com/ml/#unsubscribe-simple

--
¤¤º°`°º¤ø,¸¸,ø¤º°`°º¤øø¤º°`°º¤ø,¸¸,ø¤º°`°º¤øø¤º°`°º¤
¤°`°Systems  Manager and Tivoli Support Geek
¤°`°Lightbridge, Inc
¤°`°67 South Bedford St.
¤°`°Burlington MA 01832
¤°`°781.359.4795 mailto:lbohm@lightbridge.com
¤°`° http://www.lightbridge.com
¤°`°Free Tivoli scripts at: http://www.microgeek.com
¤¤º°`°º¤ø,¸¸,ø¤º°`°º¤øø¤º°`°º¤ø,¸¸,ø¤º°`°º¤øø¤º°`°º¤



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: When will cygwin ever be stable?

[egor duda]

Hi!

Tuesday, 01 May, 2001 Andy Piper andyp@bea.com wrote:

>>What does "the headers change the whole time" mean?  What specifically

AP> It means that each time I install a new version of w32api or the mingw 
AP> one's I have to fix XEmacs compilation in some way or other.

>>caused you problems?  Was it the move of headers to /usr/include/w32api?

AP> That didn't help. My problem is not whether this was a good or bad thing to 
AP> do, but rather that it changed again (remember the move to the new headers 
AP> etc?)

i wonder if it was my changes to w32api that change _ANONYMOUS_*
semantics? they surely can break applications that include headers
individually without including <windows.h> first. since you didn't
state yet what exactly the problem with headers was, i can only guess.
if some application included individual w32api headers without
<windows.h>, i think it's wrong. i think you understand that api
writer should make some assumptions about how this api will be used
and act accordingly. "always include windows.h" is, i think, quite
logical assumption. and, speaking of this specific change, it was made
to not break programs that do include windows.h

i think you understand that "don't change it in any way" is a bit,
uhm, unrealistic attitude.

i wholeheartedly agree that lots of cygwin users will benefit from
rock-stable cygwin. the main question is "what cygwin team should do
for this?" don't change anything? this won't make things stable.
maintain "stable" and "development" branches? well, perhaps somebody
will be doing this, but the question of "should we merge w32api
changes from devel branch to the stable one, and if we should, then
when?" is still unanswered.

Egor.            mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: When will cygwin ever be stable?

[Earnie Boyd]

egor duda wrote:
> 
> Hi!
> 
> Tuesday, 01 May, 2001 Andy Piper andyp@bea.com wrote:
> 
> >>What does "the headers change the whole time" mean?  What specifically
> 
> AP> It means that each time I install a new version of w32api or the mingw
> AP> one's I have to fix XEmacs compilation in some way or other.
> 
> >>caused you problems?  Was it the move of headers to /usr/include/w32api?
> 
> AP> That didn't help. My problem is not whether this was a good or bad thing to
> AP> do, but rather that it changed again (remember the move to the new headers
> AP> etc?)
> 
> i wonder if it was my changes to w32api that change _ANONYMOUS_*
> semantics? they surely can break applications that include headers
> individually without including <windows.h> first. since you didn't
> state yet what exactly the problem with headers was, i can only guess.
> if some application included individual w32api headers without
> <windows.h>, i think it's wrong. i think you understand that api
> writer should make some assumptions about how this api will be used
> and act accordingly. "always include windows.h" is, i think, quite
> logical assumption. and, speaking of this specific change, it was made
> to not break programs that do include windows.h
> 

Yes, you should always `#include <windows.h>' and never the pieces.  You
can limit some of the pieces from being included by `#define
WIN32_LEAN_AND_MEAN prior to the inclusion of windows.h.

> i think you understand that "don't change it in any way" is a bit,
> uhm, unrealistic attitude.
> 

Definitely.

> i wholeheartedly agree that lots of cygwin users will benefit from
> rock-stable cygwin. the main question is "what cygwin team should do
> for this?" don't change anything? this won't make things stable.
> maintain "stable" and "development" branches? well, perhaps somebody
> will be doing this, but the question of "should we merge w32api
> changes from devel branch to the stable one, and if we should, then
> when?" is still unanswered.
> 

What is "stable"?  What is "development"?  IMO, there is the "released"
branch and the "unreleased" branch and both branches can be under
development.  For Cygwin the released branch maintains no further
development and is frozen in time.  And the unreleased branch at times
may include feature improvements and additions or may be in a state of
"fix the bugs to the extent possible within a given time frame".

Earnie.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: When will cygwin ever be stable?

[Warren Young]

egor duda wrote:
> 
> i wholeheartedly agree that lots of cygwin users will benefit from
> rock-stable cygwin. the main question is "what cygwin team should do
> for this?" 

To answer this it might be helpful to know where Cygwin is going.  I
assume that the overall goal is stepwise refinement towards Linuxness or
similar.  So, how far are we from that goal?
-- 
= Warren -- Video articles: http://www.cyberport.com/~tangent/video/
= 
= ICBM Address: 36.8274040 N, 108.0204086 W, alt. 1714m

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: When will cygwin ever be stable?

[Larry Hall (RFK Partners, Inc)]

At 08:38 AM 5/3/2001, Warren Young wrote:
>egor duda wrote:
> > 
> > i wholeheartedly agree that lots of cygwin users will benefit from
> > rock-stable cygwin. the main question is "what cygwin team should do
> > for this?" 
>
>To answer this it might be helpful to know where Cygwin is going.  I
>assume that the overall goal is stepwise refinement towards Linuxness or
>similar.  So, how far are we from that goal?



Impossible to say, since the stated goal is so broad.  I doubt there will
ever be a day where everything done in Linux will transparently work in 
Cygwin.  But if you want some idea of where things stand, I'd say the best 
indicator is the cygwin-apps list.  This list is for people porting apps to 
Cygwin.  Issues they encounter are the best indication of where Cygwin needs 
to go to support the packages people want to run.  I think the main point to 
focus on here is that Cygwin is still very much a work in progress.  Needed 
functionality is still missing.  Until that changes or the set of "needed
functionality" dwindles to a small enough amount that the vast majority 
don't care about it, I don't think it will be possible to address the needs
of those who want a "rock-stable cygwin" and those who need the additional 
functionality with one branch of the code.  Unfortunately, managing two 
branches isn't likely to happen without a lot more resource.  That additional
resource would need to be able to maintain, release, and provide technical
support for the alternate Cygwin.  Also, coordination with the "development"
branch is required.  Its not a trivial task but it could be done if there were
enough volunteers to undertake this task.



Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: When will cygwin ever be stable?

[Robert Collins]

----- Original Message -----
From: "Warren Young" <warren@etr-usa.com>
To: "egor duda" <cygwin@cygwin.com>
Sent: Thursday, May 03, 2001 10:38 PM
Subject: Re: When will cygwin ever be stable?


> egor duda wrote:
> >
> > i wholeheartedly agree that lots of cygwin users will benefit from
> > rock-stable cygwin. the main question is "what cygwin team should do
> > for this?"
>
> To answer this it might be helpful to know where Cygwin is going.  I

http://www.cygwin.com/faq/faq_1.html#SEC1

Anything that expands the quality (speed/security/flexability/API's
supported) of the cygwin library. That's it. All the software you get is
incidental to cygwin itself. If you mean Cygwin the volunteer run
distribution of open source software linked to the cygwin library, well
I think the closest model we've got for comparison is debian. (In that
the _distribution_ itself is not a business for anyone. ) And at the
moment everyone who's contributing is either being altruistic because
noone else was willing, and they didn't want to see cygwin suffer, or
they are scratching their own itch and helping out because it's trivial
for them (ie Squid and I).

> assume that the overall goal is stepwise refinement towards Linuxness
or
> similar.  So, how far are we from that goal?

Well thats a hard question. linuxness and similar are all moving
targets. How long is a piece of string?

Name a piece of software that runs on linux. If it doesn't run on
cygwin, then document the missing or broken cygwin functions and you can
then point to something thats in the "gap between here and the goal".

Rob


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: When will cygwin ever be stable?

[Christopher Faylor]

On Thu, May 03, 2001 at 11:40:45PM +1000, Robert Collins wrote:
>Well thats a hard question. linuxness and similar are all moving
>targets. How long is a piece of string?

Yeah, I know.  That linux is so unstable.

cgf

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

RE: When will cygwin ever be stable?

[Robert Collins]

You've made my day :]

Rob

> -----Original Message-----
> From: Christopher Faylor [ mailto:cgf@redhat.com ]
> Sent: Friday, May 04, 2001 8:43 AM
> To: egor duda
> Subject: Re: When will cygwin ever be stable?
> 
> 
> On Thu, May 03, 2001 at 11:40:45PM +1000, Robert Collins wrote:
> >Well thats a hard question. linuxness and similar are all moving
> >targets. How long is a piece of string?
> 
> Yeah, I know.  That linux is so unstable.
> 
> cgf
> 
> --
> Want to unsubscribe from this list?
> Check out: http://cygwin.com/ml/#unsubscribe-simple
> 
> 

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: When will cygwin ever be stable?

[Andy Piper]

Louis Bohm wrote:

 > I do not know about the other points you made but I can tell you that 
the scroll
 > bars do work when you are running rxvt.  Maybe you should try that instead.

So let me understand this, in order to get a functional terminal I have to 
use a package that is not even shipped with the standard install? No 
standard user is ever going to do this, they are just going to get hacked 
off with it being broken. A better reason for using rxvt might be because 
its faster.

Maybe everyone in the know uses rxvt and that's why the standard terminal 
is not so great?

andy


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: When will cygwin ever be stable?

[Charles S. Wilson]

Andy Piper wrote:
> 
> Louis Bohm wrote:
> 
>  > I do not know about the other points you made but I can tell you that
> the scroll
>  > bars do work when you are running rxvt.  Maybe you should try that instead.
> 
> So let me understand this, in order to get a functional terminal I have to
> use a package that is not even shipped with the standard install? No
> standard user is ever going to do this, they are just going to get hacked
> off with it being broken. A better reason for using rxvt might be because
> its faster.
> 
> Maybe everyone in the know uses rxvt and that's why the standard terminal
> is not so great?

It was only a suggestion -- not an official recommendation.  Louis was
just trying to solve your problem by offering a solution that worked for
him.  Would you rather he (and everyone else) ignored your problems?

Anyway, 1) a native port of rxvt will soon be in the standard install,
pending a couple of bugfixes, IIRC.  2) I think most people DO use the
standard terminal.  I use an Xport of rxvt with an Xserver; others use
the native rxvt port.  Most poeple probably use "bash in a dosbox" just
like you do.  3) the standard terminal runs inside the @#!!&$@#
dain-bramaged microsoft cmd shell.  Or command shell.  Depending on your
OS.  And cmd.exe and command.com both work differently.  Worse, cmd.exe
works differently on NT and 2K.  C'mon, it's a difficult task: translate
vt100/linux style terminal codes and make them "do the right thing" --
IF POSSIBLE -- inside that trashy MS console window.  Cut us *some*
slack, okay?

--Chuck

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: When will cygwin ever be stable?

[Andy Piper]

At 08:23 PM 5/3/01 -0400, Charles S. Wilson wrote:
>IF POSSIBLE -- inside that trashy MS console window.  Cut us *some*
>slack, okay?

Sorry. I'll go and cool off.

andy


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: When will cygwin ever be stable?

[Andy Piper]

egor duda <deo at logos-m dot ru> wrote:
 > i wonder if it was my changes to w32api that change _ANONYMOUS_*
 > semantics? they surely can break applications that include headers
 > individually without including <windows.h> first. since you didn't

Actually this was the cause of the problem, and it existed because I was 
using code that originated from the cygwin setup - which had the same 
problems. I'm not sure that including individual headers is wrong - but 
there we go.

andy


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: When will cygwin ever be stable?

[Earnie Boyd]

Andy Piper wrote:
> 
> egor duda <deo at logos-m dot ru> wrote:
>  > i wonder if it was my changes to w32api that change _ANONYMOUS_*
>  > semantics? they surely can break applications that include headers
>  > individually without including <windows.h> first. since you didn't
> 
> Actually this was the cause of the problem, and it existed because I was
> using code that originated from the cygwin setup - which had the same
> problems. I'm not sure that including individual headers is wrong - but
> there we go.
> 

According to the w32api maintainer, including individual headers is
wrong.

Earnie.
The w32api maintainer.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple