Cygwin instabilities

Cygwin instabilities

[Al]

Hello,

I run Cygwin on a double core machine with Vista. I estimate that 1 of
20 of my compilations break and need to be repeated. One weak point is
the compression of man pages.

Others report that they don't use Cygwin because of instablilities,
especially in the server context.

What are the reasons? Will this be better with Windows 7? Can Cygwin
become "server stable"?

Al

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin instabilities

[Larry Hall (Cygwin)]

On 9/13/2010 9:19 AM, Al wrote:
> Hello,
>
> I run Cygwin on a double core machine with Vista. I estimate that 1 of
> 20 of my compilations break and need to be repeated. One weak point is
> the compression of man pages.
>
> Others report that they don't use Cygwin because of instablilities,
> especially in the server context.
>
> What are the reasons? Will this be better with Windows 7? Can Cygwin
> become "server stable"?

You'll need to be more specific about the issues you're encountering
and your configuration.  See <http://cygwin.com/problems.html>.

-- 
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
216 Dalton Rd.                          (508) 893-9889 - FAX
Holliston, MA 01746

_____________________________________________________________________

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin instabilities

[Al]

Hello Larry,

>> What are the reasons? Will this be better with Windows 7? Can Cygwin
>> become "server stable"?
>
> You'll need to be more specific about the issues you're encountering
> and your configuration.  See <http://cygwin.com/problems.html>.

I am not asking this to debug my own setup. I am rather ask for an
overall estimation of Cygwins current and future usability and
stability.

I am currently working on an OS product that depends on Cygwin as
POSIX layer. I would like to estimate the chances it will have, to be
usefull for many people.

It not, how to tweak Cygwin to run on some machines. It's, how big is
the percentage of windows machines, that will run a stable Cygwin with
the standard setup.exe setup.

Al

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin instabilities

[Markus Hoenicka]

Al <oss.elmar@googlemail.com> was heard to say:

> I am not asking this to debug my own setup. I am rather ask for an
> overall estimation of Cygwins current and future usability and
> stability.
>

These two things are related. Remember that Cygwin is an open source  
project, and that it does not employ dozens of developers with the  
abstract task of increasing usability or stability. Both are increased  
by either debugging or at least properly reporting bugs. If you  
experience stability problems on your setup, then reporting this in  
all necessary detail is a sure step to increase future usability and  
stability.

> It not, how to tweak Cygwin to run on some machines. It's, how big is
> the percentage of windows machines, that will run a stable Cygwin with
> the standard setup.exe setup.

Who would keep counters of stable or instable setups? These number are  
exceptionally hard to come by. Even if this list is now flooded with  
"my setup works" and "mine too" posts, these numbers would not be  
representative. Users may have given up on Cygwin due to instabilities  
without notifying the list. Others may run Cygwin so happily they  
never think about joining the list. All you could do is to scan the  
Cygwin archives for "instabilities" (this is your term and arguably  
far too unspecific) and compare it to the number of instabilities  
reported for any run-of-the mill Linux in the same timeframe.

Just my 2cc

Markus

P.S. mine works

-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin instabilities

[mike marchywka]

On 9/13/10, Markus Hoenicka <markus.hoenicka xxx.duh> wrote:
> Al <oss.elmar@xxx.xxx> was heard to say:
>
>> I am not asking this to debug my own setup. I am rather ask for an
>> overall estimation of Cygwins current and future usability and
>> stability.
>>
>
> These two things are related. Remember that Cygwin is an open source
> project, and that it does not employ dozens of developers with the
> abstract task of increasing usability or stability. Both are increased
> by either debugging or at least properly reporting bugs. If you
> experience stability problems on your setup, then reporting this in
> all necessary detail is a sure step to increase future usability and
> stability.
>
>> It not, how to tweak Cygwin to run on some machines. It's, how big is
>> the percentage of windows machines, that will run a stable Cygwin with
>> the standard setup.exe setup.
>
> Who would keep counters of stable or instable setups? These number are
> exceptionally hard to come by. Even if this list is now flooded with
> "my setup works" and "mine too" posts, these numbers would not be
> representative. Users may have given up on Cygwin due to instabilities
> without notifying the list. Others may run Cygwin so happily they
> never think about joining the list. All you could do is to scan the
> Cygwin archives for "instabilities" (this is your term and arguably
> far too unspecific) and compare it to the number of instabilities
> reported for any run-of-the mill Linux in the same timeframe.

