Linked by Thom Holwerda on Thu 28th May 2009 12:08 UTC, submitted by lemur2
Thread beginning with comment 365789
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
That has already been done with coLinux and there are there are several distributions that support coLinux.
LUK would be a sort-of "inverse coLinux", wherein Linux was the core OS and the NT kernel extensions were the tacked-on bits.
The major, major difference in these approaches would be that LUK would still give you an open source kernel, whereas coLinux only gives you the Linux add-ons as open source.
That has major implications from a licensing perspective. You would no longer require a Windows license to be able to run applications designed for Windows. You wouldn't have to put up with WGA. There wouldn't have to be a "Windows Update" backdoor. Updates to LUK itself could be delivered via Linux distribution repositories.
Finally, software vendors who wanted to easily extend their customer base could prepare additional (binary only if they wanted) repositories for their applications (without having to re-write anything), so that all applications on LUK machines could still auto-update via the one updater.
Edited 2009-05-28 23:34 UTC






Member since:
2006-08-18
That has already been done with coLinux and there are there are several distributions that support coLinux.