Another nail in CygWin's coffin (attached)

[M. Edward (Ed) Borasky]

--------------070503060106080809020308
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Austin is basically right -- *nobody* should use CygWin as a Windows
development platform/IDE/whatever. And nobody should use CygWin for Ruby
or Rails work of any kind on a Windows platform, since everything you
need is available in native form (the One-Click installer, Instant
Rails, and a native Windows PostGreSQL).

However, someone (Larry Wall??) flagged laziness as a virtue, so I'll
ignore Austin's complaints about laziness and continue to use CygWin for
times when someone gives me 15 minutes to get a job done on a Windows
platform that would take me several hours or several days to do if I had to

a. Locate a native Windows tool to do it,
b. Install the Windows tool and
c. Learn how to use the Windows tool.



--------------070503060106080809020308
Content-Type: message/rfc822;
name="Re: GCC 4.1.1?"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="Re: GCC 4.1.1?"

X-Account-Key: account2
Return-Path: <[email protected]>
Delivered-To: (e-mail address removed)
Received: (qmail 2435 invoked from network); 27 Oct 2006 01:21:22 -0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on blade3.cesmail.net
X-Spam-Level:
X-Spam-Status: hits=0.0 tests=none version=3.1.1
Received: from unknown (192.168.1.101)
by blade3.cesmail.net with QMQP; 27 Oct 2006 01:21:22 -0000
Received: from sourceware.org (209.132.176.174)
by mailgate.cesmail.net with SMTP; 27 Oct 2006 01:21:06 -0000
Received: (qmail 21891 invoked by alias); 27 Oct 2006 01:21:04 -0000
Received: (qmail 21883 invoked by uid 22791); 27 Oct 2006 01:21:03 -0000
Received: from smtp101.sbc.mail.mud.yahoo.com (HELO smtp101.sbc.mail.mud.yahoo.com) (68.142.198.200) by sourceware.org (qpsmtpd/0.31) with SMTP; Fri, 27 Oct 2006 01:20:56 +0000
Received: (qmail 45029 invoked from network); 27 Oct 2006 01:20:53 -0000
Received: from unknown (HELO ?68.122.9.103?) ([email protected]@68.122.9.103 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 27 Oct 2006 01:20:52 -0000
Message-ID: <[email protected]>
Date: Thu, 26 Oct 2006 18:20:51 -0700
From: Tim Prince <[email protected]>
Reply-To: (e-mail address removed)
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: (e-mail address removed)
Subject: Re: GCC 4.1.1?
References: <[email protected]>
In-Reply-To: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact (e-mail address removed); run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:[email protected]>
List-Subscribe: <mailto:[email protected]>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:[email protected]>
List-Help: <mailto:[email protected]>, <http://sourceware.org/ml/#faqs>
Sender: (e-mail address removed)
Mail-Followup-To: (e-mail address removed)
Delivered-To: mailing list (e-mail address removed)
X-SpamCop-Checked: 192.168.1.101 209.132.176.174 68.142.198.200 68.122.9.103 68.122.9.103

I'm sure this is a FAQ, but I didn't see it anywhere on line. How long
before GCC 4.1.1 is available in CygWin, and what can we users do to
accelerate the progress towards said availability?

Why specifically 4.1.1? 4.2.0 has a lot of advantages. Not many people
are testing newer gcc versions under cygwin and posting results to
(e-mail address removed). Far from sufficient interest to make
cygwin one of the primary supported targets for gcc.
People probably want to be assured that cygwin-specific bugs have been
fixed, and see satisfactory results for cygwin modifications of standard
gcc, such as -mno-cygwin support et al. If you don't need those
modifications, you are weloome to build (if necessary) and install the
newer public versions.
I myself don't see a lot of incentive to keep cygwin up to date until
64-bit support is available.

--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/



--------------070503060106080809020308--

 

[Philip Hallstrom]

Austin is basically right -- *nobody* should use CygWin as a Windows

development platform/IDE/whatever. And nobody should use CygWin for Ruby
or Rails work of any kind on a Windows platform, since everything you
need is available in native form (the One-Click installer, Instant
Rails, and a native Windows PostGreSQL).

However, someone (Larry Wall??) flagged laziness as a virtue, so I'll
ignore Austin's complaints about laziness and continue to use CygWin for
times when someone gives me 15 minutes to get a job done on a Windows
platform that would take me several hours or several days to do if I had to

a. Locate a native Windows tool to do it,
b. Install the Windows tool and
c. Learn how to use the Windows tool.

I haven't followed this thred so don't know if it's been mentioned, but if
your stuck on windows and don't want to use native windows, maybe try
colinux?

http://www.colinux.org/

I ran that a year or so ago, not ruby, but Apache, PHP, PostgreSQL. If
those all work, I can't see why ruby wouldn't.

My memory is it was oodles faster than cygwin. I seem to remember they've
made some progress with the networking to make it appear as your own ip
(similar to cygwin) instead of needing it's own... but i could be wrong
about that.

-philip

 

[hemant]

I believe coLinux was mentioned a few times in that thread

--
Robert W. Oliver II
President, OCS Solutions, Inc. - Web Hosting and Development
http://www.ocssolutions.com/

Toll-Free Phone - 1-800-672-8415

OCS Ruby Forums - http://www.rubyforums.com/
My Blog - http://www.rwoliver.com/

"Austin is basically right -- *nobody* should use CygWin as a Windows
development platform/IDE/whatever."

Why? I have a case, where my office PC has only Windows and my
development machines that stores the projects and where my programs
run is Linux machines and I access it remotely through samba/putty.

I use Emacs extensively, call me naive if you will...but i needed X
Window with Emacs for certain lisp packages that i use. Then i looked
into Windows version of Emacs.

1. I needed latest Emacs from CVS -meaning got to compile the thing
2. Tried using W32Emacs...but since it was a binary install...few of
my lisp packages refused to work.


I already had cygwin installed..so i took the plunge..and compiled
Emacs from CVS under cygwin and it works pretty nicely.

Though i agree, you can't use cygwin to host your RoR projects..even
in development. But its fine..if you are using it as a IDE/UNIX
toolchain.

 

[Tom Pollard]

Austin is basically right -- *nobody* should use CygWin as a Windows
development platform/IDE/whatever.

Actually, I think Cygwin is a pretty reasonable platform for porting
Unix apps to Windows. It made it possible for my company to use our
Unix build system (make files and shell scripts) under Windows more
or less directly, without any radical changes. Not having to
maintain separate Unix and Windows build systems is a huge plus and I
don't think it would have been possible without Cygwin. (...at least,
not without much more effort.) One big win is that Cygwin tools are
flexible about pathnames, and typically accept either Unix-style
(forward slashes), Windows-style (volume names and backslashes) and
mixed-format (volume names and forward slashes) pathnames. MS
Services for Unix, in particular, is much less flexible in this
regard, it would have required a lot more work to port our shell
scripts to SFU. If I was starting a fresh project, I might try to
use a higher-level language like Ruby as the engine for cross-
platform builds, but that's not the typical scenario, at least in our
business.