I would mention in response to earlier question that I'm quite happy with cygwin
on 'doze 7. I routinely build and test mobile phone apps here as well
as miscellaneous script based downloads and everything seems fine.
The performance issues I reported are fine compared to any 'doze alternatives
and so far most of what I have developed under cygwin runs under real linux.
And it is a good way to learn linux too LOL.

btw, is is possible to do something like the new iproute2 stuff in dohs?




>
> Just my 2cc
>
> Markus
>
> P.S. mine works
>

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin instabilities

[Al]

> These two things are related. Remember that Cygwin is an open source

Sure it is related, but that doesn't answer my question.

> Who would keep counters of stable or instable setups? These number are
> exceptionally hard to come by. Even if this list is now flooded with "my
> setup works" and "mine too" posts, these numbers would not be

No that is not the way to go. I think there are people which run
Cygwin on more than 1 machine, so they have a personal estimation and
experience.

> representative. Users may have given up on Cygwin due to instabilities
> without notifying the list. Others may run Cygwin so happily they never

Right. Similar I can't report the bugs for people telling me, they
don't use Cygwin, because of stability issues they encountered in the
past.

Al

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin instabilities

[Larry Hall (Cygwin)]

On 9/13/2010 11:57 AM, Al wrote:
>> These two things are related. Remember that Cygwin is an open source
>
> Sure it is related, but that doesn't answer my question.
>
>> Who would keep counters of stable or instable setups? These number are
>> exceptionally hard to come by. Even if this list is now flooded with "my
>> setup works" and "mine too" posts, these numbers would not be
>
> No that is not the way to go. I think there are people which run
> Cygwin on more than 1 machine, so they have a personal estimation and
> experience.
>
>> representative. Users may have given up on Cygwin due to instabilities
>> without notifying the list. Others may run Cygwin so happily they never
>
> Right. Similar I can't report the bugs for people telling me, they
> don't use Cygwin, because of stability issues they encountered in the
> past.

OK.  Well without any specifics about a particular issue and/or point in
time, there's really no way for anyone on this list to respond to this
type of query.  If someone finds something, the best way to handle the
problem is to report it here following the guidelines of
<http://cygwin.com/problems.html>.

-- 
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
216 Dalton Rd.                          (508) 893-9889 - FAX
Holliston, MA 01746

_____________________________________________________________________

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin instabilities

[Markus Hoenicka]

Al <oss.elmar@googlemail.com> was heard to say:

> No that is not the way to go. I think there are people which run
> Cygwin on more than 1 machine, so they have a personal estimation and
> experience.
>

Yes, and this is where the Cygwin archives come in handy. If there are  
users running Cygwin on lots of machines, they are likely to run into  
problems once in a while, and they're likely to use the list for  
reporting these problems. If Cygwin was as instable as you apparently  
suspect, you'd find plenty of reports in the archives. I haven't  
noticed any such large-scale reports about instabilities in several  
years of lurking on this list, but your thorough perusal of the  
archives may well prove me wrong.

regards,
Markus


-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin instabilities

[Christopher Faylor]

On Mon, Sep 13, 2010 at 05:57:08PM +0200, Al wrote:
>>These two things are related.  Remember that Cygwin is an open source
>
>Sure it is related, but that doesn't answer my question.
>
>>Who would keep counters of stable or instable setups?  These number are
>>exceptionally hard to come by.  Even if this list is now flooded with
>>"my setup works" and "mine too" posts, these numbers would not be
>
>No that is not the way to go.  I think there are people which run
>Cygwin on more than 1 machine, so they have a personal estimation and
>experience.
>
>>representative.  Users may have given up on Cygwin due to instabilities
>>without notifying the list.  Others may run Cygwin so happily they
>>never
>
>Right.  Similar I can't report the bugs for people telling me, they
>don't use Cygwin, because of stability issues they encountered in the
>past.

You seem to be approaching this problem as if people will say "Ah!
Stability issues! Right.  Well, ok, here's what you need to know."

If we knew of stability issues they would be fixed.  Don't assume that
since some nebulous person or persons couldn't get some version of
Cygwin running it means that there are well-known problems that we will
all clamor to proclaim.

If you think that asking a group of strangers for help with a nebulously
defined "instability" is really going to get you any useful responses
then you must not be well-acquainted with open source.

