Airyx OS
airyx.org
airyx.org
The main design goals are:
* source compatibility with macOS applications (i.e. you could compile a Mac application on Airyx and run it)
* similar GUI metaphors and familiar UX (file manager, application launcher, top menu bar that reflects the open application, etc)
* compatible with macOS filesystems (HFS+ and APFS) and folder layouts (/Library, /System, /Users, /Volumes, etc)
* self-contained applications in folders or a single file and a (mostly) installer-less experience for /Applications
* mostly maintain compatibility with the FreeBSD base system and X11 - a standard Unix environment under the hood
* compatible with Linux binaries via FreeBSD's Linux support
* eventual compatibility with x86-64 macOS binaries (Mach-O) and libraries
* pleasant to use, secure, stable, and performant
Hard to see how this can be done legally. The libraries (sorry, Frameworks) that make up the user-space runtime for macOS are all proprietary. There's no replacement for the most important parts of it.
This is no more menace to them than ReactOS for Microsoft.
OTOH Wine, properly improved and adjusted, sort of made a dent in the market in the form of Steam game consoles.
But yet, I misunderstood the GP comment, and what I said was not really appropriate in that context.
As an example of how this works in practice, the disassembler/decompiler Hopper has both MacOS and Linux versions that are compiled from the same code.
Now, how successful they'll be extending the open source frameworks to made this useful in compiling non-trivial software that wasn't written with "dual compatibility" is a fair question, but the starting pieces are there, and patching the compilers and creating a copy of MacOS's filesystem layout would go a long way in making it easier to compile MacOS software on FreeBSD/GNUstep.
And in any event, so far as doing it legally, I don't see why this would be any less legal than Wine's recreation of the Win32 API/libraries. Only difference is Apple might be more litigious than Microsoft, but Microsoft doesn't exactly lie down to software theft...
It had to be, it was forked from KHtml, which was GPL.
I was following and trying to use GNUstep 15 years ago, and they were constantly chasing a moving target and were not managing to catch up. (Plus naturally the reimplementation bugs, plus the differences in interpretation of the "spec" which forced the programmer to be very careful and not take shortcuts.)
That's the huge issue when you are trying to reproduce an API which is not under your control by any mean, and is still alive and changing.
Those frameworks are also a tiny part of the full set that you need to build non-trivial software on macOS.
Audio? Video? so much more stuff that nobody has ever tried to reimplement the APIs for.
Yes, such a reimplementation would be legal,but Wine has been a project for 20+ years and has a huge headstart compared to any idea of doing this for macOS.
Why? Things like Wine and Proton exist and Windows is proprietary.
There is absolutely no equivalent for macOS frameworks. GNUStep is a tiny part of the picture, and in addition has not kept up with the fairly radical changes that Apple has introduced to the frameworks that GNUStep does correspond to.
That may have been incorrect.
https://www.eff.org/cases/oracle-v-google
https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_....
That decision only applies in the USA. I think it will be undetermined in many jurisdictions.
IBM hasn't been doing that for decades, despite the supreme court decision being quite recent - I think that was more about clean room reimplementation than APIs.
My point wasn't about ruling differently but the lack of rulings/laws making it explicitly legal creating uncertainty and opportunities for Oracle/Apple to go after people. Some countries have other ways to deal with it too, e.g. NZ allows reverse engineering for compatibility purposes, which seems likely to cover APIs (not sure, haven't needed to know).
I meant to imply that unlike the case with Windows/Wine, there is no reimplementation of the overwhelming majority of macOS APIs. So if you wanted to do this now, you could only do it by copying frameworks directly from macOS (which some people are doing for various reasons), and that does have some potential legal issues.
Theoretically, a reimplementation is possible. It doesn't exist, it's a huge project (far, far bigger than GNUstep), and as someone notes down-thread, it's also a moving target. There are also uncounted numbers of bugs in the current implementation of Apple's APIs, and for many things to work correctly you'd need to implement the bugs too since developers have designed around them.
Yes, Wine exists. But Wine started in 1993. The idea that a bit of hard work by some good developers is going to provide a reimplementation of the macOS frameworks in a year or three strikes me as without any foundation in reality.
And you're right - the Cocoa API continues to evolve, so if the goal is "source compatible with latest and greatest macOS APIs" it's hard to see how a small group of open source devs can out-run the sum totality of every API engineer at Apple.
I have similar feelings about cross-platform tools like Flutter as well - the idea in a vacuum is reasonably sound, but then you run into the basic scale problems of maintaining compatibility with a moving target - a moving target that has >10x more staffing than you do.
How far along is this? I think she's underestimating how hard it is to implement a modern filesystem that won't eat users' data. I've been working on a Linux APFS driver[0] for several years, and it's not fully functional yet. It's a pity that she is working with FreeBSD, or it could have been of use to her.
FTFY
Btrfs' implementation is even used to do most of the functionality in the tools (like send/receive) rather than using the kernel to do it (in order to minimize context switches that reduce I/O performance).
The benchmarks on their website[1] compare it running on a 4 x 3.20GHz with hardware AES-N instructions, against an in-kernel implementation of a different cryptosystem running on a 2.7GHz cpu that does NOT have AES instructions. I also can't see anything that speaks to speed of the storage (or if this is controlled for), so I'm admittedly quite skeptical.
The numbers they do publish aren't particularly impressive to me either, so we may also have wildly different ideas about what "quite high performance" even means.
[1]: https://nuetzlich.net/gocryptfs/comparison/#performance
On top of that, since there is no single standard interface in the kernel, kernel maintainers are skeptical of adding shims to the mainline kernel. The Linux kernel developers are perhaps the most famous for being vocal about this, but they are not unique.
That being said, there are portable file system implementations that use FUSE. See e.g. NTFS-3g[1]
Why is that so hard? Because of edge-cases? Caching/Timing considerations?
How hard this is, it depends on the filesystem. Something like FAT, for example, is pretty much designed for ease of implementation, with few edge cases. Modern filesystems are not like that at all, the data structures are very complicated, so they must be extremely well tested before they are good enough to use. That would probably require an fsck to check for subtle inconsistencies; in the case of APFS you can use mine, but it's still very incomplete. Apple's published fsck is not very thorough.
As an example of the kind of problems to expect, I recall a bug in the Linux HFS+ driver. If you had a drive with lots of short filenames and lots of long filenames, and you started deleting the short filenames, eventually you would lose half of your files. This kind of things happen because HFS+ has variable-length keys in the index nodes of its trees, so deleting a record may trigger a complicated cascade of node splits. APFS inherited this feature, and it was very annoying to implement.
But HFS+ is very well documented; APFS is not, and that doesn't help.
[0] https://www.theregister.com/2018/02/16/apple_file_system_bug...
• C being a shitty language that does not force or even encourage programmers to handle errors
• implementation knowledge about file system technology is generally stuck in the 1990s
• disk controller hardware lying to the OS to make them appear more performant than they really are
visit https://danluu.com & ctrl+f "files"
I don't see where this is coming from. Most of the world's top filesystems are written in C, and they work just fine. Maybe other languages could get better results, but it's hard to say with so little data.
> implementation knowledge about file system technology is generally stuck in the 1990s
If you are talking about me, that might be true, I'm relatively new to this and still learning. But there's definitely people out there with some serious "implementation knowledge". And tools like xfstests did not exist in the 1990s, that makes a huge difference.
And for specific examples of options with better safety records, then sure Rust would be one possibility, as would Ada, or Frama-C if you need to stick with C.
> I'm simply disputing your general claim that moving away from C would not help
I never said such a thing, I said we don't know. As always, in theory, there is no difference between theory and practice; in practice, there is.
I suppose FreeBSD made more sense as a base considering MacOS is derived from BSD.
The XNU kernel does not have a stable syscall ABI so perhaps it doesn't matter if the syscalls are different because the implementation of libSystem can convert as appropriate in userspace (see also: WINE).
Partially, XNU is Mach AND the FreeBSD-Kernel:
As another commenter noted: XNU = Mach + FreeBSD.
What you are referring to is what NeXTSTEP was, Mach + BSD4:
* https://en.wikipedia.org/wiki/NeXTSTEP#Unix
By the time Apple got to them it was a few years later, and so they decided to updated that part of the kernel, and also brought in FreeBSD's userland.
Historical note: FreeBSD used to support XFS; I believe it was ported from Linux.
That said, there's nothing stopping you or anyone else from reworking my code into a (gpl-licensed) FUSE driver. I don't think it's a straightforward task, but it can definitely be done.
It's a tall order, but sometimes projects like this take off.
What a silly reason to not use something.
I always figured that whole branch of design came out of dealing with mobile limitations, with some amount of side benefit from more screen space to do useless but flashy things to make the boss/client happy.
Why would you ever go that route for a general purpose desktop?
Growth requires change and if you don't have a billion dollars up front you do this iteratively in small pieces by necessity.
Ubuntu Unity did not - it was great for classic desktop usage with Mac-like (most importantly, not a mediocre attempt to mimic but even better than the original in some aspects) UX + advanced supports for keyboard lovers + keeping the mobile in mind.
IMHO late years Unity was the best Linux UI yet. If only they would add Pop_OS!-like tiling + some more little Mac goodies only experienced Mac users know it would be perfect. And I absolutely can not say the same about GNOME3 although I actually want a GNOME3 tablet.
I'm OK with a global menu bar, or app-window menu bar, but hiding everything behind a stupid hamburger thing on a desktop computer?
Weird choice IMO. I'm just living with it, though, since I don't really want to fuck around with my system itself.
There may be things users have grown to 'tolerate' that were accustomed to using only a desktop environment that may surprise those who might've managed possibly faster workflows on something like a tablet.
I downloaded the preview ISO. I looks a lot like another BSD project I know that aimed to be an open BSD based Mac desktop. IDK if they renamed the project or if this is the same project I was thinking of.
Screenshots from the Live CD: https://imgur.com/a/q3hp0np
However, who really wants a "global menu bar". It made sense for the original mac, when people just used one app at a time. And it's left in the current MacOS for legacy reasons. But now people usually have multiple 27" monitors. So, instead of having menus where the app is, you need to move the mouse all the way to the top and then back. Im not sure why anyone would want to replicate it.
If you're on a Mac now, try quickly hitting the menu bar items (at the very top edge of the screen) vs the tabs (below the menu bar, not quite at the edge).
I find the difference quite significant.
Peculiarly, this convenience would flip to the opposite if the screen were touch-enabled!
…Honestly, I don't know why the trackpad acceleration curve behaves that way. I've never consciously noticed this problem before right now, though, so it can't be that bad.
Anyway, of course my experience also differs in that my MacBook Pro does not have a 27" monitor. I could be using a desktop with a large monitor, but I prefer to be able to work from any chair or couch or even lying on the floor. I can see why the global menu bar would be more of a hindrance with a large monitor. But speak for yourself about what people "usually" have. :)
Please still use one app at a time. Try examining what most people actually do: they hit maximize on each app and fill the screen.
People that tile windows are the exception from my experience.
> But now people usually have multiple 27" monitors.
[citation needed]
I'd be curious to see what the numbers are. How many people in call centres have that? How many accounting and HR departments?
Me? Even when I "use" multiple apps at the same time, I can only interact with one at at time in the current keyboard/mouse paradigm we're working in, and it's nice to know that when I need menu options, they're always in the same place - the top left. There's always a context menu available by right/ctrl clicking if I'm so inclined and it's properly implemented, but in my multiple-monitor setup, I like having the global menu bar for when keyboard commands don't cut it.
It seems well-organized. She has her work cut out for her, but it can def be done (I seem to recall a certain trashmouth Finn, doing something similar...).
If this isn't the final look then I apologise.
What's the first thing you see on Apple's Big Sur landing page[1]? A big fat screenshot!
What about Windows 11 preview[2]? Yep, screenshots!
I can't think of a single time when the first thing I want to see on a landing page (or 1 click away) is not a screenshot or a demo.
[1]: https://www.apple.com/macos/big-sur/ [2]: https://www.microsoft.com/fr-fr/windows/windows-11
It's open and on github. It clearly says at the bottom of that page
A Developer Preview image of Airyx is currently available here. It's open to everyone, but is mainly intended for developers helping build the system and is not ready for daily use yet. Running in a virtual machine is recommended, although it should work on any hardware supported by FreeBSD 12.2 with at least 4GB RAM. (8GB is recommended.)
Downloading the ISO and mounting it in a VM took me problably less time than it took you to write this self-entitled comment.
Requesting screenshots is not entitlement, it's both legitimate AND a useful advice to improve the landing page.
The "source code" in this repo consists entirely of Makefiles and build scripts for working with helloSystem, along with a few FreeBSD header includes that were copied verbatim.
I mean, more power and best of luck to the author here. But let's not exaggerate the act of forking another repo and tinkering with its build process. All of the items in the post here (e.g. macOS application and filesystem compatibility) are still twinkles in the author's eye at this point.
I was once critical of ReactOS for similar reasons, but I’ve realized just how beneficial that project has been to OSS as a whole. Even if they fail they will uncover a lot of interesting stuff if the project continues long-term.
I’d argue that there is room for both.
But, who is attempting anything better?
Similarly, I don't see much difference between Ubuntu desktop distros in terms of differences across versions , say from 16 to 20.
Therefore... I don't see a being "one step behind" as any kind of issue. I've never run into an issue with past versions (such as those menntioned above) of OSes not running what I need them to run.
Personally, I'd like to see a Linux version which is very close to Apple so I can use it (such as OP's), instead of expensive Apple computers.
macOS has, however, been making superficial changes that people don’t care about. A free macOS desktop alternative would build on a stable set of core technologies, and let people do the crazy things that they want, and not do the crazy things that they don’t want.
What if you spend your entire career innovating and the result is still worse than Snow Leopard?
(/me kicks GNOME into a bottomless pit)
No, they won't. MacOS and Windows are both going backwards in innovations (according to many HN commenters at least). At some point this project (and ReactOS) will get better than the originals.
That said, lots of IDEs let you build on Windows/Linux, they just use a daemon running on a headless Mac on your LAN (or a rented “cloud” Mac) to do the code-signing part.
Of course it is
Heaven forbid we have any choices at all.
[0] And it didn't even make sense. I was making industrial equipment repair guide software. The first version of it I made for the Hololens, where it made sense, because, you know, you need your hands free to be able to actually enact the repairs. But you try telling that to a literally corrupt manager.
It's just a bad idea. They'll never get even close, and those screenshots on Imgur prove it.
What I'd prefer is if these definitely brilliant developers would "own" the Unix history more, and build upon Motif. Put the effort do create a mimicry of MacOS into modernising Motif. Hopefully not just make the chrome translucent, but really think about how Motif would look if invented in 2021.
It's a great idea. Because developing your own look and feel for the entire OS is an enormous task. This way you at least have a foundation to build upon.
If you read my comment, you'd have read that I propose to look to the history of Unix as the foundation.
While I am delighted that there are people out there trying to build open source desktops that are more friendly and attractive, it isn't going to turn out well unless you have people on board who really know and grok user interface experience and design. For a good example of this, look at the vast quality difference between helloSystem and elementaryOS — the latter having significantly more attention poured into the smaller design details and it is immediately obvious how much of a difference that makes.
You can't just duplicate what you think you see. You have to also understand why it was designed that way in the first place.
My point is that helloSystem and/or Airyx are going to need that same level of design attention if it's ever going to feel like an adequate substitute. That tends to be where most open source desktops miss the mark today — they feel like they were designed by developers, not people who understand what makes up a good user interface.
Of course, that should be the main driving force: to understand the why and the how.
All I'm saying is that it's easier to do by copying an existing design than trying to come up with your own. Fake it till you make it is also a part of the process :D
The first Gimp version even was written in Motif, before its developers started Gtk (and bikeshedding Xt)...
(I wouldn't start with a 2021 vision, as that seems to imply bad versions of over-stylized web and app interfaces, being almost as bad as the worst of the skeuomorphic UIs)
So, looking at CDE, what was specifically "Motif" about it? I don't think the file management was as special and intrinsic as the spatial Finder, Win95s tree+file view explorer or even NextStep's Miller columns.
Prominent virtual desktop usage?
More "active" use of color?
I think the dtksh part could be something interesting. Bridging the gap between regular Unix shell scripting (still more common than VBS or Rexx usage on other platforms) and UI creation.
Now, I don't think this is the way of the future, but it's not like anything will come out of the Mac clones (Etoile, hello, Airyx) either, and this seems like a more original thought experiment.
XFCE was born as a CDE clone, then it switched to GTK from XForms, but the essence looked really close to CDE.
On philosophy and universalitiy among Unices, QT won.
Could be something else, I know there were projects attempting to do things with Darwin in the past and none were successful.
If you dont want to eat meat, why try and replicate the taste, texture and sensation of eating meat?
If you dont want to use macOS, why try and replicate the taste, texture and sensation of using macOS?
To this first one I have 2 points, 1. don't tell me what I want and don't want to do and 2. don't tell me what I want and don't want to do. For the second point, when did you become a burger defender.
Before being vegetarian I've always heard how annoying are vegans trying to convince you bla bla bla, while I know it's circumstantial, I've almost never had that experience, but when I stopped eating meat, I've had dozens of people tell me I'm wrong, doing harm, it's stupid, pointless and that I should reconsider my personal dietary choices.
Personally, I like a fair number of the "plant-based meats" that are out there. When I cook vegetarian I'm often interested in finding ways to get a satisfying taste without using a meat substitute, but that's because, well, I find it interesting. If I want a burger, I want a burger, and this whole "you can't name it after a thing that traditionally comes from animals if it doesn't come from an animal" nonsense is nonsense.
(And, as a long-time Mac user, I'm not sure it's entirely off-topic, as for many years I saw lots of people complaining about pushy smug Mac users always being pushy and smug at them, but saw very few Mac users actively being pushy and smug. It was pretty clear that just mentioning "oh, I use a Mac" was enough to set people off. The smug pushy Mac user was the one in their head.)
It's awful how very few in the tech community challenge Apple for their false privacy claims.
/Happy and productive onna Linux desktop
Also, note they because FreeBSD is orders of magnitude less bloated and organizationally convoluted, it’s easier to implement functionality you need.
If you're not an average endusers, and you don't need to support average endusers with all their gazillion hardware and software needs, that's not an issue, of course.
> If you dont want to eat meat, why try and replicate the taste, texture and sensation of eating meat?
What is this taste, texture, and sensation of meat in regards to bacon you're talking about? Bacon is the opposite of the actual taste, texture, and sensation of meat. It's cooked, salted, and processed to give it that taste, texture, and sensation.
It's the same with people making fun of plant-based burgers and sausages. Well, guess what, burgers and sausages don't exist in nature, neither as meat nor plant. Well, actually... Cucumbers and a few other plants seem quite like sausages. Anyways. The burger, sausage, and bacon form factor is what makes it attractive. It's why people have liked it for so long, and why people like it still when they switch to a plant-based diet.
I guess it's the same reason why some people are into Airyx OS.
And even more absurd to use this kind of argument in the software world. Imagine back then... „If you don‘t like Unix, why...“, or the first GUI implementations on Linux trying to achieve what apple or microsoft did... Oh well, what our hacker world would be like if more people thought that way...
Sorry, not trying to offend, but these projects are what I live for. „Stickin‘ it to the big guys“ - after all, we are hackers, aren‘t we?
The fact that I could enjoy meat without any of those downsides is appealing to me :)
Enjoy the off topic comment chain.
- expensive.
- unergonomic.
- locked in.
I need macbook for work but I use Linux personally. Would be great if I could have native toolset on both.
Also there are hundreds of perfectly valid reasons to not want to support or deal with Apple.
Because the taste and texture of meat are pretty great, it's just that whole "raising and killing a sentient being" thing that's the problem.
The argument for something like Airyx is pretty similar: there are things to like about MacOS and things to not like about it, and it'd be great to get an alternative that has fewer negatives.
This might be OK though, because I think what a hacker interested in this is really interested is the parts of macOS that are common with NextSTEP. Which are all the parts 20+ years old!
Does GNUStep even support latest Objective-C runtime?
Go up against Fuchia and Google hardware in less time and with more clarity.
Why not build on Darwin which basically forms macOS's core?
And how it differs from helloSystem?
Possibly because of greater hardware compatibility.
Some other users in this thread did link some Imgur galleries of the live CD, though:
- https://imgur.com/a/OsxT3GI ( from https://news.ycombinator.com/item?id=28070125 )
- https://imgur.com/a/q3hp0np ( from https://news.ycombinator.com/item?id=28068895 )Given the differences in hardware support between Linux and FreeBSD, the fact that FreeBSD is slightly more similar under the hood provides next to no benefit when you already need a layer like wine anyway, and especially the necessity to produce an APFS filesystem if this wont end up going the same route ultimately.
How does this materialize when MacOS is shifting away from x86-64?
Also, they need to do some basic spell checking.
How do you people even come to these conclusions?
People looked at the behaviour of many large companies when they had to deal with IP infringement, and the most memorable examples were when they waited until near completion before launching a legal procedure (I've seen that mostly from the movie industry). From this behaviour, they then try to guess an ulterior motive.
The issue is that they fail to notice that a procedure on IP infringement is more likely to succeed when the supposed infringing work is closer to its source of inspiration: suing too early is a recipe of failure.
It's clear that phrased as it was, it painted Apple as an intrinsically bad actor. And you reacted to that. It is probably closer to the truth that it is in Apple's interest to protect its market using all available legal means. If this project turns out to be a threat, I don't think it is unreasonable to expect their legal team to make a move. But I don't think either that they are naive enough to believe that a success would dissuade the rest of the world from trying again.
Or, probably a better question, how am I misunderstanding the situation :)
https://github.com/helloSystem/hello
Why?
It also has the exact same stated goals, regarding macOS.
So when the goal is the same my question is legit, why?
What will be different to hello?
Why not just contribute to hello?
This is routing to a plain HTTP URL for some reason despite a valid HTTPS one existing.
Such projects help reduce a lot of friction for people who want to switch but need a little help to make the jump.
I don't think I will ever buy a new Mac. I will by used though.
I will continue buying Phones, and Ipads, until there's a comparable product.
Awful
They'll probably fail, but that's not the right criterium to apply to most projects...