Despite being somewhat of a Unix/Linux junky, I really want ReactOS to be a thing. I would love to get older family members who refuse to upgrade from Windows Vista to something that is still being updated and will work on their older hardware.
That said, the last three times I've tried dogfooding ReactOS, I had trouble keeping it stable for more than 20 minutes, which is a complete non-starter for getting non-technical people using it.
It seems like the people working on the project are very smart and motivated, so I have to wonder why this is still a huge issue? I know almost nothing of OS/Kernel dev, so is it basically impossible to salvage all the stability work from the Linux kernel?
> is it basically impossible to salvage all the stability work from the Linux kernel?
Short answer: Yes.
Medium answer: That would be a near-complete rewrite of the project, since the ReactOS kernel and Linux have nothing in common. Different architectures, code styles, conventions, APIs, ABIs (which is super important for drivers). Probably the best option would be to port all of the ReactOS userland to run on WINE (which would actually be cool, and might be easy), and possibly write a Linux kernel module that provided a NT-compatible driver ABI (which would probably be hell to write, but if it's even possible then it would be a huge boon to Linux hardware compatibility... probably).
> APIs, ABIs (which is super important for drivers)
Yes, only userspace code would be reusable with a linux based kernel. Might as well start from scratch.
One more option that's being tried is to split the difference by integrating more of Wine's code. This approach is being testing in the Arwinss branch[1]
Well, I meant this in the "practice what you preach" sense. I actually nuked my laptop and went all-in with React for a couple days each time. "Using" is more vague and could just mean I tried running it in a VM for ten minutes.
But that's not dogfooding. If you were a ReactOS developer using ReactOS to compile future version of ReactOS, then you would be "eating your own dogfood", but simply using it as a daily driver doesn't count.
The main issue is developing device drivers is very complicated and difficult to get right. A sensible approach IMO would be to have ReactOS run virtualized on top of the Linux kernel. That way Users get all of the stability benefits of Linux, plus hardware support. The ReactOS team would then be able to concentrate on Windows compatibility, while only developing a few drivers for virtualization. The downside with this approach is a huge performance hit on computers without virtualization extensions. However I think the main use case of ReactOS is to provide a way to run old windows programs on modern hardware, so I don't think this would be a concern for most potential commercial users.
Running it in a VM under a Linux host is exactly how a lot of involved people have it, the reason being that that setup was more accessible, more stress-tested, and thus got more stable compared to a real-hardware setup. The goal however is to develop it to be compatible with current Windows NT drivers, which in some cases still happens to have received more love from their vendors compared to their Linux versions.
"is it basically impossible to salvage all the stability work from the Linux kernel?"
If you'll search through ReactOS codebase, you'll definitely encounter Linux pieces of code, thus it's safe to assume ReactOS doesn't suffer from NIH syndrome and that it salvages whatever it can from any given legit available source. Other than that, ReactOS has its own NT reference (which covers stability too) that it has to follow and that isn't any of the easy-available *nix architectures, so there's that.
I tried that yesterday because the ISOs were already up and unfortunately, unless Qemu is an unsupported platform, it's a mess.
First, I tried the LiveCD and found that the default qemu's network driver is unsupported. Found the docs, changed the driver and found that I have networking... but explorer.exe can't really visit any page, so all I could think of is to telnet somewhere. Then I tried to install some apps, but found that the "add or remove applications", while being a nice concept, unfortunately doesn't work on the live CD. So I switched to the main iso.
Two reboots later I tried to install Firefox... and found that it freezes the machine. A while later I found that this is the way ReactOS handles lack of RAM, so I added some. The scary part is that the freeze actually rendered the system unbootable after restart, which is super weird. Then I was wondering if I could install some old Visual Studio there and while trying to install .NET, first I found that 4.6 is "unsupported on this system" (which is fair, since it's fairly new) and the older .NET crashed the system again, this time because I ran out of disk space. So, if the system runs out of resources, its default response is to bluescreen.
At this point I just gave up. I'll probably come back to try it out at the next release, but for now... either I'm doing something wrong, or it's unusable.
I've been keeping an eye on this for over 10 years, I still hope for the day I can use it instead of installing a bloated Windows VM that takes up gigs of RAM just to be idle. But also licensing is the other drawback to Windows VMs constantly needing to relicense.
Really? I've been able to do this for pretty much every version I've ever downloaded, at least in a VM but also on my old K7. It's unstable but not that unstable.
+1. I couldn't manage to make it boot on vmware for the life of me the last time I tried a few months ago.
I think that is terrible. Many people would try it on virtual machines and see what happens, and those people could be potential developers in the future. But the way it's now...
I'm wondering what the community could do to make this less hands on and more out of the box friendly. I can install usually any Linux Distro without having to fuzz about too much with the settings, except with VirtualBox if I really want the extras installed, but it's still usually usable.
As others have noted, setting it up isn't so straight forward. There's even Wikis for installing it on a VM that don't seem as straight forward as just mounting an ISO[0]. Also, getting internet to work / websites to load seems problematic. I want a OS that is as usable as installing any Ubuntu derivative or Debian for that matter!
If your use case is VM-related, why not just use Wine? The only real advantage to ReactOS over Wine is its support for Windows kernel drivers, which only matters if you're running on native hardware.
On Virtualbox 5.2.12 with 3 gigs ram and 30 gigs virtual disk, FAT file system, the installer boots up ReactOS, but then on the reboot, it hangs on the ReactOS logo. :-/
Update: rebooted, pressed F12 and selected Debug.
Now it works...
rebooted in normal (default) boot, works now too. Except that the new hardware wizard fails installing any drivers for audio and ethernet.
Could install Virtualbox additions. Though weirdly, the mouse stopped working, so I had to use the keyboard for that.
5.2.12 was released in May 2018. That's hardly that old. None of the fixes since then sound like security fixes (all of the releases say 'maintenance release').
I eagerly await the day when I can run this for more than 10 minutes without anything going wrong. Tried out a recent build last week in vmware and... it didn't even boot.
That said, the last three times I've tried dogfooding ReactOS, I had trouble keeping it stable for more than 20 minutes, which is a complete non-starter for getting non-technical people using it.
It seems like the people working on the project are very smart and motivated, so I have to wonder why this is still a huge issue? I know almost nothing of OS/Kernel dev, so is it basically impossible to salvage all the stability work from the Linux kernel?