Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Airyx OS

airyx.org

Post reply on HN
Print view View original

171–180 of 258 posts

Re: Airyx OS

#171

Post by trasz »

Conan_Kudo wrote: post #128
atombender wrote: post #123

Earlier quoted context omitted.

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

This is also how the original BSD UFS/FFS was developed some three decades ago.

Re: Airyx OS

#172

Post by trasz »

bayesian_horse wrote: post #73
shapefrog wrote: post #59

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?

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.

Re: Airyx OS

#173

Post by trasz »

NotEvil wrote: post #162
trasz wrote: post #137

Earlier quoted context omitted.

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.

Re: Airyx OS

#174

Post by trasz »

rjsw wrote: post #167
NotEvil wrote: post #162

Earlier quoted context omitted.

I don't think it's a licencing issue. It's implementation as both kernels uses different syscalls and have different architecture.

It takes a lot of work to get the Linux GPU drivers to build for other operating systems.

True. Although it’s way easier than it used to be, thanks to linuxkpi layer - the piece of FreeBSD kernel which implements various Linux kernel APIs.

Re: Airyx OS

#175

Post by protomyth »

mkl wrote: post #163
3np wrote: 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,_... .

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.

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.

Re: Airyx OS

#176

Post by geocar »

lapinot wrote: post #159
codetrotter wrote: post #153

Earlier quoted context omitted.

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.

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

Re: Airyx OS

#177

Post by ma2rten »

eafer wrote: post #54
3np wrote: 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+…

> 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

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.

Re: Airyx OS

#178

Post by jeremyjh »

AnIdiotOnTheNet wrote: post #154
foerbert wrote: post #26

Earlier quoted context omitted.

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?

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.

Re: Airyx OS

#179

Post by infogulch »

3np wrote: 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+…

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?

Re: Airyx OS

#180

Post by mkl »

protomyth wrote: post #175
mkl wrote: post #163

Earlier quoted context omitted.

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.

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

Post reply on HN