Live data from Hacker News

FUSE-T is a kext-less implementation of FUSE for macOS that uses NFSv4

github.com

11–20 of 73 posts

Re: FUSE-T is a kext-less implementation of FUSE for macOS that uses NFSv4

#11

It’s surprising that given Apple’s war on kexts, they still haven’t come out with a proper API for implementing local user-space filesystems. It seems like this exists for remote filesystems (eg: Google Drive, Dropbox), but not for filesystems on local storage devices? This sounds like a nice workaround, though!

Yes, an Apple-supported API is likely coming. They’ve been gradually providing userspace alternatives for kernel extensions. Their API isn’t likely to be FUSE but hopefully the community will develop a translation layer.

I wonder if one of the holdups is that they don’t want a profusion of filesystems and would prefer everyone use ExFAT or APFS. Data loss/corruption ultimately results in more support calls and headaches for them, after all.

Re: FUSE-T is a kext-less implementation of FUSE for macOS that uses NFSv4

#12
post #8
post #4

Earlier quoted context omitted.

Does not answer your question directly, but related: https://github.com/macos-fuse-t/fuse-t/issues/1#issuecomment... > The project consists of two components: libfuse and fuse-t server. libfuse is LGPL licensed and can be downloaded from here: macos-fuse-t/libfuse [1]. You can modify and build it as you wish, the build instructions are provided in the README file. The fuse-t server on the other hand is a proprietary…

Weird that early in the issue comments the author claims they're going to release source for fuse-t, but then later in the comments changes course and says it's proprietary. Sounds like they originally wanted to release it as open source, but under a restrictive non-commercial license (which is fine, I guess), but then has gone back on that promise. I'm not gonna be one of those "proprietary software is immoral" peop…

Especially something like FUSE where it’s potentially the middle man of personal data.

If there’s concern about other companies profiteering, release it under a license that prevents such and those companies can pay to license under something else.

This approach could even be useful on Linux where fuse isn’t viable (e.g inside containers)

Re: FUSE-T is a kext-less implementation of FUSE for macOS that uses NFSv4

#13

What prevents Apple from just integrating MacFUSE(or a reimplementation) into the their kernel, and then shipping it with the next release?

I'd be shocked if there was any technical reason they couldn't; if they haven't, they either don't care or actively don't want to for some reason. (But yes, I think they could and a lot of people would be very happy if they did)

Re: FUSE-T is a kext-less implementation of FUSE for macOS that uses NFSv4

#14

Why is there a GitHub and no source code?

There are two FUSE implementations for macOS and neither is open source, unfortunately. One reason: it’s a critical component of several profitable, commercial products, but the authors of then-open source FUSE implementations found that none of those companies were willing to financially support their work. Those authors also haven’t seemed interested in crowdfunding when it has been proposed.

They actually tried with crowdfunding, but it didn't go well. Mostly because German laws and other things.

Re: FUSE-T is a kext-less implementation of FUSE for macOS that uses NFSv4

#15

It’s surprising that given Apple’s war on kexts, they still haven’t come out with a proper API for implementing local user-space filesystems. It seems like this exists for remote filesystems (eg: Google Drive, Dropbox), but not for filesystems on local storage devices? This sounds like a nice workaround, though!

> they still haven’t come out with a proper API for implementing local user-space filesystems.

They have, it's called a File Provider Extension (0). The major downside is that it's extremely limited in what you can provide and it's an extension of the interface on top of APFS and not a proper file system in user space.

Frankly, I don't think Apple cares about creating features that would interfere with their own offerings. User space file systems (to them) are for remote storage. Users should use iCloud. Apps that can't shim over iCloud should be file provider extensions.

If your app doesn't fit in those boxes then Apple doesn't care about providing the APIs to implement it cleanly on their platform. You can hack it through NFS.

(0) https://developer.apple.com/documentation/fileprovider

Re: FUSE-T is a kext-less implementation of FUSE for macOS that uses NFSv4

#17
post #15

It’s surprising that given Apple’s war on kexts, they still haven’t come out with a proper API for implementing local user-space filesystems. It seems like this exists for remote filesystems (eg: Google Drive, Dropbox), but not for filesystems on local storage devices? This sounds like a nice workaround, though!

> they still haven’t come out with a proper API for implementing local user-space filesystems. They have, it's called a File Provider Extension (0). The major downside is that it's extremely limited in what you can provide and it's an extension of the interface on top of APFS and not a proper file system in user space. Frankly, I don't think Apple cares about creating features that would interfere with their own offe…

I'm not sure "interfere with their own offerings" is quite the right framing. It's more about "going beyond their imagined use case".

iCloud Drive is a File Provider. Third-party services that want to do the same kind of file syncing as iCloud Drive, and thus compete it with it, can. And there are several highly-popular competitors that have recently moved to File Provider, like Dropbox and Google Drive. But when they did so they had to lose some functionality, like the ability to store data on an external drive [1]. And for the less popular use case of third-party filesystems that aren't just for syncing, File Provider is completely inapplicable.

The box covers most of the use cases that most users are using third-party filesystems for. But it's shrink-wrapped around those use cases – no room to invent new ones.

[1] https://talk.tidbits.com/t/dropbox-drops-support-for-storing...

Re: FUSE-T is a kext-less implementation of FUSE for macOS that uses NFSv4

#18

Why is there a GitHub and no source code?

There are two FUSE implementations for macOS and neither is open source, unfortunately. One reason: it’s a critical component of several profitable, commercial products, but the authors of then-open source FUSE implementations found that none of those companies were willing to financially support their work. Those authors also haven’t seemed interested in crowdfunding when it has been proposed.

See https://www.theregister.com/2019/12/16/fuse_macos_closed_sou... for more info. I wonder why a dual-licensing approach was not pursued though, e.g. some viral license (AGPL?) for the open-source part. This could have the same benefit of getting companies to negotiate an explicit (paid) license agreement while still making source available.

Re: FUSE-T is a kext-less implementation of FUSE for macOS that uses NFSv4

#19

It’s surprising that given Apple’s war on kexts, they still haven’t come out with a proper API for implementing local user-space filesystems. It seems like this exists for remote filesystems (eg: Google Drive, Dropbox), but not for filesystems on local storage devices? This sounds like a nice workaround, though!

I wish everyone would just standardize on 9p already. It's solid and has existed for going on thirty years.

Microsoft actually uses it for WSL, but afaik does provide the ability to access other 9p servers.

Re: FUSE-T is a kext-less implementation of FUSE for macOS that uses NFSv4

#20
I upgraded my MBP after keeping MBP 2013 for 10 years and had to go through the shamanic dance of booting Sonoma into the safe mode, changing preferences and rebooting again to get macfuse working and I would still prefer it to dealing with NFS.
Post reply on HN