TomP

 

[Austin Ziegler]

Actually, I think Cygwin is a pretty reasonable platform for porting
Unix apps to Windows. It made it possible for my company to use our
Unix build system (make files and shell scripts) under Windows more
or less directly, without any radical changes.

So. Is your company's product open source? Because if it isn't, and
you're distributing it, you're violating the GNU GPL for Cygwin1.dll.
In other words, if you're distributing your software on Windows with
Cygwin, your software is now infected with the GNU GPL.

-austin

 

[Tom Pollard]

So. Is your company's product open source? Because if it isn't, and
you're distributing it, you're violating the GNU GPL for Cygwin1.dll.

Thanks for your concern, but I didn't say we were using the Cygwin
DLL. We're using the Cygwin shell and Cygwin tools to build our
software as regular Win32 apps using Microsoft & Intel compilers;
there's no compatibility layer, beyond what we created ourselves (and
not much was required). The point was, Cygwin lets us do that with
the same build scripts and makefiles that we use for the Unix
builds. For the first Windows port we did, we used a Visual Studio
project that was maintained in parallel with the Unix makefiles; it
seemed like a good idea at the time, because it was the "Windows
way". It was a nightmare to maintain, however, and less transparent
and flexible than our Unix build system. Using Cygwin lets us work
from the same code base, using the same build system, on all
platforms. All of our Unix test scripts run under Cygwin, as well.
There was a little work required to get things to work seemlessly,
but it really works quite well. It's not perfect, and we've kept our
eyes open for better alternatives, but the ones we've looked at
seriously (like 'Services for Unix') seem to have worse problems than
the Cygwin-based system.

