ReactOS Forum

I was browsing the net and came upon the Linux Unified Kernel(LUK). Here's the project's website http://www.longene.org/en/index.php and it's wikipage http://en.wikipedia.org/wiki/Linux_Unified_Kernel.
In a nutshell they're making an operating system kernel intended to be binary-compatible with application software and device drivers made both for Microsoft Windows and Linux, by porting key features of the Windows kernel to the Linux kernel.

As far as I can see LUK has some noticeable advantages over ReactOS:

1) LUK makes a tremendous shortcut by using a complete and already stable operating system as it's starting point.
ReactOS is still developing an alpha stage operating system and will continue do so for an undetermined period of time.

2) LUK takes advantage of already existing Linux drivers for it's initial install, after which Windows drivers could be downloaded and installed.
ReactOS has limited hardware support, numerous open source drivers will have to be written from scratch in order to get the system through it's initial install since it can't be shipped with Windows drivers, which are proprietary.

3) LUK supports Linux apps and is developing support for Windows ones.
ReactOS is developing support only for Windows apps and as a result is currently unable to run as many programs as LUK(and even Linux+Wine for that matter!) and will continue do so for an undetermined period of time.

What do you think?

I think it's been discussed a tremendous amount on ROS' own forums quite a bit already.

Try the search box.

FlyingIsFun1217

First, i fail to observe your point. Is there any suggestion hidden in your post?
Second, last time i heard from LUK guys, there were asking US how to implement WDM support in their kernel.
Third, from what some of our devs got from looking into their code, they are just rewriting ReactOS code, linuxify it and squeeze into Linux kernel with a sledgehammer. Good luck, anyway.

The reason ReactOS is being developed is because not everyone believes that Linux is the best operating system out there. As much as architects of buildings disagree on the style of building a house or a tower, operating system developers disagree on how an operating system should be built. Some people believe Linux is perfectly fine, whereas others believe that Windows NT is a more viable platform. People in the latter category are what make up the ReactOS team.

LUK's support for Windows applications will never be greater than ReactOS's or Wine's because they use the code from these projects to build LUK. To the best of my knowledge, they take code from other projects more than they write their own. Wine is a pretty successful project, and ReactOS actually shares code with Wine, but Wine is restricted because it doesn't target drivers. LUK (or rather the projects that LUK feeds off of) attempts to address this by supporting Windows drivers, but even still it's just not Windows.

It's not entirely true that Windows can't run Linux apps. There are projects such as Cygwin that provide Unix compatibility for Windows, and there are also programs such as Cooperative Linux. KDE can also be run on Windows. ReactOS will be able to run this software as well as it matures. Not to mention that most Linux software is open-source and usually finds itself ported to Windows sooner or later anyway, so Windows running Linux apps isn't as big a problem as Linux running Windows apps.

There's also no need to write open-source drivers for ReactOS, whereas Linux driver support is still lacking, since some hardware manufacturers still don't support Linux. ReactOS will be able to utilize Windows drivers regardless of whether they are open-source or closed source. The lack of Linux drivers and the abundance of Windows ones is one of the reasons ReactOS was started in the first place. People installing ReactOS onto existing hardware will simply use the drivers that came with their software or download them from the Internet. If hardware manufacturers do actually start packaging ReactOS with their systems, then they can simply package the hardware drivers with their custom ReactOS installation discs, just as Gateway, Dell, and others do with the customized copies of Windows they already ship with their hardware. I have a Windows XP disc from my old Gateway and it doesn't even use the default Windows installer.

@FlyingIsFun1217:
Thank you for pointing me in the right direction. From previous posts I've come to know that ReactOS developers truly dislike the Linux architecture so my initial post is pretty much useless.

@Haos:
Speed(of development) was my point.
Ever since I've heard of ReactOS, I've been concerned with the following scenario: ROS manages to reimplement X or Y or Z version of the Windows OS/kernel, but then Microsoft releases a new version and moves all it's users to that. ROS now has to reimplement the new version or else risk to fall behind just like Windows 2000 fell behind XP(as software manufacturers support 2000 less and less) and soon enough XP will fall behind Vista and 7.
In this scenario ReactOS seemed to me as always two steps behind, while LUK seemed to jump three steps ahead(already offering users: stability, drivers and apps through it's Linux core, while implementing what ROS is doing, into the Linux kernel).
Maybe I'm wrong, maybe when the ROS kernel is ready, development will be lightning fast! But right now(and users like to have solutions right now) the LUK idea has better hardware support, runs more apps and is more stable than ROS and will be so for an undetermined period of time.

@RaptorEmperor:
I don't believe I ever said Windows can't run Linux apps.
I'm not comparing the number of Linux drivers to the number of Windows ones... I'm saying excepting OEM ReactOS installs where the manufacturer packages in Windows drivers, retail ROS installs would need new open source drivers written from scratch to boot and do an initial install because ROS can't be shipped with the plethora of proprietary Windows motherboard drivers, whilst LUK/Linux already has a lot(I'm not saying all) of these lying around...