As a project lead, here's my advice: If you are concerned that Cygwin is
unstable then buy support from Red Hat.  Then you have a guaranteed
recourse if something doesn't work.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin instabilities

[Al]

> You seem to be approaching this problem as if people will say "Ah!
> Stability issues! Right.  Well, ok, here's what you need to know."
>

It's not me thinking in the bug -> solution pattern here. I don't ask
for a solution.

>
> If you think that asking a group of strangers for help with a nebulously
> defined "instability" is really going to get you any useful responses
> then you must not be well-acquainted with open source.
>

I ask for an estimation. I ask people that work intensively with
Cygwin, to have a second opinion. Then I can compare it to the
non-cygwin-advocates. So please don't take it the wrong way. I don't
want to start a flame. Would be the wrong place anyway. :-)

> As a project lead, here's my advice: If you are concerned that Cygwin is
> unstable then buy support from Red Hat.  Then you have a guaranteed
> recourse if something doesn't work.

If I would sell closed source product, instead of devolping an OS one.

... but than I could advice the customer to buy the Interix layer instead.

Al

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin instabilities

[Ramiro Polla]

On Mon, Sep 13, 2010 at 10:19 AM, Al <oss.elmar@googlemail.com> wrote:
> Others report that they don't use Cygwin because of instablilities,
> especially in the server context.

I've also been having "instabilities" in my "server context" (Windows
Server 2008 R2), but I have a few more concrete details:

I had 1.7.5 installed, and built gcc-3.4.6, gcc-4.2.4, and gcc-4.4.4
to use on a continuous integration test box. All went relatively fine.
I updated to 1.7.7 and kept using the toolchains built with 1.7.5. I
got that some of the build cycles would hang in "make" (in gcc.exe or
tr.exe actually) with "Bad address". The process would still appear in
pstree with a * and I had to "/usr/bin/kill -W" it. Since it seemed to
happen randomly, it wasn't easily reproducible, so I don't how or what
exactly to debug. Is there any way to try and trap that error? I could
also try to log everything with strace but I'm afraid that would
produce tons of data (the builds could run for hours before such error
occurred).

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin instabilities

[Dave Korn]

