public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
* Cygnus Support - WAS: Re: Cygwin B20 - fseek under gcc fails to reposition on text files
@ 1999-02-19  9:27 Steve Biskis
       [not found] ` < 00b301be5c2d$05517220$080216c0@newt.san.rr.com >
  1999-02-28 23:02 ` Steve Biskis
  0 siblings, 2 replies; 6+ messages in thread
From: Steve Biskis @ 1999-02-19  9:27 UTC (permalink / raw)
  To: Cygnus Solutions

Yep, what he said and now (my story/excuse):

I have a fairly rough go at just compiling the development sources,
let alone making a great deal of sense out of the code.
When I do finally get built, many of the binaries(stripped or not)
do not size and/or sum to your original binary release.  This alone
would not make such a big deal but when stuff starts running flaky its
a bit tougher to know where to start (what is different ?).

Now, I've been coding for many years on many platforms and like any
other problem-solving veteran, I can sense when a high hill looms ahead.
That source hierarchy with lack of developer documentation is a
mini-mountain !  The fact that outsiders can contribute anything
significant to the cygwin internals is a testament to their sheer wills.

Don't get me wrong, I love this stuff, and I made a pact with myself to
never dump on it.  Besides, you get what you pay for, right ? (if you're
lucky)
I must tip my hat to you guys working for the cause - I don't know how you
ever find the time.  And if I was doin' something pro-bono, I'd take exactly
0 crap from anyone.  Far less than you do.

I guess what it comes down to with me is that it all works just good enough
to
serve my relatively "light" windows needs.  Yet its not quite UNIXy enough
to really grip me by the gonads.  e.g. Those system attribute luvin' soft
links are a real bummer !  This means that I can't maintain your free
sources for compilation on a true UNIX file system using free file sharing
software (Samba).
This forces me to buy into yet more Wintel if I want to get serious.
I have a real philosophical problem with that.  Plus, given that you guys
made a
sort of virtual UNIX on Windows thang it just seems like it would make more
sense
to have a link scheme that doesn't cripple the (arguably)most popular
UNIX-to-Windows interconnectivity software in existence.

But on the positive side, I can edit/compile/debug on my NeXTStep box and
then
compile the very same source (stored on my FreeBSD file server) on my NT
box.
As long as its my own source - see where I'm heading ?

I abandoned C++ many years ago in lieu of ObjC, add to this that I am
primarily a UNIX programmer unfamiliar and unconcerned with a multitude
of Win32 oddities ((text_or_binary)?who_cares:not_me).  I find myself a bit
removed from what seems to be the mainstream of community gossip in
our little mail-group.

I think the heart of the "Cygnus lack of outside developer support" problem
is this:

Your niche.

You provide windows software of interest to UNIX and Windoze people.
Many of the UNIX people are lured because  they figure that they can deploy
much of their UNIX code on Windoze WITHOUT needing to understand very
much about the Windoze way of doing things.  Since they approach your
software with this in (conscience or unconscience)mind, they are
understandably
reluctant and/or ill-prepared to get very involved with what would turn out
to be
by anyone's reckoning, some pretty hairy Windoze coding !

Windoze people, on the other hand, tend to be less system aware.
Mostly married to GUI-based toolkits like Delphi, VB, VC++, etc, they have a
difficult
enough time understanding what the hell make is, let alone what you guys
need !

Now those of you code who code primarily on the Windoze platform and really
understand make, don't get mad at me - I'm not talking about you.

Anyway, I admire what you guys have accomplished, it keeps getting better.
I'll try to do something, but you know getting started is always the hardest
part.


Steve B.


-----Original Message-----
From: setera@us.ibm.com <setera@us.ibm.com>
To: cygwin@sourceware.cygnus.com <cygwin@sourceware.cygnus.com>
Date: Friday, February 19, 1999 7:00 AM
Subject: Re: Cygwin B20 - fseek under gcc fails to reposition on text files


