FAQ

No - not yet. This is a major goal and we're working towards it. So far, some trivial "Hello World" binaries in C and Objective-C have been compiled on macOS Big Sur and the resulting Mach-O binaries ran on ravynOS using our in-dev Hybrid linker without any Frameworks or tools from macOS. Source code of some simple Cocoa AppKit-based applications have been built on ravynOS and run as native applications (e.g. Install ravynOS.app). While this is all very exciting, you will have to wait a bit longer to run Photoshop or Xcode.

In theory, it will be easier to build Mac code on FreeBSD because it is closer to macOS than Linux is. Using the BSD kernel also eliminates the need to emulate BSD system calls like Darling (on Linux) does, and made it easier to patch in Mach 3.0 support.

Also, why not? Devils need love too!

The short answer is "hardware support". ravynOS should run on most commodity x86_64 hardware using FreeBSD's very stable and performant drivers.

The longer answer is that plus I don't see any real advantage to using XNU. We have merged in Mach support now (big thanks to NetBSD, NextBSD and the iX Systems folks for that) so the xnu approach just seems to add complexity and the effort of writing and maintaining drivers.

Considering how big this project is already, I opted to stick with the BSD kernel - at least for now.

No. Consider projects like ReactOS, a from-scratch effort to create an OS compatible with Microsoft Windows, GNUstep, which provides an open implementation of Cocoa APIs and other things, or Darling, a compatibility layer for running Darwin (macOS) binaries on Linux. ravynOS is similar and stands on the shoulders of many such projects.

All code used is freely available under open source licenses. No proprietary elements like fonts, icons, trademarks, etc can be used. Original code must be written using "clean room" techniques - that is, from public documentation like developer guides by people who have never seen the proprietary code - and released under the FreeBSD license or the MIT license.

The goal is to use a small core set of languages as much as possible: the "C" family (C, C++, Objective-C, and Objective-C++), Swift, Python, Java, and shell scripts. This should cover most needs.

Great! Take a look at the issues list to find something that interests you, or contact mszoek.

Absolutely! There will be art, documentation, testing, UX and UI work, release management, project management, legal advice, hosting, and many other ways to contribute. This project is huge and help is very welcome. Check out the issues for ideas on how to contribute, or contact mszoek.

You sure can! I've signed up for GitHub Sponsors to make monthly sponsorship easy. You can also make a contribution via PayPal.

This one has been asked a lot so:

• helloSystem: We have been in fact working with helloSystem! As some people have noticed, Release 0.2.X was basically helloSystem. (That was the second PoC. The first had been built on vanilla FreeBSD and had no GUI at all.) Under the hood, however, release 0.2.2 has a partial implementation of Cocoa, a modified compiler & linker that support frameworks, and several other additions that make it distinct. We have similar philosophies, and share technology and cooperate where it makes sense (e.g. Filer), but the project goals are quite different.

  helloSystem wants to create a computer that is simple to use, open, elegant, small and fast. Older MacOS X and Classic are an inspiration to what that might look like, but they are not explicitly trying to create an open-source Mac. In fact they're mostly avoiding Objective C and XML plists and other Mac technology in favor of simpler and/or more modern ways (e.g. Qt, C++, JSON).

  ravynOS is explicitly trying to be compatible with Mac software at a source and eventually a binary level, without losing support for FreeBSD/X11 software, and to implement a very similar experience on the desktop and at the command line. For example, on ravynOS you can type open -a MyApp image.jpg and have image.jpg open in MyApp. You will find things in (mostly) the same directories as a Mac, like ~/Library or /System/Library/Fonts. This project is not as concerned about keeping the OS as small and simple as possible, and more concerned about making it clean, secure, performant, and compatible - implementing many of the features I use daily in macOS while skipping the lock-in and "tabletization" of the computer.

  Some of the more technical differences between ravynOS and helloSystem are:

  • ravynOS uses a patched kernel with support for Mach, just like xnu, and a compiler suite that supports Frameworks and has preliminary support for Mach-O as well as ELF
  • ravynOS has a package repo with software built to "standard" paths like /System, /etc, and /usr instead of the FreeBSD repos which are built into /usr/local
  • ravynOS desktop is being written from scratch with Cocoa, Mach, and OpenGL on a Wayland compositor, whereas helloSystem's desktop is based on OpenBox, Menu and Filer (originally from LXQt) plus other lightweight services for notifications (dunst), screen color temperature (redshift) etc
  • helloSystem uses a simplified .app structure whereas ravynOS uses real Bundles for .app
  • helloSystem tends to use typical Unix paths and files, while ravynOS is moving towards typical Mac paths and files
  • ravynOS tries to provide the same APIs as macOS

• elementaryOS: Currently using some icons and themes and totally open to other possibilities. However, we are not aligned on our preferred stacks - GTK vs Qt/Cocoa - which makes it harder.
• PureDarwin: ravynOS is not based on Darwin (see "Why not Darwin" above) but uses many of the same underlying pieces.
• Darling: ravynOS is not based on Linux or Mach-O but uses many of the same underlying pieces. Darling's Cocoa implementation comes from the same source as ours and I suspect we could share some code here. I'm definitely keeping an eye on Darling :)
• GNUStep: GNUStep is pretty good and their Cocoa implementation is much further ahead than ours. We use the libobjc2 runtime from it. However, the way it is packaged, the GS* extension classes, and various other things made it "less than ideal" for ravynOS. Also I prefer BSD/MIT/Apache-style licensing. That said, I'm open to using it if we can make it work.

Notwithstanding the above, I'm open to collaboration with anyone who finds parts of ravynOS useful or who has code they think might be useful to it.

Yes. Here's to the crazy ones... because the people who are crazy enough to think they can change the world are the ones that do.

In all seriousness, though, it's not my first rodeo. I have no illusions about the scale of building an OS or how long projects like Haiku, ReactOS or GNUStep took to get usable. This is just something I like doing in my Copious Spare Time™ and that I hope will be useful someday.

I've always liked Apple's design and elegance, but am not thrilled with the direction of recent macOS® or how closed the hardware has become. And I'm a big believer in open source. So ... let's build something that feels as elegant, without all the lock-in, and maybe (just maybe) I can get it to a point that reasonably useful Mac apps build & run on it. And if not, we'll build a lot of cool pieces along the way and learn a ton. I'm OK with that.

The login credential for the liveboot currently is: liveuser, all in small letters, and no password. Just type liveuser in the username field and press enter/click on the login button.

Since ravynOS 0.4.0 is having its GUI written from scratch, there is no driver for any virtual machine GPU yet, including VMware VGA, Virtualbox SVGA, virtio-vga or qxl and thus, no form of graphics acceleration is currently available. The OS will display a shell-like/ tty interface on virtual machines.

We are working on this, and help is welcome. There is work being done on vmwgfx for ravynOS and this might be released soon, making it possible to test LiveCD on virtual machines 🙂. Currently, VMs are usable for non-UI development.

Video drivers, for the time being, exist for only Intel HD series, Intel Iris series (Xe graphics), most AMD integrated and discrete GPUs. There is no driver yet for NVIDIA. Help fixing this is most welcome. If your GPU is supported, the GUI starts automatically on boot. If not, you will receive boot messages on screen followed by a shell-like interface (tty1).