Earlier quoted context omitted.
> 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?
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…
Airyx OS
211–220 of 258 posts
Re: Airyx OS
#212Earlier quoted context omitted.
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,_... .
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…
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.
Re: Airyx OS
#213More 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+…
It's a tall order, but sometimes projects like this take off.
Re: Airyx OS
#214Airyx’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/
Re: Airyx OS
#215How does this materialize when MacOS is shifting away from x86-64?
Also, they need to do some basic spell checking.
Re: Airyx OS
#216No screenshots for a GUI-centric OS? Seriously?
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 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 i…
Requesting screenshots is not entitlement, it's both legitimate AND a useful advice to improve the landing page.
Re: Airyx OS
#217Given 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.
Re: Airyx OS
#218More 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+…
The problem is lack of support for docker.
Re: Airyx OS
#219Earlier quoted context omitted.
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.
Re: Airyx OS
#220Earlier quoted context omitted.
> 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.
Could you perhaps relicense your implementation so it could be used outside of 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.