RE: Cygwin B20 - fseek under gcc fails to reposition on text files

RE: Cygwin B20 - fseek under gcc fails to reposition on text files

[Earnie Boyd]

Ok I appoligize.

Here is the "Microsoft VC++ Run-Time Library Reference" quote:

For streams opened in text mode, fseek has limited use, because
carriage return-linefeed translations can cause fseek to produce
unexpected results.  The only fseek operations guaranteed to work on
streams opened in text mode are:

* Seeking with an offset of 0 relative to any of the origin values.

* Seeking from the beginning of the file with an offset value returned
from a call to ftell.

Also in text mode, CTRL+Z is interpreted as an end-of-file character
on input.  In files opened for reading/writing, fopen and all related
routines check for a CTRL+Z at the end of the file and remove it if
possible.  This is done because using fseek and ftell to move within
an file that ends in CTRL+Z may cause fseek to behave improperly near
the end of the file.

---

Based on the documentation then I'll have to agree that your programs
isn't behaving as the documentation states that it should.  But, which
is wrong, fseek or ftell?

Sorry for speaking out of line,
Earnie.

---Peter Kabal <kabal@ece.mcgill.ca> wrote:
>
> I did.  I quote from Harbison and Steele, Fourth edition, p 353.
> 
> "The following, more limited set of calls is permitted on text streams
> by ISO C:
> 
> fseek (stream, 0L, SEEK_SET)
> fseek (stream, 0L, SEEK_CUR)
> fseek (stream, 0L, SEEK_END)
> fseek (stream, 0L, ftell_pos, SEEK_SET)  at a position returned by a
>     previous call to ftell for stream.
> "
> 
> I <did> read the docs about "text mode processing"!  Your comment was
> unwarranted and warrants an apology.
> 
> > -----Original Message-----
> > From: Earnie Boyd [ mailto:earnie_boyd@yahoo.com ]
> > Sent: February 16, 1999 8:28 AM
> > To: kabal@ece.mcgill.ca
> > Cc: cygwin users
> > Subject: Re: Cygwin B20 - fseek under gcc fails to reposition on
text
> > files
> > 
> > 
> > 
> > You need to read the docs about "text mode processing".  This is
> > exactly the expected behavior.  If you're going to use these
functions
> > then you must process in binary mode.
> > 
> > Regards,
> > Earnie.
> > 
> > ---Peter Kabal <kabal@ECE.McGill.CA> wrote:
> > >
> > > Consider a text file (CR/LF line endings).  Read a line, save the
> > > current position, seek to end-of-file, seek to the saved position,
> > > read a line.  The second read does not return the second line of
> > > the file.
> > > 
> > > A shell script which tests the problem is included below:
> > >
---------------------------------------------------------------------
> > > #!/bin/sh
> > > #
> > > # Test fseek bug
> > > # On Cygwin 20.1, a file is not correctly repositioned after
seeking
> > to the
> > > # end-of-file on a text file (CR/LF line endings).
> > > 
> > > cat > tfrepos.c << EoF
> > > #include <stdio.h>
> > > int main (int argc, char *argv[])
> > > {
> > >   FILE *fp;
> > >   long int pos, size;
> > >   char line[200];
> > >   char *p;
> > > 
> > >   fp = fopen (argv[1], "r");
> > >   p = fgets (line, 200, fp);
> > >   printf (" Line: %s", p);
> > > 
> > >   pos = ftell (fp);
> > >   fseek (fp, 0L, SEEK_END);
> > >   fseek (fp, pos, SEEK_SET);
> > > 
> > >   p = fgets (line, 200, fp);
> > >   printf (" Line: %s", p);
> > > 
> > >   return 0;
> > > }
> > > EoF
> > > 
> > > # Run the test program with the c-program as input
> > > gcc tfrepos.c -o tfrepos
> > > ./tfrepos tfrepos.c
> > > 
> > > # Clean up
> > > rm -f tfrepos tfrepos.c
> > >
---------------------------------------------------------------------
> > > 
> > > Peter Kabal  kabal@ECE.McGill.CA
> > > Dept. Electrical & Computer Eng.
> > > McGill University 
> > > 
> > 
> > _________________________________________________________
> > DO YOU YAHOO!?
> > Get your free @yahoo.com address at http://mail.yahoo.com
> > 
> > 
> 

_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: Cygwin B20 - fseek under gcc fails to reposition on text files

[Christopher Faylor]

On Tue, Feb 16, 1999 at 07:41:34AM -0800, Earnie Boyd wrote:
>
>Ok I appoligize.
>
>Here is the "Microsoft VC++ Run-Time Library Reference" quote:
>
>For streams opened in text mode, fseek has limited use, because
>carriage return-linefeed translations can cause fseek to produce
>unexpected results.  The only fseek operations guaranteed to work on
>streams opened in text mode are:
>
>* Seeking with an offset of 0 relative to any of the origin values.
>
>* Seeking from the beginning of the file with an offset value returned
>from a call to ftell.
>
>Also in text mode, CTRL+Z is interpreted as an end-of-file character
>on input.  In files opened for reading/writing, fopen and all related
>routines check for a CTRL+Z at the end of the file and remove it if
>possible.  This is done because using fseek and ftell to move within
>an file that ends in CTRL+Z may cause fseek to behave improperly near
>the end of the file.
>
>---
>
>Based on the documentation then I'll have to agree that your programs
>isn't behaving as the documentation states that it should.  But, which
>is wrong, fseek or ftell?
>
>Sorry for speaking out of line,

This does sound like a bug.  We'll try to look into this, time permitting.

If anyone else wants to take a stab at this (Corinna?) I'd be very grateful.

-chris

Re: Cygwin B20 - fseek under gcc fails to reposition on text files

[DJ Delorie]

> >* Seeking with an offset of 0 relative to any of the origin values.

This means fseek(file, 0, SEEK_SET) or fseek(file, 0, SEEK_END).

> >* Seeking from the beginning of the file with an offset value returned
> >from a call to ftell.

This allows the library to read() through the file instead of seeking,
to compensage for CR/LF conversions.  If you seek from the end of the
file, these rules do not guarantee success.

The problems are usually in ftell(), since with buffered I/O it's
nearly impossible to determine what actual file position corresponds
to a character in the middle of a stdio buffer.  DJGPP could only
solve this problem by having stdio open *all* files as binary, and
managing the conversion after the buffering.

Re: Cygwin B20 - fseek under gcc fails to reposition on text files

[DJ Delorie]

> >* Seeking with an offset of 0 relative to any of the origin values.

This means fseek(file, 0, SEEK_SET) or fseek(file, 0, SEEK_END).

> >* Seeking from the beginning of the file with an offset value returned
> >from a call to ftell.

This allows the library to read() through the file instead of seeking,
to compensage for CR/LF conversions.  If you seek from the end of the
file, these rules do not guarantee success.

The problems are usually in ftell(), since with buffered I/O it's
nearly impossible to determine what actual file position corresponds
to a character in the middle of a stdio buffer.  DJGPP could only
solve this problem by having stdio open *all* files as binary, and
managing the conversion after the buffering.

Re: Cygwin B20 - fseek under gcc fails to reposition on text files

[Corinna Vinschen]

Christopher Faylor wrote:
> 
> On Tue, Feb 16, 1999 at 07:41:34AM -0800, Earnie Boyd wrote:
> >
> >Here is the "Microsoft VC++ Run-Time Library Reference" quote:
> >
> >For streams opened in text mode, fseek has limited use, because
> >carriage return-linefeed translations can cause fseek to produce
> >unexpected results.  The only fseek operations guaranteed to work on
> >streams opened in text mode are:
> >
> >* Seeking with an offset of 0 relative to any of the origin values.
> >
> >* Seeking from the beginning of the file with an offset value returned
> >from a call to ftell.
> >
> >Also in text mode, CTRL+Z is interpreted as an end-of-file character
> >[...]

This is the _documentation_ of M$. In fact their code doesn't do the right
thing! As the ftell of newlib, it works without special calls of the
underlying OS, only calls to `_lseek()' are performed.  The only difference
between M$ and newlib is, that M$ performs additional counting of \n in
case of text file processing. It's done in the already translated buffer,
so the result is crap, as in newlib. Only their hit count is better.

> >Based on the documentation then I'll have to agree that your programs
> >isn't behaving as the documentation states that it should.  But, which
> >is wrong, fseek or ftell?
> 
> This does sound like a bug.  We'll try to look into this, time permitting.
> 
> If anyone else wants to take a stab at this (Corinna?) I'd be very grateful.

We have three possible choices:

1st: We are not performing the same errors as M$. We do our own, so we let
     it as it is.

2nd: M$-compatible errors, so we let ftell count \n, too. This would result
     in more often correct telling.

3rd: The full stdio code in newlib has to be changed. The buffer is used
     anyway in binary mode, every call has to use new counting and
     translation methods than the current one.
     Because this has to be done _very_ cautious, it's a long time change.

For the near future, I would prefer the second choice. Other opinions?

Regards,
Corinna


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

Re: Cygwin B20 - fseek under gcc fails to reposition on text files

[DJ Delorie]

> 3rd: The full stdio code in newlib has to be changed. The buffer is used
>      anyway in binary mode, every call has to use new counting and
>      translation methods than the current one.
>      Because this has to be done _very_ cautious, it's a long time change.

FYI, DJGPP does it this way, and you're right, it was a big change.

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

Re: Cygwin B20 - fseek under gcc fails to reposition on text files

[DJ Delorie]

> 3rd: The full stdio code in newlib has to be changed. The buffer is used
>      anyway in binary mode, every call has to use new counting and
>      translation methods than the current one.
>      Because this has to be done _very_ cautious, it's a long time change.

FYI, DJGPP does it this way, and you're right, it was a big change.

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

Re: Cygwin B20 - fseek under gcc fails to reposition on text files

[J. J. Farrell]

> From: Corinna Vinschen <corinna.vinschen@cityweb.de>
> 
> Christopher Faylor wrote:
> > 
> > On Tue, Feb 16, 1999 at 07:41:34AM -0800, Earnie Boyd wrote:
> > >
> > >Here is the "Microsoft VC++ Run-Time Library Reference" quote:
> > >
> > >For streams opened in text mode, fseek has limited use, because
> > >carriage return-linefeed translations can cause fseek to produce
> > >unexpected results.  The only fseek operations guaranteed to work on
> > >streams opened in text mode are:
> > >
> > >* Seeking with an offset of 0 relative to any of the origin values.
> > >
> > >* Seeking from the beginning of the file with an offset value returned
> > >from a call to ftell.
> > >
> > >Also in text mode, CTRL+Z is interpreted as an end-of-file character
> > >[...]
> 
> This is the _documentation_ of M$. In fact their code doesn't do the right
> thing! As the ftell of newlib, it works without special calls of the
> underlying OS, only calls to `_lseek()' are performed.  The only difference
> between M$ and newlib is, that M$ performs additional counting of \n in
> case of text file processing. It's done in the already translated buffer,
> so the result is crap, as in newlib. Only their hit count is better.
> 
> We have three possible choices:
> 
> 1st: We are not performing the same errors as M$. We do our own, so we let
>      it as it is.
> 
> 2nd: M$-compatible errors, so we let ftell count \n, too. This would result
>      in more often correct telling.
> 
> 3rd: The full stdio code in newlib has to be changed. The buffer is used
>      anyway in binary mode, every call has to use new counting and
>      translation methods than the current one.
>      Because this has to be done _very_ cautious, it's a long time change.
> 
> For the near future, I would prefer the second choice. Other opinions?

This isn't just a question of compatibility with MS, it's one of
conformance to Standard C - we should aim to get it right, in the
long term at least, whether we like it or not!

Here are a couple of extracts from C89 which describe how this
lot should work on text streams - it's perhaps safer to base an
implementation on what comes from the horse's mouth rather than
what MS's documentation says, though MS looks basically OK in
this case:

   4.9.9.2  int fseek(FILE *stream, long int offset, int whence)

   For a text stream, either <offset> shall be zero, or <offset>
   shall be a value returned by an earlier call to the <ftell>
   function on the same stream and <whence> shall be <SEEK_SET>.


   4.9.9.4  long int ftell(FILE *stream)

   The <ftell> function obtains the current value of the file
   position indicator for the stream pointed to by <stream>. 
   For a text stream, its file position indicator contains
   unspecified information, usable by the <fseek> function for
   returning the file position indicator for the stream to its
   position at the time of the <ftell> call; the difference
   between two such return values is not necessarily a meaningful
   measure of the number of characters written or read.

Do we do fgetpos/fsetpos right for both binary and text? The
definition of ftell/fseek for text is essentially the same as
fgetpos/fsetpos for both types - so I would guess there's either
a problem with fgetpos/fsetpos as well, or we could pinch
something from it for the ftell/fseek text case.


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

Re: Cygwin B20 - fseek under gcc fails to reposition on text files

[J. J. Farrell]

