New OS aims to provide (some) compatibility with macOS

I would much rather emulate linux apps on a more stable and consistent OS than vice versa. The sheer number of toolkits and window managers leaves my head spinning, and unifying their behavior even before you can begin to improve it feels like a nightmare.

I personally don't care much about the dock or the look and feel or whatever; I just want access to the usability of macos without having to accept how closed it is.

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 messaging into the kernel, where it is much more performant.

They chose the FreeBSD kernel over Darwin for the sake of hardware compatibility (though of course NeXT Mach is one of the most widely-ported kernels of all time...)

There is also overlap with GNUstep, helloSystem, and other projects in the broader "open-source Mac/NeXT" space, though ravynOS (obviously) prefers BSD/MIT/Apache-style licensing over GNU-style licensing. Nevertheless, ravynOS currently uses the GNUstep libobjc2 runtime, a bit like how most of the Unix world used to depend on gcc.

I'm not affiliated with ravynOS, but I've been periodically following the project for a few years.

The main page (https://ravynos.com/) expresses the philosophy of ravynOS:

"We love macOS, but we’re not a fan of the ever-closing hardware and ecosystem. So, we are creating ravynOS — an OS aimed to provide the finesse of macOS with the freedom of FreeBSD."

rayvnOS seems to be designed for people who love macOS, particularly its interface, its UI guidelines, and its ecosystem of applications, but who do not like the direction that Apple has moved toward under Tim Cook (soldered RAM, limited and inflexible hardware choices, notarization, iOS-influenced interface changes, increased pushiness with advertising Apple's subscription services, etc.) and who would be unhappy with either Windows or the Linux desktop.

Speaking for myself, I used to daily-drive Macs from 2006 through 2021, but I now daily-drive PCs running Windows due primarily to the lack of upgradable RAM in ARM Macs. I'm not a big fan of Windows, but I need some proprietary software packages such as Microsoft Office. This makes switching to desktop Linux difficult.

It would be awesome using what is essentially a community-driven clone of macOS, where I could continue using a Mac-like operating system without needing to worry about Apple's future directions.

On the Unix side of things, I believe the decision to base ravynOS on FreeBSD rather than on Linux may make migrating from macOS to ravynOS easier, since macOS is based on a hybrid Mach/BSD kernel, and since many of the command-line tools that ship with macOS are from the BSDs. This is known as Darwin. It's not that a Mac clone can't be built on top of Linux, but FreeBSD is closer to Darwin than Linux is.

I have the same sentiment. I am forced to use a MacBook in my new job while waiting for them to procure a laptop that I can put Linux on. I can say that Linux with KDE Plasma desktop is in almost every way superior to Mac OS. Much better UX, configurability and core applications. And even little things are more polished and thought through compared to what a trillion dollar company was able to produce. It's really beyond me how people use Apple products, and it's the absolute majority of them in my field.

Mac OS without the background ads garbage or the constant blocking of call-home requests would be nice.

It would be great if it runs on mac too. macOS doesn't have much compatibility with itself.

> Would the energy be better spent in making Linux more stable or usable for the general public?

Linux is stable and widely used, whether as Android, Ubuntu, WSL on Windows or Crostini on ChromeOS (itself Linux under the hood).

The general public buy products like Macs, Lenovos, Steam Decks, Chromebooks or Frameworks. Nobody buys a "Linux".

Linux and it's ecosystem are features of those products, not products themselves.

> Also, is there such a need for running macOS apps on a non-macOS?

Arguably there's a need for running macOS apps on macOS even. E.g. my parents are stuck having an old Intel Mac Pro around on an old OS for a few 32-bit programs (not sure if it changed, but IIRC you couldn't run an OS that supported them as a VM on Apple Silicon). Pretty soon Rosetta 2 will go away as well.

They say source-compatible, not binary-compatible.

GNUstep failed to get traction, I doubt they can do much better.

It's a totally different path but you could try Immich to do that.

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.

Test successful?

The Mac UI only got worse after that.

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

My dream is to work on an operating system that at least gets us to the 1990s and 2000s when it comes to research ideas.

I have a soft spot for the Smalltalk-80 environment and Lisp machines. They had a single address space. In my opinion, the two most interesting things about these environments are (1) their facilitation for component-based software based on live, dynamic objects, and (2) the malleability of the system, where every aspect of the system can be modified by the user in real time.

Of course, a critical downside of Smalltalk-80 and Lisp machine environments is the lack of security; any piece of code can modify the system. There are two solutions to this that I'm thinking about: (1) capability-based security for objects in the system, and (2) work on single-address space operating systems that still have memory protection (Opal was a research system that had this design; see Sharing and Protection in a Single-Address-Space Operating System [Chase et al. 1994]).

One of the nice things about Lisp is its metaprogramming facilities, from macros to the metaobject protocol. Metaprogramming makes it feasible to implement domain-specific languages that make expressing problems more aligned to their domains.

During the late 2000s and early 2010s, Alan Kay's Viewpoints Research Institute had a project named STEPS that investigated the pervasive use of DSLs to implement an entire desktop environment. They did not use Lisp as a substrate, but they did use OMeta (https://tinlizzie.org/ometa/) for handling parsing expression grammars (PEGs), which are used to describe many of the systems in STEPS. Two DSLs that immediately come to mind are one for describing the 2D graphics system and another for describing TCP.

So now I've described my dream substrate: a single-address operating system with capability-based security, where each subsystem is expressed as a live object, ideally coded in a DSL.

Now comes the interface. The programmer's interface would be similar to Smalltalk-80 and Lisp machines, with a live REPL for interactive coding. All objects can be accessed programmatically by sending messages to them. The end-user interface would be heavily based on the classic Mac OS, and applications would conform to human interface guidelines similar to System 7.5, but with some updates to reflect usage patterns and lessons in UI/UX that weren't known at the time. Application software would be similar to the OpenDoc vision, where components can be combined based on the user's wishes.

The end result sounds like a synthesis of various Apple projects from the late 1980s until 1996: component-based applications backed by a live object system with capability-based security.

This is my dream and is a side project I'd love to create.

I would argue that iPadOS (built on iPhone's coat tails) moved the field forward significantly in terms of isolation and user security.

While this has left a long tail of inconveniences, many resolved and some not, I am very confident that using 1 app on my iPhone/iPad will not leak data to another in any case that I am likely to care about as a non-significantly interesting person (political figure, etc).

... and for those people Apple even makes lockdown mode to move the bar, while acknowledging it adds extra inconvenience: https://support.apple.com/en-au/105120

I have no such confidence about macOS, Linux or Windows, in fact the reverse. macOS has done the best at trying to bolt on some sandboxing (and linux has it too) but that's still very holey and not all-in like iOS/iPadOS has ended up.

Yes, I know there have been many bugs and leaks in iOS but the security level is far and above the desktops currently, and designed that way from the ground up. So when they finally make something work like copy and paste or sharing between apps, etc... it's by and large done very well.

It's been very difficult to add that kind of thing to Linux because you're trying to do the reverse and lock things down and it breaks everything... making it very challenging.. as opposed to Apple where basically nothing useful worked at the start (no copy/paste, one app at a time, no meaningful filesystem, etc).. but managed to get the product successful in the limited state and has slowly unlocked that stuff over time. Admittedly very slowly.

I cannot speak for Android as I just have never used it or surrounded myself in info about it's design, security, etc.. it may well be very similar although they from my casual observation seemed to do a much worse job at granular privacy permissions (e.g. for the longest time permissions were all granted at install time, and so many apps want so many most people are blind to it.. as opposed to Apple's model where even if notarised for something on the app store in most cases you have to agree to it when the app first uses it.. I know they fixed that a while back but I have no idea how well things have transitioned to that now). As a very techy person deeply knowledge in many things, and using desktop Linux since 2002, it's kindof a hilarious personal failing that I have never used Android.. I really should try and resolve that at some point.

Because writing even a remotely modern OS is really really hard. I speak from experience. Even getting old hardware from the 90s and early 00s to work is a pain. Then of course you have the more modern standards (although even SATA is still modern for some definition of modern, but AHCI is a nightmare), and then you have things like modern NICs and GPUs which has documentation that is very hard to find, or in the case of even modern Intel GPUs, documentation that is 13 plus volumes and is absolutely massive... And the list just goes on and on and on. Before you know it your codebase is 100k LoC and like 80-90 percent of it is device drivers alone. And if you thought all that was bad, wait until you get into ACPI...

Yeah. OS dev is, I think it's safe to say, the hardest and most difficult project a software engineer could do, right alongside a modern compiler if you ditched LLVM and decided to make your own backend.

It takes an astronomical amount of work to not only write an OS but handle 30 years worth of both hardware, and lessons learned.

People do write new OSes from scratch all the time, you can see the result of no popularity/usage because they can't do much for even enthusiasts.

Not to mention, if you want users, you need apps, and that involves trying to run what already exists or making it as easy as possible to port. All of that shapes the OS.

Microsoft came close with Midori but bailed out and canned the product just before it should have been released in alfa / beta 1

> Midori is an experimental managed code operating system that was in development until 2015. A joint effort by Microsoft and Microsoft Research, it had been reported to be a possible commercial implementation of the OS Singularity, a research project begun in 2003 to build a highly dependable OS whose kernel, device drivers, and application software would all be written in managed code. It was designed for concurrency, and would run a program spread across multiple nodes at once.[1]

[1] https://en.wikipedia.org/wiki/Midori_(operating_system)

https://joeduffyblog.com/2015/11/03/blogging-about-midori/

How about the immutable OSes like Fedora Silverblue

> 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.

Frankly I was a bit surprised that was not what they were doing. As a user I’d prefer a “mere” macOS UI on top of FreeBSD, so long as its quality is of the same. Use Darling as a compatibility loader, like WINE/Proton in SteamOS.

I think the idea is take what you can and evolve.

Keeping it x86_64 for now makes sense in many respects.

But it could become a real uKernel OS in the long run.

I think it's in the frameworks folder, e.g., https://github.com/ravynsoft/ravynos/tree/main/Frameworks/Ap...

Edit: also CoreServices https://github.com/ravynsoft/ravynos/tree/main/CoreServices/...

Well, there is actually a lot of ObjC.