Cygwin in a Production Environment?

not-so-anonymous Anonymous Coward asks: "I'm working for a company that does all of its programming and script development in a Unix environment (90% of our work is either Bash or Perl scripts that communicate with an Oracle database). We've recently gotten a new customer and for reasons beyond our control, the server must be a Windows box. Since we want to reuse our existing scripts that we've spent a considerable amount of time developing, we're looking into Cygwin as an option. Has anyone run Cygwin in a production server environment for any extended period of time? If so, what were your experiences with it?"

Comments

using cygwin to run RSYNC

[stonebeat.org]

We have been using cygwin dll to run RSYNC on Windows servers without any issues.

Re:using cygwin to run RSYNC

[n9hmg]

Don't get me wrong, rsync rulz. I haven't used it myself, but I've heard cwrsync solves the remaining problems.
Cygwin will do much more, though - apache, postgresql(probably mysql too, but I haven't seen it), etc. - almost any unix app you can get the source for, you can compile(and use) in Cygwin.
I keep getting in jobs that require the use of windows. I'm a unix guy. I retain my sanity by doing everything in cygwin. I'm wasting an exceed license right now because while they can require that I have it installed, I greatly prefer cygwin X and fvwm. I build most of my applications in shell or perl, sometimes with fakes of the unix apps they'll run against, to feed in the inputs or take the outputs.

Specifically, you say your product is mostly Perl and bash? You write in two of the most-portable languages of all, and you're worried? Jeez, man, it's RedHat! I assume you're using db::oracle or some such perl module for your fancy work. Your porting is likely to be no porting at all, i.e., you'll probably be able to scp your stuff in and just run it without further work. The ease of acquisition and configuration of the platform is such that determining details is honestly trivial. Install, run, try your apps, tell us what you find out.

PostgreSQL on cygwin

[barries]

cygwin is a really nice emulation layer, but it is an emulation layer and is not 24x7 ready. The timekeeping and IPC mechnisms aren't fully reliable for production-ready use, IMHO. It is amazing for what it does.

We've been running several production PostgreSQL-on-cygwin servers and have been experiencing random corruption and poor timekeeping. There's a bug (hopefully fixed now) in cygwin timekeeping that causes a rollover after 49 days of uptime. PostgreSQL on cygwin also experiences odd table and index corruption problems that I've never seen with it on Linux/FreeBSD.

We're cutting to Oracle for business reasons, or we'd switch to the newly free Win32 PostgreSQL ASAP.

Have you considered MS' Services for Unix? We've not used it, but I'd be interested in hearing about how well it works.

- Barrie

Re:PostgreSQL on cygwin

[Electrum]

We're cutting to Oracle for business reasons, or we'd switch to the newly free Win32 PostgreSQL ASAP.

Why not run PostgreSQL on UNIX? Even buying new machines from a UNIX vendor (Apple, Dell, etc.) has to be cheaper than Oracle licenses.

Re:PostgreSQL on cygwin

[Anonymous Coward]

If you'd take off your "everything except OSS is teh sux" glass, you'd see that he answered your question already:

for business reasons

As for myself, there is one word that can explain why I'd choose Oracle over anything else: RMAN.

What are you doing with it?

[Eneff]

If you're just running shell scripts, you're probably going to be able to make the transition with a minimum of effort. Cygwin is a bit slow, though. It's good for most purposes, but don't depend on it to do more than administrative tasks.

At least, in my experience. I use it for development and it makes my life livable.

Re:What are you doing with it?

[MBCook]

There are other things to be aware of too. Cygwin is nice (I use it myself on my personal laptop) but you should look into the tools you want on Windows. Yes you can get bash and perl, but there are limitations to considder. For example, IIRC, the fork() call on Windows is VERY slow for some reason that I don't remember.

If the Windows environment becomes that much of a problem (and don't forget to try, as another poster suggested, things like Services For Unix (SFU)), set up a demo of the two things side by side to show the customer just how much more efficent running it on the Unix of your choice is than making it run on Windows. That might convince them if it comes to that.

Speaking of which, I would love to know WHY the client has to have Windows. Maybe there is something there that you can deal with that you don't realize.

Re:What are you doing with it?

[Atzanteol]

Speaking of which, I would love to know WHY the client has to have Windows. Maybe there is something there that you can deal with that you don't realize.

I'm not the original questioner, but may be able to give one plausible reason. Many slashdotters seem to have trouble grappling with this idea (Why can't your client just run Linux?). Typically a given client has existing infrastructure and admins. If they have lotsa Windows guys, they'll want a Windows box so they can admin it when you're done.

I work aa a consultant, and many clients will request an operating system that matches their existing systems. Unless you can really convince them otherwise, they'll look elsewhere if you don't come up with a solution on their platform.

Re:What are you doing with it?

[bofkentucky]

So you've got windows admins who are going to have to grok enough unix to get unix applications to run in a unix emulation environment on windows, but aren't good enough to maintain a "Real" unix systems, good luck.

Re:What are you doing with it?

[Eneff]

fork() is emulated in the windows environment - there is no exact windows equivalent.

as for windows-only shops, it doesn't make sense to have *one* unix box, and have to get training for *one* application.

I don't think windows is a superior server operating system, but there are instances (small businesses in particular) where it can be more cost effective.

Re:What are you doing with it?

[Eneff]

The developer's job is to make sure that the customer doesn't have to grok the unix. They just have to open up this window and type runme .

Re:What are you doing with it?

[Anonymous Coward]

fork() is also a really bad idea for a way to create a thread. It might have seemed conceptually cute in the 60s -- Hoare's CSP forks and joins, and all that -- but it should be obvious with hindsight that if I have Task A and Task B, I do not want to start Task A, which happens to also contain all of Task B's code and environment, make an exact duplicate of Task A, then test and branch to the Task B part, leaving all of Task A's code as dead weight in B while B is dead weight in A. It would make much more sense just to start A and B separately.

fork() makes slight sense if you want N duplicates of a given task. But you're probably better off in that case with one thread managing N objects than N seperate threads. The task overhead is a high price to pay just so that you can have some global variables instead of passing some sort of instance handle to your functions.

Just because Unix did it doesn't mean it was a good idea.

Re:What are you doing with it?

[Anonymous Coward]

The developer's job is to make sure that the customer doesn't have to grok the unix. They just have to open up this window and type runme.

And that, my friends, is what being a Windows admin is all about.

Re:What are you doing with it?

[cowbutt]

For example, IIRC, the fork() call on Windows is VERY slow for some reason that I don't remember.

UNIX is designed in such a way that process creation is very cheap, therefore lots of UNIX programs use fork to achieve parallelism. OTOH, Windows is designed around the threading model, so no particular attention has been made to make process creation similarly cheap.

More info at this link and this one.

--

Re:What are you doing with it?

[Atzanteol]

That's *very* simplistic, and may be true of your typical shrink-wrap application. But many business systems are much more complicated than that.

Large business systems (database, web server, lotsa business logic) need maintenance. DBA's to tune the database, backup old data, etc; admins to monitor the system, run jobs, monitor logs to determine that jobs are running properly, etc.

Often a client will want a developer or two to fix minor bugs that may arise over time, or to make minor modifications to the system.

This is not your Business App 1.0 that you pickup at the store.

Re:What are you doing with it?

[Eneff]

You mean... the kind I work on every day?

A database shouldn't depend on your environment, and is likely running on Oracle or DB2. (If it's running on Postgres, they're in trouble anyway.) The DBA is business as usual.

When modifications are made to the system (that's what the maintenance contract is for!) a developer is likely going to be on-site and making the change. If not, they should have an upgrade process that is as simple as "runme."

Re:What are you doing with it?

[salimma]

For example, IIRC, the fork() call on Windows is VERY slow for some reason that I don't remember.

AFAIR Linux (and probably other Unices?) is unique in this regard - fork() on Linux is similar to threads in Windows when it comes to overheads. But I read this 3 years ago so I might have misremembered it.

Re:What are you doing with it?

[Atzanteol]

Nothing ever goes wrong with the applications your write for clients? You keep clients 'forever' (and thus are always there to provide support)?

Perhaps my company is different. At some point we turn the system over to the client (if they want it), and leave. At that point their IT department (if they have one) takes over day-to-day maintenance and operating of the system, monitoring batch jobs, etc. For clients without an in-house IT department, we will maintain the system for a cost...

Re:What are you doing with it?

[Anonymous Coward]

The reason fork() is slow on Windows is that fork() creates a process in its own image.

For a Unix that is fine, because Unix kernels implement copy-on-write paging. In other words, the fork()'d process won't have to duplicate the process's memory until it's changed.

Windows doesn't have copy-on-write pages, so a proper fork() implementation has to duplicate the process's entire memory immediately after fork() is called. The vast majority of the memory will probably not change after the fork(), so this creates a lot of unnecessary work for your poor CPU.

Re:What are you doing with it?

[nyteroot]

Thats a cute bit of disinformation. For the benefit of any poor soul who doesn't know better, this has been patently untrue on Linux -- and my guess is any modern OS implementing fork() -- for a long time. Anything that you might consider "dead weight" -- i.e., A's information that B doesn't use or B's information that A doesn't use -- is kept in shared pages. So none of the "weight" is "dead". Furthermore, memory is actually saved, because information that both A and B use is not duplicated with this method.

SFU?

[m0rph3us0]

Services For Unix is now free.

Re:SFU?

[Anonymous Coward]

That should be STFU.

haha...

[Anonymous Coward]

...I remember when that was just a Windows bug...

Re:haha...

[frp001]

This one ? http://support.microsoft.com/default.aspx?scid=kb; en-us;216641

But that was Win98, surely they are non running a DB server on Win98.

Just Rembember

[I_Love_Pocky!]

No matter how well Cygwin works out, you still have to run Windows under it. Doesn't sound very "production server environment" ready to me.

Re:Just Rembember

[I_Love_Pocky!]

That's not flamebait, that was a failed attempt at humor...

Much better flamebait would be:

Cygwin is known to crash regularly, but not any more regularly than any other application running under Windows. Anyone who would run Windows on a production server is asking for trouble. Clearly your best course of action is to forget this Cygwin idea, and spend your time and effort changing people's minds about this whole Windows garbage.

See, I can do a real flamebait!

Compile your perl scripts?

[Wee]

I know this isn't quite what you asked, and it might only solve half your problem, but have you thought about compiling your perl scripts? I've had lots of cases where I've had to re-use unix-ish thing in a Win32 environment, and found that Perl2exe works pretty well. One of the scripts I had to compile for Windows involved the DBI stuff, a bunch of Crypt::OpenSSL modules, Tie::IXHash, XML::SAX, and a bunch of others. It works like a champ.

The main downside is that you get an exe with a perl intepreter in it. If you have more than one script to build, get the pro versionand compile them with the -small option. That will build a dll which contains the interpreter, and the compiled exes link to it.

As far as your shell scripts, I'm not sure. I've run scripts under Cygwin, but they weren't very complicated and so I wouldn't know much about reliabilty or performance.

-B

cygwin terminal

[timothv]

If you use cygwin, make sure to get a better terminal for it. Puttycyg uses Putty's great terminal emulator for cygwin, and it works rather well.

Re:cygwin terminal

[algae]

Cygwin also comes with a win32 native (ie, doesn't need Cygwin/X) rxvt terminal that's far far better that the default cmd.exe style cygwin terminal. You can also incorporate ssh-agent if you remote into lots of machines. Here's my startup shortcut:

C:\cygwin\bin\rxvt.exe -e ssh-agent bash --login -i

IIRC, rxvt isn't installed by default, but it's available under 'shells' when you run the cygwin setup.

Re:cygwin terminal

[The OPTiCIAN]

You might not get your PATH kept if you run as this user suggests. Here's my cygwin.bat file:

--
@echo off

C:
chdir C:\cygwin\bin

rem bash --login -i

rem c:\cygwin\bin\rxvt -geometry 80x60 -e cmd /c c:\cygwin\bin\bash --login -i

c:\cygwin\bin\rxvt.exe -sl 500 -geometry 80x46 -fn courier -bg white -sr -e bash --rcfile H:\.bashrc

non cygwin way..

[gl4ss]

http://home.wanadoo.nl/fvu/Projects/Bash/Web/bash. htm bash & windows faq/howto thingy and perl on windows google search .

Cygwin is Jus' Fine

[Giant Ape Skeleton]

My employer has been using Cygwin in production for quite some time now - we use it to get our Windows servers to act a little more...serverish :-)

I would recommend you use ActiveState's Perl distribution in conjuction with the Cygwin enbvironment.
It's reasonably prioed and well supported, without a lot of stuff you *don't* need thrown in.

Re:Cygwin is Jus' Fine

[CyberVenom]

Actually, if you don't spring for the extras, ActivePerl is free (As much as ActiveState would like to prevent you from realizing that). The package that includes the .exe compiler and the service compiler costs money, but the base free package covers pretty much exactly the same functionality as you get on Unix systems with the additional benefit of being able to use some Windows-native features like OLE and ODBC.

Maybe

[zatz]

I use Cygwin all the time, and I would say that it doesn't feel quite solid enough for production. The only long-lived processes I run in cygwin are xinetd and sshd, and I've occasionally seen sshd crap out. On the other hand, I've been using it daily for 8-10 months to run a CVS repository and several clients, and not had one problem with that.

It could be that my poor impressions of reliability are based on older versions (I've been using it since B19 or so) or a few buggy packages. Most of the weird errors I've seen are due to Cygwin's filesystem games; if they would stop trying to name executables .exe, and use some other mechanism for storing symlinks (NTFS reparse points maybe), that would help greatly.

I don't use Perl much myself, but one-liners generally work as expected. A surprising number of Unix scripts and programs work without any changes under Cygwin; why not just set up an instance of your software on it, and see what happens?

Re:Maybe

[d00dl3]

Cygwin suffers a lot for its slowness on File i/o, hence, it's not so proper to use it as cvs client for large project. My suggestion is to use wincvs on windows, that's much better.

Best is the enemy of better.

Cygwin + Unison

[ch1rd]

Cygwin is an integral part of a remotely managed windows-based touchscreen information network we've deployed across Scotland. It's been running without issue for almost two years now, on about 30 WinXP machines. In fact, just about everything else has gone wrong throughout this time thanks to viruses and shoddy supplied hardware, but Cygwin quietly does it's (admittedly simple) job.

VMWare? Either Way?

[4of12]

What about the possibility of either running Linux inside VMWare on a Windows machine or the reverse?

Admission: I don't have recent direct experience with VMWare myself; it used to be that the two systems needed different IP addresses, but I don't know if that would keep within the constraints your customer wants to impose.

[My two cents: the constraint sounds overly artificial. A network-presence appliance that's secure and does its job is good enough for most people. Think of network printers, for example. It's not like every single active IP presence is going to need a Windows XP update...

Finally, I've heard some people express a preference for MinGW over Cygwin for some reason...

Re:VMWare? Either Way?

[tyndyll]

Another option is coLinux. Almost the same as using VMWare without the cost. From the site -

Cooperative Linux is the first working free and open source method for optimally running Linux on Microsoft Windows natively. More generally, Cooperative Linux (short-named coLinux) is a port of the Linux kernel that allows it to run cooperatively alongside another operating system on a single machine

I've been using it with the Debian image in recent days with few problems. Check out the Manager as well

Why not run your UNIX OS under Windows?

[DiSKiLLeR]

Use VMware or Virtual PC (Virtual PC is from Microsoft, too! so they should be happy) and run whatever unix OS you're using inside Virtual PC (or VMware) and you're happy and they're happy.

I dunno about CGYWIN, i wouldn't trust it....

Re:Why not run your UNIX OS under Windows?

[sirvulcan]

thats a bit of an overkill just for running some perl scripts (assuming thats all they plan on running according to the article text)

Larger thoughts...

[ComputerSlicer23]

I think Cygwin will work just fine. I've known a number of people who used it for extended periods of time. It'd be more helpful to know precisely what it is you are planning on doing to know for sure if it will work.

However, in a larger context:

Uhhh, you are taking on a customer for whom you have no tools and no infrastructure for? Who doesn't fit your current model, and fundamentally doesn't fit how you do business? Unless you are laying the ground work to bring in lots more revenue at a lower cost in the future, this might be stupid to do.

Now, a company has to grow, but remember the princepal that says, "Not all customers are profitable". You don't want customers who don't make you money. I remember a story about an advertising company that eliminated 70% of their existing customers and have revenue plumet, but their profits jumped by 30% (as a dollar value, not as a percentage of revenue, they made 2.5Mil instead of 1.5Mil in profit, I believe revenue went from 30Mil to 12Mil).

I know on more then on occasion, the smartest thing the guys in charge where I work is to fire customers. Some customers aren't worth the time or the trouble to deliver service to.

This isn't an anti-Window post, it's merely a matter of considering weather or not this is an area you are planning to expand into, or if this is a one-off, non-scalable solution for a single customer just to get the business.

We run into this quite often, around it's driven by sales people whose sales goals are about bringing in revenue, not bringing in profit. If it costs us $1000 in to bring in $500 in revenue, that's a stupid business proposition. If it's a big chunk of revenue, and you can build it while making money go for it.

Kirby

Re:Larger thoughts...

[duffbeer703]

You need to work cross-platform. If you are selling appications and don't offer Windows support, you're essentially cutting out a huge slice of the market.

Re:Larger thoughts...

[Stinking Pig]

Any salesweasel worth the oxygen they breathe is working to the compensation plan put together by their VP and usually blessed by the executive staff. If they're not working to the comp plan, they're too stupid to even act in their own interest, much less in the company's interest.

In other words, while it might be a rogue salesweasel causing the problem, it's more likely to be an idiot sales manager. Most likely of all: an executive team with dreams of going public and cashing in buckets of pre-IPO stock... in order to make revenue growth look good, they're pursuing bad business. Probably doing a number of other stupid and shady things too, such as fudging their accounting and stuffing the channel to make it look like each quarter's doing better than it really is.

I wish bad management was rare...

Cygwin Threading problem

[a11]

Under Windows XP only, cygwin dll has a problem with locking threads after they have terminated.

If you spawn a bunch of processes (such as in a common loop), each of those will use up at least 1 TID. Any call to create new threads made through the cygwin dll makes that TID non-reusable in windows, and will eventually crash your box.

Shell Script that crashes your box:
integer i=70000
while ((i -= 1)) ;do
echo hello\\nworld | cat|cat|cat|grep h >&- #spawn some processes
done

While cygwin has its problems, I've had many more w/ Services for UNIX

Re:Cygwin Threading problem

[Anonymous Coward]

Have you bothered reporting this to the cygwin developer's list?

Re:Cygwin Threading problem

[Elwood P Dowd]

I think you win for most unnecessary uses of cat.

Re:Cygwin Threading problem

[Chuck_McDevitt]

The Threading problems have been reported.

Right now, the primary developers don't have a hyperthreaded or SMP machine free to use to reproduce the problem.

Re:Cygwin Threading problem

[cgf]

But we'll certainly appreciate the donation of a hyperthreaded machine...

CYGWIN running on production servers...

[IamInsane]

I work for a relatively large Credit Union and we currently run CYGWIN on many of our production servers to communicate with our UNISYS host. It's running in a 24x7 environment and has given us no problems. We do restart the web hosting services once a night (mostly to change log files).

We use it to interface with both Oracle and MSSQL databases. Again we have found little to no problems at all running on production hosts.

Apache under Cygwin

[Radical Rad]

If you will need to run Apache 1.3 under Cygwin, watch out for the path traversal expoloit. It supposedly only shows up under Cygwin but you can work around it by setting filesystem permissions carefully.

UNXUtils and ActivePerl

[Youssef Adnan]

Well.. If most of what you have is shell and perl scripts, you can always get

• UNXUtils http://unxutils.sourceforge.net/ and
• ActivePerl http://www.activestate.com/Products/ActivePerl/.

They always did the trick for me...

Re:UNXUtils and ActivePerl

[dolmen.fr]

UNXUTils seems to be not maintained.

However I use Win32 ports of GNU (and non-GNU) tools from GNUWin32.
They are quite up to date with frequent releases.

Get the permissions right

[dr_leviathan]

One problem I've noticed using cygwin as a development environment with a bunch of Windoze programmers is that cygwin is more particular bout the permissions on the files than the Windoze double-click. That is, cygwin needs the executable bit set, where Windoze doesn't care. This can be frustrating when you have scripts calling other scripts and the permissions are wrong somewhere deep in the heirarchy.

While this might not affect you if you are setting up the directories yourself, it might bite you if your customer uses the mouse to copy new scripts into the directories from a non-cygwin environment.

Some glitches but overall OK

[Lomby]

I use Cygwin to run under Windows a rather complex apllication that is developed under Linux.
Everything goes well, but there are some small thing to notice:

- the performance usually is comparable to that on Unix. Sometimes I get the impression that the network operations are a bit slower (just an impression, but it repeats itself)

- some libraries/applications may need shared memory: configuring the ipc-daemon (or cygsrv), which provide IPC share memory, is sometimes rather tricky. Once they are configured, they work without problems.

- sometimes you get a weird remap error when trying to link or load some libraries. There you have to use the rebaseall utility, which will fix the conflicting addresses

- Cygwin comes with X windows, which can greatly simplify your life.

- The default Cygwin shell is ugly and lacks many capabilities: it is better to install rxvt (which does not need to have X installed) to have a very Unix compatible terminal.

Interix, not Cygwin

[mirabilos]

I highly recommend that you use Interix
(www.microsoft.com/windows/sfu/) instead
of GNU cygwin, and ksh instead of GNU bash.

For connecting to Oracle from ksh using
co-routines, a feature which bash doesn't
have (besides ksh using _less_ memory and
being _much_ faster on string ops), see
https://MirBSD.BSDadvocacy.org:8890/cvs.cgi/c ontri b/samples/codesnippets/oracle-ksh-access.shar

For a portable version of a highly modern
pdksh derivate, the project has released
http://wiki.mirbsd.de/MirbsdKsh - it works
under Interix with no patches.

Re:Interix, not Cygwin

[Anonymous Coward]

pdksh is downloadable from the cgywin setup utility.

Re:Interix, not Cygwin

[mirabilos]

Yes, but that was not the point. Cygwin sucks - /bin/ls.exe? excuse me?

Re:Interix, not Cygwin

[Anonymous Coward]

Cygwin sucks - /bin/ls.exe? excuse me?

Er, and to run it you type "/bin/ls" just like on Unix. The only time the .exe suffix enters into any equation at all is when you're copying files around, and I can count the number of times I've wanted to do anything with /bin/ls OTHER than run it on the fingers of one head.

Re:Interix, not Cygwin

[mirabilos]

I'm system engineer, not a user. From a library
programmers' standpoint, this sucks.

In fact, I'm thinking of porting most of the
userland portion of our OS to Interix, because
it looks like it's easily possible (except from
the object format being PE, not ELF, of course).

Perl on Windows

[Josh Mast]

If you're using a fair bit of Perl on windows you probably want to use Active state Perl. It's pretty nice, and you'll have no problem installing pretty much any module you'll need. If your scripts are written well (i.e. not doing platform specific system calls) then porting will be almost a non-issue.

Re:Perl on Windows

[tarquin_fim_bim]

Are you saying that any Perl script constructed with platform specific system calls is badly written? That seems a rather blinkered viewpoint.

Personal experience

[consolidatedbord]

At one of my clients, there are about 9 solaris servers that run headless, but have a few applications that are X based. All of the windows servers are hooked up to a KVM, so I put cygwin on one of the windows boxes, set it up to auto-login and start the X server (prodiving you are at the console, and not thorugh terminal services) and start acceptings connections from the defined servers.

Not quite the same situation as yours, but I think if it can handle running an X server (stable, for the past several months) it should be able to handle some bash/perl scripts.

Good luck.

Good emulation is no substitute for polish

[Cecil]

For most intents and purposes (all that I've come across), cygwin is effectively seamless, and is at least as reliable as Windows is.

Obviously, though, you should take an intelligent approach. Some things don't make much sense to run under cygwin. cron comes to mind. It's available, but if you want it to be a little more integrated, I'd invest a little bit of effort to get those things that need to be cronned running as a windows service or under task scheduler or something native to Windows. Not only will it be more efficient and more intuitive for the Windows admin, it may be more reliable too. There are plenty of other examples too, I'm sure.

Anyway, cygwin will have no trouble at all handling the scripts, but I don't think simply dropping everything into a cygwin installation is the nicest way to go. Put a little effort into it and cygwin will serve you well for the rest.

Cygwin's ssh under XP has issues

[Kevin Burtch]

I tried numerous times today to scp a 1MB file from an XP box running the current version of Cygwin to a Linux box (#1) with the most recent OpenSSH.
It would xfer a random amount (0-43%) and hang every time I tried.
I finally ended up using Linux's SMB mounting capability to access the file and used the Linux box (#2) to scp the file - no problem.

The XP box and 2nd Linux box mentioned are on the same network, the 1st Linux box (that I was trying to scp to) was on another network many hops away.

I have no idea why it would hang every time, but I went to check the installed version using Cygwin's setup tool and it said openssh and openssl were both current.

Tell you what... install the software on Linux and provide the customer with the BSOD screen-saver, they'll think they got MS-Windows. ;)

Re:Cygwin's ssh under XP has issues

[Anonymous Coward]

I do this all the time with no problem. I see that no one has brought up the fact that the file versions are totally messed up and it all depends on which FTP mirror you choose. Use WinSCP3.

win4lin, co-linux?

[cwg_at_opc]

i have a similar issue: i have some semi-RT apps that were written by a vendor for
WinNT(and XP) - and not having tried either(i'm an end-user, not an admin, so i can't tinker... ;-),
there ought to be a good way to utilise one or the other to achieve acceptable results in a
production environment.

before anyone gets all huffy about XP, it is fairly stable, can be configured to be relatively
secure(!) and, a recent LinuxFormat Magazine had a co-linux/Gentoo dist on it.

anyone try either one out? philosophically, i'd prefer to use win4lin, but realise that it may be
more practical to try co-linux because of the peculiarities of XP(wierd system calls, etc.)

24x7

[sICE]

Hi,
I already made a post in a thread about SFU that was looking like (disclaimer: i love cygwin):

1) WSFU is faster (IO/API/...)
2) WSFU is better integrated with win32 architecture (OLE/ODBC/...)
3) WSFU make a lot of things easier than cygwin with windows

BUT, i wouldnt trade cygwin for it, note that i have both installed here. I just isolated what i needed from WSFU and was better than cygwin and added them last in my path. I dont have any preferences, but cygwin is waaay more complete, and you have the +/- the same versions of the application that runs on linux. Same config files work fine, same behaviours (which isnt the case with WSFU), etc.

For me, WSFU is just a little + to cygwin.

Now bout your particular problem (prod env, 24x7), I've experienced very few problems running CygWin in such an environment. I use it since at least 5 years (I remember downloading it at 56k, so it's probably more), but there's some things you need to be aware with cygwin:

• Versions of the applications you run: they often differs from what you're used to. Sometimes I ended up with different settings between solaris, linux, win32, etc. This is generally fixed with a recompile of the common denominator version, possibly the latest one.
• Performances: As you probably noticed from the other posts, cygwin is an emulation layer. It is slow. And I really mean slow. Something you usually do in nunux in a few seconds might take a few minutes on win32 depending on how it is coded. Forks and threads are really badly implemented. Yet nobody else did better.
• Alternatives: Frequently natives win32 programs are faster, better, or both. Have a look on google after alternatives (adding +win32 +unix, and +free if money is a problem). It will save you some time. Maintaining several branches of your scripts might be a good investment, if you factor out the common base, and manage to get them do what they should on different platforms while compiling/installing (and anyway if you start nunux/win32, you might as well just do that, you'll end up with the pot). Though it perhaps require another employee, it's worth it. For cygwin alternatives I'd recommend the SFU (of course), Mingw, GNU utilities for Win32
• The DLL Nightmare (Take II): If you dont need too much apps (.exe) relative to cygwin it could be good to just use those. Compile the stuff you want in cygwin, and modify the $INSTALL path, so you can just take that to another machine. The DLL hell here is that you'll probably not only need the cygwin dll but some more... If you have quickview installed on your machine, you can see what DLLs a program use in its Import Section (from the PE header). Else i would recommend OllyDBG (free) or PE Explorer ($$$). Both can lists what DLLs an app use, just find them, and copy them in the folder, et voila! you can use it elsewhere.
• Perl: DO NOT USE the cygwin version of perl, unless you have a really good reason to do so. Instead use Active Perl It's damn faster. If it's called from bash then put #!/c:/perl/bin/perl5 -- or where ever you installed it). Some other things to know about active state perl on win32:
  • Hiding the cmd.exe box when running a script: Instead of putting '.pl' at the end of your scripts, try '.wsf' and have a look at the examples given by ActiveState:
    <Job ID="MyJobID">
    <script language=PerlScript>
    # ... your code here ...
    </script

Re:24x7

[sICE]

I forgot a damned trap:

• NTFS handle hard links: cygwin let you make new files with the same node than another one, but sadly, they usually breaks because most win32 programs first rename a file (to make a backup, instead of making a copy) and create a new one.

Re:24x7

[duffbeer703]

Sorry for being off-topic, but yours is probably the best Slashdot post I've read in 2-3 years.

Thanks.

Re:24x7

[sICE]

Thanks a lot :-) Sorry for being off-topic, but compliments like that would perhaps help the /. crowd to make better posts... erm, in 2-3 years ;)

