Whizzkid develops Linux application for Windows
April 12, 2004 4:42 PM Subscribe
Whizzkid develops Linux application for Windows [...]The significance of the development is that Linux and Windows are able to work in parallel on the same computer or server. To[sic] now, the computer world is divided into systems that operate either with Windows or with Linux. [...]
Wow, that article managed to entirely avoid saying what they'd actually done.
If they've managed to run linux applications under windows: It's been done, see cygwin.
If they've managed to run a linux kernel under windows: It's been done, see vmware.
Mind you, there's still some room for improvement, it'd be nice to see something like vmware being done with less privileges, something like usermode linux being run under windows. But it certainly won't create a stir in the computing world, at most a mild twitch.
posted by fvw at 4:48 PM on April 12, 2004
If they've managed to run linux applications under windows: It's been done, see cygwin.
If they've managed to run a linux kernel under windows: It's been done, see vmware.
Mind you, there's still some room for improvement, it'd be nice to see something like vmware being done with less privileges, something like usermode linux being run under windows. But it certainly won't create a stir in the computing world, at most a mild twitch.
posted by fvw at 4:48 PM on April 12, 2004
I think you're both about right -- it's sort of vmware-like. Based on a quick googling, the project's homepage is here (I think), and there's a sourceforge page, too. It seems pretty interesting, if not revolutionary.
posted by Zonker at 4:50 PM on April 12, 2004
posted by Zonker at 4:50 PM on April 12, 2004
the computer world is divided into systems that operate either with Windows or with Linux
Really? I could have sworn there were a few others like Unix and all of its variants, including Mac OS X.
And MS hasn't responded to this "threat"? How surprising.
posted by fenriq at 4:51 PM on April 12, 2004
Really? I could have sworn there were a few others like Unix and all of its variants, including Mac OS X.
And MS hasn't responded to this "threat"? How surprising.
posted by fenriq at 4:51 PM on April 12, 2004
I've discovered this awesome secret way of developing applications that run on Linux and Windows AND Mac, check it out.
posted by badstone at 5:08 PM on April 12, 2004
posted by badstone at 5:08 PM on April 12, 2004
"Yellow journalism" is very common in Israel
(from the live journal link)
i have heard that, but i don't want to go repeating it without backing lest i sound anti-semetic... can anyone substantiate the claim?
Aljazeera has a special feature up right now about the joke that is 'israeli journalistic integrity' but then aljazeera isn't exactly an unbiased 3rd party......... link
posted by Tryptophan-5ht at 5:10 PM on April 12, 2004
(from the live journal link)
i have heard that, but i don't want to go repeating it without backing lest i sound anti-semetic... can anyone substantiate the claim?
Aljazeera has a special feature up right now about the joke that is 'israeli journalistic integrity' but then aljazeera isn't exactly an unbiased 3rd party......... link
posted by Tryptophan-5ht at 5:10 PM on April 12, 2004
I'm not belittling his achievement. I'm belittling the tone of the article, as this somehow represents a threat vector to Microsoft.
A version of the Linux kernel that can coexist with another operating system isn't that revolutionary - it's interesting, and may have some practical value. But I doubt it's going to keep Microsoft up at night. No one in their right mind would run this thing in a production environment.
As for allowing support, who in their right mind would attempt to support a machine simultaneously running multiple kernels? You know the first question any tech support person with half a clue is going to ask - "please stop one of the operating systems, so we can determine which one may be causing the problem."
posted by FormlessOne at 5:14 PM on April 12, 2004
A version of the Linux kernel that can coexist with another operating system isn't that revolutionary - it's interesting, and may have some practical value. But I doubt it's going to keep Microsoft up at night. No one in their right mind would run this thing in a production environment.
As for allowing support, who in their right mind would attempt to support a machine simultaneously running multiple kernels? You know the first question any tech support person with half a clue is going to ask - "please stop one of the operating systems, so we can determine which one may be causing the problem."
posted by FormlessOne at 5:14 PM on April 12, 2004
I won't belittle the achievement either, but how do successes like this get good press with so little details? It seems obvious the reporter doesn't grasp the significance of whatever this software does.
It reminds me of a story a while ago (anyone have the link?) of a kid who made some browser that goes 5000 times faster than IE or some outrageously advertised amount, but then I never heard anything more about it. Sometimes I wonder if these computer guys are pulling the reporter's chains.
posted by banished at 5:28 PM on April 12, 2004
It reminds me of a story a while ago (anyone have the link?) of a kid who made some browser that goes 5000 times faster than IE or some outrageously advertised amount, but then I never heard anything more about it. Sometimes I wonder if these computer guys are pulling the reporter's chains.
posted by banished at 5:28 PM on April 12, 2004
colinux is old news, not to say that it's not interesting news. actually I'd kinda forgotten about it already, so I'm glad to have been reminded of it (in an obtuse way, since that article is vaguely intelligible...)
it's not really a threat to microsoft, but it is a damned amazing achievement. the kernel is running in ring-zero almost as a *driver* of windows. it's bizarre. but it also has the potential to be way more useful than either vmware or cygwin. it did create a stir, back when it was announced; since then, not so much.
as for machines running multiple simultaneous kernels, ibm has been doing that for a while. not that a home pc user is going to get similar support as the sort of big-iron customers of ibm...
posted by dorian at 5:29 PM on April 12, 2004
it's not really a threat to microsoft, but it is a damned amazing achievement. the kernel is running in ring-zero almost as a *driver* of windows. it's bizarre. but it also has the potential to be way more useful than either vmware or cygwin. it did create a stir, back when it was announced; since then, not so much.
as for machines running multiple simultaneous kernels, ibm has been doing that for a while. not that a home pc user is going to get similar support as the sort of big-iron customers of ibm...
posted by dorian at 5:29 PM on April 12, 2004
I don't know if this is much of a threat for microsoft (at least in the OS domain)the whole purpose of this software is to coexist with windows right? doesn't that already imply that windows has already been installed?
Nonetheless, one cute application is for people developing/testing applications in both environments can do so simultaneously in both linux and windows without having to switch/reboot...
posted by nish01 at 5:46 PM on April 12, 2004
Nonetheless, one cute application is for people developing/testing applications in both environments can do so simultaneously in both linux and windows without having to switch/reboot...
posted by nish01 at 5:46 PM on April 12, 2004
VMWare might be a much better solution for those people, since it actually protects the host operating system from what's happening on the virtual machine. The way this thing is set up, I don't know how you'd isolate the two systems for debugging purposes: it would be impossible to tell which system is causing a problem, or if the problem might be arising from the interaction between the two systems. It seems very cool for the end-user, though. Much smoother than emulation or a virtual machine, I would expect. It also seems like it could have just devastating failure modes, though. Let's see if he can get an X server running....
posted by mr_roboto at 6:12 PM on April 12, 2004
posted by mr_roboto at 6:12 PM on April 12, 2004
If the post is less than worthwhilek I apologize. I have no tech background and certainly no tech skills but on reading the piece I thought it might be useful information for those who did have such skills...Over my head I am afraid..sorry.
posted by Postroad at 6:48 PM on April 12, 2004
posted by Postroad at 6:48 PM on April 12, 2004
I can understand disliking the term "Whiz Kid," as it's diminutive and a stereotype. But "Whizz Kid," now that's downright scatological (whizzological, whatever).
posted by scarabic at 7:08 PM on April 12, 2004
posted by scarabic at 7:08 PM on April 12, 2004
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.
The CoLinux guy simply noted that, if Ring 0 has total control of the PC, and is already used to run one kernel, why not have it run another kernel at the same time?
So that's what he did. Instead of having a device driver talk to hardware, he had it loop back around and create a whole new chain of operations -- Linux, at full permissions on the underlying hardware, with only the slightest of barriers necessary to keep it from wiping out the original operating environment. And this is no minor demo, but a full environment thats successfully booted and operated an entire CD-bootable Linux environment without a single failure. And since there's almost no virtualization, speed is only negligibly impacted.
This is the first full-speed Linux-In-Windows solution we've ever seen, and to see it this capable at this early level of development is shocking.
The biggest concern is that the two environments will contend for the same resources, but the code appears to do this very successfully. Don't get me wrong -- there's lots of room for polish. But this is some really, flat out, impressive stuff that gets this Cygwin _and_ VMWare using hacker very, very excited.
Incidentally, IBM kit offers much, much better hardware support for this kind of virtualization than x86 does, to the point where it's simply not the same kind of problem to do this on a mainframe as it is to do it on a PC.
posted by effugas at 7:48 PM on April 12, 2004
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.
The CoLinux guy simply noted that, if Ring 0 has total control of the PC, and is already used to run one kernel, why not have it run another kernel at the same time?
So that's what he did. Instead of having a device driver talk to hardware, he had it loop back around and create a whole new chain of operations -- Linux, at full permissions on the underlying hardware, with only the slightest of barriers necessary to keep it from wiping out the original operating environment. And this is no minor demo, but a full environment thats successfully booted and operated an entire CD-bootable Linux environment without a single failure. And since there's almost no virtualization, speed is only negligibly impacted.
This is the first full-speed Linux-In-Windows solution we've ever seen, and to see it this capable at this early level of development is shocking.
The biggest concern is that the two environments will contend for the same resources, but the code appears to do this very successfully. Don't get me wrong -- there's lots of room for polish. But this is some really, flat out, impressive stuff that gets this Cygwin _and_ VMWare using hacker very, very excited.
Incidentally, IBM kit offers much, much better hardware support for this kind of virtualization than x86 does, to the point where it's simply not the same kind of problem to do this on a mainframe as it is to do it on a PC.
posted by effugas at 7:48 PM on April 12, 2004
effugas that was a very, very good job at explaining what is going on in modern PCs. you've made another hacker proud. i was wondering though, (and the clarity of your explanation makes me question myself) is the Ring 0 paradigm a x86 arch thing, or rather a windows invention. i stopped coding assembly slightly after my IBM 486/75 and i am still under the impression that x86 protected mode is "flat," and there were not really anything other than protected and non-protected modes. could you clarify or point to some learning material? thanks..
posted by cmicali at 8:52 PM on April 12, 2004
posted by cmicali at 8:52 PM on April 12, 2004
cmicali: Ring 0 (and 1, 2 and 3) is part of the x86 privilege architecture. Most OSs only use 0 and 3. As for pmode vs real or long mode, the only real difference between them is how memory is accessed - 16bit for real mode, 32bit for protected, 64bit for long. As a result, it doesn't have any effect on the ring that the code is running on, which is generally dictated by your kernel.
posted by Jairus at 9:33 PM on April 12, 2004
posted by Jairus at 9:33 PM on April 12, 2004
...that is to say, your assembly apps are running on Ring 3, because that's where the kernel (which on in Ring 0) wants the apps to be.
posted by Jairus at 9:34 PM on April 12, 2004
posted by Jairus at 9:34 PM on April 12, 2004
effugas, thanks for such an articulate explanation..
From your explanation what I don't understand is whether vmware still has to make calls to the native OS to utilize the hardware. If it still does then what is the difference between cygwin and vmware...
Thanks for the great post Postroad
posted by nish01 at 10:11 PM on April 12, 2004
From your explanation what I don't understand is whether vmware still has to make calls to the native OS to utilize the hardware. If it still does then what is the difference between cygwin and vmware...
Thanks for the great post Postroad
posted by nish01 at 10:11 PM on April 12, 2004
nish--
Technically, VMWare is a device driver that creates a virtualized x86 environment on top of the actual Ring 0. In other words, it emulates a Ring 0 environment in what I think is actually Ring 1 (though it could be 3 -- I actualy admit some lack of knowledge regarding the precise privs of Ring 1 and 2). The key thing to understand is that most system functionality is not implemented directly through the Windows kernel: A "file open" call is not mapped to the NT kernel, as it is with Cygwin, but done either directly or through a VMWare specific interface (i.e. NT locks an entire file, which the VMWare device driver exports as an IDE drive, which the Linux kernel speaks to as if it was a hard drive connected to the IDE bus.)
As Jarius says, Rings are an x86 thing.
One of the more interesting things, incidentally, is the degree of overlap between the concepts of memory protection between processes and NAT for networks. Ring 0 has, as far as I know, direct access to the actual memory layout of the entire system, but code running in other rings receive "fake ranges" that don't have any necessary linkage to the real layout of system memory. This is what a segmentation violation refers to -- when a process attempts to access a memory chunk outside a specific range it was assigned -- and is similar to NAT in that it makes it a "special case" for two processes to directly communicate, at least by native addresses. Potentially, one of the really cool things about CoLinux will be the ability to debug Windows, at a core level, from within a Unix environment, since as a Ring 0 process CoLinux will have as full access to the underlying environment as Windows itself.
Of course, all the DRM folks just had a heart attack :-)
posted by effugas at 11:43 PM on April 12, 2004
Technically, VMWare is a device driver that creates a virtualized x86 environment on top of the actual Ring 0. In other words, it emulates a Ring 0 environment in what I think is actually Ring 1 (though it could be 3 -- I actualy admit some lack of knowledge regarding the precise privs of Ring 1 and 2). The key thing to understand is that most system functionality is not implemented directly through the Windows kernel: A "file open" call is not mapped to the NT kernel, as it is with Cygwin, but done either directly or through a VMWare specific interface (i.e. NT locks an entire file, which the VMWare device driver exports as an IDE drive, which the Linux kernel speaks to as if it was a hard drive connected to the IDE bus.)
As Jarius says, Rings are an x86 thing.
One of the more interesting things, incidentally, is the degree of overlap between the concepts of memory protection between processes and NAT for networks. Ring 0 has, as far as I know, direct access to the actual memory layout of the entire system, but code running in other rings receive "fake ranges" that don't have any necessary linkage to the real layout of system memory. This is what a segmentation violation refers to -- when a process attempts to access a memory chunk outside a specific range it was assigned -- and is similar to NAT in that it makes it a "special case" for two processes to directly communicate, at least by native addresses. Potentially, one of the really cool things about CoLinux will be the ability to debug Windows, at a core level, from within a Unix environment, since as a Ring 0 process CoLinux will have as full access to the underlying environment as Windows itself.
Of course, all the DRM folks just had a heart attack :-)
posted by effugas at 11:43 PM on April 12, 2004
Pushing linux into ring 1 is nifty and all, but it's been done before by adeos. Mind you, they didn't stuff it into windows. I wonder if the CoLinux people had access to the windows kernel code?
Nice to actually have a use for the trainwrecks that are ring 1 and 2 anyway…
posted by fvw at 2:24 AM on April 13, 2004
Nice to actually have a use for the trainwrecks that are ring 1 and 2 anyway…
posted by fvw at 2:24 AM on April 13, 2004
fvw--
He's not pushing Linux into Ring 1. He's actually running the Linux kernel as a device driver at Ring 0, context switching repeatedly between the Windows kernel and the Linux one. Upon analysis, he seems to be modifying the Linux kernel to play nice with Windows -- don't muck the RTC, probably removing a bunch of hardware probes, etc. But the capabilities are there.
posted by effugas at 3:46 AM on April 13, 2004
He's not pushing Linux into Ring 1. He's actually running the Linux kernel as a device driver at Ring 0, context switching repeatedly between the Windows kernel and the Linux one. Upon analysis, he seems to be modifying the Linux kernel to play nice with Windows -- don't muck the RTC, probably removing a bunch of hardware probes, etc. But the capabilities are there.
posted by effugas at 3:46 AM on April 13, 2004
Oh, right. That's actually a lot less work (you lose a lot of operations in in ring 1). Still, if it works it works.
posted by fvw at 4:02 AM on April 13, 2004
posted by fvw at 4:02 AM on April 13, 2004
Of course, all the DRM folks just had a heart attack :-)
heh, aren't computers beautiful? I wonder what the first drm-circumvention linux/bsd/whatever distro will be called, cowindows?
even if they can manage to shove a total hardware/ms solution down the public's throats, they're in for a big shock. it's almost as if fundamentally not-getting-it is part of their business model. oh wait...
posted by dorian at 8:13 AM on April 13, 2004
heh, aren't computers beautiful? I wonder what the first drm-circumvention linux/bsd/whatever distro will be called, cowindows?
even if they can manage to shove a total hardware/ms solution down the public's throats, they're in for a big shock. it's almost as if fundamentally not-getting-it is part of their business model. oh wait...
posted by dorian at 8:13 AM on April 13, 2004
Of course, all the DRM folks just had a heart attack ...
Would anyone like to explain this to a non-geek?
posted by Termite at 12:37 PM on April 13, 2004
Would anyone like to explain this to a non-geek?
posted by Termite at 12:37 PM on April 13, 2004
Termite: normally on a memory-protected operating system like Windows NT / 2000 / XP programs do not have direct access to memory. More specifically they are limited to the memory that they have requested from the kernel - this means they can only read or write to their allocation.
Any attempt to reference memory directly is caught by the kernel and prevented; if this is left unchecked then a poorly written program could bring down the entire system. This memory protection is good if you want a stable system that can survive a program crashing - but also means that it becomes much more difficult to see what other programs are doing, say if they are decrypting DRM files to play.
Having the ability to run linux alongside the windows kernel means that colinux has complete access to the system and therefore could, as an example, find the key used to decrypt a DRM or simply copy out the decrypted audio / video stream straight to a file.
As with any encryption scheme the biggest area of weakness is that the content must be converted to a raw format at some point so the consumer can view / listen to it. This conversion process is where most cracking effort is directed as it is easier to let the system decode the content and then grab it rather than attempt to decode the content yourself by bruteforce.
This all becomes a moot point however if you can freely observe what the system does to decode file, what encryption keys it uses and how. This is what coLinux (amongst a whole straft of other, considerably more legal applications) would allow you to do.
posted by gi_wrighty at 3:02 PM on April 13, 2004
Any attempt to reference memory directly is caught by the kernel and prevented; if this is left unchecked then a poorly written program could bring down the entire system. This memory protection is good if you want a stable system that can survive a program crashing - but also means that it becomes much more difficult to see what other programs are doing, say if they are decrypting DRM files to play.
Having the ability to run linux alongside the windows kernel means that colinux has complete access to the system and therefore could, as an example, find the key used to decrypt a DRM or simply copy out the decrypted audio / video stream straight to a file.
As with any encryption scheme the biggest area of weakness is that the content must be converted to a raw format at some point so the consumer can view / listen to it. This conversion process is where most cracking effort is directed as it is easier to let the system decode the content and then grab it rather than attempt to decode the content yourself by bruteforce.
This all becomes a moot point however if you can freely observe what the system does to decode file, what encryption keys it uses and how. This is what coLinux (amongst a whole straft of other, considerably more legal applications) would allow you to do.
posted by gi_wrighty at 3:02 PM on April 13, 2004
It's too bad about the article; it sounds like a cool hack. I don't really understand how the system multiplexes hardware access, though, since you can really only have one driver talking to one device at a time. Does the colinux kernel just include a bunch of fake drivers for virtual devices which call through to Windows, VMWare-style, or do you have to divide the hardware up between the kernels?
posted by Mars Saxman at 4:20 PM on April 13, 2004
posted by Mars Saxman at 4:20 PM on April 13, 2004
Mars--
It's a custom Linux kernel that specifically avoids stomping on any piece of actual hardware. Mind you, it _can_ stomp on said hardware, but the kernel redirects itself not to.
posted by effugas at 1:15 AM on April 14, 2004
It's a custom Linux kernel that specifically avoids stomping on any piece of actual hardware. Mind you, it _can_ stomp on said hardware, but the kernel redirects itself not to.
posted by effugas at 1:15 AM on April 14, 2004
Right, I get that part; what I don't understand is what it does instead. The system needs to talk to hardware somehow, if only to mount a filesystem; in order to be useful, it would also want access to mouse, keyboard, monitor, and ethernet. I don't understand how the colinux kernel can run drivers for these devices without confusing the existing Windows drivers for the same devices.
posted by Mars Saxman at 9:17 AM on April 14, 2004
posted by Mars Saxman at 9:17 AM on April 14, 2004
If you think about it, the kernel only needs access to the filesystem and memory. If it then presents a virtual network interface then it doesn't need to worry about input / output devices. This is reason (I think) why you ssh or use cygwin xserver to use the kernel.
posted by gi_wrighty at 8:11 AM on April 15, 2004
posted by gi_wrighty at 8:11 AM on April 15, 2004
« Older Are We Safer Yet? | random LJ image of the moment. Newer »
This thread has been archived and is closed to new comments
posted by reklaw at 4:45 PM on April 12, 2004