>Chris,
>
>I can certainly understand your frustrations.  In my GIMP work, I've had a
>heck of a time with some hanging problems which I've reported to you.  I
>report them to you and DJ not because I *expect* you to jump and fix them,
>but because I am clueless on how to fix them myself.  I *have* downloaded
>the source code and *have* attempted to understand the infrastructure
>enough to solve the problems.  In my case at least, if there were more
>documentation on the internals of the winsup code, I might be able to solve
>some problems on my own.  Unfortunately, I think with the exception of a
>few people (you, DJ, Sergey, etc) most do not have a good enough
>understanding of the internals of winsup to really be able to help out.  On
>the other hand, I try not to complain about things either.
>
>Anyway, just another person's perspective.
>
>Craig
>
>
>Craig Setera
>AS/400 Enterprise Java Development
>IBM Rochester
>setera@us.ibm.com
>(507) 253-3387 - Tie: 553-3387
>
>
>
>
>--
>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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Cygnus Support - WAS: Re: Cygwin B20 - fseek under gcc fails to reposition on text files
       [not found] ` < 00b301be5c2d$05517220$080216c0@newt.san.rr.com >
@ 1999-02-19 10:29   ` Larry Hall
       [not found]     ` < 3.0.5.32.19990219132631.0162d0c0@pop.ma.ultranet.com >
  1999-02-28 23:02     ` Larry Hall
  0 siblings, 2 replies; 6+ messages in thread
From: Larry Hall @ 1999-02-19 10:29 UTC (permalink / raw)
  To: Steve Biskis, Cygnus Solutions

At 09:26 AM 2/19/99 -0800, Steve Biskis wrote:
>I guess what it comes down to with me is that it all works just good enough
>to
>serve my relatively "light" windows needs.  Yet its not quite UNIXy enough
>to really grip me by the gonads.  e.g. Those system attribute luvin' soft
>links are a real bummer !  This means that I can't maintain your free
>sources for compilation on a true UNIX file system using free file sharing
>software (Samba).
>This forces me to buy into yet more Wintel if I want to get serious.
>I have a real philosophical problem with that.  Plus, given that you guys
>made a
>sort of virtual UNIX on Windows thang it just seems like it would make more
>sense
>to have a link scheme that doesn't cripple the (arguably)most popular
>UNIX-to-Windows interconnectivity software in existence.

Addressing this issue directly and completely out of context of the thread,
I think its important for people to realize that the "system attribute" 
approach to the symlinks is for performance reasons only!  Once upon a 
time, there was no need to set the system attribute in order to get Cygwin
to recognize a symlink.  However, this tended to make ls -F and other 
utilities that wanted to know file types slow so the attribute idea was
added to speed up these cases.  If someone is willing to put up with the
performance issues, removing the attribute aspect of symlinks should allow
it to work on any kind of file system, if I'm not mistaken about the
implementation.  That said, I would suggest that anyone who is intrigued
by this information consider 2 things:

  1. Making a change to enable symlinks over Samba or whatever would be
     a change that wouldn't be accepted in general without a switch 
     (probably via CYGWIN).

  2. Symlinks would still be Cygwin specific.  Don't expect to be able to
     use a Cygwin symlink on a shared partition with Linux when booted to
     Linux (or vice versa for that matter)!:-)

