RE: press for cygwin

["Larry Hall (RFK Partners, Inc)" <lhall at rfk dot com>]

At 10:35 AM 8/31/2001, Mark Bradshaw wrote:
>Hmm...  Should I paint a bulls eye on my chest here.  Eh.  Why not.
>
>Couple of quick notes on the thread.  
>
>1)  Complete agreement with Jonathon Merz on the WinZip thing.  Going to bz2
>just to thwart WinZip doesn't seem like a good use of energy.  Unfortunately
>at the time I wrote the article bz2 wasn't in use for the packages.  WinZip,
>being the most popular zip tool for Windows, seemed the obvious choice for
>unzipping the cygwin packages.  You wouldn't believe how long it takes to
>get an article printed. :(


Just so everyone is clear (in case there still is some ambiguity on this
subject in this thread), discouraging the use of WinZip is *not* the root
of some insidious plot.  There's a good reason.  That reason is 
WinZip doesn't understand facilities and conventions of Cygwin (like
symbolic links, mounts, etc).  As a result, things installed with WinZip
are very likely to be broken when done.  While that's the plight of the 
person adopting the wrong install procedure, it leaves a bad impression
with the would-be user and probably generates some email to the list.
We see plenty of this kind of email now.  So the we strongly discourage 
the use of WinZip as a result.  It is not a robust installation procedure
for Cygwin and we'd like to avoid people trying to use this approach, for
their benefit and ours.  Changing to bzip2 format files would do this,
since the Cygwin installer (setup.exe) can handle bzip2 files just as
readily as gzip.  Of course, some day WinZip will add bzip2 file support
and we'll be right back to to square one again! ;-)


>2)  Goes the same for the references to old versions, etc.  The article's
>almost a year old now, believe it or not.
>
>3)  Yes I know it's an unsupported install, but I think the point was missed
>here.  Many windows admins won't install the full cygwin installation, and
>most won't have a clue what to do with bash, etc.  The point here isn't to
>exclude people from a great tool, but to help make an intermediate step more
>palatable.  I know many will disagree with this, with sentiments along the
>lines of "They should just learn how to work with it."  I disagree.  I think
>it's worth it to get telnet replaced, in whatever fashion that happens.
>Bashless or not.


The issue of performing a full Cygwin installation is one that this list
understands well and is something that's being addressed.  The strong
recommendation to install *all* packages comes from the fact that there
are implicit interdependencies among packages.  Folks who try to 
pick-and-choose the packages they want without an understanding of the 
underlying dependencies often end up with strange problems, resulting in 
an avalanche of email queries.  While many of us on this list are quite 
proud of Cygwin and wish to promote its use, the main reason at this point 
for pushing for full installs is, again, pretty pragmatic.  We want folks 
to be able to install stuff and get it going very easily.  Without explicit 
dependency information, this can't be guaranteed to your average net user 
unless they install everything (since then all the dependencies will be 
resolved by default).  Rest assured there's been allot of talk on this 
list about a solution for the dependency problem and quite a bit of work 
on a new version of setup.exe which will handle them transparently.  Once 
this is in place, I think most folks on the list will feel comfortable 
with the average user downloading only the packages they want.  In the 
meantime I, for one, have no problem with folks downloading only what they 
need so long as they know what they need (i.e. they understand the implicit
dependencies).  If they don't, I feel it's up to them to pull down 
everything and retry their problem before consulting the list.  I believe 
it's fair to allow people to use these tools the way they want to but I 
also believe it's not too much to ask that they recognize that the list 
can't be expected to debug their home-grown installations.  All this 
should be much less of an issue with the upcoming setup.exe that understands the package dependencies.



>4)  The weird "ps &-ef" and "kill &-HUP <PID>" commands are not my fault.
><whine>  The publisher's somehow managed to screw up some of the command
>lines.  </whine>  They will be corrected soon hopefully.
>
>I apologize if I've stepped on some toes with this article.  I know that
>here I'm talking to the folks who are satisfied with the full cygwin
>install, or are knowledgeable enough about it to install the portions
>necessary without the hand holding.  You aren't the target audience for a
>piece like this.  I hoped to catch those people who are largely unaware of
>cygwin and ssh and maybe give them a push into using it.  


I suppose I should add an apology to you, since I was the one that
posted the reference to your article and thus touched off this thread.
While I think the discussion that resulted unearthed some fair criticism,
I came away from it with the distinct impression that you were promoting 
OpenSSH specifically and Cygwin secondarily as good tools.  At least in 
that respect, I was pleased to see these referenced in the Windows 2000 
Magazine forum.  My intent was to share this with the Cygwin community as 
a form of recognition for the hard work.  I hope no one was too offended 
on either side by the resulting discussion.

Regards,



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


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/