TomP

 

[Reid Thompson]

So. Is your company's product open source? Because if it isn't, and
you're distributing it, you're violating the GNU GPL for Cygwin1.dll.
In other words, if you're distributing your software on Windows with
Cygwin, your software is now infected with the GNU GPL.

-austin

Actually that would only be true if they were distributing it without a
cygwin license. RedHat does offer a license that allows redistribution
w/o requiring source code release.

 

[Charles Oliver Nutter]

Austin is basically right -- *nobody* should use CygWin as a Windows
development platform/IDE/whatever. And nobody should use CygWin for Ruby
or Rails work of any kind on a Windows platform, since everything you
need is available in native form (the One-Click installer, Instant
Rails, and a native Windows PostGreSQL).

However, someone (Larry Wall??) flagged laziness as a virtue, so I'll
ignore Austin's complaints about laziness and continue to use CygWin for
times when someone gives me 15 minutes to get a job done on a Windows
platform that would take me several hours or several days to do if I had to

a. Locate a native Windows tool to do it,
b. Install the Windows tool and
c. Learn how to use the Windows tool.

d. realize how maddeningly frustrating it is when the Windows tool is
only 80% correct in what it's doing and ultimately revert back to Cygwin.

There's also the Services for Unix, which provides a (very) limited set
of unixy tools, but when I'm stuck on Windows I too simply must have
cygwin. Anyone who believes there's a usable Windows equivalent for
every day-to-day unix CLI app is just plain wrong.

 

[Michal Suchanek]

d. realize how maddeningly frustrating it is when the Windows tool is
only 80% correct in what it's doing and ultimately revert back to Cygwin.

There's also the Services for Unix, which provides a (very) limited set
of unixy tools, but when I'm stuck on Windows I too simply must have
cygwin. Anyone who believes there's a usable Windows equivalent for
every day-to-day unix CLI app is just plain wrong.

I use msys [1] when I want something like unix environment on Windows.
To me it looks lighter than cygwin, and I get a toolchain that does
not require cygwin1.dll (which causes many compatibility problems from
what I have heared). But it may not be able to support some stuff that
works under cygwin.
I saw projects that use msys but I haven't built anything useful with
the compiler. I just use the shell and diff when I need that.

Thanks

Michal


[1] http://www.mingw.org/msys.shtml

 

[ara.t.howard]

I use msys [1] when I want something like unix environment on Windows.
To me it looks lighter than cygwin, and I get a toolchain that does
not require cygwin1.dll (which causes many compatibility problems from
what I have heared). But it may not be able to support some stuff that
works under cygwin.
I saw projects that use msys but I haven't built anything useful with
the compiler. I just use the shell and diff when I need that.

i've compiled both the gnu scientific library, narray, and rbtree packages for
use on a window box here at work using msys. all are immensely useful and
easy to compile under msys. fyi.

-a

 

[M. Edward (Ed) Borasky]

I use msys [1] when I want something like unix environment on Windows.
To me it looks lighter than cygwin, and I get a toolchain that does
not require cygwin1.dll (which causes many compatibility problems from
what I have heared). But it may not be able to support some stuff that
works under cygwin.
I saw projects that use msys but I haven't built anything useful with
the compiler. I just use the shell and diff when I need that.

i've compiled both the gnu scientific library, narray, and rbtree
packages for
use on a window box here at work using msys. all are immensely useful and
easy to compile under msys. fyi.

-a

Yeah, the R Windows folks use MSys and eschew CygWin. I should try
rebuilding Atlas under MSys. Now that I think of it, the Windows port of
LyX uses MSys too, so I probably have it already.