[HN Gopher] FUSE-T is a kext-less implementation of FUSE for mac...
___________________________________________________________________
FUSE-T is a kext-less implementation of FUSE for macOS that uses
NFSv4
Author : nimish
Score : 81 points
Date : 2023-12-26 20:13 UTC (2 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| PlutoIsAPlanet wrote:
| Why is there a GitHub and no source code?
| fathyb wrote:
| 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
| component, it's written in go and doesn't link to or includes
| anything GPL related, all respective copyright owners are
| mentioned in License.txt file [...]
|
| [1] https://github.com/macos-fuse-t/libfuse
| kelnos wrote:
| 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" people, but it just rubs me the wrong way to see
| someone take a concept/protocol that was originally developed
| in the open and released as open source (the Linux version of
| FUSE itself), and then build something proprietary.
| PlutoIsAPlanet wrote:
| 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)
| rgovostes wrote:
| 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.
| xaerise wrote:
| They actually tried with crowdfunding, but it didn't go well.
| Mostly because German laws and other things.
| krackers wrote:
| 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.
| nextfx wrote:
| I've been using mksquashfs to make full-system backups lately,
| but had to resort to using unsquashfs for recovering files. This
| combined with squashfuse might come in handy.
| EdSchouten wrote:
| Previously discussed here:
|
| https://news.ycombinator.com/item?id=32726166
| Reason077 wrote:
| 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!
| rgovostes wrote:
| 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.
| duped wrote:
| > 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
| comex wrote:
| 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...
| donatj wrote:
| I wish everyone would just standardize on 9p already. It's
| solid and has existed for going on thirty years. Microsoft uses
| it for WSL, but afaik does provide the ability to access other
| 9p servers.
| mathiasgredal wrote:
| What prevents Apple from just integrating MacFUSE(or a
| reimplementation) into the their kernel, and then shipping it
| with the next release?
| yjftsjthsd-h wrote:
| 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)
| pjmlp wrote:
| Basically doesn't fit their roadmap.
| mynegation wrote:
| 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.
___________________________________________________________________
(page generated 2023-12-26 23:00 UTC)