> From: Corinna Vinschen <corinna.vinschen@cityweb.de>
> 
> Christopher Faylor wrote:
> > 
> > On Tue, Feb 16, 1999 at 07:41:34AM -0800, Earnie Boyd wrote:
> > >
> > >Here is the "Microsoft VC++ Run-Time Library Reference" quote:
> > >
> > >For streams opened in text mode, fseek has limited use, because
> > >carriage return-linefeed translations can cause fseek to produce
> > >unexpected results.  The only fseek operations guaranteed to work on
> > >streams opened in text mode are:
> > >
> > >* Seeking with an offset of 0 relative to any of the origin values.
> > >
> > >* Seeking from the beginning of the file with an offset value returned
> > >from a call to ftell.
> > >
> > >Also in text mode, CTRL+Z is interpreted as an end-of-file character
> > >[...]
> 
> This is the _documentation_ of M$. In fact their code doesn't do the right
> thing! As the ftell of newlib, it works without special calls of the
> underlying OS, only calls to `_lseek()' are performed.  The only difference
> between M$ and newlib is, that M$ performs additional counting of \n in
> case of text file processing. It's done in the already translated buffer,
> so the result is crap, as in newlib. Only their hit count is better.
> 
> We have three possible choices:
> 
> 1st: We are not performing the same errors as M$. We do our own, so we let
>      it as it is.
> 
> 2nd: M$-compatible errors, so we let ftell count \n, too. This would result
>      in more often correct telling.
> 
> 3rd: The full stdio code in newlib has to be changed. The buffer is used
>      anyway in binary mode, every call has to use new counting and
>      translation methods than the current one.
>      Because this has to be done _very_ cautious, it's a long time change.
> 
> For the near future, I would prefer the second choice. Other opinions?

This isn't just a question of compatibility with MS, it's one of
conformance to Standard C - we should aim to get it right, in the
long term at least, whether we like it or not!

Here are a couple of extracts from C89 which describe how this
lot should work on text streams - it's perhaps safer to base an
implementation on what comes from the horse's mouth rather than
what MS's documentation says, though MS looks basically OK in
this case:

   4.9.9.2  int fseek(FILE *stream, long int offset, int whence)

   For a text stream, either <offset> shall be zero, or <offset>
   shall be a value returned by an earlier call to the <ftell>
   function on the same stream and <whence> shall be <SEEK_SET>.


   4.9.9.4  long int ftell(FILE *stream)

   The <ftell> function obtains the current value of the file
   position indicator for the stream pointed to by <stream>. 
   For a text stream, its file position indicator contains
   unspecified information, usable by the <fseek> function for
   returning the file position indicator for the stream to its
   position at the time of the <ftell> call; the difference
   between two such return values is not necessarily a meaningful
   measure of the number of characters written or read.

Do we do fgetpos/fsetpos right for both binary and text? The
definition of ftell/fseek for text is essentially the same as
fgetpos/fsetpos for both types - so I would guess there's either
a problem with fgetpos/fsetpos as well, or we could pinch
something from it for the ftell/fseek text case.


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

Re[2]: Cygwin B20 - fseek under gcc fails to reposition on text files

[Paul Sokolovsky]

Hello Corinna,

Corinna Vinschen <corinna.vinschen@cityweb.de> wrote:

[]

CV> We have three possible choices:

CV> 1st: We are not performing the same errors as M$. We do our own, so we let
CV>      it as it is.

CV> 2nd: M$-compatible errors, so we let ftell count \n, too. This would result
CV>      in more often correct telling.

CV> 3rd: The full stdio code in newlib has to be changed. The buffer is used
CV>      anyway in binary mode, every call has to use new counting and
CV>      translation methods than the current one.
CV>      Because this has to be done _very_ cautious, it's a long time change.

CV> For the near future, I would prefer the second choice. Other opinions?

    Let me support 3rd way, in rather flamy passages, however.

    So, for more than twenty years MS maintains myth about "special
format" of text files of their systems. It's hardly believable. Since
my old XT I quite nicely handled any text files - be they Unix \xa,
Mac \xd, or "dos" \xd\xa . So there's nothing special to talk about
"special" format of text files. Most tools available handled any type,
and conversion between formats was quite feasible. With win32, such
problems are ceased at all - I don't have no line endings problems, no
encoding problems, even that unicode seams to be here.

   And here we come to most interesting questions - that fact that MS
maintains aforementioned myth is not surprising, but that myth is
carefully maintained by outside crew too! Just listen to those GNUers
telling us that text files here are "special" and they must dirty
workaround that! Just see peoples advocating data stream corruption on
most basic system level!

   But what if stop that play and acknowledge that some guys have done
quite well and it's useless to try to not notice that. \r\n textfiles
should be handled properly where they belong - e.g. in textutils, but
never in core system, leading just to corruption.

   So, what I argue:

1. Text/binary file notion on most basic, POSIX level should be
   abandoned.
2. That has nothing to do with stdio level - since default accessors for
   that level are single-character oriented, it doesn't hurt much
   stuffing single test there.

(Note that this indeed DJ Delorie's idea as of DJGPP lib, pushed further
to exterminating textuality on POSIX level at all)

3. All stuff working with textfiles and using POSIX level either should
   be taught accept any line-endings or reimplented in stdio.

4. Until then, there're fromdos/todos filters.


   And finally, from where all this stuff might be originated - it may
be done whatever wanted, but if, when writing to console we get clobbered
output without carrage returns, it doesn't cost a cent. That's where
myth of win32 speciality breaks down - Win32 console, as any other
console in cooked mode (Linux, say) performs implicit cr after lf,
when there's no explicit.

   Just run following (tested only on Win95/Win95OSR2 to be honest):

--------
#include <windows.h>

char str[]="\nline1\nline2\nline3\n";

void main()
{
  DWORD dummy;
  WriteFile(STD_OUTPUT_HANDLE,str,sizeof(str)-1,&dummy,NULL);
  WriteFile(STD_ERROR_HANDLE,str,sizeof(str)-1,&dummy,NULL);
}
--------


CV> Regards,
CV> Corinna


Best regards,
 Paul                            mailto:paul-ml@is.lg.ua


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

Re: Cygwin B20 - fseek under gcc fails to reposition on text files

[DJ Delorie]

>    And finally, from where all this stuff might be originated - it may
> be done whatever wanted, but if, when writing to console we get clobbered
> output without carrage returns, it doesn't cost a cent. That's where
> myth of win32 speciality breaks down - Win32 console, as any other
> console in cooked mode (Linux, say) performs implicit cr after lf,
> when there's no explicit.

To add fact to the myth, if you bring up such a file (\n without \r)
in notepad, it does not do the right thing - it very explicitly looks
for the CR/LF pair to mean a line ending, and no other ending will do.

Batch files also cannot have NL endings - they need CR/LF endings.

Of course, this really just means that the programmers were
short-sighted, but it's still a fact we must live with.

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

Re: Cygwin B20 - fseek under gcc fails to reposition on text files

[Larry Hall]

At 01:07 PM 2/17/99 -0500, DJ Delorie wrote:
>Batch files also cannot have NL endings - they need CR/LF endings.

You sure about that?  In my binary mounted environment I tried:

D:\tmp>cat b.bat
echo hello

D:\tmp>b

D:\tmp>echo hello
hello

D:\tmp>od -h b.bat
0000000 6365 6f68 6820 6c65 6f6c 000a
0000013

D:\tmp>

Hm...


Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      (781) 239-1053
8 Grove Street                          (781) 239-1655 - FAX
Wellesley, MA  02482-7797               http://www.rfk.com

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

Re: Cygwin B20 - fseek under gcc fails to reposition on text files

[DJ Delorie]

> You sure about that?  In my binary mounted environment I tried:

Under Win95, try two lines:

	echo hi
	dir

I *know* DOS has this problem, I suspect Win95 shares it.  NT does not.

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

Re: Cygwin B20 - fseek under gcc fails to reposition on text files

[Larry Hall]

At 10:18 PM 2/17/99 -0500, DJ Delorie wrote:
>
>> You sure about that?  In my binary mounted environment I tried:
>
>Under Win95, try two lines:
>
>	echo hi
>	dir
>
>I *know* DOS has this problem, I suspect Win95 shares it.  NT does not.
>

Ah, forgot about that!  I'm on NT!;-)


Larry

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

Re: Cygwin B20 - fseek under gcc fails to reposition on text files

[Larry Hall]

At 10:18 PM 2/17/99 -0500, DJ Delorie wrote:
>
>> You sure about that?  In my binary mounted environment I tried:
>
>Under Win95, try two lines:
>
>	echo hi
>	dir
>
>I *know* DOS has this problem, I suspect Win95 shares it.  NT does not.
>

Ah, forgot about that!  I'm on NT!;-)


Larry

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

Re: Cygwin B20 - fseek under gcc fails to reposition on text files

[DJ Delorie]

> You sure about that?  In my binary mounted environment I tried:

Under Win95, try two lines:

	echo hi
	dir

I *know* DOS has this problem, I suspect Win95 shares it.  NT does not.

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

Re: Cygwin B20 - fseek under gcc fails to reposition on text files

[Larry Hall]

At 01:07 PM 2/17/99 -0500, DJ Delorie wrote:
>Batch files also cannot have NL endings - they need CR/LF endings.

You sure about that?  In my binary mounted environment I tried:

D:\tmp>cat b.bat
echo hello

D:\tmp>b

D:\tmp>echo hello
hello

D:\tmp>od -h b.bat
0000000 6365 6f68 6820 6c65 6f6c 000a
0000013

D:\tmp>

Hm...


Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      (781) 239-1053
8 Grove Street                          (781) 239-1655 - FAX
Wellesley, MA  02482-7797               http://www.rfk.com

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

Re: Cygwin B20 - fseek under gcc fails to reposition on text files

[DJ Delorie]

>    And finally, from where all this stuff might be originated - it may
> be done whatever wanted, but if, when writing to console we get clobbered
> output without carrage returns, it doesn't cost a cent. That's where
> myth of win32 speciality breaks down - Win32 console, as any other
> console in cooked mode (Linux, say) performs implicit cr after lf,
> when there's no explicit.

To add fact to the myth, if you bring up such a file (\n without \r)
in notepad, it does not do the right thing - it very explicitly looks
for the CR/LF pair to mean a line ending, and no other ending will do.

Batch files also cannot have NL endings - they need CR/LF endings.

Of course, this really just means that the programmers were
short-sighted, but it's still a fact we must live with.

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

Re: Cygwin B20 - fseek under gcc fails to reposition on text files

[Corinna Vinschen]

Paul Sokolovsky wrote:
>     So, for more than twenty years MS maintains myth about "special
> format" of text files of their systems. It's hardly believable. Since
> my old XT I quite nicely handled any text files - be they Unix \xa,
> Mac \xd, or "dos" \xd\xa . So there's nothing special to talk about
> "special" format of text files. Most tools available handled any type,
> and conversion between formats was quite feasible. With win32, such
> problems are ceased at all - I don't have no line endings problems, no
> encoding problems, even that unicode seams to be here.

As a matter of fact: Peter's c example, which opens this thread, does
not work with VC++, if the newline is not \r\n. Look into the source
of M$-ftell(), it can't work.

The best way would be to throw away and ignore any newline with
more than one single character.

But let's get serious.

IMHO, above all text file processing should be done according to the
underlying OS and it's vendor, also if this is wretched.

The second choice has the advantage, to be easy to implement.

The third choice should be implemented, if s.o. has nothing important
to do.

Regards,
Corinna


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

Re[2]: Cygwin B20 - fseek under gcc fails to reposition on text files

[Paul Sokolovsky]

Hello Corinna,

Corinna Vinschen <corinna.vinschen@cityweb.de> wrote:

>>     So, for more than twenty years MS maintains myth about "special
>> format" of text files of their systems. It's hardly believable. Since

CV> The best way would be to throw away and ignore any newline with
CV> more than one single character.

    Yes, and bad thing is that people came say, from Unix, and don't knowing
that here text files are special, but constantly getting binary file
corruptions when filtering gifs, piping gzips, etc. may think that way is
right ;-(

CV> But let's get serious.

CV> IMHO, above all text file processing should be done according to the
CV> underlying OS and it's vendor, also if this is wretched.

    Bad thing is that issue very minor. People might don't care what
line-endings text files have, they might don't care that there's
notepad and bat files. And when their favorite vi chokes on that \r at
the end (or beginning? ;-) ) of line they might teach him chop it -
after all, that's not notepad. But they might think that wrapping each
command piping binary files in shell script setting CYGWIN (having
spent some nice time trying to understand why their files are
corrupted and asking maillist why this bug) is too awkward.

   Of course, that far too imaganable picture, just like my previous
massage has, just like several years ago cygwin itself was only
imaganable. I don't believe that things enpictured by me will be, or
even should be, done to cygwin. I just wanted to hyperbolize it,
showing that changing itself is not an edge alternative, all
determained by ammount of changes, and there might be the golden mean,
exactly what you'll do. (That's just because I have a ho that Cygnus
guys quite conservative - I remember Christopher Faylor's hesitating
in cygwin-developer whether correcting bug won't break user (or
customer) code. Maybe you, Corinna, as leading contributor, and DJ, as
author of alternative approach, and working for Cygnus, have other
opinions).

   But there still that idea - there maybe niche that cygwin doesn't
fill - to be more unixish despite be less winnish.

CV> The second choice has the advantage, to be easy to implement.

CV> The third choice should be implemented, if s.o. has nothing important
CV> to do.

CV> Regards,
CV> Corinna

    Thanks for not taking previous text as profanity, that's was just rebellion
humoresqe, just forgot adding trailing disclaimer ;-)


Best regards,
 Paul                            mailto:paul-ml@is.lg.ua


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

Re: Cygwin B20 - fseek under gcc fails to reposition on text files

[Christopher Faylor]

On Thu, Feb 18, 1999 at 06:38:46PM +0200, Paul Sokolovsky wrote:
>    Bad thing is that issue very minor. People might don't care what
>line-endings text files have, they might don't care that there's
>notepad and bat files. And when their favorite vi chokes on that \r at
>the end (or beginning? ;-) ) of line they might teach him chop it -
>after all, that's not notepad. But they might think that wrapping each
>command piping binary files in shell script setting CYGWIN (having
>spent some nice time trying to understand why their files are
>corrupted and asking maillist why this bug) is too awkward.

Actually, as far as pipes are concerned, they default to binmode
unless overridden by CYGWIN so this should not be an issue.

>   Of course, that far too imaganable picture, just like my previous
>massage has, just like several years ago cygwin itself was only
>imaganable. I don't believe that things enpictured by me will be, or
>even should be, done to cygwin. I just wanted to hyperbolize it,
>showing that changing itself is not an edge alternative, all
>determained by ammount of changes, and there might be the golden mean,
>exactly what you'll do. (That's just because I have a ho that Cygnus
>guys quite conservative - I remember Christopher Faylor's hesitating
>in cygwin-developer whether correcting bug won't break user (or
>customer) code. Maybe you, Corinna, as leading contributor, and DJ, as
>author of alternative approach, and working for Cygnus, have other
>opinions).

I have no idea what, specifically, you are referring to but it is
interesting that you find it "quite conservative" to consider caring
about breaking somebody's code.  You are probably referring to my
soliciting of opinions on the subject of breaking API compatibility
with a new cygwin DLL.  This was obviously a subject which deserved
careful consideration and it was something that I was willing to do.
In fact, it is something that *will* occur in a future release.

Regardless, if you look at the ChangeLog in the last year, you'll find
that I'm the author of a lot of radical changes in Cygwin.

I am not at all opposed to the idea of somebody fixing ftell/fseek
to work as Microsoft has documented them or as DJGPP has currently
implemented things.  I've written a stdio layer myself and I know
that this is not a trivial undertaking, though.  Certainly no
one at Cygnus has the time right now to undertake this.

Currently, Corinna, Mumit, and a couple of other people are the only
outside contributers to the project.  Everyone else seems to be in
"Cygwin doesn't work the way I think it should when I run program X.
Here's the error message." mode.

I'm collecting the error messages and hope to investigate problems but
the reality is that this is a volunteer effort for DJ and me.  Our
real jobs don't offer much time for tracking down net problems.

-chris

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

Re[2]: Cygwin B20 - fseek under gcc fails to reposition on text files

[Paul Sokolovsky]

Hello Christopher,

Christopher Faylor <cgf@cygnus.com> wrote:

[]

CF> Currently, Corinna, Mumit, and a couple of other people are the only
CF> outside contributers to the project.  Everyone else seems to be in
CF> "Cygwin doesn't work the way I think it should when I run program X.
CF> Here's the error message." mode.

    With other opinions expressed in this thread, I'd like to add
following: it's quite understood that most people are in that mode -
they are using cygwin as their tool, something like car, and are not
concerned, or able to, how it's functioning. Hopefully, that's what
you wanted - to give people nice tool, to keep balance with such toys
like msvc, delphi, etc.

    But when someone wants to fix or add something to cygwin, here
comes another problem - it's high enough threshold to be able to do
so. Even higher threshold to make it acceptable for inclusion back.
By this I mean whole technology issues - not Cygwin technology, I call
it GNU technology - configuration/setup methods, coding styles (not
just mere conventions for identifier naming / block indentation, but
modularization conventions, from source modules thru libs to
executables, etc.) And all that are obstacles to contributing. But of
course I don't say that's bad - there must be order and who willing to
contribute should know and accept it, but it requires time, and
potential contributors may not have it, just the same as developers
may not ;-) .

    Ok, I turn down considering problems of open-source
development, this is hardly appropriate place for it.

CF> I'm collecting the error messages and hope to investigate problems but
CF> the reality is that this is a volunteer effort for DJ and me.  Our
CF> real jobs don't offer much time for tracking down net problems.

CF> -chris


Best regards,
 Paul                            mailto:paul-ml@is.lg.ua


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

Cygwin participation threshold

[DJ Delorie]

> Hopefully, that's what you wanted - to give people a nice tool,

I think it would be more accurate to replace "give" with "share with".

As a bit of history, Cygnus had a purely business reason to create
cygwin.  Doing so let us host our tools on 95/NT platforms, which
meant more customers (i.e. more money).  AFAIK, releasing cygwin to
the net had two reasons: the first philosophical, in that we like to
share; and the second practical, in that the more people using cygwin
the more paid support contracts we'll get.

>     But when someone wants to fix or add something to cygwin, here
> comes another problem - it's high enough threshold to be able to do
> so. Even higher threshold to make it acceptable for inclusion back.

DJGPP has a much higher threshold (it's much more complicated), but
there are far more people contributing to djgpp than to cygwin.  If
anyone can figure out *why*, let us know! ;-) I think it's social -
djgpp contributors just know that they'll get a friendly reception to
their contributions, good or bad, so they aren't as hesitant to send
stuff in.

> By this I mean whole technology issues - not Cygwin technology, I
> call it GNU technology - configuration/setup methods, coding styles
> (not just mere conventions for identifier naming / block
> indentation, but modularization conventions, from source modules
> thru libs to executables, etc.) And all that are obstacles to
> contributing.

Even so, I'd rather people contribute what they can instead of just
sulking off in a corner and getting nowhere.  We're not going to laugh
at you for bad style (I hope).  More likely, we'll explain how to
change what you've got to work better with what we've got (it's called
"learning").  Cooperation is a two-way street!  If you're willing to
do *anything*, we'll probably meet you half-way.

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

Re: Cygwin participation threshold

[Carl Zmola]

> DJGPP has a much higher threshold (it's much more complicated), but
> there are far more people contributing to djgpp than to cygwin.  If
> anyone can figure out *why*, let us know! ;-) I think it's social -
> djgpp contributors just know that they'll get a friendly reception to
> their contributions, good or bad, so they aren't as hesitant to send
> stuff in.

That could be part of it.  The fact that a company is in charge of 
coordinating the efforts has an effect.

In the past the main reason I didn't even investigate contributing is :
Because of the feeling that contributions are unwanted, and that someone
else is making money of of my work.

After a little investigation, I found that these wern't valid concerns, but
they are a first line of resistance.  

Carl 
zmola@campbellsci.com

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

Re: Cygwin participation threshold

[Fergus Henderson]

> DJGPP has a much higher threshold (it's much more complicated), but
> there are far more people contributing to djgpp than to cygwin.  If
> anyone can figure out *why*, let us know! ;-) I think it's social -
> djgpp contributors just know that they'll get a friendly reception to
> their contributions, good or bad, so they aren't as hesitant to send
> stuff in.

I think the licensing may well have something to do with it.
DJGPP is licensed under a quite liberal license.
Cygwin, on the other hand, is only licensed under the GPL
or for a fee.  For libraries, the GPL is quite restrictive.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "Binaries may die
WWW: < http://www.cs.mu.oz.au/~fjh >  |   but source code lives forever"
PGP: finger fjh@128.250.37.3        |     -- leaked Microsoft memo.

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

Re: Cygwin participation threshold

[Fergus Henderson]

> DJGPP has a much higher threshold (it's much more complicated), but
> there are far more people contributing to djgpp than to cygwin.  If
> anyone can figure out *why*, let us know! ;-) I think it's social -
> djgpp contributors just know that they'll get a friendly reception to
> their contributions, good or bad, so they aren't as hesitant to send
> stuff in.

I think the licensing may well have something to do with it.
DJGPP is licensed under a quite liberal license.
Cygwin, on the other hand, is only licensed under the GPL
or for a fee.  For libraries, the GPL is quite restrictive.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "Binaries may die
WWW: < http://www.cs.mu.oz.au/~fjh >  |   but source code lives forever"
PGP: finger fjh@128.250.37.3        |     -- leaked Microsoft memo.

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

Re: Cygwin participation threshold

[DJ Delorie]

> That could be part of it.  The fact that a company is in charge of 
> coordinating the efforts has an effect.

What effect?  I would think that having a company back a project would
be *good*, since they have more to lose if it fails.

> In the past the main reason I didn't even investigate contributing
> is : Because of the feeling that contributions are unwanted, and
> that someone else is making money of of my work.
>
> After a little investigation, I found that these wern't valid
> concerns, but they are a first line of resistance.

How did you get these impressions?  If there is a way for us to make
sure people get the right impressions up front, perhaps that would
save people a bit of grief.

However, let's get one thing straight: Cygnus *is* making money off
your work, at least indirectly.  However, in return we're giving a lot
of technology and effort (in the form of cygwin, since we do most of
the work on it) back to the community (you).  I'd like to think this
is a fair exchange.  Do you think this is a fair exchange?

As for contributions, we definitely want them, but keep in mind that
it's our responsibility to the cygwin community (you), as the "keepers
of cygwin", to ensure that anything added to cygwin doesn't make it
worse.  The preferred method of dealing with these types of
contributions is to work with the author until they meet our
standards, rather than simply rejecting it.

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

Re: Cygwin participation threshold

[DJ Delorie]

> That could be part of it.  The fact that a company is in charge of 
> coordinating the efforts has an effect.

What effect?  I would think that having a company back a project would
be *good*, since they have more to lose if it fails.

> In the past the main reason I didn't even investigate contributing
> is : Because of the feeling that contributions are unwanted, and
> that someone else is making money of of my work.
>
> After a little investigation, I found that these wern't valid
> concerns, but they are a first line of resistance.

How did you get these impressions?  If there is a way for us to make
sure people get the right impressions up front, perhaps that would
save people a bit of grief.

However, let's get one thing straight: Cygnus *is* making money off
your work, at least indirectly.  However, in return we're giving a lot
of technology and effort (in the form of cygwin, since we do most of
the work on it) back to the community (you).  I'd like to think this
is a fair exchange.  Do you think this is a fair exchange?

As for contributions, we definitely want them, but keep in mind that
it's our responsibility to the cygwin community (you), as the "keepers
of cygwin", to ensure that anything added to cygwin doesn't make it
worse.  The preferred method of dealing with these types of
contributions is to work with the author until they meet our
standards, rather than simply rejecting it.

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

Re: Cygwin participation threshold

[Christopher Faylor]

On Mon, Feb 22, 1999 at 11:30:59AM +0000, Carl Zmola wrote:
>
>> DJGPP has a much higher threshold (it's much more complicated), but
>> there are far more people contributing to djgpp than to cygwin.  If
>> anyone can figure out *why*, let us know! ;-) I think it's social -
>> djgpp contributors just know that they'll get a friendly reception to
>> their contributions, good or bad, so they aren't as hesitant to send
>> stuff in.
>
>That could be part of it.  The fact that a company is in charge of 
>coordinating the efforts has an effect.
>
>In the past the main reason I didn't even investigate contributing is :
>Because of the feeling that contributions are unwanted, and that someone
>else is making money of of my work.
>
>After a little investigation, I found that these wern't valid concerns, but
>they are a first line of resistance.  

It is interesting that you felt this way at first.  I wonder if the reason
has anything to do with the name "Cygwin" which sounds so similar to "Cygnus".

The reason I am saying this is because hundreds of people have contributed to
the linux project and *many* companies make money from linux.

cgf

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

Re: Cygwin participation threshold

[Fergus Henderson]

On 23-Feb-1999, Christopher Faylor <cgf@cygnus.com> wrote:
> On Mon, Feb 22, 1999, Carl Zmola wrote:
> >
> >The fact that a company is in charge of 
> >coordinating the efforts has an effect.
> >
> >In the past the main reason I didn't even investigate contributing is :
> >Because of the feeling that contributions are unwanted, and that someone
> >else is making money of of my work.
> >
> >After a little investigation, I found that these wern't valid concerns, but
> >they are a first line of resistance.  
> 
> It is interesting that you felt this way at first.  I wonder if the reason
> has anything to do with the name "Cygwin" which sounds so similar to "Cygnus".
> 
> The reason I am saying this is because hundreds of people have contributed to
> the linux project and *many* companies make money from linux.

Yes, but you can write and distribute proprietry applications or even
proprietry kernel modules for Linux without paying anyone a license fee.
The same is not true for Cygwin (although it *was* true once, back around
version b16, when it was called gnu-win32).

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "Binaries may die
WWW: < http://www.cs.mu.oz.au/~fjh >  |   but source code lives forever"
PGP: finger fjh@128.250.37.3        |     -- leaked Microsoft memo.

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

Re: Cygwin participation threshold

[Christopher Faylor]

On Thu, Feb 25, 1999 at 12:51:48AM +1100, Fergus Henderson wrote:
>On 23-Feb-1999, Christopher Faylor <cgf@cygnus.com> wrote:
>> On Mon, Feb 22, 1999, Carl Zmola wrote:
>> >
>> >The fact that a company is in charge of 
>> >coordinating the efforts has an effect.
>> >
>> >In the past the main reason I didn't even investigate contributing is :
>> >Because of the feeling that contributions are unwanted, and that someone
>> >else is making money of of my work.
>> >
>> >After a little investigation, I found that these wern't valid concerns, but
>> >they are a first line of resistance.  
>> 
>> It is interesting that you felt this way at first.  I wonder if the reason
>> has anything to do with the name "Cygwin" which sounds so similar to "Cygnus".
>> 
>> The reason I am saying this is because hundreds of people have contributed to
>> the linux project and *many* companies make money from linux.
>
>Yes, but you can write and distribute proprietry applications or even
>proprietry kernel modules for Linux without paying anyone a license fee.
>The same is not true for Cygwin (although it *was* true once, back around
>version b16, when it was called gnu-win32).

True, but that is not the point.  I believe this whold thread started
because I lamented the lack of people contributing directly to cygwin
development.  The many contributors to the linux kernel do not do so
because it is possible to develop proprietary code for linux.

I don't consider companies who create proprietary kernel modules as
contributing to linux development in any way.  Possibly they help indirectly
by getting the word out about linux but that is a secondary and, IMO, very
minor benefit.

cf

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

Re: Cygwin participation threshold

[Weiqi Gao]

Christopher Faylor wrote:
> 
> True, but that is not the point.  I believe this whold thread started
> because I lamented the lack of people contributing directly to cygwin
> development.  The many contributors to the linux kernel do not do so
> because it is possible to develop proprietary code for linux.
> 
> I don't consider companies who create proprietary kernel modules as
> contributing to linux development in any way.  Possibly they help indirectly
> by getting the word out about linux but that is a secondary and, IMO, very
> minor benefit.

Windows is too complicated.  It usually takes a sharp individual a long
time (four years?) to become really proficient in Windows.  And that
proficiency usually last a very short time (two years).  All of their
knowledge would have been gained through the continued (and expensive)
subscription to MSDN.  They usually don't feel compelled to contribute
to anything.

It's the culture.  Groups of Windows developers would sit around bashing
Unix.  An ActiveX DLL is the highest ideal that they can attain. 
Putting the "copy file" animation into every program is their idea of
fun.  Their world evolved around OLE, COM, ActiveX, DirectX, ODBC, DAO,
RDO, ADO, DCOM, MVM.

They would ask: "what's the point of Cygwin?"  And you answer "so that
Cygnus can host GNU tools on NT for embedded programming."  They open up
their MSDN case, thumb through the couple dozen or so CDs inside and
find WindowsCE.  "We have Visual Basic and Windows CE.  And Microsoft
told me that's all I need for embedded programming," they would say.  "I
don't care what you think of me, but as far as I'm concerned, Microsoft
invented the PC in 1980.  They invented GUI and the Mouse in 1989.  They
invented TCP/IP in 1992. And they invented the Internet in 1995."

There's a huge mass of them out there is a fact of life.  The only way
to turn their heads around and even look at something non-Microsofty is
to show them a huge amount of money.  "What's there in it for me?" is
their motto, or they wouldn't have become Windows programmers.

If you don't believe me, look at (or just imagine) the latest CNN/USA
Today poll.

--
Weiqi Gao
weiqigao@a.crl.com

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

Re: Cygwin participation threshold

[Fergus Henderson]

On 24-Feb-1999, Weiqi Gao <weiqigao@a.crl.com> wrote:
> 
> Windows is too complicated.  It usually takes a sharp individual a long
> time (four years?) to become really proficient in Windows.  And that
> proficiency usually last a very short time (two years).  All of their
> knowledge would have been gained through the continued (and expensive)
> subscription to MSDN.  They usually don't feel compelled to contribute
> to anything.

That doesn't explain why they contribute more to djgpp than to cygwin.

> It's the culture.  Groups of Windows developers would sit around bashing
> Unix.

But that could well explain it.

One thing that might help would be better mingw32 support.
That might encourage people who would otherwise use djgpp
to use cygwin instead.  But I suppose they still wouldn't
be likely to contribute to the winsup stuff.

Someone else also commented that people who use cygwin probably
run Linux when they can, and so don't get much chance to play
around with cygwin.  I think that is another very likely explanation.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "Binaries may die
WWW: < http://www.cs.mu.oz.au/~fjh >  |   but source code lives forever"
PGP: finger fjh@128.250.37.3        |     -- leaked Microsoft memo.

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

Re: Cygwin participation threshold

[Weiqi Gao]

Fergus Henderson wrote:
> 
> On 24-Feb-1999, Weiqi Gao <weiqigao@a.crl.com> wrote:
> >
> > Windows is too complicated.  It usually takes a sharp individual a long
> > time (four years?) to become really proficient in Windows.  And that
> > proficiency usually last a very short time (two years).  All of their
> > knowledge would have been gained through the continued (and expensive)
> > subscription to MSDN.  They usually don't feel compelled to contribute
> > to anything.
> 
> That doesn't explain why they contribute more to djgpp than to cygwin.

There is a sense of the "power of personality" in the DJGPP project. 
For example, DJ never complained about not enough people contributing. 
And Eli Zarreskii(?) had never gone into an argument with a user,
contributing or not.  He's been sending out ten pieces of emails per day
for three(?) years now, and fifty percent of them are "Read the FAQ". 
He's accumulated quite a bunch "lose your temper for free" card now!

DOS is also more primitive, simpler, and more UNIX like than Windows. 
And DJGPP is more kernel like than wrapper/call forwarder/translator
like than Cygwin.  It is higher on the Cool scale than Cygwin.  It's
almost the "GNU operating system with the DJGPP kernel".

> > It's the culture.  Groups of Windows developers would sit around bashing
> > Unix.
> 
> But that could well explain it.
> 
> One thing that might help would be better mingw32 support.
> That might encourage people who would otherwise use djgpp
> to use cygwin instead.  But I suppose they still wouldn't
> be likely to contribute to the winsup stuff.
> 
> Someone else also commented that people who use cygwin probably
> run Linux when they can, and so don't get much chance to play
> around with cygwin.  I think that is another very likely explanation.

Historically, UNIX has gathered all the free software writers because it
is accessible and had a free software culture.  DOS and Windows lacks
it.

Here's a challenge: Name as many as you can, any widely spread free
software (in the FSF free speech sense) packages that's originated from
DOS/Windows.  The closest I can come up is an editor called the PFE
(Programmers File Editor) which is a Notepad clone.  But you can't get
the source of it.

The fact that Microsoft "owns" Windows might have something to do with
it.

--
Weiqi Gao
weiqigao@a.crl.com

--
Quote of the day:
  --Which is worse, ignorance or indifference
  --I don't know, and I don't care.

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

Re[2]: Cygwin participation threshold

[Paul Sokolovsky]

Hello Weiqi,

Weiqi Gao <weiqigao@a.crl.com> wrote:


WG> There is a sense of the "power of personality" in the DJGPP project. 
WG> For example, DJ never complained about not enough people contributing. 
WG> And Eli Zarreskii(?) had never gone into an argument with a user,
WG> contributing or not.  He's been sending out ten pieces of emails per day
WG> for three(?) years now, and fifty percent of them are "Read the FAQ". 
WG> He's accumulated quite a bunch "lose your temper for free" card now!

     If you imply current discussion, I don't think you're right. I
haven't heard any complaints about not enough people contributing
from Cygwin people. Instead, they was so attentive to explain this. I
don't think that's bad. Such discussion may help them to make cygwin
better and make cygwin users better understand cygwin and its
developers. As for latter, I think it's an important privilege open
source community (and companies) give their members (and users), which
many other organizations unable to give.

WG> DOS is also more primitive, simpler, and more UNIX like than Windows. 
WG> And DJGPP is more kernel like than wrapper/call forwarder/translator
WG> like than Cygwin.  It is higher on the Cool scale than Cygwin.  It's
WG> almost the "GNU operating system with the DJGPP kernel".

    I agree with you about DJGPP. I however disagree about Win32. My
argument is "They tried hard and they tried long and what they did is
exactly POSIX (I prefer that term) system, but it advertizes its
POSIXness in rather strange and shy words". I may only feel pity that
cygwin can't teach it speak loud and eloquently.

WG> Here's a challenge: Name as many as you can, any widely spread free
WG> software (in the FSF free speech sense) packages that's originated from
WG> DOS/Windows.  The closest I can come up is an editor called the PFE
WG> (Programmers File Editor) which is a Notepad clone.  But you can't get
WG> the source of it.

    From such observations I devised that "two types" theory. ;-)

WG> The fact that Microsoft "owns" Windows might have something to do with
WG> it.

    But God with that they own it. What may displease some people is
observation that they own all end user sector of computer industry,
and more frightenly - attitudes of those users.

WG> --
WG> Weiqi Gao
WG> weiqigao@a.crl.com


Best regards,
 Paul                            mailto:paul-ml@is.lg.ua


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

Re[2]: Cygwin participation threshold

[Paul Sokolovsky]

Hello Weiqi,

Weiqi Gao <weiqigao@a.crl.com> wrote:


WG> There is a sense of the "power of personality" in the DJGPP project. 
WG> For example, DJ never complained about not enough people contributing. 
WG> And Eli Zarreskii(?) had never gone into an argument with a user,
WG> contributing or not.  He's been sending out ten pieces of emails per day
WG> for three(?) years now, and fifty percent of them are "Read the FAQ". 
WG> He's accumulated quite a bunch "lose your temper for free" card now!

     If you imply current discussion, I don't think you're right. I
haven't heard any complaints about not enough people contributing
from Cygwin people. Instead, they was so attentive to explain this. I
don't think that's bad. Such discussion may help them to make cygwin
better and make cygwin users better understand cygwin and its
developers. As for latter, I think it's an important privilege open
source community (and companies) give their members (and users), which
many other organizations unable to give.

WG> DOS is also more primitive, simpler, and more UNIX like than Windows. 
WG> And DJGPP is more kernel like than wrapper/call forwarder/translator
WG> like than Cygwin.  It is higher on the Cool scale than Cygwin.  It's
WG> almost the "GNU operating system with the DJGPP kernel".

    I agree with you about DJGPP. I however disagree about Win32. My
argument is "They tried hard and they tried long and what they did is
exactly POSIX (I prefer that term) system, but it advertizes its
POSIXness in rather strange and shy words". I may only feel pity that
cygwin can't teach it speak loud and eloquently.

WG> Here's a challenge: Name as many as you can, any widely spread free
WG> software (in the FSF free speech sense) packages that's originated from
WG> DOS/Windows.  The closest I can come up is an editor called the PFE
WG> (Programmers File Editor) which is a Notepad clone.  But you can't get
WG> the source of it.

    From such observations I devised that "two types" theory. ;-)

WG> The fact that Microsoft "owns" Windows might have something to do with
WG> it.

    But God with that they own it. What may displease some people is
observation that they own all end user sector of computer industry,
and more frightenly - attitudes of those users.

WG> --
WG> Weiqi Gao
WG> weiqigao@a.crl.com


Best regards,
 Paul                            mailto:paul-ml@is.lg.ua


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

Re: Cygwin participation threshold

[Weiqi Gao]

Fergus Henderson wrote:
> 
> On 24-Feb-1999, Weiqi Gao <weiqigao@a.crl.com> wrote:
> >
> > Windows is too complicated.  It usually takes a sharp individual a long
> > time (four years?) to become really proficient in Windows.  And that
> > proficiency usually last a very short time (two years).  All of their
> > knowledge would have been gained through the continued (and expensive)
> > subscription to MSDN.  They usually don't feel compelled to contribute
> > to anything.
> 
> That doesn't explain why they contribute more to djgpp than to cygwin.

There is a sense of the "power of personality" in the DJGPP project. 
For example, DJ never complained about not enough people contributing. 
And Eli Zarreskii(?) had never gone into an argument with a user,
contributing or not.  He's been sending out ten pieces of emails per day
for three(?) years now, and fifty percent of them are "Read the FAQ". 
He's accumulated quite a bunch "lose your temper for free" card now!

DOS is also more primitive, simpler, and more UNIX like than Windows. 
And DJGPP is more kernel like than wrapper/call forwarder/translator
like than Cygwin.  It is higher on the Cool scale than Cygwin.  It's
almost the "GNU operating system with the DJGPP kernel".

> > It's the culture.  Groups of Windows developers would sit around bashing
> > Unix.
> 
> But that could well explain it.
> 
> One thing that might help would be better mingw32 support.
> That might encourage people who would otherwise use djgpp
> to use cygwin instead.  But I suppose they still wouldn't
> be likely to contribute to the winsup stuff.
> 
> Someone else also commented that people who use cygwin probably
> run Linux when they can, and so don't get much chance to play
> around with cygwin.  I think that is another very likely explanation.

Historically, UNIX has gathered all the free software writers because it
is accessible and had a free software culture.  DOS and Windows lacks
it.

Here's a challenge: Name as many as you can, any widely spread free
software (in the FSF free speech sense) packages that's originated from
DOS/Windows.  The closest I can come up is an editor called the PFE
(Programmers File Editor) which is a Notepad clone.  But you can't get
the source of it.

The fact that Microsoft "owns" Windows might have something to do with
it.

--
Weiqi Gao
weiqigao@a.crl.com

--
Quote of the day:
  --Which is worse, ignorance or indifference
  --I don't know, and I don't care.

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

Re: Cygwin participation threshold

[Fergus Henderson]

On 24-Feb-1999, Weiqi Gao <weiqigao@a.crl.com> wrote:
> 
> Windows is too complicated.  It usually takes a sharp individual a long
> time (four years?) to become really proficient in Windows.  And that
> proficiency usually last a very short time (two years).  All of their
> knowledge would have been gained through the continued (and expensive)
> subscription to MSDN.  They usually don't feel compelled to contribute
> to anything.

That doesn't explain why they contribute more to djgpp than to cygwin.

> It's the culture.  Groups of Windows developers would sit around bashing
> Unix.

But that could well explain it.

One thing that might help would be better mingw32 support.
That might encourage people who would otherwise use djgpp
to use cygwin instead.  But I suppose they still wouldn't
be likely to contribute to the winsup stuff.

Someone else also commented that people who use cygwin probably
run Linux when they can, and so don't get much chance to play
around with cygwin.  I think that is another very likely explanation.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "Binaries may die
WWW: < http://www.cs.mu.oz.au/~fjh >  |   but source code lives forever"
PGP: finger fjh@128.250.37.3        |     -- leaked Microsoft memo.

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

Re: Cygwin participation threshold

[Weiqi Gao]

Christopher Faylor wrote:
> 
> True, but that is not the point.  I believe this whold thread started
> because I lamented the lack of people contributing directly to cygwin
> development.  The many contributors to the linux kernel do not do so
> because it is possible to develop proprietary code for linux.
> 
> I don't consider companies who create proprietary kernel modules as
> contributing to linux development in any way.  Possibly they help indirectly
> by getting the word out about linux but that is a secondary and, IMO, very
> minor benefit.

Windows is too complicated.  It usually takes a sharp individual a long
time (four years?) to become really proficient in Windows.  And that
proficiency usually last a very short time (two years).  All of their
knowledge would have been gained through the continued (and expensive)
subscription to MSDN.  They usually don't feel compelled to contribute
to anything.

It's the culture.  Groups of Windows developers would sit around bashing
Unix.  An ActiveX DLL is the highest ideal that they can attain. 
Putting the "copy file" animation into every program is their idea of
fun.  Their world evolved around OLE, COM, ActiveX, DirectX, ODBC, DAO,
RDO, ADO, DCOM, MVM.

They would ask: "what's the point of Cygwin?"  And you answer "so that
Cygnus can host GNU tools on NT for embedded programming."  They open up
their MSDN case, thumb through the couple dozen or so CDs inside and
find WindowsCE.  "We have Visual Basic and Windows CE.  And Microsoft
told me that's all I need for embedded programming," they would say.  "I
don't care what you think of me, but as far as I'm concerned, Microsoft
invented the PC in 1980.  They invented GUI and the Mouse in 1989.  They
invented TCP/IP in 1992. And they invented the Internet in 1995."

There's a huge mass of them out there is a fact of life.  The only way
to turn their heads around and even look at something non-Microsofty is
to show them a huge amount of money.  "What's there in it for me?" is
their motto, or they wouldn't have become Windows programmers.

If you don't believe me, look at (or just imagine) the latest CNN/USA
Today poll.

--
Weiqi Gao
weiqigao@a.crl.com

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

Re: Cygwin participation threshold

[Fergus Henderson]

On 24-Feb-1999, Christopher Faylor <cgf@cygnus.com> wrote:
> On Thu, Feb 25, 1999, Fergus Henderson wrote:
> >Yes, but you can write and distribute proprietry applications or even
> >proprietry kernel modules for Linux without paying anyone a license fee.
> >The same is not true for Cygwin (although it *was* true once, back around
> >version b16, when it was called gnu-win32).
> 
> True, but that is not the point.  I believe this whold thread started
> because I lamented the lack of people contributing directly to cygwin
> development.

You also asked why.  I believe that licensing may be one of the reasons why.
So I don't think my comment is beside the point.  You may disagree with me,
but I think we're talking about the same topic.

> The many contributors to the linux kernel do not do so
> because it is possible to develop proprietary code for linux.

That may not be their direct motivation, but I do think it is a
significant factor.  I think that if it were impossible to develop
proprietry code for Linux, then Linux would have a much smaller user
base, and there would be far fewer contributors to Linux.

> I don't consider companies who create proprietary kernel modules as
> contributing to linux development in any way.

The ability to create proprietry kernel modules is of little importance.
The ability to create proprietry applications is of much greater importance.

> Possibly they help indirectly
> by getting the word out about linux but that is a secondary and, IMO, very
> minor benefit.

I agree that the benefits are indirect and secondary.  However,
I don't think they should be ignored.

In addition to getting the word out, companies which develop proprietry
applications (or kernel modules) often also help

	(1) by using Linux, and in the process sometimes reporting
	    and/or fixing bugs in the kernel and/or the various
	    open-source applications that are part of Linux; sometimes
	    they will even add whole new features which are needed for
	    their proprietry application (or module); and

	(2) by providing software (or drivers) which other people need,
	    and thus encouraging those other people to use Linux,
	    leading to the same benefits as (1).

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "Binaries may die
WWW: < http://www.cs.mu.oz.au/~fjh >  |   but source code lives forever"
PGP: finger fjh@128.250.37.3        |     -- leaked Microsoft memo.

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

Re: Cygwin participation threshold

[Lam Pui Yuen]

done !

On Thu, 25 Feb 1999, Fergus Henderson wrote:

> On 24-Feb-1999, Christopher Faylor <cgf@cygnus.com> wrote:
> > On Thu, Feb 25, 1999, Fergus Henderson wrote:
> > >Yes, but you can write and distribute proprietry applications or even
> > >proprietry kernel modules for Linux without paying anyone a license fee.
> > >The same is not true for Cygwin (although it *was* true once, back around
> > >version b16, when it was called gnu-win32).
> > 
> > True, but that is not the point.  I believe this whold thread started
> > because I lamented the lack of people contributing directly to cygwin
> > development.
> 
> You also asked why.  I believe that licensing may be one of the reasons why.
> So I don't think my comment is beside the point.  You may disagree with me,
> but I think we're talking about the same topic.
> 
> > The many contributors to the linux kernel do not do so
> > because it is possible to develop proprietary code for linux.
> 
> That may not be their direct motivation, but I do think it is a
> significant factor.  I think that if it were impossible to develop
> proprietry code for Linux, then Linux would have a much smaller user
> base, and there would be far fewer contributors to Linux.
> 
> > I don't consider companies who create proprietary kernel modules as
> > contributing to linux development in any way.
> 
> The ability to create proprietry kernel modules is of little importance.
> The ability to create proprietry applications is of much greater importance.
> 
> > Possibly they help indirectly
> > by getting the word out about linux but that is a secondary and, IMO, very
> > minor benefit.
> 
> I agree that the benefits are indirect and secondary.  However,
> I don't think they should be ignored.
> 
> In addition to getting the word out, companies which develop proprietry
> applications (or kernel modules) often also help
> 
> 	(1) by using Linux, and in the process sometimes reporting
> 	    and/or fixing bugs in the kernel and/or the various
> 	    open-source applications that are part of Linux; sometimes
> 	    they will even add whole new features which are needed for
> 	    their proprietry application (or module); and
> 
> 	(2) by providing software (or drivers) which other people need,
> 	    and thus encouraging those other people to use Linux,
> 	    leading to the same benefits as (1).
> 
> -- 
> Fergus Henderson <fjh@cs.mu.oz.au>  |  "Binaries may die
> WWW: < http://www.cs.mu.oz.au/~fjh >  |   but source code lives forever"
> PGP: finger fjh@128.250.37.3        |     -- leaked Microsoft memo.
> 
> --
> 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

Re: Cygwin participation threshold

[Lam Pui Yuen]

dear all,
sorry for this wrong reply mail.
Regs.

> done !
> 
> On Thu, 25 Feb 1999, Fergus Henderson wrote:
> 
> > On 24-Feb-1999, Christopher Faylor <cgf@cygnus.com> wrote:
> > > On Thu, Feb 25, 1999, Fergus Henderson wrote:
> > > >Yes, but you can write and distribute proprietry applications or even
> > > >proprietry kernel modules for Linux without paying anyone a license fee.
> > > >The same is not true for Cygwin (although it *was* true once, back around
> > > >version b16, when it was called gnu-win32).
> > > 
> > > True, but that is not the point.  I believe this whold thread started
> > > because I lamented the lack of people contributing directly to cygwin
> > > development.
> > 
> > You also asked why.  I believe that licensing may be one of the reasons why.
> > So I don't think my comment is beside the point.  You may disagree with me,
> > but I think we're talking about the same topic.
> > 
> > > The many contributors to the linux kernel do not do so
> > > because it is possible to develop proprietary code for linux.
> > 
> > That may not be their direct motivation, but I do think it is a
> > significant factor.  I think that if it were impossible to develop
> > proprietry code for Linux, then Linux would have a much smaller user
> > base, and there would be far fewer contributors to Linux.
> > 
> > > I don't consider companies who create proprietary kernel modules as
> > > contributing to linux development in any way.
> > 
> > The ability to create proprietry kernel modules is of little importance.
> > The ability to create proprietry applications is of much greater importance.
> > 
> > > Possibly they help indirectly
> > > by getting the word out about linux but that is a secondary and, IMO, very
> > > minor benefit.
> > 
> > I agree that the benefits are indirect and secondary.  However,
> > I don't think they should be ignored.
> > 
> > In addition to getting the word out, companies which develop proprietry
> > applications (or kernel modules) often also help
> > 
> > 	(1) by using Linux, and in the process sometimes reporting
> > 	    and/or fixing bugs in the kernel and/or the various
> > 	    open-source applications that are part of Linux; sometimes
> > 	    they will even add whole new features which are needed for
> > 	    their proprietry application (or module); and
> > 
> > 	(2) by providing software (or drivers) which other people need,
> > 	    and thus encouraging those other people to use Linux,
> > 	    leading to the same benefits as (1).
> > 
> > -- 
> > Fergus Henderson <fjh@cs.mu.oz.au>  |  "Binaries may die
> > WWW: < http://www.cs.mu.oz.au/~fjh >  |   but source code lives forever"
> > PGP: finger fjh@128.250.37.3        |     -- leaked Microsoft memo.
> > 
> > --
> > 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
> 
> 


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

Re: Cygwin participation threshold

[Lam Pui Yuen]

dear all,
sorry for this wrong reply mail.
Regs.

> done !
> 
> On Thu, 25 Feb 1999, Fergus Henderson wrote:
> 
> > On 24-Feb-1999, Christopher Faylor <cgf@cygnus.com> wrote:
> > > On Thu, Feb 25, 1999, Fergus Henderson wrote:
> > > >Yes, but you can write and distribute proprietry applications or even
> > > >proprietry kernel modules for Linux without paying anyone a license fee.
> > > >The same is not true for Cygwin (although it *was* true once, back around
> > > >version b16, when it was called gnu-win32).
> > > 
> > > True, but that is not the point.  I believe this whold thread started
> > > because I lamented the lack of people contributing directly to cygwin
> > > development.
> > 
> > You also asked why.  I believe that licensing may be one of the reasons why.
> > So I don't think my comment is beside the point.  You may disagree with me,
> > but I think we're talking about the same topic.
> > 
> > > The many contributors to the linux kernel do not do so
> > > because it is possible to develop proprietary code for linux.
> > 
> > That may not be their direct motivation, but I do think it is a
> > significant factor.  I think that if it were impossible to develop
> > proprietry code for Linux, then Linux would have a much smaller user
> > base, and there would be far fewer contributors to Linux.
> > 
> > > I don't consider companies who create proprietary kernel modules as
> > > contributing to linux development in any way.
> > 
> > The ability to create proprietry kernel modules is of little importance.
> > The ability to create proprietry applications is of much greater importance.
> > 
> > > Possibly they help indirectly
> > > by getting the word out about linux but that is a secondary and, IMO, very
> > > minor benefit.
> > 
> > I agree that the benefits are indirect and secondary.  However,
> > I don't think they should be ignored.
> > 
> > In addition to getting the word out, companies which develop proprietry
> > applications (or kernel modules) often also help
> > 
> > 	(1) by using Linux, and in the process sometimes reporting
> > 	    and/or fixing bugs in the kernel and/or the various
> > 	    open-source applications that are part of Linux; sometimes
> > 	    they will even add whole new features which are needed for
> > 	    their proprietry application (or module); and
> > 
> > 	(2) by providing software (or drivers) which other people need,
> > 	    and thus encouraging those other people to use Linux,
> > 	    leading to the same benefits as (1).
> > 
> > -- 
> > Fergus Henderson <fjh@cs.mu.oz.au>  |  "Binaries may die
> > WWW: < http://www.cs.mu.oz.au/~fjh >  |   but source code lives forever"
> > PGP: finger fjh@128.250.37.3        |     -- leaked Microsoft memo.
> > 
> > --
> > 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
> 
> 


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

Re: Cygwin participation threshold

[Lam Pui Yuen]

done !

On Thu, 25 Feb 1999, Fergus Henderson wrote:

> On 24-Feb-1999, Christopher Faylor <cgf@cygnus.com> wrote:
> > On Thu, Feb 25, 1999, Fergus Henderson wrote:
> > >Yes, but you can write and distribute proprietry applications or even
> > >proprietry kernel modules for Linux without paying anyone a license fee.
> > >The same is not true for Cygwin (although it *was* true once, back around
> > >version b16, when it was called gnu-win32).
> > 
> > True, but that is not the point.  I believe this whold thread started
> > because I lamented the lack of people contributing directly to cygwin
> > development.
> 
> You also asked why.  I believe that licensing may be one of the reasons why.
> So I don't think my comment is beside the point.  You may disagree with me,
> but I think we're talking about the same topic.
> 
> > The many contributors to the linux kernel do not do so
> > because it is possible to develop proprietary code for linux.
> 
> That may not be their direct motivation, but I do think it is a
> significant factor.  I think that if it were impossible to develop
> proprietry code for Linux, then Linux would have a much smaller user
> base, and there would be far fewer contributors to Linux.
> 
> > I don't consider companies who create proprietary kernel modules as
> > contributing to linux development in any way.
> 
> The ability to create proprietry kernel modules is of little importance.
> The ability to create proprietry applications is of much greater importance.
> 
> > Possibly they help indirectly
> > by getting the word out about linux but that is a secondary and, IMO, very
> > minor benefit.
> 
> I agree that the benefits are indirect and secondary.  However,
> I don't think they should be ignored.
> 
> In addition to getting the word out, companies which develop proprietry
> applications (or kernel modules) often also help
> 
> 	(1) by using Linux, and in the process sometimes reporting
> 	    and/or fixing bugs in the kernel and/or the various
> 	    open-source applications that are part of Linux; sometimes
> 	    they will even add whole new features which are needed for
> 	    their proprietry application (or module); and
> 
> 	(2) by providing software (or drivers) which other people need,
> 	    and thus encouraging those other people to use Linux,
> 	    leading to the same benefits as (1).
> 
> -- 
> Fergus Henderson <fjh@cs.mu.oz.au>  |  "Binaries may die
> WWW: < http://www.cs.mu.oz.au/~fjh >  |   but source code lives forever"
> PGP: finger fjh@128.250.37.3        |     -- leaked Microsoft memo.
> 
> --
> 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

Re: Cygwin participation threshold

[Fergus Henderson]

On 24-Feb-1999, Christopher Faylor <cgf@cygnus.com> wrote:
> On Thu, Feb 25, 1999, Fergus Henderson wrote:
> >Yes, but you can write and distribute proprietry applications or even
> >proprietry kernel modules for Linux without paying anyone a license fee.
> >The same is not true for Cygwin (although it *was* true once, back around
> >version b16, when it was called gnu-win32).
> 
> True, but that is not the point.  I believe this whold thread started
> because I lamented the lack of people contributing directly to cygwin
> development.

You also asked why.  I believe that licensing may be one of the reasons why.
So I don't think my comment is beside the point.  You may disagree with me,
but I think we're talking about the same topic.

> The many contributors to the linux kernel do not do so
> because it is possible to develop proprietary code for linux.

That may not be their direct motivation, but I do think it is a
significant factor.  I think that if it were impossible to develop
proprietry code for Linux, then Linux would have a much smaller user
base, and there would be far fewer contributors to Linux.

> I don't consider companies who create proprietary kernel modules as
> contributing to linux development in any way.

The ability to create proprietry kernel modules is of little importance.
The ability to create proprietry applications is of much greater importance.

> Possibly they help indirectly
> by getting the word out about linux but that is a secondary and, IMO, very
> minor benefit.

I agree that the benefits are indirect and secondary.  However,
I don't think they should be ignored.

In addition to getting the word out, companies which develop proprietry
applications (or kernel modules) often also help

	(1) by using Linux, and in the process sometimes reporting
	    and/or fixing bugs in the kernel and/or the various
	    open-source applications that are part of Linux; sometimes
	    they will even add whole new features which are needed for
	    their proprietry application (or module); and

	(2) by providing software (or drivers) which other people need,
	    and thus encouraging those other people to use Linux,
	    leading to the same benefits as (1).

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "Binaries may die
WWW: < http://www.cs.mu.oz.au/~fjh >  |   but source code lives forever"
PGP: finger fjh@128.250.37.3        |     -- leaked Microsoft memo.

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

Re: Cygwin participation threshold

[Christopher Faylor]

On Thu, Feb 25, 1999 at 12:51:48AM +1100, Fergus Henderson wrote:
>On 23-Feb-1999, Christopher Faylor <cgf@cygnus.com> wrote:
>> On Mon, Feb 22, 1999, Carl Zmola wrote:
>> >
>> >The fact that a company is in charge of 
>> >coordinating the efforts has an effect.
>> >
>> >In the past the main reason I didn't even investigate contributing is :
>> >Because of the feeling that contributions are unwanted, and that someone
>> >else is making money of of my work.
>> >
>> >After a little investigation, I found that these wern't valid concerns, but
>> >they are a first line of resistance.  
>> 
>> It is interesting that you felt this way at first.  I wonder if the reason
>> has anything to do with the name "Cygwin" which sounds so similar to "Cygnus".
>> 
>> The reason I am saying this is because hundreds of people have contributed to
>> the linux project and *many* companies make money from linux.
>
>Yes, but you can write and distribute proprietry applications or even
>proprietry kernel modules for Linux without paying anyone a license fee.
>The same is not true for Cygwin (although it *was* true once, back around
>version b16, when it was called gnu-win32).

True, but that is not the point.  I believe this whold thread started
because I lamented the lack of people contributing directly to cygwin
development.  The many contributors to the linux kernel do not do so
because it is possible to develop proprietary code for linux.

I don't consider companies who create proprietary kernel modules as
contributing to linux development in any way.  Possibly they help indirectly
by getting the word out about linux but that is a secondary and, IMO, very
minor benefit.

cf

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

Re: Cygwin participation threshold

[Fergus Henderson]

On 23-Feb-1999, Christopher Faylor <cgf@cygnus.com> wrote:
> On Mon, Feb 22, 1999, Carl Zmola wrote:
> >
> >The fact that a company is in charge of 
> >coordinating the efforts has an effect.
> >
> >In the past the main reason I didn't even investigate contributing is :
> >Because of the feeling that contributions are unwanted, and that someone
> >else is making money of of my work.
> >
> >After a little investigation, I found that these wern't valid concerns, but
> >they are a first line of resistance.  
> 
> It is interesting that you felt this way at first.  I wonder if the reason
> has anything to do with the name "Cygwin" which sounds so similar to "Cygnus".
> 
> The reason I am saying this is because hundreds of people have contributed to
> the linux project and *many* companies make money from linux.

Yes, but you can write and distribute proprietry applications or even
proprietry kernel modules for Linux without paying anyone a license fee.
The same is not true for Cygwin (although it *was* true once, back around
version b16, when it was called gnu-win32).

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "Binaries may die
WWW: < http://www.cs.mu.oz.au/~fjh >  |   but source code lives forever"
PGP: finger fjh@128.250.37.3        |     -- leaked Microsoft memo.

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

Re: Cygwin participation threshold

[Carl Zmola]

Christopher Faylor <cgf@cygnus.com> wrote:

> On Mon, Feb 22, 1999 at 11:30:59AM +0000, Carl Zmola wrote:
> >
> >In the past the main reason I didn't even investigate contributing is :
> >Because of the feeling that contributions are unwanted, and that someone
> >else is making money of of my work.
> >
> >After a little investigation, I found that these wern't valid concerns, but
> >they are a first line of resistance.  
> 
> It is interesting that you felt this way at first.  I wonder if the reason
> has anything to do with the name "Cygwin" which sounds so similar to "Cygnus".

Quite possibly. Also in the past, if you went to the cygnus web site, you couldn't
get to the 'free' cygwin tools.  That left a bad taste in my mouth.

> The reason I am saying this is because hundreds of people have contributed to
> the linux project and *many* companies make money from linux.

That is quite true.  The name could be part of the problem, but I do know
who cygnus is because of the name.

 

Carl 
zmola@campbellsci.com

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

Re: Cygwin participation threshold

[Christopher Faylor]

On Wed, Feb 24, 1999 at 11:35:42AM +0000, Carl Zmola wrote:
>Christopher Faylor <cgf@cygnus.com> wrote:
>
>> On Mon, Feb 22, 1999 at 11:30:59AM +0000, Carl Zmola wrote:
>> >
>> >In the past the main reason I didn't even investigate contributing is :
>> >Because of the feeling that contributions are unwanted, and that someone
>> >else is making money of of my work.
>> >
>> >After a little investigation, I found that these wern't valid concerns, but
>> >they are a first line of resistance.  
>> 
>> It is interesting that you felt this way at first.  I wonder if the reason
>> has anything to do with the name "Cygwin" which sounds so similar to "Cygnus".
>
>Quite possibly. Also in the past, if you went to the cygnus web site, you couldn't
>get to the 'free' cygwin tools.  That left a bad taste in my mouth.

When was this?  There has been a button on the main site for some time.
I can't say for sure, but I believe that if you were having problems
accessing the cygwin page it must have been an oversight by our
webmaster.

>> The reason I am saying this is because hundreds of people have contributed to
>> the linux project and *many* companies make money from linux.
>
>That is quite true.  The name could be part of the problem, but I do know
>who cygnus is because of the name.

Yup.  It's likely many people Cygwin == Cygnus.

cgf

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

Re: Cygwin participation threshold

[Carl Zmola]

> 
> When was this?  There has been a button on the main site for some time.
> I can't say for sure, but I believe that if you were having problems
> accessing the cygwin page it must have been an oversight by our
> webmaster.

Oh 2 years maybe? A long time ago.  

> Yup.  It's likely many people Cygwin == Cygnus.

For better or for worse. 
 

Carl 
zmola@campbellsci.com

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

Re: Cygwin participation threshold

[Carl Zmola]

> 
> When was this?  There has been a button on the main site for some time.
> I can't say for sure, but I believe that if you were having problems
> accessing the cygwin page it must have been an oversight by our
> webmaster.

Oh 2 years maybe? A long time ago.  

> Yup.  It's likely many people Cygwin == Cygnus.

For better or for worse. 
 

Carl 
zmola@campbellsci.com

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

Re: Cygwin participation threshold

[Christopher Faylor]

On Wed, Feb 24, 1999 at 11:35:42AM +0000, Carl Zmola wrote:
>Christopher Faylor <cgf@cygnus.com> wrote:
>
>> On Mon, Feb 22, 1999 at 11:30:59AM +0000, Carl Zmola wrote:
>> >
>> >In the past the main reason I didn't even investigate contributing is :
>> >Because of the feeling that contributions are unwanted, and that someone
>> >else is making money of of my work.
>> >
>> >After a little investigation, I found that these wern't valid concerns, but
>> >they are a first line of resistance.  
>> 
>> It is interesting that you felt this way at first.  I wonder if the reason
>> has anything to do with the name "Cygwin" which sounds so similar to "Cygnus".
>
>Quite possibly. Also in the past, if you went to the cygnus web site, you couldn't
>get to the 'free' cygwin tools.  That left a bad taste in my mouth.

When was this?  There has been a button on the main site for some time.
I can't say for sure, but I believe that if you were having problems
accessing the cygwin page it must have been an oversight by our
webmaster.

>> The reason I am saying this is because hundreds of people have contributed to
>> the linux project and *many* companies make money from linux.
>
>That is quite true.  The name could be part of the problem, but I do know
>who cygnus is because of the name.

Yup.  It's likely many people Cygwin == Cygnus.

cgf

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

Re: Cygwin participation threshold

[Carl Zmola]

Christopher Faylor <cgf@cygnus.com> wrote:

> On Mon, Feb 22, 1999 at 11:30:59AM +0000, Carl Zmola wrote:
> >
> >In the past the main reason I didn't even investigate contributing is :
> >Because of the feeling that contributions are unwanted, and that someone
> >else is making money of of my work.
> >
> >After a little investigation, I found that these wern't valid concerns, but
> >they are a first line of resistance.  
> 
> It is interesting that you felt this way at first.  I wonder if the reason
> has anything to do with the name "Cygwin" which sounds so similar to "Cygnus".

Quite possibly. Also in the past, if you went to the cygnus web site, you couldn't
get to the 'free' cygwin tools.  That left a bad taste in my mouth.

> The reason I am saying this is because hundreds of people have contributed to
> the linux project and *many* companies make money from linux.

That is quite true.  The name could be part of the problem, but I do know
who cygnus is because of the name.

 

Carl 
zmola@campbellsci.com

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

Re: Cygwin participation threshold

[Christopher Faylor]

On Mon, Feb 22, 1999 at 11:30:59AM +0000, Carl Zmola wrote:
>
>> DJGPP has a much higher threshold (it's much more complicated), but
>> there are far more people contributing to djgpp than to cygwin.  If
>> anyone can figure out *why*, let us know! ;-) I think it's social -
>> djgpp contributors just know that they'll get a friendly reception to
>> their contributions, good or bad, so they aren't as hesitant to send
>> stuff in.
>
>That could be part of it.  The fact that a company is in charge of 
>coordinating the efforts has an effect.
>
>In the past the main reason I didn't even investigate contributing is :
>Because of the feeling that contributions are unwanted, and that someone
>else is making money of of my work.
>
>After a little investigation, I found that these wern't valid concerns, but
>they are a first line of resistance.  

It is interesting that you felt this way at first.  I wonder if the reason
has anything to do with the name "Cygwin" which sounds so similar to "Cygnus".

The reason I am saying this is because hundreds of people have contributed to
the linux project and *many* companies make money from linux.

cgf

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

Re: Cygwin participation threshold

[Carl Zmola]

> DJGPP has a much higher threshold (it's much more complicated), but
> there are far more people contributing to djgpp than to cygwin.  If
> anyone can figure out *why*, let us know! ;-) I think it's social -
> djgpp contributors just know that they'll get a friendly reception to
> their contributions, good or bad, so they aren't as hesitant to send
> stuff in.

That could be part of it.  The fact that a company is in charge of 
coordinating the efforts has an effect.

In the past the main reason I didn't even investigate contributing is :
Because of the feeling that contributions are unwanted, and that someone
else is making money of of my work.

After a little investigation, I found that these wern't valid concerns, but
they are a first line of resistance.  

Carl 
zmola@campbellsci.com

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

Cygwin participation threshold

[DJ Delorie]

> Hopefully, that's what you wanted - to give people a nice tool,

I think it would be more accurate to replace "give" with "share with".

As a bit of history, Cygnus had a purely business reason to create
cygwin.  Doing so let us host our tools on 95/NT platforms, which
meant more customers (i.e. more money).  AFAIK, releasing cygwin to
the net had two reasons: the first philosophical, in that we like to
share; and the second practical, in that the more people using cygwin
the more paid support contracts we'll get.

>     But when someone wants to fix or add something to cygwin, here
> comes another problem - it's high enough threshold to be able to do
> so. Even higher threshold to make it acceptable for inclusion back.

DJGPP has a much higher threshold (it's much more complicated), but
there are far more people contributing to djgpp than to cygwin.  If
anyone can figure out *why*, let us know! ;-) I think it's social -
djgpp contributors just know that they'll get a friendly reception to
their contributions, good or bad, so they aren't as hesitant to send
stuff in.

> By this I mean whole technology issues - not Cygwin technology, I
> call it GNU technology - configuration/setup methods, coding styles
> (not just mere conventions for identifier naming / block
> indentation, but modularization conventions, from source modules
> thru libs to executables, etc.) And all that are obstacles to
> contributing.

Even so, I'd rather people contribute what they can instead of just
sulking off in a corner and getting nowhere.  We're not going to laugh
at you for bad style (I hope).  More likely, we'll explain how to
change what you've got to work better with what we've got (it's called
"learning").  Cooperation is a two-way street!  If you're willing to
do *anything*, we'll probably meet you half-way.

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

Re[2]: Cygwin B20 - fseek under gcc fails to reposition on text files

[Paul Sokolovsky]

Hello Christopher,

Christopher Faylor <cgf@cygnus.com> wrote:

[]

CF> Currently, Corinna, Mumit, and a couple of other people are the only
CF> outside contributers to the project.  Everyone else seems to be in
CF> "Cygwin doesn't work the way I think it should when I run program X.
CF> Here's the error message." mode.

    With other opinions expressed in this thread, I'd like to add
following: it's quite understood that most people are in that mode -
they are using cygwin as their tool, something like car, and are not
concerned, or able to, how it's functioning. Hopefully, that's what
you wanted - to give people nice tool, to keep balance with such toys
like msvc, delphi, etc.

    But when someone wants to fix or add something to cygwin, here
comes another problem - it's high enough threshold to be able to do
so. Even higher threshold to make it acceptable for inclusion back.
By this I mean whole technology issues - not Cygwin technology, I call
it GNU technology - configuration/setup methods, coding styles (not
just mere conventions for identifier naming / block indentation, but
modularization conventions, from source modules thru libs to
executables, etc.) And all that are obstacles to contributing. But of
course I don't say that's bad - there must be order and who willing to
contribute should know and accept it, but it requires time, and
potential contributors may not have it, just the same as developers
may not ;-) .

    Ok, I turn down considering problems of open-source
development, this is hardly appropriate place for it.

CF> I'm collecting the error messages and hope to investigate problems but
CF> the reality is that this is a volunteer effort for DJ and me.  Our
CF> real jobs don't offer much time for tracking down net problems.

CF> -chris


Best regards,
 Paul                            mailto:paul-ml@is.lg.ua


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

Re: Cygwin B20 - fseek under gcc fails to reposition on text files

[Christopher Faylor]

On Thu, Feb 18, 1999 at 06:38:46PM +0200, Paul Sokolovsky wrote:
>    Bad thing is that issue very minor. People might don't care what
>line-endings text files have, they might don't care that there's
>notepad and bat files. And when their favorite vi chokes on that \r at
>the end (or beginning? ;-) ) of line they might teach him chop it -
>after all, that's not notepad. But they might think that wrapping each
>command piping binary files in shell script setting CYGWIN (having
>spent some nice time trying to understand why their files are
>corrupted and asking maillist why this bug) is too awkward.

Actually, as far as pipes are concerned, they default to binmode
unless overridden by CYGWIN so this should not be an issue.

>   Of course, that far too imaganable picture, just like my previous
>massage has, just like several years ago cygwin itself was only
>imaganable. I don't believe that things enpictured by me will be, or
>even should be, done to cygwin. I just wanted to hyperbolize it,
>showing that changing itself is not an edge alternative, all
>determained by ammount of changes, and there might be the golden mean,
>exactly what you'll do. (That's just because I have a ho that Cygnus
>guys quite conservative - I remember Christopher Faylor's hesitating
>in cygwin-developer whether correcting bug won't break user (or
>customer) code. Maybe you, Corinna, as leading contributor, and DJ, as
>author of alternative approach, and working for Cygnus, have other
>opinions).

I have no idea what, specifically, you are referring to but it is
interesting that you find it "quite conservative" to consider caring
about breaking somebody's code.  You are probably referring to my
soliciting of opinions on the subject of breaking API compatibility
with a new cygwin DLL.  This was obviously a subject which deserved
careful consideration and it was something that I was willing to do.
In fact, it is something that *will* occur in a future release.

Regardless, if you look at the ChangeLog in the last year, you'll find
that I'm the author of a lot of radical changes in Cygwin.

I am not at all opposed to the idea of somebody fixing ftell/fseek
to work as Microsoft has documented them or as DJGPP has currently
implemented things.  I've written a stdio layer myself and I know
that this is not a trivial undertaking, though.  Certainly no
one at Cygnus has the time right now to undertake this.

Currently, Corinna, Mumit, and a couple of other people are the only
outside contributers to the project.  Everyone else seems to be in
"Cygwin doesn't work the way I think it should when I run program X.
Here's the error message." mode.

I'm collecting the error messages and hope to investigate problems but
the reality is that this is a volunteer effort for DJ and me.  Our
real jobs don't offer much time for tracking down net problems.

-chris

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

Re[2]: Cygwin B20 - fseek under gcc fails to reposition on text files

[Paul Sokolovsky]

Hello Corinna,

Corinna Vinschen <corinna.vinschen@cityweb.de> wrote:

>>     So, for more than twenty years MS maintains myth about "special
>> format" of text files of their systems. It's hardly believable. Since

CV> The best way would be to throw away and ignore any newline with
CV> more than one single character.

    Yes, and bad thing is that people came say, from Unix, and don't knowing
that here text files are special, but constantly getting binary file
corruptions when filtering gifs, piping gzips, etc. may think that way is
right ;-(

CV> But let's get serious.

CV> IMHO, above all text file processing should be done according to the
CV> underlying OS and it's vendor, also if this is wretched.

    Bad thing is that issue very minor. People might don't care what
line-endings text files have, they might don't care that there's
notepad and bat files. And when their favorite vi chokes on that \r at
the end (or beginning? ;-) ) of line they might teach him chop it -
after all, that's not notepad. But they might think that wrapping each
command piping binary files in shell script setting CYGWIN (having
spent some nice time trying to understand why their files are
corrupted and asking maillist why this bug) is too awkward.

   Of course, that far too imaganable picture, just like my previous
massage has, just like several years ago cygwin itself was only
imaganable. I don't believe that things enpictured by me will be, or
even should be, done to cygwin. I just wanted to hyperbolize it,
showing that changing itself is not an edge alternative, all
determained by ammount of changes, and there might be the golden mean,
exactly what you'll do. (That's just because I have a ho that Cygnus
guys quite conservative - I remember Christopher Faylor's hesitating
in cygwin-developer whether correcting bug won't break user (or
customer) code. Maybe you, Corinna, as leading contributor, and DJ, as
author of alternative approach, and working for Cygnus, have other
opinions).

   But there still that idea - there maybe niche that cygwin doesn't
fill - to be more unixish despite be less winnish.

CV> The second choice has the advantage, to be easy to implement.

CV> The third choice should be implemented, if s.o. has nothing important
CV> to do.

CV> Regards,
CV> Corinna

    Thanks for not taking previous text as profanity, that's was just rebellion
humoresqe, just forgot adding trailing disclaimer ;-)


Best regards,
 Paul                            mailto:paul-ml@is.lg.ua


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

Re: Cygwin B20 - fseek under gcc fails to reposition on text files

[Corinna Vinschen]

Paul Sokolovsky wrote:
>     So, for more than twenty years MS maintains myth about "special
> format" of text files of their systems. It's hardly believable. Since
> my old XT I quite nicely handled any text files - be they Unix \xa,
> Mac \xd, or "dos" \xd\xa . So there's nothing special to talk about
> "special" format of text files. Most tools available handled any type,
> and conversion between formats was quite feasible. With win32, such
> problems are ceased at all - I don't have no line endings problems, no
> encoding problems, even that unicode seams to be here.

As a matter of fact: Peter's c example, which opens this thread, does
not work with VC++, if the newline is not \r\n. Look into the source
of M$-ftell(), it can't work.

The best way would be to throw away and ignore any newline with
more than one single character.

But let's get serious.

IMHO, above all text file processing should be done according to the
underlying OS and it's vendor, also if this is wretched.

The second choice has the advantage, to be easy to implement.

The third choice should be implemented, if s.o. has nothing important
to do.

Regards,
Corinna


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

Re[2]: Cygwin B20 - fseek under gcc fails to reposition on text files

[Paul Sokolovsky]

Hello Corinna,

Corinna Vinschen <corinna.vinschen@cityweb.de> wrote:

[]

CV> We have three possible choices:

CV> 1st: We are not performing the same errors as M$. We do our own, so we let
CV>      it as it is.

CV> 2nd: M$-compatible errors, so we let ftell count \n, too. This would result
CV>      in more often correct telling.

CV> 3rd: The full stdio code in newlib has to be changed. The buffer is used
CV>      anyway in binary mode, every call has to use new counting and
CV>      translation methods than the current one.
CV>      Because this has to be done _very_ cautious, it's a long time change.

CV> For the near future, I would prefer the second choice. Other opinions?

    Let me support 3rd way, in rather flamy passages, however.

    So, for more than twenty years MS maintains myth about "special
format" of text files of their systems. It's hardly believable. Since
my old XT I quite nicely handled any text files - be they Unix \xa,
Mac \xd, or "dos" \xd\xa . So there's nothing special to talk about
"special" format of text files. Most tools available handled any type,
and conversion between formats was quite feasible. With win32, such
problems are ceased at all - I don't have no line endings problems, no
encoding problems, even that unicode seams to be here.

   And here we come to most interesting questions - that fact that MS
maintains aforementioned myth is not surprising, but that myth is
carefully maintained by outside crew too! Just listen to those GNUers
telling us that text files here are "special" and they must dirty
workaround that! Just see peoples advocating data stream corruption on
most basic system level!

   But what if stop that play and acknowledge that some guys have done
quite well and it's useless to try to not notice that. \r\n textfiles
should be handled properly where they belong - e.g. in textutils, but
never in core system, leading just to corruption.

   So, what I argue:

1. Text/binary file notion on most basic, POSIX level should be
   abandoned.
2. That has nothing to do with stdio level - since default accessors for
   that level are single-character oriented, it doesn't hurt much
   stuffing single test there.

(Note that this indeed DJ Delorie's idea as of DJGPP lib, pushed further
to exterminating textuality on POSIX level at all)

3. All stuff working with textfiles and using POSIX level either should
   be taught accept any line-endings or reimplented in stdio.

4. Until then, there're fromdos/todos filters.


   And finally, from where all this stuff might be originated - it may
be done whatever wanted, but if, when writing to console we get clobbered
output without carrage returns, it doesn't cost a cent. That's where
myth of win32 speciality breaks down - Win32 console, as any other
console in cooked mode (Linux, say) performs implicit cr after lf,
when there's no explicit.

   Just run following (tested only on Win95/Win95OSR2 to be honest):

--------
#include <windows.h>

char str[]="\nline1\nline2\nline3\n";

void main()
{
  DWORD dummy;
  WriteFile(STD_OUTPUT_HANDLE,str,sizeof(str)-1,&dummy,NULL);
  WriteFile(STD_ERROR_HANDLE,str,sizeof(str)-1,&dummy,NULL);
}
--------


CV> Regards,
CV> Corinna


Best regards,
 Paul                            mailto:paul-ml@is.lg.ua


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

Re: Cygwin B20 - fseek under gcc fails to reposition on text files

[Corinna Vinschen]

Christopher Faylor wrote:
> 
> On Tue, Feb 16, 1999 at 07:41:34AM -0800, Earnie Boyd wrote:
> >
> >Here is the "Microsoft VC++ Run-Time Library Reference" quote:
> >
> >For streams opened in text mode, fseek has limited use, because
> >carriage return-linefeed translations can cause fseek to produce
> >unexpected results.  The only fseek operations guaranteed to work on
> >streams opened in text mode are:
> >
> >* Seeking with an offset of 0 relative to any of the origin values.
> >
> >* Seeking from the beginning of the file with an offset value returned
> >from a call to ftell.
> >
> >Also in text mode, CTRL+Z is interpreted as an end-of-file character
> >[...]

This is the _documentation_ of M$. In fact their code doesn't do the right
thing! As the ftell of newlib, it works without special calls of the
underlying OS, only calls to `_lseek()' are performed.  The only difference
between M$ and newlib is, that M$ performs additional counting of \n in
case of text file processing. It's done in the already translated buffer,
so the result is crap, as in newlib. Only their hit count is better.