There's more for the mix!:-)


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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Cygnus Support - WAS: Re: Cygwin B20 - fseek under gcc fails to reposition on text files
       [not found]     ` < 3.0.5.32.19990219132631.0162d0c0@pop.ma.ultranet.com >
@ 1999-02-19 17:29       ` Christopher Faylor
  1999-02-28 23:02         ` Christopher Faylor
  0 siblings, 1 reply; 6+ messages in thread
From: Christopher Faylor @ 1999-02-19 17:29 UTC (permalink / raw)
  To: Larry Hall, Steve Biskis, Cygnus Solutions

On Fri, Feb 19, 1999 at 01:26:31PM -0500, Larry Hall wrote:
>At 09:26 AM 2/19/99 -0800, Steve Biskis wrote:
>>I guess what it comes down to with me is that it all works just good
>>enough to serve my relatively "light" windows needs.  Yet its not quite
>>UNIXy enough to really grip me by the gonads.  e.g.  Those system
>>attribute luvin' soft links are a real bummer ! This means that I can't
>>maintain your free sources for compilation on a true UNIX file system
>>using free file sharing software (Samba).  This forces me to buy into
>>yet more Wintel if I want to get serious.  I have a real philosophical
>>problem with that.  Plus, given that you guys made a sort of virtual
>>UNIX on Windows thang it just seems like it would make more sense to
>>have a link scheme that doesn't cripple the (arguably)most popular
>>UNIX-to-Windows interconnectivity software in existence.
>
>Addressing this issue directly and completely out of context of the
>thread, I think its important for people to realize that the "system
>attribute" approach to the symlinks is for performance reasons only!
>Once upon a time, there was no need to set the system attribute in
>order to get Cygwin to recognize a symlink.  However, this tended to
>make ls -F and other utilities that wanted to know file types slow so
>the attribute idea was added to speed up these cases.  If someone is
>willing to put up with the performance issues, removing the attribute
>aspect of symlinks should allow it to work on any kind of file system,
>if I'm not mistaken about the implementation.  That said, I would
>suggest that anyone who is intrigued by this information consider 2
>things:
>
>1.  Making a change to enable symlinks over Samba or whatever would be
>     a change that wouldn't be accepted in general without a switch
>     (probably via CYGWIN).

Of course you could always investigate the documentation for samba and
look into a way of making the system attribute show up on a samba
mounted drive.  It *is* possible.

cgf

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Cygnus Support - WAS: Re: Cygwin B20 - fseek under gcc fails to reposition on text files
  1999-02-19 10:29   ` Larry Hall
       [not found]     ` < 3.0.5.32.19990219132631.0162d0c0@pop.ma.ultranet.com >
@ 1999-02-28 23:02     ` Larry Hall
  1 sibling, 0 replies; 6+ messages in thread
From: Larry Hall @ 1999-02-28 23:02 UTC (permalink / raw)
  To: Steve Biskis, Cygnus Solutions

At 09:26 AM 2/19/99 -0800, Steve Biskis wrote:
>I guess what it comes down to with me is that it all works just good enough
>to
>serve my relatively "light" windows needs.  Yet its not quite UNIXy enough
>to really grip me by the gonads.  e.g. Those system attribute luvin' soft
>links are a real bummer !  This means that I can't maintain your free
>sources for compilation on a true UNIX file system using free file sharing
>software (Samba).
>This forces me to buy into yet more Wintel if I want to get serious.
>I have a real philosophical problem with that.  Plus, given that you guys
>made a
>sort of virtual UNIX on Windows thang it just seems like it would make more
>sense
>to have a link scheme that doesn't cripple the (arguably)most popular
>UNIX-to-Windows interconnectivity software in existence.

Addressing this issue directly and completely out of context of the thread,
I think its important for people to realize that the "system attribute" 
approach to the symlinks is for performance reasons only!  Once upon a 
time, there was no need to set the system attribute in order to get Cygwin
to recognize a symlink.  However, this tended to make ls -F and other 
utilities that wanted to know file types slow so the attribute idea was
added to speed up these cases.  If someone is willing to put up with the
performance issues, removing the attribute aspect of symlinks should allow
it to work on any kind of file system, if I'm not mistaken about the
implementation.  That said, I would suggest that anyone who is intrigued
by this information consider 2 things:

  1. Making a change to enable symlinks over Samba or whatever would be
     a change that wouldn't be accepted in general without a switch 
     (probably via CYGWIN).

  2. Symlinks would still be Cygwin specific.  Don't expect to be able to
     use a Cygwin symlink on a shared partition with Linux when booted to
     Linux (or vice versa for that matter)!:-)

