Will Linux For Windows Change The World? 770
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.)
Gah (Score:5, Funny)
Re:Conquering Windows (Score:5, Funny)
5.) Users
Re:Conquering Windows (Score:4, Informative)
One word: (Score:4, Insightful)
Distributions put these things together for end-users to enjoy, and any recently updated distro worth it's beans has either Gnome 2.4 or the Bitstream Vera fonts. In my not-so-humble opinion, they are far superiour to the fonts in Windows. Unfortunately, however, they look pretty horrid in Windows, if you ask me.
Don't you think you're being pretty unreasonable saying Linux w/KDE or Gnome is unsuitable for anything like this (fonts) when it's already been addressed? You can lead a horse to water but you can't make it drink, download a better distro plz.
Re:Conquering Windows (Score:5, Informative)
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.
Re:Conquering Windows (Score:5, Funny)
Re:Conquering Windows (Score:5, Insightful)
Re:Conquering Windows (Score:5, Interesting)
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.
Re:Conquering Windows (Score:5, Insightful)
Much more money in PC games though I'm afraid. And as always, money talks.
Re:Conquering Windows (Score:5, Funny)
Congratulations Mr. Obvious! (Score:5, Insightful)
No, really? DirectX was designed explicitly for games. That means that early in its life, it sacrificed accuracy for speed (compared to OpenGL, which took the opposite approach and didn't really gain speed on consumer hardware until 3D accelerators took off). Even now, DirectX is driven by games and multimedia, not CAD and scientific/engineering requirements. There's absolutely nothing wrong with that, and in fact it's better for games that it's focused on games and multimedia rather than engineering applications, because the requirements for games are different.
If you're writing scientific software, use OpenGL. If you're writing a (Windows- or XBox-targetted) game, use DirectX.
Oh, yeah, it's also possible to use DirectX and OpenGL together. Like SDL, DirectX is an entire framework, not just a 3D rendering interface. Id and theCarmack use DirectX for input and sound while rendering their 3D visuals in OpenGL.
Re:Conquering Windows (Score:4, Insightful)
Is there a reason why it sucks for such work?
Well, the OpenGL guys have long said that DirectX was only concerned with getting things to "look right," rather than having pure mathematical accuracy. In other words, some of the rendering calculations were done in such a fashion as to make them inappropriate for, say, physics modelling, but fine (and faster) for video games.
That said, I'm not sure that argument holds much water anymore with the later versions of DirectX. It's hard to say, since I don't use it. But anyway, from the games standpoint (which I'll agree is lots more important to Linux's mainstream success) it doesn't make hardly any difference now, which was your main point anyway. Both are plenty fast with modern hardware, and do all the stuff games need.
Which of course means that the point that started all this (that Linux needed DirectX compatibility to succeed) is totally bogus. But then, that's no surprise, so were his other two points.
Re:Conquering Windows (Score:3, Flamebait)
1.) Linux has plenty of great fonts, it just depends what distro you pick and if you install more than just the base packages.
2.) DirectX is a MICROSOFT ONLY format. It will never, ever, be in any linux distro except in emulation form. And for second, why should it be? OpenGL is fine and great, and with 2.0 coming out you can stuff DirectX where the sun don't shine.
3.) Great, so linux gets to turn into Windows by taking away the free choice of picking
Re:Conquering Windows (Score:5, Insightful)
2.) DirectX is a MICROSOFT ONLY format. It will never, ever, be in any linux distro except in emulation form. And for second, why should it be? OpenGL is fine and great, and with 2.0 coming out you can stuff DirectX where the sun don't shine.
At its very core, DirectX is just a set of APIs. Yes, it's a Microsoft API, but the exposed interfaces are well documented, and ignoring any possible legal issues, it is entirely possible to write a DirectX implementation on another platform. Okay, some of you may disagree on whether or not DirectX is well documented, but it's documented well enough for emulation purposes.
There are wrappers [v3x.net] available that translate Direct3D calls into OpenGL calls (similar to Glide wrappers from the 3dfx days), and I don't see any technical problems with removing the OpenGL layer and having the new Direct3D implementation call the graphics card directly. However, and correct me if I'm wrong, I think Linux 3D graphics drivers are currently all proprietary, so nVidia and ATI would have to provide the Direct3D layer.
Still, even with an emulation layer, why SHOULDN'T DirectX run on Linux? Ignore legal issues and Microsoft's desires. Believe it or not, there are some developers who've only used DirectX and not OpenGL+SDL. It's worth having DirectX on Linux even if only a tiny fraction of those developers decide to port to Linux. That fraction may grow, and after familiarizing themselves with Linux they may switch to other APIs that are better supported on Linux, such as OpenGL and SDL.
Re:Conquering Windows (Score:5, Insightful)
Fonts are fonts. I use Windows fonts in Linux. They look great. Big deal.
What do you mean by "the window manager have them?" My fonts look fine. In fact, try any recent distribution like SuSE, Fedora Core, Mandrake, etc., and I think you'll get the same impression.
Without DirectX, few games ever make it to Linux. Thats because DirectX is much more than just a 3-D gaming API. It has other features that make games easier to develop for.
OpenGL+SDL does as well.
Without a standard window manager and a standard API to program for (thanks GNOME vs KDE war), there is hardly any incentive for an application developer to go to linux. Sorry, its just too complicated to make it run correctly (across window managers).
Umm, are you implying that an app compiled against Gnome libraries will suddenly break if you try to run it in KDE? Actually, you can just choose the one you like best and develop for it. Copy and pasting will take care of themselves, and with good themes, they can look nearly identical.
What do you mean running properly "across window managers?" Window managers almost certainly could never prevent a program from working properly, unless they draw a border and buttons when they're not supposed to, for example.
So basically, you can't decide if you would want to program for Gnome or KDE, and you don't like the fonts that distros ship by default (even though haven't been an embarrasing smidgen on the Linux desktop for years), so you don't really think it's worth your time to develop for Linux.
I think it's more than fine to just say "hey, I'm doing fine developing for Windows, I don't have any problems with it, so I don't need to switch." So often zealots convince people on Slashdot that you ought to be ashamed of yourself if you run Windows, and while I disagree with your post and reasons for not choosing Linux as a development platform, I think it's totally fine to not choose Linux for no reason other than you're content with what you have :)
Re:Conquering Windows (Score:3, Insightful)
Couldn't care less. I've never been bothered by my fonts.
2.) automatic directX compatibility for games
This would be a good one. I could go 100% Linux at home.
3.) one solid universal gui
This I don't get. One of the strengths of Linux is options. I don't use a computer the same way as the guy next to me, why should we be stuck with the same interface? I'm incredibly productive in AutoCAD at work, partly because I have customized the interface to exactly the way I use it (to the po
An AutoCAD Clone for Linux (Score:5, Informative)
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 [bricscad.com]
French version [bricscad.com]
German version [bricscad.com]
Interested beta-testers are invited to contact BricsCad at linux@bricscad.com [mailto]
Re:Conquering Windows (Score:5, Insightful)
Well, funny that you think this is a strength. This is IMO the main weakness of all Unix based systems. Too many options means you can be familiar 100% with your system, and yet you won't be able to operate (well) another Linux, because things are so different. Hence the difficulty to debug your mom's Linux on the phone because your freaking brother installed it and he's on vacation right now, so you have no clue how to drive your mom through the command line stuff. With Windows, if she has a Win98 and you too, you're on the same page. It basically boils down to:
If you want a huge userbase, and a lot of knowledge of your system spread around, present a homogen system. Heterogen system will look (from Joes SixPack's point of view) as different systems, and he will be - rightfully - scared. Joe Sixpack wants a system that works. Not a tetrazillion of options and choices. Joe is scared by choices by nature.
Re:Conquering Windows (Score:5, Insightful)
Ever since XFT2/fontconfig and the Bitstream Vera fonts have been released, I've been enjoying high-quality, subpixel antialiased fonts on my Linux desktop computer. I suggest you to upgrade to a modern distribution and use the Vera fonts.
Alternatives are not going away. What's wrong with making both GNOME and KDE so userfriendly that the user can find it's way no matter which desktop he's using?
Some people prefer simplicity while other people prefer power and bells & whistles. What's wrong with being able to choose what desktop you want based on your *preference*?
In case you don't want to choose - fine, use whatever default desktop is chosen by your distribution. You don't have to choose if you really don't want to.
As for standardizes interfaces: even Windows doesn't have standardized interfaces. Installers all look a little different from each other - fullscreen blue InstallShield, MSI, Win2k-style InstallShield, fullscreen Inno Setup, Win2k-style Inno Setup, WinSFX, WISE Installer, etc. etc.
An installation system that handles dependancies with no user interfaction is being worked on - see my sig. We're close to 1.0.
Re:Conquering Windows (Score:3, Interesting)
0.) Driver support from the vendor side
Even if we had directX compatibility we would still be missing video drivers, storage drivers, etc. All of those items, to be a sustainable resource, have to come from the horses mouth (as in I can get my Radeon working with the Open driver, but to get 3D acceleration I need the binary driver from ATI
Cleartype - prior art by Steve Wozniak? (Score:4, Informative)
Re:Cleartype - prior art by Steve Wozniak? (Score:4, Informative)
That's not entirely true. The Apple ][c and ][gs used subpixel tricks to increase their horizontal resolution, but they never used it to antialias fonts. In fact, fonts on the ][gs looked worse because of this (you'd often see little purple and green pixels on the edges of your fonts when against a subpixel dithered background)
Re:Conquering Windows (Score:5, Insightful)
"ClearType" is a Microsoft branding term. The generalized term, subpixel rendering, is definitely supported under XFree86 and x.org. LCDs with multiple layout order of the RGB elements are even supported.
2.) automatic directX compatibility for games
WINE does this, but honestly, while there are a lot of game developers out there that know DirectX, there's nothing particularly magical about DirectX, and it'd be pretty hard to "just" do DirectX without supporting the other chunks of the Windows API (though I guess you could do a "DirectX-like" API). OpenGL is a truly open standard that's widely supported (and preferred by videocard developers), and SDL and its child libraries provide a more modular system than DirectX does.
one solid universal gui
I see why you want it, but it's not going to happen. Too many KDE people like KDE (which is, while not unbreakably, still strongly tied to Qt) and too many people have legal issues with Qt or prefer GNOME for technical reasons.
Honestly, I don't think it's all that necessary, either. Windows users have been using non-Windows widget sets for a long time in major apps -- Lotus Notes or Mozilla or any of the standard Win32 variants, which operate differently over the Win95-WinXP lifetime. People adapt pretty well. Both Qt and GTK are pretty snappy. Both interoperate pretty well today. Two widget sets is hardly a reason for a platform to fall apart.
Re:Conquering Windows (Score:4, Insightful)
1. Integration of video drivers into the kernel. Yes this makes it unstable, but Linux currently is plagued by the problem that Windows NT 3.51 had using fastLPC and HAL to control the video cards. Integrating into the kernel will give the necessary speed.
Well, shit, here this whole time I thought nvidia.o was loaded into my running kernel each time I booted. (Oh, and before you start going on about the GLX module, it's in the right spot too...suggesting it should be a kernel module would be obtuse at best.
2. A thread model that allows thread ownership to be changed dynamically. Most important is the thread model. IPC is just too dammed slow compared to reading a common memory heap for a process. Without a thread model it is very difficult to make a responsive GUI application that does anything complex (unless of course you use IPC and spawn several processes).
Without a thread model? Pthreads? Oh, and about thread ownership changing dynamically, I'm too frightened by the security consequences of something like this to even think about it.
3. A GUI messaging system that makes much faster calls on the operating system. GUI applications will not be able to compete with the speed of windows apps unless something is done to integrate this GUI messaging system with the OS. While this sounds like it is forcing a default Window manager, this isn't so. It just requires a programming standard to the messaging system to be written.
You know, Linux could use that. Perhaps even through a scheduler that can dynamically reassign priority to a server process when a client is waiting on it....hmmm....Oh wow...that's funny...that's in the 2.6 kernel.
I'm not saying X is perfect...but it's pretty damn good, with speed in the same neighborhood as Windows. And looking at the change in performance over time of the two systems (Windows slowing down, X speeding up), it's not X that should be worried.
Re:Gah (Score:3, Funny)
Hmmmmmm (Score:5, Funny)
Cygwin, MS Services for Unix? (Score:4, Interesting)
Re:Cygwin, MS Services for Unix? (Score:4, Funny)
Re:Cygwin, MS Services for Unix? (Score:5, Informative)
It actually works! (Score:4, Interesting)
I happened to be playing with coLinux for the first time this afternoon (beating the
It works easier than I expected. And it really does use regular binares. For instance, I've just installed X and KDE from the regular Debian package repositories.
I tend to think of this as a specialized, i.e. Linux Only, alternative to a VMWARE for Windows license. Free, and moderately easy to install - I'm sure that in time, it'll be a lot easier to setup.
Re:Cygwin, MS Services for Unix? (Score:5, Informative)
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.
Re:Cygwin, MS Services for Unix? (Score:5, Informative)
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.
Re:Cygwin, MS Services for Unix? (Score:4, Interesting)
Re:Cygwin, MS Services for Unix? (Score:3, Informative)
Yes, Cygwin is nice. But I've found it considerably slower than a native Linux box.
I occasionally have to mangle several gigs of text-based log files. I can toss together a nice script in my Cygwin environment. But when I want to run the real job... I better scp it over to one of the dev Linux boxes and run it there. Otherwise it will take weeks longer to run.
Maybe it's something in my config. I haven't spent much time looking in to it.
Good idea (Score:5, Interesting)
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.
Linux on the JVM (Score:4, Interesting)
Its pretty hard tho - the JVM is nowhere near a complete hardware platform, but it would be possible.
Re:Linux on the JVM (Score:5, Interesting)
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.
Re:POSIX?? (Score:5, Informative)
Re:Good idea (Score:5, Interesting)
Software became a licencee under NDA of Microsoft's NT code and developed Interix as an alternative and far more robust Posix subsystem.
One of the things that makes it radically different (and superior) to things like Cygwin is that Interix is a whole seperate subsystem that talks directly to the NT kernel, in parallel with the Win32 subsystem. Cygwin is a DLL kludge that rides on top of the Win32 subsystem. Everything is translated through an entire extra layer for Cygwin.
I licensed a copy of Interix before Microsoft acquired Softway Systems. My copy came as a nice bundle, with the Interix POSIX subsystem, Motif, the Motif libraries, and the Exceed X server. It included binaries for NT-x86 and NT-Alpha. It included a complete GNU toolchain, including the GNU C Compiler, etc.
The latest incarnation of Interix, since Microsoft bought Softway Systems, is somewhat 'dumbed down' from what it was in it's glory. With Interix installed on an NT4 system back in the day you could set it up with Inetd and make it a remotely accessable system that nobody even had to know was running on an NT box. Some of that is probably still possible, but Microsoft has pared away a lot of the useful binaries, i.e. it doesn't even have the vi editor anymore.
At a point shortly before Microsoft purchased Softway Systems, the Softway people put out 'feelers' to see if anybody in the OSS community was interested in Interix being 'open sourced'. Near as I can tell nobody at all responded. Microsoft bought it shortly after.
Seems Like (Score:3, Interesting)
Re:Seems Like (Score:5, Funny)
But with Apple, the crappy system runs inside the good system; with this it's the reverse.
Re:Seems Like (Score:4, Informative)
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.
If it works very well... (Score:5, Interesting)
So, the next time your manager is afraid of having a Linux server on the production network, use CoLinux instead?
How about... (Score:4, Funny)
Re:How about... (Score:4, Informative)
Might not work, but the other way around should. (Score:3, Interesting)
Probably wouldn't work. I doubt Wine (not)emulates that part of Windows.
But you should be able to do it the other way around: Run Windows apps in Wine in Linux in CoLinux in Windows.
Wouldn't be totally silly either: You could more ealisy compare the apps behavior under Wine and under Windows. (Though if it was sluggish or flakey on the Wine/Linux/CoLinux/Windows stack you'd have to confirm with Wine on native Linux to be sure it wasn't an
Street Fighter: The Movie: Game. (Score:3, Funny)
That's pretty close. =)
So... (Score:4, Funny)
Re:So... (Score:4, Funny)
Maybe a stupid question... (Score:3, Insightful)
Why? and How?
Hardware is so cheap, I would just get two boxes.
Landrew, guide me!
Re:Maybe a stupid question... (Score:3, Informative)
Hardware is not cheap if we are talking about good hardware. It also needs care and feeding (such as UPS power, cooling, new fans once a year, cleaning, rack space, RAM, RAID etc.) You can save a lot in any business environment this way. Even in home conditions you will save a lot on energy if you have only one box 24/7 and not two.
Re:Maybe a stupid question... (Score:5, Interesting)
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.
Re:Maybe a stupid question... (Score:4, Insightful)
Very importantly, Linux running on Windows can be used to train Windows users on migrating to Linux. No messy dual-booting setups required. Just copy Linux and "click to start".
Secondly, this opens up Linux for sampling to many more interested users who are wondering what the hype is all about. I am not talking about the typical Slashdot geek here. Instead normal people with techie inclinations who want to try out things.
Thirdly, it is an easier way for running pilot trials of Linux deployments in a corporate environment. As no extra servers are required, no extra money needs to be sent. Although administration effort will obviously increase, it won't be to the extent of twice the administration effort of the original Windows server on which Linux is running.
One huge barrier to Linux adoption is that management does not want to do a trial deployment at most times due to the cost involved. This will certainly mitigate that.
next thing you know... (Score:5, Funny)
but why? (Score:3, Insightful)
Re:but why? (Score:5, Insightful)
VMWare is like $300. CoLinux is free.
Development for Windows weenies (Score:4, Insightful)
And no, a second box is not a solution. "Hardware is so cheap" doesn't cut out the fact that many aspiring coders may not even have $50 (hell, I started at 9, think I had that kind of chash?), may not have the desk space, may not want the extra power drain, may not want to get a second monitor (or a KVM), etc. Just running Linux in a "window" on Windows is very cheap ($0, assuming they already own the Windows machine), provides no physical space/power hassles, and would be rather easy to use.
Again, for some people, switching to Linux, a second box, or dual booting just *isn't a choice*. For those people, CoLinux is a boon. For the rest of us, it's just a sick toy.
Article Text... (Score:5, Informative)
Another way to break the wall? (Score:4, Insightful)
Link to the colinux project (Score:5, Informative)
- Dunno, seems like the original article missed the actual link.
Has anyone tried this on this CoLinux (Score:3, Funny)
1)Run Windows XP.
2)Install CoLinux
3)Install Wine in CoLinux
4)Run windows applications in Wine
Well, if you have nothing else to do on a weekend.........
Re:Has anyone tried this on this CoLinux (Score:4, Funny)
What the fuck else are we going to do? Date? Sheesh.
Bundle it... (Score:3, Insightful)
Thats how you change the world.
Worked well for Microsoft.
Support? (Score:5, Interesting)
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?
Re:Support? (Score:3, Funny)
Can Microsoft really refuse to support your windows installation if you're running Linux (as an application, even?)
How much do they "support" installations of Windows anyway? Could it truly get any less supported?
But why? (Score:3, Insightful)
Either OS can now crash the machine, so the MTBF gets worse. You get to pay both Microsoft and Red Hat. And few people run Linux because they like the desktop applications.
This sounds like one of those "I'm l33t" toys.
The ability to run Windows apps on Linux is far more useful.
Becuase some devices have only Windows drivers (Score:4, Interesting)
So, why not just boot into windows, do my scanning and get out?
Because scanning a roll of film can take hours of off and on work. I don't want to to be stuck with Windows that whole time.
Wine (when it works at all) is of no help. It runs only apps, not drivers. Even VMware, when the host OS is Linux, is of no help.
Severe limitation (Score:5, Informative)
Re:Severe limitation (Score:5, Funny)
I can see why it would run a little slower under linux, but 41 minutes [colinux.org]?!?
plex86? (Score:5, Informative)
CoLinux [linuxkernel.net] is apparently somewhat similar to Plex86, but additionally requires admin access whereas Plex86 wasn't supposed to. Anyone know more?
in reverse (Score:5, Insightful)
-m
Re:in reverse (Score:5, Interesting)
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.
Re:in reverse (Score:3, Informative)
There's nothing to reverse!
This isn't Linux running on Windows or Windows running on LInux! It's fundamentally different, as in time-slicing the CPU:
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 gene
Advantage (Score:3, Insightful)
Then convince them that the 95% market share of Windows is not a problem, since the app will run in Windows anyway.
Answer: No (Score:5, Insightful)
How often do we, here at /., ask if a new software development is going to change the world? Constantly. And how often does it? Never.
This is no exception. It's just a sort of more native version of Cygwin. Sure, it could be kind of nifty, but it's not some major breakthrough which will leave the world shocked.
Could people please stop being so melodramatic with their subject lines?
Come on (Score:4, Funny)
Overall, it's a "good thing"... (Score:5, Insightful)
I also see it as a good thing in some corporate environments. Say you have a call center, and all the operatives have been trained to use some program for their task (let's say they're in a credit card environment) and their software is Unix based. Well, porting to Linux could be straightforward. Also for these operators they don't need to access the computer for anything much besides this application... and maybe the web and email to keep in contact with people. So these guys would have Linux desktops. Now there would also be some other administrative people who don't take calls, and who have other tasks. Like payroll, or some other fancy tasks. Maybe these programs were written for Windows, and there is no Linux port planned. Rather than trying to make these programs work through Wine or Crossover Office or something like that the obvious solution is to make Linux run on top of Windows. Then people have the best of both worlds for those kind of operations.
I also see advantages of running CoLinux in a dual boot environmemnt. That is, if you are short on disk space. I presume that CoLinux would run on the same filesystem as Windows. In a traditional dual boot system you might have a 20 gb disk, and split it up two ways - 10gb for Windows, and 10Gb for Linux. Let's suppose you are a Windows fan, and you easily eat up that 10Gb for Windows use, and hardly use Linux, except to 'play around with'. You then have 8Gb of disk space that Windows can't access natively (yes there are third party apps now that get around this) and as such you are short on space. So if Windows and Linux are sharing the same 20Gb partition, then Windows can use more than that smaller partition on those occasions it is deemed necessary (like downloading by broadband that 5Gb linux distribution on X # of CD's).
I don't see it as a "real major" security problem, because I perceive its main target is the desktop, and not for running security-critical applications which could get hacked to shreds. Also that these Windows boxes would be firewalled anyway for Internet access - behind native Linux firewalls on native Linux machines.
Mark.
Why not vmware? One word: laptops (Score:3, Insightful)
I wouldn't do it without a 3.0 Mhz system with 2 Gb of RAM, and at least a 40 Gb disk. I happen to have such a laptop, and I bought it especially for this purpose and paid lots of bucks for it. But my old 1.7 Ghz, 30 Gb, 256 Mb RAM Vaio R505 should be able to handle this...
Motivation from Windows (Score:3, Insightful)
And on a different note, people will get to see the most stable program that Windows has to offer. Even though it may crash a few times, giving Linux a bad name... but it's Windows fault.
EULA (Score:3, Insightful)
Re:EULA (Score:5, Interesting)
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.
Why a user might want to run coLinux... (Score:5, Interesting)
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.
One Practical Use: GnuCash! (Score:5, Interesting)
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 [colinux.org] so that they appear to be native Windows applications.
A Summary Of What's Going On (Score:5, Informative)
===
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.
No, it won't change the world (Score:4, Insightful)
Which of these do you get if you run Linux over Windows?
None of the above, of course.
If one simply needs a Open Source Office, that's what OpenOffice.org is for and there is a Windows version.
If there were a killer app for the general population that only ran on Linux and can't be ported, this might make sense. Name one.
This may be touted as a technical miracle, and it might be. But change the world? Looks more to me like a solution in search of a problem.
This is just what Windows has been needing. (Score:4, Funny)
Re:What's the difference (Score:5, Informative)
Re:What's the difference (Score:5, Informative)
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.
Re:possibly not (Score:5, Insightful)
The biggest benefit I see is that people could start running (and liking?) Linux applications without having to make "the big switch." Once they realize that they like Linux better and [hopefully] can do everything they need to under Linux, then the next computer they buy may run Linux alone. It's certainly more elegant and appealing to current Windows users than just telling them they're unsophisticated dolts for not using Linux.
Re:possibly not (Score:3, Insightful)
I doubt this will turn to much, it seems like a toy for geeks.
Re:possibly not (Score:5, Interesting)
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.
Re:Side by side comparison (Score:3, Insightful)
You're comparing twm (an ancient window manager used by basically nobody these days) vs. WinXP (the latest and "greatest" from Microsoft)? Give me a break... A comparable Windows GUI for twm is Win1.0...
Even with the KDE shell (via Knoppix), the XP UI is much more polished and 'consumer friendly' than t
Re:Side by side comparison (Score:3, Insightful)
For mass adoption, oh yeas it is the most important part. Parent post is not exactly off-topic either, considering the Slashdot story asks about Linux changing the world.
Re:What about Cygwin? (Score:5, Informative)
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.
Re:What about Corel? (Score:3, Informative)
I believe what they basically did was use the loopback device to put a Linux filesystem inside a file on the Windows filesystem. That served as the root filesystem for Linux.
So, basically it was a dual-boot setup, where you did not have to repartition your disk to get space for Linux.
Re:Hmm (Score:4, Informative)
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.
Three letters... KVM (Score:3, Interesting)
Re:whatever (Score:5, Insightful)
Of course, the second biggest part of the hurdle is customizing the system without having to learn all the nuts and bolts of operating system function. This is *almost* solved, but compared to the rather intuitive and standardized interface that Windows has nothing in the OSS community has been able to match it.
For example, tweaking options for a program should be done via an "options" menu of some kind there is a logical, visual organization to the settings with checkboxes and drop down lists, not a 30+ page
God help you if it's case sensitive or syntactically anal, too; you may never get it right unless you've done it several times before. Your average home user doesn't have the patience to deal with that kind of thing, and until this hurdle is taken down they'll stick with Windows for sure.
=Smidge=
Re:Linux Under XP? I'm So Non-Excited (Score:5, Informative)
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).It works if you RTFM (Score:5, Informative)
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.