"ReactOS should be seen as something more like GNU Hurd. An exercise in kernel development and reverse engineering, a project that clearly requires a high level of technical skill, but long past the window of opportunity for actual adoption."
I understand your angle, or rather the attempt of fitting them in the same picture, somehow. However, the differences between them far surpass the similarities. There was no meaningful user-base for Unix/Hurd so to speak of compared to NT kernel. There's no real basis to assert the "kernel development" argument for both, as one was indeed a research project whereas the other one is just clean room engineering march towards replicating an existing kernel. What ReactOS needs to succeed is to become more stable and complete (on the whole, not just the kernel). Once it will be able to do that, covering the later Windows capabilities will be just a nice-to-have thing. Considering all the criticism that current version of Windows receives, switching to a stable and functional ReactOS, at least for individual use, becomes a no-brainer. Comparatively, there's nothing similar that Hurd kernel can do to get to where Linux is now.
Hurd was not a research project initially. It was a project to develop an actual, usable kernel for the GNU system, and it was supposed to be a free, copyleft replacement for the Unix kernel. ReactOS was similarly a project to make a usable and useful NT-compatible kernel, also as a free and copyleft replacement.
The key difference is that Hurd was not beholden to a particular architecture, it was free to do most things its own way as long as POSIX compatibility was achieved. ReactOS is more rigid in that it aims for compatibility with the NT implementation, including bugs, quirks and all, instead of a standard.
Both are long irrelevant to their original goals. Hurd because Linux is the dominant free Unix-like kernel (with the BSD kernel a distant second), ReactOS because the kernel it targets became a retrocomputing thing before ReactOS could reach a beta stage. And in the case of ReactOS, the secondary "whole system" goal is also irrelevant now because dozens of modern Linux distributions provide a better desktop experience than Windows 2000. Hell, Haiku is a better desktop experience.
"And in the case of ReactOS, the secondary «whole system» goal is also irrelevant now because dozens of modern Linux distributions provide a better desktop experience than Windows 2000. Hell, Haiku is a better desktop experience."
Yet, there are still too many desktop users that, despite the wishful thinking or blaming, still haven't switched to neither Linux, nor Haiku. No mater how good Haiku or Linux distributions are, their incompatibility with the existing Windows simply disqualifies them as options for those desktop users. I bet we'll see people switching to ReactOS when it will get just stable enough, yet long before it will get as polished as either Haiku or any given quality Linux distribution.
No, people will never be switching to ReactOS. For some of the same reasons they don't switch to Linux, but stronger.
ReactOS aims to be a system that runs Windows software and looks like Windows. But, it runs software that's compatible with WinXP (because they target the 5.1 kernel) and it looks like Windows 2000 because that's the look they're trying to recreate. Plenty of modern software people want to run doesn't run on XP. Steam doesn't run on XP. A perfectly working ReactOS would already be incompatible with what current Windows users expect.
UI wise there is the same issue. Someone used to Windows 10 or 11 would find a transition to Windows 2000 more jarring than to say Linux Mint. ReactOS is no longer a "get the UI you know" proposition, it's now "get the UI of a system from twenty five years ago, if you even used it then".
"UI wise there is the same issue. Someone used to Windows 10 or 11 would find a transition to Windows 2000 more jarring than to say Linux Mint. ReactOS is no longer a «get the UI you know» proposition, it's now «get the UI of a system from twenty five years ago, if you even used it then»." "A perfectly working ReactOS would already be incompatible with what current Windows users expect."
That look and feel is the easy part. That can be addressed if it's really an issue. The hard part is the compatibility (that is given by many still missing parts) and stability (the still defective parts). The targeted kernel matters, of course, but that is not set in stone. In fact, there is Windows Vista+ functionality added and written about, here: https://reactos.org/blogs/investigating-wddm although doing it properly would mean rewriting the kernel, bumping it to NT version 6.0
I'm sure there will indeed be many users that will find various ReactOS aspects jarring for as long as there are still defects, lack of polish, or dysfunction on application and kernel (drivers) level. However, considering the vast pool of Windows desktop users, it's reasonable to expect ReactOS to cover the limited needs for enough users at some point, which should turn attention into testing, polish, and funding to address anything still lacking, which then should further feed the adoption and improvement loop.
"No, people will never be switching to ReactOS. For some of the same reasons they don't switch to Linux, but stronger."
To me, this makes sense maybe for corporate world. The reasons that made them stick with Windows has less to do with familiarity or with application compatibility (given the fact that a lot of corporate infrastructure is in web applications). Yes, there must be something else that governs corporate decisions, something to do with the way corporations function, and that will most likely prevent a switch to ReactOS just as it did to Linux based distributions. But, this is exactly why I intentionally specified "for individual use" when I said "switching to a stable and functional ReactOS, at least for individual use, becomes a no-brainer". For individual use, the reason that prevented people to switch to Linux is well known, and ReactOS's reason to be was aimed exactly at that.
> There was no meaningful user-base for Unix/Hurd so to speak of compared to NT kernel.
Sure, but that userbase also already has a way of using the NT kernel: Windows. The point is that both Hurd and ReactOS are trying to solve an interesting technical problem but lack any real reason to use rather than their alternatives that solve enough of the practical problems for most users.
I understand your angle, or rather the attempt of fitting them in the same picture, somehow. However, the differences between them far surpass the similarities. There was no meaningful user-base for Unix/Hurd so to speak of compared to NT kernel. There's no real basis to assert the "kernel development" argument for both, as one was indeed a research project whereas the other one is just clean room engineering march towards replicating an existing kernel. What ReactOS needs to succeed is to become more stable and complete (on the whole, not just the kernel). Once it will be able to do that, covering the later Windows capabilities will be just a nice-to-have thing. Considering all the criticism that current version of Windows receives, switching to a stable and functional ReactOS, at least for individual use, becomes a no-brainer. Comparatively, there's nothing similar that Hurd kernel can do to get to where Linux is now.