It’s Time for Cygwin to Close Shop
Posted by HokieTux on May 27, 2010 in General, Technology
Update: After discussing this topic with the developer of mintty, I have to agree that there are still some instances in which Cygwin serves a purpose that VMs cannot. Specifically, there is no good alternative for *nix-reliant build systems for building Windows ports (e.g. Make, Autotools). Also, and while I think this will change in the near future, there are still some hardware platforms that VMs are not well suited for, like NetBooks. While I would never purchase a NetBook for that sort of computing, it is a valid point. Here is what I had to say at the end of the discussion:
All-in-all, I think you have made some points. There really is no alternative for *nix-reliant build systems for port development, and there are still some hardware platforms (e.g. NetBooks) that cannot yet support Cygwin. I do firmly believe, however, that for simply using *nix-only software packages, or needing a *nix desktop environment on Windows, VMs have Cygwin firmly beaten.
To see the rest of the discussion, check out the comments.
————————————————————————-
I recently purchased my first PC laptop in about five years. While I do nearly all of my work on pure-Linux machines, I had purchased only Apple laptops since ~2005. When I first began buying Macs, it was generally for their good hardware and great stability. Linux had been my operating system of choice since the early 2000s, but it tended to be too unstable for me to totally embrace it on my only computer. It was common for updates to break the xserver (this was prior to xorg - the standard was XF86) or break wireless connectivity. Since my laptop was the only machine I owned, and I needed it working 24/7 without much maintenance so that I could get my schoolwork done, Apple was an easy choice.
Linux OSes have, of course, come a long way since 2005. The most recent release of Ubuntu is a prime example of how much the Linux desktop experience has improved in the last 5-6 years. ArchLinux remains my Linux distribution of choice; I use it on my home desktop, the server hosting this website, and my critical lab research desktop.
When I decided it was time for a new machine at the start of this year, I figured I would just wait for Apple to update their line of MBPs, and buy the new model whenever it was released. This turned out to be an agonizing experience, as the new models got delayed over and over again. When Apple finally got enough Intel chips to release the new model, I was pretty disappointed. As a student, the price for the hardware was just too much – even for Apple. I decided to buy a PC.
Additionally, I decided to install Windows 7 Ultimate on the machine, rather than Linux. I did this for a variety of reasons, but in the end, I still really needed a *nix work environment on my Windows machine. Without it, my laptop would quite literally be useless to me as a work machine.
For years, Cygwin has been the default solution to this issue. Cygwin was fantastic technology when it was first released in 1995 (granted, it wasn’t ‘Cygwin’ then, but you get the idea), and continued to be the gold-standard for a UNIX-like environment on Windows platforms for many years. That said, Cygwin has a number of weaknesses. Some of the main ones, in my opinion, include:
- Available Software Packages – This is not the fault of the Cygwin developers, obviously, as they cannot be expected to port every known package to Cygwin. Installing Cygwin to get a particular package only to find out that it doesn’t support Cygwin, however, can be rough.
- Update: A commenter pointed me to the mintty project, which was released just recently. It seems to clear up most of my complaints regarding terminal emulators. Limitations of the Windows Console – Not sure how to get past this one. There are dozens and dozens of terminal emulators for *nix platforms. On Windows, you get ‘console’. It is pretty horrendous… even Windows 7 hasn’t improved it at all. Cygwin relies on the default Windows Console, which immediately limits the terminal’s functionality.
- Developers’ Time – Maintaining an active port of native Linux applications for Cygwin is not a small task, and is very difficult for many smaller projects. In addition, the Cygwin ports of many notable software packages often have an extreme number of bugs relative to the native Linux versions. Indeed, most ports of traditional *nix software to Windows run better than its Cygwin counterpart (e.g. SSH and ViM). Trying to maintain these multiple platform lines of development soaks of developers’ time and money.
So when I finished my Windows install, I needed a Linux environment, but did not want Cygwin. The answer was virtualization. Most people are familiar with virtualization at this point; virtualization software allows you to run a ‘virtualized’ computer on your real computer. It gets it’s own ‘harddrive’, a chunk of RAM, access to the the real computer’s hardware, etc. The virtualized computer is called a ‘Virtual Machine’, and provides a great way to run other operating systems on your platform-of-choice. I’ve used a fairly large number of different virtualization suites, including: VMWare Player, VMWare Server, VMWare Fusion, Parallels, and VirtualBox. The latter is, relative to the other options, new to the virtualization scene. Backed by Sun (now Oracle), VBox is quickly gaining users. It is fast, stable, and provides a wonderful set of features.
And, perhaps most important to me, it has an extremely easy-to-use ‘Shared Folder’ feature that doesn’t require manually going through a bunch of NFS nonsense.
I installed ArchLinux on a VM, and so far, I love it. I can do anything I want to with a native Linux environment, its fast, stable, and it is *extremely* simple to use both OSes simultaneously. I use git, running in my VM, to manage my source code for Matlab, running in Windows, and don’t even notice that the Linux console isn’t native to Windows.
<3 pacman
VMs have become so smooth, easy-to-use, and functional that I think Cygwin is on the verge of deprecation. Cygwin has done some wonderful things in its lifetime, but hardware technology has progressed enough that virtual machines don’t clobber your computer’s resources anymore. Running a ‘UNIX-like’ environment just doesn’t make any sense when you can run a real UNIX environment with less work and more functionality.
I have already recommended VirtualBox over Cygwin to one co-worker, and I don’t forsee myself recommending Cygwin to anyone in the future. The Cygwin devs are obviously very talented… honestly, their time spent on Cygwin just doesn’t seem worth it anymore.
5 Comments on It’s Time for Cygwin to Close Shop
I agree that VMs have made big strides forward, but Cygwin still delivers greater Windows integration. In particular, you can’t invoke Windows programs from a Linux virtual machine. This is crucial when you need to mix Unix and Windows tools. It also offers goodies like /proc/registry or /dev/clipboard, and it allows using Unix and Windows APIs in the same program, which can be useful for gradual porting from one platform to the other.
Cygwin continues to improve regarding Linux API support, so more and more programs compile out-of-the-box without requiring any Cygwin-specific changes. For example, Cygwin 1.7 brought full locale and charset support, including correct interop with Windows’ Unicode filenames.
Regarding the console, have a look at mintty (at http://mintty.googlecode.com), which provides xterm-compatible terminal emulation with a native Windows user interface and without requiring an X server. If you do want to run an X server, there’s also xterm and rxvt-unicode.
Finally, I don’t take the point about native ports, in particular ssh and vim. Run them in mintty or one of the other terminals, and there shouldn’t be much difference from Linux. And is there even a Windows native version of ssh?
Andy -
Thanks for the well thought-out comment =)
First, I should state that I never said that Cygwin _did not_ deliver great Windows integration. Cygwin delivers fantastic integration, and is hands-down the best at what it does. The point I was trying to make is that I don’t think we need it anymore.
I totally agree that goodies like /proc/registry and /dev/clipboard are great tools. They are so great, in fact, that I wonder why I should have to install a software suite like Cygwin to get them? Why not make a Windows stand-alone program with that kind of functionality? Installing the entire Cygwin environment for a few great tools seems like overkill.
The fact that Cygwin can launch Windows programs from a ‘Linux-like’ environment and that it is capable of invoking both Linux and Windows APIs are the best arguments for its continued existence, in my opinion. I have used both of these capabilities in the past, and I agree that they are quite useful.
That said, more and more software suites are developed for Windows and Linux simultaneously. Many libraries and tools that used to be *nix-only are now native to Windows as well – GTK and Qt are great examples. There are cross-platform media libraries (e.g. SDL), and even ‘platform-independent’ languages (e.g. Java, Python).
Additionally, shared files and folders have become so smooth and efficient in VMs that program communication via a file pipe would be trivial. Mixing Linux and Windows program through a VM, or even IPC through a VM, is no longer impossible.
While Cygwin does make great strides in compatibility with each of its releases, ‘compatibility’ will always be a moving target. Much like WINE, Cygwin will never really ‘catch’ native development. For any non-trivial codebase, there will always have to be a Cygwin branch. Perhaps even more frustrating for package developers are that when there are compatibility issues, there is nothing they can do about it. They have to file a bug with Cygwin, and hope it gets fixed sometime soon.
My argument is that the software package developers’ time would be better spent on a native Windows branch than a Cygwin branch, and that the time of the Cygwin devs would be better spent on other, new, challenging software problems.
Also, I was totally unaware of mintty. In addition, everyone I have talked to is unaware of it. The commit logs and associated PR make it sound like it was released just two months ago. It does look like a great terminal emulator, and I’m glad someone is tackling the issue. That said, it is late to the scene, and I don’t think it is enough to save Cygwin. I do, however, concede that this is a great counter-point to my complaint about terminals. I’ll update my post accordingly.
Finally, no, there isn’t a Windows-native port of SSH distributed by the OpenSSH devs. I was referred to PuTTY, which of course is native, and provides a full SSH1+SSH2 implementation. Coincidentally, it appears that ‘mintty’ is based on the PuTTY terminal =)
Cheers,
Ben
I should declare an interest here: I developed mintty, because like you I was frustrated with the default console and I wasn’t happy with any of the available alternatives either. I first released it at the end of 2008, and I do what I can to publicise it; but yeah, it’s slow work, apart from occasional lucky breaks like http://lifehacker.com/5185647/mintty-gives-cygwin-a-native-windows-interface.
It’s simply not true that any non-trivial codebase requires a dedicated Cygwin branch, for example, vim and openssh are both built from vanilla sources. Where patches are required, they tend to be rather small, whereas the effort required for a native Windows port obviously depends on how much Unix-specific functionality it uses. Where it does require a lot of work, dropping any Cygwin port would make little difference.
Also, a native Windows port still needs to be built and tested, so unless you eliminate any uses of tools that aren’t available natively, you’ll still need something like Cygwin. Shell scripts including configure scripts are the most prominent examples here. Cross-compiling from a Linux VM is a less comfortable alternative, and I don’t know of any established way to do automated “cross-testing”. Rather ironically, VirtualBox is one project that uses Cygwin in its Windows build, as mentioned at http://www.virtualbox.org/wiki/Windows%20build%20instructions. Google Chromium is another.
The core of Cygwin is maintained by one full-time developer and about half a dozen volunteers, with perhaps a couple dozen more contributing packages on a fairly regular basis. So not an awful lot of resources to go spare. No more than yet another second division Linux distro anyway.
The Wine comparison isn’t really fair either, because Cygwin implements an open API where specs and sources are readily available, whereas Wine implements a proprietary API with spotty documentation.
ps: I just stumbled across this blog post that could have been written as a response to yours: http://blog.mrhacks.com/?p=470, which makes the point that resource use isn’t irrelevant just yet.
Andy -
Congratulations on mintty! LifeHacker is one of the highest-trafficked sites on the Internet (it’s in the Top 10… forget where though). That featured article is nice =)
I agree that my statement that any non-trivial codebase requires a Cygwin branch isn’t fair. I _do_ believe that this used to be _more_ true, but I agree that it is not true anymore. This was too broad of a statement to be accurate. That said, like you pointed out, the nature of patches necessary to successfully build a package on Cygwin really depend on what sort of *nix functionality they rely on. Increasingly, programs are simply using standard & open libraries. Boost is a great example of this. Use of Boost is growing very quickly, and successfully removes the user from many platform-dependent libraries.
Also, I hadn’t thought of the build environment bit. That is an excellent point, especially, as you pointed out, for building ports. Cross-compiling from a VM doesn’t seem like a good idea at all, and I’m also not aware of any ‘cross-testing’ suites.
That blog post brings up a good point – Cygwin is currently better suited for NetBooks than VMs are. This will not be true for much longer, however, as nano-scale technology continues to improve. This goes back to one of the original points I was trying to make – improved hardware has made VMs much more plausible on standard workstations.
Finally, my comparison to WINE wasn’t meant as an attack on WINE. I think WINE has done an incredible job, given their task. My point was simply that, like WINE, Cygwin will ever achieve true ‘native compatibility’.
All-in-all, I think you have made some points. There really is no alternative for *nix-reliant build systems for port development, and there are still some hardware platforms (e.g. NetBooks) that cannot yet support Cygwin. I do firmly believe, however, that for simply using *nix-only software packages, or needing a *nix desktop environment on Windows, VMs have Cygwin firmly beaten.
I’ll update the start of my post with your points about build systems and limited-resource hardware platforms =)
Cheers,
Ben
I also take issue with the notion that the programs in the cygwin distribution are full of bugs. It seems like you’re using misleading vividness to make a point without backing up your statements with facts.
Cygwin’s death has been predicted for years. It was going to be killed by Interix since Interix provided true fork/exec. It was going to be killed when Interix was acquired by Microsoft since now unix services would be more generally available. It was going to be killed by colinux or by vmware or virtualbox or any other virtual system.
It was not killed by any of those things and, in fact, continues to be going strong, because it works just fine for what people need. Telling every cygwin user to install a linux vm when they can just easily run a program to get linux-like programs on their systems would be extreme overkill for most people. It isn’t going to happen.
That doesn’t mean that it’s impossible that there’s a virtual machine killer-app out there which will wipe the floor with cygwin. But, impassioned blog posts are not what cause projects to die. They die when the need shifts. If virtual machines truly met the needs of the millions of cygwin users then the project would be dying automatically. So far, there is no evidence that this is the case.
Subscribe
Follow comments by subscribing to the It’s Time for Cygwin to Close Shop Comments RSS feed.