There's more for the mix!:-)


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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Cygnus Support - WAS: Re: Cygwin B20 - fseek under gcc fails to reposition on text files
  1999-02-19 17:29       ` Christopher Faylor
@ 1999-02-28 23:02         ` Christopher Faylor
  0 siblings, 0 replies; 6+ messages in thread
From: Christopher Faylor @ 1999-02-28 23:02 UTC (permalink / raw)
  To: Larry Hall, Steve Biskis, Cygnus Solutions

On Fri, Feb 19, 1999 at 01:26:31PM -0500, Larry Hall wrote:
>At 09:26 AM 2/19/99 -0800, Steve Biskis wrote:
>>I guess what it comes down to with me is that it all works just good
>>enough to serve my relatively "light" windows needs.  Yet its not quite
>>UNIXy enough to really grip me by the gonads.  e.g.  Those system
>>attribute luvin' soft links are a real bummer ! This means that I can't
>>maintain your free sources for compilation on a true UNIX file system
>>using free file sharing software (Samba).  This forces me to buy into
>>yet more Wintel if I want to get serious.  I have a real philosophical
>>problem with that.  Plus, given that you guys made a sort of virtual
>>UNIX on Windows thang it just seems like it would make more sense to
>>have a link scheme that doesn't cripple the (arguably)most popular
>>UNIX-to-Windows interconnectivity software in existence.
>
>Addressing this issue directly and completely out of context of the
>thread, I think its important for people to realize that the "system
>attribute" approach to the symlinks is for performance reasons only!
>Once upon a time, there was no need to set the system attribute in
>order to get Cygwin to recognize a symlink.  However, this tended to
>make ls -F and other utilities that wanted to know file types slow so
>the attribute idea was added to speed up these cases.  If someone is
>willing to put up with the performance issues, removing the attribute
>aspect of symlinks should allow it to work on any kind of file system,
>if I'm not mistaken about the implementation.  That said, I would
>suggest that anyone who is intrigued by this information consider 2
>things:
>
>1.  Making a change to enable symlinks over Samba or whatever would be
>     a change that wouldn't be accepted in general without a switch
>     (probably via CYGWIN).

Of course you could always investigate the documentation for samba and
look into a way of making the system attribute show up on a samba
mounted drive.  It *is* possible.

cgf

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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Cygnus Support - WAS: Re: Cygwin B20 - fseek under gcc fails to reposition on text files
  1999-02-19  9:27 Cygnus Support - WAS: Re: Cygwin B20 - fseek under gcc fails to reposition on text files Steve Biskis
       [not found] ` < 00b301be5c2d$05517220$080216c0@newt.san.rr.com >
@ 1999-02-28 23:02 ` Steve Biskis
  1 sibling, 0 replies; 6+ messages in thread
From: Steve Biskis @ 1999-02-28 23:02 UTC (permalink / raw)
  To: Cygnus Solutions

Yep, what he said and now (my story/excuse):

I have a fairly rough go at just compiling the development sources,
let alone making a great deal of sense out of the code.
When I do finally get built, many of the binaries(stripped or not)
do not size and/or sum to your original binary release.  This alone
would not make such a big deal but when stuff starts running flaky its
a bit tougher to know where to start (what is different ?).

Now, I've been coding for many years on many platforms and like any
other problem-solving veteran, I can sense when a high hill looms ahead.
That source hierarchy with lack of developer documentation is a
mini-mountain !  The fact that outsiders can contribute anything
significant to the cygwin internals is a testament to their sheer wills.

Don't get me wrong, I love this stuff, and I made a pact with myself to
never dump on it.  Besides, you get what you pay for, right ? (if you're
lucky)
I must tip my hat to you guys working for the cause - I don't know how you
ever find the time.  And if I was doin' something pro-bono, I'd take exactly
0 crap from anyone.  Far less than you do.

