> A BSD-based OS project that aims to provide source and binary compatibility with macOS® and a similar user experience.
I am curious - what is the motivation for this project?
Is it to replicate macOS? - If yes, why?
Is it to provide application compatibility on a non-macOS? If yes, why a full OS? Why not take the route like Wine or other such layers that make compatibility possible? Also, is there such a need for running macOS apps on a non-macOS? Who is the target audience?
Would the energy be better spent in making Linux more stable or usable for the general public?
Can it run stock macOS programs like Photos? I want a non-chaotic way to import my old fart's iPhone galleries without a Mac Mini (HEIC and Lives are annoying), and docker-osx/vm's don't work for everyone.
This is so cool, the little mini screenshots look gorgeous because it replicates MacOS. I’m not sure if a lot of people feel the same but over the years I always thought it was a shame that Linux’ overall UX and aesthetics seemed a little bit more rushed and “crowd sourced” (in the sense that it felt diverse in terms of ui opinions and taste etc). It almost makes me want to try Linux again just for that look and feel (because I love my Mac’s but would like something different and more free)
> the little mini screenshots look gorgeous because it replicates MacOS.
I have the opposite reaction. To me the screenshots look like someone tried to replicate macOS but failed. The text antialiasing is off, the font is different (and worse), the border-radii on menus are off, etc.
To me, it looks a lot like Uncanny Valley macOS. Yes, it's macOS, but something's just not right. Maybe the fonts don't look right, or the spacing of the icons on the dock?
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.
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.
It doesn't seem to be their focus, but this could be amazing for macOS build machines, and servers. There have been a number of changes in recent years focussed on improving the security of macOS when used as a Desktop OS. These work well for their intended purpose, but they have made macOS harder and harder to deploy headlessly, and use as a server.
I hope to see this become an open source OS that runs the full xcode command line suite, deploys easily to headless machines, and inherits FreeBSD's server hardware compatibility.
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.
One interesting cheat code is to start by only running inside KVM. Virtio for everything, no real hardware drivers. The host Linux can become a thinner and thinner shell over time.
Because many open an UNIX book, and rather copy what was already done.
Note that Smalltalk, Interlisp-D, Mesa, Cedar, safe systems programming are also 60/70's tech, but these ones hardly anyone bothers to copy in such attempts.
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 loader - it brings nothing to the table. Just use ELF binaries. Although at that point there's nothing macOS about it - it's just a Mac-like UI facade for FreeBSD distro with a different API. If Ravyn doesn't want to be to macOS like WINE is to Windows, I don't see the point.
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.
Wouldn't it be more natural if this project made use of XNU/Darwin... But with the way things are going, with XNU going more and more proprietary, I suppose FreeBSD is "close enough". In any case, there's nothing we can do about it but these "macOS" alternatives are too fragmented. I would love to see "The" macOS clone.
If you don't provide CoreFoo (for Foo in *), there's not really much point in talking about compatibility with macOS. I see no sign that they provide any of the possible CoreFoo libraries/frameworks.
Apple releases part of the source code of XNU, it would make much more sense to me, to re-create something like the original Darwin CD out of this for x86-64.
There are a number of MacOS CLI tools and drivers for x86_64.
It may be a motivation to continue work.
Even commercially it could be something interesting.
Wine works because Microsoft spends billions on backwards compatibility and APIs are stable over time.
Apple regularly deprecates frameworks and adds new ones at rapid rates. It's a moving target with the added complication of moving build targets.
If you implement your own version of Apple's XyzKit, that might only be used in macOS 12 to 14, and not before or after that, so you put in a lot of work to essentially support binaries that were released between X date and Y date and that's it. And you have to do that for a sliding window of dates, macOS versions and framework releases and deprecations.
Perhaps I need to understand something first, but at this point in time I see no value in projects like this. Beyond the obvious fact of hacking. Ideally, I don’t even want, say, Linux to have any binary compatibility with Windows. I want native apps, games included. I don’t want to see Photoshop working on Linux, I want Gimp to become successful (maybe, start with the name change), or, well, Krita then. Same with macOS. I don’t miss any app from macOS, I want to run so badly. I want Linux to catch up where it isn’t.
I guess one thing macOS users like is the default UI. So
this is probably an area where Linux lacks - both GNOME
and KDE have shortcomings when compared to that UI. (They
are mostly fine if one does not have that as a use case,
though I find GNOME to really want to simplify everything
to the point of having almost no features left.)
34 comments
[ 13.3 ms ] story [ 53.6 ms ] threadI am curious - what is the motivation for this project?
Is it to replicate macOS? - If yes, why?
Is it to provide application compatibility on a non-macOS? If yes, why a full OS? Why not take the route like Wine or other such layers that make compatibility possible? Also, is there such a need for running macOS apps on a non-macOS? Who is the target audience?
Would the energy be better spent in making Linux more stable or usable for the general public?
If its just a hobby, sure, that is well & good.
I have the opposite reaction. To me the screenshots look like someone tried to replicate macOS but failed. The text antialiasing is off, the font is different (and worse), the border-radii on menus are off, etc.
Besides, the actual screenshots of the current OS (https://ravynos.com/screenshots) are... really rough.
https://imgur.com/a/svQaeCa
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.
I hope to see this become an open source OS that runs the full xcode command line suite, deploys easily to headless machines, and inherits FreeBSD's server hardware compatibility.
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.
Note that Smalltalk, Interlisp-D, Mesa, Cedar, safe systems programming are also 60/70's tech, but these ones hardly anyone bothers to copy in such attempts.
But if macOS binary compatibility is not the goal, then there's no need for a Mach-O loader - it brings nothing to the table. Just use ELF binaries. Although at that point there's nothing macOS about it - it's just a Mac-like UI facade for FreeBSD distro with a different API. If Ravyn doesn't want to be to macOS like WINE is to Windows, I don't see the point.
Wouldn't it be more natural if this project made use of XNU/Darwin... But with the way things are going, with XNU going more and more proprietary, I suppose FreeBSD is "close enough". In any case, there's nothing we can do about it but these "macOS" alternatives are too fragmented. I would love to see "The" macOS clone.
Keeping it x86_64 for now makes sense in many respects.
But it could become a real uKernel OS in the long run.
ravynOS is moving to Darwin.
There are a number of MacOS CLI tools and drivers for x86_64.
It may be a motivation to continue work.
Even commercially it could be something interesting.
I am not sure if it is easier though.
PureDarwin seems to do very slow progress.
This considering the last macOS version before Swift was announced as goal.
Apple regularly deprecates frameworks and adds new ones at rapid rates. It's a moving target with the added complication of moving build targets.
If you implement your own version of Apple's XyzKit, that might only be used in macOS 12 to 14, and not before or after that, so you put in a lot of work to essentially support binaries that were released between X date and Y date and that's it. And you have to do that for a sliding window of dates, macOS versions and framework releases and deprecations.
What would be required to achieve this?
I guess one thing macOS users like is the default UI. So this is probably an area where Linux lacks - both GNOME and KDE have shortcomings when compared to that UI. (They are mostly fine if one does not have that as a use case, though I find GNOME to really want to simplify everything to the point of having almost no features left.)