Airyx OS(airyx.org)
airyx.org
Airyx OS
http://airyx.org/
257 comments
It’s hard to tell how far they’re at. No screenshots? No progress bar?
Cool! Screenshots?
More information and motivation in the git repo[0], the link to which I didn't spot easily in the site header.
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
[0] https://github.com/mszoek/airyx
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
[0] https://github.com/mszoek/airyx
> compatible with macOS filesystems (HFS+ and APFS)
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.
[0] https://github.com/eafer/linux-apfs-rw
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.
[0] https://github.com/eafer/linux-apfs-rw
> It's a pity you are working with Linux, or it could have been of use to her.
FTFY
FTFY
Oh, I wasn't trying to diss FreeBSD. It would probably have been better to write my driver for fuse to make it portable, but it's too far along at this point.
Out of interest, why can't file system implementations be portable? A shared core that exists as a library that can be tested in userland, and which can then be used by a lightweight shim that implements the kernel-facing interfaces. But I haven't seen any file systems implemented this way.
The irony is that most of the newer ones in Linux are written that way, just nobody writes a FUSE binding to them. For example, both Btrfs and XFS contain fully functional pure-userspace implementations of the filesystem inside their userspace code (libbtrfs and libxfs both contain the complete filesystem code), but nobody has written a FUSE binding to either.
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).
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).
FUSE is neat for one-off access to obscure file systems, and FUSE is usable for things like sshfs for those who use that, but it is my impression from having used FUSE myself that FUSE does come with a noticeable performance penalty. Is my perception wrong on this? Because if it is not then I’d be hesitant to use a system where the main storage was relying on FUSE.
FUSE is also great for slower media. Copying files over USB sticks without being restrained by FAT-32 limitations is great. There have been times that I've used NTFS-3g for this because its FUSE implementation meant I could read it on any OS.
Stuff like gocryptfs seem to push FUSE to quite high performance. There is still some latency but streaming read/write seem to go fast.
Do you have any documentation on that?
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
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
This is also how the original BSD UFS/FFS was developed some three decades ago.
While the kernel interfaces aren't exactly wildly disparate, they are perhaps surprisingly diverse (and coupled to kernel implementation details) for something as boring as a filesystem. At least some of this is for performance reasons. Accessing offsets into kernel structures is usually going to be faster than copying the data to use on your own.
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]
1: https://en.wikipedia.org/wiki/NTFS-3G
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]
1: https://en.wikipedia.org/wiki/NTFS-3G
Shims in the kernel seem a bit anti-social, since all module developers are expected to contribute to the shared core code. Of course it can be done, and it has been done. But I think FUSE is better if all you care about is portability, and you don't mind the heavy performance cost. My module could be ported for FUSE of course, but it's a lot more work than it may seem, the kernel interfaces are too alien compared to a userland library.
ZFS is pretty portable because of spl ;)
Too late, the Linux fanboys have already struck!
> how hard it is to implement a modern filesystem that won't eat users' data.
Why is that so hard? Because of edge-cases? Caching/Timing considerations?
Why is that so hard? Because of edge-cases? Caching/Timing considerations?
The main problem is simply that people really really really don't like losing their data after they saved it to disk. A simple app that corrupts its in-memory state once a year is probably acceptable. A filesystem that corrupts its on-disk state once a year is pure garbage. You basically need to aim for zero bugs.
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.
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.
It's worse than this. You not just need to aim for zero bugs, but zero bugs despite working with hardware that can degrade with use and who's firmware often does have bugs.
HFS+ is open source, so you don’t even need to rewrite it from scratch.
And yet this didn't stop Apple from automatically converting HFS+ volumes to APFS in iOS 10.3 and macOS 10.13.0 soon after the APFS beta dropped in macOS 10.12.5 and it didn't stop Apple from requiring APFS for all volumes in macOS 10.14+. Apple must have been pretty confident that APFS was working reliably to be so bold.
Not sure why you are telling me this, I don't know anything about Apple's internal development process. I assume they did run a lot of tests. But I recall at least one serious bug early on too[0].
[0] https://www.theregister.com/2018/02/16/apple_file_system_bug...
[0] https://www.theregister.com/2018/02/16/apple_file_system_bug...
The big problems continue to be
• 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"
• 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"
> C being a shitty language that does not force or even encourage programmers to handle errors
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.
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.
I'm curious why you think file systems written in C would somehow be better than any other type of program written in C. We have plenty of data suggesting C programs have more bugs and vulnerabilities than programs written in safer languages.
If you are thinking about rust, we don't have any data about it in the context of the kernel yet, not even for device drivers. It may prevent some exploitable bugs, but those aren't a big concern for filesystems - otherwise they wouldn't be put inside the kernel at all. The reality is, we don't know if it would help; and given how conservative we all are with our filesystem implementations (for good reasons), it's possible that we never will.
I'm not thinking about anything specific, I'm simply disputing your general claim that moving away from C would not help, when it has clearly helped in every single other domain of software development. I see no real reason why file systems should be any different, but clearly you do, so I was asking you why you think file systems would be different.
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.
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.
OK, I thought you meant rust because that's the only other language with chances of getting support inside the Linux kernel right now.
> 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'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.
> It's a pity that she is working with FreeBSD, or it could have been of use to her.
I suppose FreeBSD made more sense as a base considering MacOS is derived from BSD.
I suppose FreeBSD made more sense as a base considering MacOS is derived from BSD.
FreeBSD differs quite substantially from the XNU kernel used by MacOS because XNU is based on Mach, and it was forked (Edit: from 4.3BSD) in 1988 - before Linux even existed.
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).
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).
>XNU is based on Mach
Partially, XNU is Mach AND the FreeBSD-Kernel:
https://www.youtube.com/watch?v=-7GMHB3Plc8
Partially, XNU is Mach AND the FreeBSD-Kernel:
https://www.youtube.com/watch?v=-7GMHB3Plc8
> MacOS because XNU is based on Mach, and it was forked (Edit: from 4.3BSD) in 1988
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.
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.
Could you perhaps relicense your implementation so it could be used outside of Linux?
I don't think it's a licencing issue. It's implementation as both kernels uses different syscalls and have different architecture.
Syscalls are mostly the same, but indeed, the interface between the kernel and the file systems is very different. However, code which implements that interface on the file system is a relatively small part of the whole thing; most of the code should be reusable.
Historical note: FreeBSD used to support XFS; I believe it was ported from Linux.
Historical note: FreeBSD used to support XFS; I believe it was ported from Linux.
I don't think I can, I'm using gpl code from other parts of the kernel. I'm not sure I would want to either, I put a lot of work into this and the gpl gives me more of a feeling of ownership.
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.
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.
I think are underestimating in general how much work it is. ReactOS has been developed for 23 years and is not in a useable state yet.
However ReactOS has a more challenging/bigger goal for a few reasons. It aims to be binary compatible, not just source compatible. Much more of the underlying tech is proprietary while the BSD subsystem on macOS is free for them to use.
"eventual compatibility with x86-64 macOS binaries (Mach-O) and libraries"
Is there a particular reason to reimplement a proprietary FS (a gargantuan task) when FreeBSD already has a world class (cross-platform!) FS in ZFS/OpenZFS? Is there something about Mac apps that rely on HFS+/APFS-specific features?
I assume some of those apps may not work with case sensitive file systems. Which I believe is supported by ZFS.
> source compatibility with macOS applications (i.e. you could compile a Mac application on Airyx and run it)
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.
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.
Darwin can run limited MacOS applications provided they don't use a proprietary Apple MacOS library. Airyx is so limited and doesn't have a lot of users to be worth suing over I think.
Probably cheaper and easier for apple to kill them while small/young
They are no threat to Apple; Apple's business is selling hardware, with software bundled to it.
This is no more menace to them than ReactOS for Microsoft.
This is no more menace to them than ReactOS for Microsoft.
A natural pivot if the software was successful would be to start selling the hardware with the software putting them in direct competition. After all people generally don't buy OS they buy computers.
Exactly. Do people sell computers with ReactOS?
OTOH Wine, properly improved and adjusted, sort of made a dent in the market in the form of Steam game consoles.
OTOH Wine, properly improved and adjusted, sort of made a dent in the market in the form of Steam game consoles.
They haven't done anything illegal or immoral. Giant company tries to use nonsense lawsuits to illegally destroy competition doesn't make for great PR.
Yeah, if they took the path of ARDI's Executor from the 90's, it IS possible to have a completely clean-room emulation (of Apple) without violating any intellectual property.
You would need to reverse engineer what the frameworks are supposed to do and provide new implementations. (You can see all their external APIs) This is what Google did with Java on Android. The courts currently view this as legal (Google v Oracle).
The core of MacOS is Darwin which is open source. Based on the MACH/XNU kernel and *BSD. So any MacOS clone would start with using Darwin code.
Emulating macOS at the Darwin layer is not necessary and often not advisable (see: GNUstep).
The goal was "source code compatibility with macOS applications".
Most Mac apps never call into the Darwin layer directly.
Lots of macOS applications need to drop to a few Darwin related features from time to time, if only to work around bugs in the frameworks. In addition, lots of applications run on macOS that use POSIX APIs, which are (typically) implemented in Darwin and not in the user-space frameworks.
But yet, I misunderstood the GP comment, and what I said was not really appropriate in that context.
But yet, I misunderstood the GP comment, and what I said was not really appropriate in that context.
Sure there are (for some definition of "most important parts). Take a look at GNUstep for a start. Some MacOS frameworks like WebKit are also open sourced from Apple itself.
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...
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...
GNUStep is not current with the frameworks that it corresponds to on macOS (and was never complete).
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.
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.
GNUStep now it's implementing CoreVideo and CoreAudio.
> Sure there are (for some definition of "most important parts). Take a look at GNUstep for a start.
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.
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.
> Hard to see how this can be done legally.
Why? Things like Wine and Proton exist and Windows is proprietary.
Why? Things like Wine and Proton exist and Windows is proprietary.
Even ReactOS, an open-source implementation of Windows exists.
How many years has the Wine project been running?
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.
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's a practical question, not related to the legal question.
The legal question I was referring was related to my perception that the goal was "source code compatibility for macOS applications" now, not after some essentially unbounded engineering task.
That may have been incorrect.
That may have been incorrect.
This is addressed in the README I linked to. Reimplementation of APIs is not legally sketchy. See Oracle vs Google.
https://www.eff.org/cases/oracle-v-google
https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_....
https://www.eff.org/cases/oracle-v-google
https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_....
Working second link: <https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_...> (it has a "." at the end)
That decision only applies in the USA. I think it will be undetermined in many jurisdictions.
That decision only applies in the USA. I think it will be undetermined in many jurisdictions.
If it is, then expect everyone selling PCs to get a nicely worded letter from IBM about their BIOS. Any jurisdiction that rules differently will imperil their whole software industry.
(Edited for clarity)
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).
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).
IBM already tried that in the 80's and lost, due to the way Compaq did it, that is why you have PC compatibles.
Yes, but Oracle's lawsuit was trying to rewrite the book so copying API was copyright infringement regardless of the clean room used.
To clarify, I didn't mean to imply that reimplementation would be a legal issue.
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.
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.
Yeah oddly enough that seems like the diciest part of the project to me. The Cocoa API is vast, reimplementing it isn't necessarily rocket science but would require a pretty huge amount of labor.
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.
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.
I love an ambitious project like this.
It's a tall order, but sometimes projects like this take off.
It's a tall order, but sometimes projects like this take off.
The problem is lack of support for docker.
Apple's MacOD only supports Docker through a virtual machine anyways, so it's not like that's any different
Airyx’s developer may want to say hello to the developers of Hello, who are doing something very complementary to this with UX—and are quite far along already. https://hellosystem.github.io/docs/
"0.2.2 is the first build of Airyx based on the helloSystem components and FuryBSD LiveCD installer. It can be run or installed from the ISO and should have better hardware support, in addition to the slick helloSystem desktop and applications."
via https://github.com/mszoek/airyx/releases
via https://github.com/mszoek/airyx/releases
Good eye. Probably should be made more clear in the readme, because it’s the obvious question that came up for me.
I find it funny that there are people working (presumably) really hard to replicate the trademark OS X look and feel for other operating systems while Apple is working similarly hard to move away from it as quickly as possible.
It's a general trend in SW development. If it works, fix it. It seems to make everyone except users happy.
I had a buddy who had a sort-of designer-developer role who would say "if it ain't broke don't don't fix it"
You have to think about it in terms of form-factor changes/evolution.
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.
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.
If any Hello devs are here, I just want to point out that I was interested in using their interface, until I noticed that the window titles are not centered based on the window but on the space between the window buttons and the window (this is on the website). That put me off the whole website (which is fast judgement on my part, but hey I've got stuff to do).
Does anyone else here agree?
It is a known issue (ref: https://github.com/helloSystem/ISO/issues/145).
It's hilarious how a macOS-lookalike desktop environment is using Linux-like technologies like Openbox and KWin, rather than building something in Cocoa. I suspect it will cause trouble trying to bodge KWin to have Mac-like window management, or support apps that integrate with Apple's graphical acceleration and compositing frameworks (Core Animation? https://mozillagfx.wordpress.com/2019/10/22/dramatically-red...).
oh, why did you point that out to me!, now it's driving me crazy.
How similar are Airyx and Hello to: https://www.darlinghq.org/
I probably missed a lot of things, but didn’t Gnome already achieve this? Weren’t most of the people behind its design from Apple?
Gnome shares some of the same aesthetic choices and its co-founder famously went on the record as preferring Macs but I'm not aware of any substantial connection between Apple and Gnome. Gnome is strongly connected with Red Hat which naturally supports a lot of Linux development.
The developer of Hello would disagree with you: https://medium.com/@probonopd/hellosystem-three-layer-ux-des...
That's a good sign. Gnome has only become practical for me in recent years. I believe it's because its designers were from the original Mac OS era (pre OSX) where they favored too much simplicity at the cost of functionality. Maybe Hello designers are trying to get the balance of usability & functionality of OS X / modern Mac OS? If so, that's a great goal and I look forward to trying out what they have to offer in the near future.
Funny how he complains about missing the German language setting and proposing a new system where my language (Dutch) is completely missing... I will stick to Gnome...
Clearly he designed an example from scratch to underline his basic point, which makes sense because he’s making a point about user interface design. There are only a handful of languages in there—presumably an actual list will have more.
What a silly reason to not use something.
What a silly reason to not use something.
Ubuntu's Unity was a lot more macOS-like with the default global menu bar, then they gave up on it :(
Gnome doesn't even have a menu bar anymore, preferring apps use a single hamburger menu.
Wow. I believe you, but I really don't want to.
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?
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?
Because modern UX designers consider users their enemy. It's the only explanation I've heard that fits all the data.
It does sometimes seem like they are designing to impress other designers at talks and conferences, rather than to make users happy. But I respect anyone who develops open source end-user software. To say it is thankless is quite an understatement.
Yes, it is, and I respect them too. I just wish UIs would be considered finished once the major UX and implementation bugs were fixed. The reason I won't touch eithet Gnome or KDE is that there have been so many reimplementations of their UI that I simply don't want to learn them again. And again. And again. Especially as they bring nothing new to the table, just more "flashiness".
As someone who has used KDE 3, 4 5 I would say the only really big change was 3 -> 4 and many aspects of it have been refined/improved. I think if you plunked someone down who had only used KDE 4, released in 2008, in front of the current version in 2021 they would require minimal learning to catch up.
Growth requires change and if you don't have a billion dollars up front you do this iteratively in small pieces by necessity.
Growth requires change and if you don't have a billion dollars up front you do this iteratively in small pieces by necessity.
Unity was designed more for touchscreens, so that Ubuntu could make smartphones based on it. It didn't work out apparently.
Unity was originally designed for netbooks with limited screen real estate.
It was designed for touchscreens and desktops; a so called convergent interface. For example HUD, which allowed you to search any menu option (ref: https://wiki.ubuntu.com/Unity/HUD#Overview), and its Dash, a desktop search utility, were clearly keyboard-oriented. The bigger icons that launcher and dash had were probably made that way for touchscreens.
Vanilla GNOME3 looks and feels a lot like it was designed for tablets as the primary target, keyboard users as the secondary and mouse users only as the third.
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.
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.
Yeah I recently switched from macOS to a Gnome-using variant of Linux (Pop!_OS 21.04, which overall I really like and recommend if you are of the "I want to do my specific work and not tinker with my OS much" mindset like I am) and this design choice blew my mind.
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.
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.
This looks super cool. Reminds me of GoboLinux a bit but with BSD and the goal of being an open Mac environment. This has my interest cause I'm looking into trying to do something similar but using Linux instead (mainly because of hardware and graphics support) but without the goal of being Mac compatible.
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
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
Hello is the BSD Desktop project I was thinking of, someone mentioned it in a reply in this thread [0]. Also a very cool project.
0: https://news.ycombinator.com/item?id=28068864
0: https://news.ycombinator.com/item?id=28068864
Agreed; and to be clear, it’s great if both evolve separately. Building MacOS analogues is a great goal for BSD-based projects, especially given all the old machines that could use them, and I think will attract new folks to that community.
Projects like these will be always one step behind the thing they are trying to replicate (MacOS in this case). It is better to spend one's creative energy innovating and coming up with better solutions rather than re-implementing what Apple is doing.
Given that there’s 20 years of “behind,” and many of those machines are no longer getting updates, what’s the harm? The dev learns something and the community gains knowledge from the project.
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 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 Wine has been of far greater utility than ReactOS - both to users and as contribution to open-source.
There is a ton of cross-pollination between the ReactOS and Wine projects. Sure, Wine is more useful but they wouldn’t exist as they do today without each other.
> It is better to spend one's creative energy innovating and coming up with better solutions rather than re-implementing what Apple is doing.
I’d argue that there is room for both.
But, who is attempting anything better?
I’d argue that there is room for both.
But, who is attempting anything better?
Eh, I don't see much difference between older MacOS versions such as Mountain Lion compared to Big Sur.
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.
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.
It could be argued that just by being community-driven and open source, projects like these are in fact better. It all depends what "better" means to you. (E.g. not phoning home to Apple every time you open a program...)
I disagree. NeXT / macOS has been a pretty stable target for a very, very long time. If you’re going to clean room implement anything, a stable thing is a great target.
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.
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.
The „good thing“ is, that Apple seems to be heading in wrong directions.
So yes, it will be behind. Until suddenly it stops following and have it‘s own direction.
It is way overdue for a change in the ecosystem again.
There should be more choices for the average user.
I urge everyone who has some demanded skills to get involved in projects like this. It is time.
Luckily, macOS was at its best ~8 years ago, so it's okay if they're behind.
It is better to spend one's creative energy innovating and coming up with better solutions rather than re-implementing what Apple is doing.
What if you spend your entire career innovating and the result is still worse than Snow Leopard?
(/me kicks GNOME into a bottomless pit)
What if you spend your entire career innovating and the result is still worse than Snow Leopard?
(/me kicks GNOME into a bottomless pit)
> Projects like these will be always one step behind the thing they are trying to replicate (MacOS in this case).
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.
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.
Is it going to use the same keybinding convention that macOS uses, ie cmd-c/v for copy/paste etc?
We need a review video please!
Can I compile iOS apps on this? That's honestly the only thing holding me to macOS, I really wish Apple didn't force every iOS developer to use macOS to do so.
Isn’t that dependent on your private key stored on Apple’s equivalent to a TPM?
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.
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.
No, building software for iOS is possible on other platforms although this is against the terms of the Apple developer agreement.
> this is against the terms of the Apple developer agreement.
Of course it is
Heaven forbid we have any choices at all.
Of course it is
Heaven forbid we have any choices at all.
To be fair, Macs are one of the best choices out there, so I'm not complaining. The only thing that sucks on Macs nowadays for devs is how poor Docker is performing, even with all the workarounds like Docker-sync etc.
A few years ago I would've agreed but WSL is so damn good now that I honestly prefer it over developing on a Mac, particularly as it solves a lot of the performance issues.
I still have to try that...do you even prefer it over Linux? Or do you develop Windows-centric so you're on Windows anyway?
Nobody is forcing you to make ios apps
At my previous job, I got hired to build VR apps for the HTC Vive on Windows, which was exactly what I wanted to do. But I only ever got assignments to build AR apps for the iPad[0]. So while nobody was physically putting a gun to my head, there was the ever present threat of not being able to provide for my family.
[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.
[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.
They make references to a Darwin compat layer somewhere down the line.
Why do you think people want this?
People with old computers that no longer receive MacOS security updates, but are still perfectly functional and pretty powerful computers.
That is a big market, I believe.
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.
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.
The people making this want this. Why do you assume everything that someone makes must have a market to be worth making?
What is the difference between this and GNUSTEP http://www.gnustep.org/ and Darling http://darlinghq.org
Not sure about GNUstep, but Darling is akin to Wine, in that it is a re-implementation of the Mac APIs within a Linux environment, allowing you to run MacOS apps on Linux without recompilation. Whereas Airyx is a full FreeBSD OS (distribution?) that tries to mimic MacOS as a whole.
Sorry for what I’m sure is a stupid question, but what base this on BSD rather than Darwin itself?
Or, probably a better question, how am I misunderstanding the situation :)
Or, probably a better question, how am I misunderstanding the situation :)
people are hungry for a new utilitarian but fresh desktop OS. after the phone-home thing macos doesnt even exist as an option in my mind. i really like elementaryOS.
Apple cease and desist in 3... 2...
It looks like the APIs are being reverse engineered, thus even if this happens, Apple likely has little legal ground to stand on, if at all (IANAL). See also ReactOS[0].
[0] https://reactos.org/
[0] https://reactos.org/
True, though being wrong has never stopped a legal threats and action in the past. They can just bully a small project out of existence.
Pretty interesting project.
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.
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.
One advantage of a global menu bar is that items at the top of the screen are effectively an infinitely large target, so you can rapidly move the mouse to them without worrying about overshooting: https://en.wikipedia.org/wiki/Fitts%27s_law
But you want to select a specific menu and not just click somewhere on the whole menubar. So, it's no longer an infinitly large target and you need precision
They didn't say infinitely large in every direction.
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!
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!
You need a precise angle but not a precise speed. I can't speak for mice myself, but on my MacBook Pro trackpad, this is still much faster. Indeed, if I try to get the mouse cursor from somewhere near the middle of the screen to somewhere near the top, unless I go very slowly, it's essentially impossible to do it without overshooting and hitting the top. At that point I can turn around and move the cursor back down to the spot I'm trying to hit, but that requires waiting a fraction of a second, or else the high speed I accumulated from accelerating quickly will 'bounce' off the top and send me too far back down.
…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. :)
…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. :)
I like the menubar being a system-owned fixture (as it is for global menubars) because then there’s no reason for app developers to try to trim away menus or cram them in a “junk drawer” hamburger menu in the name of minimalism.
this this this. On Windows, menu bars are few and far between because of this.
I actually find the metaphor quite useful–as a developer I can develop a GUI application utilizing a common menu metaphor but _not_ always have a window open; essentially an application is a 'toolbox', presenting its tools via the global menu, and documents/'work' appear as windows. For context, I used Windows all my life before switching to Mac about six years ago, and I find this makes a lot more sense than one menu per window, where application developers often like to go their own way and implement their own menu metaphors.
> However, who really wants a "global menu bar". It made sense for the original mac, when people just used one app at a time.
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?
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?
> However, who really wants a "global menu bar".
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.
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.
how will this diverge from Hello?
Poked around a little bit on the livecd system, screenshots: https://imgur.com/a/OsxT3GI
Given the amount of stuff GNUStep is lagging behind macOS Frameworks after three decades, let alone the Swift ones, what is this for?
This reminds me of vegan bacon.
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?
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?
You can have the desire to not eat meat, yet, love the taste, texture and sensation of it. These things aren't incompatible.
I know it's kind of offtopic, but having gone vegetarian around 2 years ago, it's amazing how many times I heard this argument presented in the way you SHOULD NOT want to replicate meat, you can't call that a burger if it doesn't have meat, I'm not one to get offended but I find it so weird.
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.
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.
I'm not a vegan -- or vegetarian -- but I've noticed that, too: I see lots of people complaining about pushy smug vegans always being pushy and smug at them, but see very few vegans being actively pushy and smug. One kind of suspects that it's simply letting people know that you're vegan that they're reacting negatively to. The smug pushy vegan is the one in their head.
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.)
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.)
macOS comes with the cost of an expensive computer, this is a free OS that mimics a well designed one.
The obvious answer, of course, is that you do want to eat meat and run macOS for some reasons, but don't want to for other reasons, so I'm not sure what you really mean. Should we forget the good parts of things with bad aspects and not chase facsimiles, or embrace the bad aspects of things with good parts..? Neither one really makes sense to me; fake meat and fake macOS make sense to me, though I eat meat and use macOS. Or perhaps just that we should find substitutes that don't attempt mimicry.
Simple. Meat is delicious, but for some it comes with ethical issues. If you they replicate the taste (or sufficiently delude yourself), they can enjoy "meat" once again and sleep at night.
You want the taste you are used to but don't want to increase demand for animal abuse.
Here is a reason: Mac OS telemetry is just as bad as Windows. Few months ago app launches on Mac OS slowed down because the service that received the "app launch event" degraded. /Facepalm
It's awful how very few in the tech community challenge Apple for their false privacy claims.
/Happy and productive onna Linux desktop
It's awful how very few in the tech community challenge Apple for their false privacy claims.
/Happy and productive onna Linux desktop
I agree. It doesn't make particular sense. Even if you aren't a complete fanatic about MacOs UI, you wouldn't choose FreeBSD as a base, but rather Linux, which has a lot of advantages for the average user, I'd say.
Can you give some examples for those advantages?
Also, note they because FreeBSD is orders of magnitude less bloated and organizationally convoluted, it’s easier to implement functionality you need.
Also, note they because FreeBSD is orders of magnitude less bloated and organizationally convoluted, it’s easier to implement functionality you need.
FreeBSD has also some advantages. The major disadvantage I see is that there is less adoption, thus less possibility to get help with the various issues endusers do face.
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'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.
Let’s not forget that projects like this are cool and we should support developers who are biting off a ton.
> This reminds me of vegan bacon.
> 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.
> 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.
If you don‘t want to rape people, why try and have sex at all?
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?
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?
I am not vegan because I do not like meat, I am vegan because I think that it bad for the environment and causes unnecessary suffering to animals.
The fact that I could enjoy meat without any of those downsides is appealing to me :)
The fact that I could enjoy meat without any of those downsides is appealing to me :)
Change your thinking and you will be able to enjoy it again.
Did you really have to sidetrack and bait a technical conversation by mentioning vegan bacon?
Enjoy the off topic comment chain.
Enjoy the off topic comment chain.
because Macbooks aren't great machines:
- 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.
- 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.
> If you dont want to eat meat, why try and replicate the taste, texture and sensation of eating meat?
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.
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.
I think they want to build a new FreeBSD distribution rather than "a new operating system". Similar to Ubuntu maybe, but imitating MacOs.
They'll probably fail, but that's not the right criterium to apply to most projects...
They'll probably fail, but that's not the right criterium to apply to most projects...
Why cant you guys add some screenshots?
Seconding this! Having some screenshots on the homepage would be very useful, since most other OS distros out there offer that.
Some other users in this thread did link some Imgur galleries of the live CD, though:
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 )I think macOS has too large of an API nowadays to try to copy. There are a whole smorgasbord of frameworks. This can only really help with the simplest of Cocoa applications.
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!
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!
I checked a few files, and a lot of the foundation library have 2007 until 2009 copyright notices. Another random check, CALayer.h and CATransform3D from the Quartz framework, shows terribly limited functionality in comparison to the files on macOS 11.5. The latter comes with 198 frameworks, Airyx has 16, 2 of which don't exist (anymore). Catching up seems an impossible task.
Just look at GNUStep for a failed effort to keep up, despite it existing since the golden days of AfterStep and WindowMaker.
Does GNUStep even support latest Objective-C runtime?
Does GNUStep even support latest Objective-C runtime?
>It builds on the solid foundations of FreeBSD
Why not build on Darwin which basically forms macOS's core?
And how it differs from helloSystem?
Why not build on Darwin which basically forms macOS's core?
And how it differs from helloSystem?
No screenshots for a GUI-centric OS? Seriously?
The OS doesn't exist today. Mostly likely it never will. Like half of the projects posted to HN, this is "aspirational". A landing page for a project that someone would sure like to do.
Sure it does, they link to the developer preview: https://github.com/mszoek/airyx/releases
That is essentially a repackaging of helloSystem (https://hellosystem.github.io/docs), which itself is a FreeBSD spin with a custom display manager.
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.
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.
oh c'mon, it's a pre-alpha/pre-release of something someone is developing in their spare time and haven't even posted on HN themselves.
It's open and on github. It clearly says at the bottom of that page
Downloading the ISO and mounting it in a VM took me problably less time than it took you to write this self-entitled comment.
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.
Come on, you can't seriously respond to "can I see some screenshots" with "just download the ISO and install a VM"...
Requesting screenshots is not entitlement, it's both legitimate AND a useful advice to improve the landing page.
Requesting screenshots is not entitlement, it's both legitimate AND a useful advice to improve the landing page.
This is incredibly common. Why would you develop anything and then not provide screenshots? Even for CLIs screenshots are useful!
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
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
Not to diminish the effort, but I think replicating the look and design (as in how things work) of MacOS (or Windows 10) is a pitfall that very few alternative OS developers manage to avoid.
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 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.
And while they are at it, they really oughta think about how that Unixy 3D file manager from Jurassic Park would look if invented in 2021!
XFCE is the modern CDE and GTK was the modern Motif on UI.
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.
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.
> It's just a bad idea. They'll never get even close, and those screenshots on Imgur prove it.
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.
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.
As I'm saying, to choose MacOS or Windows 10 as your foundation is a dead-end. Many have tried before.
If you read my comment, you'd have read that I propose to look to the history of Unix as the foundation.
If you read my comment, you'd have read that I propose to look to the history of Unix as the foundation.
It looks like a counterfeit operating system though.
It's also an enormous task to replicate one. User interface design isn't just about rounded edges and aqua chrome, it's about all of the small details: spacing, scale, padding, margins, font rendering and hinting, colour, arrangement, target zones, interactive feedback, discoverability.
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.
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.
hello started out of dissatisfaction with elementaryOS. hello tries to replicate Mac OS not how it looks but how it works. It’s not fair to compare elementary to such a new project maintained by one person.
There's a big difference between replicating how something looks or works and replicating how something actually feels to use. Granted, elementaryOS is a more mature project with more people behind it but the attention to all those little details is what makes it feel nice to a user.
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.
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.
> 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.
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
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
Gnome is good enough.
This but unironically for KDE. (UI wise)
Gnome was good enough until the Gnome 3, by then it lost the plot.
That's an interesting take. It would've been interesting if Motif were open sourced a few years earlier, as there would've been fewer wars about the correct Linux X11 toolkit (amongst the commercial Unices, this was just settled with Motif/CDE being the winner).
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.
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.
Presumably Apple is waiting for this project to invest a huge amount of time and resources and be almost ready to release before suing the hell out of them, in order to discourage similar efforts?
Of course, it is the sole purpose of Apple existence.
How do you people even come to these conclusions?
How do you people even come to these conclusions?
I understand it was meant as a rhetorical question, but I think there's a plausible response to that.
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.
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.
I thought it was a more polished version of PureDarewin.
One thing I wonder is why they're using FreeBSD as a base and not Darwin. I use FreeBSD myself and it's great, but if you're really going for Mac compatibility I would use the same kernel considering it's FOSS.
Lack of device drivers mainly, I would assume.
Could be something else, I know there were projects attempting to do things with Darwin in the past and none were successful.
Could be something else, I know there were projects attempting to do things with Darwin in the past and none were successful.
Aha that explains a lot. Yes I'd imagine Darwin having drivers only for hardware used in Macs and nothing else. I didn't think of that.
I think this could be more successful if they break it into parts. E.g. a window manager, and separate macOS emulator. And allow other BSD/Linux/Unix distributions to use them as well and install them as packages.
> Drag and drop app install and uninstall - no package manager, no installers
Awful
Awful
I'd love to throw an investment into something like this with GUI, marketing and supply chain resources to build a solid computer under $300 for a developing world.
Go up against Fuchia and Google hardware in less time and with more clarity.
Go up against Fuchia and Google hardware in less time and with more clarity.
As a long time windows user, Linux Mint greatly eased my transition from Windows to Linux and now I love it so much that I am never going back to windows again.
Such projects help reduce a lot of friction for people who want to switch but need a little help to make the jump.
Such projects help reduce a lot of friction for people who want to switch but need a little help to make the jump.
As someone who regularly takes on projects that are bigger on the inside, than the outside, I wish her well.
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...).
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...).
[deleted]
I'm not really sure why this project exists separately from Hello, and loath the idea that something like that is already fragmenting, Linux distro style. That said, having more things out there demonstrating that application management need not be any more complex than file management is good. It seems like people who never experienced AppDirs, Application Bundles, or the original Mac Applications simply can't conceive of a universe in which applications don't need an installer or a specialized complicated management tool.
Hm, there is a German company with the same name..
https://airyx.de/
https://airyx.de/
curious how Airyx devs think about the question of supporting apple silicon arm64, like m1 (or presumably m2 etc later on). Is it an explicit non-goal? A question of having the resources?
So you ripped off helloSystem, basically.
https://github.com/helloSystem/hello
Why?
https://github.com/helloSystem/hello
Why?
Having a similar idea is not the same as ripping off.
It's literally a copy of hello which makes it a ripoff.
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?
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?
"compatibiilty with macOS® on x86-64 sytems"
How does this materialize when MacOS is shifting away from x86-64?
Also, they need to do some basic spell checking.
How does this materialize when MacOS is shifting away from x86-64?
Also, they need to do some basic spell checking.
This reminds me tangentially of another formerly BSD project trident formerly based on TrueOS that made the jump to being based off void Linux.
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.
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.
This is kind of an aside, but can mods edit links the way they can post titles?
This is routing to a plain HTTP URL for some reason despite a valid HTTPS one existing.
This is routing to a plain HTTP URL for some reason despite a valid HTTPS one existing.
A cargo cult operating system. None of the things it provides are the reason people use macOS. They use it because they pay money to ensure everything just works, and to use their macOS apps.