Slashdot Mirror
Will Linux For Windows Change The World?
An anonymous reader writes "A month ago, a trial version of a little-known Linux application called 'CoLinux' was released that is the first working free and open source method for optimally running Linux on Microsoft Windows natively. It's the work of a 21-year-old Israeli computer science student and some Japanese open source programmers; in Israel, analysts are already saying it could help transform the software world." (CoLinux is short for Cooperative Linux; we mentioned this project in January as well.)
It's already becoming a bit slow... Looks like the Israel Defence Force may have done it again. Already famous for spawning an entire generation of software geniuses now active in the world of wireless technologies, the IDF has now apparently incubated the technical talent capable of creating a project that could change the world: the ability to run Linux on Windows 2000/XP. 21 year-old Dan Aloni, a graduate of an IDF computer unit, has developed a Linux application - called Cooperative Linux ("CoLinux" for short) - that is a port of the Linux kernel that allows it to run cooperatively alongside another operating system on a single machine. For instance, it allows one to freely run Linux on Windows without using a commercial PC virtualization software such as VMware, in a way which is much more optimal than using any general purpose PC virtualization software. A member of the international open source community, Aloni developed CoLinux along with several Japanese programmers, collaborating over the Net. According to the Web site, they've written special core drivers for the host OS which modify the way the host OS receives notifications from the hardware - thus allowing both OSes to coexist peacefully - and run at a decent speed as well. In Israel, acclaim for a system potentially capable of allowing organizations to run Linux and Windows in parallel on the same computer or server has been immediate. Organizations would make great savings if they didn't any longer have to have separate machines for each OS, says Shahar Shemesh, a member of the Israeli open source forum. And Pini Cohen, a senior informations systems analyst at computer research company Meta Group Israel has called the development "an important stage in breaking Microsoft's monopoly." "As the trend is for Linux to take a more important role in organizations," Shemesh continues, "Aloni's development is extremely interesting. The question is how Microsoft will react and whether it will allow support for Windows systems if they have Linux systems installed on them." According to Haaretz.com that is carrying details of this story, Microsoft has so far made no comment on Aloni's development.
The difference would be that you can run already availble Linux binaries under Windows rather than trying to get programs to work and compile for Windows under Cygwin.
This comment was thought up very late at night and does not necessarily reflect my views at a more reasonable hour.
With Cygwin, you aren't running a full blown Linux environment. Here is the Cygwin FAQ. I can't read the article (Slashdotted), but judging from the snippet here, it seems like coLinux will run an actual Linux image, which would be a big difference.
- Dunno, seems like the original article missed the actual link.
Wine doesn't emulate Windows. It reimplements with Windows API under Linux/X. What you describe wouldn't work.
It's hard to be religious when certain people are never incinerated by bolts of lightning.
CoLinux is apparently somewhat similar to Plex86, but additionally requires admin access whereas Plex86 wasn't supposed to. Anyone know more?
You mean the already available binaries bundled with Cygwin? Or coming up with a Win 32 copy of Mozilla? Or GCC? Or even the Gimp? Or do you mean Open GL apps? Or Vim? Emacs? Etc etc etc.
Nope.
Any existing linux binary. Any new linux binary.
Like that internal application that your company wrote whose source got lost.
Or the complicated one you got debugged and deployed on your department's native Linux platforms and you want to be sure runs EXACTLY THE SAME WAY on the boss' Windows box.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
There are three approaches to this problem (aside from virtual machines, like VMWare, or emulation).
The Cygwin approach is to provide basically a windows library that implements the Linux API. You can then recompile Linux programs using that library to run on Windows.
The CoLinux approach is to basically run the Linux kernel as a process on Windows, and then you can run Linux binaries under Windows. Think of it as conceptually like User Mode Linux, but running on Windows instead of Linux.
The third approach is what my employer is doing, in a product that we have in beta right now, which I won't name since I'm not sure if we have announced this yet. It's kind of in between Cygwin and CoLinux--it provides an implementation of the Linux API on Windows, so you can run Linux binaries, but it has no Linux code in it. Basically the same way WINE lets you run Win32 binaries on Linux.
From what I remember:
1) It runs as a device driver under Windows, which provides it with hardware access.
2) It doesn't yet run X correctly; any screenshots showing an X interface were done by running a separate X server under Windows and having CoLinux talk to that.
>Cygwin was a nice placeholder until Linux arrived for Windows. Now it is irrelevent. I wouldn't be surprised to see reports of its death shortly.
Not so fast, hombré.
CoLinux doesn't even have X yet.
You actually NEED Cygwin/X to be able to display any graphics, unless you want to run text-only... Which is reliable and all, but visually underwhelming for what Linux can actually do.
I don't know the meaning of the word 'don't' - J
cleartype fonts? You mean sub-pixel hinting? That's been available for a long time.
Pretty much
- every
distribution can make this happen for you automatically... (yes, speaking from experience). The most recent of which I installed was Mandrake, works like a charm, nice easy colorful menu and all =-P (This is on an old Thinkpad 600E, with only one hard drive, so I'd assume you would have no problems at all).I recall there being a lot of discussion when ms introed Cleartype about Steve Wozniak having developed a virtually identical font smoothing algorithm for the Apple II. Has this been rebutted? Do a google search for wozniak and cleartype. Here's one article.
Part 1 | Part 2
QEMU can't run windows very well yet, but it runs Linux, ReactOS and handful of others already.
The Windows POSIX was purposely designed to not interoperate with other programs in order to discourage it's use. Microsoft wrote it only to fulfill government purchasing requirements.
Both this thing and cygwin read and write the same files with the same names as Windows-native programs, and do many other things that would seem obvious but the POSIX system does not do.
All? Have you downloaded and installed the Bitstream Vera families into your X11 font server?
NT's POSIX support is POSIX.1 support. The Unix world is interested in POSIX.2.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Not really, "Classic" mode in OS X (and X11 for that matter) is more integrated with the host system than CoLinux.
This is more comparable to the countless emulation softwares out there (VirtualPC, VMware etc).
I'm not saying the technological approaches are similar, just that they run in a separate window from the host system.
What are you talking about?
1. Of course you shouldn't be running the xserver in it. The documentation clearly states this, and explains that the way to get a gui is to either:
a) Run an X server under Windows and use XDMCP to connect... or
b) Use VNC to connect to it.
PS: There is a bug in the libpam-runtime, so have fun doing any sort of apt-get upgrade action.
First of all... if this were true, it would be a bug in one of the harddisk images, not in coLinux... coLinux is just the kernel and the mechanism for running it in windows... It is not a Linux "distribution".
Second, it works for me. I used the provided debian disk image and dist-upgraded to testing with no trouble whatsoever.
I also had very little trouble using VNC to get Fluxbox running either in full screen or in a window(TM).
Even at version 0.60 it is very impressive. I suppose it will be even more impressive when it is included on a Knoppix cd with a simple installation method for those who are too lazy to RTFM.
If I could run AutoCAD on Linux, I would use it at work (for something other than a server).
There is an AutoCAD clone for Linux. Here's a quote from my Linux user group list. (I haven't used it, so YMMV)...
Date: Tue, 16 Mar 2004 09:41:07 +0100
From: "BricsCad BackOffice" email-deleted
Subject: BricsCAD goes Linux
BricsCad, the market leader in low cost DWG CAD software, today announced the beta release of BricsCad for Linux. The product is based on the IntelliCAD kernel.
BricCad for Linux is an "almost clone" of AutoCAD(r). BricsCad uses the exact same DWG drawing format as AutoCAD(r). Drawings made by BricsCad can be read by AutoCAD(r) and the other way round.
BricsCad for Linux addresses the untapped group of individual and corporate professional CAD users in the LINUX community allowing them to use their operating system of choice without being locked out from the professional Engineering world and the DWG standard.
The full press release can be found on their website(s):
English version
French version
German version
Interested beta-testers are invited to contact BricsCad at linux@bricscad.com
Threw this on MetaFilter a few hours ago; hope this helps clarify what's going on here. Thanks to the good Jason Spence for explaining most of this to me over fine tequila at Defcon a few years back :-)
:-)
===
OK, terrible terrible story. Nobody's going to contest that. My immediate reaction: "Yay, another whiz kid story. Kid probably rediscovered prefetching web pages."
Yeah. Then the CoLinux guy came up.
People, CoLinux is absurdly brilliant stuff, the kind of hardcore engineers get drunk about and laugh that "some psycho pulled off WHAT?!" regarding. I can say this from personal experience
To put it simply, most approaches that involve multiple operating systems sharing a processor require a significant degree of subordination. In the Cygwin model, the "Linux/Unix" way of requesting services from the operating system (open this file, give me that network connection) is translated to the Windows way through a library of functions. The mapping is pretty good, but like any translation, it's not perfect. Some actions, like starting new programs, are very very fast under Linux/Unix and are extraordinarily slow under Windows. Cygwin deals with this as best it can, but there's only so much it can do.
VMWare offers a different approach. Instead of translating Unix to Windows, VMWare creates a "virtual PC", complete with its own processor, motherboard, sound card, network card, and everything else. The child operating system -- Linux, for example -- gets a complete environment to manipulate, and VMWare handles the translation between what the child PC is asking to do and what the parent PC is actually capable of. This interface is much more isolated than what Cygwin offers -- memory, for instance, is not shared between the two environs -- but as such, the child operating system is freed of many of the particular quirks of the parent OS. The child Linux really is Linux, and can do everything Linux can do, because Linux is an environment for controlling a PC.
The only catch is that it's a virtualized PC, and VMWare needs to do alot of work to keep the two contexts separate -- and to emulate all the hardware resources that are normally "just there", but now need to be simulated. There's a 20-30% speed cut out of this. Also, switching contexts between parent PC and child PC is not a trivial thing to do, meaning it can only be done a certain number of times per second. This causes issues for some real time operations. Specifically, audio in VMWare is a problem.
CoLinux is something else entirely. x86 CPU's have the concept of Rings -- these are roughly analogous to privelege levels, in which certain classes of commands may be issued to certain components of the architecture. Lowest level code operates in what's referred to as "Ring 0" -- at this level of permissions, one can directly control the raw components of the PC, for better or worse. This is a gross oversimplification, but there's basically two things that live at Ring 0: A kernel, and device drivers (which are not entirely separate from the kernel). Kernels are basically a core set of commands that user software can execute to get things done -- create processes, read files, open network connections, and so on. Here's a list of Linux syscalls, at least from 2.2. Not on this list -- stuff like, "Send this block of memory to this device on the PCI bus, and tell the sound card to start emitting sound from that memory address on its internal buffer." That's what device drivers are for -- they get some kind of interface that userspace can talk to, and they do things with what they're given. Those things can be pretty much anything the underlying hardware can do -- stuff way deeper than "write this file" and "trace this process", and into the nuts and bolts of what the PC is -- a collection of wires and memory addresses. Normally, that's what a device driver does: It implements the requisite hardware calls to let some piece of equipment work.
At least someone else seems to think so too in this rant.
Joel's rant is incorrect. His whole premise is flawed, because he's arguing from incorrect definitions.
He states anti-aliased text is bad... when what he really dislikes is scalable text.
His complaints all come from the idea that onscreen text can be scaled to an arbitrary non-integer pixel height. If nobody used scalable fonts, his problems would vanish. But given that people do wish to view 12 pt text at 115% WYSIWG magnification, antialiasing is the best option.
He shows two sample paragraphs that he labels as non-anti-aliased and anti-aliased. But if those paragraphs were redone with text scaled 21% larger, then the non-anti-aliased version would be immeasurably uglier.