If the current RAM heavy buyers, the AI powerhouses investors, don't get the into a profitable state of business, then sustaining this rhythm "for a long time" becomes impossible. It won't matter much that "fab allocation is booked years out" if the client that expects the goods goes out of business, doesn't it? I, for one, don't find convincing hints that this free AI crazy partying will go on for long, so then what gives?
> If the current RAM heavy buyers, the AI powerhouses investors, don't get the into a profitable state of business, then sustaining this rhythm "for a long time" becomes impossible.
Exactly that is the problem with the "pork cycle" we are seeing [1] - there aren't that many manufacturers and ODMs around nowadays for RAM, storage, CPUs and GPUs. The ecosystem was so much more vibrant even 10 years ago. When the AI bubble collapses, it will take the entire world's economy down the drain, and I think that quite a few of the brands we have now will be extinct after this iteration.
"Microsoft's GitHub is hosting the leaked source code (which probably got sucked into Copilot and every other AI under the sun as a result)." "However, I don't think copyright lawyers will care. «They're also committing a crime» doesn't mean you're free to do what you want. That applies especially in ReactOS vs MS, because if ReactOS succeeds, it will compete directly with Microsoft."
There's also such thing as being responsible (for an outcome), which in case of litigation means being culpable. Microsoft here is the sole actor that has any control on the GitHub Copilot, on what it was fed with, and thus - on its output (which would be the base of their accusation if they sue). How do you imagine such a case could be made to look like it would have any legal standing?
"In January 2006, concerns grew about contributors having access to leaked Windows source code and possibly using this leaked source code in their contributions. In response, Steven Edwards strengthened the project’s intellectual property policy and the project made the difficult decision to audit the existing source code and temporarily freeze contributions."
The allegations have been taken seriously and since then the procedure for accepting contributions include measures to prevent such further events from occurring. If you or anyone else happen to have any plausible suspicion, then please report it to the ReactOS team, otherwise keeping alive this kind of vague and uncertain connection between some Windows code leakage and ReactOS fits the very definition of FUD: https://en.wikipedia.org/wiki/Fear,_uncertainty,_and_doubt Please stop.
"if Microsoft attempts to sue (themselves?) over their own Copilot tool injecting their own copyrighted code into a user's codebase"
Such an attempt can't make sense, given that the model used by ReactOS is in Microsoft's control and thus Microsoft alone is the one responsible for the model's behavior. They won't sue, thus much is clear.
But, if any such model got fed with leaked code, then how is this a specific open-source project's problem and not of all projects (either open-source or private) that got to ever use that model?
Then, (having thought this just now) how can an argument relying on (legally) undisclosed information be used against anything public? Isn't the onus on the party having the undisclosed information to prove that it preceded the public one? How can that precedence be trusted by an independent judging party if the undisclosed information (source-code and systems managing that source code) is and always has been in the hands of the accusing (thus biased) party?
"it probably scrapped the multiple git repository of Windows leaked source code. In which case it would ABSOLUTELY undermine the project's ability to say it's a clean room implementation"
If an LLM model has been fed leaked code, then that is a general problem for that model and for its use for anything. Singling out its use for an open-source project and denouncing that as a potential problem while otherwise keeping quiet about it just makes no sense. Just take legal action against the model if there's anything plausible to warrant that, don't weaponize it against open-source projects.
All LLM have probably as they scrape github, and there are still to this day multiple Windows XP source code live on it (I won't give links but they are pretty easy to find). And I'd bet there is way more than just windows leaks on there...
"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.
Besides what you said, it is also in landlords' interest to maintain (but admittedly with as little cost/involvement as possible) the perception that the real estate goods they're renting are (quality wise) reasonable options for their prospective clients. That means that they (may go to lengths to) fend off troublesome tenants and thus contribute to the overall quality of life for the community in the neighborhood.
What often happens next is, another party comes up in the middle to manage the interaction between both of you (with the proper bump in the ask price), because there's not only so many decision makers looking for neat presentations and whatnot but also there's only so many teams willing to do the actual work.
reply