> >Based on the documentation then I'll have to agree that your programs
> >isn't behaving as the documentation states that it should.  But, which
> >is wrong, fseek or ftell?
> 
> This does sound like a bug.  We'll try to look into this, time permitting.
> 
> If anyone else wants to take a stab at this (Corinna?) I'd be very grateful.

We have three possible choices:

1st: We are not performing the same errors as M$. We do our own, so we let
     it as it is.

2nd: M$-compatible errors, so we let ftell count \n, too. This would result
     in more often correct telling.

3rd: The full stdio code in newlib has to be changed. The buffer is used
     anyway in binary mode, every call has to use new counting and
     translation methods than the current one.
     Because this has to be done _very_ cautious, it's a long time change.

For the near future, I would prefer the second choice. Other opinions?

Regards,
Corinna


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

Re: Cygwin B20 - fseek under gcc fails to reposition on text files

[Christopher Faylor]

On Tue, Feb 16, 1999 at 07:41:34AM -0800, Earnie Boyd wrote:
>
>Ok I appoligize.
>
>Here is the "Microsoft VC++ Run-Time Library Reference" quote:
>
>For streams opened in text mode, fseek has limited use, because
>carriage return-linefeed translations can cause fseek to produce
>unexpected results.  The only fseek operations guaranteed to work on
>streams opened in text mode are:
>
>* Seeking with an offset of 0 relative to any of the origin values.
>
>* Seeking from the beginning of the file with an offset value returned
>from a call to ftell.
>
>Also in text mode, CTRL+Z is interpreted as an end-of-file character
>on input.  In files opened for reading/writing, fopen and all related
>routines check for a CTRL+Z at the end of the file and remove it if
>possible.  This is done because using fseek and ftell to move within
>an file that ends in CTRL+Z may cause fseek to behave improperly near
>the end of the file.
>
>---
>
>Based on the documentation then I'll have to agree that your programs
>isn't behaving as the documentation states that it should.  But, which
>is wrong, fseek or ftell?
>
>Sorry for speaking out of line,

