Live data from Hacker News

New OS aims to provide (some) compatibility with macOS

github.com

61–70 of 170 posts

Re: New OS aims to provide (some) compatibility with macOS

#61

The RavynOS project would have a good chance at being binary compatible with Mac OSX if it copied all the Darwin libraries from the Darling project and used LLVM to generate all the appropriate dylibs. That's something I would support and contribute to. It could get to the point where it could run macOS console based applications. But if macOS binary compatibility is not the goal, then there's no need for a Mach-O lo…

> copied all the Darwin libraries from the Darling project and used LLVM to generate all the appropriate dylibs I'm just starting for the day and misread that as "...used LLM to generate...", and I wondered what kind of crack you were smoking.

In future, your OS will be an agentic LLM which runs software by YOLOing the binaries, and then continuously fixing and refining the environment until it runs without crashing.

Re: New OS aims to provide (some) compatibility with macOS

#63

The website looks sleek, I get the impression that the ui for the os will be the same. But then when I look at the screenshots, it look like macOS stuck in 2008.

Who cares about sleekness? Linux has looked sleek for decades but still behaves like ass

“Looks sleek” was only ever a surface level reason why macOS was a good UI. Far more important was that it was highly opinionated, and those opinions were very consistently applied, resulting in a highly predictable interface.

This has been degrading over the past decade, unfortunately.

Re: New OS aims to provide (some) compatibility with macOS

#64

Earlier quoted context omitted.

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

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

Re: New OS aims to provide (some) compatibility with macOS

#66
post #49

Earlier quoted context omitted.

There are objective criteria that macOS definitely fails at. Various government agencies here in the states can't use macs even if they wanted to due to lack of #a11y support or the ability to load their own root cert stores. I agree with you that for MOST people, MOST of the complaints boil down to "I just don't like the Mac UX," but there are organizations that cannot tolerate the risk of forcing employees to use e…

You can import new roots via Keychain, correct?

Yes.

Re: New OS aims to provide (some) compatibility with macOS

#67

Earlier quoted context omitted.

A lot of these questions are answered here: https://ravynos.com/faq To summarize... There is a WINE-analogous project, called Darling: https://www.darlinghq.org/ The goal for ravynOS is to be analogous to ReactOS. Much like ReactOS and WINE, ravynOS and Darling share a lot of Cocoa code. For the problem of OpenStep implementations specifically, a bespoke software stack has the benefit of being able to put Mach messag…

> of course NeXT Mach is one of the most widely-ported kernels of all time... actually the broader Mach kernel, not specifically the NeXT variant, is the one with a documented history of extensive portability

The NeXT variant did run on the following architectures:

1. Motorola 68k (the original NeXT hardware had 68030 and 68040 chips)

2. Intel x86 (NeXTSTEP 3.1 for Intel was released in 1993)

3. HP PA-RISC (I have an OPENSTEP 4.2 CD that can run on Motorola 68k, x86, PA-RISC, and SPARC hardware)

4. Sun SPARC

5. 32-bit PowerPC (Rhapsody, the original Mac OS X 1.0 that was essentially still Rhapsody, and of course Mac OS X from Cheetah through Leopard)

6. 64-bit PowerPC (Power Mac G5 and iMac G5)

7. Intel x86-64 (starting from Mac OS X Tiger all the way to macOS Tahoe)

8. 32-bit ARM (iOS on early iPhones with 32-bit ARM chips)

9. 64-bit ARM

I could be forgetting other platforms, but these are the ones I know from the top of my head.

Re: New OS aims to provide (some) compatibility with macOS

#68
post #19

The website looks sleek, I get the impression that the ui for the os will be the same. But then when I look at the screenshots, it look like macOS stuck in 2008.

The Mac UI only got worse after that.

Nah. Mavericks was peak.

Re: New OS aims to provide (some) compatibility with macOS

#69
post #64

Earlier quoted context omitted.

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

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

ReactOS froze development to audit their code.[1] Circumstantial evidence was enough to call code not clean. WINE are strict as well. It is impossible to verify beyond all doubt of course.

[1] https://reactos.org/wiki/Audit

Re: New OS aims to provide (some) compatibility with macOS

#70

Earlier quoted context omitted.

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

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.
Post reply on HN