This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Proposed Mailing List Page Reorg

On 14 Jan 2002 at 7:59, Tim Prince wrote: 

> And, without experience specific to Cygwin, no one knows exactly which
> variations on the standard behavior of free software will apply on Cygwin. 

I was hoping and expecting that someone would make this observation. It's 
one that I think is important to keep in mind -- there have had to be, I 
think I can be confident in stating, *some* particular differences in the 
way that some things "work" on cygwin vs. how they work on other platforms 
that are considered Unixen (with GNU/Linux being the obvious major 
reference point at this stage of the game). 

I didn't really have in mind examples like this one however: 

> For example, has anyone documented the ways in which cygwin 
> differs from linux in application of code and data alignments?  Does 
> anyone think the newlib mailing list is a helpful place?

According to my understanding I see this as being eminently ON-topic for 
the cygwin List (or even for cygwin-developers), whereas I was addressing 
the area of topics of a more general user nature, where that user is not 
someone trying to write code for/to Cygwin, but rather was at a much less 
high-level engineering-oriented phase of "usership," and where there might 
therefore be a question whether the question is Cygwin-OT or not. 

In case it isn't at all clear what I might mean, say I might be thinking of 
someone who is trying to build standard Open Source or Free Software 
packages on Cygwin -- not trying to extend or doing a major porting job to 
some app or write an entirely new application, but simply trying to "get 
[foo] to build." I have spent countless hours trying to get  pretty widely- 
used packages to build using Cygwin tools and trying to understand whether 
and how my Cygwin environment was "broken" as the expression goes. 

So what I am addressing is a perceived (on my part) need for clarification 
or contemplation about what comprises a user question that falls within the 
intent of the main cygwin List. Somebody here will (or can or has) stated 
"what is the List intent" very succinctly and will probably probably feel 
that they've nailed it down and it doesn't deserve or need lots more 
discussion, and may be so confident in their assertion that readers will be 
drawn to agree; but a little time and observation may reveal that there are 
many special cases where a gray area is entered and the brief and brusque 
and cut-and-dried doesn't seem to have been enough to cover everything in 
that light. 

A minor but good case in point that occurs to me is the recent discussion 
on List that dealt with enabling certain key-bindings in bash (msg # 42891, 
"Copy and Paste into Console"). One of those bindings was to make the 
'insert' key do something useful (paste from the Windows clipboard into the 
cygwin bash console). IMO this kind of question and the knowledge that was 
shared is very OT because, for one thing, it is Windows-specific (the 
clipboard as such doesn't exist on other platforms, although surely 
analogous entities must..). So this is an instance of a divergence between 
"standard" behavior of a Gnu tool and a "special behavior or modification" 
that this tool's Cygwin port has. For another thing, I think it can be seen 
as reasonable to assert that having an efficient and "confortable" shell 
environment to work in is a prerequisite for a lot of users to getting more 
specific and interesting work done. It certainly is for me. I'd like to 
think that the Cygwin project's folks would see this as an area that needs 
support, very legitimately. It may not particularly *interest* some 
individual who is of capability such that they are preoccupied with the 
innards of Cygwin or some major piece of Cygwin, but the mere fact that it 
isn't especially stimulating to such individuals to deal with such 
questions doesn't make the asking of them invalid or the effort to provide 
helpful and accessible support on them unimportant. 

This is what FAQs are for, of course, and a lot of info exists in them. 
FAQs are only any good if a user finds them and reads them, of course. And 
they may need constant upkeep and re-writing to be really useful. 

   Best Regards,
     Soren Andersen 

Unsubscribe info:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]