This does sound like a bug.  We'll try to look into this, time permitting.

If anyone else wants to take a stab at this (Corinna?) I'd be very grateful.

-chris

RE: Cygwin B20 - fseek under gcc fails to reposition on text files

[Earnie Boyd]

Ok I appoligize.

Here is the "Microsoft VC++ Run-Time Library Reference" quote:

For streams opened in text mode, fseek has limited use, because
carriage return-linefeed translations can cause fseek to produce
unexpected results.  The only fseek operations guaranteed to work on
streams opened in text mode are:

* Seeking with an offset of 0 relative to any of the origin values.

* Seeking from the beginning of the file with an offset value returned
from a call to ftell.

Also in text mode, CTRL+Z is interpreted as an end-of-file character
on input.  In files opened for reading/writing, fopen and all related
routines check for a CTRL+Z at the end of the file and remove it if
possible.  This is done because using fseek and ftell to move within
an file that ends in CTRL+Z may cause fseek to behave improperly near
the end of the file.

---

Based on the documentation then I'll have to agree that your programs
isn't behaving as the documentation states that it should.  But, which
is wrong, fseek or ftell?

Sorry for speaking out of line,
Earnie.

---Peter Kabal <kabal@ece.mcgill.ca> wrote:
>
> I did.  I quote from Harbison and Steele, Fourth edition, p 353.
> 
> "The following, more limited set of calls is permitted on text streams
> by ISO C:
> 
> fseek (stream, 0L, SEEK_SET)
> fseek (stream, 0L, SEEK_CUR)
> fseek (stream, 0L, SEEK_END)
> fseek (stream, 0L, ftell_pos, SEEK_SET)  at a position returned by a
>     previous call to ftell for stream.
> "
> 
> I <did> read the docs about "text mode processing"!  Your comment was
> unwarranted and warrants an apology.
> 
> > -----Original Message-----
> > From: Earnie Boyd [ mailto:earnie_boyd@yahoo.com ]
> > Sent: February 16, 1999 8:28 AM
> > To: kabal@ece.mcgill.ca
> > Cc: cygwin users
> > Subject: Re: Cygwin B20 - fseek under gcc fails to reposition on
text
> > files
> > 
> > 
> > 
> > You need to read the docs about "text mode processing".  This is
> > exactly the expected behavior.  If you're going to use these
functions
> > then you must process in binary mode.
> > 
> > Regards,
> > Earnie.
> > 
> > ---Peter Kabal <kabal@ECE.McGill.CA> wrote:
> > >
> > > Consider a text file (CR/LF line endings).  Read a line, save the
> > > current position, seek to end-of-file, seek to the saved position,
> > > read a line.  The second read does not return the second line of
> > > the file.
> > > 
> > > A shell script which tests the problem is included below:
> > >
---------------------------------------------------------------------
> > > #!/bin/sh
> > > #
> > > # Test fseek bug
> > > # On Cygwin 20.1, a file is not correctly repositioned after
seeking
> > to the
> > > # end-of-file on a text file (CR/LF line endings).
> > > 
> > > cat > tfrepos.c << EoF
> > > #include <stdio.h>
> > > int main (int argc, char *argv[])
> > > {
> > >   FILE *fp;
> > >   long int pos, size;
> > >   char line[200];
> > >   char *p;
> > > 
> > >   fp = fopen (argv[1], "r");
> > >   p = fgets (line, 200, fp);
> > >   printf (" Line: %s", p);
> > > 
> > >   pos = ftell (fp);
> > >   fseek (fp, 0L, SEEK_END);
> > >   fseek (fp, pos, SEEK_SET);
> > > 
> > >   p = fgets (line, 200, fp);
> > >   printf (" Line: %s", p);
> > > 
> > >   return 0;
> > > }
> > > EoF
> > > 
> > > # Run the test program with the c-program as input
> > > gcc tfrepos.c -o tfrepos
> > > ./tfrepos tfrepos.c
> > > 
> > > # Clean up
> > > rm -f tfrepos tfrepos.c
> > >
---------------------------------------------------------------------
> > > 
> > > Peter Kabal  kabal@ECE.McGill.CA
> > > Dept. Electrical & Computer Eng.
> > > McGill University 
> > > 
> > 
> > _________________________________________________________
> > DO YOU YAHOO!?
> > Get your free @yahoo.com address at http://mail.yahoo.com
> > 
> > 
> 

_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: Cygwin participation threshold

[Suhaib M. Siddiqi]

>
>> Hopefully, that's what you wanted - to give people a nice tool,
>
>I think it would be more accurate to replace "give" with "share with".
>
>As a bit of history, Cygnus had a purely business reason to create
>cygwin.  Doing so let us host our tools on 95/NT platforms, which
>meant more customers (i.e. more money).  AFAIK, releasing cygwin to
>the net had two reasons: the first philosophical, in that we like to
>share; and the second practical, in that the more people using cygwin
>the more paid support contracts we'll get.


What about third party products. For example PGI Workstation comes
bundle with
Cygwin. It uses better commercial compilers and one has a choice to use
GCC/G77
or PGCC/PG77/PGF90 etc.  Who gets the *paid support* in that case?
I am just a bit curious!

Regards
Suhaib




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

Re: Cygwin participation threshold

[DJ Delorie]

> What about third party products. For example PGI Workstation comes
> bundle with Cygwin.  Who gets the *paid support* in that case?

In cases where companies write software that depends on cygwin, such
as the example you give, the potential customer for Cygnus would be
that company, for two reasons: (1) they would need a commercial
license for cygwin, and (2) they would want a support contract to make
sure the cygwin they include in their product doesn't make their
product look bad by having bugs.

It would be unrealistic to expect each individual user of that
software to come to Cygnus for support.  More likely, they'd go to the
package producer, who may have solutions specific to their
software/cygwin bundling, such as a custom-fixed dll.

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

Re: Cygwin participation threshold

[DJ Delorie]

> What about third party products. For example PGI Workstation comes
> bundle with Cygwin.  Who gets the *paid support* in that case?

In cases where companies write software that depends on cygwin, such
as the example you give, the potential customer for Cygnus would be
that company, for two reasons: (1) they would need a commercial
license for cygwin, and (2) they would want a support contract to make
sure the cygwin they include in their product doesn't make their
product look bad by having bugs.

It would be unrealistic to expect each individual user of that
software to come to Cygnus for support.  More likely, they'd go to the
package producer, who may have solutions specific to their
software/cygwin bundling, such as a custom-fixed dll.

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

Re: Cygwin participation threshold

[Suhaib M. Siddiqi]

>
>> Hopefully, that's what you wanted - to give people a nice tool,
>
>I think it would be more accurate to replace "give" with "share with".
>
>As a bit of history, Cygnus had a purely business reason to create
>cygwin.  Doing so let us host our tools on 95/NT platforms, which
>meant more customers (i.e. more money).  AFAIK, releasing cygwin to
>the net had two reasons: the first philosophical, in that we like to
>share; and the second practical, in that the more people using cygwin
>the more paid support contracts we'll get.


What about third party products. For example PGI Workstation comes
bundle with
Cygwin. It uses better commercial compilers and one has a choice to use
GCC/G77
or PGCC/PG77/PGF90 etc.  Who gets the *paid support* in that case?
I am just a bit curious!

Regards
Suhaib




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

Re: Cygwin participation threshold

[Suhaib M. Siddiqi]

>
>> Their product does not depend on Cygwin, but it does provide
>> switches to use Cygwin headers and libraries for porting purposes.
>> The fact is they got a commercial F77 and F90 which can use Cygwin
>> headers and libraries, makes it a really attractive product.
>
>In that case, it still acts to mkae cygwin more popular, which
>hopefully means that more people will use it in general, etc.
>

Absolutely true.  I guess PGi is the only product right now which offers
a
Cygwin compability, with F77/F90 and HPF for single and multiprocessors
machines.

That was the reason i decided to go for it.  To be honest G77 still lags
behind a normal F77 compiler.


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

Re: Cygwin participation threshold

[Suhaib M. Siddiqi]

>
>> Their product does not depend on Cygwin, but it does provide
>> switches to use Cygwin headers and libraries for porting purposes.
>> The fact is they got a commercial F77 and F90 which can use Cygwin
>> headers and libraries, makes it a really attractive product.
>
>In that case, it still acts to mkae cygwin more popular, which
>hopefully means that more people will use it in general, etc.
>

Absolutely true.  I guess PGi is the only product right now which offers
a
Cygwin compability, with F77/F90 and HPF for single and multiprocessors
machines.

That was the reason i decided to go for it.  To be honest G77 still lags
behind a normal F77 compiler.


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

Re: Cygwin participation threshold

[Tom St Denis]

I agree, at first I was hesitant to try it, cause I thought it was
copyrighted, or whatever.... Anyways, I am not a big software
developer, but I thought I would give it a try.

Thanks to all who have contributed.  If I ever have the time,
patience, and enough know-how I will contrib something.  But I  doubt
that will happen any time soon.

Tom
+--------------------------------------------------------------------------+
| The coolest site for free home pages, email, chat, e-cards, movie info.. |
|               http://www.goplay.com - it's time to Go Play!              |
+--------------------------------------------------------------------------+

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

Re: Cygwin participation threshold

[Tom St Denis]

I agree, at first I was hesitant to try it, cause I thought it was
copyrighted, or whatever.... Anyways, I am not a big software
developer, but I thought I would give it a try.

Thanks to all who have contributed.  If I ever have the time,
patience, and enough know-how I will contrib something.  But I  doubt
that will happen any time soon.

Tom
+--------------------------------------------------------------------------+
| The coolest site for free home pages, email, chat, e-cards, movie info.. |
|               http://www.goplay.com - it's time to Go Play!              |
+--------------------------------------------------------------------------+

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

Re: Cygwin participation threshold

[Steve Morris]

Christopher Faylor writes:
 > It is interesting that you felt this way at first.  I wonder if the reason
 > has anything to do with the name "Cygwin" which sounds so similar to "Cygnus".
 > 
 > The reason I am saying this is because hundreds of people have contributed to
 > the linux project and *many* companies make money from linux.

Actually I think you've hit on a major issue. Even though Cygnus makes
cygwin available as sourceware it is obviously a Cygnus
product. Cygnus controls the feature set. Design decisions are made by
Cygnus. People can contribute but Cygnus is the final arbitor on
design decisions and even code style.