[-- Attachment #1: Type: text/plain, Size: 942 bytes --]

On 13/09/2010 17:35, Christopher Faylor wrote:

> You seem to be approaching this problem as if people will say "Ah!
> Stability issues! Right.  Well, ok, here's what you need to know."
> 
> If we knew of stability issues they would be fixed.

  Well, I know of one, but haven't had time to fix it yet, so I keep this hack
in my local builds.  Can't run "make check -jN" without it, but even then it
sometimes locks up.

  The problem I've run into is that on a heavily loaded system, a pinfo struct
can get truncated into a redirector in between the time a syscall checks the
process_state (using ISSTATE or NOTSTATE) and the time it subsequently
attempts to access a pinfo member which it hoped to guard by that check.

  I have a bad feeling that the only way to totally resolve this is going to
be adding lots of locking or mutexing around pinfo calls, which is almost
bound to have performance implications :-(

    cheers,
      DaveK


[-- Attachment #2: pinfo-fix.diff --]
[-- Type: text/x-c, Size: 1100 bytes --]

--- src.clean/winsup/cygwin/pinfo.h	2010-09-01 22:06:36.000000000 +0100
+++ src/winsup/cygwin/pinfo.h	2010-09-06 20:36:17.062500000 +0100
@@ -51,8 +51,6 @@ public:
 
   DWORD exitcode;	/* set when process exits */
 
-#define PINFO_REDIR_SIZE ((char *) &myself.procinfo->exitcode - (char *) myself.procinfo)
-
   /* > 0 if started by a cygwin process */
   DWORD cygstarted;
 
@@ -64,9 +62,6 @@ public:
     signals.  */
   DWORD dwProcessId;
 
-  /* Used to spawn a child for fork(), among other things. */
-  WCHAR progname[NT_MAX_PATH];
-
   /* User information.
      The information is derived from the GetUserName system call,
      with the name looked up in /etc/passwd and assigned a default value
@@ -121,6 +116,12 @@ public:
   HANDLE wr_proc_pipe;
   DWORD wr_proc_pipe_owner;
   friend class pinfo;
+
+  /* Used to spawn a child for fork(), among other things. */
+  WCHAR progname[NT_MAX_PATH];
+  /* Truncate it after execed process exits. */
+#define PINFO_REDIR_SIZE ((char *) &myself.procinfo->progname[0] - (char *) myself.procinfo)
+
 };
 
 DWORD WINAPI commune_process (void *);


[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin instabilities

[Christopher Faylor]

On Mon, Sep 13, 2010 at 03:52:55PM -0300, Ramiro Polla wrote:
>On Mon, Sep 13, 2010 at 10:19 AM, Al <oss.elmar@googlemail.com> wrote:
>> Others report that they don't use Cygwin because of instablilities,
>> especially in the server context.
>
>I've also been having "instabilities" in my "server context" (Windows
>Server 2008 R2), but I have a few more concrete details:

Ok.  Two reports of "instabilities".  And what does that show?

Here are the OP's original questions:

What are the reasons?

Dave theorized about one.

Will this be better with Windows 7?

No.

Can Cygwin become "server stable"?

It depends on what is meant by "become".  If it means will there be a concerted
effort to "harden" Cygwin for a server then the answer is likely "not unless
someone pays for it."

That points back to paying Red Hat for support.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin instabilities

[Christopher Faylor]

On Mon, Sep 13, 2010 at 08:34:42PM +0100, Dave Korn wrote:
>On 13/09/2010 17:35, Christopher Faylor wrote:
>
>> You seem to be approaching this problem as if people will say "Ah!
>> Stability issues! Right.  Well, ok, here's what you need to know."
>> 
>> If we knew of stability issues they would be fixed.
>
>  Well, I know of one, but haven't had time to fix it yet, so I keep this hack
>in my local builds.  Can't run "make check -jN" without it, but even then it
>sometimes locks up.
>
>  The problem I've run into is that on a heavily loaded system, a pinfo struct
>can get truncated into a redirector in between the time a syscall checks the
>process_state (using ISSTATE or NOTSTATE) and the time it subsequently
>attempts to access a pinfo member which it hoped to guard by that check.
>
>  I have a bad feeling that the only way to totally resolve this is going to
>be adding lots of locking or mutexing around pinfo calls, which is almost
>bound to have performance implications :-(

You've included a patch here but, FYI, I have no idea why.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin instabilities

[Tim Prince]

  On 9/13/2010 12:34 PM, Dave Korn wrote:
Even when I submit make check-c make check-fortran and make check-c++ in 
separate windows, occasionally an instance of expect will hang and fail 
to time out, so has to be killed to complete the check.  More often than 
not, it's possible to complete the whole 3 day series without such a 
hang.  Anyway, it's not specific to -jN.

-- 
Tim Prince


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin instabilities

[Dave Korn]

On 13/09/2010 20:23, Christopher Faylor wrote:
> You've included a patch here but, FYI, I have no idea why.

  FTR only.  It might be useful to others following the list.

    cheers,
      DaveK


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin instabilities

[Al]

> It depends on what is meant by "become".  If it means will there be a concerted
> effort to "harden" Cygwin for a server then the answer is likely "not unless
> someone pays for it."
>
> That points back to paying Red Hat for support.

I think you use the term support in the wrong field. It is the enduser
who buys support, not the developers.

Also the enduser doesn't buy support to make a product more stable.
It's works the other way. A stable product is choosen by more
endusers, which in return buy more support. So it's Red Hat, who has
to invest into stability of Cygwin to make it as succesfull as
possible.

If they don't see a challange in this, than Cygwin is in a kind of
cul-de-sac with Red Hat I guess.

Al

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin instabilities

[Christopher Faylor]

On Mon, Sep 13, 2010 at 09:48:49PM +0200, Al wrote:
>> It depends on what is meant by "become". ?If it means will there be a concerted
>> effort to "harden" Cygwin for a server then the answer is likely "not unless
>> someone pays for it."
>>
>> That points back to paying Red Hat for support.
>
>I think you use the term support in the wrong field. It is the enduser
>who buys support, not the developers.

Can't really parse that, especially given that I'm a developer and you're
obviously not.

>Also the enduser doesn't buy support to make a product more stable.

My supposition was that you would purchase the product from Red Hat, run
it, report problems, and, gradually, have Red Hat improve "stability".
However, you could also purchase a contract with Red Hat with the goal
of improving "server stability".  I guess the latter is not strictly
a "support" contract but I don't see why there has to be minute hair
splitting here.

>It's works the other way. A stable product is choosen by more
>endusers, which in return buy more support. So it's Red Hat, who has
>to invest into stability of Cygwin to make it as succesfull as
>possible.
>
>If they don't see a challange in this, than Cygwin is in a kind of
>cul-de-sac with Red Hat I guess.

Red Hat puts as much money into the product as needed to make a profit.
If they are satisfied with their customer base then they have no
incentive to do anything to Cygwin.

If *you* want to use Cygwin and you have a specific requirement that is
not going to be met by the meandering ways of an open source project
then you have two options:  1) work on improving the product yourself
or 2) pay someone to do it for you.  In the Cygwin scenario, the most
likely place to find someone to do it for you is Red Hat.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin instabilities

[Al]

>
> Can't really parse that, especially given that I'm a developer and you're
> obviously not.
>

lol

Al

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin instabilities

[Al]

>
> Can't really parse that, especially given that I'm a developer and you're
> obviously not.
>

lol

Al

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin instabilities

[Al]

>
> You'll need to be more specific about the issues you're encountering
> and your configuration.  See <http://cygwin.com/problems.html>.
>

The majority of instabilities I observerved while compressing manpages
with  bzip2 -9, a minority during execessiv link operations. Some
others I can't relate to something.

Since I have compiled bzip2 from the Gentoo sources, I haven't seen
any instablilities from this side any more, but a also was more
conservative and didn't do parallel builds.

Al

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin instabilities

[Reini Urban]

2010/9/13 Al wanted stability stories:
> I run Cygwin on a double core machine with Vista. I estimate that 1 of
> 20 of my compilations break and need to be repeated. One weak point is
> the compression of man pages.

I routinely run my perl compiler smokes on cygwin and linux machines.
This involves automatic updates, failures which cause core dumps,
100%CPU or eating all available memory.

cygwin (better Windows) is more stable than linux in this regard.
I should really tune my ulimits on my linux but out of the box my linux
box becomes unusable at certain tests. With cygwin not.
Cygwin is just about 3x slower, and processes keep locking certain
files. Why not.

> Others report that they don't use Cygwin because of instablilities,
> especially in the server context.

Okay. While I'm running my nightly destructive smokes I also serve
content for various projects. My linux laptop started with issues
(heat or SW?) during night
while people were up- and downloading via sftp, so I fell back to my cygwin
box, and since then I kept running this cygwin server instead. Much
more stable than my
linux box so far. Of course that's most likely a HW issue, but cygwin
was stable enough and better.

For example I run vlc sessions (publicly broadcasting football games
from brazil here
in my town) with the cygwin perl testing sessions and cygwin stfp
uploading in the background,
and linux is not really as fast and stable in vlc client response as I
with my windows box.

> What are the reasons? Will this be better with Windows 7? Can Cygwin
> become "server stable"?

Windows 7 was not better for me. More system DLL's and footprint, much
more rebase problems.
Sometimes I can only stop MSIE and MS Outlook to continue to work in
my mintty shells.

"Server stable" in ISP terms of course not. It's still just Windows,
with all its known weaknesses.
But ISP's are still selling and using windows servers.
-- 
Reini Urban
http://phpwiki.org/           http://murbreak.at/

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin instabilities

[Al]

>> What are the reasons? Will this be better with Windows 7? Can Cygwin
>> become "server stable"?
>
> Windows 7 was not better for me. More system DLL's and footprint, much
> more rebase problems.
> Sometimes I can only stop MSIE and MS Outlook to continue to work in
> my mintty shells.

:-( I always thought Vista was the ugly prototype and Windows 7 would
become the lean new system, that brings back the fun. No, that brings
the fun. There was never much fun in Windows, although I personally
like the mere surface of Vista.

>
> "Server stable" in ISP terms of course not. It's still just Windows,
> with all its known weaknesses.
> But ISP's are still selling and using windows servers.

Yes, in terms of ISP. It's not the Desktop users complaints. As a
developer I can react immediatly, if something goes wrong. The admins
can't.

http://en.gentoo-wiki.com/wiki/Prefix/Cygwin

I have done much progress with the evaluation of the Prefix
bootstrapping process meanwhile. That was 4 weeks work to solve all
issues.

In a few days I will put that all into one big script. Then I will
see, if the whole process will go through over night or where
instabilities will occur. In that case I will be able to report more
details of instabilities.

Al

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple