Comment by linguae
17 hours ago
I've been paying attention to this project periodically over the past few years. It would be nice to have a FOSS clone of macOS, similar to how FreeDOS, ReactOS, and Haiku are FOSS clones of MS-DOS, Windows, and BeOS, respectively.
The only thing is that this project has been quite slow going, which is similar to the histories of FreeDOS, ReactOS, and Haiku, where it took a long time for those projects to get to a usable state. It is a lot of work cloning an operating system, especially with an aim for binary compatibility. The Linux kernel benefited from the fact that there was an entire GNU ecosystem of tools that can run on Unix, and even in that case, the GNU ecosystem was seven years in the making in 1991 when the first version of the Linux kernel was released. It would've taken much longer for Linux to have been developed had GNU tools not existed.
Writing an entire operating system is long, hard work, even when provided the resources of companies like Microsoft, Apple, and Google. Hopefully projects like ravynOS and the similar HelloSystem (https://hellosystem.github.io/docs/) will lead to FOSS clones of macOS eventually, even if we need to wait another 5-10 years.
Sometimes it strikes me that something like this might be one of the better litmus tests for AI — if it’s really good enough to start 10x-ing engineers (let alone replacing them) it should be more common for more projects like this should begin to accelerate to practical usability.
If not, maybe the productivity dividends are mostly shallow.
The problem is that many of these clean room reimplementations require contributors to not have seen any of the proprietary source. You can't guarantee that with ai because who knows which training data was used
> You can't guarantee that with ai because who knows which training data was used
There are no guarantees in life, but with macOS you can know it is rather unlikely any AI was trained on (recent) Apple proprietary source code – because very little of it has been leaked to the general public – and if it hasn't leaked to the general public, the odds are low any mainstream AI would have been trained on it. Now, significant portions of macOS have been open-sourced – but presumably it is okay for you to use that under its open source license – and if not, you can just compare the AI-generated code to that open source code to evaluate similarity.
It is different for Windows, because there have been numerous public leaks of Windows source code, splattered all over GitHub and other places, and so odds are high a mainstream AI has ingested that code during training (even if only by accident).
But, even for Windows – there are tools you can use to compare two code bases for evidence of copying – so you can compare the AI-generated reimplementation of Windows to the leaked Windows source code, and reject it if it looks too similar. (Is it legal to use the leaked Windows source code in that way? Ask a lawyer–is someone violating your copyright if they use your code to do due diligence to ensure they're not violating your copyright? Could be "fair use" in jurisdictions which have such a concept–although again, ask a lawyer to be sure. And see A.V. ex rel. Vanderhye v. iParadigms, L.L.C., 562 F.3d 630 (4th Cir. 2009))
In fact, I'm pretty sure there are SaaS services you can subscribe to which will do this sort of thing for you, and hence they can run the legal risk of actually possessing leaked code for comparison purposes rather than you having to do it directly. But this is another expense which an open source project might not be able to sustain.
Even for Windows – the vast majority of the leaked Windows code is >20 years old now – so if you are implementing some brand new API, odds of accidentally reusing leaked Windows code is significantly reduced.
Other options: decompile the binary, and compare the decompiled source to the AI-generated source. Or compile the AI-generated source and compare it to the Windows binary (this works best if you can use the exact same compiler, version and options as Microsoft did, or as close to the same as is manageable.)
1 reply →
I’ve been thinking a long time about using AI to do binary decompilation for this exact purpose. Needless to say we’re short of a fundamental leap forward from doing that
Are those OSes actually that strict about contributors? That’s got to be impossible to verify and I’ve only seen clean room stuff when a competitor is straight up copying another competitor and doesn’t want to get sued
2 replies →
I had never thought of this until now. Is the clean-room approach officially done with? I guess we have to wait for a case to be ruled on.
There's also a cost problem here.
Who's paying $30 to run an AI agent to run a single experiment that has a 20% chance of success?
On large code-bases like this, where a lot of context gets pulled in, agents start to cost a lot very quickly, and open source projects like this are usually quite short on money.
> Who's paying $30 to run an AI agent to run a single experiment that has a 20% chance of success?
Someone who stands to make or save (significantly) more than 150$ if it's successful.
It doesn't have to be an unemployed contributer or student. Someone deploying it on a data center is the archetype you're looking for.
The organisational bottleneck still remains though. People need to discuss and coordinate at human speed.
I think AI will likely create more fragmentation initially, if a 10x developer is forced to run at 0.1x they're going to fork a project.
I believe in the AI 10x developer, but I suspect it only works for individuals or small teams at the moment.
In an actual business environment, you are right that its not a 10x gain, more like 1.5-2x. Most of my job as an engineer is gathering and understanding requirements, testing, managing expectations, making sure everyone is on the same page etc...it seems only 10-20% is writing actual code. If I do get AI to write some code, I still need to do all of these other things.
I have used it for my solo startups much more effectively, no humans to get in the way. I've used AI to replace things like designers and the like that I didn't have to hire (nor did I have the funds for that).
I can build mini AI agents with my engineering skills for simple non-engineering tasks that might otherwise need a human specialist.
This was my thought here as well. Getting one piece of software to match another piece of software is something that agentic AI tools are really good at. Like, the one area where they are truly better than humans.
I expect that with the right testing framework setup and accessible to Claude Code or Codex, you could iterate your way to full system compatibility in a mostly automated way.
If anyone on the team is interested in doing this, I’d love to speak to them.
I have the unpopular opinion that like I have witness in person the transition from Assembly into high level languages, eventually many tasks that we manually write programs for, will be done with programable agents of some sort.
In an AI driven OS, there will be less need for bare bones "classical" programming, other than the AI infrastructure.
Now is this possible today, not really as the misteps from Google, Apple and Microsoft are showing, however eventually we might be there with a different programming paradigm.
Having LLMs generate code is a transition step, just like we run to Compiler Explorer to validate how good the compiler optimizer happens to be.
Sure. In the meantime productivity is still useful.