With gcc it is different. Cygnus is the official maintainer but the
perception is that Cygnus acts more as a custodian for FSF and the
free software community. FSF owns the copyright. Redhat is another
example. Redhat doesn't own Linux. RPM is the only significant thing
that RedHat copyrights and even that makes people nervous.

On the other hand Cygwin is obviously branded. Even the mailing list
is controlled by Cygnus. The developers mailing list access is
restricted by Cygnus engineers. The official Cygwin web page is
controlled by Cygnus. The bug list is an internal Cygnus system.

Psychologically it doesn't make me feel like I would count as much as
a Cygnus engineer if I contributed. Helping Cygnus with their free
software product doesn't have the same cachet as helping Linus Torvald
with his. Linus stands first among equals partners. How can I feel
like an equal partner to a company?

I guess the issue is not companies making money on free
software. Instead the issue is companies being perceived as
controlling the software development.

Tcl is entering the same delicate state. With Ousterhout starting
Scriptics which is now the official distributor of the release people
are beginning to get nervous. The question always hovers "will
Scriptics pull Tcl in and make it a commercial product?" TclPro is
$1000 a seat. What if new development or the good extensions only
appear in TclPro? Nobody begrudges Ousterhout's right to make money on
his major contribution but still there is anxiety.

I don't envy Cygnus as it tries to walk this tightrope.

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

Re: Cygwin participation threshold

[Christopher Faylor]

On Wed, Feb 24, 1999 at 09:59:16AM -0500, Steve Morris wrote:
>Christopher Faylor writes:
> > It is interesting that you felt this way at first.  I wonder if the reason
> > has anything to do with the name "Cygwin" which sounds so similar to "Cygnus".
> > 
> > The reason I am saying this is because hundreds of people have contributed to
> > the Linux project and *many* companies make money from Linux.
>
>Actually I think you've hit on a major issue. Even though Cygnus makes
>cygwin available as sourceware it is obviously a Cygnus
>product. Cygnus controls the feature set. Design decisions are made by
>Cygnus. People can contribute but Cygnus is the final arbiter on
>design decisions and even code style.

This is very similar to the way Linux was developed except that in the
Linux case Linus Torvalds was the final arbiter.  In the Cygnus case
the final arbiter was first Steve Chamberlain, then Geoffrey Noer, and
now me.  There's still one person involved in decisions but input from
external developers is both solicited and appreciated.

>With gcc it is different. Cygnus is the official maintainer but the
>perception is that Cygnus acts more as a custodian for FSF and the
>free software community. FSF owns the copyright. Redhat is another
>example. Redhat doesn't own Linux. RPM is the only significant thing
>that RedHat copyrights and even that makes people nervous.

Of course, gcc wasn't initially developed by Cygnus either.  One of the
reasons behind the formation of EGCS was that there were a number of
contributors besides Cygnus who felt that they weren't able to contribute
to GNU's gcc project.  This is entirely a different situation from Cygwin.

Although RedHat doesn't own Linux, it obviously does make money from its
sale.  This means that if you contribute some nifty code to Linux you
also might benefit RedHat.  I don't see how the ownership issue matters
here.  Somebody is still making money from your work whether it's Cygnus
or RedHat.

>On the other hand Cygwin is obviously branded. Even the mailing list
>is controlled by Cygnus. The developers mailing list access is
>restricted by Cygnus engineers. The official Cygwin web page is
>controlled by Cygnus. The bug list is an internal Cygnus system.

All this is true of EGCS, too, isn't it?

The developers mailing list is supposed to be open only to people who
are willing to contribute to the development of cygwin.  If the rest of
the (developers) mailing list thinks that that is too restrictive a goal
then I'd be happy to open it up.  We have maintained cygwin-developers
as a closed list to try to limit discussions to actual development
issues.

>Psychologically it doesn't make me feel like I would count as much as
>a Cygnus engineer if I contributed. Helping Cygnus with their free
>software product doesn't have the same cachet as helping Linus Torvald
>with his. Linus stands first among equals partners. How can I feel
>like an equal partner to a company?

Have you actually read the linux-dev-kernel?  I don't think that
net contributors would rank Linus "first among equal partners".  Linus
is a semi-benign despot.  He accepts patches from people but he always
has the right of refusing patches and he does reject patches often.

Patches from people like Alan Cox or David Miller or Stephen Tweedie are
likely to be given the "fast track" into the main development kernel.
Patches from you or me are likely to be ignored unless we can really
prove our technical competence.

For a long time, this same model was also used by Larry Wall for perl.
In fact, it didn't really break down until Larry suffered health
problems.  Now perl has a number of people contributing code to
an volunteer maintainer who acts as an arbiter of what gets in and what
doesn't.  But in case of deadlock, Larry's word always trumps everyone.

I think that this model is actually what makes these packages a
success.  They have one person at the top with a clear vision of where the
product is supposed to be going and what it is supposed to be doing.

This is what we're trying to do with Cygwin too, with, so far, limited
success.  Cygwin does have it's contributors and I'm *very* grateful for
the time that they've put into making it better.  Some of the major
Cygwin subsystems have, in fact, been contributed by people who managed
to get beyond this "company" barrier.  Or maybe it never occurred to them.

>I guess the issue is not companies making money on free software.
>Instead the issue is companies being perceived as controlling the
>software development.

Well, if that is your feeling, I can't dispute it.  If I understand what
you're saying correctly, your philosophy for Cygwin is that you will use
it and hope that it improves from release to release but, if it doesn't,
the barrier of a company judging and profiting by your code submissions
is too high for you to consider attempting any improvements yourself.

>Tcl is entering the same delicate state. With Ousterhout starting
>Scriptics which is now the official distributor of the release people
>are beginning to get nervous. The question always hovers "will
>Scriptics pull Tcl in and make it a commercial product?" TclPro is
>$1000 a seat. What if new development or the good extensions only
>appear in TclPro? Nobody begrudges Ousterhout's right to make money on
>his major contribution but still there is anxiety.

I don't know anything about Scriptics' philosophy of business but I hope
that most people on the net know that Cygnus has been dedicated to the
concept of free software for a long time.  Hopefully that stands for
something.

If it doesn't then I don't know how to overcome this obstacle.  I could
give personal assurances that Cygwin will always be free but since
Cygnus is a business, DJ and I could be booted out tomorrow and replaced
by some evil software hoarders.  It's not a likely scenario (at least
the evil software hoarder part) but there is no guarantee that anyone
can give that means anything.

But, of course, maybe none of these observations matter.  We're talking
about perceptions, here.  It's my contention that if the EGCS project
had been named 'cyg-gcc' that it probably wouldn't have as large a base
of contributors.  It's probably the initial 'cyg' which is off putting
to people as well as the technical barrier of having to know both UNIX
and Windows code.

cgf

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

Re[2]: Cygwin participation threshold

[Paul Sokolovsky]

Hello Christopher,

Christopher Faylor <cgf@cygnus.com> wrote:

CF> But, of course, maybe none of these observations matter.  We're talking
CF> about perceptions, here.  It's my contention that if the EGCS project
CF> had been named 'cyg-gcc' that it probably wouldn't have as large a base
CF> of contributors.  It's probably the initial 'cyg' which is off putting
CF> to people as well as the technical barrier of having to know both UNIX
CF> and Windows code.

    By the way, if you haven't answered that yet, changing name from
gnu-win32 to cygwin has your motivation or FSF's?

CF> cgf


Best regards,
 Paul                            mailto:paul-ml@is.lg.ua


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

Re: Cygwin participation threshold

[Christopher Faylor]

On Wed, Feb 24, 1999 at 11:10:20PM +0200, Paul Sokolovsky wrote:
>Christopher Faylor <cgf@cygnus.com> wrote:
>CF> But, of course, maybe none of these observations matter.  We're talking
>CF> about perceptions, here.  It's my contention that if the EGCS project
>CF> had been named 'cyg-gcc' that it probably wouldn't have as large a base
>CF> of contributors.  It's probably the initial 'cyg' which is off putting
>CF> to people as well as the technical barrier of having to know both UNIX
>CF> and Windows code.
>
>    By the way, if you haven't answered that yet, changing name from
>gnu-win32 to cygwin has your motivation or FSF's?

I wasn't around for all of the naming decisions but I think that the
decision was entirely Cygnus's.  Maybe if Geoff is still reading the
list he can elaborate.  It would be interesting to see if contributions
slacked off after the original name change.

We have kicked around other names from time to time but, personally,
given the amount of trouble caused by the transition from cygwin32 ->
cygwin, I don't think I want to change the product name again soon.

In case it wasn't obvious, the 32 was dropped from cygwin32 to avoid
potential trademark infringement with some company whose name currently
escapes me.

cgf

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

Re: Cygwin participation threshold

[Geoffrey Noer]

On Wed, Feb 24, 1999, Christopher Faylor wrote:
[...]
  > >    By the way, if you haven't answered that yet, changing name from
> >gnu-win32 to cygwin has your motivation or FSF's?
> 
> I wasn't around for all of the naming decisions but I think that the
> decision was entirely Cygnus's.  Maybe if Geoff is still reading the
> list he can elaborate.  It would be interesting to see if contributions
> slacked off after the original name change.

Yep, I'm still here.  :-)

Folks at Cygnus made the decision (I was one of the people involved in
it, to a degree).  It was made for a number of reasons -- that
"gnu-win32" was needlessly cumbersome, that Cygwin was meant to
support more Unix apps than just the GNU ones, and that the central
piece of technololgy was Cygwin so it made sense to use that name for
the tools as well as for the library.

Whether or not this was a good decision, it's made and as the person
who recently went through all of the config files changing all
instances of cygwin32 to cygwin*, I hope the current project name
stays for a good long time. :-)

AFAIK, amount of contributions did not vary with this name change.
I think most variation has more to do with how busy individual people
have been and what they've been interested in working on.

-- 
Geoffrey Noer		Email: noer@cygnus.com
Cygnus Solutions

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

Re: Cygwin participation threshold

[Larry Hall]

At 10:51 PM 2/25/99 -0800, Geoffrey Noer wrote:
>AFAIK, amount of contributions did not vary with this name change.
>I think most variation has more to do with how busy individual people
>have been and what they've been interested in working on.
>
>-- 
>Geoffrey Noer		Email: noer@cygnus.com
>Cygnus Solutions
>


Right on!  If anyone wants my opinion (and even if you don't, I guess you'll
get it!;-)), the level of contributions from the current "user" base 
is, much like the contribution level of the people at Cygnus, quite tied to 
what's going on in their "day jobs".  This description certainly fits me to a
tee over the last few months!:-(  I expect the overall level of contributions
will increase only as the user base that likes to dabble in it increases.
While I don't think discussion of this topic is a bad idea, I think it has
become somewhat academic at this point.  People will contribute as they can
and when they can.  I think that describes most of what drives contributions.
Other things mentioned here may be factors on "ramping up" or becoming 
comfortable with what it means to contribute but I expect these are really
secondary issues for most users who would lend a hand.  Obviously, anything
that can be done to mitigate the secondary issues only helps!  Certainly,
if there is a simple "tweak" to any of these, let's find them and "tweak"
them!;-)




Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      (781) 239-1053
8 Grove Street                          (781) 239-1655 - FAX
Wellesley, MA  02482-7797               http://www.rfk.com

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

Re: Cygwin participation threshold

[Larry Hall]

At 10:51 PM 2/25/99 -0800, Geoffrey Noer wrote:
>AFAIK, amount of contributions did not vary with this name change.
>I think most variation has more to do with how busy individual people
>have been and what they've been interested in working on.
>
>-- 
>Geoffrey Noer		Email: noer@cygnus.com
>Cygnus Solutions
>


Right on!  If anyone wants my opinion (and even if you don't, I guess you'll
get it!;-)), the level of contributions from the current "user" base 
is, much like the contribution level of the people at Cygnus, quite tied to 
what's going on in their "day jobs".  This description certainly fits me to a
tee over the last few months!:-(  I expect the overall level of contributions
will increase only as the user base that likes to dabble in it increases.
While I don't think discussion of this topic is a bad idea, I think it has
become somewhat academic at this point.  People will contribute as they can
and when they can.  I think that describes most of what drives contributions.
Other things mentioned here may be factors on "ramping up" or becoming 
comfortable with what it means to contribute but I expect these are really
secondary issues for most users who would lend a hand.  Obviously, anything
that can be done to mitigate the secondary issues only helps!  Certainly,
if there is a simple "tweak" to any of these, let's find them and "tweak"
them!;-)




Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      (781) 239-1053
8 Grove Street                          (781) 239-1655 - FAX
Wellesley, MA  02482-7797               http://www.rfk.com

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

Re: Cygwin participation threshold

[Geoffrey Noer]

On Wed, Feb 24, 1999, Christopher Faylor wrote:
[...]
  > >    By the way, if you haven't answered that yet, changing name from
> >gnu-win32 to cygwin has your motivation or FSF's?
> 
> I wasn't around for all of the naming decisions but I think that the
> decision was entirely Cygnus's.  Maybe if Geoff is still reading the
> list he can elaborate.  It would be interesting to see if contributions
> slacked off after the original name change.

Yep, I'm still here.  :-)

Folks at Cygnus made the decision (I was one of the people involved in
it, to a degree).  It was made for a number of reasons -- that
"gnu-win32" was needlessly cumbersome, that Cygwin was meant to
support more Unix apps than just the GNU ones, and that the central
piece of technololgy was Cygwin so it made sense to use that name for
the tools as well as for the library.

Whether or not this was a good decision, it's made and as the person
who recently went through all of the config files changing all
instances of cygwin32 to cygwin*, I hope the current project name
stays for a good long time. :-)

AFAIK, amount of contributions did not vary with this name change.
I think most variation has more to do with how busy individual people
have been and what they've been interested in working on.

-- 
Geoffrey Noer		Email: noer@cygnus.com
Cygnus Solutions

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

Re: Cygwin participation threshold

[Christopher Faylor]

On Wed, Feb 24, 1999 at 11:10:20PM +0200, Paul Sokolovsky wrote:
>Christopher Faylor <cgf@cygnus.com> wrote:
>CF> But, of course, maybe none of these observations matter.  We're talking
>CF> about perceptions, here.  It's my contention that if the EGCS project
>CF> had been named 'cyg-gcc' that it probably wouldn't have as large a base
>CF> of contributors.  It's probably the initial 'cyg' which is off putting
>CF> to people as well as the technical barrier of having to know both UNIX
>CF> and Windows code.
>
>    By the way, if you haven't answered that yet, changing name from
>gnu-win32 to cygwin has your motivation or FSF's?

I wasn't around for all of the naming decisions but I think that the
decision was entirely Cygnus's.  Maybe if Geoff is still reading the
list he can elaborate.  It would be interesting to see if contributions
slacked off after the original name change.

We have kicked around other names from time to time but, personally,
given the amount of trouble caused by the transition from cygwin32 ->
cygwin, I don't think I want to change the product name again soon.

In case it wasn't obvious, the 32 was dropped from cygwin32 to avoid
potential trademark infringement with some company whose name currently
escapes me.

cgf

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

Re: Cygwin participation threshold

[DJ Delorie]

> For a long time, this same model was also used by Larry Wall for perl.

The model is *still* used by djgpp - *all* patches must go through me.
I'm at the moment starting to let a few others apply patches (like
Eli), but getting code into djgpp is much more draconic than cygwin,
since (1) there are more cygwin people who can check in changes, and
(2) I'm much more strict about style and quality in djgpp :)

> If it doesn't then I don't know how to overcome this obstacle.  I
> could give personal assurances that Cygwin will always be free but
> since Cygnus is a business, DJ and I could be booted out tomorrow
> and replaced by some evil software hoarders.

Even if that happens, you could always take the most recent net
release of cygwin and move forward with it.  It is, after all, GPL.

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

Re: Cygwin participation threshold

[DJ Delorie]

> For a long time, this same model was also used by Larry Wall for perl.

The model is *still* used by djgpp - *all* patches must go through me.
I'm at the moment starting to let a few others apply patches (like
Eli), but getting code into djgpp is much more draconic than cygwin,
since (1) there are more cygwin people who can check in changes, and
(2) I'm much more strict about style and quality in djgpp :)

> If it doesn't then I don't know how to overcome this obstacle.  I
> could give personal assurances that Cygwin will always be free but
> since Cygnus is a business, DJ and I could be booted out tomorrow
> and replaced by some evil software hoarders.

Even if that happens, you could always take the most recent net
release of cygwin and move forward with it.  It is, after all, GPL.

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

Re: Cygwin participation threshold

[Steve Morris]

Christopher Faylor writes:
 > On Wed, Feb 24, 1999 at 09:59:16AM -0500, Steve Morris wrote:
 > >Christopher Faylor writes:
 > > > It is interesting that you felt this way at first.  I wonder if the reason
 > > > has anything to do with the name "Cygwin" which sounds so similar to "Cygnus".
 > > > 
 > > > The reason I am saying this is because hundreds of people have contributed to
 > > > the Linux project and *many* companies make money from Linux.
 > >
 > >Actually I think you've hit on a major issue. Even though Cygnus makes
 > >cygwin available as sourceware it is obviously a Cygnus
 > >product. Cygnus controls the feature set. Design decisions are made by
 > >Cygnus. People can contribute but Cygnus is the final arbiter on
 > >design decisions and even code style.
... clipped ....
 > >On the other hand Cygwin is obviously branded. Even the mailing list
 > >is controlled by Cygnus. The developers mailing list access is
 > >restricted by Cygnus engineers. The official Cygwin web page is
 > >controlled by Cygnus. The bug list is an internal Cygnus system.
 > 
 > All this is true of EGCS, too, isn't it?
 > 
 > The developers mailing list is supposed to be open only to people who
 > are willing to contribute to the development of cygwin.  If the rest of
 > the (developers) mailing list thinks that that is too restrictive a goal
 > then I'd be happy to open it up.  We have maintained cygwin-developers
 > as a closed list to try to limit discussions to actual development
 > issues.
... clipped ....
 > >I guess the issue is not companies making money on free software.
 > >Instead the issue is companies being perceived as controlling the
 > >software development.
 > Well, if that is your feeling, I can't dispute it.  If I understand what
 > you're saying correctly, your philosophy for Cygwin is that you will use
 > it and hope that it improves from release to release but, if it doesn't,
 > the barrier of a company judging and profiting by your code submissions
 > is too high for you to consider attempting any improvements yourself.

Actually I wasn't stating my philosophy. I was generally responding to
your general question. As long as you are making it personal here is
my philosophy: People that use free software should give back to the
free software community where they can. This can be major software
development, helping with doc, or merely fielding questions where they
can from the supporting list or newsgroup. However I don't feel they
need to feel obliged to contribute to every free software package they
use.

Personal note: I attempted to sign up for the cygwin developers
mailing list. I wasn't ready to commit to specific work but I wanted
to get a feel for the level of mutual support and how the team
interacted. I intended to silently lurk a while and then step into a
more active role as I found a place to contribute. Apparently my
justification and commitment didn't seem strong enough because I was
silently excluded. No explanation, no apology. I just wasn't added to
the list. It didn't leave a good taste in my mouth or predispose me to
step up my level of commitment to this particular freeware project.

 > But, of course, maybe none of these observations matter.  We're talking
 > about perceptions, here.  It's my contention that if the EGCS project
 > had been named 'cyg-gcc' that it probably wouldn't have as large a base
 > of contributors.  It's probably the initial 'cyg' which is off putting
 > to people as well as the technical barrier of having to know both UNIX
 > and Windows code.

I think that you are exactly right. Perception is the key, although it
goes beyond just the cyg prefix. I suspect that as long as cygwin is
perceived as a company product people will be less willing to help
than for other projects which are lead by volunteers with no fiduciary
interest. Both are good but one is more attractive than the other.

Steve Morris
sjm@judgement.com


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

RE: Cygwin participation threshold

[Todd Goodman]

> Steve Morris writes:
[SNIP]
> Personal note: I attempted to sign up for the cygwin developers
> mailing list. I wasn't ready to commit to specific work but I wanted
> to get a feel for the level of mutual support and how the team
> interacted. I intended to silently lurk a while and then step into a
> more active role as I found a place to contribute. Apparently my
> justification and commitment didn't seem strong enough because I was
> silently excluded. No explanation, no apology. I just wasn't added to
> the list. It didn't leave a good taste in my mouth or predispose me to
> step up my level of commitment to this particular freeware project.

I had the same experience.  A request for more information (which I
forwarded) but no response after that.

I can certainly understand wanting to keep usage questions, etc from
the developers list and I believe it's a reasonable rule to keep the
list restricted to those who contribute.

However, one of the best ways to get your feet wet and find a place
*to* contribute is to lurk on a developers list for a while.

As is likely the case with most who aren't active contributors, it is
available time at this point that keeps me from contributing more.

If I was able to lurk on the developers list then I could more easily
judge what I might be able to work on.  If something looked like it
would fit with my available time then I might be able to contribute.
If I knew I might have more available time, I could see about something
else.

As it is now, I have no idea what even requires more work.  Everything
works well for me.  :-)

Just my $.02.

Thanks for all the good work,

Todd Goodman

[SNIP]
> Steve Morris
> sjm@judgement.com


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

