Slashdot Mirror

← Back to Stories (view on slashdot.org)

Cygwin in a Production Environment?

Posted by Cliff on from the is-it-ready-for-prime-time dept.

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

28 of 111 comments (clear)

  1. using cygwin to run RSYNC by stonebeat.org · · Score: 2, Informative

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

    --


    Consensus is good, but informed dictatorship is better
    1. Re:using cygwin to run RSYNC by n9hmg · · Score: 2, Informative

      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.

  2. PostgreSQL on cygwin by barries · · Score: 4, Informative

    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

  3. What are you doing with it? by Eneff · · Score: 3, Informative

    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.

    1. Re:What are you doing with it? by MBCook · · Score: 3, Informative
      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.

      --
      Comment forecast: Bits of genius surrounded by a sea of mediocrity.
    2. Re:What are you doing with it? by Atzanteol · · Score: 3, Insightful

      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.

      --
      "Ignorance more frequently begets confidence than does knowledge"

      - Charles Darwin
    3. Re:What are you doing with it? by cowbutt · · Score: 2, Informative
      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.

      --

    4. Re:What are you doing with it? by salimma · · Score: 2, Interesting
      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.
      --
      Michel
      Fedora Project Contribut
  4. SFU? by m0rph3us0 · · Score: 5, Informative

    Services For Unix is now free.

  5. cygwin terminal by timothv · · Score: 3, Insightful

    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.

    1. Re:cygwin terminal by algae · · Score: 4, Informative

      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.

      --
      Causation can cause correlation
  6. non cygwin way.. by gl4ss · · Score: 2, Insightful

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

    --
    world was created 5 seconds before this post as it is.
  7. Cygwin is Jus' Fine by Giant+Ape+Skeleton · · Score: 2, Interesting
    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.

    --
    The difference between stupidity and genius is that genius has its limits.
  8. Re:Just Rembember by I_Love_Pocky! · · Score: 3, Funny
    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!
  9. VMWare? Either Way? by 4of12 · · Score: 2, Insightful

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

    --
    "Provided by the management for your protection."
  10. Larger thoughts... by ComputerSlicer23 · · Score: 4, Informative
    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

  11. Cygwin Threading problem by a11 · · Score: 5, Informative

    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

  12. CYGWIN running on production servers... by IamInsane · · Score: 2, Interesting

    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.

  13. UNXUtils and ActivePerl by Youssef+Adnan · · Score: 2, Interesting
    Well.. If most of what you have is shell and perl scripts, you can always get
    They always did the trick for me...
  14. win4lin, co-linux? by cwg_at_opc · · Score: 2, Insightful

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

    --
    "...that's as white as it gets; all the bits are on..."
  15. 24x7 by sICE · · Score: 4, Informative
    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
    --
    -- search the web
    1. Re:24x7 by duffbeer703 · · Score: 2, Insightful

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

      Thanks.

      --
      Conformity is the jailer of freedom and enemy of growth. -JFK
  16. Unix for Windows from ATT by caesar79 · · Score: 2, Informative

    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 .

  17. GPL Warning by Eil · · Score: 2, Informative


    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.

    1. Re:GPL Warning by Anonymous Coward · · Score: 3, Informative

      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/

    2. Re:GPL Warning by Haeleth · · Score: 2, Interesting
      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)
  18. Re:The Cygwin vs MinGW thing by cgf · · Score: 2, Informative

    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.

  19. cygwin - sfu - mks by witte · · Score: 2, Interesting

    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.