Read the Original Article at http://www.informationweek.com/news/showArticle.jhtml?articleID=19205491
Cooperative Linux is a set of device drivers and assorted snippets that, when installed, lets Linux run as a protected process under Windows. It comes from Israel, and if you believe the stories about it, it's the best thing since sliced challah.
Does it live up to claims of being revolutionary? It's certainly innovative. Is Bill Gates losing sleep over this new threat to his Windows dominance?
Well, it's certainly innovative.
How does it compare with other products that allow you to run Windows and Linux on the same machine, such a VMWare and CygWin? It's too early to tell - coLinux is still beta - but coLinux is already significant faster than the other software.
Download and Installation
It's a small download, less than 2MB. It installs easily, although it's a bit unusual in that the interim result provides for a non-connected network connection as seen in the Control Panel. You need to have a boot image of a Linux system available. Following the installation instructions carefully, I grabbed a Debian system, and decompressed it into my new coLinux directory. Tweaks here and there, some simple edits to an XML file defining where that boot image resides, some rudimentary partition information, define how much memory to devote to Linux, and you're basically done. Click on the coLinux icon and you're running Linux. And Windows. On the same box. At the same time. Woo-hoo!
It was a perfectly painless installation. Once installed, booting Linux just involved double clicking on a Windows icon. Next came installing a network "card" - just a software driver installed using the "Add Hardware" wizard on my Windows XP system - configuring it, and letting it know how to use my existing DSL line for Internet Connection Sharing. Then some pings to make sure my connectivity was good, and with a few downloads I was using Mozilla under Linux and Microsoft Internet Explorer 6 under Windows. At the same time. On the same box.
I like this product. A lot.
When you first boot coLinux up, you're in a text-only environment. Download your favorite GUI and mouse about. I found the Windows text mode window very slow, but the performance with true Linux code was standard speed - seemingly no delay and everything ran normally and at the same speed as stand-alone Linux.
CoLinux was substantially faster than the same code under both VMWare and CygWin on the same box.
How it all works and how it compares, say, to VMWare's running of a virtualized Linux kernel is all supposition. based on some research and some guesswork. Neither VMWare nor CoLinux wants to give up the trade-secrets of exactly how they work.
Here's how coLinux works: It's not magic. With a rewrite of the Linux kernel, and some device driver rewrites, it just appears magical. It seems the Linux kernel runs entirely in protected mode (Ring 0) and speaks to the Windows kernel through a marshaling set of device drivers. There are likely some transitioning surprises with buffer overruns and the like: having a Linux API call to read a huge disk file into a too-small buffer causes some serious problems, but that is to be expected, and seems to only cause these problems in the error-producing window. Just reboot the Linux window, fix the problem, and keep going.
VMWare takes a different approach than coLinux. Instead of rewriting the kernel, apparently the route coLinux took, VMWare creates a super virtualized kernel in the most privileged Ring 0 of the processor, within which Windows, Linux, and virtually any operating system can run, demoted to a lower privilege level, such as Ring1 or Ring3. VMWare runs a specialized device driver to avoid conflicts between operating systems, instead of coLinux's approach that appears to let Windows device drivers control the actual hardware. So, under VMWare, a super monitor vitalizes the hardware and most privileged software operations, marshaling out privileged operations, which seem to require 15 percent overhead for I/O.CoLinux seems to pass the I/O request to the Windows driver and hope for the best.
Each method has its advantages and disadvantages. I'm not sure which is better, or which scales better to massive enterprises. Time will tell on those scores.
I ran a number of CPU and screen intensive tasks, games and business apps under coLinux, and there was no performance drag I could point at. Interestingly, when I ran ports of the same code in the Linux window and Windows window, the Linux code ran more smoothly. Linux showed less jerky motion on the games. Also, Linux was a touch faster for graphics intensive font rendering Linux's OpenOffice versus Windows Word.
Running CPU-only tasks in each window showed almost identical performance. Disk heavy tasks showed varied results: disk reads and directory operations gave about a 10 percent edge to Linux; there was no clear winner for SQL fetches and puts. My benchmarks were just quick hacks to give me a feel for the product and were not formal by any means. I suggest you run a full set of real benchmarks on a variety of operations to get a more accurate result than my, at best, back-of-the-envelope guesstimates.
Basically, this code took a licking and kept on ticking. My preliminary look showed that running bad code in either window would cause that window to crash, BSOD or panic - it didn't cause a real problem in the other window. Running infinite loop disk I/O code did cause some lock ups in the other window, but nothing a "kill -9" (or Window's task manager) couldn't handle in an expected way. Devices are run, it appears, from the Windows device driver: a buggy Windows device driver causes problems in both windows, some serious enough to require a system reboot.
Before opting to put this code in mission critical applications: remember this is still beta code. Test, test and re-test
All in all, I'm impressed. Not awed. But very impressed. And I don't impress all that easily anymore.
And this is still an early beta.
Ross M. Greenberg is a programmer, writer, consultant, and web page designer with experience in Linux, Unix and Windows. He started working on Unix-based systems in the early 1980s. Lately, he's been concentrating on PHP and ASP database programming.