FUSE-T is a kext-less implementation of FUSE for macOS that uses NFSv4
1–10 of 73 posts
Re: FUSE-T is a kext-less implementation of FUSE for macOS that uses NFSv4
#2Why is there a GitHub and no source code?
Re: FUSE-T is a kext-less implementation of FUSE for macOS that uses NFSv4
#3I'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.
Re: FUSE-T is a kext-less implementation of FUSE for macOS that uses NFSv4
#4Why is there a GitHub and no source code?
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 [...]
Re: FUSE-T is a kext-less implementation of FUSE for macOS that uses NFSv4
#5Why is there a GitHub and no source code?
[deleted]
Re: FUSE-T is a kext-less implementation of FUSE for macOS that uses NFSv4
#6Previously discussed here:
Re: FUSE-T is a kext-less implementation of FUSE for macOS that uses NFSv4
#7Why 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.
Re: FUSE-T is a kext-less implementation of FUSE for macOS that uses NFSv4
#8Why is there a GitHub and no source code?
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" 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.
Re: FUSE-T is a kext-less implementation of FUSE for macOS that uses NFSv4
#9It’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!
Re: FUSE-T is a kext-less implementation of FUSE for macOS that uses NFSv4
#10What prevents Apple from just integrating MacFUSE(or a reimplementation) into the their kernel, and then shipping it with the next release?