RE: Cygwin participation threshold

[Todd Goodman]

> Steve Morris writes:
[SNIP]
> Personal note: I attempted to sign up for the cygwin developers
> mailing list. I wasn't ready to commit to specific work but I wanted
> to get a feel for the level of mutual support and how the team
> interacted. I intended to silently lurk a while and then step into a
> more active role as I found a place to contribute. Apparently my
> justification and commitment didn't seem strong enough because I was
> silently excluded. No explanation, no apology. I just wasn't added to
> the list. It didn't leave a good taste in my mouth or predispose me to
> step up my level of commitment to this particular freeware project.

I had the same experience.  A request for more information (which I
forwarded) but no response after that.

I can certainly understand wanting to keep usage questions, etc from
the developers list and I believe it's a reasonable rule to keep the
list restricted to those who contribute.

However, one of the best ways to get your feet wet and find a place
*to* contribute is to lurk on a developers list for a while.

As is likely the case with most who aren't active contributors, it is
available time at this point that keeps me from contributing more.

If I was able to lurk on the developers list then I could more easily
judge what I might be able to work on.  If something looked like it
would fit with my available time then I might be able to contribute.
If I knew I might have more available time, I could see about something
else.

As it is now, I have no idea what even requires more work.  Everything
works well for me.  :-)

Just my $.02.

Thanks for all the good work,

Todd Goodman

[SNIP]
> Steve Morris
> sjm@judgement.com


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

Re: Cygwin participation threshold

[Steve Morris]

Christopher Faylor writes:
 > On Wed, Feb 24, 1999 at 09:59:16AM -0500, Steve Morris wrote:
 > >Christopher Faylor writes:
 > > > It is interesting that you felt this way at first.  I wonder if the reason
 > > > has anything to do with the name "Cygwin" which sounds so similar to "Cygnus".
 > > > 
 > > > The reason I am saying this is because hundreds of people have contributed to
 > > > the Linux project and *many* companies make money from Linux.
 > >
 > >Actually I think you've hit on a major issue. Even though Cygnus makes
 > >cygwin available as sourceware it is obviously a Cygnus
 > >product. Cygnus controls the feature set. Design decisions are made by
 > >Cygnus. People can contribute but Cygnus is the final arbiter on
 > >design decisions and even code style.
... clipped ....
 > >On the other hand Cygwin is obviously branded. Even the mailing list
 > >is controlled by Cygnus. The developers mailing list access is
 > >restricted by Cygnus engineers. The official Cygwin web page is
 > >controlled by Cygnus. The bug list is an internal Cygnus system.
 > 
 > All this is true of EGCS, too, isn't it?
 > 
 > The developers mailing list is supposed to be open only to people who
 > are willing to contribute to the development of cygwin.  If the rest of
 > the (developers) mailing list thinks that that is too restrictive a goal
 > then I'd be happy to open it up.  We have maintained cygwin-developers
 > as a closed list to try to limit discussions to actual development
 > issues.
... clipped ....
 > >I guess the issue is not companies making money on free software.
 > >Instead the issue is companies being perceived as controlling the
 > >software development.
 > Well, if that is your feeling, I can't dispute it.  If I understand what
 > you're saying correctly, your philosophy for Cygwin is that you will use
 > it and hope that it improves from release to release but, if it doesn't,
 > the barrier of a company judging and profiting by your code submissions
 > is too high for you to consider attempting any improvements yourself.

Actually I wasn't stating my philosophy. I was generally responding to
your general question. As long as you are making it personal here is
my philosophy: People that use free software should give back to the
free software community where they can. This can be major software
development, helping with doc, or merely fielding questions where they
can from the supporting list or newsgroup. However I don't feel they
need to feel obliged to contribute to every free software package they
use.

Personal note: I attempted to sign up for the cygwin developers
mailing list. I wasn't ready to commit to specific work but I wanted
to get a feel for the level of mutual support and how the team
interacted. I intended to silently lurk a while and then step into a
more active role as I found a place to contribute. Apparently my
justification and commitment didn't seem strong enough because I was
silently excluded. No explanation, no apology. I just wasn't added to
the list. It didn't leave a good taste in my mouth or predispose me to
step up my level of commitment to this particular freeware project.

 > But, of course, maybe none of these observations matter.  We're talking
 > about perceptions, here.  It's my contention that if the EGCS project
 > had been named 'cyg-gcc' that it probably wouldn't have as large a base
 > of contributors.  It's probably the initial 'cyg' which is off putting
 > to people as well as the technical barrier of having to know both UNIX
 > and Windows code.

I think that you are exactly right. Perception is the key, although it
goes beyond just the cyg prefix. I suspect that as long as cygwin is
perceived as a company product people will be less willing to help
than for other projects which are lead by volunteers with no fiduciary
interest. Both are good but one is more attractive than the other.

Steve Morris
sjm@judgement.com


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

Re: Cygwin participation threshold

[Steve Morris]

In all this discussion something important is being lost. Cris
bemoaned the lack of development support for cygwin and asked for
reasons. I and others tried to explain where we think the issues
are. Inevitably this comes out sounding negative, but at least on my
part, this is not intended. Maybe we took Cris' questions too
literally. Flogging Cygnus was not the intent. We were trying to offer
legitimate feedback to a legitimate question.

Let me reiterate that Cygnus is clearly one of the Good Guys. The best
guys are the Cygnus employees (like Cris) who volunteer their own time
to this project.

Many of us are rooting for Cygnus and are hoping more companies figure
out how to make money on free software; because they then tend to give
back. As an example gcc and gdb have been in much better shape all
these years since Cygnus became the official release site.

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

Re: Cygwin participation threshold

[Steve Morris]

In all this discussion something important is being lost. Cris
bemoaned the lack of development support for cygwin and asked for
reasons. I and others tried to explain where we think the issues
are. Inevitably this comes out sounding negative, but at least on my
part, this is not intended. Maybe we took Cris' questions too
literally. Flogging Cygnus was not the intent. We were trying to offer
legitimate feedback to a legitimate question.

Let me reiterate that Cygnus is clearly one of the Good Guys. The best
guys are the Cygnus employees (like Cris) who volunteer their own time
to this project.

Many of us are rooting for Cygnus and are hoping more companies figure
out how to make money on free software; because they then tend to give
back. As an example gcc and gdb have been in much better shape all
these years since Cygnus became the official release site.

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

Re: Cygwin participation threshold

[Christopher Faylor]

On Wed, Feb 24, 1999 at 09:59:16AM -0500, Steve Morris wrote:
>Christopher Faylor writes:
> > It is interesting that you felt this way at first.  I wonder if the reason
> > has anything to do with the name "Cygwin" which sounds so similar to "Cygnus".
> > 
> > The reason I am saying this is because hundreds of people have contributed to
> > the Linux project and *many* companies make money from Linux.
>
>Actually I think you've hit on a major issue. Even though Cygnus makes
>cygwin available as sourceware it is obviously a Cygnus
>product. Cygnus controls the feature set. Design decisions are made by
>Cygnus. People can contribute but Cygnus is the final arbiter on
>design decisions and even code style.

This is very similar to the way Linux was developed except that in the
Linux case Linus Torvalds was the final arbiter.  In the Cygnus case
the final arbiter was first Steve Chamberlain, then Geoffrey Noer, and
now me.  There's still one person involved in decisions but input from
external developers is both solicited and appreciated.

>With gcc it is different. Cygnus is the official maintainer but the
>perception is that Cygnus acts more as a custodian for FSF and the
>free software community. FSF owns the copyright. Redhat is another
>example. Redhat doesn't own Linux. RPM is the only significant thing
>that RedHat copyrights and even that makes people nervous.

Of course, gcc wasn't initially developed by Cygnus either.  One of the
reasons behind the formation of EGCS was that there were a number of
contributors besides Cygnus who felt that they weren't able to contribute
to GNU's gcc project.  This is entirely a different situation from Cygwin.

Although RedHat doesn't own Linux, it obviously does make money from its
sale.  This means that if you contribute some nifty code to Linux you
also might benefit RedHat.  I don't see how the ownership issue matters
here.  Somebody is still making money from your work whether it's Cygnus
or RedHat.

>On the other hand Cygwin is obviously branded. Even the mailing list
>is controlled by Cygnus. The developers mailing list access is
>restricted by Cygnus engineers. The official Cygwin web page is
>controlled by Cygnus. The bug list is an internal Cygnus system.

All this is true of EGCS, too, isn't it?

The developers mailing list is supposed to be open only to people who
are willing to contribute to the development of cygwin.  If the rest of
the (developers) mailing list thinks that that is too restrictive a goal
then I'd be happy to open it up.  We have maintained cygwin-developers
as a closed list to try to limit discussions to actual development
issues.

>Psychologically it doesn't make me feel like I would count as much as
>a Cygnus engineer if I contributed. Helping Cygnus with their free
>software product doesn't have the same cachet as helping Linus Torvald
>with his. Linus stands first among equals partners. How can I feel
>like an equal partner to a company?

Have you actually read the linux-dev-kernel?  I don't think that
net contributors would rank Linus "first among equal partners".  Linus
is a semi-benign despot.  He accepts patches from people but he always
has the right of refusing patches and he does reject patches often.

Patches from people like Alan Cox or David Miller or Stephen Tweedie are
likely to be given the "fast track" into the main development kernel.
Patches from you or me are likely to be ignored unless we can really
prove our technical competence.

For a long time, this same model was also used by Larry Wall for perl.
In fact, it didn't really break down until Larry suffered health
problems.  Now perl has a number of people contributing code to
an volunteer maintainer who acts as an arbiter of what gets in and what
doesn't.  But in case of deadlock, Larry's word always trumps everyone.

I think that this model is actually what makes these packages a
success.  They have one person at the top with a clear vision of where the
product is supposed to be going and what it is supposed to be doing.

This is what we're trying to do with Cygwin too, with, so far, limited
success.  Cygwin does have it's contributors and I'm *very* grateful for
the time that they've put into making it better.  Some of the major
Cygwin subsystems have, in fact, been contributed by people who managed
to get beyond this "company" barrier.  Or maybe it never occurred to them.

>I guess the issue is not companies making money on free software.
>Instead the issue is companies being perceived as controlling the
>software development.

Well, if that is your feeling, I can't dispute it.  If I understand what
you're saying correctly, your philosophy for Cygwin is that you will use
it and hope that it improves from release to release but, if it doesn't,
the barrier of a company judging and profiting by your code submissions
is too high for you to consider attempting any improvements yourself.

>Tcl is entering the same delicate state. With Ousterhout starting
>Scriptics which is now the official distributor of the release people
>are beginning to get nervous. The question always hovers "will
>Scriptics pull Tcl in and make it a commercial product?" TclPro is
>$1000 a seat. What if new development or the good extensions only
>appear in TclPro? Nobody begrudges Ousterhout's right to make money on
>his major contribution but still there is anxiety.

I don't know anything about Scriptics' philosophy of business but I hope
that most people on the net know that Cygnus has been dedicated to the
concept of free software for a long time.  Hopefully that stands for
something.

If it doesn't then I don't know how to overcome this obstacle.  I could
give personal assurances that Cygwin will always be free but since
Cygnus is a business, DJ and I could be booted out tomorrow and replaced
by some evil software hoarders.  It's not a likely scenario (at least
the evil software hoarder part) but there is no guarantee that anyone
can give that means anything.

But, of course, maybe none of these observations matter.  We're talking
about perceptions, here.  It's my contention that if the EGCS project
had been named 'cyg-gcc' that it probably wouldn't have as large a base
of contributors.  It's probably the initial 'cyg' which is off putting
to people as well as the technical barrier of having to know both UNIX
and Windows code.

cgf

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

Re[2]: Cygwin participation threshold

[Paul Sokolovsky]

Hello Steve,

Steve Morris <smorris@nexen.com> wrote:

SM> Christopher Faylor writes:
 >> It is interesting that you felt this way at first.  I wonder if the reason
 >> has anything to do with the name "Cygwin" which sounds so similar to "Cygnus".
 >> 
 >> The reason I am saying this is because hundreds of people have contributed to
 >> the linux project and *many* companies make money from linux.

SM> Actually I think you've hit on a major issue. Even though Cygnus makes
SM> cygwin available as sourceware it is obviously a Cygnus
SM> product. Cygnus controls the feature set. Design decisions are made by
SM> Cygnus. People can contribute but Cygnus is the final arbitor on
SM> design decisions and even code style.

    As far all messages in this thread were concerned with money and
company status. There're however other attitudes may exist not
concerned with that things. They hardly make great slice in overall
pie, but they may be interesting and completing picture. I write
something like that to DJ Delorie because I hoped that thread will
die. I however, will risk uttering it here. In maxims. Sorry.

1. Here, at my place, nor me nor other people cannot decide which
system they will use: we condemned to use M$ .
2. I personally like anything which allows me to fool this fate (the
motto is: "They can make us use their crap, but they cannot make us
use it their way - we anyway will use it normal way ;-E")
3. I'm just student and appreciate any system allowing me experience
things from which I am departed due (1).
4. I come at little misfeatures, which I probably fix and would like
other guys who just (3) or something like that never come again at.
5. Such things as Linux show that something rightly designed from
scratch can really be right. Question interesting me if is something
inherently weird and evil like windoze can be cured into normal state.
6. Ultimate motto is: "Operating systems considered harmful". OSes stand
in our way. They must be destroyed. Anything helping this worth
appreciating.

      All this makes me wanting to make contributions. What is largely
disallows me it (besides being nothing but bag of crazy ambitions, of
course) is pure technological matters: it's too hard to get that
threshold to make it effectively. Time I need to get it, I can spend
doing something else, e.g. reenventing it all ;-) And, as I told
before, that's not Cygwin problem - IMHO, that's GNU problem - their
style of writing programs is somewhat ... not as in other places %)

      Hopefully, all this is rambling of single freak. But at last I
remind that there're really some problems GNU facing of kind very
familiar to which I talk about. Remember Richy Stallman's sulking at
Linux community for not calling itself "GNU Linux community"? Whether
Linux people was so ungrateful to admit using GNU tools? Somewhere I
read following explaination: Linux is not all that stuff sitting on
system, which is _of course_ GNU, Linux is kernel, which has far
relation with GNU (in code style too, I must note), made by some guy
who has quite careless attitude towards existing things like FreeBSD,
Minix, HURD, etc., just wanting to make 'something weird'.

       All this is exaggeration.



Best regards,
 Paul                            mailto:paul-ml@is.lg.ua


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

Re: Cygwin participation threshold

[Christopher Faylor]

On Wed, Feb 24, 1999 at 10:43:46PM +0200, Paul Sokolovsky wrote:
>      All this makes me wanting to make contributions. What is largely
>disallows me it (besides being nothing but bag of crazy ambitions, of
>course) is pure technological matters: it's too hard to get that
>threshold to make it effectively. Time I need to get it, I can spend
>doing something else, e.g. reenventing it all ;-) And, as I told
>before, that's not Cygwin problem - IMHO, that's GNU problem - their
>style of writing programs is somewhat ... not as in other places %)

Could you be more specific?  What "style of writing programs" are you
referring to?  Is it just the indentation?  That's surely an extremely
trivial thing.

Cygwin is unusual in that it's written in C++ but hopefully that's
not *too* big a barrier at this time.

Otherwise, given the vast popularity of GNU tools and the huge number of
people contributing to them, I'm mystified as to your problems with the
GNU style of writing software.  There is so much GNU software available
that one could easily make the case that it is actually the norm.

cgf

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

Re: Cygwin participation threshold

[Mumit Khan]

On Wed, 24 Feb 1999, Christopher Faylor wrote:

> Could you be more specific?  What "style of writing programs" are you
> referring to?  Is it just the indentation?  That's surely an extremely
> trivial thing.
> 
> Cygwin is unusual in that it's written in C++ but hopefully that's
> not *too* big a barrier at this time.
> 
> Otherwise, given the vast popularity of GNU tools and the huge number of
> people contributing to them, I'm mystified as to your problems with the
> GNU style of writing software.  There is so much GNU software available
> that one could easily make the case that it is actually the norm.
> 


I personally don't use the GNU coding-style guideline, and I doubt if I
ever will.  I see no reason to second-guess many many years of proven
and (mostly) consistent style, but that hasn't stopped me from sending
in contributions, formatted according to GNU guidelines, to various GNU
packages. BTW, there's still no consensus on GNU style in C++ coding,
but since most GNU packages are written in C, this has not been a big
issue.

There's always Emacs (or indent) to help in the formatting process.

As for C++, Cygwin really doesn't use C++ features other than the most
basic kind. This is actually good for a project like this. I doubt
if that will deter the determined.

Regards,
Mumit



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

Re: Cygwin participation threshold

[Mumit Khan]

On Wed, 24 Feb 1999, Christopher Faylor wrote:

> Could you be more specific?  What "style of writing programs" are you
> referring to?  Is it just the indentation?  That's surely an extremely
> trivial thing.
> 
> Cygwin is unusual in that it's written in C++ but hopefully that's
> not *too* big a barrier at this time.
> 
> Otherwise, given the vast popularity of GNU tools and the huge number of
> people contributing to them, I'm mystified as to your problems with the
> GNU style of writing software.  There is so much GNU software available
> that one could easily make the case that it is actually the norm.
> 


I personally don't use the GNU coding-style guideline, and I doubt if I
ever will.  I see no reason to second-guess many many years of proven
and (mostly) consistent style, but that hasn't stopped me from sending
in contributions, formatted according to GNU guidelines, to various GNU
packages. BTW, there's still no consensus on GNU style in C++ coding,
but since most GNU packages are written in C, this has not been a big
issue.

There's always Emacs (or indent) to help in the formatting process.

As for C++, Cygwin really doesn't use C++ features other than the most
basic kind. This is actually good for a project like this. I doubt
if that will deter the determined.

Regards,
Mumit



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

Re: Cygwin participation threshold

[Christopher Faylor]

On Wed, Feb 24, 1999 at 10:43:46PM +0200, Paul Sokolovsky wrote:
>      All this makes me wanting to make contributions. What is largely
>disallows me it (besides being nothing but bag of crazy ambitions, of
>course) is pure technological matters: it's too hard to get that
>threshold to make it effectively. Time I need to get it, I can spend
>doing something else, e.g. reenventing it all ;-) And, as I told
>before, that's not Cygwin problem - IMHO, that's GNU problem - their
>style of writing programs is somewhat ... not as in other places %)

Could you be more specific?  What "style of writing programs" are you
referring to?  Is it just the indentation?  That's surely an extremely
trivial thing.

Cygwin is unusual in that it's written in C++ but hopefully that's
not *too* big a barrier at this time.

Otherwise, given the vast popularity of GNU tools and the huge number of
people contributing to them, I'm mystified as to your problems with the
GNU style of writing software.  There is so much GNU software available
that one could easily make the case that it is actually the norm.

cgf

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

Re: Cygwin participation threshold

[Steve Morris]

Christopher Faylor writes:
 > It is interesting that you felt this way at first.  I wonder if the reason
 > has anything to do with the name "Cygwin" which sounds so similar to "Cygnus".
 > 
 > The reason I am saying this is because hundreds of people have contributed to
 > the linux project and *many* companies make money from linux.

Actually I think you've hit on a major issue. Even though Cygnus makes
cygwin available as sourceware it is obviously a Cygnus
product. Cygnus controls the feature set. Design decisions are made by
Cygnus. People can contribute but Cygnus is the final arbitor on
design decisions and even code style.

With gcc it is different. Cygnus is the official maintainer but the
perception is that Cygnus acts more as a custodian for FSF and the
free software community. FSF owns the copyright. Redhat is another
example. Redhat doesn't own Linux. RPM is the only significant thing
that RedHat copyrights and even that makes people nervous.

On the other hand Cygwin is obviously branded. Even the mailing list
is controlled by Cygnus. The developers mailing list access is
restricted by Cygnus engineers. The official Cygwin web page is
controlled by Cygnus. The bug list is an internal Cygnus system.

Psychologically it doesn't make me feel like I would count as much as
a Cygnus engineer if I contributed. Helping Cygnus with their free
software product doesn't have the same cachet as helping Linus Torvald
with his. Linus stands first among equals partners. How can I feel
like an equal partner to a company?

I guess the issue is not companies making money on free
software. Instead the issue is companies being perceived as
controlling the software development.

Tcl is entering the same delicate state. With Ousterhout starting
Scriptics which is now the official distributor of the release people
are beginning to get nervous. The question always hovers "will
Scriptics pull Tcl in and make it a commercial product?" TclPro is
$1000 a seat. What if new development or the good extensions only
appear in TclPro? Nobody begrudges Ousterhout's right to make money on
his major contribution but still there is anxiety.

I don't envy Cygnus as it tries to walk this tightrope.

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

Re: Cygwin participation threshold

[Ken Thompson]

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

I wonder if part of the reason that there is a lot more
participation on Linux as opposed to cygwin is that maybe most people who
use cygwin do so because there job requires use of a windows platform but
need the tool set provided by Linux/Unix.  At home on their own
time, they are much more likely to muck around with Linux than
windows/cygwin.  Just a thought.

                                    Ken


