This is the mail archive of the
mailing list for the Cygwin project.
RE: press for cygwin
- To: Mark Bradshaw <bradshaw at staff dot crosswalk dot com>,"'cygwin at cygwin dot com'" <cygwin at cygwin dot com>
- Subject: RE: press for cygwin
- From: "Larry Hall (RFK Partners, Inc)" <lhall at rfk dot com>
- Date: Fri, 31 Aug 2001 13:30:22 -0400
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.
Larry Hall email@example.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