Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Cygwin in a Production Environment?

Cliff posted more than 10 years ago | from the is-it-ready-for-prime-time dept.

Operating Systems 111

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?"

Sorry! There are no comments related to the filter you selected.

using cygwin to run RSYNC (2, Informative) (562495) | more than 10 years ago | (#9952832)

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

Re:using cygwin to run RSYNC (2, Informative)

n9hmg (548792) | more than 10 years ago | (#9955490)

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.

My thoughts on Cygwin (and ActiveState Perl) (1)

mikehoskins (177074) | more than 10 years ago | (#9958029)

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?

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) (0)

Anonymous Coward | more than 10 years ago | (#9965914)

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.

PostgreSQL on cygwin (4, Informative)

barries (15577) | more than 10 years ago | (#9952897)

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

haha... (0)

Anonymous Coward | more than 10 years ago | (#9952956)

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

Re:PostgreSQL on cygwin (1)

Electrum (94638) | more than 10 years ago | (#9953137)

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 (0)

Anonymous Coward | more than 10 years ago | (#9953304)

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.

The 49-day limit. (1)

devphil (51341) | more than 10 years ago | (#9955261)

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. (1)

dealsites (746817) | more than 10 years ago | (#9955690)

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: []

Support and Open Source (1)

cbr2702 (750255) | more than 10 years ago | (#9955752)

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.

Re:The 49-day limit. (1)

einhverfr (238914) | more than 10 years ago | (#9956023)

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

What are you doing with it? (3, Informative)

Eneff (96967) | more than 10 years ago | (#9952909)

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? (3, Informative)

MBCook (132727) | more than 10 years ago | (#9953012)

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? (3, Insightful)

Atzanteol (99067) | more than 10 years ago | (#9953452)

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? (1)

bofkentucky (555107) | more than 10 years ago | (#9953962)

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? (1)

Eneff (96967) | more than 10 years ago | (#9954080)

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? (0)

Anonymous Coward | more than 10 years ago | (#9955673)

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? (1)

Atzanteol (99067) | more than 10 years ago | (#9957245)

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? (1)

Eneff (96967) | more than 10 years ago | (#9960914)

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? (1)

Atzanteol (99067) | more than 10 years ago | (#9961583)

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? (1)

Eneff (96967) | more than 10 years ago | (#9954063)

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? (0)

Anonymous Coward | more than 10 years ago | (#9954754)

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? (2, Informative)

cowbutt (21077) | more than 10 years ago | (#9956733)

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? (2, Interesting)

salimma (115327) | more than 10 years ago | (#9961183)

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? (0)

Anonymous Coward | more than 10 years ago | (#9964881)

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.

SFU? (5, Informative)

m0rph3us0 (549631) | more than 10 years ago | (#9952944)

Services For Unix is now free.

Re:SFU? (0)

Anonymous Coward | more than 10 years ago | (#9955953)

That should be STFU.

Just Rembember (0, Flamebait)

I_Love_Pocky! (751171) | more than 10 years ago | (#9952963)

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 (3, Funny)

I_Love_Pocky! (751171) | more than 10 years ago | (#9953242)

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? (1)

Wee (17189) | more than 10 years ago | (#9952999)

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.


cygwin terminal (3, Insightful)

timothv (730957) | more than 10 years ago | (#9953009)

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 (4, Informative)

algae (2196) | more than 10 years ago | (#9953177)

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.

Cygwin is Jus' Fine (2, Interesting)

Giant Ape Skeleton (638834) | more than 10 years ago | (#9953059)

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 (1)

CyberVenom (697959) | more than 10 years ago | (#9954503)

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 (1)

zatz (37585) | more than 10 years ago | (#9953120)

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 (1)

d00dl3 (805639) | more than 10 years ago | (#9973730)

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 (1)

ch1rd (662455) | more than 10 years ago | (#9953136)

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? (2, Insightful)

4of12 (97621) | more than 10 years ago | (#9953317)

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...

The Cygwin vs MinGW thing (1)

devphil (51341) | more than 10 years ago | (#9955299)

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 (2, Informative)

cgf (50504) | more than 10 years ago | (#9955599)

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.

Re:VMWare? Either Way? (1)

tyndyll (653821) | more than 10 years ago | (#9956640)

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? (1)

DiSKiLLeR (17651) | more than 10 years ago | (#9953329)

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? (1)

sirvulcan (700310) | more than 10 years ago | (#9953869)

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... (4, Informative)

ComputerSlicer23 (516509) | more than 10 years ago | (#9953331)

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.


Re:Larger thoughts... (1)

duffbeer703 (177751) | more than 10 years ago | (#9954573)

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.

Not necessarily (1)

V. Mole (9567) | more than 10 years ago | (#9959551)

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.)

Best bet is probably Cygwin (1)

einhverfr (238914) | more than 10 years ago | (#9956054)

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.

Re:Larger thoughts... (1)

Stinking Pig (45860) | more than 10 years ago | (#9965729)

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 (5, Informative)

a11 (716827) | more than 10 years ago | (#9953380)

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

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

Re:Cygwin Threading problem (0)

Anonymous Coward | more than 10 years ago | (#9953482)

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

Re:Cygwin Threading problem (1)

Chuck_McDevitt (665265) | more than 10 years ago | (#9962545)

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 (1)

cgf (50504) | more than 10 years ago | (#9964455)

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

Re:Cygwin Threading problem (1)

Elwood P Dowd (16933) | more than 10 years ago | (#9954069)

I think you win for most unnecessary uses of cat.

CYGWIN running on production servers... (2, Interesting)

IamInsane (416252) | more than 10 years ago | (#9953407)

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 (1)

Radical Rad (138892) | more than 10 years ago | (#9953411)

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.

Get the permissions right (1)

dr_leviathan (653441) | more than 10 years ago | (#9953525)

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 (1)

Lomby (147071) | more than 10 years ago | (#9953704)

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 (1)

mirabilos (219607) | more than 10 years ago | (#9953782)

I highly recommend that you use Interix
( 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 ontri b/samples/codesnippets/oracle-ksh-access.shar

For a portable version of a highly modern
pdksh derivate, the project has released - it works
under Interix with no patches.

Re:Interix, not Cygwin (0)

Anonymous Coward | more than 10 years ago | (#9957488)

pdksh is downloadable from the cgywin setup utility.

Re:Interix, not Cygwin (1)

mirabilos (219607) | more than 10 years ago | (#9959073)

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

Re:Interix, not Cygwin (0)

Anonymous Coward | more than 10 years ago | (#9960102)

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 (1)

mirabilos (219607) | more than 10 years ago | (#9960381)

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 (1)

Josh Mast (1283) | more than 10 years ago | (#9953815)

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.

Personal experience (1)

consolidatedbord (689996) | more than 10 years ago | (#9953846)

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 (1)

Cecil (37810) | more than 10 years ago | (#9953881)

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 (1)

Kevin Burtch (13372) | more than 10 years ago | (#9953961)

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. ;)

win4lin, co-linux? (2, Insightful)

cwg_at_opc (762602) | more than 10 years ago | (#9954145)

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 (4, Informative)

sICE (92132) | more than 10 years ago | (#9954468)

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 ...
    • Common interface: WxWindows [] for perl [] . You can get the same widgets on nearly any platform you can imagine. In fact i think it really sucks, but the work is done, and well. I didnt found a -free- usable editor, but some $$$ are worth it (google [ttp] )
    • A single package: have a look to Perl2exe [] if you want to simply handle a perl ".exe" (what else?) to your customer. I had nice experiences with it.
    • Tests: make TESTS [] in your apps, you'd be surprised how much bugs i'd found in my own code just using tests... well, in fact i am surprised by how much ~subtles errors~ might arise in my code... ;)

  • No compatibility: NEVER trust that if it will work with nunux, it will work with cygwin, check, and check twice, and just to be sure check a third time. Very simple bugs get in because you're on win32, the first example that comes to mind is that the line endings are different on that platform, but they're another thing on MacOS X...

All in all when i use cygwin in a 24x7 env, i'm quite happy. Just those few things i told you and that you need to keep in mind, but if you use it, it will all come by itself.

One must say: "Thanks RedHat, CygWin is damn good".

Go on! And have fun! ;-)

Re:24x7 (1)

sICE (92132) | more than 10 years ago | (#9954565)

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 (2, Insightful)

duffbeer703 (177751) | more than 10 years ago | (#9954626)

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


Re:24x7 (1)

sICE (92132) | more than 10 years ago | (#9954687)

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 (0)

Anonymous Coward | more than 10 years ago | (#9957516)

cygwin's own cygcheck program will list dll dependencies

Re:24x7 (1)

cgf (50504) | more than 10 years ago | (#9964501)

>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 (1)

sICE (92132) | more than 10 years ago | (#9965979)

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 (1)

cgf (50504) | more than 10 years ago | (#9971428)

"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 (1)

sICE (92132) | more than 10 years ago | (#9972989)

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 (1)

ulrikp (64196) | more than 10 years ago | (#9972593)

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).


It's pretty reliable (0)

Anonymous Coward | more than 10 years ago | (#9954546)

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 (2, Informative)

caesar79 (579090) | more than 10 years ago | (#9954644)

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 [] .

GPL Warning (2, Informative)

Eil (82413) | more than 10 years ago | (#9954924)

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 (3, Informative)

Anonymous Coward | more than 10 years ago | (#9957537)

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

Re:GPL Warning (1)

The Lord of Chaos (231000) | more than 10 years ago | (#9958340)

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 (1)

Eil (82413) | more than 10 years ago | (#9962457)

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.

Re:GPL Warning (1)

duffbeer703 (177751) | more than 10 years ago | (#9959837)

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

Re:GPL Warning (1)

Eil (82413) | more than 10 years ago | (#9962286)

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 (2, Interesting)

Haeleth (414428) | more than 10 years ago | (#9960035)

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: [] )

Re:GPL Warning (1)

Eil (82413) | more than 10 years ago | (#9962405)

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.)

inodes (1)

eraserewind (446891) | more than 10 years ago | (#9955496)

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.

Cygwin? (1)

PhlegmMaster (596165) | more than 10 years ago | (#9956031)

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).

MKS (0)

Anonymous Coward | more than 10 years ago | (#9957094)

It's not free but there is also MKS []

cygwin - sfu - mks (2, Interesting)

witte (681163) | more than 10 years ago | (#9957196)

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 [ [] ], 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 (0)

Anonymous Coward | more than 10 years ago | (#9957553)

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

Re:cygwin - sfu - mks (1)

Chuck_McDevitt (665265) | more than 10 years ago | (#9959613)

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.

We use it in production -- but there are issues. (1)

Chuck_McDevitt (665265) | more than 10 years ago | (#9959742)

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 (1)

asahetter (800625) | more than 10 years ago | (#9960850)

<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 (1)

spiritraveller (641174) | more than 10 years ago | (#9963819)

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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?