Live data from Hacker News

Airyx OS

airyx.org

211–220 of 258 posts

Re: Airyx OS

#211
post #88
post #75

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…

HFS+ is open source, so you don’t even need to rewrite it from scratch.

Re: Airyx OS

#212
post #63

Earlier 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…

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.

Re: Airyx OS

#213
post #4

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+…

I love an ambitious project like this.

It's a tall order, but sometimes projects like this take off.

Re: Airyx OS

#216
post #147

No 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…

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.

Re: Airyx OS

#217
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.

Re: Airyx OS

#218
post #70
post #4

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+…

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

Re: Airyx OS

#219
post #134

Earlier 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.

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.

Re: Airyx OS

#220
post #137
post #112

Earlier 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?

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.

Post reply on HN