I guess what it comes down to with me is that it all works just good enough
to
serve my relatively "light" windows needs.  Yet its not quite UNIXy enough
to really grip me by the gonads.  e.g. Those system attribute luvin' soft
links are a real bummer !  This means that I can't maintain your free
sources for compilation on a true UNIX file system using free file sharing
software (Samba).
This forces me to buy into yet more Wintel if I want to get serious.
I have a real philosophical problem with that.  Plus, given that you guys
made a
sort of virtual UNIX on Windows thang it just seems like it would make more
sense
to have a link scheme that doesn't cripple the (arguably)most popular
UNIX-to-Windows interconnectivity software in existence.

But on the positive side, I can edit/compile/debug on my NeXTStep box and
then
compile the very same source (stored on my FreeBSD file server) on my NT
box.
As long as its my own source - see where I'm heading ?

I abandoned C++ many years ago in lieu of ObjC, add to this that I am
primarily a UNIX programmer unfamiliar and unconcerned with a multitude
of Win32 oddities ((text_or_binary)?who_cares:not_me).  I find myself a bit
removed from what seems to be the mainstream of community gossip in
our little mail-group.

I think the heart of the "Cygnus lack of outside developer support" problem
is this:

Your niche.

You provide windows software of interest to UNIX and Windoze people.
Many of the UNIX people are lured because  they figure that they can deploy
much of their UNIX code on Windoze WITHOUT needing to understand very
much about the Windoze way of doing things.  Since they approach your
software with this in (conscience or unconscience)mind, they are
understandably
reluctant and/or ill-prepared to get very involved with what would turn out
to be
by anyone's reckoning, some pretty hairy Windoze coding !

Windoze people, on the other hand, tend to be less system aware.
Mostly married to GUI-based toolkits like Delphi, VB, VC++, etc, they have a
difficult
enough time understanding what the hell make is, let alone what you guys
need !

Now those of you code who code primarily on the Windoze platform and really
understand make, don't get mad at me - I'm not talking about you.

Anyway, I admire what you guys have accomplished, it keeps getting better.
I'll try to do something, but you know getting started is always the hardest
part.


Steve B.


-----Original Message-----
From: setera@us.ibm.com <setera@us.ibm.com>
To: cygwin@sourceware.cygnus.com <cygwin@sourceware.cygnus.com>
Date: Friday, February 19, 1999 7:00 AM
Subject: Re: Cygwin B20 - fseek under gcc fails to reposition on text files


>Chris,
>
>I can certainly understand your frustrations.  In my GIMP work, I've had a
>heck of a time with some hanging problems which I've reported to you.  I
>report them to you and DJ not because I *expect* you to jump and fix them,
>but because I am clueless on how to fix them myself.  I *have* downloaded
>the source code and *have* attempted to understand the infrastructure
>enough to solve the problems.  In my case at least, if there were more
>documentation on the internals of the winsup code, I might be able to solve
>some problems on my own.  Unfortunately, I think with the exception of a
>few people (you, DJ, Sergey, etc) most do not have a good enough
>understanding of the internals of winsup to really be able to help out.  On
>the other hand, I try not to complain about things either.
>
>Anyway, just another person's perspective.
>
>Craig
>
>
>Craig Setera
>AS/400 Enterprise Java Development
>IBM Rochester
>setera@us.ibm.com
>(507) 253-3387 - Tie: 553-3387
>
>
>
>
>--
>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


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~1999-02-28 23:02 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-02-19  9:27 Cygnus Support - WAS: Re: Cygwin B20 - fseek under gcc fails to reposition on text files Steve Biskis
     [not found] ` < 00b301be5c2d$05517220$080216c0@newt.san.rr.com >
1999-02-19 10:29   ` Larry Hall
     [not found]     ` < 3.0.5.32.19990219132631.0162d0c0@pop.ma.ultranet.com >
1999-02-19 17:29       ` Christopher Faylor
1999-02-28 23:02         ` Christopher Faylor
1999-02-28 23:02     ` Larry Hall
1999-02-28 23:02 ` Steve Biskis

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).