Ken
Thompson                            
GTRI/ELSYS/SEN 
(404) 894-7089
(VOICE)              
(404) 596-5995 (PAGER) 
(404) 894-7080
(FAX)                  
ken.thompson@gtri.gatech.edu 
The aspiration toward freedom is the most
essentially human of all human manifestations. 
                    
- Eric Hoffer 


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

Re: Cygwin participation threshold

[Ken Thompson]

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

I wonder if part of the reason that there is a lot more
participation on Linux as opposed to cygwin is that maybe most people who
use cygwin do so because there job requires use of a windows platform but
need the tool set provided by Linux/Unix.  At home on their own
time, they are much more likely to muck around with Linux than
windows/cygwin.  Just a thought.

                                    Ken


Ken
Thompson                            
GTRI/ELSYS/SEN 
(404) 894-7089
(VOICE)              
(404) 596-5995 (PAGER) 
(404) 894-7080
(FAX)                  
ken.thompson@gtri.gatech.edu 
The aspiration toward freedom is the most
essentially human of all human manifestations. 
                    
- Eric Hoffer 


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

RE: Cygwin participation threshold

[Bernard Dautrevaux]

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

> -----Original Message-----
> From: DJ Delorie [ mailto:dj@delorie.com ]
> Sent: Wednesday, February 24, 1999 10:50 PM
> To: cgf@cygnus.com
> Cc: cygwin@sourceware.cygnus.com
> Subject: Re: Cygwin participation threshold
> 
> 
> 
> > If it doesn't then I don't know how to overcome this obstacle.  I
> > could give personal assurances that Cygwin will always be free but
> > since Cygnus is a business, DJ and I could be booted out tomorrow
> > and replaced by some evil software hoarders.
> 
> Even if that happens, you could always take the most recent net
> release of cygwin and move forward with it.  It is, after all, GPL.
> 

I wonder if that was not precisely the reason of the lack of
contributors to cygwin. Let make a supposition: suppose Linus had put on
the Linux kernel (the equivalent to cygwin.dll) a copyright saying that
*any* program run under Linux *must* be distributed in source form under
the GPL... I'm quite sure Linux would *not* have been as successful as
it is, would had *a lot* less contributors, and would certainly *not* be
promoted now by little guys like Compaq and HP...

I would like to use cygwin, and I would certainly contribute to cygwin
(helping to solve the problems that bother me in it), but I'm not *able*
to use it (I *have* to restrain to mingw32) because I have to live from
my work and thus I have to sell my software.

How I understand free software is that I'm ready to help build powerful
free tools like cygwin, if I can use this work to earn my life. However
my boss would not allow me to spend my time on cygwin, as he cannot sold
proprietary code built with it. So I *can't* contribute, not because
cygwin is complicated (I'm myself building real-time executives and I
know what complexity is), not because someone may send my patches back
because they are not good enough (I'm sure the first one would be, or
cygwin will be a lot worse than it is), not because cygnus is a company
earning money with free software (I'd like to also). 

The whole point here is these three letters: GPL; let add a 4th one (an
initial L) and it could be a lot more successful, and people that do not
think at contributing would do (at least I would probably do because, at
least for now, I will probably need to if I use it seriously).

Hope this will not start a new GPL/nonGPL flame war; GPL is fine but I
think LGPL would be a lot more appropriate for cygwin.dll.

Best regards, 

		Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingéniérie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

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

RE: Cygwin participation threshold

[Bernard Dautrevaux]

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

> -----Original Message-----
> From: DJ Delorie [ mailto:dj@delorie.com ]
> Sent: Wednesday, February 24, 1999 10:50 PM
> To: cgf@cygnus.com
> Cc: cygwin@sourceware.cygnus.com
> Subject: Re: Cygwin participation threshold
> 
> 
> 
> > If it doesn't then I don't know how to overcome this obstacle.  I
> > could give personal assurances that Cygwin will always be free but
> > since Cygnus is a business, DJ and I could be booted out tomorrow
> > and replaced by some evil software hoarders.
> 
> Even if that happens, you could always take the most recent net
> release of cygwin and move forward with it.  It is, after all, GPL.
> 

I wonder if that was not precisely the reason of the lack of
contributors to cygwin. Let make a supposition: suppose Linus had put on
the Linux kernel (the equivalent to cygwin.dll) a copyright saying that
*any* program run under Linux *must* be distributed in source form under
the GPL... I'm quite sure Linux would *not* have been as successful as
it is, would had *a lot* less contributors, and would certainly *not* be
promoted now by little guys like Compaq and HP...

I would like to use cygwin, and I would certainly contribute to cygwin
(helping to solve the problems that bother me in it), but I'm not *able*
to use it (I *have* to restrain to mingw32) because I have to live from
my work and thus I have to sell my software.

How I understand free software is that I'm ready to help build powerful
free tools like cygwin, if I can use this work to earn my life. However
my boss would not allow me to spend my time on cygwin, as he cannot sold
proprietary code built with it. So I *can't* contribute, not because
cygwin is complicated (I'm myself building real-time executives and I
know what complexity is), not because someone may send my patches back
because they are not good enough (I'm sure the first one would be, or
cygwin will be a lot worse than it is), not because cygnus is a company
earning money with free software (I'd like to also). 

The whole point here is these three letters: GPL; let add a 4th one (an
initial L) and it could be a lot more successful, and people that do not
think at contributing would do (at least I would probably do because, at
least for now, I will probably need to if I use it seriously).

Hope this will not start a new GPL/nonGPL flame war; GPL is fine but I
think LGPL would be a lot more appropriate for cygwin.dll.

Best regards, 

		Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingéniérie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

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

Re: Cygwin participation threshold

[Suhaib M. Siddiqi]

>I wonder if that was not precisely the reason of the lack of
>contributors to cygwin. Let make a supposition: suppose Linus had put
on
>the Linux kernel (the equivalent to cygwin.dll) a copyright saying that
>*any* program run under Linux *must* be distributed in source form
under
>the GPL...


Does the GPL applies to GNUPro, which is distributed for commercial
use?



>I'm quite sure Linux would *not* have been as successful as
>it is, would had *a lot* less contributors, and would certainly *not*
be
>promoted now by little guys like Compaq and HP...
>
>I would like to use cygwin, and I would certainly contribute to cygwin
>(helping to solve the problems that bother me in it), but I'm not
*able*
>to use it (I *have* to restrain to mingw32) because I have to live from
>my work and thus I have to sell my software.






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

Re: Cygwin participation threshold

[DJ Delorie]

> Does the GPL applies to GNUPro, which is distributed for commercial
> use?

GNUPro is made up of a number of components with a number of licensing
terms, just like djgpp is.  Those parts that are copyrighted by
authors other than Cygnus, like gcc, must be distributed under the
terms the author supplied, in this case the GPL.  Cygnus can do
nothing about that.

However, Cygnus is the author of some of those parts (like I'm the
author of djgpp's libc) and can choose alternate terms for alternate
distributions.  For example, our C runtime and cygwin runtimes were
written by us, so we can decide that they're GPL for this release, and
proprietary for that release.  If you purchase a GNUPro distribution
from us, it comes with the same software as a net release (except it's
been QAd, may have some as-yet-unreleased improvements over the net
release, and is supported by Cygnus) but we use a different license
that lets you use our runtimes in proprietary applications.  It just
isn't practical to provide source code for cell phones :) The fees from
these sales are the primary source of funding for the software, and
thus pay for the net releases.

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

Re: Cygwin participation threshold

[DJ Delorie]

> Does the GPL applies to GNUPro, which is distributed for commercial
> use?

GNUPro is made up of a number of components with a number of licensing
terms, just like djgpp is.  Those parts that are copyrighted by
authors other than Cygnus, like gcc, must be distributed under the
terms the author supplied, in this case the GPL.  Cygnus can do
nothing about that.

However, Cygnus is the author of some of those parts (like I'm the
author of djgpp's libc) and can choose alternate terms for alternate
distributions.  For example, our C runtime and cygwin runtimes were
written by us, so we can decide that they're GPL for this release, and
proprietary for that release.  If you purchase a GNUPro distribution
from us, it comes with the same software as a net release (except it's
been QAd, may have some as-yet-unreleased improvements over the net
release, and is supported by Cygnus) but we use a different license
that lets you use our runtimes in proprietary applications.  It just
isn't practical to provide source code for cell phones :) The fees from
these sales are the primary source of funding for the software, and
thus pay for the net releases.

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

Re: Cygwin participation threshold

[Suhaib M. Siddiqi]

>I wonder if that was not precisely the reason of the lack of
>contributors to cygwin. Let make a supposition: suppose Linus had put
on
>the Linux kernel (the equivalent to cygwin.dll) a copyright saying that
>*any* program run under Linux *must* be distributed in source form
under
>the GPL...


Does the GPL applies to GNUPro, which is distributed for commercial
use?



>I'm quite sure Linux would *not* have been as successful as
>it is, would had *a lot* less contributors, and would certainly *not*
be
>promoted now by little guys like Compaq and HP...
>
>I would like to use cygwin, and I would certainly contribute to cygwin
>(helping to solve the problems that bother me in it), but I'm not
*able*
>to use it (I *have* to restrain to mingw32) because I have to live from
>my work and thus I have to sell my software.






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

RE: Cygwin participation threshold

[Bernard Dautrevaux]

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

> -----Original Message-----
> From: DJ Delorie [ mailto:dj@delorie.com ]
> Sent: Thursday, February 25, 1999 7:36 PM
> To: Ssiddiqi@InspirePharm.Com
> Cc: cygwin@sourceware.cygnus.com
> Subject: Re: Cygwin participation threshold
> 
> 
> 
> > Does the GPL applies to GNUPro, which is distributed for commercial
> > use?
> 
> GNUPro is made up of a number of components with a number of licensing
> terms, just like djgpp is.  Those parts that are copyrighted by
> authors other than Cygnus, like gcc, must be distributed under the
> terms the author supplied, in this case the GPL.  Cygnus can do
> nothing about that.
> 
> However, Cygnus is the author of some of those parts (like I'm the
> author of djgpp's libc) and can choose alternate terms for alternate
> distributions.  For example, our C runtime and cygwin runtimes were
> written by us, so we can decide that they're GPL for this release, and
> proprietary for that release.  If you purchase a GNUPro distribution
> from us, it comes with the same software as a net release (except it's
> been QAd, may have some as-yet-unreleased improvements over the net
> release, and is supported by Cygnus) but we use a different license
> that lets you use our runtimes in proprietary applications.  It just
> isn't practical to provide source code for cell phones :) The 
> fees from
> these sales are the primary source of funding for the software, and
> thus pay for the net releases.
> 

So if I understand you corectly, if I *pay* it may be interesting for me
to contribute *pro-bono* to the net release? perhaps I'll negociate
discounts on my payments against my contributions? :-) 

Seriously I effectively remember having noted that I may get a cygwin
release not covered by the GPL against a fee (the one thing I don't know
is "how much?"); however I think it's quite discouraging to see Cygnus,
known to be able to earn its life with free software due to its
excellent support to its high-grade customers (I think I remember
support contracts with Cygnus were quite expensive), shift to a purely
mercantile strategy: If you pay, you'll get the right to earn some money
and to use some proprietary Cygnus code and corrections that may never
be put in the net release...

Too bad for free software fate :-( or *please* explain me that I'm plain
wrong and that Cygnus is not doing anything like that...

Best regards,

		Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingéniérie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

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

Re: Cygwin participation threshold

[DJ Delorie]

> Seriously I effectively remember having noted that I may get a cygwin
> release not covered by the GPL against a fee

Yes, but the only part not covered by the fee is the cygwin/newlib
runtime libraries.  Things like the compiler will always be GPL, no
matter how much you pay.

> (the one thing I don't know is "how much?");

Me neither.  It depends on how much support you want, I think.  We
have everything from "will be fixed in the next release" to "will be
fixed and in your hands in a few hours".

> however I think it's quite discouraging to see Cygnus, known to be
> able to earn its life with free software due to its excellent
> support to its high-grade customers

Yup, that's us.  Support and custom work are still by far the biggest
chunk of our income.

> (I think I remember support contracts with Cygnus were quite
> expensive),

And worth it, I think.  When was the last time you got a useful answer
out of Microsoft's support line?

> shift to a purely mercantile strategy: If you pay, you'll get the
> right to earn some money and to use some proprietary Cygnus code and
> corrections that may never be put in the net release...

Look at it the other way - it encourages people to produce GPL
software, since to do otherwise is more expensive.

As for the "never be put in the net release" you're wrong.  All our
contracts are negotiated such that all changes are folded into the net
releases eventually, usually within six months for custom work.  In
the case of cygwin (winsup, at least), I don't think there's any code
at the moment that isn't already in the net releases.

As for "purely mercantile" you're wrong there too.  Product sales are
a small part of our income, and even then each product sale includes a
support contract, which is part of the price.  I think the *smallest*
contract you can buy is a 30-day "Getting Started" contract.

> Too bad for free software fate :-( or *please* explain me that I'm
> plain wrong and that Cygnus is not doing anything like that...

I think you're wrong, but it's hard to expain why.  Consider that the
GNUPro package (that's what we call it) contains more than just
software.  For the price you pay, you get the following:

* Software that's been fully tested and known to work well together
* hard media and printed documentation
* commercial-grade phone and email support, as much as you paid for
* custom patches and upgrades as per your support agreement
* permission to use the GNUPro runtime for proprietary products

As you see, you're not just paying for the license change.  You're
paying for a lot more, and the license is just part of it.  By selling
these bundles, we accomplish the following goals:

* we spread the word about free software
* we encourage companies to *write* free software
* we fund free software development
* we are more profitable :-)

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

Re: Cygwin participation threshold

[DJ Delorie]

> Seriously I effectively remember having noted that I may get a cygwin
> release not covered by the GPL against a fee

Yes, but the only part not covered by the fee is the cygwin/newlib
runtime libraries.  Things like the compiler will always be GPL, no
matter how much you pay.

> (the one thing I don't know is "how much?");

Me neither.  It depends on how much support you want, I think.  We
have everything from "will be fixed in the next release" to "will be
fixed and in your hands in a few hours".

> however I think it's quite discouraging to see Cygnus, known to be
> able to earn its life with free software due to its excellent
> support to its high-grade customers

Yup, that's us.  Support and custom work are still by far the biggest
chunk of our income.

> (I think I remember support contracts with Cygnus were quite
> expensive),

And worth it, I think.  When was the last time you got a useful answer
out of Microsoft's support line?

> shift to a purely mercantile strategy: If you pay, you'll get the
> right to earn some money and to use some proprietary Cygnus code and
> corrections that may never be put in the net release...

Look at it the other way - it encourages people to produce GPL
software, since to do otherwise is more expensive.

As for the "never be put in the net release" you're wrong.  All our
contracts are negotiated such that all changes are folded into the net
releases eventually, usually within six months for custom work.  In
the case of cygwin (winsup, at least), I don't think there's any code
at the moment that isn't already in the net releases.

As for "purely mercantile" you're wrong there too.  Product sales are
a small part of our income, and even then each product sale includes a
support contract, which is part of the price.  I think the *smallest*
contract you can buy is a 30-day "Getting Started" contract.

> Too bad for free software fate :-( or *please* explain me that I'm
> plain wrong and that Cygnus is not doing anything like that...

I think you're wrong, but it's hard to expain why.  Consider that the
GNUPro package (that's what we call it) contains more than just
software.  For the price you pay, you get the following:

* Software that's been fully tested and known to work well together
* hard media and printed documentation
* commercial-grade phone and email support, as much as you paid for
* custom patches and upgrades as per your support agreement
* permission to use the GNUPro runtime for proprietary products

As you see, you're not just paying for the license change.  You're
paying for a lot more, and the license is just part of it.  By selling
these bundles, we accomplish the following goals:

* we spread the word about free software
* we encourage companies to *write* free software
* we fund free software development
* we are more profitable :-)

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

RE: Cygwin participation threshold

[Bernard Dautrevaux]

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

> -----Original Message-----
> From: DJ Delorie [ mailto:dj@delorie.com ]
> Sent: Thursday, February 25, 1999 7:36 PM
> To: Ssiddiqi@InspirePharm.Com
> Cc: cygwin@sourceware.cygnus.com
> Subject: Re: Cygwin participation threshold
> 
> 
> 
> > Does the GPL applies to GNUPro, which is distributed for commercial
> > use?
> 
> GNUPro is made up of a number of components with a number of licensing
> terms, just like djgpp is.  Those parts that are copyrighted by
> authors other than Cygnus, like gcc, must be distributed under the
> terms the author supplied, in this case the GPL.  Cygnus can do
> nothing about that.
> 
> However, Cygnus is the author of some of those parts (like I'm the
> author of djgpp's libc) and can choose alternate terms for alternate
> distributions.  For example, our C runtime and cygwin runtimes were
> written by us, so we can decide that they're GPL for this release, and
> proprietary for that release.  If you purchase a GNUPro distribution
> from us, it comes with the same software as a net release (except it's
> been QAd, may have some as-yet-unreleased improvements over the net
> release, and is supported by Cygnus) but we use a different license
> that lets you use our runtimes in proprietary applications.  It just
> isn't practical to provide source code for cell phones :) The 
> fees from
> these sales are the primary source of funding for the software, and
> thus pay for the net releases.
> 

So if I understand you corectly, if I *pay* it may be interesting for me
to contribute *pro-bono* to the net release? perhaps I'll negociate
discounts on my payments against my contributions? :-) 

Seriously I effectively remember having noted that I may get a cygwin
release not covered by the GPL against a fee (the one thing I don't know
is "how much?"); however I think it's quite discouraging to see Cygnus,
known to be able to earn its life with free software due to its
excellent support to its high-grade customers (I think I remember
support contracts with Cygnus were quite expensive), shift to a purely
mercantile strategy: If you pay, you'll get the right to earn some money
and to use some proprietary Cygnus code and corrections that may never
be put in the net release...

Too bad for free software fate :-( or *please* explain me that I'm plain
wrong and that Cygnus is not doing anything like that...

Best regards,

		Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingéniérie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

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

Re: Cygwin participation threshold

[Christopher G. Faylor]

>From: Steve Morris <smorris@nexen.com>
>Date: Fri, 26 Feb 1999 11:55:50 -0500 (EST)
>
>In all this discussion something important is being lost. Cris
>bemoaned the lack of development support for cygwin and asked for
>reasons. I and others tried to explain where we think the issues
>are. Inevitably this comes out sounding negative, but at least on my
>part, this is not intended. Maybe we took Cris' questions too
>literally. Flogging Cygnus was not the intent. We were trying to offer
>legitimate feedback to a legitimate question.
>
>Let me reiterate that Cygnus is clearly one of the Good Guys. The best
>guys are the Cygnus employees (like Cris) who volunteer their own time
>to this project.
>
>Many of us are rooting for Cygnus and are hoping more companies figure
>out how to make money on free software; because they then tend to give
>back. As an example gcc and gdb have been in much better shape all
>these years since Cygnus became the official release site.

Thanks very much for this positive note.

I was hoping that my original message would generate a lot of discussion
because I thought that it would give DJ and myself an opportunity to
explain something about Cygnus/Cygwin as well as providing a venue
for everyone else to provide their outlook.

It may not be obvious but I do appreciate any and all feedback on this
issue.  It certainly helps educate me on people's perception of my
company and my product.  I do want to understand what people think
about this.

That doesn't mean that I won't argue with perceptions that I think
are wrong but I certainly respect everyone's right to an opinion.

Again, thanks to you and to the handful of other people who sent me
private supportive email.  I appreciate it.

cgf

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

Re: Cygwin participation threshold

[Christopher G. Faylor]

>From: Steve Morris <smorris@nexen.com>
>Date: Fri, 26 Feb 1999 11:55:50 -0500 (EST)
>
>In all this discussion something important is being lost. Cris
>bemoaned the lack of development support for cygwin and asked for
>reasons. I and others tried to explain where we think the issues
>are. Inevitably this comes out sounding negative, but at least on my
>part, this is not intended. Maybe we took Cris' questions too
>literally. Flogging Cygnus was not the intent. We were trying to offer
>legitimate feedback to a legitimate question.
>
>Let me reiterate that Cygnus is clearly one of the Good Guys. The best
>guys are the Cygnus employees (like Cris) who volunteer their own time
>to this project.
>
>Many of us are rooting for Cygnus and are hoping more companies figure
>out how to make money on free software; because they then tend to give
>back. As an example gcc and gdb have been in much better shape all
>these years since Cygnus became the official release site.

Thanks very much for this positive note.

I was hoping that my original message would generate a lot of discussion
because I thought that it would give DJ and myself an opportunity to
explain something about Cygnus/Cygwin as well as providing a venue
for everyone else to provide their outlook.

It may not be obvious but I do appreciate any and all feedback on this
issue.  It certainly helps educate me on people's perception of my
company and my product.  I do want to understand what people think
about this.

That doesn't mean that I won't argue with perceptions that I think
are wrong but I certainly respect everyone's right to an opinion.

Again, thanks to you and to the handful of other people who sent me
private supportive email.  I appreciate it.

cgf

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