- Can I run macOS apps on airyxOS?
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 airyxOS 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 airyxOS and run as native applications (e.g.
Install airyxOS.app). While this is all very exciting, you will have to wait a bit longer to run Photoshop or Xcode.
- Why BSD instead of Linux?
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!
- Why BSD instead of Darwin?
The short answer is "hardware support". Airyx 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.
- Is this... legally sketchy?
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 Darwin (macOS) emulation on Linux. Airyx 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.
- What programming languages does Airyx use?
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.
- I can code in those! How can I help?
Great! Take a look at the issues list to find something that interests you, or contact mszoek.
- I don't code but this looks awesome! Can I still help?
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.
- Can I support the project financially?
You sure can! I've signed up for GitHub Sponsors to make monthly sponsorship easy. You can also make a contribution via PayPal.
- Why aren't you working with project XXXX? Isn't this a duplication of effort?
This one has been asked a lot so:
helloSystem: We are in fact working with helloSystem! As some people have noticed, Airyx 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, Airyx 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).
Airyx 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 Airyx you can type
open -a MyApp image.jpgand have
image.jpgopen in MyApp. You will find things in (mostly) the same directories as a Mac, like
/System/Library/Fonts. Airyx 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 Airyx and hello are:
- Airyx uses a patched kernel and compiler suite that supports Frameworks and has preliminary support for Mach-O as well as ELF
- Airyx has a package repo with software built to "standard" paths like
/usrinstead of the FreeBSD repos which are built into
- Airyx desktop is based on KDE Plasma where hello'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 Airyx uses real Bundles for .app
- helloSystem tends to use typical Unix paths and files, while Airyx is moving towards typical Mac paths and files
- Airyx 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: Airyx is not based on Darwin (see "Why not Darwin" above) but uses many of the same underlying pieces.
- Darling: Airyx 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 Airyx's 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 Airyx. 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 Airyx useful or who has code they think might be useful to it.
- This is a huge effort. Y'all must be crazy!
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.
- Why won't it start in VirtualBox?
Airyx 0.2.2 may hang after booting the LiveCD with a black screen if you run in VirtualBox with the default VMSVGA driver. Changing to the VBoxSVGA driver for display may fix the issue. See issue #74 for details.