Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Operating Systems Programming Software IT Technology

Cygwin in a Production Environment? 111

Posted by Cliff 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?"
This discussion has been archived. No new comments can be posted.

Cygwin in a Production Environment? More

Cygwin in a Production Environment?

Comments Filter:

  • using cygwin to run RSYNC (Score:3, Informative)

    by stonebeat.org ( 562495 ) on Thursday August 12, 2004 @05:17PM (#9952832) Homepage
    We have been using cygwin dll to run RSYNC on Windows servers without any issues.
    • 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
    • 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 o

  • PostgreSQL on cygwin (Score:5, Informative)

    by barries ( 15577 ) on Thursday August 12, 2004 @05:22PM (#9952897) Homepage

    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

  • What are you doing with it? (Score:4, Informative)

    by Eneff ( 96967 ) on Thursday August 12, 2004 @05:23PM (#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? (Score:4, Informative)

      by MBCook ( 132727 ) <foobarsoft@foobarsoft.com> on Thursday August 12, 2004 @05:33PM (#9953012) Homepage
      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? (Score:4, Insightful)

        by Atzanteol ( 99067 ) on Thursday August 12, 2004 @06:21PM (#9953452) Homepage
        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.
        • 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.
          • 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 .
            • 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
              • 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."

                • 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...
      • 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.
      • 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 [robelle.com] and this one [geeksalad.org].

        --

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

  • SFU? (Score:5, Informative)

    by m0rph3us0 ( 549631 ) on Thursday August 12, 2004 @05:27PM (#9952944)
    Services For Unix is now free.
  • 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 [indigostar.com] 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 inteprete

  • cygwin terminal (Score:4, Insightful)

    by timothv ( 730957 ) on Thursday August 12, 2004 @05:33PM (#9953009)
    If you use cygwin, make sure to get a better terminal for it. [maricopa.edu] Puttycyg uses Putty's great terminal emulator for cygwin, and it works rather well.

    • Re:cygwin terminal (Score:4, Informative)

      by algae ( 2196 ) on Thursday August 12, 2004 @05:50PM (#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.
      • 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.. (Score:3, Insightful)

    by gl4ss ( 559668 ) on Thursday August 12, 2004 @05:35PM (#9953035) Homepage Journal
    http://home.wanadoo.nl/fvu/Projects/Bash/Web/bash. htm [wanadoo.nl] bash & windows faq/howto thingy and perl on windows google search [google.com].

  • Cygwin is Jus' Fine (Score:3, Interesting)

    by Giant Ape Skeleton ( 638834 ) on Thursday August 12, 2004 @05:38PM (#9953059) Homepage
    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.

    • 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 (Score:1)

    by zatz ( 37585 )
    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 e
    • 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 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? (Score:3, Insightful)

    by 4of12 ( 97621 ) on Thursday August 12, 2004 @06:04PM (#9953317) Homepage Journal

    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 [mingw.org] over Cygwin for some reason...

    • 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'

      • 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.
    • Another option is coLinux [colinux.org]. 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 [biermana.org] as well

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

  • Larger thoughts... (Score:5, Informative)

    by ComputerSlicer23 ( 516509 ) on Thursday August 12, 2004 @06:06PM (#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.

    Kirby

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

      • 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

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

  • Cygwin Threading problem (Score:5, Informative)

    by a11 ( 716827 ) on Thursday August 12, 2004 @06:12PM (#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
    done

    While cygwin has its problems, I've had many more w/ Services for UNIX
  • 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.
  • 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.
  • Well.. If most of what you have is shell and perl scripts, you can always get
    They always did the trick for me...
  • 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 yo
  • 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
  • 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 In
  • If you're using a fair bit of Perl on windows you probably want to use Active state Perl [activestate.com]. 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.
  • 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
  • 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

  • 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 id

  • win4lin, co-linux? (Score:3, Insightful)

    by cwg_at_opc ( 762602 ) on Thursday August 12, 2004 @07:54PM (#9954145) Journal
    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 (Score:5, Informative)

    by sICE ( 92132 ) on Thursday August 12, 2004 @08:35PM (#9954468) Homepage
    Hi,
    I already made a post [slashdot.org] in a thread [slashdot.org] about SFU [microsoft.com] 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 [microsoft.com] (of course), Mingw [mingw.org], GNU utilities for Win32 [sourceforge.net]
    • 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 [t-online.de] (free) or PE Explorer [heaventools.com] ($$$). 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 [activestate.com] 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 (Score:2)

      by sICE ( 92132 )
      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 (Score:3, Insightful)

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

      Thanks.

      • Re:24x7 (Score:2)

        by sICE ( 92132 )
        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 (Score:1)

      by cgf ( 50504 )
      >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 b

      • Re:24x7 (Score:2)

        by sICE ( 92132 )
        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 (Score:1)

          by cgf ( 50504 )
          "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

          • Re:24x7 (Score:2)

            by sICE ( 92132 )
            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

          • Re:24x7 (Score:2)

            by GCP ( 122438 )
            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

            • Re:24x7 (Score:1)

              by cgf ( 50504 )
              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 ar

    • 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 [freshmeat.net] for editing all sorts of executable files (Windows and Linux/Unix).

      Ulrik

  • 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 [att.com].

  • GPL Warning (Score:3, Informative)

    by Eil ( 82413 ) on Thursday August 12, 2004 @09:47PM (#9954924) Homepage Journal

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

    • Re:GPL Warning (Score:3, Informative)

      by 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/
    • 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 [redhat.com].

      • 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.
    • Shell scripts aren't linking directly to the library, so GPL shouldn't be an issue to the OP.


      • 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 (Score:3, Interesting)

      by Haeleth ( 414428 )
      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 per


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

  • cygwin - sfu - mks (Score:2, Interesting)

    by witte ( 681163 )
    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/ [redhat.de]], who apparently were busy with anything but cygwin. Their website said something about $100.000 or something for a developer license,
    • 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 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, C
    • <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>
  • Also consider coLinux [colinux.org].

    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.

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

    This is a Java (J2EE) application using JBoss [jboss.org] 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, alt

  • 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
  • It [microsoft.com]'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).

Slashdot Top Deals

"It's a dog-eat-dog world out there, and I'm wearing Milkbone underware." -- Norm, from _Cheers_

Close