Re:24x7

[Anonymous Coward]

cygwin's own cygcheck program will list dll dependencies

Re:24x7

[cgf]

>Versions of the applications you run: they often differs from what you're used to. Sometimes I ended up with different settings between solaris, linux, win32, etc.

This is pretty much common sense. If you are using a different version of program X on platform Y, you may run into trouble. Well, duh.

>Forks and threads are really badly implemented. Yet nobody else did better.

Odd how you would make such a strong statement with no apparent understanding of how "fork and threads" could be implemented better.

"threads" are just Windows threads. It's hard to see how they could be implemented as anything else.

>No compatibility: NEVER trust that if it will work with nunux, it will work with cygwin,

It's generally true that you should never trust that something will run just because you happened to get it working on some *NIX variant. This is true of HP/UX, Ultrix, SunOS, and Cygwin.

>The DLL hell here is that you'll probably not only need the cygwin dll but some more...

Yeah, cygwin apps rely on shared libraries, just like linux/*nix apps do. So, if you build your program to use a shared library, guess what? You have to make sure that the shared library exists on the platform that you're going to run the program on. Again, this is common sense. What seems to be tripping you up is the fact that you can't expect cygwin to be installed on every Windows system but you do stand a good chance of the shared library you want being installed on another linux system.

Re:24x7

[sICE]

This is pretty much common sense. If you are using...

Now bout your particular problem...

Now, what is really common sense is reading the thing you try to troll on...
Guess who is in the middle of the crowd, and that peoples are looking at with a (little) smile?

Re:24x7

[cgf]

"trolling" == "making salient points"

I don't have to troll. I am one of the project leaders for cygwin. I understand the issues very well. Most of the problems you describe are just generic problems with porting to another system. Perhaps you have little experience porting between systems and are unaware of this.

Cygwin's fork is certainly slower than UNIX's fork, but since you lack any understanding of Cygwin fork internals, your assertion that it is badly implemented is uninformed. I thought people should know that.

Re:24x7

[ulrikp]

If you have quickview installed on your machine, you can see what DLLs a program use in its Import Section (from the PE header). Else i would recommend OllyDBG (free) or PE Explorer ($$$).

I can recommend the HT Editor for editing all sorts of executable files (Windows and Linux/Unix).

Ulrik

Re:24x7

[sICE]

Ouch, my head hurts... I should never be left with a keyboard around when I'm drunk... First of all, I'm sorry for the rude reply i did and i ask you to excuse me.

In the original post i was trying to highlight the "do" and "don't" one needs to know when working with cygwin. The hard links for example is one problem peoples frequently stumble on. Most of the things you underlined are, of course, common sense. I just end up running into smart ones that think common sense is something only happening to other peoples... possibly when they're asleep, or dead, or both...

For the fork/thread problem, yes you're right again i never put my nose into cygwin source, and probably shouldnt talk of it that badly. Yet it is something peoples should be aware of when considering cygwin for a production environment. Seeking for alternatives isnt probably a too bad idea. I did such a statement because under cygwin i always end up trying to fix problems with programs using forks. Perhaps i am doing something bad, but perhaps cygwin is having a flaw there. I just dont know. Yet i think i'm quite able to find out if a program is badly written, or if it is the underlying system that makes something wrong... To finish this up, generally an afternoon modifying some lines in the code (and taking some fresh beers with a friend) is worth making it compile with .net studio. It works fine and is faster than if i make it under cygwin.

Sorry again for 14-year-old-stupid-reply i did before (and probably for this one too, cheers ;-)).

Re:24x7

[GCP]

I don't have to troll. I am one of the project leaders for cygwin. I understand the issues very well....

So why didn't YOU answer the OP's question instead of merely criticizing other people's answers?

Of course I may have missed your answer because the posts can be read in several different orders. It's possible that you provided a great answer and I just haven't reached it yet. Apologies in advance if that's the case, but so far I haven't seen YOUR answer, though I've seen more than one of your comments on other answers.

Your criticism of this guy's answer, though, makes me think that you're more interested in defending cygwin than in being helpful. The OP wanted to know what problems he might have to deal with if he tried to use cygwin for production, and he didn't say, "please don't mention any problem that might be considered common sense to people with lots of experience", did he?

Re:24x7

[cgf]

I found out about this thread rather late and had little to add, especially since *I* don't run cygwin in production. I did clarify another point in the discussion, however.

Of course I want to defend cygwin against charges like "fork is poorly implemented". I don't know why I have to explain this but if someone blindly criticizes something you contributed to without offering any supporting details, you don't just let the criticism sit. We're happy to hear about improvements to fork assuming that they aren't the same-old suggestions that have been showing up in the cygwin mailing list for the last five years. Vague criticisms could well leave a reader with an incorrect impression of something that has received a lot of attention from cygwin developers over the years.

I also thought it was useful for people to know that the other issues were just normal problems that you would find moving between two different versions of *nix. Often people spend time on linux, move to cygwin, have problems, and think "Aha! I've found cygwin incompatibilities."

What I was trying to make clear is that you would have similar incompatibilities moving to HP/UX or Tru64 or even another version of linux. You can't expect that if you built a program using Red Hat Linux 7.3 it will run without problems on Red Hat Linux 9. You could well have issues with the fact that there are different versions of bash or because there are different shared libraries available.

I do apologize for using the term "common sense" since it is an implied slight indicating that if someone makes a point they lack common sense. Obviously issues involved in porting to other platforms are not obvious and deserved to be discussed. Cygwin does have some unique issues not common to linux (like filename case sensitivity, tcp/ip issues, permission problems) but most of the issues listed were not cygwin-specific.

Finally, it might be a good idea to ask this question in the cygwin mailing list. You won't reach as wide an audience as here but you will hit many people who have spent a lot of time on issues like cygwin reliability in a production environment.

It's pretty reliable

[Anonymous Coward]

IBM/Tivoli used cygwin all over the place in older versions of the Tivoli Management Framework & Monitoring. It works great.

Unix for Windows from ATT

[caesar79]

If cygwin is not upto production standard, then maybe you can evaluate Unix for Windows - it was originally an ATT labs product - but now seems to have been sold. You can download a non-commercial version for free (as in beer). Check it out at http://www.research.att.com/sw/tools/uwin .

GPL Warning

[Eil]

If you can get past the horrible, horrible installation, Cygwin is a pretty nifty piece of kit.

However, in a commercial environment there is one tremendous downfall to using Cygwin. The Cygwin.dll library that does all of the translation from Unix to Windows system calls is under the GPL. NOT the LGPL. This means that if you write an application and build it against the Cygwin libraries and plan to distribute it, the only license you can legally put your software under is the GPL. This is the only case of the "virulent" nature of the GPL that we've witnessed firsthand and I must say it is a particularly nasty one.

For more info:
read the FAQ.

Re:GPL Warning

[Anonymous Coward]

IF you want to develop non-open source commercial software with cygwin then purchase a license. Red Hat sells them, see http://www.redhat.com/software/cygwin/

Re:GPL Warning

[The Lord of Chaos]

If you need to use cygwin in a commercial setting where you don't want to license your source code under the GPL then you should consider getting a cygwin contract.

Re:GPL Warning

[duffbeer703]

Shell scripts aren't linking directly to the library, so GPL shouldn't be an issue to the OP.

Re:GPL Warning

[Haeleth]

The Cygwin.dll library that does all of the translation from Unix to Windows system calls is under the GPL. NOT the LGPL. This means that if you write an application and build it against the Cygwin libraries and plan to distribute it, the only license you can legally put your software under is the GPL. This is the only case of the "virulent" nature of the GPL that we've witnessed firsthand and I must say it is a particularly nasty one.

This is NOT TRUE.

"In accordance with section 10 of the GPL, Red Hat permits programs whose sources are distributed under a license that complies with the Open Source definition to be linked with libcygwin.a without libcygwin.a itself causing the resulting program to be covered by the GNU GPL.

"This means that you can port an Open Source(tm) application to cygwin, and distribute that executable as if it didn't include a copy of libcygwin.a linked into it. Note that this does not apply to the cygwin DLL itself. If you distribute a (possibly modified) version of the DLL you must adhere to the terms of the GPL, i.e. you must provide sources for the cygwin DLL."

(Source: http://cygwin.com/licensing.html)

Re:GPL Warning

[Eil]

IIRC, he said shell scripts yes, but also vaguely alluded to other kinds of development as well. Even if they *are* just doing shell scripts for now, once they're using Cygwin on a more permanent basis, they won't be able to move to C or C++ programs.

Re:GPL Warning

[Eil]

What's not true about it? I said that if you link against the cygwin dll and then distribute the result, the only license you can put your work under is GPL. The two clauses that you pasted support that, but also add the phrase "complies with the Open Source definition" which just looks like a summery of the GPL to me.

I got bit on Cygwin when I wanted to distribute a Cygwin-linked binary under the BSD license, which does NOT comply with the "Open Source" definition as stated by the GPL, Red Hat, and Bruce Perens. (Despite the fact that it is technically the most free software license there is, short of public domain.)

Re:GPL Warning

[Eil]

Yes, I will admin that I missed that point. My argument draws from a previous experience of my own where I wanted to distribute a Cygwin binary for a C program that I wrote and put under the BSD license. The BSD license does not conform to Red Hat's definition of "Open Source" and buying a commercial license for my tiny (but useful!) program would have been impractical.

The 49-day limit.

[devphil]

This is the same bug that occurs in native Windows 95, I believe. I think it's fixed in newer Cygwin DLLs.

Re:The 49-day limit.

[dealsites]

Not to bash open source products, but if you find a problem how are you going to go about getting it fixed? Sure you might be able to code around the problem, but you don't have any support contracts to really get it fixed.

--
New deal processing engine online: http://www.dealsites.net/livedeals.html

Re:The 49-day limit.

[einhverfr]

You want a support agreement? My company sells them :-)

http://www.metatrontech.com

Re:The 49-day limit.

[bedessen]

Yes, it was fixed some time around 1-July-2004. See http://www.cygwin.com/ml/cygwin/2004-07/msg00015.h tml. Try a snapshot if you want to test this.

The Cygwin vs MinGW thing

[devphil]

Cygwin basically adds a nice layer of POSIX functionality to the Win32 subsystem. (Don't even mention "Windows has POSIX" -- it's a seperate subsystem, it's broken and incomplete and not going to be fixed, MS just added enough to be able to say to the US government "yes, NT is POSIX" with a straight face, so that they qualify for defense contracts.)

It also adds bunch of other things (mount points, IPC, etc), but the POSIX/*nix features are the main part of the DLL.

The downside to the layer is that it's very slow. This is not always Cygwin's fault; some of the Win32 calls that have to be used to get correct Cygwin behavior are slower'n hell. One of our customers uses a GCC hosted on Cygwin, and it spends a lot of time in the Win32 code, just waiting.

The MinGW system is the same idea, but without the special DLL, without the layer, and therefore using only the features offered by native Windows. A lot of nice stuff is unvailable that way, but it's faster. After moving the customer's GCC to be MinGW-hosted instead, they reported serious speedups.

(There's also MSys, which is MinGW plus some other stuff; I'm not really sure what it does. It's all explained on their website.)

Re:The Cygwin vs MinGW thing

[cgf]

Msys is just an older version of cygwin with some additions that purportedly make it easier to use with mingw.

The last time I checked, msys was slower than cygwin.

inodes

[eraserewind]

I had some problems with inodes not being unique in earlier versions of cygwin (this caused problems in a very large "make"). This has been mostly fixed though as far as I can tell. The last version a few weeks ago I tried only had 2 non unique inodes in the filesystem for 2 files that were "the same" but stored in different locations.

Other issues are that it's better to do everything in cygwin, or everything in windows rather than mixing the two, as translating the paths from one to the other can cause a lot of annoyance. Personally I'm veering towards the opinion that, at least for what I do, it's better to use native windows versions of the GNU tools if you can find them rather than the cygwin ones.

Support and Open Source

[cbr2702]

Re-read the GP's post. This bug has been fixed. So what do you do if you find a different bug? You submit it to the maintainer of the program, and they'll try to fix it. That is the exact same thing you'd do with a closed source product. As for support contracts, if you want one, you can usually find someone who will sell you one.

Cygwin?

[__aafkqj3628]

Are you sure you want to be considering cygwin for a production environment?
Microsoft has their Services for Unix (SFU) at version 3.5 and is now free for download. I'd say that in a mission-critical environment, SFU is much more rock solid and production-tested than cygwin.

(And if you're going to bash it just because it bears a Microsoft name, just remember that technically it's only sold by Microsoft and developed by someone else).

Best bet is probably Cygwin

[einhverfr]

SFU is great and may be needed in addition, but you can't mix UNIX and Windows executables in your scripts with it. Cygwin allows this. So the SFU shell is more like a VMWare installation than Cygwin, which may reduce the usability of your scripts.

But it depends on what you need.

MKS

[Anonymous Coward]

It's not free but there is also MKS http://mkssoftware.com/

cygwin - sfu - mks

[witte]

I had a similar problem with a customer needing code ported from unix to windows 2000, with some unix specific stuff in the code like forking processes etc. (This was about two years ago)
I looked around for several solutions and came across cygwin, which did the job.

The problem was that at that time it was property of Red Hat [http://www.redhat.de/software/cygwin/support/], who apparently were busy with anything but cygwin. Their website said something about $100.000 or something for a developer license, which was out of the question. Emails I sent were not answered, and i had to abandon the idea.

Similar story with Microsoft. The *one* guy i managed to get hold of wasn't even aware they had a product named Services For Unix. (Hello ?)

Different story with MKS. Unfortunately their toolkit was over-budget too, but at least they were trying to help me, and trying to sell me a product I needed, and very polite and helpful.
(Kudos to miss K. :)

I hope for their sake they got their act together at Red hat about cygwin now, cause they probably missed an opportunity to make some bucks and more importantly get a foothold in a big japanese electronics company's development division.

Re:cygwin - sfu - mks

[Anonymous Coward]

I believe the license was around $12000 last time i checked -- a bit of a while ago.

Re:cygwin - sfu - mks

[Chuck_McDevitt]

Redhat hasn't sold Cygwin for a long time. The only Cygwin is the free, unsupported one. Redhat still supports the project, by hosting web sites and I believe *one* developer who works on it. Otherwise, It's all supported by volunteers.

My thoughts on Cygwin (and ActiveState Perl)

[mikehoskins]

I've used Cygwin for years and they'll have to pry it from my cold, dead fingers -- unless they convert to Linux from Windoze. ("They" is anybody that makes me use Windoze on the Desktop but still gives me admin capability to my Windoze box.)

It's pretty stable, but I don't know if I'd trust it for mission-critical work. Again, I don't trust Windoze for mission-critical work, either.

The fact that Cygwin usually runs as an app on top of Windoze and that it usually likes to run in a console window on top of a real desktop makes it less stable and is a non-replacement for Linux/Unix, for sure. I'd take it over MKS or Hummingbird Exceed in a heatbeat, however, for functionality and performance reasons, alone!

It's definitely better than VBA or OLE, for stability and automation of the things it can automate. OTOH, ActiveState Perl is, too, and it can hook into Windoze pretty well. I believe that ActiveState Perl, if you can run your apps on it, would be more stable, but less feature-rich than Cygwin. You may want to use ActiveState Perl, instead.

However, has the author considered this option?
http://www.redhat.com/software/cygwin/

RedHat sells support contracts. Also, the RedHat license for Cygwin is REQUIRED if you commercially distribute cygwin or its apps.

Re:My thoughts on Cygwin (and ActiveState Perl)

[Anonymous Coward]

Wow, spelling Windows 'Windoze' gives what you're saying a lot of credibility. What are you, 12?

Again, I don't trust Windoze for mission-critical work, either.
Ha. My previous job involved over 5000 Windows 2000 servers processing over 3.2 trillion dollars in Internation stock trades every day, and we had 0 problems. Not even when NIMDA came out and shut down a majority of Win networks. I now work in a bank, and we use Windows 2000 and 2003 on over 3000 servers located world-wide to process transactions, transfer funds, and a majority of what banks do - again, we've had no problems.
Sure, Windows can be a bitch if your admin team doesn't know where they're doing but *GASP* so can Linux/Unix. Get your head out of your ass and grow up - taking your whining ass somewhere else. We don't need your bitching Win95 using ass here.

VBA? wtf would you use VBA? WSH is a lot better for system admnistration tasks.

Not necessarily

[V. Mole]

It depends on the application, the cost of being cross-platform, and the potential value of the expanded market.

The likely answer is really that you can't afford to be cross-platform. Good cross-platform development is expensive. It's *not* just a matter of coding everything in (say) MONO/GTK#. You have to have installers for each platform. You have to have documentation for each platform. You have to have support for each platform. You have to have test infrastructure for each platform. It just goes on and on and on.

Therefore, if you have an application that makes sense on Windows, the market for non-Windows versions is so small that it's silly to waste the money and time to be cross-platform. Alternatively, if you have an app that is going to be Unixy, then just get the Unixy one right, and go after that market. Your revenues might not be as large, but I bet your profit margins will be better.

Sure, there are exceptions. But general statements like "you need to be cross-platform" means you probably haven't really thought about your target market and don't have any how much cross-platform really costs. (Just to be clear: running on a few different Unix variants isn't what I'm talking about, although even just that adds a surprising amount of effort.)

We use it in production -- but there are issues.

[Chuck_McDevitt]

We use Cygwin in production environments.
We have been very pleased with the functionality.

But, we have run into one major bug. On hyperthreaded machines or SMP machines the Cygwin1.dll has threading bugs.

These cause random errors, crashes, and hangs.

Since Cygwin is free, and supported by volunteer effort, there isn't any guaranteed support (other than the standard OSS mantra "You have the source, so fix it yourself!")

If you can live without guaranteed support, and understand that there are some bugs, Cygwin is a nice product.

Re:We use it in production -- but there are issues

[asahetter]

<offtopic> That exact mantra is one of the things wrong with the open source mindset. Not all the users of the product are programmers so they cannot fix it themselves.

Also, of those that ARE programmers how many of them will actually take the time to fix the problem? In my humble opinion, the programmers of the OSS should take the advice to heart and fix the problem! </offtopic>

coLinux

[spiritraveller]

Also consider coLinux.

Instead of running an "emulation layer" (like Cygwin) or a "PC virtulization" (like vmWare), you could be running Linux alongside Windows.

Though it's a young project, I have been playing with it quite a bit, and haven't run into any problems re stability.

It might be faster than Cygwin too.

Use in Critical Production

[bokmann]

I am the architect for Tracker, a project funded by the U.S. State Department and deployed in 9 countries.

This is a Java (J2EE) application using JBoss as our application server. We need to develop as well as deploy on Mac OS X, linux (Redhat 9), Solaris 8, and windows XP.

We use Cygwin on windows in both development and deployment environments, so that all of our scripts (administrative, start, stop, build, etc) are completely cross platform. Works like a champ. No complaints in production at all, although their installer interface seems a little wierd to me. It would be really useful if I could get some kind of report stting the exact configuration of a machine.

Cygwin is the ultimate OS

[bheckel]

I don't use Cygwin for production work. That doesn't mean it wouldn't be useful in that capacity, I just haven't found the right employer for that type of work.

I use it as a way to take Windows 2000 (let's face it, a stable but not secure, OS) and make it almost as smart as Unix. I'm a command line, vi loving, Perl programming geek and I've essentially eliminated 98% of all differences between a Linux/Unix platform and Windows. I hate dual booting.

I can use the best of Windows and the best of Unix with little drawback on either end. I use VirtuaWin to get multiple desktops and the Cygwin/GNU tools to make the Windows OS capable of doing hard work.

I prefer the Windows' GUI to KDE, Gnome, etc. because it's clean and I don't do too much customization anyway.

Cygwin is the most important piece of software I use.

Services For Unix

[lkaos]

It's free as in beer and performs a lot better than Cygwin. MS has special hooks in the kernel for SFU so thinks like piping actually has a reasonable performance (on Cygwin it sucks major ass). Not as fast as running natively on Unix and much much much less reliable but probably a better option.

I normally don't endorse MS products but in this case you'll actually get reasonable vendor support (something you can't really say with Cygwin).