> 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

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

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

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

>XNU is based on Mach

Partially, XNU is Mach AND the FreeBSD-Kernel:

https://www.youtube.com/watch?v=-7GMHB3Plc8

If you look at the source of a lot of drivers on MacOS a few years ago, they were heavily based on the FreeBSD drivers.

Yes sure they do, just look the presentation.

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.

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.

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.

A lot of us have long been tired of the "all things must be Linux" mantra. It is nice having options, having other environments.

100% correct, and I think FreeBSD is woefully underrated.

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

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

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

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

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.

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.

Can you elaborate on the second point?

courses offered by polytechnics and online learning platforms not being up-to-date, restricted and uneven access to expert implementers

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"

> It's a pity you are working with Linux, or it could have been of use to her.

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

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

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

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!

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.

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

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

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.

Nope, and it was a pity that they lost.

Ok, why was it a pity Oracle lost?

Android Java is Google's own flavour of J++ and needs to be slammed by the same exemplary way.

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

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

>Some MacOS frameworks like WebKit are also open sourced from Apple itself.

It had to be, it was forked from KHtml, which was GPL.

KHTML is LGPL, as is much of WebKit. If it was GPL, Safari would have to be too, instead of proprietary.

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.

GNUStep now it's implementing CoreVideo and CoreAudio.

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.

> Hard to see how this can be done legally.

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.

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.

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

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.

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.

I love an ambitious project like this.

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