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.)
Whats the difference between this and Cygwin? Or (though I haven't tried it, MS SFU). Cygwin seems to run extremely fast and reliably already. Of course, Cygwin doesn't run executables other than standard Windows EXEs, but what isn't available for Cygwin (or natively on Windows) already? This seems like a project to run Linux for the sake of Linux
Implicit Evaluation with PHP
It's about time someone thought of doing this.
The NT(2000/XP) kernel has had the ability to run other native applications for a while.
It sounds like they are going the same way that Win16/WOW, OS/2 and Posix apps currently get run in Windows. There's no reason not to add Linux to this list.
So, the next time your manager is afraid of having a Linux server on the production network, use CoLinux instead?
"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."
Hmm.. there's an interesting question. Can Microsoft really refuse to support your windows installation if you're running Linux (as an application, even?) Or is this guy just trolling?
DJ kRYPT's Free MP3s!
Now imagine a world where you can do the same thing, but it takes 15 seconds to boot, and you don't have to exit the person's applications, log them out, shut down their internet daemons, etc. Walk up to virtually any computer, and you have the full comfort of your standard environment.
Therein lies the problem. To make the situation reversed, where the NT kernel was made to run on top of Linux, one would need access to the source code for the NT Kernel.
What they (i think) did with coLinux was hack Linux to run within the parameters of a loaded NT enviorment. It's like a low level multitasking dance where NT leads and Linux follows.
Sometimes I wish I was a plumber, then I'd know how to deal with other people's shit.
Perhaps if DirectX actually was inferior, and if it wasn't the primary or only API for 90% of the games out there, you'd have a point.
DirectX is great for PC Games - but for real scientific/commercial work it *SUCKS*.
Whenn Boeing dows the next 7E7 fly-though in DirectX, give me a call.
Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.
Yes but then it would only run Linux alone. The beauty of this system is that it provides both a social as well as technical solution to the Open Source problem.
The technical solution is that it will allow native Linux applications to run in Windows without the massive overhead of emulation.
The social solution is when some Pointy Head Boss who is taken in by MS FUD about the evils of linux and wants you to write an app in that runs in Windows for a task that you know Linux can preform better.
So what do you do? With coLinux, you can still write the app to run in Linux, then run it on the windows machine with coLinux. So it makes the PHB happy by giving the impression that it's running on Windows, but Linux is actualy doing the work and at the same time you gave Linux a foothold on Windows' terrortory.
So down the road, when MS decides it's time to "Upgrade" you can propose that instead of spending millions on new MS licences, you can show that all the applications that were written to run the business runs perfectly and exactly the same under Linux, and it's time tested since all this while Linux was doing the work, thereby justifying ditching MS altogather.
Why this is good is that it provides a bridge between Windows and Linux. You can demostrate without leaving the Windows enviorment, the power of Linux and at the point where you eventualy make the transition, re-education needs will be minimal as employees will already be familier with using native linux apps.
Finally, a technological fix for a social problem.
Sometimes I wish I was a plumber, then I'd know how to deal with other people's shit.
I've seen a number of scattered reasons (above) for running coLinux but here is the scenario I have for using coLinux.
The need to run a linux Distribution from within a Windows box not the need to run Linux applications on a Windows box:
First I want to point out that cygwin will get you a secure shell, gcc, and a number of other biaries, as ported from Linux. But it will not natively behave the same way that Linux does. The primary difference I'm referring to is hardware support and native binary support. It is for this reason that Cygwin will never be as useful to the Linux world as other distributions are. (Contributions back to Linux from Cygwin are not practical.... [Mozilla aside, there are no other good examples of OSS projects where there is a large number of developers porting their software from a Cygwin environ back to Linux]). There are several interesting cases of Linux software being compiled for windows (Xine, Gaim, X, etc) but these programs are not sufficient to be considered a "linux distribution within windows" instead should be considered, Linux apps for windows.
Consider now, my personal usage example, I have had a Linux dist sitting idle on my drive because I sold my second box (power is expensive!), and I needed to develop in MFC (Direct X 9.0) for a course that I was taking (leave linux on one part, install XP on the other). Right now there are several applications and other things that I'm missing from when I had primarily booted Linux, but I can't move away from Windows and still continue my studies (and btw, dual-booting is not an option I'm eager to go back to [takes forever, and I always want that one windows or linux app when I'm in the wrong boot]). So, after this project matures, I will hopefully be able to mount my existing Linux partition, boot my kernel, and access my applications and settings as I left them before, without disturbing my continued study with MFC and Direct X.
A few final points:
1.) XP is not as unstable as everyone here seems to contend, I have had weeks of uptime on my computer at work, as has the other developer who works with me.
2.) Cygwin does not allow developers to comfortably develop Linux apps on windows, and is limited inherently by Windows (terminal width constrained to less than 72 characters, X Windows loads slowly, etc).
3.)There are a number of practical uses for virtual machines but the speed of these systems, their somewhat limited application (hardware) support, and the price of the software ($$$ you would pay a heck of a lot more for VMWare than for Windows XP, buddy) tends to leave something to be desired from that corner of the market.
In conclusion, yeah, coLinux may not change the world, and it may not even turn a few heads, but it certainly could be useful for a number of people such as myself who are looking to get a little bit more Linux out of their Windows boxes.
.: 2+2 = PI SQRT(1+N)
No Windows version.
Can't compile in Cygwin.
Enter coLinux... finally a way to run GnuCash on my Windows laptop.
I am sure there are other programs like this.
It is even possible to run Linux programs in rootless windows so that they appear to be native Windows applications.
Whaddya bet that MS changes their EULA to make running another OS concurrently a violation of said EULA? I can see that happening judging by their history.
That'd be dumb, since then they'd prevent xbox developers from doing work. It would prevent pocketpc developers from doing work.
If they made an exception for MS OSes, it'd be a very obvious anti-trust move.
It would likely be very very slow, but in conjunction with a UMLinux port to the JVM it would allow you to run many Linux x86 binaries on anything with a JVM as long as you packaged enough of the Linux x86 .so libraries with it.
For a while Sun toyed with the idea of a JavaOS where everything but the kernel ran in a JVM. Unfortunately, few people consider even modern JVMs acceptably fast. The JVM forces the Java object model and calling mechanics on the code, so writing code for a JavaOS would be great as long as Java is the best tool for the job.
Additionally, stack-based virtual machines are pretty much ideal for interpreters (see Xavier LeRoy's design paper for Zinc, the O'caml VM) but other VM models are much better suited to just-in-time compilation (see Ken Thompson's Dis VM design paper). Java is a great language, but the JVM was litterally designed to be runnable on 8-bit microcontrollers in toasters and fridges 2 decades ago. Now, 32-bit microcontrollers and RAM are so cheap that Sun should really consider keeping 100% source compatibility but scrapping direct binary campatibilty with it's 8-bit microcontroller optimized stack VM. They could always use something like OpenJIT to implement reverse compatibility inside the Java 3 JVM. (The whole "Java 2 Virtaul Machine v.1.4.2" thing is anoying and confusing for many people. Letting Marketing call it "Java 2" but letting Engineering call it the "1.2.1 JVM" was dumb.)
Diverging back on topic...
The idea of a VM-oriented OS is nice, but it seems that in order to compete with native applications, higher performance and more flexible VM designs are needed.
Vmware, Bochs, and CoLinux can all be thought of as more or less high performance flexible virtual machines, each with a different level of virtualization and performance. A complete re-design in Java 3 would make a JavaOS (such as UMLinux and libraries for the JVM) much more attractive. It looks like Microsoft is working towards a .NET VM (CLR) based OS. This is a logical step in a long historical trend towards more hardware abstraction at the application layer. I'm sad that MS decided to leverage so much of its JVM experience in creating the CLR as a stack-based machine that enforces a particular object model at the lowest level (rather than being enforced at the class loader level), but at least it's a step in the right direction.
Copyright Violation:"theft, piracy"::Anti-Trust Violation:"thermonuclear price terrorism"<-Overly dramatic language.