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.
New OS aims to provide (some) compatibility with macOS
61–70 of 170 posts
Re: New OS aims to provide (some) compatibility with macOS
#62Re: New OS aims to provide (some) compatibility with macOS
#63The 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
This has been degrading over the past decade, unfortunately.
Re: New OS aims to provide (some) compatibility with macOS
#64Earlier 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
Re: New OS aims to provide (some) compatibility with macOS
#65Re: New OS aims to provide (some) compatibility with macOS
#66Earlier 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?
Re: New OS aims to provide (some) compatibility with macOS
#67Earlier 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
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
#68Re: New OS aims to provide (some) compatibility with macOS
#69Earlier 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
Re: New OS aims to provide (some) compatibility with macOS
#70Earlier 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