@RaptorEmperor
Add to the motherboard drivers, the fact that ROS can't be shipped with the plethora of proprietary Windows network-card drivers either...

Hi,

WDM was working in old Reactos ntoskrnl.
For example it was possible to use the NTFS.sys from Microsoft Windows XP with Reactos 0.26.
http://www.jankratochvil.net/project/captive/Preview.pm
Last time I tried with Reactos (current 0.3.10) it failed and I think this situation exists since Reactos 0.30 (2006)

On the contrary it's quite easy to tweak a 0.2.6 kernel to list a root Windows XP NTFS directory.

Freeguy wrote:@RaptorEmperor
Add to the motherboard drivers, the fact that ROS can't be shipped with the plethora of proprietary Windows network-card drivers either...

Unless you fork the project and make your own distribution, which of course, you are free to do.

Maybe I am wrong, but is this whole driver topic not maybe a bit "over-valued"? - I mean, as opposed to Linux, the drivers ALREADY EXIST. They are just not open-source... but then again, do they have to be? - Like, fine, the drivers are not open source, so what? - If they can be somehow supplied, maybe simply through asking the respective companies whether they may be included on the installation media one day, that will solve the problem from the user perspective well enough.

JPLR wrote:Hi,

WDM was working in old Reactos ntoskrnl.
For example it was possible to use the NTFS.sys from Microsoft Windows XP with Reactos 0.26.
http://www.jankratochvil.net/project/captive/Preview.pm
Last time I tried with Reactos (current 0.3.10) it failed and I think this situation exists since Reactos 0.30 (2006)

On the contrary it's quite easy to tweak a 0.2.6 kernel to list a root Windows XP NTFS directory.

Er what??? Windows' NTFS driver never ever did work in ROS till now. After months of hidden development, arty is close to get this done now, but not yet.

Please mind that LUK at the moment ATTEMPTS to implement what is being done on ROS, it doesnt actually deliver it. I havent seen LUK kernel doing anythin NT-alike.

EmuandCo wrote:Er what??? Windows' NTFS driver never ever did work in ROS till now. After months of hidden development, arty is close to get this done now, but not yet.

I think he refers to his "proof of concept."

There is nothing stopping us legally from arranging some deal with hardware manufacturers and getting permission to distribute binary drivers. We choose not to dump a couple gigs of drivers onto the ROS download because we trust that the people that actually go and install ROS on their systems are competent enough to find the Windows drivers on the manufacturer website. If they aren't, then why are they mucking around with installing operating systems anyway?

There is nothing stopping us legally from arranging some deal with hardware manufacturers and getting permission to distribute binary drivers.

are you completely sure? the gpl is confusing on finer points like this, but (if you're using any gpl code from outside the project,) i wonder if that doesn't prevent you from bundling ros with non-free drivers. it's all about whether the non-free software "hooks" the free software, iirc.

if you write the whole kernel yourself, or get permission from all the authors of all the code you use, it should still be possible. since you're not bundling it with proprietary drivers, it's a non-issue. but i wonder if the oem's would be able to bundle it with non-free drivers. i'm sure it will be 5 years before most oems would consider doing such a thing, when microsoft will surely block oems from selling ros machines the same way they recently blocked most netbooks formerly being offered with gnu/linux.

then again in 5 years maybe enough people will know how to install ros themselves... just like when microsoft windows was something you installed. ...or perhaps there will be more free drivers for windows devices (written by former members of the ros team?) at which point ros will still be binary compatible with non-free drivers, though no one will ship them with ros.

I dont see much of a chance for opesource NT drivers, as its a tedious and time consuming process to write and polish one, not even speaking of know-how required. As someone neatly noticed, ReactOS contains almost all opensource NT drivers available.